로드 밸런싱(Load Balancing) 둘 이상의 CPU or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것 요즘 시대에는 웹 사이트에 접속하는 인원이 급격히 늘어나게 되었다. 따라서 이 사람들에 대해 모든 트래픽을 감당하기엔 1대의 서버로는 부족하다. 대응 방안으로 하드웨어의 성능을 올리거나(Scale-up) 여러대의 서버가 나눠서 일하도록 만드는 것(Scale-out)이 있다. 하드웨어 향상 비용이 더욱 비싸기도 하고, 여러대면 무중단 서비스를 제공하는 환경 구성이 용이하므로 Scalue-out이 효과적이다. 이때 여러 서버에게 균등하게 트래픽을 분산시켜주는 것이 바로 로드 밸런싱이다. 로드 밸런싱은 분산식 웹 서비스로, 여러 서버에 부하(Load)를 나누어주는 역할을 한다. Load Bala..
대칭키 & 공개키 [대칭키 암호화] 암호화에 사용되는 키와 복호화에 사용되는 키가 동일한 암호화 기법이다. 대칭키 암호 방식으로 암호화한 정보를 누군가에게 보낼 때, 암호키도 함께 보내야 한다. 암호키 자체는 암호화가 되지 않은 평문으로 분실하거나 타인에게 노출되면 보안에 매우 취약할 수 있다. 키 전달 및 관리에 어려움이 있지만, 대칭키 암호화 방식은 암호화 연산 속도가 빠르기 때문에 효율적인 암호 시스템을 구축할 수 있다는 장점이 있다 블록 암호화, 스트림 암호화가 있다. [공개키 암호화] 대칭키 암호화 방식의 키 전달의 취약점을 해결하기 위해 나온 방식이다. 암호화에 사용하는 키와 복호화에 사용하는 키를 분리했다. 따라서 비대칭키 암호화라고도 부른다. 자신기 가지고 있는 고유한 암호키(개인키 or ..
I/O 작업 I/O 작업은 Input/Output의 약자이다. 주로 파일 입출력을 다룰 때, 흔히 볼 수 있다. ex) 2대 이상의 컴퓨터끼리 서로 네트워크를 통해 통신을 한다고 가정할 때, 한 컴퓨터에서 출력(send)을 하고 다른 한 컴퓨터에서 입력(read)을 받는 과정을 통해 통신할 수 있다. I/O 작업은 User Level에서 직접 진행할 수 없고, 실제 I/O 작업을 수행하는 것은 Kernel Level에서만 가능하다. User Process, Thread는 커널에게 요청하고 작업 완료 후, 커널이 반환하는 결과를 기다릴 뿐이다. Blocking Model 가장 기본적인 I/O 모델로, 리눅스에서 모든 소켓 통신은 기본 blocking으로 동작한다. I/O 작업이 진행되는 동안 유저 프로세스..
Cookie & Session HTTP는 비상태성(Stateless) 프로토콜로 상태 정보를 유지하지 않는다. 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것은 큰 장점이지만 통신할 때마다 매번 연결 설정을 해야 하며, 이전 요청과 현재 요청이 같은 사용자의 요청인지 알 수 없다는 단점이 존재한다. 쿠키와 세션을 통해서 HTTP의 Stateless한 문제점을 해결할 수 있다. 저장위치 쿠키: 클라이언트의 웹 브라우저가 지정하는 메모리 or 하드 디스크 세션: 서버의 메모리 만료 시점 쿠키: 저장할 때, expires 속성을 정의하여 무효화시키면 삭제될 날짜를 지정할 수 있다. 세션: 클라이언트가 로그아웃하거나 설정 시간 동안 반응이 없으면 무효화되기 때문에 정확한 시점을 알 수 없다. 리소스 쿠키..
HTTP (HyperText Transfer Protocol) 웹 서버와 클라이언트 간의 문서를 교환하기 위한 통신 규약 웹에서만 사용하는 프로토콜로 TCP/IP 기반으로 서버와 클라이언트 간의 요청과 응답을 전송한다. HTTP의 특징 TCP 기반의 통신 방식 비연결 지향 브라우저를 통해 사용자의 요청으로 서버와 접속하여 요청에 대한 응답의 데이터를 전송 후, 연결을 종료한다. 간단하기 때문에 자원이 적게드는 장점이 있다. 하지만, 연결이 지속적이지 않기 때문에 사용자와 연결 종료후 추가적인 요청시 어떤 사용자의 요청인지 모른다는 점이 존재한다. 즉, 여러 사용자가 요청할 시 각각의 사용자 요청을 구분할 수 없어서 제대로 된 응답 데이터를 전송할 수 없다는 단점이 있다. 해결 방법으로는 쿠키, 세션, 히..
주소창에 naver.com을 치면 일어나는 일 면접 질문에 자주 나오는 질문이다. 올해 어디 공채에서도 이 문제가 나왔는데, 답을 못했던 문제이다. 이번 기회에 정리해보자! IP 주소 IP 주소란 많은 컴퓨터들이 인터넷 상에서 서로를 인식하기 위해 지정받은 식별용 번호라고 생각하면 된다. 현재는 IPv4 버전(32 비트)로 구성되어 있으며, 127.0.1 같은 주소를 말한다. 시간이 갈수록 IPv4 주소의 부족으로 IPv6가 생겼는데, 128비트로 구성되어 있기 때문에 IP주소가 부족하지 않다는 특징이 있다. 도메인 네임(Domain Name) IP 주소는 12자리의 숫자로 되어 있기 때문에 사람이 외우기 힘들다는 단점이 있다. 그렇기 때문에 12자리의 IP 주소를 문자로 표현한 주소를 도메인 네임이라고..
Computer Science/네트워크
[네트워크] - 로드 밸런싱(Load Balancing)
로ᄏｌ2020. 9. 25. 08:40
728x90
로드 밸런싱(Load Balancing)
둘 이상의 CPU or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것
요즘 시대에는 웹 사이트에 접속하는 인원이 급격히 늘어나게 되었다. 따라서 이 사람들에 대해 모든 트래픽을 감당하기엔 1대의 서버로는 부족하다. 대응 방안으로 하드웨어의 성능을 올리거나(Scale-up) 여러대의 서버가 나눠서 일하도록 만드는 것(Scale-out)이 있다. 하드웨어 향상 비용이 더욱 비싸기도 하고, 여러대면 무중단 서비스를 제공하는 환경 구성이 용이하므로 Scalue-out이 효과적이다. 이때 여러 서버에게 균등하게 트래픽을 분산시켜주는 것이 바로 로드 밸런싱이다.
로드 밸런싱은 분산식 웹 서비스로, 여러 서버에 부하(Load)를 나누어주는 역할을 한다. Load Balancer를 클라이언트와 서버 사이에 두고, 부하가 일어나지 않도록 여러 서버에 분산시켜주는 방식이다. 서비스를 운영하는 사이트의 규모에 따라 웹 서버를 추가로 증설하면서 로드 밸런서로 관리해주면 웹 서버의 부하를 해결할 수 있다.
로드 밸런서가 서버를 선택하는 방식
라운드 로빈(Round Robin): CPU 스케줄링의 라운드 로빈 방식 활용
Least Connections: 연결 개수가 가장 적은 서버 선택 (트래픽으로 인해 세션이 길어지는 경우 권장)
Source: 사용자 IP를 해싱하여 분배 (특정 사용자가 항상 같은 서버로 연결되는 것 보장)
로드 밸런서 장애 대비
서버를 분배하는 로드 밸런서에 문제가 생길 수 있기 때문에 로드 밸런서를 이중화하여 대비한다.
대칭키 암호 방식으로 암호화한 정보를 누군가에게 보낼 때, 암호키도 함께 보내야 한다. 암호키 자체는 암호화가 되지 않은 평문으로 분실하거나 타인에게 노출되면 보안에 매우 취약할 수 있다.
키 전달 및 관리에 어려움이 있지만, 대칭키 암호화 방식은 암호화 연산 속도가 빠르기 때문에 효율적인 암호 시스템을 구축할 수 있다는 장점이 있다
블록 암호화, 스트림 암호화가 있다.
[공개키 암호화]
대칭키 암호화 방식의 키 전달의 취약점을 해결하기 위해 나온 방식이다. 암호화에 사용하는 키와 복호화에 사용하는 키를 분리했다. 따라서 비대칭키 암호화라고도 부른다.
자신기 가지고 있는 고유한 암호키(개인키 or 비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에게 공개한다.
공개키 암호화 방식의 진행과정
B 사용자는 자신의 공개키를 공개한다. 이 공개키는 암호화에 사용되는 키이며, 누구든지 열람이 가능하다. (복호화에 사용되는 키는 B 자신만 가지고 있다. 잃어버리면 안된다)
A 사용자는 B 사용자의 공개키로 데이터를 암호화한다.
암호화된 문서를 B 사용자에게 전송한다.
B 사용자는 자신만의 개인키(복호화키)를 이용하여 전송받은 암호화 문서를 복호화하여 데이터를 열람한다.
대칭키 암호화 방식의 키 전달 문제를 해결했지만 암호화, 복호화를 위해 복잡한 수학 연산을 수행하기 때문에 대칭키 방식에 비해 속도가 느리고 복잡하다는 단점이 있다.
공개키 기반 구조
특정 사람의 개인키와 공개키는 어떻게 생성할 것이며, 어떻게 배포할 것이고 어떻게 관리해야 하는가에 대한 이슈가 존재한다. 또한, 어떤 공개키가 특정한 사람의 공개키라는 것을 어떻게 보장할 수 있는지에 대한 이슈도 존재한다.
이를 해결하기 위해 디지털 인증서도 도입했고 이를 활용하는 소프트웨어, 하드웨어, 정책, 제도, 사용자 등을 총칭해서 공개키 기반 구조라고 한다.
대칭키와 공개키 암호화 방식을 적절히 혼합해보면?
SSL 탄생의 시초가 됨
1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화고 B에게 보냄
2. B는 암호문을 받고, 자신의 비밀키로 복호화함.
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄
4. A는 자신의 대칭키로 암호문을 복호화함
5. 앞으로 이 대칭키로 암호화를 통신함
즉, 대칭키를 주고받을 때만 공개키로 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신하는 것!
HTTP는 비상태성(Stateless) 프로토콜로 상태 정보를 유지하지 않는다. 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것은 큰 장점이지만 통신할 때마다 매번 연결 설정을 해야 하며, 이전 요청과 현재 요청이 같은 사용자의 요청인지 알 수 없다는 단점이 존재한다.
쿠키와 세션을 통해서 HTTP의 Stateless한 문제점을 해결할 수 있다.
저장위치
쿠키: 클라이언트의 웹 브라우저가 지정하는 메모리 or 하드 디스크
세션: 서버의 메모리
만료 시점
쿠키: 저장할 때, expires 속성을 정의하여 무효화시키면 삭제될 날짜를 지정할 수 있다.
세션: 클라이언트가 로그아웃하거나 설정 시간 동안 반응이 없으면 무효화되기 때문에 정확한 시점을 알 수 없다.
리소스
쿠키: 클라이언트에 저장되고 클라이언트의 메모리를 사용하기 때문에 서버 자원을 사용하지 않는다.
세션: 서버에 저장되고, 서버 메모리로 로딩되기 때문에 세션이 생길 때마다 리소스를 차지한다.
용량 제한
쿠키: 클라이언트도 모르게 접속되는 사이트에 의하여 설정될 수 있기 때문에 쿠키로 인해 문제가 발생하는 걸 막고자 한 도메인당 20개, 하나의 쿠키당 4KB로 제한해두었다.
클라이언트는 인증서가 신용이 있는 CA로부터 서명된 것인지 판단한다. 브라우저는 CA 리스트와 해당 CA의 공개키를 가지고 있다. 공개키를 활용하여 인증서가 복호화가 가능하다면 접속한 사이트가 CA에 의해 검토되었다는 것을 의미한다. 따라서 서버가 신용이 있다고 판단한다. 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것으로 이러한 것을 전자 서명이라고 한다.
클라이언트는 CA의 공개키를 이용해 인증서를 복호화하고, 서버의 공개키를 획득한다.
클라이언트는 서버의 공개키를 사용해 랜덤 대칭 암호화키, 데이터 등을 암호화하여 서버로 전송한다.
서버는 자신의 개인키를 이용해 복호화하고 랜덤 대칭 암호화키, 데이터 등을 획득한다.
서버는 랜덤 대칭 암호화키로 클라이언트 요청에 대한 응답을 암호화하여 전송한다.
클라이언트는 랜덤 대칭 암호화키를 이용해 복호화하고 데이터를 이용한다.
인증서에 포함된 내용
서버측 공개키 (public key)
공개키 암호화 방법
인증서를 사용한 웹서버의 URL
인증서를 발행한 기관 이름
모든 웹페이지에서 HTTPS를 사용하지 않는다. 이유는 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 많이 필요로 하기 때문이다. 통신할 때마다 암호화를 하면 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 Request 수가 줄어들게 된다.
따라서 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용해야 한다. 또한, HTTPS도 무조건 안전한 것은 아니다. (신뢰받는 CA 기업이 아닌 자체 인증서를 발급한 경우 etc..) 이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의 받게 된다.
면접 질문에 자주 나오는 질문이다. 올해 어디 공채에서도 이 문제가 나왔는데, 답을 못했던 문제이다. 이번 기회에 정리해보자!
IP 주소
IP 주소란 많은 컴퓨터들이 인터넷 상에서 서로를 인식하기 위해 지정받은 식별용 번호라고 생각하면 된다.
현재는 IPv4 버전(32 비트)로 구성되어 있으며, 127.0.1 같은 주소를 말한다.
시간이 갈수록 IPv4 주소의 부족으로 IPv6가 생겼는데, 128비트로 구성되어 있기 때문에 IP주소가 부족하지 않다는 특징이 있다.
도메인 네임(Domain Name)
IP 주소는 12자리의 숫자로 되어 있기 때문에 사람이 외우기 힘들다는 단점이 있다.
그렇기 때문에 12자리의 IP 주소를 문자로 표현한 주소를 도메인 네임이라고 한다.
다시 말해서, 도메인 네임은 'naver.com'처럼 몇 개의 의미있는 문자들과 '.'의 조합으로 구성된다.
도메인 네임은 사람의 편의성을 위해 만든 주소이므로 실제로는 컴퓨터가 이해할 수 있는 IP 주소로 변환하는 작업이 필요하다.
이때, 사용할 수 있도록 미리 도메인 네임과 함께 해당하는 IP 주소값을 한 쌍으로 저장하고 있는 데이터베이스를 DNS(Domain Name System) 이라고 부른다.
도메인 네임으로 입력하면 DNS를 이용해 컴퓨터는 IP 주소를 받아 찾아갈 수 있다.
작동 방식
사용자가 브라우저에 도메인 네임(www.naver.com)을 입력한다.
사용자가 입력한 URL 주소 중에서 도메인 네임(Domain Name) 부분을 DNS 서버에서 검색하고, DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달한다.
페이지 URL 정보와 전달받은 IP 주소는 HTTP 프로토콜을 사용하여 HTTP 요청 메시지를 생성하고, 이렇게 생성된 HTTP 요청 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP 주소의 컴퓨터로 전송된다.
이렇게 도착한 HTTP 요청 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환되어 웹 페이지 URL 정보에 해당하는 데이터를 검색한다.
검색된 웹 페이지 데이터는 또 다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지를 생성하고 TCP 프로토콜을 사용하여 인터넷을 거쳐 원래 컴퓨터로 전송된다.
도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환되어 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 된다.
DHCP & ARP
대부분의 가정집에서는 DHCP로 인터넷 접속을 하고 있다. DHCP는 Dynamic Host Configuration Protocol의 약자로, 호스트의 IP 주소 및 TCP / IP 설정을 클라이언트에 자동으로 제공하는 프로토콜이다. 사용자의 PC는 DHCP 서버에서 사용자 자신의 IP 주소, 가장 가까운 라우터의 IP 주소, 가장 가까운 DNS 서버의 IP 주소를 받는다. 이후, ARP 프로토콜을 이용하여 IP 주소를 기반으로 가장 가까운 라우터의 MAC 주소를 알아낸다.
DHCP 서버의 동작 개념도 - 클라이언트가 인터넷 접속을 시도하면 IP와 기본 정보를 제공해준다
IP 정보 수신 위의 과정을 통해 외부와 통신할 준비를 마쳤으므로, DNS Query를 DNS 서버에 전송한다. DNS 서버는 이에 대한 결과로 웹 서버의 IP 주소를 사용자 PC에 돌려준다. DNS 서버가 도메인에 대한 IP 주소를 송신하는 과정은 약간 복잡하다.
사용자의 PC는 가장 먼저 지정된 DNS 서버(우리나라의 경우, 통신사별로 지정된 DNS 서버가 있다)에 DNS Query를 송신한다. 그 후 지정된 DNS 서버는 Root 네임서버에 www.naver.com을 질의하고, Root 네임서버는 .com 네임서버의 ip 주소를 알려준다.
이와 같이 여러번 왔다갔다 하는 이유는, 도메인의 계층화 구조에 따라 DNS 서버도 계층화 되어있기 때문이다. 이렇게 계층화되어 있으므로 도메인의 가장 최상단, 즉 가장 뒷쪽(ex .com, .kr)을 담당하는 DNS 서버는 전세계에 13개 뿐이다.
웹 서버 접속
이제 웹 서버의 IP 주소까지 알았다. Http Request를 위해 TCP Socket을 개방하고 연결한다. 이 과정에서 3-way hand shaking 과정이 일어난다. TCP 연결에 성공하면, Http Reqeust가 TCP Socket을 통해 보내진다. 이에 대한 응답으로 웹 페이지의 정보가 사용자의 PC로 들어온다.
