로드 밸런싱_시스템 설계 노트 5

영.수평 확장부터 시작하다

단일 머신에서複数 머신으로 확장할 때, 처음 직면하는 문제는 이러한 머신들이 어떻게 협력하여 작업하는가, 즉어떻게 리퀘스트를 스케줄링하는가입니다:

[caption id="attachment_2103" align="alignnone" width="625"] load balancer dispatcher[/caption]

P.S. 수평 확장과 수직 확장에 대한 상세 정보는, Scalability_시스템 설계 노트 1 참조

일.로드 밸런서

여러 서버 하에서의 리퀘스트 스케줄링 메커니즘을 로드 밸런싱 (Load balancing) 이라 하며, 스케줄러 (Dispatcher) 는 로드 밸런서 (Load balancer) 입니다:

그 주요 역할은기정 전�� (랜덤, 라운드 로빈 등) 에 따라 클라이언트 리퀘스트를 각 서버에 배분하는 것입니다:

The fundamental feature of a load balancer is to be able to distribute incoming requests over a number of backend servers in the cluster according to a scheduling algorithm.

다음에 도움이 됩니다:

리퀘스트가 사용 불가능한 서버에 도달하는 것을 방지
리소스 과부하 방지
단일 장애점 제거, 가용성 향상

또한 다음에도 사용할 수 있습니다:

SSL termination:SSL 연결 처리, 암호화/복호화 작업을 스케줄링 층에 전치
세션 유지 (Session persistence):세션을 집중 처리, 서버 전환으로 인한 세션 상태 손실 회피

즉, 다중 머신 장면에서는 반드시 리퀘스트 배분/스케줄링을 담당하는 로드 밸런서가 필요합니다. 그렇다면, 다음 문제는로드 밸런싱 메커니즘을 어느 계층에서 구현해야 하는가입니다

이.구현 사로

HTTP 리퀘스트가 클라이언트에서 서버로의 통신 프로세스를 고려하면, 간단히 3 개 단계로 나눌 수 있습니다:

출발:클라이언트가 리퀘스트 발송
도중:리퀘스트가 네트워크 전송 경유
도착:서버가 리퀘스트 수신

리퀘스트의 배분/스케줄링이란, (기정 전략에 따라) 리퀘스트의 목적지를 변경하는 방법을 생각하는 것 입니다. 따라서, 적어도 3 가지 사로가 있습니다:

출발 전:리퀘스트가 네트워크 전송되기 전에, 최종 목적지를 결정. 예:DNS 로드 밸런싱, 클라이언트 측 로드 밸런싱
전송 중:네트워크 전송의 몇몇环节에서 목적지 변경. 예:4 계층 로드 밸런싱
도착 후:리퀘스트가 서버에 도착한 후, 이차 배분. 예:7 계층 로드 밸런싱

삼.DNS 로드 밸런싱

클라이언트가 서버에 리퀘스트를 개시하려면, 먼저 서버의 IP 주소를 알아야 하며, DNS 를 통해 조회합니다:

DNS 는 도메인 이름과 IP 주소 간의 매핑 관계를 유지하므로, 여기서 로드 밸런싱 전략을 구현하여 리퀘스트를 타겟 서버 (의 IP 주소) 로 향하게 할 수 있습니다. 예를 들어:

라운드 로빈 배분:일련의 A 레코드를 추가하여, 동일 도메인 이름을 여러 다른 IP 주소로 향하게 함.round-robin DNS 라 함
랜덤 배분:다치 응답 라우팅 전략 을 지원하는 DNS 서비스 채택

간단하고 사용하기 쉽지만, 결함도 명확 합니다:

신뢰성 보장 안 됨:DNS 는 서버의 가용성을 체크하지 않음. 타겟 서버가 다운되거나 접근 불가능해져도, 그 IP 주소를 반환
업데이트 시기적절하지 않음:DNS 의 해석 결과는 종종层层에 캐시되며, 레코드 업데이트가 즉시生效하지 않음

P.S. DNS 로드 밸런싱에 대한 상세 정보는, What Is DNS Load Balancing? 참조

사.클라이언트 측 로드 밸런싱

마찬가지로, 서버 IP 주소 선택 메커니즘을 클라이언트 측에서 구현하는 것을, 클라이언트 측 로드 밸런싱이라 합니다

클라이언트가 스스로 타겟 서버의 IP 주소를 선택 (DNS 조회를 통하지 않음):

[caption id="attachment_2105" align="alignnone" width="445"] client-side load balancing[/caption]

예를 들어, 클라이언트에 서버 IP 리스트를 제공하고, 클라이언트가 리퀘스트 개시 전에 랜덤으로 하나의 IP 를 선택하면, 랜덤 배분의 목적을 달성할 수 있습니다

DNS 로드 밸런싱과 비교하여, 클라이언트 측에는 캐시 문제가 없으며, 더욱 정교한 제어가 가능 합니다. 예를 들어 서비스 가용성을 체크하고, 그 중에서 사용 가능한 IP 주소를 선택할 수 있습니다

오.OSI 7 계층 모델

리퀘스트가 클라이언트에서 발송된 후, 네트워크를 통해 전송됩니다

OSI(Open System Interconnect) 참조 모델 은 네트워크 통신을 7 개의 추상 계층으로 나눕니다:

아래에서 위로, 순서대로:

물리 계층 (제 1 계층):물리 매체를 통해 원시 비트스트림, 즉 물리 신호 (Symbol) 전송
데이터 링크 계층 (제 2 계층):신뢰할 수 있는 노드 간 데이터 프레임 (Frame) 전송 메커니즘 제공. 구체적 작업에는 MAC 주소 지정 포함
네트워크 계층 (제 3 계층):데이터 패킷 (Packet) 전송이 채택할 물리 경로 결정.IP, ARP 등 프로토콜 지원. 구체적 작업에는 IP 주소 지정, 라우팅, 플로우 제어 포함
전송 계층 (제 4 계층):신뢰할 수 있는报文 (Datagram) 전송 메커니즘 제공.TCP, UDP 등 전송 프로토콜 지원. 구체적 작업에는
세션 계층 (제 5 계층):세션 관리 담당.여러 차례 전송을 통한 연속적 정보 교환 지원
프레젠테이션 계층 (제 6 계층):네트워크 서비스からの 데이터를 애플리케이션 계층에서 사용 가능한 형식으로 번역.구체적 작업에는 문자 인코딩 변환, 데이터 압축, 암호화/복호화 등 포함
애플리케이션 계층 (제 7 계층):고급 API 의 인간 - 기계 인터랙션 층 제공.애플리케이션은 이 층을 통해 네트워크 서비스에 액세스 가능.리소스 공유, 원격 파일 액세스 등

그 중, 제 1 계층은 원시 데이터, 제 2 계층은 타겟 머신의 MAC 주소를 결정, 제 3 계층은 종점의 IP 주소, 및 경유하는 구체적 경로를 결정.제 4 계층까지 도달하면, 전송 프로토콜에 따라 타겟 포트 번호를 결정.제 5~7 계층은 종점을 신경 쓰지 않음.IP 주소 + MAC 주소 + 포트 번호가 이미 타겟 애플리케이션을 유일하게 결정했기 때문

즉, HTTP 리퀘스트는 이러한 계층들을 경유해야만 타겟 서버에 도달할 수 있습니다. 따라서, 이론상, 제 2~7 계층中的任意 한 계층에서 종점을 변경하고, 로드 밸런싱을 구현할 기회가 있습니다

일반적인 로드 밸런싱 메커니즘이 주로 제 4 계층과 제 7 계층에서 구현되는 것은, 왜일까요?

육.2 계층, 3 계층 로드 밸런싱

2 계층 로드 밸런싱:송신원/목적지 MAC 주소에 따라 배분.예:가상 MAC 주소를 기정 전략에 따라 실제 MAC 주소로 매핑
3 계층 로드 밸런싱:송신원/목적지 IP 주소, 및 제 2 계층 정보에 따라 배분.예:가상 IP(Virtual IP address) 해석

底层에 가까울수록, 배분 결정에 사용할 수 있는 정보가 적어집니다. 따라서 2 계층 로드 밸런싱의 실제 용도는 제한적이며, 일반적인 것은 중복 게이트웨이 프로토콜 (GLBP, VRRP 등) 과 링크 어그리게이션 (Link aggregation, etherchannel 라고도 함) 등.상세는 How is load balancing achieved with layer 2 devices? 참조

칠.4 계층 로드 밸런싱

4 계층 로드 밸런싱은 전송 계층 (제 4 계층) ��보를 기반으로 리퀘스트를 배분.송신원/목적지 IP 주소, 및 데이터 패킷 헤더의 포트 번호 포함.단 데이터 패킷 내용은 고려하지 않음:

Layer 4 load balancing uses information defined at the networking transport layer (Layer 4) as the basis for deciding how to distribute client requests across a group of servers. For Internet traffic specifically, a Layer 4 load balancer bases the load-balancing decision on the source and destination IP addresses and ports recorded in the packet header, without considering the contents of the packet.

클라이언트는 로드 밸런서의 IP 주소를 목적지 IP 주소로 하여 리퀘스트를 개시.4 계층 로드 밸런서는 리퀘스트 수신 후, 데이터 패킷에 NAT 변환을 실행.목적지 IP 주소를 실제 서버의 주소로 변경.서버 응답을 클라이언트에 전송하기 전에, 로드 밸런서는 송신원 IP 주소를 자신의 IP 주소로 변경.비슷하게, 데이터 패킷 내의 송신원/목적지 포트 번호도 이 방식으로 변경

P.S. 제 4 계층 로드 밸런서는 일반적으로 전용 하드웨어 장치.NAT 조작은 전용 칩에 의해 완료될 수 있음

더 복잡한 7 계층 로드 밸런싱과 비교하여, 4 계층 로드 밸런싱에 필요한 계산은 적음.그러나 현재 하드웨어 조건 하에서는, 이로 인한 성능 우위는 이미 중요하지 않음

P.S.엄밀히 말하면, 4 계층 로드 밸런싱은 3/4 계층 로드 밸런싱이라 불러야 함.제 3 계층의 IP 주소와 제 4 계층의 포트 번호 정보를 결합했기 때문

팔.7 계층 로드 밸런싱

7 계층 로드 밸런싱은애플리케이션 계층 프로토콜 정보 (HTTP 헤더 등) 및 데이터 패킷 내용 정보를 기반으로 배분.URL, 데이터 타입, Cookie 정보 등 포함:

Layer 7 load balancers base their routing decisions on various characteristics of the HTTP header and on the actual contents of the message, such as the URL, the type of data (text, video, graphics), or information in a cookie.

4 계층 로드 밸런싱과 비교하여, 7 계층 로드 밸런싱은 리퀘스트와 응답 내용을 읽을 수 있음.필요한 계산은 많지만, 반드시 4 계층 로드 밸런싱보다 성능이 나쁜 것은 아님.보다 포괄적인 컨텍스트 정보를 소유하고 있으므로, 이를 기반으로 더욱 현명한 글로벌 결정을 내릴 수 있음(저속 연결 제거, 타임아웃 리퀘스트 리다이렉트 등).게다가 내용의 최적화 (압축 등) 도 가능.从而 성능 향상

P.S.엄밀히 말하면, 7 계층 로드 밸런싱은 5~7 계층 로드 밸런싱이라 불러야 함.OSI 모델의 5~7 계층의 관련 정보를 결합했기 때문:

[caption id="attachment_2110" align="alignnone" width="800"] TCP/IP model and OSI model[/caption]