로드 밸런서

서비스의 안정성이나 가용량을 높이기 위해 서비스를 이중화할 때는 서비스 자체적으로 HA 클러스터(High Availability Cluster)를 구성하기도 하지만 복잡한 고려 없이 이중화를 손쉽게 구현하도록 로드 밸런서가 많이 사용된다.

부하 분산이란?

서비스 규모가 커지면 물리 가상 서버 한 대로는 모든 서비스를 수용할 수 없게 된다. 서버 한대로 서비스를 제공할 수 있는 용량이 충분하더라도 서비스를 단일 서버로 구성하면 해당 서버의 애플리케이션, 운영체제, 하드웨어에 장애가 발생할 때, 정상적인 서비스를 제공할 수 없다.

서비스 가용성을 높이기 위해 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데 각 서버 IP 주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 한다.

사용자에 따라 호출하는 서버의 IP가 다르다면 특정 서버에 장애가 발생했을 때, 전체 사용자에게 영향을 미치지 않아 장애 범위는 줄어들겠지만 여전히 부분적으로 서비스 장애가 발생한다. 아래의 그림은 이런 서비스 장애의 예시이다.

이런 문제를 해결하기 위해 L4나 L7 스위치라는 로드 밸런서(Load Balancer)를 사용한다. 로드 밸런서에서는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 서비스 요청을 분산시켜 부하를 분산한다. 대규모 서비스 제공을 위해 이런 로드 밸런서는 필수 서비스이다.

로드 밸런서에서는 서비스를 위한 가상 IP(VIP)를 하나 제공하고 사용자는 각 서버의 개별 IP 주소가 아닌 동일한 가상 IP를 통해 각 서버로 접근한다. 또한 로드 밸런서는 각 서버의 서비스 상태를 체크해 서비스가 가능한 서버로만 사용자의 요청을 분산하므로 서버에서 장애가 발생하더라도 기존 요청을 분산하여 다른 서버에서 서비스를 제공할 수 있다.

부하 분산 방법

이중화 기술에서 공부한 LACP는 두 개 이상의 인터페이스를 하나의 논리 인터페이스로 묶어 회선의 부하를 분산시켰다. LACP는 다수의 물리 인터페이스를 하나의 논리 인터페이스로 구성하기 위해 LACP를 가상의 MAC 주소를 만들게 된다.

로드 밸런스도 이와 유사하게 부하를 다수의 장비에 분산키시기 위해 가상 IP 주소를 갖게 된다. 이 IP 주소는 가상 IP 주소이므로 VIP(Virtual IP)라고도 하고 서비스를 위해 사용되는 주소이므로 서비스 IP 주소라고도 한다.

가상 IP 주소가 있다면 실제 IP 주소도 있다. 각 서버의 실제 IP 주소를 리얼(Real) IP라고 하고 로드 밸런서의 가상 IP에 실제 서버들이 바인딩(Binding)된다.

가상 IP 주소 = VIP = 서비스 IP 주소

정리하면 로드 밸런서에는 서비스를 제공하는 서버의 IP인 리얼 IP와 로드 밸런서에서 서비스를 대표하는 VIP가 있다. VIP에는 리얼 IP가 바인딩되어 있고 사용자가 VIP로 서비스를 요청하면 해당 VIP에 연결된 리얼 IP로 해당 요청을 전달한다.

아래 그림을 통해 부하 분산의 예를 확인해보자.

로드 밸런서에서 부하 분산을 위한 그룹을 만들 때는 앞의 예제처럼 OSI 3계층 정보인 IP 주소뿐만 아니라 4계층 정보인 서비스 포트까지 지정해서 만든다.

위의 예제에서는 HTTP와 HTTPS 서비스에 대해 각각 동일한 VIP를 사용했지만 서로 다른 VIP로도 구성할 수 있다. 또한, 로드 밸런서의 VIP에 설정된 서비스 포트와 실제 서비스 포트는 반드시 같을 필요가 없다.

즉, 실제 서버에서는 서비스 포트 8080으로 웹 서비스를 수행하면서 VIP에서는 일반 HTTP 서비스 포트인 80으로 설정할 수 있다. 이렇게 되면 사용자는 VIP의 80 서비스 포트로 접근하고 로드 밸런서에서는 해당 서비스 요청을 실제 서버의 8080 서비스 포트 변경까지 함께 수행하게 된다.

동일한 리얼 IP에서 서비스 포트마다 VIP를 다르게 설정할 수 있고 리얼 IP의 서비스 포트와 VIP 포트도 서로 다르게 설정할 수 있다.

헬스 체크

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

헬스 체크 방식

TCP 서비스 포트

가장 기본적인 헬스 체크 방법은 로드 밸런서에 설정된 서버의 서비스 포트를 확인하는 것이다. 즉, 로드 밸런서에서 서버의 서비스 포트 2000번을 등록했다면 로드 밸런서에서는 리얼 IP의 2000번 포트로 SYN을 보내고 해당 리얼 IP를 가진 서버로부터 SYN, ACK를 받으면 서버에 다시 ACK로 응답하고 FIN을 보내 헬스 체크를 종료한다.

SYN - 연결 시작 용도로 사용
FIN - 데이터 전송을 마친 후 정상적으로 양방향 종료 시 사용

TCP 서비스 포트: Half Open

일반 TCP 서비스 포트를 확인할 때는 SYN/SYN, ACK/ACK까지 정상적인 3방향 핸드셰이크를 거치게 된다. 헬스 체크로 인한 부하를 줄이거나 정상적인 종료 방식보다 빨리 헬스 체크 세션을 끊기 위해 정상적인 3방향 핸드셰이크와 4방향 핸드셰이크가 아닌 TCP Half Open 방식을 사용하기도 한다.

RST - 연결 강제 종료를 위해 연결을 일방적으로 끊을 때 사용

HTTP 상태 코드

웹 서비스를 할 떄, 서비스 포트까지는 TCP로 정상적으로 열리지만 웹 서비스에 대한 응답을 정상적으로 해주지 못하는 경우가 있다. 이때 로드 밸런서의 헬스 체크 방식 중 HTTP 상태 코드를 확인하는 방식으로 로드 밸런서가 서버로 3방향 핸드셰이크를 거치고나서 HTTP를 요청해 정상적인 상태 코드(200 OK)를 응답한는지 여부를 체크해 헬스 체크를 수행할 수 있다.

헬스 체크 주기와 타이머

헬스 체크 방법 외에 헬스 체크의 주요 고려사항인 헬스 체크 주기에 대해 알아보자. 헬스 체크 주기를 볼 때는 응답 시간, 시도 횟수, 타임아웃 등 다양한 타이머를 함께 고려해야 한다.

주기(Intervel)
로드 밸런서에서 서버로 헬스 체크 패킷을 보내는 주기

응답 시간(Response)
로드 밸런서에서 서버로 헬스 체크 패킷을 보내고 응답을 기다리는 시간
해당 시간까지 응답이 오지 않으면 실패로 간주

시도 횟수(Retries)
로드 밸런서에서 헬스 체크 실패 시 최대 시도 횟수
최대 시도 횟수 이전에 성공 시 시도 횟수는 초기화 됨

타임아웃(Timeout)
로드 밸런서에서 헬스 체크 실패 시 최대 대기 시간
헬스 체크 패킷을 서버로 전송한 후 이 시간 내에 성공하지 못하면 해당 서버는 다운

서비스 다운 시의 주기(Dead Interval)
서비스의 기본적인 헬스 체크 주가기 아닌, 서비스 다운 시의 헬스 체크 주기
서비스가 죽은 상태에서 헬스 체크 주기를 별도로 더 늘릴 때 사용

다음 그림은 헬스 체크를 수행하는 주기와 타이머를 시각화한 것이다.

검은색 원 모양은 로드 밸런서에서 서버로 헬스 체크 패킷을 보내는 시점을 나태낸다. 헬스 체크 주기 시간마다 로드 밸런서는 서버로 헬스 체크 패킷을 전송한다. 주기가 3초로 설정되었다면 3초마다 헬스 체크 패킷을 서버로 전송한다. 이때 원 모양 사이의 시간이 3초가 된다.

파란색 원 모양은 로드 밸런서가 보낸 헬스 체크 패킷에 대한 서버의 응답을 최대로 기다리는 시간이다. 응답 시간으로 설정된 시간 내에 서버에서 응답이 오지 않으면 로드 밸런서는 해당 헬스 체크 시도를 실패로 처리한다. 응답 시간을 1초로 주었다면 검은색 원 모양의 헬스 체크 패킷 전송 이후 1초 내에 서버에서 응답을 수신해야 한다. 이때 유의사항은 헬스 체크 패킷을 보내는 주기를 응답 시간보다 크게 설정해야하는 점이다.

부하 분산 알고리즘

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

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

라운드 로빈

라운드 로빈 방식은 특별한 규칙 없이 현재 구성된 장비에 순차적으로 돌아가면서 트래픽을 분산한다. 순차적으로 모든 장비에 분산하므로 모든 장비의 총 누적 세션 수는 같아진다.

최소 접속 방식

최소 접속 방식은 서버가 가진 세션 부하를 확인해 그것에 맞게 부하를 분산하는 방식이다. 로드 밸런서에서는 서비스 요청을 각 장비로 보내줄 때마다 세션 테이블이 생성되므로 각 장비에 연결된 현재 세션 수를 알 수 있다. 최소 접속 방식은 각 장비의 세션 수를 확인해 현재 세션이 가장 적게 연결된 장비로 서비스 요청을 보내는 방식이다. 서비스별로 세션 수를 관리하면서 분산해주므로 각 장비에서 처리되는 활성화 세션 수가 비슷하게 분산되면서 부하를 분산한다.

해시

해시 방식은 서버의 부하를 고려하지 않고 클라이언트가 같은 서버에 지속적으로 접속하도록 하기 위해 사용하는 부하 분산 방식이다. 서버 상태를 고려하는 것이 아니라 해시 알고리즘을 이용해 얻은 결과값으로 어떤 장비로 부하를 분산할지 결정한다.

라운드 로빈이나 최소 접속 방식은 부하를 비교적 비슷한 비율로 분산시킬 수 있다는 장점이 있지만 동일한 출발지에서 로드 밸런서를 거친 서비스 요청이 처음에 분산된 서버와 그 다음 요청이 분산된 서버가 달라질 수 있어 각 서버에서 세션을 유지해야 하는 서비스는 정상적으로 서비스되지 않는다.

반대로 해시 방식은 알고리즘으로 계싼한 값으로 서비스를 분산하므로 항상 동일한 장비로 서비스가 분산된다. 즉, 세션을 유지해야 하는 서비스에 적합한 분산 방식이다.

로드 밸런서 구성 방식

로드 밸런서의 구성 방식은 로드 밸런서의 구성 위치에 따라 2가지로 나룰 수 있다.

원암(One-Arm) 구성

인라(Inline) 구성

아래의 그림은 2가지 구성방식을 표현한 것이다.

원암 구성은 로드 밸런서가 중간 스위치 옆에 연결되는 구성이고 인라인 구성은 서버로 가는 경로상에 로드 밸런서가 연결되는 구성이다.

실질적으로 원암과 인라인의 구분은 서버로 가는 트래픽이 모두 로드 밸런서를 경유하는지, 경유하지 않아도 되는지에 대한 트래픽 흐름으로 구분한다.

원암 구성은 부하 분산을 수행하는 트래픽에 대해서만 로드밸런서를 경유하고 부하 분산을 수행하지 않는 트래픽은 로드 밸런서를 경유하지 않고 통신할 수 있다. 반면, 인라인 구성은 부하 분산을 포함한 모든 트래픽이 로드 밸런서를 경유하는 구성이 된다.

원암 구성

로드 밸런서의 원암(One-Arm) 구성은 로드 밸런서가 스위치 옆에 있는 형태를 말한다. 위의 그림에서 로드 밸런서가 스위치와 인터페이스 하나로 연결되어 있지만 원암 구성이 단순히 물리 인터페이스 하나라는 뜻은 아니다. LACP와 같은 다수의 인터페이스로 스위치와 연결된 경우에도 스위치 옆에 있는 구성이라면 동일하게 원암 구성이라 한다. 또한 서로 다른 네트워크로 로드 밸런서와 구성한 경우도에 원암 구성이 될 수 있다.

원암 구성에서는 서버로 들어가거나 나오는 트래픽이 로드 밸런서를 경유하거나 경유하지 않을 수 있다.

먼저 원암 구조에서 부하 분산을 이용하는 트래픽 흐름을 살펴보자.

부하 분산을 이용하는 트래픽의 경우, 부하 분산에 사용되는 서비스 IP 정보를 로드 밸런서가 가지고 있어 서버로 유입되는 트래픽은 먼저 로드 밸런서를 거친다. 로드 밸런서에서는 각 실제 서버로 트래픽을 분산하고 서버의 응답 트래픽은 다시 로드 밸런서를 거쳐 사용자에게 응답하게 된다.

다음은 원암 구조에서 부하 분산을 이용하지 않는 트래픽 흐름의 그림이다.

로드 밸런서의 부하 분산을 이용하지 않는 트래픽은 원암 구성에서 굳이 로드 밸런서를 거치지 않아도 서버와 통신할 수 있다.

따라서 원암 구성에서는 로드 밸런서를 이용하는 서비스에 대해서만 로드 밸런서를 경유하므로 불필요한 트래픽이 로드 밸런서에 유입되지 않아 로드 밸런서 부하를 줄일 수 있다. 원암 구성은 로드 밸런서 부하 감소는 물론 장애 영향도를 줄이기 위해서도 사용된다. 또한, 로드 밸런서를 통과해야 하는 트래픽과 통과하지 않아도 되는 트래픽이 섞인 경우에 많이 사용된다.

인라인 구성

인라인 구성은 트래픽이 흐르는 경로에 로드 밸런서가 있어서 서버로 향하는 트래픽이 로드 밸런서의 서비스를 받는지 여부와 상관없이 로드 밸런서를 모두 통과한다.

아래의 그림처럼 서버#1, 서버 #2가 있을 때 서버 #1만 로드 밸런서를 통해 부하 분산을 받더라도 인라인 구조에서는 외부에서 서버까지의 경로가 로드 밸런서를 경유하도록 되어 있다.

인라인 구성에서는 부하 분산 여부와 상관없이 모든 트래픽이 동일한 경로로 흐르므로 구성이 직관적이고 이해하기 쉽지만 모든 트래픽이 로드 밸런서를 경유하므로 로드 밸런서의 부하가 높아진다.

로드 밸런서 동작 모드

로드 밸런서의 동작 방식은 많이 있지만 3가지만 알아보자.

트랜스패런트(Transparent: TP) 또는 브릿지(Bridge)

라우티드(Routed)

DSR(Direct Server Return)

트랜스패런트 모드

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

트랜스패런트 구성은 기존에 사용하던 네트워크 대역을 그대로 사용하므로 로드 밸런서 도입으로 인한 IP 네트워크 재설계를 고려하지 않아도 되고 네트워크에 L2 스위치를 추가하는 것과 동일하게 기존 망의 트래픽 흐름에 미치는 영향 없이 로드 밸런서를 손쉽게 구성할 수 있다. 또한, 원암과 인라인 구성에서 모두 트랜스패런트 구성이 가능하다.

트랜스패런트 모드에서 부하 분산 트래픽이 어떻게 흐르는지 알아보자.

사용자는 서비스 IP인 로드 밸런서의 VIP 주소 10.10으로 서비스를 요청한다. 로드 밸런서로 들어온 패킷은 목적지 IP 주소를 VIP에 바인딩되어 있는 실제 서버 IP 주소로 변경하므로 목적지 IP 주소는 10.10에서 10.11로 변경된다. 마찬가지로 목적지 MAC 주소도 실제 서버의 MAC 주소인 C가 된다. 로드 밸런서와 목적지 서버가 동일한 네트워크 대역이므로 L3장비를 지날 때처럼 출발지 MAC 주소는 변경되지 않는다.
로드 밸런서에서 서비스를 위한 VIP 주소가 실제 서버의 IP 주소로 변경해 전송하므로 목적지(Destination) NAT가 되었다고 한다.

서버에서 사용자에게 응답할 때는 로드 밸런서를 지나면서 요청할 때와 반대로 출발지의 IP 주소가 실제 서버의 IP에서 VIP 주소로 변경되지만 목적지 MAC 주소는 변경되지 않는다. 서버에서 응답할 때, 목적지 MAC 주소가 이미 게이트워이의 MAC 주소를 갖고 있어 변경할 필요가 없기 때문이다.

라우티드 모드

라우티드 구성은 이름에서도 알 수 있듯이 로드 밸런서가 라우팅 역할을 수행하는 모드이다. 즉, 로드 밸런서를 기준으로 사용자 방향(Client Side)과 서버 방향(Server Side)이 서로 다른 네트워크로 분리된 구성이다. 로드 밸런서는 사용자 방향과 서버 방향의 네트워크를 라우팅으로 연결한다. 라우티 모드는 원암 구성와 인라인 구성에서 모두 구성할 수 있다.

라우티드 구성에서 로드 밸런서를 통한 트래픽이 어떻게 흐르는지 살펴보자.

사용자는 서비스 IP인 VIP 주소 10.10으로 서비스를 요청한다. 로드 밸런서로 들어온 패킷은 목적지 IP 주소를 VIP에 바인딩된 실제 서버 IP 주소인 20.11로 변경한다. 라우팅을 수행하면서 로드 밸런서를 통과하므로 일반 라우팅과 동일하게 출발지와 목적지의 MAC 주소도 각각 A → D, B → C로 변경된다. 목적지 IP와 출발지/목적지 MAC이 변경된 패킷은 라우팅 테이블을 확인해 실제 서버로 전송한다.

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

DSR 모드

DSR(Direct Server Return)은 명칭 그대로 사용자의 요청이 로드 밸런서를 통해 서버로 유입된 후에 다시 로드 밸런서를 통하지 않고 서버가 사용자가에 직접 응답하는 모드이다. 로드 밸런서에는 응답 트래픽이 유입되지 않으므로 사용자가 요청하는 패킷에 대해서만 관여한다. DSR 모드는 응답할 때, 로드 밸런서를 경유하지 않으므로 원암으로 구성한다.

DSR 모드는 L2 DSR과 L3 DSR로 구분되는데 L2 DSR은 실제 서버의 네트워크를 로드 밸런서가 가진 경우이며 L3 DSR은 실제 서버의 네트워크 대역을 로드 밸런서가 가지지 않은 경우이다. 즉, 로드 밸런서에서 실제 서버까지의 통신이 L2 통신인지, L3 통신인지에 따라 L2 DSR과 L3 DSR로 나눌 수 있다.

DSR 모드에서는 요청 트래픽만 로드 밸런서를 통해 흐르므로 로드 밸런서 전체 트래픽이 감소해 로드 밸런서 부하가 감소한다. 예를 들어 사용자 요청에 의한 스트리밍 서비스와 같이 응답 패킷의 트래픽이 서비스에 필요한 대역폭의 대부분을 차지하는 경우에는 DSR 모드를 통해 로드 밸런서를 경유하지 않고 응답 패킷의 트래픽을 전달하여 로드 밸런서 부하 감소 효과를 극대화할 수 있다.

이러한 효과가 있는 반면에 DSR 모드의 서비스 응답이 로드 밸런서를 경유하지 않으므로 문제가 발생했을 때, 문제 확인이 어렵다.

아래의 그림은 L2 DSR과 L3 DSR을 표현한 그림이다.

DSR는 로드 밸런서 설정 외에 서버에서도 추가 설정이 필요한데 그 이유를 DSR 모드의 트래픽 흐름을 통해 알아보자.

사용자는 서비스 IP인 VIP로 서비스를 요청한다. 로드 밸런서로 들어온 서비스 요청 패킷은 앞에서 알아본 트랜스패런트나 라우티드 방식의 경우, 목적지 IP 주소가 로드 밸런서를 거치면서 실제 서버의 IP로 Destination NAT가 되고 응답할 때는 다시 VIP를 Source NAT를 수행한다.
하지만 DSR 모드는 아래의 그림처럼 서버에서 로드 밸런서를 거치지 않고 응답해야 하므로 응답할 때, 로드 밸런서를 통한 출발지 IP를 변경하는 Source NAT를 수행할 수 없다.

Source NAT가 수행되지 않았기 때문에 사용자 입장에서는 서비스를 요청했던 IP 주소인 로드 밸런서의 서비스 VIP가 아닌 실제 서버 IP로 응답을 받는다. 요청했던 IP 주소와 응답을 해주는 IP 주소가 다르기 때문에 사용자는 비정상적인 응답으로 간주하고 패킷을 처리하지 않는다.

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

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

아래의 그림은 DSR 모드에서 서비스 요청 시의 패킷 흐름이다.

DSR 모드에서 서비스 응답 시의 패킷 흐름이다.

로드 밸런서 유의 사항

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

아래의 그림은 원암 구성에서 서비스 IP와 서버의 네트워크 대역이 동일 네트워크를 사용하는 경우를 나타낸 것이다.

사용자가 서비스 IP(VIP)로 요청하면 로드 밸런서에서는 실제 서비스 IP 주소로 Destination NAT한 후 서버로 전달한다. 서버는 다시 사용자에게 응답할 때 게이트웨이 장비인 L3 스위치를 통해 응답하는데 인라인 구성에서는 로드 밸런서를 통과하지만 원암 구성에서는 로드 밸런서를 거치지 않고 사용자에게 바로 응답한다.

사용자는 10.10이라는 서비스 IP로 요청했지만 응답은 서버의 실제 IP 10.11로 받게 되고 서비스를 호출한 사용자 입장에서는 요청하지 않은 IP에서 응답 패킷을 받았으므로 해당 패킷은 정상적으로 처리되지 않고 폐기된다.

다음은 이런 문제를 해결하는 방법이다.

게이트웨이를 로드 밸런서로 설정

서버에서 동일 네트워크가 아닌 목적지로 가려면 게이트웨이를 통과해야 한다. 따라서 로드 밸런서를 통해 부하 분산이 이루어지는 실제 서버에 대해서는 게이트웨이를 로드 밸런서로 설정하면 로컬 네트워크가 아닌 외부 사용자의 호출에 대한 응답이 항상 로드 밸런서를 통하므로 정상적으로 사용자에게 응답할 수 있게 된다.

Source NAT 사용

사용자의 서비스 요청에 대해 로드 밸런서가 실제 서버로 가기 위해 수행하는 Destination NAT뿐만 아니라 출발지 IP 주소를 로드 밸런서가 가진 IP로 함께 변경한다. 그럼 서버에서는 사용자의 요청이 아니라 로드 밸런서가 서비스 요청을 한 것으로 보이기 때문에 응답을 로드 밸런서로 보내게 된다. 로드 밸런서는 응답 패킷의 출발지를 실제 서버에서 로드 밸런서에 있는 서비스 IP(VIP)로 바꾸고 목적지 IP 주소를 로드 밸런서의 IP에서 원래의 사용자 IP로 변경해 사용자에게 응답한다.

DSR 모드

원암 구조의 동일 네트워크에서 DSR 모드를 사용할 수 있다. DSR 모드는 사용자의 서비스 요청 트래픽에 대해 별도의 Destination NAT를 수행하지 않고 실제 서버로 서비스 요청 패킷을 전송한다. 각 서버에는 서비스 IP 정보가 루프백 인터페이스에 설정되어 있으며 서버에 응답할 때, 루프백에 설정된 서비스 IP 주소를 출발지로 응답한다.

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

로드 밸런서 구성상 두 번째 유의사항은 동일 네트워크 내에서 서비스 IP(VIP)를 호출하는 경우이다. 아래의 그림을 예제로 살펴보자.

서버 #1은 로드 밸런서의 서비스 IP를 통해 부하 분산이 이루어지고 있는 서버이다. 이때 서버 #2에서 서버 #1의 서비스 IP 호출을 위해 로드 밸런서로 서비스 요청을 한다(①).
로드 밸런서에서는 목적지 IP인 서비스 IP 주소를 서버 #1의 IP 주소로 변환해 서버 #1로 전달한다(②). 서비스 요청을 받은 서버#1은 서비스를 호출한 출발지 IP를 확인해 응답하는데 이때 서비스를 호출한 출발지가 자신과 동일한 네트워크임을 확인하다. 동일한 네트워크이므로 목적지에 대해 로드 밸런서를 거치지 않고 바로 응답한다(③).
서버 #2에서는 서비스를 요청한 IP 주소가 아닌 다른 IP 주소로 응답이 오므로 해당 패킷은 폐기되면서 정상적인 서비스가 이루어지지 않게 된다.

이러한 문제 해결 방법은 서비스 요청이 로드 밸런서를 걸칠 때, 출발지 IP 주소를 로드 밸런서의 IP로 변경하는 Source NAT 방법을 사용하거나 DSR 모드를 사용해 실제 서버에서 로드 밸런서를 거치지 않고 직접 응답하면 된다.

출처
IT 엔지니어를 위한 네트워크 입문을 정리한 포스팅입니다.