[네트워크] 12. 로드 밸런서

고재성, 이상훈 저자님의 “IT 엔지니어를 위한 네트워크 입문” 책을 학습하고 정리한 글입니다.

 

1. 부하 분산 (Load Balancing)

단일 서버를 구성하거나 서버를 이중화해 서비스 호출을 분리한 경우, 서버 장애에 따라 서비스 장애가 발생한다.

이런 문제를 해결하기 위해 L4 또는 L7 스위치라고 불리는 로드 밸런서(Load Balancer)를 사용한다.

 

동일한 서비스를 하는 다수의 서버가 등록되어, 서비스 요청 시 다수의 서버에 요청을 분산시켜 부하를 분산한다. 서비스를 위한 가상 IP를 하나 제공하여 각 서버의 개별 IP 주소가 아닌 동일한 가상 IP를 통해 각 서버로 접근한다. 또한, 각 서비스 상태를 체크해 가능한 서버로만 요청을 분산하여 장애가 발생해도 다른 서버에서 서비스를 제공할 수 있다.

 

✍🏻 FWLB (FireWall Load Balancing)

서버 부하 분산을 SLB(Server Load Balancing), 방화벽 부하 분산을 FWLB(FireWall Load Balancing)라고 한다.

 

방화벽은 자신을 통과한 패킷에 대해 세션을 관리하는 세션 테이블을 가지고 있는데, 세션 테이블에 있는 응답 패킷이면 이미 정책에서 허용된 패킷이므로 방화벽을 바로 통과할 수 있다. 하지만 세션 테이블에 없는 응답 패킷이라면 폐기(Drop)하게 되는데, 이런 경우는 출발지와 목적지 간 경로가 두 개 이상으로 비대칭 경로가 만들어질 때도 발생할 수 있다.

 

이중화된 방화벽을 모두 사용하기 위해 FWLB를 사용한다. FWLB가 세션을 인식하고 일정한 규칙을 이용하여 방화벽 세션을 분산하는데, 한 번 방화벽을 지나갔던 세션이 다시 같은 방화벽을 거치도록 트래픽을 분산한다.

 

이외에도 방화벽끼리 세션 테이블을 동기화하거나, 첫 번째 패킷이 SYN이 아니어도 허용하는 기능을 사용할 수 있다.

 

2. 부하 분산 방법

로드 밸런서는 부하를 다수 장비에 분산시키기 위해 가상 IP 주소(VIP, Virtual IP 또는 서비스 IP 주소)를 사용한다. 각 서버의 실제 IP 주소를 Real IP라고 하고, 로드 밸런서의 가상 IP에 실제 서버들이 바인딩되어 해당 요청을 전달하게 된다.

부하 분산을 위한 그룹을 만들 때는 OSI 3계층 정보인 IP 주소뿐만 아니라 4계층 정보인 서비스 포트까지 지정한다. 7계층 정보(프로토콜)까지 확인해 처리하는 기능이 포함되는 경우도 있어 L7 스위치라고도 하지만, 보통 L4 스위치라고 부른다. 위 이미지는 HTTP와 HTTPS 서비스에 대해 각각 동일한 VIP를 사용했지만, 서로 다른 VIP로도 구성할 수 있다.

 

또한, 로드 밸런서의 VIP 서비스 포트와 Real IP 서비스 포트는 반드시 같을 필요가 없다. 이에 따라 사용자는 VIP의 80번 서비스 포트로 접근하고, 로드 밸런서에서는 실제 서버의 8080 서비스 포트로 변경까지 함께 수행할 수 있다.

 

3. 헬스 체크

로드 밸런서는 부하 분산을 하는 각 서버의 서비스를 주기적으로 헬스 체크(Health Check)해 정상적인 서비스로만 부하를 분산하고, 비정상적인 서버는 서비스 그룹에서 제외해 트래픽을 보내지 않는다. 서비스 그룹에서 제외한 후에도 헬스 체크를 계속 수행하여 정상으로 확인되면 서비스 그룹에 다시 포함해 트래픽이 분산되도록 한다.

 

3-1. 헬스 체크 방식

1. ICMP
   • VIP에 연결된 리얼 서버에 대해 ICMP(ping)로 헬스 체크를 수행하는 방법이다.
   • 단순히 서버가 살아 있는지 여부만 체크하는 방법으로, 잘 사용하지 않는다.
2. TCP 서비스 포트
   • 가장 기본적인 방법은 로드 밸런서에 설정된 서버의 서비스 포트를 확인하는 것이다.
   • 서버의 서비스 포트로 2000번을 등록했다면 해당 포트로 SYN으르 보내고, 서버로부터 SYN, ACK를 받으면 다시 ACK로 응답하고 FIN을 보내 헬스 체크를 종료한다.
3. TCP 서비스 포트 : Half open
   • 일반 TCP 서비스 퐅트를 확인할 때는 SYN/SYN, ACK/ACK까지 정상적인 3방향 핸드셰이크를 거친다.
   • 헬스 체크로 인한 부하를 줄이거나 빨리 헬스 체크 세션을 끊기 위해 TCP Half Open(절반 개방) 방식을 사용하기도 한다. 초기에 3방향 핸드셰이크와 동일하게 SYN을 보내고 SYN, ACK를 받지만 ACK 대신 RST를 보내 세션을 끊는다.
4. HTTP 상태 코드
   • 웹 서비스를 할 때 서비스 포트까지는 TCP로 정상적으로 열리지만, 웹 서비스 응답을 정상적으로 해주지 못하는 경우가 있다. 이때 HTTP 상태 코드를 확인하여 정상적인 상태 코드(200 OK)를 응답하는지 여부를 체크해 헬스 체크를 수행할 수 있다.
5. 콘텐츠 확인 (문자열 확인)
   • 서버로 콘텐츠를 요청하고 응답하는 내용을 확인하여 지정된 콘텐츠의 정상 응답 여부를 확인하는 방법도 있다.
   • 보통 특정 웹페이지를 호출해 사전에 지정한 문자열이 해당 웹 페이지 내에 포함되어 있는지 확인하는 기능이다.
   • 유의사항은 단순히 서버에서 응답받은 문자열만 체크하면 정상적인 요청 결과 값이 아닌 문자열만 체크하므로, 비정상적인 에러 코드에 대한 응답도 해당 응답 내용에 해당 문자열이 존재하면 헬스 체크를 정상으로 판단할 수 있다.

 

3-2. 헬스 체크 주기와 타이머

• 주기(Interval) : 서버로 헬스 체크 패킷을 보내는 주기
• 응답시간(Response) : 서버로 헬스 체크 패킷을 보내고 응답을 기다리는 시간
• 시도 횟수(Retries) : 헬스 체크 실패 시 최대 시도 횟수 (성공 시 초기화)
• 타임아웃(Timeout) : 헬스 체크 실패 시 최대 시도 횟수
• 서비스 다운 시의 주기(Dead interval) : 서비스 다운 시의 헬스 체크 주기

 

4. 부하 분산 알고리즘

로드 밸런서가 리얼 서버로 부하를 분산할 때, 사전에 설정한 분산 알고리즘을 통해 부하 분산이 이루어진다.

 

4-1. 라운드 로빈

라운드 로빈 방식은 특별한 규칙 없이 현재 구성된 장비에 순차적으로 돌아가면서 트래픽을 분산하는 방법이다.

• 순차적으로 모든 장비에 분산하므로 모든 장비의 총 누적 세션 수는 같아진다.

 

4-2. 최소 접속 방식

최소 접속 방식(Least Connection)은 서버가 가진 세션 부하를 확인해 그것에 맞게 부하를 분산하는 방법이다.

• 서비스 요청을 각 장비로 보내줄 때마다 세션 테이블이 생성되므로 각 장비에 연결된 현재 세션 수를 알 수 있다. 즉, 각 장비의 세션 수를 확인해 현재 세션이 가장 적게 연결된 장비로 서비스 요청을 보내는 방식이다.
• 서비스 별로 세션 수를 관리하며 분산하므로 각 장비에서 처리되는 활성화 세션 수가 비슷하게 부하를 분산하게 된다.

 

4-3. 해시

해시 방식은 서버의 부하를 고려하지 않고 클라이언트가 같은 서버에 지속 접속하도록 하기 위해 사용하는 부하 분산 방법이다.

• 서버 상태를 고려하는 것이 아니라, 해시 알고리즘을 이용해 얻은 결과 값으로 부하를 분산하게 된다.
• 즉, 같은 알고리즘을 사용하면 항상 동일한 결과 값을 가지고 서비스를 분산할 수 있는데 주로 출발지 IP 주소, 목적지 IP 주소, 출발지 서비스 포트, 목적지 서비스 포트를 사용한다.

 

4-4. 정리

• 라운드 로빈 / 최소 접속 방식은 부하가 비교적 비슷한 비율로 분산시킬 수 있지만 로드 밸런서를 거친 서비스 요청이 처음 분산된 서버와 다음 요청이 분산된 서버가 달라질 수 있어 각 서버에서 세션을 유지하는 서비스는 정상적으로 서비스할 수 없다.
• 해시 방식은 세션을 유지해야 할 때 항상 동일한 장비로 서비스를 분산할 수 있다. 하지만 부하 분산 비율이 한 쪽으로 치우칠 수 있다.
• 해시 방식과 최소 접속 방식의 장점을 묶어 스티키 옵션을 주어 한 번 접속한 커넥션을 지속 유지하는 기법도 있다. 하지만 세션 테이블 타임아웃이 발생하면 분산되는 장비가 달라질 수 있어 애플리케이션 세션 유지 시간이나 일반 사용자들의 애플리케이션 행동 패턴을 감안해야 한다.

 

5. 로드 밸런서 구성 방식

✍🏻 로드 밸런서의 구성 위치에 따른 구성 방식

• 원암 구성 (One-Arm)
• 인라인 구성 (Inline)

두 방식은 서버로 가는 트래픽이 모두 로드 밸런서를 경유하는지, 경유하지 않아도 되는지에 대한 트래픽 흐름으로 구분한다.

 

5-1. 원암 구성

원암 구성(One-Arm)은 로드 밸런서가 스위치 옆에 있는 형태를 말한다.

따라서, 원암 구성에서는 로드 밸런서를 이용하는 서비스에 대해서만 경유하므로 불필요한 트래픽이 유입되지 않아 부하를 줄일 수 있다. 또한 장애 영향도를 줄이기 위해서도 사용하는데, 장비에 장애가 발생하더라도 로드 밸런서를 거치지 않는 일반 서비스 트래픽 흐름에는 영향이 없기 때문이다.

 

5-2. 인라인 구성

인라인 구성(Inline)은 로드 밸런서가 스위치에서 서버까지 가는 일직선상 경로에 있는 형태를 말한다.

• 서버 #1만 로드 밸런서를 통해 부하 분산을 받더라도 인라인 구조에서는 모든 경로가 로드 밸런서를 경유하게 된다.
• 모든 트래픽이 로드 밸런서를 경유하므로 부하가 높아지게 된다. 특히 L3 스위치에 비해 4계층 이상의 데이터를 처리하므로 처리 가능한 용량이 적고 처리 용량에 따라 가격이 많이 상승하므로 부하에 따른 성능을 반드시 고려해야 한다.

 

6. 로드 밸런서 동작 모드

✍🏻 로드 밸런서 동작 방식 3가지

• 트랜스패런트(TP, Transparent) 또는 브릿지(Bridge)
• 라우티드(Routed)
• DSR(Direct Server Return)

 

 6-1. 트랜스패런트 모드

트랜스패런트(Transparent) 구성은 로드 밸런서가 OSI 2계층 스위치처럼 동작하는 구성이다. 즉, 로드 밸런서에서 서비스하기 위해 사용하는 VIP 주소와 실제 서버가 동일한 네트워크를 사용하는 구성이다.

• 원암 구성과 인라인 구성 모두 사용할 수 있는 모드이다.
• 기존에 사용하던 네트워크 대역을 그대로 사용하여 IP 네트워크 재설계를 고려하지 않아도 된다.
• 기존 망의 트래픽 흐름에 미치는 영향 없이 로드 밸런서를 쉽게 구성할 수 있다.
• 부하 분산 서비스를 받는 트래픽인 경우에만 4계층 이상의 기능을 수행하며, 부하 분산 서비스가 아닌 경우 L2 스위치와 동일한 스위칭 기능만 수행하여 L2 구조라고 부른다.

 

✍🏻 트랜스패런트 서비스 요청 과정

• 사용자가 서비스 IP 10.10으로 서비스를 요청하면 VIP에 바인딩되어 있는 Real IP 주소인 10.11로 목적지 주소가 변경된다.
• 로드 밸런서와 목적지 서버가 동일한 네트워크 대역이므로 L3 장비를 지날 때처럼 출발지 MAC 주소는 변경되지 않는다.

⇒ 서비스를 위한 VIP 주소가 Real IP 주소로 변경해 전송하므로 Destination NAT가 되었다고 한다.

 

✍🏻 트랜스패런트 서비스 응답 과정

• 서버가 응답할 때는 요청과 반대로 출발지 IP 주소가 Real IP에서 VIP 주소로 변경되지만, 목적지 MAC 주소는 변경되지 않는다.

 

6-2. 라우티드 모드

라우티드 구성(Routed)은 로드 밸런서가 라우팅 역할을 수행하는 모드다.

로드 밸런서를 기준으로 사용자 방향과 서버 방향이 서로 다른 네트워크로 분리된 구성이다.

• 원암 구성과 인라인 구성 모두 사용할 수 있는 모드이다.
• 보안 강화 목적으로 서버쪽 네트워크를 사설로 구성해 서버에 직접 접속하는 것을 막는 용도로도 사용한다.

 

✍🏻 라우티드 서비스 요청 과정

• 사용자가 VIP 주소 10.10으로 서비스를 요청하면 목적지 IP 주소를 바인딩된 Real IP 주소 20.11로 변경한다.
• 라우팅을 수행하면서 로드 밸런서를 통과하므로 출발지와 목적지 MAC 주소도 각각 변경한다.

⇒ 로드 밸런서는 서비스를 위한 VIP에서 Real IP 주소로 변경해 전송하므로 Destination NAT가 되었다고 한다.

 

✍🏻 라우티드 서비스 응답 과정

• 서버가 응답하기 위해 출발지 IP가 Real IP 주소가 되고 목적지 IP는 원래 사용자의 IP 주소가 된다.
• 다만 목적지 IP가 외부 네트워크이므로 목적지 MAC은 관문인 로드 밸런서의 MAC 주소가 된다.
• 로드 밸런서로 들어온 패킷은 출발지 IP 주소를 VIP 주소인 10.10으로 변환한다.
• 그리고 요청과 마찬가지로 출발지와 목적지 MAC 주소를 변경한 후 응답 패킷을 전송한다.

 

6-3. DSR 모드

DSR 모드(Direct Server Return)는 사용자의 요청이 로드 밸런서를 통해 서버로 유입된 후에 다시 로드 밸런서를 통과하지 않고 서버가 사용자에게 직접 응답하는 모드이다. 로드 밸런서는 응답 트래픽이 유입되지 않으므로 사용자가 요청하는 패킷만을 관리하게 된다.

• 응답 시 로드 밸런서를 경유하지 않으므로, 원암 구성으로만 사용할 수 있는 모드이다.
• L2 DSR : 실제 서버의 네트워크를 로드 밸런서가 가진 경우
• L3 DSR : 실제 서버의 네트워크 대역을 로드 밸런서가 가지지 않은 경우
• 즉, 로드 밸런서에서 실제 서버까지의 통신이 L2 통신인지, L3 통신인지에 따라 L2 DSR, L3 DSR로 나눌 수 있다.

 

✍🏻 DSR 모드의 장단점

• 요청 트래픽만 로드 밸런서를 통해 흘러, 로드 밸런서 전체 트래픽과 부하가 감소하게 된다.
• 응답 패킷의 트래픽이 서비스의 대역폭 대부분을 차지하는 경우 로드 밸런서 부하 감소 효과를 극대화할 수 있다.
• DSR 모드의 응답이 로드 밸런서를 경유하지 않아 문제 발생 시 확인이 어렵다.
• L2 DSR, L3 DSR은 다른 모드와 달리 로드 밸런서 설정 외에 서버에서도 추가적인 설정이 필요하다.

 

🤔 DSR 모드의 서버 추가 설정이 필요한 이유

 

• 요청 단계에서 로드 밸런서를 통해 VIP에서 Real IP로 Destiination NAT가 되어 목적지 주소가 변경된다.
• 이때 서버가 로드 밸런서를 거치지 않고 응답하게 되면 출발지 IP를 변경하는 Source NAT를 수행할 수 없다.
• 사용자 입장에서는 서비스를 요청한 로드 밸런서의 VIP가 아닌 다른 주소로 응답이 돌아와 비정상적인 응답으로 간주하고 패킷을 처리하게 되어 문제가 발생한다.

 

✍🏻 DSR 모드의 서버 추가 설정

• 따라서, DSR 모드는 로드 밸런서는 서비스를 요청할 때 목적지 IP는 VIP로 유지하고, 목적지 MAC 주소만 실제 서버의 MAC 주소로 변경해 서버로 전송한다.
• 서버에서는 해당 패킷을 수신할 때 목적지 IP 주소가 서버의 주소와 맞지 않으면 폐기되므로 루프백 인터페이스를 생성해 VIP 주소를 할당한다.
• 서비스 요청 트래픽이 들어오면 해당 인터페이스 IP가 아닌 루프백에 설정된 IP 주소더라도 패킷을 수신할 수 있도록 설정한다.
• 마지막으로 VIP는 로드 밸런서와 동일한 IP가 중복 설정된 상태이므로 ARP에 의해 중복된 IP에 대한 MAC이 갱신되지 않도록 서버에 설정된 VIP에 대해서는 ARP 광고가 일어나지 않도록 한다.

 

📌 루프백 인터페이스

네트워크 장치에서 내부적으로 데이터를 전송할 때 사용하는 가상 네트워크 인터페이스

• 실제 서버의 IP와 일치하지 않는 VIP로 들어오는 패킷을 서버가 유효한 트래픽으로 받아들이기 위한 목적으로 사용한다.

 

✍🏻 DSR 모드 서비스 요청 과정

• 사용자는 서비스 IP인 VIP 10.10으로 요청하고, 로드 밸런서는 목적지 IP는 둔채 목적지 서버 MAC 주소만 변경해 Real 서버로 전송한다.
• 실제 서버는 루프백 인터페이스에 VIP에 동일한 IP 주소가 설정되어 있고, 목적지 IP가 이 루프백 IP와 동일한 경우에도 패킷을 수신한다.

 

✍🏻 DSR 모드 서비스 응답 과정

• DSR 모드의 응답은 로드 밸런서가 개입하지 않아 일반 패킷과 유사하게 전달된다.
• 다만 출발지 IP가 서버의 인터페이스 IP 주소가 아닌 루프백 인터페이스 IP 주소, 즉 사용자가 요청했던 VIP 주소로 설정해 패킷을 전송한다.

 

7. 로드 밸런서 유의사항

7-1. 원암 구성의 동일 네트워크 사용 시

🤔 개인적인 견해

복잡하게 생각할 필요 없이, 원암 구성에서 로드 밸런서를 거쳐 요청이 들어왔다면, 응답 또한 로드 밸런서를 거치면 된다.

유의사항이라고 생각할 정도인가 싶은...

 

• 사용자가 로드 밸런서의 VIP로 서비스 요청을 보내면 Real IP로 변환하는 Destination NAT 후 서버로 전달한다.
• 이에 따라 서버에서 응답 패킷을 보내면 출발지 주소가 사용자가 보낸 VIP 주소가 아닌 서버 Real IP로 보내게 된다.
• 사용자는 보낸 패킷과 다른 출발지 주소 패킷을 받으므로 비정상적인 패킷으로 판단하여 폐기하게 된다.
• 즉, 로드 밸런서를 거치며 변경된 IP를 원래 IP로 바꾸어 응답해야 하는 문제를 가지고 있다.

 

1. 게이트웨이를 로드 밸런서로 설정
   • 로드 밸런서로 부하 분산이 이루어지는 실제 서버는 게이트웨이를 로드 밸런서로 설정하면 항상 응답이 로드 밸런서를 통하므로 정상적으로 사용자에게 응답할 수 있다.
   • 다만 원암 구조의 장점인 로드 밸런서의 부하 감소 효과가 감소하게 된다.
2. Source NAT 사용
   • 사용자 요청에 대해 로드 밸런서가 Destination NAT 뿐만 아니라 Source ANT를 통해 출발지 IP 주소를 로드 밸런서가 가진 IP로 함께 변경한다.
   • 서버는 사용자 요청이 아닌 로드 밸런서 요청으로 보아 응답을 로드 밸런서로 전송하게 된다.
   • 로드 밸런서는 응답 패킷의 출발지를 VIP로 바꾸고, 목적지 주소를 사용자 IP로 변경해 사용자에게 응답하게 된다.
   • 즉, 서비스를 호출할 때와 응답할 때 모두 Source/Destination NAT를 함께 수행하게 된다.
   • 다만, 서버 애플리케이션 입장에서 서비스를 호출한 IP가 하나의 동일한 IP로 보이기 때문에 사용자 구분이 어렵다.
3. DSR 모드
   • 원암 구조의 동일 네트워크에서 DSR 모드를 사용할 수 있다.

 

7-2. 동일 네트워크 내에서 서비스 IP 호출

7-1. 원암 구성의 동일 네트워크 사용 시와 마찬가지로 로드 밸런서를 거치지 않고, 서비스를 요청한 곳으로 바로 응답을 보내는 문제가 발생한다.

 

이 문제 또한 출발지 주소를 로드 밸런서 IP로 변경하는 Source NAT 방법 또는 DSR 모드를 사용해 실제 서버에서 로드 밸런서를 거치지 않고 직접 응답하면 된다. 또는 어떤 서비스 요청에 대한 응답이든 물리적으로 로드 밸런서를 거치게 하는 방법이 있는데, 이는 로드 밸런서의 포트 수가 제한되어 서버 확장에 제한적인 문제를 가지고 있다.

 

참고자료

• 책 - IT 엔지니어를 위한 네트워크 입문 (고재성/이상훈, 2020년 10월)