쉽게 말해서 여러대의 컴퓨터가 있고, 이 여러대의 컴퓨터에 각각 작업을 분산시켜서 나눠주는 것을 의미합니다.
일반적으로 우리가 토이프로젝트를 할 때 사용하는 일반적인 WAS(Web Application Server)를 예로 들어봅시다. 먼저 보통 해당 인스턴스에 도메인이 연결되고, ip가 할당될 수 있습니다. 토이프로젝트에서는 문제가 없습니다.
그런데, 점점 사용자가 많아져서 우리의 인스턴스로는 정상적으로 응답을 줄 수 없는 상황이 왔습니다. 우리의 서버는 성능을 더 좋게 해야만 합니다. 두 가지 선택지가 있습니다. 서버의 자원을 늘리는 수직 확장, 비슷한 성능을 가진 서버를 여러 대 준비하는 수평 확장이 있습니다.
수직 확장 보다는 수평 확장을 통해 대응하는 것이 더 효과적입니다. 왜냐하면 서버의 크기를 늘리는 것은 물리적인 한계가 존재하기 때문입니다.
이 수평 확장을 적용하게 되면, 신경써야 할 부분이 수직 확장에 비해 많아지게 되는데 그 중 하나가 부하분산입니다. 여러 서버를 사용하면 엔드 포인트를 한 군데에 두고, 여러 서버들을 사용할 때 요청이 특정 서버에만 몰리지 않도록 골고루 처리하도록 하는 것입니다.
로드 밸런싱이 없다면 어떻게 될까요? 최악의 경우 특정 서버에는 요청이 몰리지만, 요청이 아예 없다시피 한 서버도 존재하게 될 것입니다. 그렇다면 우리가 굳이 수평확장을 선택한 이유가 없어져버립니다. 요청이 몰려서 생기는 장애를 방지하고자 분산환경을 구성했는데, 장애가 발생하게 되는 것이죠.
또 하나의 장점으로는 로드밸런서를 사용함으로써 안정성이 올라간다는 점입니다. 위의 사례를 들더라도 전체 사용자에게 서비스의 장애가 발생하진 않습니다. 특정 사용자군에 한해서만 장애가 발생할겁니다.
즉, 로드 밸런서를 사용하면 사용자 경험을 크게 개선할 수도 있고, 애플리케이션 안정성에도 크게 기여하게 됩니다.
Scale up (수직 확장) 과 Scale out (수평 확장)
로드 밸런서는 대부분 아래와 같은 방식으로 동작하게됩니다.
- 클라이언트의 브라우저에서 URL을 입력합니다.
- 해당 URL에 해당하는 IP를 알아냅니다.(DNS lookup) 이 IP는 로드 밸런서의 IP 주소입니다.(Virtual IP)
- 클라이언트에서 VIP 주소로 HTTP 요청을 보냅니다.
- 로드 밸런서는 요청을 로드 밸런싱 알고리즘에 따라 실제 서버에 요청을 전달합니다.
- 실제 서버의 HTTP 응답을 로드 밸런서가 클라이언트에게 전달해줍니다.
-
상세한 동작 방식
-
Bridge/Transparent Mode
사용자가 서비스를 요청하면 L4로 전달된 목적지 IP 주소를 real server IP 주소로 변조하고, MAC 주소를 변조해서 목적지를 찾아가는 방식입니다.
- 요청 전달 시 변조
- 사용자 > L4 > NAT(IP/MAC 주소 변조) > real server - 사용자가 L4를 호출하면 NAT가 중간에 목적지 IP 주소를 real server IP 주소로 변조하고 MAC 주소도 변조합니다.
- 응답 전달 시 변조
- real server > NAT > L4 > 사용자 - real server에서 L4를 거치면서 출발지(source) IP 주소를 L4 가상 IP 주소로 변조합니다. 동일 네트워크 대역이므로 MAC 주소는 변조하지 않습니다.
- 요청 전달 시 변조
-
Router Mode
Bridge/Transparent Mode와 유사하지만 출발지(source) MAC 주소도 변조됩니다.
-
One Arm Mode
사용자가 real server에 접근할 때 목적지 IP는 L4 스위치 IP를 바라봅니다. L4에 도달하면 L4가 클라이언트에게 받은 목적지 IP 주소를 L4 IP 주소에서 real server IP와 real server MAC 주소로 변조합니다. 되돌아가는 IP는 L4의 IP pool의 IP 주소로 변조됩니다.
-
DSR(Direct Server Return) Mode
사용자가 real server에 접근할 때 출발지와 목적지의 IP 주소를 변조하지 않고, L4에서 관리하는 real server의 MAC 주소 테이블을 확인해서 MAC 주소만 변조합니다.
L4(LoadBalancer) SLB 구성 방식 | ThinkGround
-
-
로드 밸런서의 기능
일반적인 로드밸런서는 서버들에게 주기적인 Health Check를 수행합니다. 이를 통해 서버들의 장애 여부를 판단할 수 있습니다. 이로 인해서 로드밸런서가 있는 경우 서버 몇 대가 장애가 발생하더라도 정상적으로 동작하는 서버로 트래픽을 보내주는 Fail-over가 가능하며, L4의 경우 TCP/UDP 분석이 가능하기 때문에 방화벽으로써의 역할도 수행할 수 있습니다.
-
L3 체크: ICMP를 이용하여 서버의 IP 주소가 통신 가능한 상태인지를 확인합니다.
-
ICMP(Internet Control Message Protocol)의 작동원리: 네트워크 상태를 확인하려는 대상(target) 컴퓨터에 일정 크기의 패킷을 보낸 후 대상 컴퓨터가 이에 대해 응답하는 메시지를 보내면 이를 수신, 분석하여 대상 컴퓨터가 작동하는지, 또는 대상 컴퓨터까지 도달하는 네트워크 상태가 어떤지 파악할 수 있습니다. ICMP는 ping 명령어로 동작하므로, 이 명령어를 지원하지 않는 기기(IP 주소를 갖지 않는 일부 스위치, 허브)에는 ping을 수행할 수 없고, 보안상의 이유로 ICMP를 차단한 기기 역시 ping 요청에 대응하지 않습니다.
-
-
L4 체크: TCP는 지난 시간 우리가 공부했던 three-way handshaking(SYN → SYN-ACK → ACK) 을 기반으로 통신합니다. 이러한 TCP의 특성을 바탕으로 포트의 상태를 체크합니다. 예를 들어, HTTP 웹 서버의 경우 80포트를 사용하기 때문에 TCP 80 포트에 Health Check를 수행해서 해당 웹 서버가 살아있는지 확인합니다.
-
L7 체크: 애플리케이션 계층에서 체크를 합니다. 즉, HTTP 통신을 직접 수행해서 이상 유무를 파악합니다.
[이해하기] 네트워크의 부하분산, 로드밸런싱 (Load Balancing) 그리고 로드밸런서 (Load Balancer) | STEVEN J. LEE
IP 터널링을 통한 가상 서버
눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념으로, 로드 밸런서는 클라이언트와 서버 중간에서 터널링을 제공해줍니다.
여기에 사용되는 기술은 IP 데이터 그램 내에 IP 데이터 그램을 캡슐화 해서 다른 IP 주소로 리디렉션을 하는 기술입니다.
이를 통하면, 클라이언트는 가상 IP를 통해 로드밸런서에 접근을 하고, 로드 밸런서는 이 패킷을 검사합니다.(대상 주소, 포트) 그리고 실제 서비스가 있다면 로드 밸런서는 실제 서버와 클라이언트 사이에 Tunnel을 형성합니다. 그리고 서버는 요청을 디캡슐합니다. 그 후 서버의 응답은 로드밸런서를 거치지 않고, 클라이언트에게 직접 전달됩니다.
Virtual Server via IP Tunneling
서버에서 클라이언트로 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음 네트워크 장비나 로드밸런서를 거치지 않고 바로 클라이언트를 찾아가는 방식입니다. 이 경우, 로드밸런서의 부하를 줄여줄 수 있는 장점이 있습니다.
IP 주소를 변환해주는 기능입니다. (목적지와 수신지의 ICP 주소와, TCP/UDP 포트를 재기록하여 변환하며 네트워크 트래픽을 주고 받을 수 있습니다.) 예를 들어, 내부 네트워크에서 사용하던 사설 IP 주소를 로드 밸런서 외부의 공인 IP 주소로 변경해줍니다.(반대로도 가능합니다.) 로드 밸런싱 관점에서는 여러개의 호스트가 하나의 공인 IP 주소를 통해 접속하는 것이 주 목적입니다.
- SNAT(Source Network Address Translation) 내부에서 외부로 트래픽이 나가는 경우, 내부 사설 IP 주소를 외부의 공인 IP 주소로 변환하는 방식입니다. 집에서 사용하는 공유기를 예로 들 수 있습니다.
- DNAT(Destination Network Address Translation) 외부에서 내부로 트래픽이 들어오는 경우, 외부 공인 IP 주소를 내부의 사설 IP 주소로 변환하는 방식입니다. 로드 밸런서는 보통 이 기능을 수행합니다.
[이해하기] 네트워크의 부하분산, 로드밸런싱 (Load Balancing) 그리고 로드밸런서 (Load Balancer) | STEVEN J. LEE
-
-
로드 밸런싱 알고리즘
알고리즘 문제풀이시 종종 등장하는 구간 합 알고리즘입니다.
대략의 원리는 미리 해당지점까지의 총합을 저장한 배열(SUM)이 있고, 구간(S, E)이 주어지면, SUM(E) - SUM(S - 1)이 구간의 합이 됩니다.
이는 매우 제한적인 상황에서 사용되는 알고리즘이고, 로드 밸런싱을 할 때도 마찬가지입니다.
각각의 작업은 독립적이어야 하고, 각각의 실행 시간과 작업을 세분화 할 수 있어야 합니다.
보통의 웹 서비스는 불규칙한 시간과 작업을 다루므로, 이 알고리즘이 있다는 것만 알아두고 넘어가도 무방할 것 같습니다.
가장 우리가 이해하기 쉬운 로드 밸런싱 알고리즘 입니다. (로드 밸런싱 이외에도 컴퓨팅의 여러 분야에서 두루두루 쓰이는 알고리즘입니다.)
서버를 순환하면서 요청을 분배해줍니다. 이 방법의 문제점이라면, 요청이 얼마나 걸리는지 신경쓰지 않고 순서대로 분배하기 때문에 한 서버에 부하가 많이 걸릴 수 있다는 점입니다.
알고리즘 자체는 매우 간단하기 때문에, 알고리즘 상으로는 가장 빠른 알고리즘입니다.
이 방법은 모든 애플리케이션 서버가 동일한 가용성, 컴퓨팅 및 처리 능력을 가지고 있다고 가정합니다.
가중 라운드 로빈은 각 서버에 가중치를 부여해서 특정 서버에 요청을 더 분배하고, 덜 분배하는 방식으로 동작합니다.
예를 들어서 서버 1의 가중치가 2고, 서버 2, 3의 가중치가 1이라면, 요청이 5개가 들어왔을 때, 1, 2 번 요청은 서버 1에 전달되고, 3, 4번 요청은 서버 2, 3에 전달되며, 5번 요청은 다시 서버 1로 전달됩니다.
라운드 로빈과 같은 문제점을 가지고 있지만, 서버 별로 성능상의 차이가 있을 경우 유용합니다.
요청을 무작위로 할당합니다. 무작위로 분배하기 때문에 요청이 많아질 경우 복잡한 로드 밸런싱 알고리즘 보다 빠른 성능을 보여줄 수도 있습니다.
흥미로운 자료를 발견해서 아래에 붙여두었습니다. 자세한 내용은 아래의 Nginx 항목을 보는 편이 더 이해가 잘 되실겁니다.
The power of two random choices
사용자가 지정한 가중치에 따라 확률적으로 무작위로 선택된 서버에 요청을 분배합니다.
해당 내용은 자료가 충분치 않아 판단 기준을 세우기 어렵다고 판단했습니다.
Weighted Random Load Balancing property
최소 연결 로드 밸런싱은 클라이언트가 요청을 했을 때, 가장 연결이 적은 서버에 클라이언트 요청을 분산하는 동적 로드 밸런싱 알고리즘입니다. 이 알고리즘은 서버가 많아질수록 최적의 서버를 찾는데 시간이 걸리기 때문에 더 느려집니다.
또한, 서버 1대가 추가로 투입될 경우 신규 서버로 요청이 몰리는 문제가 있게됩니다.
가중 최소 연결 알고리즘은 최소 연결 알고리즘을 기반으로하며 애플리케이션 서버간 성능차이가 발생하는 경우 유용할 수 있습니다. 서버에 가중치를 할당하여 좀 더 분배하고 덜 분배하는 식으로 동작합니다.
가장 빨리 응답하는 서버에게 요청을 분배합니다. 빠르게 응답하는 서버가 다음 요청을 수신합니다.
임의의 서버 두 개를 고르고 그 중에서 연결 수가 더 적은 서버를 선택합니다. 이는 위에서 설명한 최소 연결 알고리즘과 동일한 선택 기준을 갖습니다. 혹은 최소 시간 알고리즘을 사용해도 됩니다.
모든 서버를 확인하는 비용을 절약하고, 완전 무작위보다는 나은 결정을 하겠다라는 것이 그 아이디어입니다.
완전 랜덤보다 더 공정한 결과를 반환할 수 있습니다.
아래의 글은 편향적인 내용이 일부 포함될 수 있습니다. 벤치마크는 실제환경과 거리가 있을 수 있습니다.
Test Driving "Power of Two Random Choices" Load Balancing - HAProxy Technologies
열려있거나, 대기중인 커넥션을 적게 가지고 있는 서버에 요청을 분배합니다.
고정 가중치 방식은 우리가 선택한 기준에 따라 애플리케이션 서버에 가중치를 할당하여 서버 트래픽을 처리하는 로드 밸런싱 알고리즘으로, 가중치가 가장 높은 순서대로 요청을 모두 받고, 실패하면 그 다음 가중치를 가지는 애플리케이션 서버로 요청을 전달합니다.
소스 IP 해시
고유한 해시키를 생성하기 위해서 클라이언트 IP 주소를 해싱해서 해시 값을 생성하는 알고리즘입니다. 애플리케이션과 특정 서버가 긴밀하게 연결될 수 있으며, 세션이 끊어져도 이전에 사용하던 서버와 동일한 서버를 사용할 수 있습니다. 최근에는 모바일 환경이 대두되면서, 이런 방식이 주는 장점은 많이 퇴색되었다고 생각됩니다.
URL 해시
URL을 해싱해서 해시 값을 생성하는 알고리즘 입니다. 특정 요청에 대해서 특정 서버가 반응하게 할 수 있습니다.
마스터는 부하를 분산하는 역할을 담당하고, 워커는 자신의 상태를 마스터에게 보고합니다. 워커가 유휴상태 일 때, 마스터에게 작업을 요청하고, 마스터는 워커의 요청에 응답하고 작업을 분배합니다. 더 이상 분배할 일이 없는 경우 마스터는 워커에게 요청을 그만두라고 알립니다.
이 시스템의 장점은 공정하게 부하를 분산할 수 있다는 점이지만, 불필요하게 통신량이 많아져 많은 수의 서버에 적용하기엔 실질적으로 무리가 있습니다. 결국 서버가 많아질 경우 병목의 원인이 됩니다.
Load Balancing Algorithms and Techniques
NGINX and the "Power of Two Choices" Load-Balancing Algorithm - NGINX
-
로드 밸런서의 유형
하드웨어 로드 밸런서는 부하 분산을 제공하는 네트워크 전용 장비입니다.(L2,L3,L4 스위치, L7 스위치)
하드웨어 로드 밸런서는 말 그대로 부하 분산에 특화된 기기이기 때문에 가격이 비싸지만, 좋은 성능을 제공합니다.
-
하드웨어 기반 로드 밸런서 정리(정확히는 L4, L7만 로드 밸런서라고 부를 수 있습니다.)
Mac 주소를 가지고 스위칭 합니다.
다른 방식에 비해 장비의 가격이 저렴합니다.
IP, IPX 주소를 가지고 스위칭 합니다.
해당 프로토콜을 쓰는 패킷에 대한 스위칭이 가능합니다. L2에 비해 고성능 하드웨어여야 합니다.
라우터의 기능도 수행할 수 있습니다. (L2는 L3을 모르므로 불가능합니다.)
하지만 로드 밸런싱은 불가능합니다.
Port 넘버를 가지고 스위칭 합니다.
-
L4 부터 로드 밸런서라고 부르는 이유
왜 로드 밸런서로 부를 수 있냐면, 로드 밸런서의 기능 중에 헬스 체크가 있었습니다. 이 헬스 체크는 서비스가 제대로 동작하고 있는지 확인하기 위함이라고 했습니다. 그런데, 단순히
ping명령어에 응답한다고 정상적으로 서비스가 되고있다고 확신할 수 있을까요?물론 헬스 체크 없이 로드 밸런싱을 흉내낼 수는 있습니다. 하지만, 제대로 된 로드 밸런싱은 할 수 없습니다. 정상적으로 서비스가 되고 있지 않은데도 불구하고, 트래픽을 전달하기 때문입니다.
4계층 기반 로드 밸런싱을 지원하며, HA(고가용성)를 지원합니다. 포트 기반 필터링이 가능하고, 미러링, 로드 밸런싱이 가능합니다.
L2~L4 기반 보안 기능을 사용할 수 있습니다. L7 스위치에 비해 저렴한 가격입니다. 하지만 서비스의 존재 유무만 확인할 수 있으며, 컨텐츠 기반 제어는 불가능합니다.
L4 스위치는 해당 포트의 응답이 없을경우 서비스의 장애로, L7은 개별 서비스의 장애를 인지할 수 있다고 합니다.
또, 세션을 L4에서 관리하기 때문에 최대 세션 수가 존재하고, 세션을 맺는 시나리오에 따라 최대 성능이 다릅니다. 또 세션이 비정상 종료되는 경우, 세션이 그대로 남아있을 수 있어, L4의 한계 용량을 초과할 수도 있습니다.
Application 주소(컨텐츠)를 가지고 스위칭 합니다.
L4의 기능에 더해 컨텐츠 기반 로드 밸런싱, HA(고가용성)을 지원합니다.
컨텐츠 기반 필터링이 가능하므로, 좀 더 뛰어난 성능을 요구합니다.
하지만, 컨텐츠 단위로 패킷 분석이 가능하기 때문에 좀 더 성능이 좋아야 하는 서비스에 더 우선순위를 두어서 서비스의 품질을 높이는 QoS를 지원할 수 있습니다. 또한 데이터 분석이 가능해 보안적으로 좀 더 우수합니다.
하지만 모든 애플리케이션의 데이터를 다 다룰 수는 없고 특정 데이터만 다룰 수 있습니다.
- URL 스위칭 방식: URL 주소를 확인하여 부하분산, 특정 하위 URL 들은 특정 서버로 처리합니다.
- 쿠키 지속성(Persistence with Cookies): 쿠키 정보를 바탕으로 클라이언트가 연결 했었던 동일한 서버에 계속 할당해주는 방식입니다. 특히 사설 네트워크에 있던 클라이언트의 IP 주소가 공인 IP 주소로 치환되어 전송(X-Forwarded-For 헤더에 클라이언트 IP 주소를 별도 기록)하는 방식을 지원합니다.
- 컨텐츠 스위칭 방식(Contents Switching): 클라이언트가 요청한 특정 리소스에 대해 특정 서버 등으로 연결을 해줄 수 있습니다. 예를 들어, 이미지 파일에 대해서는 확장자를 참조하여 별도로 구성된 이미지 파일이 있는 서버/스토리지로 직접 연결해줄 수 있습니다.
L4 스위치와 L7 스위치 비교 > 도리의 디지털라이프
로드밸런서 (L4, L7, NginX, HAProxy)
LB(로드밸런싱) 기능이 있는 L3 스위치가 있나요??
스위치에 대해서 알아보면 허브라는 개념이 등장합니다. 허브는 무엇일까요?
허브와 스위치의 가장 큰 차이점은 각각의 포트에 연결된 컴퓨터나 네트워크 장비의 MAC 주소를 장비가 알고 있느냐 없느냐에 있습니다. 허브의 경우에는 단순한 중계기의 역할을 합니다. 허브는 모든 신호를 브로드 캐스팅합니다. (모든 신호를 모든 연결된 장비에게 전달합니다.)
만약 허브에 10M의 대역폭이 설정되어 있고, 연결된 장비가 5대라면 각 포트의 대역폭은 2M입니다.
허브는 신호간 충돌이 발생할 수 있기 때문에 반드시 한 쪽 신호가 지나간 후 반대편 신호가 지나갑니다.
스위치는 무엇일까요?
스위치는 내부에 메모리를 가지고 있어 각 포트에 연결되어 있는 컴퓨터들의 MAC 주소, IP 주소, Port 번호, 애플리케이션 주소 등이 여기에 기록되어 있고, 따라서 한 곳으로 요청을 전달할 수 있습니다.
또한 대역폭이 10M이라면 모두 10M의 속도를 보장받을 수 있습니다.
스위치는 각각의 독립적인 통로(버스)를 가지고 있기 떄문에 서로 충돌이 발생하지 않고, 다른 포트의 통신 유무에 관계없이 통신을 할 수 있습니다. 따라서 스위치가 허브에 비해서 더 비싸고, 성능이 더 우수합니다. 스위치의 가격이 많이 비쌌을 때에는 허브를 썼지만, 현재는 스위치를 많이 사용하는 추세입니다.
-
소프트웨어 기반 로드 밸런서는 직접 설치, 관리 및 구성하는 로드 밸런서 입니다.
하드웨어에 비해서 성능은 떨어지지만, 비용이 저렴하고, 소프트 웨어기 때문에 자동화가 가능하고, 신속하게 대응이 가능합니다.
최근에는 클라우드 환경이 대두되면서 클라우드 로드 밸런서가 그 역할을 대신하게 되었습니다.
최근 인프라의 추세는 온프레미스가 아닌 클라우드 환경입니다. 클라우드 환경에서는 IaaS로 직접 로드 밸런서를 구축하거나 PaaS로 제공되는 로드 밸런서를 사용하는 방법이 있습니다. 당연히 PaaS 쪽이 관리용이성이 뛰어납니다.
또한 하드웨어 기반의 비싼 비용을 지불하지 않고도 그에 비해 저렴한 가격으로 높은 성능을 기대할 수 있다는 것도 장점입니다. 또한 확장성도 뛰어납니다.
만약 클라우드 환경에서 인프라를 운영하고 있다면 당연히 클라우드 PaaS 기반 로드 밸런서를 이용하는 것이 합리적인 선택이라고 생각됩니다.
해당 내용은 아래의 글을 참고하시면 좋을 것 같습니다. (전반적인 내용을 다 다루지는 않습니다.)
-
L4/L7 로드 밸런서의 성능을 가늠할 수 있는 주요한 지표들은 다음과 같습니다.
-
초당 연결 수 (Connections per second) 최대 처리 가능한 초당 TCP 세션의 개수
-
동시 연결 수 (Concurrent Connections) 동시에 최대로 세션을 유지할 수 있는 개수
-
처리 용량(Throughput) (패킷 자체에 대해 연결이 성립되는) UDP 프로토콜에 대한 로드 밸런싱 성능 지표. FWLB에서 중요합니다. 단위는 bps(bit per second) 또는 pps(packet per second)를 사용합니다.
-
FWLB(Firewall Load Balancing)
방화벽과 같은 보안 장비들은 내부와 외부 네트워크의 경계에 있는 중요한 장비들이고, 부하가 증가된다면 병목이 될 가능성이 높습니다. 따라서 이를 방지하기 위해서 이중화를 합니다.
보안 장비의 주 기능은 3, 4계층 헤더와 7계층 데이터를 기준으로 한 필터링, 로깅, 모니터링 입니다.
보안 장비는 보안 기능과 함께 통신 기능도 제공해야 합니다.모드는 Transparent Mode, Router Mode로 설정할 수 있습니다.
장비 이중화는 백업과 로드 밸런싱으로 나눌 수 있는데, 백업은 Active-Standby 형태고, 로드 밸런싱은 Active-Active 형태입니다.
-
-
임계치(Threshold) 내부 알고리즘 혹은 처리 방식에 따라서 임계치는 각각 다르게 설정할 수 있습니다.
로드 밸런서도 당연히 장애가 발생할 수 있습니다. 따라서 이중화 구성으로 결함 내성(fault tolerance)을 높여야 합니다.
시나리오는 다음과 같습니다.
- 로드 밸런서는 서로 헬스 체크를 합니다.
- VIP로 Active 된 로드 밸런서에 연결합니다.
- 로드 밸런서에 장애가 발생한 경우, 대기중인 로드 밸런서로 연결합니다.
둘의 공통점은 클라이언트와 서버 간의 통신에서 중개자 역할을 해서 효율성을 향상시키는 역할을 합니다.
로드 밸런서에는 이 글에서 충분히 다루었으니, 리버스 프록시에 대해서 알아봅시다.
리버스 프록시는 서버가 한 대만 있는 경우에도 유의미할 수 있습니다. 리버스 프록시가 공개적인 부분을 담당하고, 특정 애플리케이션의 백엔드를 숨기는 역할을 해줄 수 있습니다.
What is a Reverse Proxy vs. Load Balancer? - NGINX
20200726 [web] Reverse Proxy vs Web Server 에 대한 구조도 그려보기.
[DevOps] Reverse Proxy vs Load Balancer, 리버스 프록시 vs 로드 벨런서
클러스터링의 클러스터란 여러 개의 컴퓨터를 연결해서 하나의 컴퓨터처럼 사용하는 병렬 시스템입니다.
클러스터는 공통 목표를 달성하려고 한다는 점이 있고, 서로의 정보와 상태를 동기화합니다. 일반적으로는 로드 밸런싱이 클러스터에 적용되는 것이 일반적입니다.
반면 로드 밸런서는 독립 서버에 적용될 수 있고, 클러스터링 없이도 적용될 수 있습니다. 또한 독립적이므로 서로의 리소스에 관심이 없을 수 있습니다.
결국 둘을 비교한다는 것은, 어떤 것이 아키텍처를 구성할 때 적절한가? 라는 질문과 같다고 생각합니다.
클러스터링은 상태를 공유하고 로드 밸런싱은 상태를 공유할 필요가 없다는 점에 주목해봅시다.
만약 사용자가 서버에서 하던 작업이 있고 서버가 비정상 종료된 경우 클러스터링은 사용자의 작업을 그대로 이어서 할 수 있으며, 로드 밸런싱은 그대로 이어서 할 수도 있고 아닐 수도 있습니다.(상태를 공유할 수도 있고, 하지 않을 수도 있기 때문이고, 일반적으로 상태는 공유되지 않습니다. 이 경우 사용자는 작업에 실패하게됩니다.)
참고로 클러스터링은 구성하기 까다롭다는 단점이 있습니다. 😱
Clustering vs. Load Balancing - What is the difference?
우리가 지금까지 얘기한 로드 밸런싱은 SLB(Server Load Balancing)을 의미했습니다.
이와는 별개로 GSLB(Global Server Load Balancing)가 있습니다. 사실 GSLB는 로드 밸런싱이라는 이름이 들어갈 뿐, 우리가 다룬 SLB보다는 DNS와 더 밀접한 연관이 있습니다.
GSLB는 DNS를 기반으로 로드밸런싱을 하는 방법입니다. 예를 들어, 같은 동작을 하고 같은 서비스를 제공하는 서버들이 같은 네트워크 혹은 같은 지역 내에 배치되어 있지 않고 여러 지역에 분산되어 운용될 때 이용하는 방식입니다. DNS와의 차이점은, GSLB는 아래의 요소들을 고려하여 연결 대상 서버를 선택하기 때문에 지능형 DNS라고도 이해할 수 있습니다.
-
재해 복구(Disaster Recovery)
GSLB는 가용한 서버들에만 클라이언트의 요청을 전달합니다. DNS는 죽은 서버에도 요청을 전달합니다.
-
지역 로드 밸런싱
GSLB는 부하가 적은 서버로 클라이언트의 요청을 전달합니다. DNS는 과부하 서버에도 요청을 전달합니다.
-
네트워크 지연 시간
GSLB는 네트워크 상황을 고려하여 클라이언트의 요청을 전달합니다. DNS는 고려하지 않고 요청을 전달합니다.
-
지리적 위치
GLSB는 서버의 지리적 위치를 고려합니다. DNS는 서버의 지리적 위치를 고려하지 않습니다.
Enterprise를 위한 GSLB(Global Server Load Balancing) - 1편: 개념 및 서비스 로직