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

로드 밸런서는 서비스에 따라 적용해야 하는 구성 방식과 동작 모드가 각각 다르고 고려해야 하는 지점도 다르다.

따라서 로드 밸런서의 구성과 동작 모드를 이해해야만 서비스에 필요한 구성을 할 수 있다.

부하 분산

서비스 규모가 커지면 물리나 가상 서버 한대로는 모든 서비스를 수용할 수 없다.
여러 대의 서버로 구성된 서비스는 호출할 때 어떤 IP로 서비스를 요청할지 결정해야 한다.

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

헬스 체크

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

헬스체크 방식

로드 밸런서는 다양한 헬스 체크 방식으로 서버의 서비스 정상 여부를 판단할 수 있다.

ICMP

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

TCP 서비스 포트

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

TCP 서비스 포트: 하프 오픈

일반 TCP 서비스 포트를 확인할 때는 SYN/SYN, ACK/ACK까지 정상적인 3웨이 핸드쉐이크를 거치게 된다.
헬스 체크로 인한 부하를 줄이거나 정상적인 종료 방식보다 빨리 헬스 체크 세션을 끊기 위해 TCP Half Open 방식을 사용하기도 한다.
TCP Half Open 방식은 초기의 3방향 핸드셰이크와 동일하게 SYN을 보내고 SYN, ACK를 받지만 이후 ACK 대신 RST를 보내 세션을 끊는다.

HTTP 상태 코드

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

컨텐츠 확인

로드 밸런서에서 서버로 컨텐츠를 요청하고 응답받은 내용을 확인하여 지정된 컨텐츠가 정상적으로 응답했는지 여부를 확인하는 헬스 체크 방법도 있다.
보통 특정 웹페이지를 호출해 사전에 지정한 문자열이 해당 웹페이지 내에 포함되어 있는지를 체크하는 기능이다.
이 기능은 앞단의 서버가 백엔드로 요청을 하고 백엔드에서 결과값을 검사하므로 백엔드 상태까지 확인한다.

이 방식은 단순히 응답받은 문자열만 체크시 비정상적인 에러 코드에서 해당 문자열이 포함되어 있으면 헬스 체크가 정상으로 나올 수 도있다.

헬스 체크 주기와 타이머

헬스체크 주기를 볼 때 다양한 타이머를 함께 고려해야 한다.

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

• 응답 시간(Response)
  헬스 체크 패킷을 보내고 응답을 기다리는 시간, 해당 시간까지 오지 않으면 실패

• 시도 횟수(Retries)
  헬스 체크 실패 시 최대 시도 횟수

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

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

부하 분산 알고리즘

로드 밸런서가 리얼 서버로 부하를 분산할 때 여러가지 알고리즘이 사용된다.

알고리즘	설명
라운드 로빈(Round Robin)	현재 구성된 장비에 부하를 순차적으로 분산함. 총 누적 세션 수는 동일하지만 활성화된 세션수는 달라질 수 있음
최소 접속 방식(Least Connection	현재 구성된 장비 중 가장 활성화된 세션 수가 적은 장비로 부하를 분산
가중치 기반 라운드 로빈	라운드 로빈이지만, 각 장비에 가중치를 두어 가중치가 높은 장비에 부하를 분산하기 위한 분산 알고리즘
가중치 기반 최소 접속 방식	최소 접속 방식과 동일하지만 각 장비에 가중치에 부여해 가중치가 높은 장비에 부하를 더 많이 분산
해시	해시 알고리즘 사용, 클라이언트가 같은 서버에 지속적으로 접속하도록 사용하기 위함

로드 밸런서 구성 방식

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

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

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

원암 구성은 부하 분산을 수행하는 트래픽에 대해서만 로드 밸런서를 경유하고 부하 분산을 하지 않는 트래픽은 로드 밸런서를 경유하지 않고 통신할 수 있다.

인라인 구성은 부하 분산을 포함한 모든 트래픽이 로드 밸런서를 경유하는 구성이다.

이런 구성 방식에 따라 트래픽이 흐르는 경로, NAT 설정, 로드 밸런서의 동작 모드가 달라질 수 있다.

원암 구성

원암 구성에서 주의할 점은 스위치와 로드밸런서가 단순히 물리 인터페이스가 하나라는 뜻은 아니다.
LACP와 같이 다수의 인터페이스로 스위치와 연결된 경우에도 스위치 옆에 있는 구성이라면 동일하게 원암 구성이라고 한다.

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

원암 구조에서 서버의 응답 트래픽이 로드 밸런서를 다시 거치려면 서비스 IP에 실제 서버로 DNAT 뿐만 아니라 서비스를 호출한 사용자 IP가 아니라 로드 밸런서 IP로 SNAT도 함께 이루어져야 한다.

원암 구성에서는 로드 밸런서를 이용하는 서비스에 대해서만 로드 밸런서를 경유하므로 로드 밸런서의 부하를 줄일 수 있다.
스위치와 로드 밸런서 간의 대역폭을 최소화할 수 있고 대역폭이 부족할 때는 이 구간만 증설하면 되므로 인라인 방식보다 상대적으로 확장에 유리하다.

인라인 구성

인라인 구성은 서버로 향하는 모든 트래픽이 로드 밸런서를 통한다.
그래서 구성이 쉽고 직관적이다.
하지만 로드 밸런서의 부하가 높아지므로 로드 밸런서의 스펙을 잘 고려해야 한다.
인라인으로 로드 밸런서를 선정할 때 로드 밸런싱 성능과 패킷 스루풋 성능을 구별해 디자인해야 한다.

로드 밸런서 동작 모드

로드 밸런서 동작 모드에 따라 패킷 통신 방식도 바뀌므로 동작 모드에 대한 이해는 운용 및 장애조치로 직결 된다.

트랜스패런트(Transparent: 투명) 모드

로드 밸런서가 OSI 2계층 스위치처럼 동작하는 구성이다.
로드 밸런서에서 서비스하기 위해 사용하는 VIP 주소와 실제 서버가 동일한 네트워크를 사용하는 구성이다.
트랜스패런트 구성은 기존에 사용하던 네트워크 대역을 그대로 사용하므로 로드 밸런서 도입으로 인한 IP 네트워크 재설계를 고려하지 않아도 되고 네트워크에 L2 스위치를 추가하는 것과 동일하게 기존 망의 트래픽 흐름에 미치는 영향 없이 구성할 수 있다.

이 구성의 경우 패킷이 부하 분산 서비스를 받는 트래픽인 경우에만 4계층 이상의 기능을 수행하고 아닌 경우는 L2 스위치 처럼 동작한다.

트랜스패런트 모드는 원암과 인라인 구성 모두 사용할 수 있다.
다만 원암 구성에서는 응답 트래픽 경로 부분이 문제가 될 수 있어 SNAT이 필요하다.

라우티드 모드

로드 밸런서가 라우팅 역할을 수행하는 모드이다.
로드 밸런서를 기준으로 사용자 방향과 서버 방향이 서로 다른 네트워크로 분리된 구성이다.
로드 밸런서는 사용자 방향과 서버 방향의 네트워크를 라우팅으로 연결한다.
라우티드 모드는 두 가지 구성 모두 사용할 수 있다.

이 모드는 보안 강화 목적으로 서버 쪽 네트워크를 사설로 구성해 서버에서 직접 접속하는 것을 막는 용도로 사용되기도 한다.

DSR 모드

사용자의 요청이 로드 밸런서를 통해 서버로 유입되고 서버가 사용자에게 직접 응답하는 모드이다.
로드 밸런서는 사용자가 요청하는 패킷에만 관여한다.

이 모드는 응답할 때는 로드 밸런서를 경유하지 않으므로 원암으로 구성한다.

DSR 모든 L2, L3 모드가 있다.
L2 DSR은 실제 서버의 네트워크를 로드 밸런서가 가진 경우이며,
L3 DSR은 가지지 않은 경우이다.
즉, 로드 밸런서에서 실제 서버까지의 통신이 L2인지 L3인지로 나눈다.

DSR 모드는 요청 트래픽만 로드 밸런서를 경유하므로 로드 밸런서의 부하가 감소한다.
특히 서비스 요청 패킷보다 응답 패킷이 훨씬 크기 때문에 트래픽 부하 감소에 효과적이다.

반면, 서비스 응답이 로드 밸런서를 경유하지 않기 때문에 문제 확인이 어렵다.
다른 동작 모드는 로드 밸런서 설정만 필요하지만 L2, L3 DSR은 로드 밸런서 설정 외에도 서버에서도 추가 설정이 필요하다.

위의 두 모드는 로드 밸런서에서 목적지 IP 주소가 리얼 IP로 DNAT 되고 응답할 때는 VIP로 SNAT 한다.
하지만 DSR 모드는 서버에서 바로 사용자로 가야하기 때문에 로드 밸런서에서 SNAT을 할 수 없다.

그래서 사용자 입장에서는 서비스를 요청했던 VIP가 아닌 리얼 IP에서 응답을 받기 때문에 비정상적인 응답으로 간주하고 패킷을 처리하지 않는다.
DSR 모드는 서비스를 요청할 때 목적지를 VIP로 유지하고 목적지 MAC 주소만 리얼 MAC 주소로 변경한다.
리얼 서버에서는 목적지 IP 주소가 자신의 IP가 아니면 폐기되므로 루프백 인터페이스를 생성해 VIP 주소를 할당한다.
이 VIP는 로드 밸런서와 동일한 IP가 중복되기 때문에 ARP에 의해 중복된 IP에 대한 MAC이 갱신되지 않도록 서버에 설정된 VIP는 ARP 광고가 되지 않게 해야한다.

결국 리눅스에서 DSR 모드를 사용하려면, 루프백 인터페이스 설정과 리눅스 커널 파라미터 수정이 필요하다.

로드 밸런서 유의사항

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

원암 구성은 로드 밸런서를 이용하는 서비스에 대해서만 로드 밸런서를 경유하므로 로드 밸런서의 부하와 장애 범위를 줄일 수 있는 구성이다.
하지만 서비스 네트워크와 서버 네트워크가 동일 네트워크라면 문제가 발생할 수 있다.

사용자가 VIP로 요청하면 로드 밸런서에서는 리얼 IP로 DNAT한 후 서버로 전달한다.
서버는 다시 사용자에게 응답할 때 L3 스위치를 통해 응답하는데 원암 구성에서는 로드 밸런서를 거치지 않고 사용자에게 바로 응답한다.
이러면 DSR 모드와 비슷한 문제가 발생한다.

해결 사항

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

로드 밸런서를 통해 부하 분산이 이루어지는 실제 서버에 대해 게이트웨이를 로드 밸런서로 설정하면 외부 사용자 호출에 대한 응답이 항상 로드 밸런서를 통하므로 정상적으로 응답할 수 있다.

이 경우 실제 트래픽 플로우가 로드 밸런서를 게이트웨이로 사용하면 원암 구조의 로드 밸런서 부하 감소의 이점이 줄어든다.
부하 분산을 사용하지 않는 서버는 기존 설정을 유지하면 여전히 로드 밸런서의 부하 감소 효과를 가져올 수 있다.

DSR 모드

DSR과 비슷한 문제이므로 DSR 모드로 변경함으로써 해결한다.

동일 네트워크 내에서 VIP 호출

동일 네트워크에서 VIP를 호출 시 서버에서 응답을 리턴할 때 동일한 네트워크이므로 목적지에 대해 로드 밸런서를 거치지 않고 바로 응답한다.
그렇다면 요청 IP와 응답 IP가 달라지는 결과를 볼 수 있다.

이 문제는 두 가지 구성 공통이다.
이 해결 방법도 거의 비슷하다.

서비스 요청이 로드 밸런서를 거칠 때, 출발지 IP 주소를 VIP로 변경하는 SNAT를 하거나, DSR 모드를 사용하면 된다.

HAProxy를 사용한 로드 밸런서 설정

HAProxy는 오픈 소스 기반의 소프트웨어로 제공하는 일종의 NFV(Network Function Virtualization) 이다.

HAProxy는 간단한 설정만으로 바로 사용할 수 있어 로드 밸런서 서비스를 신속히 제공할 수 있다.
소프트웨어 형태로 가상화나 클라우드 환경에서 적합하다.
또한, 쿠버네티스의 인그레스 컨트롤러 역할도 할 수 있다.