로드 밸런서

이 글은 고재성, 이상훈 저 - "IT 엔지니어를 위한 네트워크 입문"를 공부하고 정리하여 작성하였습니다.

 

 

1. 부하 분산

• 로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 들어옴
• 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 서비스 요청을 분산
• 로드 밸런서에는 서비스를 위한 가상 IP(VIP)를 하나 제공하고 사용자는 동일한 가상 IP를 통해 각 서버로 접근
• 이 외에도 로드 밸런서는 각 서버의 상태를 체크해 서비스가 가능한 서버로만 사용자 요청 분산

FWLB(FireWall Load Balancing)

• 방화벽을 액티브-액티브로 구성하기 위해 로드 밸런서를 사용하기도 함
• 출발지-목적지 간 경로가 두 개 이상인 비대칭 경로의 경우, 비대칭 동작에 의해 방화벽이 정상적으로 동작하지 않는 문제가 발생
• 이러한 문제를 해결하고 동시에 이중화된 방화벽을 모두 사용하기 위해 사용됨.
• 세션을 인식하고 일정한 규칙을 이용하여 방화벽 세션을 분산
  • 한 번 방화벽을 지나갔던 세션이 다시 같은 방화벽을 거치도록 트래픽 분산
• FWLB를 사용하더라도 방화벽에 장애가 발생하는 경우를 대비하여 방화벽에서 설정이 필요함

 

2. 부하 분산 방법

• 가상 IP(Virtual IP): 서비스를 위해 사용되는 IP주소이므로 서비스 IP 주소라고도 함
• 리얼 IP(Real IP): 각 서버의 실제 IP 주소
• 로드 밸런서에 의해 가상 IP에 실제 서버들이 바인딩됨.
• 로드밸런서에서는 부하 분산을 위한 그룹을 설정할 때 IP 주소(3계층)뿐만 아니라 서비스 포트(4계층)까지 지정해 만듦
• 그리고 VIP 설정된 서비스 포트와 실제 서버 서비스 포트를 다르게 설정할 수 있음

 

3. 헬스 체크

3.1. 헬스 체크 방식

1. ICMP
   • 단순히 서버가 살아 있는지 여부만 체크하는 방법으로 잘 사용하지 않음
2. TCP 서버 포트
   • 로드 밸런서에 설정된 서버의 서비스 포트를 확인하는 방법
   • 등록된 서비스 포트로 SYN → SYN,ACK → ACK로 응답, FIN을 보내 헬스체크 종료
3. TCP 서비스 포트: Half Open
   • 헬스 체크로 인한 부하를 줄이거나 정상적인 종료 방식보다 빨리 헬스체크 세션을 끊기 위해 사용
   • SYN → SYN, ACK → RST로 마무리
4. HTTP 상태 코드
   • 서비스 포트까지는 TCP로 정상적으로 열리지만 웹 서비스에 대한 응답이 정상적이지 않은 경우 사용
   • 3방향 핸드셰이크를 거치고나서 HTTP를 요청해 정상상태 코드(200 OK)를 응답하는 지 확인
5. 콘텐츠 확인(문자열 확인)
   • 서버로 콘텐츠를 요청하고 응답받은 내용에 지정된 콘텐츠가 정상적으로 응답하는 지 여부 확인
   • 로드 밸런서에서 직접 관리하는 서버가 아닌 해당 서버의 백엔드의 상태를 해당 웹페이지로 체크 가능
   • 비정상적인 응답이라도 응답 내용에 확인하려는 문자열이 포함된 경우, 정상으로 판단
   • 그래서 정상 코드 값도 확인하거나 특정 문자열을 지정해서 확인해야 함

3방향 vs 4방향 연결 종료(Close)

• 4방향 핸드셰이크로 연결을 종료했지만 경우에 따라 3방향 핸드셰이크로 연결을 종료하기도 함.

 

3.2. 헬스 체크 주기와 타이머

• 주기(interval): 로드 밸런서에서 서버로 헬스 체크 패킷을 보내는 주기
• 응답 시간: 로드 밸런서에서 서버로 헬스 체크 패킷을 보내고 응답 시간을 기다리는 시간
• 시도 횟수(Retries): 로드 밸런서에서 헬스 체크 실패 시 최대 시도 횟수
• 타임아웃(Timeout): 로드 밸런서에서 헬스 체크 실패 시 최대 대기 시간
• 서비스 다운 시의 주기(Dead Interval)
  • 서비스의 기본적인 헬스 체크 주기가 아닌 서비스 다운 시의 헬스 체크 주기
  • 서비스가 죽은 상태에서 헬스 체크 주기를 별도로 더 늘릴 때 사용

• 응답시간 내에 응답이 오지 않으면 실패 처리
• 주기 > 응답시간

 

4. 부하 분산 알고리즘

부하분산 알고리즘
라운드 로빈	현재 구성된 장비에서 부하를 순차적으로 분산함. 총 누적 세션 수는 동일하지만 활성화된 세션 수는 달라질 수 있음
최소 접속 방식	현재 구성된 장비 중 가장 활성화된 세션 수가 적은 장비로 부하를 분산함.
가중치 기반 라운드 로빈	라운드 로빈 방식과 동일하지만 각 장비에 가중치를 두어 가중치가 높은 장비에 부하를 더 많이 분산함. 처리 용량이 다른 서버에 부하를 분산하기 위한 분산 알고리즘
가중치 기반 최소 접속 방식	최소 접속 방식과 동일하지만 각 장비에 가중치를 부여해 가중치가 높은 장비에 부하를 더 많이 분산함. 처리 용량이 다른 서버에 부하를 분산하기 위한 분산 알고리즘
해시	해시 알고리즘을 이용한 부하 분산

4.1. 라운드 로빈

• 특별한 규칙 없이 현재 구성된 장비에 순차적으로 돌아가면서 트래픽을 분산함.
• 순차적으로 모든 장비에 분산하여 모든 장비의 총 누적 세션은 동일

4.2. 최소 접속 방식

• 서버가 가진 세션 부하를 확인해 그것에 맞게 부하를 분산하는 방식
• 로드 밸런서에서는 서비스 요청을 각 장비로 보내줄 때마다 세션 테이블이 생성
• 각 장비에 연결된 현재 세션 수를 파악하여 가장 적에 연결된 장비로 서비스 요청을 보냄

4.3. 해시

• 서버 부하 상태를 고려하지 않고 클라이언트가 같은 서버에 지속적인 접속을 위해 사용
• 해시 알고리즘을 통해 얻은 값으로 어떤 장비에 부하를 분산할지를 결정
• 알고리즘에는 주로 출발지 IP주소, 목적지 IP주소, 출발지 서비스 포트, 목적지 서비스 포트를 사용
• 장점
  • 라운드 로빈이나 최소 접속 방식은 동일한 출발지에서 로드 밸런서를 거친 서비스 요청이 다른 서버에 분산되어 각 서버에서 세션을 유지해야 하는 경우 문제가 생김
  • 알고리즘으로 계산한 값으로 결정되므로 항상 동일한 장비로 서비스가 분산됨
  • 세션을 유지해야 하는 서비스에 적합한 방식
• 단점
  • 결과값이 특정한 값으로 치우치면 분산 비율이 치우칠 수 있음
• 해시와 최소 접속 방식의 장점을 결한한 분산 방법도 있음
• 라운드 로빈이나 최소 접속 방식을 사용하면서 **스티커(sticker)**를 주어 한 번 접속한 커넥션을 유지하는 방법
• 처음 들어온 서비스 요청을 세션 테이블에 두고 같은 요청이 들어오면 같은 장비로 분산해 세션을 유지해 주는 기법
• 그럼에도 세션 테이블은 타임아웃이 있어 타임아웃 이후에는 해당 기법이 유효하지 않을 수 있음

 

5. 로드 밸런서 구성 방식

• 로드 밸런서의 구성 위치에 따라 2가지로 나뉨

1. 원암(One-Arm) 구성
   1. 로드 밸런서가 중간 스위치 옆에 연결되는 구성
   2. 부하 분산을 수행하는 트래픽에 대해서만 로드 밸런서를 경유함
2. 인라인(Inline) 구성
   1. 서버로 가는 경로 상에 로드 밸런서가 연결되는 구성
   2. 부하 분산을 포함한 모든 트래픽이 로드 밸런서를 경유함

5.1. 원암 구성

• 로드 밸런서가 스위치와 인터페이스 하나로 연결되어 있음
• 서버로 들어가거나 나오는 트래픽이 로드 밸런서를 경유하지 않을 수도 있음
• 불필요한 트래픽이 로드 밸런서를 경유하지 않아 로드 밸런서 부하를 줄일 수 있음
• 스위치 - 로드 밸런서 간의 대역폭을 최소화할 수 있고 대역폭이 부족한 경우 해당 구간만 증설하면 되기 때문에 확장에 유리함.
• 로드 밸런서의 부하 감소 뿐만 아니라 장애 영향도를 줄이기 위해 사용
• 부하 분산을 이용
  • 부하 분산에 사용되는 서비스 IP 정보를 로드 밸런서가 갖고 있어 서버로 유입되는 트래픽은 먼저 로드 밸런서를 거침
  • 로드 밸런서에서는 각 실제 서버로 트래픽을 분산하고 서버의 응답 트래픽은 다시 로드 밸런서를 거쳐 사용자에게 응답
• 서버의 응답 트래픽이 로드 밸런서를 다시 거치려면 서비스 IP에 대해 실제 서버로 Destination NAT와 로드 밸런서가 가진 Source NAT도 함께 이루어짐
• Source NAT를 하지 않는 경우, DSR(Direct Server Return)을 사용함

원암 구성에서의 대역폭

• 로드 밸런서가 처리하는 용량이 줄어듦
• 인터페이스에서 인바운드/아웃바운드 트래픽 모두 수용해야 하므로 로드 밸런서-스위치 간 인터페이스 대역폭을 산정해야 함.

5.2. 인라인 구성

• 로드 밸런서의 서비스를 받는지 여부 관계없이 모두 로드 밸런서를 통과함
• 구성이 직관적이고 이해하기 쉬움
• 4계층 이상의 데이터를 처리하는 로드 밸런서는 용량이 L3 장비보다 적으며 처리 용량이 커지면 가격이 널뛰기 때문에 로드 밸런서 부하에 따른 성능을 고려해야 함

물리적 원암, 논리적 인라인

• 물리적으로는 원암이어도 실제로는 인라인 구성인 경우도 있음
• 로드 밸런서와 연결된 스위치 상에서 VRF와 같은 가상화를통해 논리적으로 분리한 경우 나타남
• 이런 경우는 물리적 구성이 아닌 논리적 구성도로 이해하여 인라인 구성이 됨.

 

6. 로드 밸런서 동작 모드

6.1. 트랜스패런트 모드

• 트랜스패런트(transparent: 투명) 구성은 로드 밸런서가 OSI 2계층 스위치처럼 동작하는 구성
• 로드 밸런서에서 서비스하기 위해 사용하는 VIP 주소와 실제 서버가 동일한 네트워크를 사용하는 구성
• 기존에 사용하던 네트워크 대역을 그대로 사용하여 네트워크 재설계가 필요 없음
• 기존 망의 트래픽 흐름에 미치는 영향 없이 로드 밸런서를 쉽게 구성할 수 있음
• 트랜스패런트 구성에서는 트래픽이 로드 밸런서를 지나가도
  • 부하 분산 서비스를 받는 트래픽인 경우만 4계층 이상의 기능을 수행
  • 받지 않는 경우 기존 L2 스위치와 동일한 스위칭 기능 수행, 그래서 L2 구조라 부르기도 함
• 원암 구성과 인라인 구성 모두 사용할 수 있는 동작 모드
• 요청

• 1. 로드 밸런서로 들어온 패킷은 목적지 ip 주소를 vip에 바인딩되어 있는 실제 ip주소로 변경
     1. 목적지 IP 주소 10.10 → 10.11, 목적지 MAC 주소 B → C
     2. 로드 밸런서와 목적지 서버가 동일한 네트워크 대역이므로 L3 장비를 지날때처럼 출발지 MAC 주소가 변경되진 않음
  2. 서비스 요청 패킷의 목적지 정보가 변경되면 실제 서버로 패킷이 전달됨.
     1. 로드 밸런서에서 서비스를 위한 VIP 주소가 실제 서버의 IP 주소로 변경해 전송하므로 목적지 NAT가 되었다고 함
• 응답

1. 로드 밸런서를 지나면서 요청할 때와 반대로 출발지의 IP 주소가 실제 서버 IP에서 VIP로 변경됨
2. 하지만 이미 게이트웨이의 MAC 주소를 갖고 있어 목적지 MAC 주소는 변경되지 않음

• 로드 밸런서가 트랜스패런트 모드에서 동작할 때, 게이트웨이 외부 사용자로부터 받은 서비스 요청을 처리하는 데는 문제가 없음
• 하지만 동일 네트워크에서 서비스를 호출할 때는 서비스 응답이 로드 밸런서를 거치지 않을 수 있음

6.2. 라우티드 모드

• 로드 밸런서가 라우팅 역할을 수행하는 모드
• 로드 밸런서를 기준으로 사용자 방향과 서버 방향이 서로 다른 네트워크로 분리된 구성
• 인라인 구성과 원암 구성에서 모두 가능함.
• 보안 강화 목적으로 서버쪽 네트워크를 사설로 구성하여 서버에 직접 접속하는 것을 막기 위한 용도로 사용
• 요청
  1. 사용자는 서비스 IP인 VIP 주소 10.10으로 서비스를 요청
  2. 로드 밸런서로 들어온 패킷은 목적지 IP 주소를 VIP에 바인딩된 실제 서버 IP 주소인 20.11로 변경함
     1. 라우팅을 수행하면서 로드 밸런서를 통과하므로 일반 라우팅과 동일하게 출발지 MAC 주소: A → D,목적지 MAC 주소: B → C
  3. 목적지 IP와 출발지/목적지 MAC이 변경된 패킷은 라우팅 테이블을 확인해 실제 서버로 전송
     1. 로드 밸런서는 서비스를 위한 VIP 주소에서 실제 서버의 IP 주소로 변경해 전송하므로 목적지 NAT가 되었다고 함
• 응답

1. 목적지 IP가 외부 네트워크이므로 목적지 MAC은 외부로 나가는 관문인 로드 밸런서의 MAC 주소가 됨
2. 로드 밸런서로 들어온 패킷은 출발지 IP 주소를 실제 서버의 IP인 20.11에서 사용자가 서비스를 위해 요청했던 VIP인 10.10으로 변환
3. 요청 트래픽과 마찬가지로 출발지와 목적지의 MAC 주소를 변경한 후 사용자에게 응답 패킷을 전송

6.3. DSR 모드

• 사용자의 요청이 로드 밸런서를 통해 서버로 유입된 후에 다시 로드 밸런서를 통하지 않고 서버가 사용자에게 직접 응답하는 모드
• 응답 트래픽이 유입되지 않으므로 사용자가 요청하는 패킷에 대해서만 관여
• 로드 밸런서를 경유하지 않으므로 원암 구성에서만 사용
• 실제 서버의 네트워크를 로드 밸런서가 가지는 지 여부에 따라 L2 DSR과 L3 DSR으로 구분됨
• 로드 밸런서 전체 트래픽이 감소해 로드 밸런서 부하가 감소함.
• 반면, DSR 모드의 서비스 응답이 로드 밸런서를 경유하지 않으므로 문제 발생시, 확인이 어려움
• L2 DSR과 L3 DSR의 경우는 로드 밸런서 설정 외에 서버에서도 추가 설정 필요
• 트래픽 흐름
  • 사용자는 서비스 IP인 VIP로 서비스를 요청
  • 로드 밸런서로 들어온 서비스 요청 패킷은 서버에서 로드밸런서를 거치지 않고 응답하기 때문에 로드 밸런서를 통한 Source NAT를 수행할 수 없음
  • 사용자 입장에서는 실제 서버 IP로 응답을 받게 되고 요청했던 주소 IP와 다르기 때문에 비정상적인 응답으로 간주
  • 그래서 서비스 요청 시 목적지 IP는 VIP 그대로 유지하고, MAC 주소만 실제 서버 MAC 주소로 변경
  • 서버에서 수신할 때, 목적지 IP 주소가 서버 주소와 맞지 않으면 폐기되므로 루프백 인터페이스를 생성해 VIP 주소를 할당
  • 루프백에 설정된 IP 주소도 수신할 수 있도록 설정함

 

7. 로드 밸런서 유의 사항

7.1. 원암 구성의 동일 네트워크 사용 시

• 사용자가 서비스 IP로 요청하면 로드 밸런서에서는 실제 서버의 IP 주소로 Destination NAT한 후 서버로 전달
• 서버는 다시 사용자에게 응답할 때 게이트웨이 장비인 L3 스위치를 통해 응답하는데 이때 원암 구성에서는 사용자에게 바로 응답
• 사용자 입장에선 10.10로 요청했는데 10.11에서 응답이 와버린 상황
• 해결방법
  1. 게이트웨이를 로드 밸런서로 설정
  2. Source NAT를 사용
  3. DSR 모드

7.2. 동일 네트워크 내에서 서비스 IP 호출

• 동일 네트워크 내인 경우 로드 밸런서를 거치지 않고 바로 응답
• 요청한 입장에선 요청한 IP 주소가 아닌 다른 IP 주소에서 응답이 오게 됨
• 이 경우, 서비스 요청이 로드 밸런서를 거칠 때 출발지 IP 주소를 로드 밸런서의 IP로 변경하는 Source NAT를 사용
• DSR 모드를 사용해 실제 서버에서 로드 밸런서를 거치지 않고 직접 응답

 

자료

• IT 엔지니어를 위한 네트워크 입문 (고재성, 이상훈 저, 2020.10)