[IT 엔지니어를 위한 네트워크 입문] Chapter12. 로드 밸런서

IT 엔지니어를 위한 네트워크 입문

고재성, 이상훈님의 책을 보며 정리한 내용입니다.

문제가 될 시 해당글 삭제하겠습니다.

---

부하 분산이란?

• 서비스 규모가 커질 때, 물리, 가상 서버 한 대로는 모든 서비스를 수용할 수 없게 된다.
• 서비스 가용성을 높이기 위해서 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데, 각 서버 IP 주소가 다르기 때문에, 사용자가 서비스를 호출할 때는 어떤 IP 로 서비스를 요청할 지 결정해야 한다.
• 이런 문제점 해결을 위해서, L4, L7 스위치라는 로드밸런서를 사용한다.

부하 분산 방법

• 로드 밸런서는 부하를 다수의 장비에 분산시키기 위해 가상 IP 주소를 갖게 된다.
  → 이 주소는 가상 IP 주소이므로 VIP(Virtual IP) 라고도 하고, 서비스를 위해 사용 되는 IP 주소이므로 서비스 IP 라고도 한다.
• 사용자가 VIP 로 서비스를 요청하게 되면, 해당 VIP 에 연결된 리얼 IP 로 해당 요청을 전달한다.
• 로드 밸런서에서 부하 분산을 위한 그룹을 만들 때는, 3계층 IP 뿐 아니라 4계층 포트번호까지 사용 한다.
  → 때문에, 포트에 따라서 실제 서버를 다르게 분산할 수 있고, 로드 밸런서를 L4 스위치로 부른다.

헬스 체크

• 로드 밸런서에서는 주기적으로 부하 분산을 하는 각 서버의 서비스를 주기적으로 헬스 체크해 정상적인 서비스로만 트래픽이 갈 수 있도록 체크한다.

헬스 체크 방식

ICMP

• VIP 에 연결된 리얼 서버에 대해 ICMP(ping) 로 헬스 체크를 수행하는 방법이다.
• 단순히 서버가 살아 있는지 체크하는 방법으로 잘 사용하지 않는다.

TCP 서비스 포트

• 가장 기본적인 헬스 체크 방법은 로드 밸런서에 설정된 서버의 서비스 포트를 확인하는 것.
• 실제 서비스 포트에 3 way handshake 후, FIN 을 보내 헬스 체크를 종료한다.

TCP 서비스 포트 : Half Open

• 일반 TCP 서비스 포트로 인한 부하를 줄이거나, 빨리 헬스 체크 세션을 끊기 위해서 사용하는 방식이다.
• SYN 을 보내고, SYN,ACK 를 받은 후 ACK 대신 RST 를 보내 세션을 끊는다. 
  → 3 way handshake 과정을 절반으로 줄임
  

HTTP 상태 코드

• 웹서비스를 할 때, 서비스 포트까지는 TCP 로 정상적으로 열리지만, 웹 서비스에 대한 응답을 정상적으로 해주지 못하는 경우가 있다.
• 이 때 로드 밸런서 헬스 체크 방식 중 HTTP 상태 코드를 확인하는 방식으로, 3 way handshake 를 거치고, HTTP 를 요청해 200번으로 응답하는지 체크할 수 있다.

콘텐츠 확인(문자열 확인)

• 로드 밸런서에서 서버로 콘텐츠를 요청하고 응답 받은 내용을 확인하여 지정된 콘텐츠가 정상적으로 응답했는지 여부를 확인하는 헬스 체크 방법.
  → 보통 특정 웹페이지를 호출해 사전에 지정한 문자열이 해당 웹페이지 내에 포함되어 있는 지를 체크하는 기능.
• 이 방식은 로드 밸런서에서 직접 관리하는 서버의 상태 뿐 아니라, 해당 서버의 백엔드의 상태를 해당 웹페이지로 체크할 수 있다.
  → 앞단의 서버가 백엔드로 요청을 하고, 백엔드에서 정상적인 결과값으로 웹페이지에 특정 문자열을 출력하게 해 백엔드 상태까지 확인하면서 헬스 체크를 수행한다.
• 한 가지 유의 사항은, 단순히 서버에서 응답 받은 문자열만 체크하면 정상적인 요청 결과값이 아닌 문자열만 체크하므로 비정상적인 에러 코드에 대한 응답인 경우라도 해당 응답 내용에 헬스 체크 하려고 했던 문자열이 포함되어 있으면 헬스 체크를 정상으로 판단할 수 있다.
  → 때문에 정상 코드 값(HTTP CODE)도 중복으로 체크하거나, 문자열 자체를 특정 문자열로 지정해 결과가 정상일 때만 헬스 체크가 성공할 수 있도록 해야 한다.

부하 분산 알고리즘

라운드 로빈

• 특별한 규칙 없이 현재 구성된 장비에 순차적으로 돌아가면서 트래픽을 분산한다.
• ex) 서버 3대가 있을 때, 첫 번째 요청은 1번, 두 번째 요청은 2번, 세 번째 요청은 3번으로 트래픽을 분산한다.

최소 접속 방식

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

해시
→ 서비스의 특정을 고려해야 한다.

• 서버 부하를 고려하지 않고 클라이언트가 같은 서버에 지속적으로 접속하도록 하기 위해서 사용하는 방식이다.
  → 이때 알고리즘 계산에 사용되는 값들을 지정할 수 있는데, 주로 출발지 IP, 목적지 IP, 출발지 포트, 목적지 포트를 사용한다.
• 라운드 로빈이나, 최소 접속 방식은 부하를 비교적 비슷한 비율로 분산시킬 수 있다는 장점이 있지만 동일한 출발지에서 로드 밸러서를 거친 서비스 요청이 처음에 분산된 서버와 그 다음 요청이 분산된 서버가 달라질 수 있어 각 서버에서 세션을 유지해야 하는 서비스는 정상적으로 서비스 되지 않는다.
• 그와 반대로 해시 방식은 알고리즘으로 계산한 값으로 서비스를 분산하므로 항상 동일한 장비로 서비스가 분산된다. → 세션 유지에 적합한 방식
• 해시 + 최소 접속 방식의 장점을 묶어, 부하를 분산 시키는 방법도 있다.
  → 라운드 로빈, 최소 접속 방식을 사용하면 스티키(Sticky) 옵션을 주어 한번 접속한 커넥션을 지속적으로 유지하는 방법!
  → 하지만, 이 방법도 해당 세션 테이블에는 타임아웃이 있어 타임아웃 이후에는 분산되는 장비가 달라질 수 있다는 것을 고려해야 한다.

로드 밸런서 구성 방식

• 구성 위치에 따라서 2가지로 나눌 수 있다.
  → 서버로 가는 트래픽이 모두 로드 밸런서를 경유하는지 아닌지로 구분한다
  • 원암(One-Arm) 구성 : 부하 분산을 수행하는 트래픽에 대해서만 로드 밸런서를 경유한다.
  • 인라인(Inline) 구성 : 모든 트래픽에 대해서 로드 밸런서를 경유한다.

원암 구성

• 원암 구성은 로드 밸런서가 스위치 옆에 있는 형태를 말한다.
• LACP 와 같이 다수의 인터페이스로 스위치와 연결된 경우에도, 스위치 옆에 있는 구성이라면 동일하게 원암 구성이라고 한다.
  → 단순히 물리 인터페이스가 하나라는 뜻은 아니다.
• 로드 밸런서와 스위치 간 서로 다른 네트워크로 구성한 경우에도 원암 구성이라 부른다.
• 원암 구성에서는 로드 밸런서를 이용하는 서비스에 대해서만 로드 밸런서를 경유하므로 로드 밸런서 부하를 줄일 수 있다.

인라인 구성

• 인라인 구성은 트래픽이 흐르는 경로에 로드 밸런서가 있어서 서버로 향하는 트래픽이 로드 밸런서의 서비스를 받는지 여부와 상관없이 로드 밸런서를 모두 통과한다.
  → 구성이 직관적이어서 이해하기 쉽다.
• 대신, 모든 트래픽을 공유하기 때문에, 로드 밸런서 자체에 트래픽이 높다.

로드 밸런서 동작 모드

트랜스패런트 모드(L2 모드)

• 로드 밸런서가 2계층 스위치처럼 동작하는 구성이다.
  → 로드 밸런서에서 서비스하기 위해 사용하는 VIP 주소와 실제 서버가 동일한 네트워크를 사용하는 구성이다.
• VIP 와 실제 서버가 동일한 네트워크를 사용하기 때문에, 로드 밸런서 도입으로 인한 IP 네트워크를 재설계하지 않아도 된다. (손쉽게 구성 가능)
• 트래픽이 로드 밸런서를 거치더라도 부하 분산 서비스를 받는 트래픽에 대해서만 4계층 이상의 기능을 수행한다.
  (그렇지 않다면 2계층 기능을 수행한다 : 스위치)
• 원암 / 인라인 구조 모두에서 사용이 가능한 동작 모드이다.
• 동작 흐름
  1. 로드 밸런서 VIP 주소로 서비스를 요청한다.
  2. 들어온 패킷의 목적지 IP 주소를 실제 서버 IP 주소로 변경한다.
  3. 마찬가지로 패킷의 목적지 MAC 주소를 실제 서버 MAC 주소로 변경한다.(Destination NAT)
  4. 반대로 서버에서 사용자에게 응답할 때는, 로드 밸런서를 지나면서 출발지의 IP 주소는 VIP 로 변경되지만, 목적지 MAC 주소는 바뀌지 않는다.
     → 서버에서 응답할 때, 목적지 MAC 주소가 이미 게이트웨이의 MAC 주소를 가지고 있기 때문이다.

라우티드 모드

• 로드 밸런서가 라우팅 역할을 수행하는 모드.
  → 로드 밸런서 기준으로 사용자 방향 네트워크와 서버 방향 네트워크가 서로 분리되었다.
• 원암 / 인라인 구조 모두에서 사용이 가능한 동작 모드이다.
• 라우티드 모드는 보안 강화 목적으로, 서버쪽 네트워크를 사설로 구성해 서버에 접속하는 것을 막는 용도로 사용된다.
• 동작 흐름
  1. 로드 밸런서 VIP 주소로 서비스를 요청한다.
  2. 들어온 패킷의 목적지 IP 주소를 실제 서버 IP 주소로 변경한다.
  3. 라우팅을 수행하면 로드 밸런서를 통과하므로 일반 라우팅과 동일하게 출발지와 목적지 MAC 주소도 변경된다.(Destination NAT)
  4. 반대로 서버에서 사용자에게 응답할 때, 목적지의 IP 가 외부 네트워크이므로 목적지 MAC 은 외부로 나가는 관문인 로드 밸런서의 MAC 주소가 된다.
     → 로드 밸런서를 기준으로 네트워크가 달라지기 때문에, 당연한 이야기이다.
     
  5. 로드 밸런서로 들어온 패킷은 출발지 IP 주소를 실제 서버의 IP 로 요청했던 VIP 로 변환, 출발지와 목적지의 MAC 주소를 변경 후 사용자에게 응답 패킷을 전송한다.

DSR(Direct Server Return) 모드

• 요청이 로드 밸런서를 통해서 서버로 유입된 이 후, 서버가 사용자에게 직접 응답하는 모드이다.
• 네트워크에 따른 분류
  → 로드 밸런서에서 실제 서버까지의 통신이 L2 / L3 인지에 따라서 구분
  • L2 DRS : 실제 서버의 네트워크 대역을 로드 밸런서가 가진 경우
  • L3 DRS : 실제 서버의 네트워크 대역을 로드 밸런서가 가지지 않은 경우
• DRS 모드는 요청 트래픽만 로드 밸런서를 통하기 때문에, 로드 밸런서 자체의 전체 트래픽은 감소한다.
• 반면, DRS 모드는 모든 응답이 로드 밸런서를 경유하지 않기 때문에, 문제 발생 시 확인이 어렵다.
• DRS 모드는 로드 밸런서 설정 이외에 서버에서도 추가 설정이 필요하다.
• 동작 흐름
  1. 로드 밸런서 VIP 주소로 서비스를 요청한다.
  2. 목적지 IP 를 실제 서버 IP 변경하지 않고 그대로 유지하고 목적지 MAC 주소만 실제 MAC 주소로 변경한다.
     • 기존 트랜스패런츠, 라우티드 방식은 요청시 Destination NAT, 응답시 Source NAT 이 이루어졌지만, DSR 모드에서는 로드 밸런스를 거치지 않고 응답해야 하기 때문에, Source NAT 을 사용할 수 없다.
     • 때문에 서버에서는 VIP 가 아닌 실제 IP 로 응답하게 된다. → 패킷이 비대칭이기 때문에 비정상 패킷으로 인지하고 폐기한다.
  3. 실제 서버에서 목적지 IP 주소가 비대칭이면 폐킷이 폐기되므로, 루프백 인터페이스를 생성해 VIP 주소를 할당한다.
  4. 서버 랜카드 MAC 주소와 대칭되는 IP 가 아니더라도, 패킷을 수신할 수 있도록 설정한다.
  5. 해당 서버 IP 는 로드 밸런서와 동일한 IP 이기 때문에 (LAN) ARP 에 의해 중복된 IP 에 의한 MAC 이 갱신되지 않도록 서버의 VIP 가 광고 되지 않도록 한다.
  6. 클라이언트에게 패킷을 응답한다.

로드 밸런서 유의사항

원암 구성의 동일 네트워크(트랜스 패런트 모드 : L2) 사용 시

• 사용자가 서비스 IP(로드 밸런서 VIP) 로 요청하면 로드 밸런서에서는 실제 서버의 IP 주소로 Destination NAT 한 후 서버로 전달한다.
• 서버는 다시 사용자에게 응답할 때 게이트웨이 장비인 L3 스위치를 통해 응답하는데 인라인 구성에서는 로드 밸런서를 통과하지만 원암 구성에서는 로드 밸런서를 거치지 않고 바로 응답한다.
  → 요청 IP 와 응답 IP 가 매칭되지 않아서 클라이언트 입장에서는 패킷을 폐기하게 된다.
• 이 문제는 로드 밸런서를 거치면서 변경된 IP 가 재응답할 때, 로드 밸런서를 경유하면서 원래의 IP 바꾸어 응답해야 하지만 원암 구조에서는 응답 트래픽이 로드 밸런서를 경유하지 않아서 발생한다.

해결방법1. 게이트웨이를 로드 밸런서로 설정

• 서버가 동일 네트워크가 아닌 다른 네트워크의 목적지로 가려면 게이트웨이를 통과해야 한다.
• 때문에, 게이트웨이를 로드 밸런서로 설정하게 되면, 외부 사용자의 호출에 대한 응답이 항상 로드 밸런서를 통하므로 정상적으로 응답할 수 있게 된다.
• 물론 부하 분산을 사용하지 않는 서버는 기존과 동일하게 게이트웨이를 L3 스위치로 설정하면 로드 밸런서를 경유하지 않으므로 여전히 로드 밸런서의 부하 감소효과를 가져올 수 있다.

해결방법2. Source NAT 사용

• 사용자의 서비스 요청에 대해 로드 밸런서가 실제 서버로 가기 위해 수행하는 Destination NAT 뿐만 아니라, 출발지 IP 주소를 로드 밸런서가 가진 IP 로 함께 변경한다. (Source NAT)
• 이 경우 서비스를 호출할 때와 응답할 때 모두 Source/Destination NAT 을 함께 수행하게 된다.

해결방법3. DSR 모드

• DSR 모드는 사용자의 서비스 요청 트래픽에 대해 별도의 Destination NAT 을 수행 하지 않고, 실제 서버로 서비스 응답 패킷을 전송한다.
• 각 서버에는 서비스 IP 정보가 루프백(클라이언트가 목적지로 설정한 VIP) 인터페이스에 설정되어 있으며 서비스에 응답할 때 루프백에 설정된 서비스 IP 주소를 출발지로 응답한다.

동일 네트워크 내에서 서비스 IP(VIP) 호출

• 로드 밸런서를 통해 동일 네트워크에 있는 서버1, 서버2 가 있다고 가정해보자.
• 문제 상황
  1. 서버2에서 서버1의 서비스 IP 호출을 위해서 로드 밸런서로 서비스 요청을 한다.
  2. 로드 밸런서는 목적지 IP 인 서비스 IP 주소를 서버1의 IP 주소로 변환해 서버1로 전달한다.
  3. 서비스 요청을 받은 서버1은 서비스를 호출한 출발지 IP 를 확인하는데, 이 때 출발지 IP 가 동일 네트워크인 것을 확인하고 로드 밸런서를 통해서가 아닌 직접 응답한다.
  4. 서버2에서는 요청한 IP 가 아닌 다른 IP 주소로 응답이 오기 때문에, 해당 패킷은 폐기되고, 정상적인 서비스가 이루어지지 않는다.
     ⇒ 원암 / 인라인 모두에서 발생할 수 있는 문제이다.
• 해결 방안
  1. Source NAT 사용
  2. DSR 모드