아래의 내용을 보기 전에 헷갈릴만한 용어 정리

• Proxy : 대리라는 뜻으로 남을 대신하여 처리한다는 뜻으로 사용
  • Spring Proxy, Proxy 패턴, Network Proxy등이 있는데 여기선 Network Proxy에 대한 설명을 하려한다.
• Proxy Server : 말 그대로 대신 처리하는 서버이다.
  • 즉 클라이언트와 서버 사이에 위치한 레이어 같은 느낌의 서버이다.
  • 클라이언트와 서버간의 중개 서버로, 통신을 대리 수행하는 서버이다.
  • 캐시/보안/트래픽 분산 등 여러 장점을 가질 수 있다.
• Forward Proxy :일반적으로 Network Proxy는 Foward Proxy를 가리킨다.
  • 보통 클라이언트에서 Foward Proxy를 경유한 뒤 Internet으로 보내고 그 다음 서버로 오게 되는 구조를 가리킨다. 주요 기능으론 아래와 같다.
  • 먼저 캐싱이 있다. 클라이언트가 요청한 내용을 캐싱한다.
    • 예를 들어 어떤 API를 물었을 때 이를 대답해준뒤 Foward Proxy에 이에 대한 API 요청을 캐싱한다.
    • 이후 같은 요청을 물었을 때 서버까지 API가 전달되지 않고 바로 응답을 할 수 있게 된다.
  • 다음 특징으론 익명성이 있다. 이는 클라이언트가 보낸 요청을 감추는 기능이다.
    • 만약 프록시가 없다면 리퀘스트 내용을 그대로 인터넷에 실어 서버로 보내게 된다. 즉 누가 요청한지 알 수 있다.
    • 하지만 Foward Proxy를 사이에 두면 요청이 모두 Foward Proxy를 통해 온 것처럼 보인다. 이를 통해 클라이언트에 익명성을 보장할 수 있다.
• Reverse Proxy : Foward Proxy랑 비슷하다. 다른점은 Foward Proxy는 클라이언트 - 프록시서버 - 인터넷 - 서버 구조라면 Reverse Proxy는 반대로 클라이언트 - 인터넷 - 프록시서버 - 서버 구조로 되어있다.
  • 주요 기능들은 아래와 같다.
  • 먼저 위와 동일하게 캐싱이 있다.
  • 그리고 보안이 있다. 이는 서버 정보를 클라이언트로부터 숨기는 효과가 있다. 위의 익명성을 역으로 사용했다고 보면 된다.
    • 이렇게 되면 서버는 실제 서버를 모르고 앞에 리버스 프록시만 알기 때문에 실제 서버의 IP가 노출되지 않게 된다.
  • 그리고 Load Balancing이 있다. 하는 경우도 있고 안하는 경우도 있다. 이제 Load Balancing에 대한 설명을 하도록 하겠다.

Load Balancing

• 아키텍쳐 : Client - Internet - |Load Balancer - 다수의 서버|로 구성된다. 즉 리버스 프록시를 둔다는 것이다.

Load Balancer

로드 밸런서란 서버에 가해지는 부하(=Load)를 분산(=Balancing)해주는 장치 또는 기술을 통칭한다. 클라이언트와 서버풀(Server Pool, 분산 네트워크를 구성하는 서버들의 그룹) 사이에 위치하며, 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 한다. Molithic Architecture를 기준으로 말하면 서버를 스케일아웃해서 각각의 서버에 대한 부하를 분산시키는 것이다. 여기서 균등하게 분산해 주기 위해 로드밸런싱이 필요한 것이다.

로드 밸런싱이 필요한 경우?

로드 밸런싱은 여러 대의 서버를 두고 서비스를 제공하는 분산 처리 시스템에서 필요한 기술이다. 서비스의 제공 초기 단계라면 적은 수의 클라이언트로 인해 서버 한 대로 요청에 응답하는 것이 가능하다. 하지만 규모가 커지고, 클라이언트 수가 많아지면 기존 서버만으로는 서비스를 운영하기 힘들다.

이러한 문제를 해결하기 위한 방법으로는 2가지 방법이 있다.

Scale-up, Scale-out

Scale-up

서버 자체의 성능을 확장하는 것을 의미한다. 서버의 하드웨어적인 측면에서 고성능의 부품으로 업그레이드를 하는 것이다.

Scale-out

기존 서버와 동일하거나 낮은 성능의 서버를 두 대 이상 증설하여 운영하는 것을 의미한다. Scale-up은 너무 비싸서 현실적으로는 힘들다. 따라서 서버가 여러대 존재하는 Scale-out 방법을 사용한다. 이를 사용하면 무중단 서비스를 제공하는 환경 구성이 용이하므로 Scale-out이 더 좋기도 하다.

그리고 Scale-out의 방식으로 서버를 증설하기로 결정했다면 여러 대의 서버로 트래픽을 균등하게 분산해주는 로드밸런싱이 반드시 필요하다.

로드밸런싱 알고리즘

L2와 L3에 대한 로드밸런싱도 있지만 백엔드 개발자로서 알아야 되는 것은 L4, L7이 더 중요하다. 따라서 해당 내용에 대한 설명만 하도록 하겠다. L2와 L3에 대해 간단하게 이야기 하면 Mac주소와 IP 주소를 바탕으로 로드밸런싱을 한다고 생각하면 된다.

그리고 L4는 TransPort Layer에서 IP와 Port Level에서 로드밸런싱을 하는 것이다. 예를 들면 어떤 사이트를 접근 할 때 각각의 서버에 로드밸런싱을 해준다. Port와 Ip를 알기 때문이다.

L7은 말 그대로 Application Level에서 로드밸런싱을 하는 것을 의미한다. 이번에도 마찬가지로 어떤 사이트를 접근 할 때 /category나 /search와 같은 자원에 접근한다고 할 때 담당 서버들로 로드밸런싱을 하는 것을 의미한다.

1. L4 로드밸런싱
   L4 로드밸런싱의 특징은 아래와 같다.

   • 라운드로빈 방식(Round Robin Method)
     • 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식이다. 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합하다.
   • 가중 라운드로빈 방식(Weighted Round Robin Method)
     • 각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분하는 방식이다. 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식이다.
     • 예를들어 A서버가 5의 가중치, B의 서버가 2의 가중치를 갖는다면, 로드밸런서는 라운드 로빈 방식으로 A서버에 5개 B서버에 2개의 요청을 전달한다.
   • IP 해시 방식(IP Hash Method)
     • 클라이언트의 IP주소를 특정 서버로 매핑하여 요청을 처리하는 방식이다. 사용자의 IP를 해싱해 로드를 부내하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.
   • 최소 연결 방식(Least Connection Method)
     • 요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽을 배분하는 방식이다.
     • 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합한 방식이다.
   • 최소 리스폰타임(Least Response Time Method)
     • 서버의 현재 연결 상태와 응답시간(Response Time, 서버에 요청을 보내고 최초 응답을 받을 때까지 소요되는 시간)을 모두 고려하여 트래픽을 배분하는 방식이다.
     • 가장 적은 연결 상태와 가장 짧은 응답시간을 보이는 서버에 우선적으로 로드를 배분하는 방식이다.

2. L7 로드 밸런싱

L7 로드밸런서는 위와 같은 L4 로드밸런서의 기능을 포함하는 것 뿐 아니라 OSI 7계층의 프로토콜을 바탕으로도 분산 처리가 가능하다. 예를들면, 온라인 쇼핑몰의 장바구니에 물건들을 담아놓고 다른 서버에서 처리하기는 힘들 것이다.

• URL 스위칭 방식(URL Switching)
  • 특정 하위 URL들을 특정 서버로 처리하는 방식이다.
  • '../steven/image' 또는 '../steven/video'와 같은 특정 URL을 가진 주소들은 서버가 아닌 별도의 스토리지에 있는 객체 데이터로 바로 연결되도록 구성 가능하다.
• Conetext Switching 방식
  • 클라이언트가 요청한 특정 서버 등으로 연결을 해줄 수 있다.
  • 예를들어 이미지 파일에 대해 확장자를 참조하여 별도로 구성된 이미지 파일이 있는 서버/스토리지로 직접 연결해줄 수 있다.
• 쿠키 지속성 (Persistence with Cookies)
  • 쿠키 정보를 바탕으로 클라이언트가 연결 했었던 동일한 서버에 계속 할당해주는 방식이다.
  • 특히 사설 네트워크에 있던 클라이언트 IP 주소가 공인 IP 주소로 치환되어 전송 (X-Forwarded-For 헤더에 클라이언트 IP 주소를 별도 기록) 하는 방식을 지원한다.

로드밸런서의 기본 동작 방식

1. 클라이언트의 브라우저에 naver.com 이라고 입력한다
2. 클라이언트에 설정된 메인 DNS 서버로 naver.com의 IP 주소를 문의한다.
3. 메인 DNS서버는 naver.com주소를 관리하는 별도의 DNS서버에 IP 주소를 문의한다.
4. 별도 관리 DNS 서버는 로드밸런서의 IP (Virtual IP) 주소를 메인 DNS 서버에게 알려준다.
5. 메인 DNS 서버는 획득한 VIP 주소를 클라이언트에 전송한다.
6. 클라이언트에서 로드밸런서의 VIP 주소로 http를 요청한다.
7. 로드밸런서는 별도 로드밸런싱 방법(ex 라운드로빈 등) 을 통하여 서버에게 요청을 전송한다.
8. 서버의 작업 결과를 받은 로드밸런서는 전달받은 http 결과를 클라이언트에게 전송한다.

로드 밸런서의 기본 기능

1. Health Check
   • 기본적으로 보통의 로드밸런서는 서버들 (또는 다음의 노드)에 대한 주기적인 Health Check를 통해 서버들의 장애 여부를 판단할 수 있다. 이로 인해 로드밸러서가 있을 때 서버 몇 대에 이상이 생기더라도 다른 정상 동작중인 서버로 트래픽을 보내주는 Fail-over가 가능하며, 또한 TCP/UDP 분석이 가능하기 때문에 Firewall의 역할도 수행할 수 있다.
     • L3 체크 : ICMP를 이용하여 서버의 IP 주소가 통신 가능한 상태인지 확인한다.
     • L4 체크 : TCP는 3 Way-Handshaking (전송 -> 확인/전송 -> 확인) 를 기반으로 통신한다. 이러한 TCP의 특성을 바탕으로 각 포트 상태를 체크하는 방식이다. 예를 들어 , HTTP 웹 서버의 경우 80 포트를 사용하므로 TCP 80 포트에 대한 체크를 통해 서버가 살아있는 상태인지 확읺나다.
     • L7 체크 : 어플리케이션 계층에서 체크한다. 즉 , 실제 웹페이지애 통신을 시도해서 이상 유무를 파악한다.
2. Tunneling
   • 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념으로, 로드밸런서는 클라이언트와 서버 간 중간에서 터널링을 제공한다. 즉, 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제하게 한다.
3. NAT (Network Address Translation)

• IP 주소를 변환해주는 기능이다. (목적지와 수신자의 IP주소와 TCP/UDP 포트를 재기록하여 변환하며 네트워크 트래픽을 주고 받을 수 있다.) 예를 들어, 내부 네트워크에서 사용하던 사설 IP 주소를 로드밸런서 외부의 공인 IP 주소로 변경해준다. (반대도 가능) 이렇게 하면 부족한 공인 IP 주소를 효율적으로 사용 가능하지만, 로드밸런싱 관점에서는 여러개의 호스트가 하나의 공인 IP 주소(VIP)를 통해 접속하는 것이 주 목적이다.
• SNAT (Source Network Address Translation) : 내부에서 외부로 트래픽이 나가는 경우, 내부 사설 IP주소를 외부의 공인 IP 주소로 변환하는 방식이다. 집에서 사용하는 공유기가 그 예시이다.
• DNAT (Destination Network Address Translation) : 외부에서 내부로 트래픽이 들어오는 경우, 외부 공인 IP주소를 내부의 사설 IP 주소로 변환하느 방식이다. 로드밸런서가 이를 사용한다.

L4와 L7

네트워크 통신 시스템은 크게 일곱 가지의 계층으로 나뉘는데 L4와 L7 로드밸런서가 부하 분산에 가장 많이 활용된다. L4 밸런서부터 포트(Port)정보를 바탕으로 로드를 분산하는 것이 가능하기 때문이다. 한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드밸런서 이상을 사용해야 한다.

L4 로드밸런싱

• 아키텍쳐 : 클라이언트 - 로드밸런서 - 다수의 웹-백엔드 - 데이터베이스
• L4 로드밸런서는 네트워크 계층(IP, IPX)이나 트랜스포트 계층(TCP, UDP)의 정보를 바탕으로 로드를 분산한다. IP 주소나 포트번호, MAC주소, 전송 프로토콜에 따라 트래픽을 나누는 것이 가능하다.
• 데이터 안을 보지 않고 패킷 레벨에만 로드를 분산하기 때문에 속도가 빠르고 효율이 높다.
• 섬세한 라우팅이 불가능하지만 L7로드 밸런서보다 저렴하다.

L7 로드밸런싱

• 아키텍쳐 : 클라이언트 - 로드밸런서 - 웹백엔드 및 메신저-백엔드 - 데이터베이스
• 애플리케이션 계층(HTTP,FTP,SMTP..)에서 로드를 분산하기 때문에 HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다. 쉽게 말해 패킷의 내용을 확인하고, 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능하다. URL에 따라 부하를 분산(메신저-백엔드)시키거나 , HTTP헤더의 쿠키값에 따라 부하를 분산(웹-백엔드)하는 등 클라이언트의 요청을 보다 셉분화해 서버에 전달할 수 잇다.
• 또한 L7 로드밸런서의 경우 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있으며, DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있어 넷웤 보안분야에서도 활용되고 있다.
• 즉 정리하자면 더 섬세한 라우팅이 가능하고, 비정상적인 트래픽을 필터링 할 수 있다.
• 하지만 패킷의 내용을 복호화 해야하기 때문에 더 많은 비용이 든다.

L4 vs L7

	L4	L7
네트워크 계층	L4	L7
특징	TCP/UDP 포트 정보 바탕	TCP/UDP 포트 정보 + HTTP의 URI, FTP의파일명, 쿠키 정보 등을 바탕으로 함
장점	1. 데이터 안을 들여보지 않고 패킷 레벨에서만 로드를 분산해 속도가 빠르고 효율이 좋다. 2. 데이터의 내용을 복호화할 필요가 없기 때문에 안전하다. 3. L7보다 저렴하다.	1. 상위 계층에서도 로드를 분산하기 때문에 더 섬세한 라우팅이 간으하다. 2. 캐싱 기능을 제공한다. 3. 비정상적인 트래픽을 사전에 필터링할 수 있어 서비스 안정성이 높다.
단점	1. 패킷의 내용을 살펴볼 수 없기 때문에 섬세한 라우팅이 불가능하다. 2. 사용자의 IP가 수시로 바뀌는 경우 연속적인 서비스를 제공하기 어렵다.	1. 패킷의 내용을 복호화해야 하기에 더 높은 비용을 지불한다. 2. 클라이언트가 로드밸런서와 인증서를 공유해야 하기 때문에 공격자가 로드밸런서를 통해 클라이언트 데이터에 접근할 보안 상의 위험이 존재한다.

L4/L7 로드밸런서의 주요 성능 짚

1. 초당 연결수 (Connections per second) : 최대 처리 가능한 초당 TCP 세션의 개수를 의미한다.
2. 동시 연결수 (concureent connections) : 동시에 최대로 세션을 유지할 수 있는 개수를 의미한다.
3. 처리용량 (Throughput) : (패킷 자체에 연결이 성립되는) UDP 프로토콜에 대한 로드밸런싱 성능 지표이다. FWLB(Firewall Load Balancing)에서 중요하다. 단위는 bps(bit per second) 또는 pps(packet per second)를 사용한다.

Load Balancer 장애 대비

• 로드 밸런서 또한 만능의 장비가 아니기 때문에 장애가 날 경우를 대비해야 한다. 로드 밸런서를 이중화하여 장애를 대비할 수 있다. (Active, Passive)

• 시나리오

  1. 이중화된 Load Balancer들은 서로 Health Check를 한다.
  2. Main Load Balancer가 동작하지 않으면 가상IP(VIP, Virtual IP)는 여분의 Load Balancer로 변경된다.
  3. 여분의 Load Balancer로 운영하게 된다.

Load Balancing 방식

1. SLB(Server Load Balancing)
2. FWLB (Firewall Load Balancing)
3. VPNLB (VPN Load Balancing)
4. CSLB (Cache Server Load Balancing)

SLB (Server Load-Balancing)

IP 주소와 Port 번호를 참조하여 여러 서버에 적절한 부하 분산 알고리즘(Load Balancing Algo)통해 전달하는 방식이다. Load Balancing을 위해 모든 서버들을 대표하는 가상의 IP (virtual IP)주소를 사용한다.

도입 배경 및 효과

예전에는 온라인 서비스 자체가 활발하지 않고, Old Site by html, image 간단한 서비스 만을 사용했다. 요즘은 New Site by html, cgi, ssl, flash 들은 복잡한 환경, TCO 증가, 많은 연계 서비스, 트래픽 관리가 필요하게 되었다. 그래서 서버를 크게 늘리고 CPU, MEMORY등에 스케일업해서 사용하였다. 하지만 서버가 Down되면, 서비스 자체를 불가능하고, 장애 처리시간 동안 엄청난 손실이 발생한다.

따라서 그걸보완하고자 L4 스위치를 이용한 SLB가 등장하였다. 이는 8대 서버를 두고 로드밸런싱을 사용하게 설정해서 1,2대가 다운돼도 남은 6~7대의 서버들이 서비스를 이상없이 하기 때문에 무결성을 위한 Fail-Over에 장점도 있다.

FWLB(Firewall Load Balancing)

두 대의 방화벽에 적절한 부하 분산 알고리즘(Load Balancing Alogorithm) 통해 전달하는 방식이다.

도입 배경 및 효과

기존의 한대의 방화벽을 사용했을 때 부하가 집중되면서 인터넷 서비스의 품질 저하 및 FW에 장애 발생 시 인터넷 서비스 사용불가 등 안정적이지 못하고 장애에 취약했다. L4스위치의 로드밸런싱 기능을 통해 방화벽 두대를 통한 FWLB를 사용하게 되었다. 방화벽의 로드밸런싱을 통해 가용성 및 성능 향상, 동적인 분산을 통해 응답속도 향상, 시스템 변경없이 방화벽 확장 및 관리가 용이한 장점이 있다.

중요한 점

FWLB를 사용하려면 무조건 두대의 L4스위치가 있어야 한다. 한 세션은 하나의 방화벽만을 거쳐가야 하기 때문에 세션 동기화를 위해 내부L4/외부L4이렇게 두대를무조건 구성한다.

VPNLB (VPN Load Balancing) & CSLB (Cache Server Load Balancing)

FWLB처럼 VPN 두 대에 대해 적절한 부하 분산 알고리즘(Load balancing Algorithm) 통해 전달하는 방식이다. FWLB랑 동일하다.

캐시 서버 로드밸런싱은 캐시를 주목적으로 하는 서버를 부하분산 하는 것으로 캐시 서버의 특성상 목적지 IP를 변경하지 않고 LB하는 것이 특징이다.

• 클라이언트에 별도의 설정이 필요 없다.
• Cache-server에 장애가 생겨도 변경 없이 서비스를 이용 가능하다.