[아키텍처] 로드밸런싱 완전 정복: L4/L7 구조부터 SPOF 해결까지

🌏 로드 밸런싱

대규모 트래픽을 다루는 모든 서비스에서 로드 밸런서는 필수적입니다.

 

✅ 개념

여러 대의 서버로 들어오는 요청을 균등하게 분산시켜 전체 시스템의 안정성과 처리량을 높이는 기술

 

 

대규모의 트래픽을 다루기 위해서는 단순히 서버 여러 대를 늘리는 것만으로는 충분하지 않고, 부하를 지능적으로 분배하고 장애를 격리하는 구조가 필요합니다.

 

이때 중앙에서 분산을 담당하는 장치나 소프트웨어가 바로 로드 밸런서(Load Balancer)입니다.

로드 밸런서는 크게 두 가지 역할을 수행합니다.

 

 

1) 트래픽 분산

여러 대의 서버 중 한 곳에 요청이 몰리지 않도록 요청을 골고루 나누는 역할입니다.

덕분에 서버 과부하를 막고, 수평 확장을 통해 전체 처리량을 늘릴 수 있습니다.

 

2) 장애 감지 및 격리(Health Check)

어떤 서버가 느려지거나 장애가 나면 그 서버로 요청을 보내지 않고 자동으로 제외합니다.

이를 통해 서비스 전체가 다운되지 않도록 고가용성(HA)을 유지합니다.

 

 

특히 대규모 트래픽 환경에서는 로드 밸런서가 전체 시스템의 관문(Gateway) 역할을 하기 때문에, 어떤 계층(L4/L7), 어떤 알고리즘, 어떤 헬스 체크 정책을 사용하느냐에 따라 시스템의 성능과 안정성이 크게 달라집니다.

 

순간적으로 트래픽이 폭증하는 상황에서는, 로드 밸런서가 요청을 적절히 분해하지 못하면 서버는 버티고 있어도 전체 서비스가 느려지거나 중단될 수 있습니다.

 

 

✅ L4 vs L7 Load Balancer

OSI 7계층에서 4계층 전송계층 기반인지, 7계층 애플리케이션 계층 기반인지에 따라서 로드밸런서는 2가지로 나뉩니다.

L4 로드 밸런서는 TCP/UDP 수준의 정보(IP, Port)만 보고 트래픽을 분산합니다. 패킷 내부의 실제 내용을 읽지 않기 때문에 아주 빠르게 동작합니다.

 

반면, L7 로드 밸런서는 HTTP 헤더, URL, 쿠키, Path까지 읽어 요청의 의미를 분석하고 클라이언트의 요청을 더더 세분화해서 처리할 수 있습니다.

 

L4 (Transport Layer)

• 라우팅 기준: IP, Port
• 장점: 매우 빠름, 부하 적음
• 단점: URL 기반 라우팅 등 고급 기능 불가

L7 (Application Layer)

• 라우팅 기준: HTTP Header, Path, Cookie 등
• 장점: 정교한 라우팅, A/B 테스트, 인증 기반 라우팅 가능
• 단점: 상대적으로 비용과 처리 부하 증가

 

예를 들어 /static처럼 정적 파일 요청을 CDN으로 넘기고, /api/order는 주문 서비스로 분기하는 식의 라우팅은 L7 LB에서만 가능합니다.

 

서비스 구조가 단순하고 속도가 우선이라면 L4, 정교한 서비스 분기나 인증 처리가 필요하다면 L7을 선택하는 것이 합리적입니다.

 

🌏 로드 밸런싱 알고리즘

로드 밸런서가 트래픽을 여러 개의 서버로 분산할 때의 알고리즘은 여러 가지가 있습니다.

 

✅ Round Robin

 

요청을 서버 리스트 순서대로 순환 분배합니다. 그냥 순서대로 서버1, 서버2, 서버3, … 서버1, 서버2,,,.. 이렇게 분배합니다. 별도의 연산은 필요하지 않으니 구현 간단, 성능 빠름이 장점입니다.

다만 서버별 부하 차이를 고려하지 못하기 때문에 모든 서버의 스펙이 동일하거나 비슷할 때 장점을 가지는 방법입니다.

 

✅ Weighted Round Robin

 

가중 라운드 로빈은 위의 그냥 라운드로빈이 모든 서버에 가중치가 1로 분배했다면, 다른 가중치를 가지게 되는 경우 더 많은 요청을 받을 수 있도록 하는 방법입니다. 일부 서버의 스펙이 더 좋다면 더 많은 요청을 받도록 할 수 있습니다.

 

✅ Least Connection

 

현재 ‘연결 수’가 가장 적은 서버로 라우팅하는 방법으로, 긴 처리 시간을 가진 요청(I/O 작업)에 유리합니다. 하지만 LB가 모든 서버 상태를 추적해서 몇개의 연결 수가 현재 있는지 판단해야 하므로 오버헤드 증가할 수 있습니다.

 

✅ IP Hash

 

클라이언트 IP를 해싱해 특정 서버에 고정하는 방법으로, 세션 Sticky가 필요한 레거시 환경에서 사용합니다. 지역/ISP 편중 시 특정 서버로 쏠림이 발생할 수 있습니다.

 

 

어떤 경우에 어떤 방법을 쓰는게 좋을까요?

예를 들어 웹소켓처럼 연결 유지 시간이 긴 트래픽은 Round Robin보다 Least Connection이 훨씬 안정적입니다. 반대로 사용자 세션을 서버 메모리에 저장하는 레거시 시스템이라면 IP Hash 기반으로 세션 고정을 해야 합니다.

 

🌏 헬스 체크

로드 밸런서는 서버의 상태를 실시간으로 감지하고, 문제가 생긴 서버를 자동으로 트래픽 대상에서 제외합니다. 이를 Health Check라고 합니다.

 

 

L4 Health Check

• TCP Port가 열려 있는지만 확인
• 빠르고 단순하지만, 애플리케이션이 죽었는데 포트만 열려 있는 경우를 걸러내지 못함

L7 Health Check

• HTTP 요청을 서버로 전송해 상태코드(200), 응답 시간 체크
• /health, /actuator/health 등을 많이 사용
• DB, Redis 등 외부 의존성을 함께 검사하도록 구성 가능

 

예를 들어 애플리케이션 스레드가 모두 막혀도 TCP 포트는 살아 있기 때문에 L4 헬스 체크는 정상이라 판단할 수 있습니다. 이런 문제는 반드시 L7 Health Check에서만 잡아낼 수 있습니다. 현대 시스템에서는 대부분 L7 헬스 체크가 기본입니다.

 

🌏 로드밸런서가 SPOF가 된다

✅ SPOF(Single Point of Failure)

로드 밸런서 자체가 죽으면 서비스 전체가 중단됩니다.

이렇게 하나가 죽었을 때 서비스 전체가 중단되는 것을 SPOF(Single Point of Failure)라고 하며, 실제 장애 복구 사례에서 가장 자주 언급되는 지점입니다.

 

✅ 해결 방법 1: LB 이중화

Active-Active 구조

• 두 개 이상의 로드 밸런서가 동시에 트래픽을 처리하는 방식
• 외부 클라이언트는 DNS 또는 상위 LB를 통해 두 LB 중 하나로 연결됨
• 각각이 독립적으로 Health Check를 실행하며, 둘 중 하나가 장애 나면 정상 LB만 계속 요청을 처리
• Load Balancer 자체에도 부하가 있으므로, Active-Active는 성능·확장성·가용성 모두 확보하는 구조
• 예시
  • AWS에서는 ALB/NLB 자체가 여러 AZ로 Active-Active 구성
  • On-premise 환경에서는 HAProxy 2대 또는 Nginx 2대를 Active-Active로 구성

Active-Standby 구조

• Active LB가 모든 트래픽을 처리하고, Standby LB는 대기 상태로 있으면서 Active LB를 감시
• Active가 장애 나면 Standby가 즉시 역할을 인계(failover)
• 비용은 절감되지만, Standby는 평소 트래픽을 처리하지 않아 리소스 낭비 요소가 있고 전환 시 아주 약간의 지연이 발생할 수 있음
• 예시
  • Keepalived + Nginx 조합으로 Active-Standby 구성
  • VRRP 기반으로 Virtual IP를 Standby가 takeover

 

 

✅ 해결 방법 2: VIP(가상 IP) Floating

여러 대의 LB가 하나의 Virtual IP(가상 IP)를 공유하고, 현재 Active LB만 이 IP를 사용합니다. 클라이언트는 Virtual IP만 알고 있기 때문에, Active LB가 어떤 물리 서버인지 알 필요 없습니다.

1. Active LB가 Virtual IP를 보유하고 있음
2. Keepalived/VRRP 프로토콜이 Active LB의 상태를 지속적으로 감시
3. Active LB가 장애 나면
   • Standby LB가 즉시 Virtual IP를 인계(ARP 갱신)
   • 클라이언트는 같은 IP로 계속 접속 가능
   • 서비스는 거의 끊기지 않음

장점

• LB 교체 전환(failover)이 매우 빠름
• 서비스 접근 IP가 바뀌지 않아 운영이 단순해짐
• 내부망 로드 밸런싱에서 특히 많이 쓰임(Nginx, HAProxy)

단점

• VIP는 동일 네트워크 내에서만 부동(floating)이 가능 (Cross-region, Cross-AZ는 불가)

 

 

 

✅ 해결 방법 3: Multi-AZ 구성

개념

• 클라우드(AWS/GCP/Azure)에서는 LB 자체가 멀티 AZ로 구성될 수 있고, LB 뒤의 서버(ECS/EC2/EKS/POD)도 각각 여러 AZ에 분산됩니다.
• AZ 장애는 흔치 않지만(AWS를 믿고 가자,,?), 발생하면 전체 서비스가 정지되는 치명적 장애로 이어질 수 있습니다.

동작 방식

• LB가 여러 AZ에 걸쳐 네트워크 인터페이스를 생성
• 각 AZ에 배치된 서버들을 모든 AZ의 LB가 동시에 Health Check
• 특정 AZ가 장애 나면
  1. LB가 그 AZ의 모든 서버를 unhealthy로 판단
  2. 트래픽은 자동으로 다른 AZ로 전환
  3. 서비스 전체는 정상 유지

장점

• 서버뿐 아니라 로드 밸런서 자체의 가용성까지 확보
• 단일 데이터센터 수준 장애에도 생존 가능
• 클라우드에서는 사실상 기본(Standard)

단점

• 네트워크 비용 증가 (특히 cross-AZ data transfer)
• 인프라 구성이 복잡해질 수 있음

 

 

 

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!