HAProxy vs AWS ALB

유정빈·2026년 5월 29일

"고양 IDC 온프레미스 환경에서 직접 구축한 HAProxy 설정 파일과 AWS ALB의 클라우드 리소스를 1:1로 매핑하여 L7 로드밸런싱의 원리와 아키텍처적 차이를 깊이 있게 분석합니다."

1. 개요

네트워크 트래픽이 집중되는 현대의 웹 아키텍처에서
로드밸런서(Load Balancer)는 고가용성(HA)과 단일 진입점(Single Point of Entry)을 제공하는 핵심 컴포넌트입니다.
클라이언트의 요청을 대리 수신하여 백엔드 서버 그룹으로 지능적으로 분산해 주는 프록시(Proxy) 메커니즘은 서비스 안정성을 유지하는 핵심 장치입니다.

저는 최근 두 가지 극명하게 다른 환경에서 로드밸런싱 아키텍처를 직접 구축해 볼 기회가 있었습니다.

  1. 온프레미스 환경 (Goyang IDC): 사설 네트워크 대역 내에서 오픈소스 소프트웨어인 HAProxy를 직접 리눅스 OS 상에 설치하고 설정 파일(haproxy.cfg)을 수정하여 Nginx 서버들을 로드밸런싱하는 인프라를 실습했습니다.
  2. 퍼블릭 클라우드 환경 (AWS): 완전 관리형 L7 로드밸런싱 서비스인 ALB(Application Load Balancer)를 프로비저닝하여 ECS Fargate 기반의 컨테이너 환경으로 유입되는 대규모 트래픽을 분산하고 무중단 배포를 실습했습니다.

두 인프라는 구축 방식과 환경이 완전히 달랐지만, 트래픽을 분산하고 제어하는 근본 원리는 동일했습니다.

이 글에서는 HAProxy의 파일 기반 설정 파일 옵션들과 AWS ALB 콘솔의 시각적인 리소스들이 어떻게 L7 수준에서 1:1로 매핑되는지 상세히 비교 분석해 봅니다.

2. 두 가지 실습 환경 아키텍처 비교

본격적인 비교에 앞서, 직접 구현했던 두 인프라의 아키텍처와 트래픽 흐름도를 살펴보겠습니다.

2.1. Goyang IDC HAProxy 아키텍처 (온프레미스)

  • 네트워크 접속: 외부 관리자가 WireGuard VPN 보안 터널을 통과하여 내부 사설망 대역(192.168.1.0/24)에 접속합니다.
  • 로드밸런서 노드: 사설 IP 192.168.1.172를 할당받은 haproxy-lb 노드에 HAProxy 데몬이 구동되어 클라이언트의 유일한 접속 창구가 됩니다.
  • 백엔드 서버: 이중화된 Nginx 기반 웹서버 ha-web-01 (192.168.1.185) 및 ha-web-02 (192.168.1.228) 노드로 트래픽을 분산합니다.

2.2. AWS ALB 및 ECS Fargate 아키텍처 (클라우드)

  • 네트워크 접속: 외부 인터넷 브라우저에서 퍼블릭 인터넷 망을 통해 AWS VPC의 퍼블릭 서브넷에 위치한 ALB(Application Load Balancer)의 80 포트로 직접 접속합니다.
  • 로드밸런서 노드: Multi-AZ 가용 영역에 자동 분산 배치된 AWS ALB가 외부 요청을 수신합니다.
  • 백엔드 서버: 프라이빗 서브넷에서 실행되는 ECS Fargate 태스크 컨테이너들의 동적 IP로 트래픽을 라우팅합니다.

3. L7 로드밸런싱 컴포넌트 1:1 매핑 분석

텍스트 기반의 코드 지시어로 인프라를 직접 빌드해야 하는 HAProxy와 달리, AWS ALB는 웹 콘솔 대시보드 UI를 통해 각 기능이 독립적인 리소스 컴포넌트로 분할되어 제공됩니다. 두 로드밸런서의 핵심 설정 요소를 1:1로 비교해 보겠습니다.

로드밸런서 컴포넌트 매핑표

로드밸런싱 역할HAProxy (haproxy.cfg)AWS ALB (AWS Console)
외부 진입점 (포트 개방 및 프로토콜 정의)frontend 섹션Listener (리스너)
라우팅 제어 규칙 (HTTP 헤더, 경로 등 조건 검사)acl 정의 & use_backend 분기Listener Rules (리스너 규칙)
목적지 서버 그룹 (트래픽 분산 대상 논리 그룹)backend 섹션Target Group (대상 그룹)
실제 대상 서버 (트래픽 수신 대상 노드)server 목록 및 정적 IPRegistered Targets (등록된 대상)
상태 검사 (장애 감지 및 노드 격리)check 옵션 (inter, rise, fall)Health Check (상태 검사 설정)

(1) 진입점 구성 (클라이언트 프론트엔드 접점)

로드밸런서가 트래픽을 수신하기 위해서는 가장 먼저 특정 포트를 바인딩하고 대기(Listen) 상태를 유지해야 합니다.

HAProxy (frontend)

frontend http_front
    bind *:80
    default_backend web_servers
  • 동작 방식:

    frontend 섹션을 통해 OS 소켓 단에서 bind *:80으로 포트를 열고 트래픽을 기다립니다.

    만약 HTTPS(443) 보안 포트를 열기 위해서는 SSL 인증서 파일들을 결합하여 서버 내부 경로에 직접 위치시킨 후, bind *:443 ssl crt /etc/ssl/private/haproxy.pem 형태로 복잡한 경로 지정을 명시해야 합니다.

AWS ALB (Listener)

  • 동작 방식:

    AWS ALB에서는 이를 리스너(Listener)라는 컴포넌트가 담당합니다.

    콘솔에서 로드밸런서 생성 시 프로토콜(HTTP/HTTPS)과 포트 번호(80/443)를 설정함으로써 간편하게 바인딩할 수 있습니다.

    특히 HTTPS를 연결할 때는 ACM(AWS Certificate Manager)과의 연동을 통해 수동 갱신이나 키 파일 경로 업로드 작업 없이 손쉽게 SSL/TLS 터미네이션을 처리할 수 있는 점이 돋보입니다.

(2) 라우팅 규칙 (L7 레이어의 패킷 조건 분기)

L7 로드밸런서는 패킷 내부의 HTTP 헤더 정보나 URL 경로를 파싱하여 다른 백엔드 서버 그룹으로 트래픽을 정교하게 흐르게 할 수 있습니다.

HAProxy (acl 및 use_backend)

frontend http_front
    bind *:80
    # X-Beta-User 헤더 값에 "true"가 포함되어 있는지 대소문자 구분 없이(-i) 검사
    acl is_beta hdr(X-Beta-User) -i true
    
    # 조건 만족 시 beta_server 백엔드 그룹으로 전달
    use_backend beta_server if is_beta
    # 기본 전송 목적지
    default_backend web_servers
  • 동작 방식:

    acl 키워드를 사용해 HTTP 헤더의 키와 값 조건을 지정하고,
    use_backend에 조건절(if >is_beta)을 붙여 특정 백엔드 목적지로 전달합니다.
    가독성은 떨어지기 쉬우나 정규식을 동원하여 매우 미세한 세그먼트 라우팅 제어가 가능합니다.

AWS ALB (Listener Rules)

  • 동작 방식:

    ALB에서는 리스너 규칙(Listener Rules)을 이용해 콘솔에서 시각적으로 HTTP 조건 분기를 설계합니다.

    HTTP 경로 패턴, 호스트 헤더, HTTP 헤더 키/값, 쿼리 스트링, 소스 IP 대역 등을 조건(Condition) 목록에서 마우스 클릭만으로 추가할 수 있습니다.
    특히 특정 대상 그룹들로 트래픽을 가중치 비율(예: 80% vs 20%)로 섞어 전송하는 기능이 기본 제공되어 Canary 배포나 가중치 기반 분기를 손쉽게 처리할 수 있습니다.

(3) 목적지 논리 그룹 (서버 분산 정책 및 묶음)

트래픽의 최종 목적지가 되는 실제 웹 서버 노드들을 하나의 가상 논리 풀(Pool)로 관리하는 단계입니다.

HAProxy (backend)

backend web_servers
    balance roundrobin
    server web01 192.168.1.185:80 check weight 9
    server web02 192.168.1.228:80 check weight 1
  • 동작 방식:

    backend 섹션 내부에서 balance roundrobin 또는 balance leastconn 등의 분산 알고리즘을 선언합니다.

    하위에 등록할 실제 물리 서버(Nginx 웹 서버 등)의 정적 사설 IP와 포트 번호를 일일이 타이핑하여 정적으로 등록합니다.

AWS ALB (Target Group)

  • 동작 방식:

    AWS ALB에서는 대상 그룹(Target Group)이라는 완전히 별개의 독립된 AWS 리소스로 동작합니다.

    가장 큰 차별점은 동적 IP 자동 변경 추적입니다.
    온프레미스 HAProxy는 백엔드 서버의 사설 IP가 변경될 경우 설정 파일의 코드를 고치고 데몬을 리로드해야 합니다.

    반면, AWS 대상 그룹은 ECS Fargate나 Auto Scaling Group과 연계되어 스케일 아웃/인되거나 컨테이너가 재생성되며 IP가 실시간으로 바뀔 때에도 AWS API를 통해 새로운 IP 주소를 자동으로 추적 및 갱신해 줍니다.

(4) 실시간 상태 검사 (Health Check & Failover)

로드밸런서는 백엔드 목적지 노드들의 생존 여부를 주기적으로 체크하여, 장애가 감지된 비정상 서버를 트래픽 분산 대상에서 신속하게 격리해야 합니다.

HAProxy (server check)

backend web_servers
    balance roundrobin
    # inter 3s: 3초 주기 상태 확인
    # rise 2: 2회 연속 정상 시 복귀
    # fall 3: 3회 연속 실패 시 장애 격리
    server web01 192.168.1.185:80 check inter 3s rise 2 fall 3
  • 동작 방식:

    개별 server 지시어 마지막에 check 옵션을 명시하고 주기를 제어합니다.

    만약 백엔드 웹 서버 데몬이 비정상 종료되어 다운스트림 노드와 통신이 두절될 경우, HAProxy는 즉시 해당 서버를 분산 풀에서 격리합니다.
    이를 설정하지 않으면 사용자는 한쪽 서버의 장애 상황에서 간헐적인 로딩 실패와 웹페이지 에러 화면을 마주하게 됩니다.

AWS ALB (Target Group Health Check)

  • 동작 방식:

    대상 그룹의 속성 탭에서 상태 검사(Health Checks) 경로(예: / 또는 /health) 및 임계값(Threshold)을 조절합니다.

    설정에 실패하여 대상 컨테이너가 Unhealthy로 판명될 경우, AWS 콘솔 상에 즉시 붉은색 알람이 발생하며 ALB 단에서 에러 노드로의 연결 라우팅을 강제로 차단하고 502/503 에러로의 우회를 사전에 차단합니다.
    CloudWatch 지표 및 AWS CLI를 통해 타겟 그룹의 가용 노드 개수를 실시간 모니터링하기가 온프레미스 서버보다 월등히 편리합니다.

4. 실무 관점에서의 장단점 비교

직접 고양 IDC 환경에서 명령줄 인터페이스(CLI) 기반으로 설정 파일을 작성해 보고, AWS 클라우드 콘솔 환경에서 마우스 클릭과 인프라 프로비저닝을 연동해 보며 느낀 장단점이 각각 있었습니다.

4.1. HAProxy (Onpremise LoadBlancer)

요약: 세밀한 성능 최적화와 완벽한 내부 제어권을 얻는 대신, 이중화 구성과 모니터링 체계를 온전히 스스로 짊어져야 합니다.

  • 장점:
    1. 극한의 세부 제어와 튜닝: 소켓 버퍼 크기, TCP 타임아웃, 커넥션 큐 처리 등 커널 및 프록시의 깊은 지점까지 최적화할 수 있습니다.
    2. 경제성: 트래픽 총량이나 동시 커넥션 누적에 따른 부가 과금(LCU 등)이 전혀 없습니다. 하드웨어 물리 서버 성능 한도 내에서 비용 부담 없이 무료 오픈소스를 무한히 활용할 수 있습니다.
    3. 낮은 지연 시간: 하드웨어 가상화 계층을 거치지 않는 베어메탈 물리 서버 위의 단독 구동 시 패킷 처리 오버헤드가 극히 적습니다.
  • 단점:
    1. 단일 장애점(SPOF) 리스크: 로드밸런서 서버(haproxy-lb)가 하드웨어 결함 등으로 죽어버리면 전체 웹 서비스가 즉시 먹통이 됩니다.
    2. 이중화 구현의 난이도: 이를 피하기 위해 상단에 VRRP 프로토콜 기반의 Keepalived 데몬을 함께 엮어 가상 IP(Virtual IP)를 분배하는 Active-Standby 고가용성 네트워크 설계를 수동으로 전부 완료해야 합니다.

4.2. AWS ALB (Cloud Native Managed L7)

요약: Multi-AZ 이중화 인프라와 컨테이너 동적 결합을 마우스 클릭 한 번으로 제공받는 대신, 클라우드 종속 비용을 감수해야 합니다.

  • 장점:
    1. 기본 탑재된 고가용성(HA): ALB 생성 단계에서 복수의 서브넷(Multi-AZ)을 선택해 주기만 하면, AWS 측에서 서로 다른 물리 데이터 센터 내에 이중화된 로드밸런서 가상 노드를 자동으로 다중 배치하여 단일 장애점 우려를 완벽히 지워줍니다.
    2. 자동 스케일링: 블랙프라이데이 등 트래픽이 폭주할 경우, 엔지니어가 시스템 성능 로그를 관찰하며 인프라를 증설하지 않아도 클라우드가 내부적으로 ALB 처리 용량을 자동으로 유연하게 확장(Scale-out)해 줍니다.
    3. 강력한 통합 생태계: ACM(인증서), Route 53(DNS), ECS Fargate(컨테이너), WAF(보안 방화벽) 등 유관 서비스와의 간편한 콘솔 내 파이프라인 결합은 실무자의 퇴근 시간을 극적으로 당겨줍니다.
  • 단점:
    1. 지속적인 누적 비용 청구: 실행 유지 시간 비용뿐만 아니라 데이터 처리 크기와 동시 커넥션을 평가하는 LCU(Load Balancer Capacity Units) 비용 기준에 비례하여 인프라 비용 청구서가 계속 불어납니다.
    2. 동작 방식의 블랙박스화: LB 내부 OS나 네트워크 버퍼 튜닝 등에 일절 관여할 수 없으며, 예기치 않은 로드밸런싱 먹통 시 AWS 내부 상태 페이지가 정상화되기를 무기력하게 대기해야 하는 상황이 발생할 수 있습니다.
profile
유정빈
cloud
이전 포스트

AWS EC2 Blue/Green CI/CD, CI/CD Pipline

다음 포스트

[OS 2편] CPU 스케줄링과 big.LITTLE 구조

0개의 댓글