#Infra #Proxy #개념

HAProxy(High Availability Proxy) 는 이름 그대로 고가용성(High Availability) 을 강조하는 리버스 프록시 + 로드 밸런서 오픈소스 소프트웨어야.

즉, 우리가 앞에서 설명한 프록시의 한계(예: 단일 장애 지점, 성능 저하)를 극복하기 위해 나온 대표적인 솔루션 중 하나라고 보면 돼.

1. 역할

리버스 프록시 기능

외부 사용자의 요청을 받아 내부 여러 서버로 전달 (보안, SSL 종료, 캐싱 지원).
로드 밸런서 기능

다양한 알고리즘(라운드 로빈, Least Connections, 소스 IP 해시 등)으로 트래픽을 여러 서버에 분산.
고가용성 제공

서버 장애 시 자동으로 다른 정상 서버로 요청을 넘겨줌.

2. 왜 쓰는가?

앞서 말한 리버스 프록시 단점 시나리오를 해결하기 위해 도입되는 경우가 많아.

단일 실패 지점(SPOF) → 해결

→ HAProxy는 클러스터링과 이중화 구성을 지원.
성능 저하 문제 → 해결

→ C 수준에서 구현된 고성능 엔진, 수십만 동시 연결 처리 가능.
로드밸런싱 오류 → 예방

→ 백엔드 서버에 대한 헬스 체크 내장.
인증서 관리

→ SSL/TLS 종료를 지원하여 웹 서버 부담을 줄여줌.

3. 대표 사용 사례

대형 웹 서비스 프런트엔드: 웹 트래픽을 다수의 웹 서버로 분산.
API 서버 게이트웨이 전 단계: 트래픽 라우팅 및 보안 강화.
마이크로서비스 환경: Kubernetes Ingress Controller 대체로 쓰이기도 함.
보안 게이트웨이: IP 차단, 제한적 DDoS 방어.

4. 다른 기술과 비교

포워드 프록시: 주로 내부망 제어용 (예: Squid)
리버스 프록시: 서버 보호/로드 분산 (예: Nginx, Apache mod_proxy)
HAProxy: 리버스 프록시의 한계를 고성능·고가용성으로 해결한 전문 솔루션

1) 구조 비교 다이어그램

A. HA 미구성(단일 장애 지점 존재)

[사용자]
   │
   ▼
[리버스 프록시/로드밸런서]  ← 단일 인스턴스(SPOF)
   │
   ├── [웹/앱1]
   └── [웹/앱2]

프록시/로드밸런서가 죽으면 전체 서비스 다운.
백엔드가 여러 대여도, 앞단 한 대가 병목/장애 지점.

B. HA 구성(이중화 + 헬스체크 + 자동 우회)

(DNS/Anycast/가상 IP/게이트웨이)
[사용자] ─────────────────────────────────────►
        ┌───────────────┬───────────────┐
        ▼               ▼               ▼
 [LB/프록시-A]   <HB>  [LB/프록시-B]   (선택적으로 GSLB)
        │  \            /  │
        │   └─ 동기/상태공유 ┘
        │
        ├──(헬스체크)──► [웹/앱1]
        ├──(헬스체크)──► [웹/앱2]
        └──(헬스체크)──► [웹/앱3]

LB/프록시를 2대 이상(Active-Active 또는 Active-Standby).
헬스체크로 죽은 백엔드는 자동 제외.
프런트 진입점은 Route53(다중 값, 헬스체크), Anycast, 가상 IP(Failover) 등으로 끊김 최소화.

2) 트래픽 흐름(장애 시나리오)

미구성(단일 LB 장애)

사용자 → LB 단일 노드 다운
접속 실패 (백엔드는 정상이어도 무의미)

HA 구성(프런트 LB 이중화)

사용자 → LB-A 다운 발생
HB(Heartbeat)/헬스체크가 감지 → LB-B가 자동 승계
사용자 요청은 LB-B 통해 지속 처리
백엔드 장애 시에는 해당 노드만 제외하고 서비스 지속

3) 실무 체크리스트(요약)

프런트(리버스 프록시/로드밸런서)

2대 이상 배치(Active-Active 권장, 세션스티키 필요 시 동기화 고려)
상태 공유/Heartbeat(예: keepalived, VRRP, 또는 클라우드 네이티브 LB)
진입점 이중화:
- 온프레미스: VRRP(가상 IP), BGP/Anycast, 이중 코어 스위치
- AWS: ALB/NLB 다중 AZ, Route53 헬스체크/Failover
TLS 종료: 인증서 자동 갱신(예: ACME/certbot, ACM) + HSTS/보안 프로파일
관측성: 지표/로그(요청 수, 오류율, 대기시간 p90/p99), 대시보드/알람

백엔드(웹/앱/서비스)

N대 수평 확장 + 헬스체크 엔드포인트 제공(/health, /ready 등)
무중단 배포(블루/그린, 롤링)와 회귀 전략
세션 관리:
- 스티키 세션이 필요 없다면 무상태(stateless) 권장
- 필요 시 Redis 세션 스토어 또는 LB 레벨 스티키 적용

데이터 계층

다중 AZ/Multi-AZ(RDS), 리플리카/Failover 전략
백업/복구 및 복구 연습(Runbook)

4) AWS 예시(간단 패턴)

웹 애플리케이션(추천)

Route53(헬스체크/Failover)
          │
       ALB(다중 AZ)
          │
     ECS/EKS Auto Scaling (헬스체크, 롤링 업그레이드)
          │
        RDS Multi-AZ / ElastiCache

ALB 자체가 프록시+LB이므로 프록시 이중화 고민 최소화.
컨테이너 오토스케일링, 헬스체크/재시도 내장.
인증서는 ACM으로 자동 관리.

온프레/하이브리드(직접 프록시 운용)

프록시 2대(Nginx/HAProxy) + keepalived(VRRP) 로 가상 IP 운용
혹은 L4 스위치 앞단에서 분산 → 뒤에 Nginx/HAProxy 팜
인증서 자동화 + 프로메테우스/그라파나/알람 세트 필수

5) 운영 팁(장애 최소화)

카나리 테스트: 새 설정은 일부 트래픽으로 검증
서킷 브레이커/타임아웃: 다운스트림 장애 전파 차단
리트라이/백오프: 과도한 재시도 폭주 방지
런북/모의훈련: LB 장애, 인증서 만료, 백엔드 다운… 시나리오별 복구 절차 문서화

HA-Proxy란?