[안정성을 위한 기술] 로드 밸런서(1)

 

 서비스의 안정성 및 가용성을 높이기 위해 이중화를 구현할 때, HA 클러스터(High Availability Cluster)와 같은 자체적인 방식도 활용되지만, 복잡한 설정 없이 이중화를 간편하게 구현할 수 있는 로드 밸런서가 널리 사용된다.

 

 로드 밸런서는 다양한 구성 방식과 동작 모드를 제공하며, 이들에 따라 서비스 데이터 흐름과 패킷 처리 방식이 달라진다. 서비스 특성에 맞는 적절한 구성 방식과 동작 모드를 선택해야 하며, 이를 위해 각 방식의 특징과 고려 사항을 명확히 이해해야 한다. 로드 밸런서를 효과적으로 활용하려면 구성 및 동작 원리에 대한 이해가 필수적이며, 이를 통해 서비스 요구 사항에 최적화된 설정을 구현할 수 있다.

 

1. 부하 분산

- 단일 서버 구성의 한계와 문제점

 

 서비스 규모가 커지면서 물리적 또는 가상 서버 한 대로는 모든 사용자 요청을 처리하기 어렵다. 단일 서버로 서비스를 구성할 경우, 해당 서버의 애플리케이션, 운영체제, 하드웨어 등에 장애가 발생하면 서비스가 중단될 위험이 크다.

 이를 해결하기 위해 동일한 서비스를 제공하는 두 대 이상의 서버를 구성하여 서비스 가용성을 높이는 방식을 사용한다. 하지만 서버마다 서로 다른 IP 주소를 가지므로, 사용자가 요청을 보낼 때 특정 서버에 장애가 발생하면 일부 사용자에게 서비스 중단이 발생할 수 있다.

 

- 로드 밸런서를 활용한 부하 분산

로드 밸런서(Load Balancer)는 이러한 문제를 해결하는 핵심 장치이다.

 

• 기능: L4/L7 스위치 기반의 로드 밸런서는 동일한 서비스를 제공하는 다수의 서버를 등록하고, 사용자 요청을 받아 서버 간에 요청을 분산시킨다. 이를 통해 서비스의 부하를 분산하고 안정성을 확보한다.
• 작동 방식: 로드 밸런서는 사용자에게 가상 IP(VIP)를 제공하며, 사용자는 개별 서버 IP 대신 이 가상 IP를 통해 서비스에 접근한다.

 로드 밸런서는 등록된 서버의 상태를 실시간으로 확인하여 장애가 없는 서버로 요청을 전달하므로, 특정 서버에 장애가 발생해도 서비스는 지속된다.

 

- 방화벽 부하 분산(FireWall Load Balancing, FWLB)

FWLB(FireWall Load Balancing)는 서버 부하 분산(SLB)과 달리 방화벽 장비의 부하 분산을 위해 사용된다.

 

• 방화벽은 통과하는 패킷을 관리하기 위해 세션 테이블을 유지한다.
• 요청 패킷이 방화벽을 통과하면 정책을 확인한 뒤 허용된 패킷 정보를 세션 테이블에 기록한다. 이후 응답 패킷은 정책 확인 없이 세션 테이블을 통해 바로 처리된다.
• 문제점: 방화벽 이중화 환경에서, 네트워크 경로가 비대칭으로 설정되면 세션 테이블에 없는 응답 패킷이 발생할 수 있다. 이는 방화벽이 패킷을 공격으로 간주하여 폐기(Drop)할 가능성을 높인다.

- FWLB를 통한 방화벽 이중화 문제 해결

 

 FWLB는 세션 기반으로 트래픽을 분산하여 동일한 세션이 항상 같은 방화벽을 통과하도록 한다. 이를 통해 방화벽 이중화 시 발생하는 비대칭 경로 문제를 해결하고, 이중화된 방화벽을 모두 효율적으로 사용할 수 있다.

• 추가 설정: FWLB를 사용하는 경우에도 방화벽 간 세션 테이블을 동기화하거나, SYN 패킷이 아닌 첫 번째 패킷도 허용하도록 설정하여 장애 시 발생하는 세션 처리 문제를 보완해야 한다.

 

2. 부하 분산 방식 : 로드 밸런서를 활용한 서비스 분산 구조

 부하 분산(Load Balancing)은 하나의 서비스 요청을 여러 서버로 분산시켜 서버의 과부하를 방지하고, 서비스의 가용성과 성능을 향상시키는 기술이다. 로드 밸런서는 이를 위해 가상 IP(VIP, Virtual IP)와 실제 IP(Real IP, RIP)를 활용한다.

가상 IP(VIP)	서비스 접근을 위해 외부에 제공되는 단일 IP 주소로, 사용자 요청은 VIP로 전달됨. VIP는 로드 밸런서에서 관리되며, 실제 서비스 제공 서버를 나타냄.
실제 IP(RIP)	각 서버가 가지는 고유의 IP 주소로, VIP와 매핑되어 사용자 요청을 처리함. 로드 밸런서는 VIP로 들어온 요청을 적절한 RIP로 분배함.

 

- VIP와 RIP 구조

 예를 들어, 3대의 서버가 다음과 같은 RIP를 가진다.

서버 번호	IP 주소	서비스 종류
Server 1	10.10.20.11	HTTP
Server 2	10.10.20.12	HTTP, HTTPS
Server 3	10.10.20.13	HTTPS

 

 

VIP는 10.10.10.1로 설정되어 있고, 사용자는 이 VIP를 통해 서비스를 요청한다.

• HTTP 서비스 : 서버 1번과 2번에서 처리
• HTTPS 서비스 : 서버 2번과 3번에서 처리

로드 밸런서는 각 요청을 적절한 RIP로 분배해 부하를 분산시킨다.

 

- 포트 기반 분산

 

• 서비스 포트 매핑 : VIP와 RIP의 서비스 포트는 서로 다르게 설정 가능하다.
  
  • VIP: HTTP 서비스 포트 80
  • RIP: 실제 서버의 HTTP 포트 8080
  사용자는 VIP의 80 포트를 통해 접근하고, 로드 밸런서는 이를 실제 서버의 8080으로 매핑한다.
• VIP와 포트 설정 확장성 : HTTP와 HTTPS와 같은 다른 서비스 간에 VIP를 분리해 설정하거나, VIP 내에서 포트 간 설정을 세부적으로 구성할 수 있다.

 

- 부하 분산 그룹과 OSI 계층

 

• 그룹 생성 : 부하 분산 그룹은 IP(OSI 3계층)와 서비스 포트(OSI 4계층) 정보를 기반으로 설정된다.
• L4 및 L7 로드 밸런서
  • L4 스위치: OSI 4계층(전송 계층)에서 서비스 포트를 기준으로 부하를 분산한다.
  • L7 스위치: OSI 7계층(애플리케이션 계층)에서 세부적인 콘텐츠 분석을 기반으로 부하를 분산한다.

 

- 로드 밸런서를 통한 서비스 가용성 강화

 부하 분산은 서비스 요청을 효과적으로 처리할 뿐만 아니라 장애 발생 시 특정 서버로의 요청을 자동으로 다른 서버로 전환하여 서비스 중단을 최소화한다.

 

 이를 통해 대규모 트래픽 관리, 서비스 연속성 유지, 유연한 인프라 확장이 가능하다.

 

3. 헬스 체크

 로드 밸런서에서 헬스 체크는 서비스 안정성을 유지하기 위해 서버의 상태를 주기적으로 점검하는 중요한 기능이다. 장애가 발생한 서버를 서비스 그룹에서 제외하고, 정상 상태로 복구되면 다시 그룹에 포함하여 트래픽을 분산한다.

 

- 헬스 체크 방식

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

 

• ICMP : 서버에 ICMP 패킷을 전송하여 서버가 응답하는지 확인하는 가장 기본적인 방식이다. 이 방식은 서버의 단순한 생존 여부만 확인하며, 네트워크 연결 상태를 확인하는 데 유용하지만, 서비스의 정상 작동 여부는 확인할 수 없어 실제 서비스 환경에서는 잘 사용되지 않는다.

 

• TCP 서비스 포트를 통한 헬스 체크 : 설정된 서버의 특정 포트에 대해 TCP 연결을 시도하여 상태를 확인하는 기본적인 방식이다. 로드 밸런서는 설정된 포트에 SYN 패킷을 전송하고, 서버가 SYN-ACK로 응답하면 ACK 및 FIN으로 세션을 종료한다. 이 방식은 실제 서비스 포트뿐만 아니라 다른 포트로도 상태를 확인할 수 있어 유연성이 있다.

 

• TCP 서비스 포트 - Half Open : 일반 TCP 헬스 체크에서 사용되는 3-way handshake와 4-way handshake를 간소화한 방식이다. 로드 밸런서는 서버에 SYN 패킷을 전송하고, 서버로부터 SYN-ACK를 수신한 후 ACK 대신 RST를 보내 세션을 종료한다. 이 방식은 헬스 체크로 인한 서버 부하를 줄이고, 빠르게 상태를 확인할 수 있다는 장점이 있다.

 

• HTTP 상태 코드 : HTTP 요청을 전송하여 서버가 반환하는 상태 코드를 확인한다. TCP 연결이 정상적으로 이루어졌더라도 HTTP 응답이 비정상적인 경우를 탐지할 수 있어, 특히 웹 서비스에서 유용하다. 서버가 200 OK 상태 코드를 반환하면 정상으로 판단되며, 이를 통해 서비스 상태를 세밀하게 확인할 수 있다.

 

• 콘텐츠 확인(문자열 확인) : 로드 밸런서가 특정 웹페이지를 호출하고, 응답받은 내용에서 사전에 지정한 문자열이 포함되어 있는지를 확인한다. 이 방식은 웹 서버뿐 아니라 백엔드(WAS, DB 등)의 상태까지 함께 확인할 수 있어 서비스 전반의 상태 점검에 효과적이다. 다만, 비정상적인 응답에 지정 문자열이 포함될 경우 정상으로 오인할 가능성이 있으므로, 정상 상태 코드와 함께 확인하는 것이 중요하다.

 

- 헬스 체크 주기와 타이머

 헬스 체크는 주기(Interval), 응답 시간(Response Time), 시도 횟수(Retries), 타임아웃(Timeout) 등 다양한 타이머 설정을 통해 조정된다.

주기(Interval)	로드 밸런서에서 서버로 헬스 체크 패킷을 보내는 주기
응답 시간(Response)	로드 밸런서에서 서버로 헬스 체크 패킷을 보내고 응답을 기다리는 시간 해당 시간까지 응답이 오지 않으면 실패로 간주
시도 횟수(Retries)	로드 밸런서에서 헬스 체크 실패 시 최대 시도 횟수 최대 시도 횟수 이전에 성공 시 시도 횟수는 초기화됨
타임아웃(Timeout)	로드 밸런서에서 헬스 체크 실패 시 최대 대기 시간 헬스 체크 패킷을 서버로 전송한 후 이 시간 내에 성공하지 못하면 해당 서버는 다운
서비스 다운 시의 주기 (Dead Interval)	서비스의 기본적인 헬스 체크 주기가 아닌, 서비스 다운 시의 헬스 체크 주기 서비스가 죽은 상태에서 헬스 체크 주기를 별도로 더 늘릴 때 사용

 

 

 헬스 체크 주기와 타이머는 로드 밸런서가 서버의 상태를 모니터링하는 중요한 요소이다. 헬스 체크는 주기적인 패킷 전송과 응답을 기반으로 동작하며, 서버의 정상 상태 여부를 판단한다.

 

 헬스 체크 주기 시간은 로드 밸런서가 서버로 헬스 체크 패킷을 보내는 간격을 의미한다. 예를 들어 주기가 3초로 설정되었다면, 로드 밸런서는 3초마다 서버로 패킷을 전송하며, 이 간격을 유지한다. 주기 설정은 서비스 상태를 자주 확인할지, 서버 부하를 줄일지를 결정짓는 중요한 요소이다.

 

 응답 시간은 로드 밸런서가 서버의 응답을 기다리는 최대 시간이다. 설정된 시간 내에 응답을 받지 못하면 해당 헬스 체크 시도는 실패로 간주된다. 예를 들어, 응답 시간이 1초로 설정되었다면, 헬스 체크 패킷 전송 후 1초 안에 서버의 응답이 도착해야 한다. 주의할 점은 헬스 체크 주기가 응답 시간보다 길게 설정되어야 원활한 동작이 가능하다는 것이다.

 

 서버 응답 실패 시, 로드 밸런서는 정해진 시도 횟수만큼 헬스 체크를 재시도한다. 모든 재시도에서 실패할 경우 해당 서버는 서비스가 다운된 것으로 간주되며, 트래픽 분산 대상에서 제외된다. 이 과정은 헬스 체크 주기, 응답 시간, 시도 횟수 또는 전체 타임아웃 시간으로 관리된다.

 

 다운된 서비스에 대해 일부 로드 밸런서는 기본 주기 대신 더 긴 주기로 헬스 체크를 수행하는 기능을 제공한다. 이는 서버 부하를 줄이는 데 유리하지만, 서비스 복구 여부를 확인하는 주기가 늘어나 복구 시점이 지연될 수 있다는 단점이 있다. 이러한 설정은 서비스 안정성과 복구 속도 간의 균형을 고려하여 조정된다.

 

 헬스 체크 관련 타이머 값은 장애 발생 시 서비스 중단 시간에 직접적인 영향을 미치므로, 각 타이머가 헬스 체크에서 어떻게 동작하는지 명확히 이해하는 것이 중요하다. 예를 들어, 헬스 체크 주기, 응답 시간, 시도 횟수 등의 설정은 장애를 인지하고 복구 상태를 판단하는 데 걸리는 시간을 결정한다. 이 값들이 적절하지 않으면 장애 인지나 복구 지연으로 인해 서비스 품질이 저하될 수 있다. 따라서 헬스 체크 타이머를 설정할 때 서비스의 안정성과 복구 속도를 모두 고려한 균형 잡힌 설정이 필요하다.

 

 

 

 로드 밸런서를 활용하면 부하를 효과적으로 분산시켜 서버 과부하를 방지하고, 서비스의 가용성과 성능을 향상시킬 수 있다. 또한, 헬스 체크를 통해 서비스의 안정성을 강화하고, 장애 발생 시에도 빠르게 대응할 수 있는 이점이 있다.