check 만 적어 두면 기본값으로 동작한다. 전환 시간은 세 값의 곱으로 정해진다.
backend web
default-server inter 2s fall 3 rise 2
server a a.example.com:80 check
server b b.example.com:80 check
| 옵션 | 뜻 | 기본값 |
|---|---|---|
inter |
체크 주기 | 2초 |
fall |
연속 실패 몇 번에 DOWN 으로 볼지 | 3 |
rise |
연속 성공 몇 번에 UP 으로 볼지 | 2 |
즉 기본 설정에서는 서버가 죽은 뒤 최대 inter × fall = 약 6초 안에 제외된다. "몇 분 뒤에 넘어가느냐"가 아니라 초 단위다.
빨리 감지하려면 inter 1s fall 2 처럼 줄인다. 대신 일시적인 지연에도 서버가 빠졌다 들어오는 플래핑이 늘어난다. 반대로 rise 를 크게 잡으면 복구된 서버를 늦게 받아들여 안정적이다.
default-server inter 2s fall 3 rise 5 slowstart 30s
slowstart 는 복구된 서버의 가중치를 지정 시간 동안 서서히 올린다. 캐시가 비어 있는 서버에 트래픽이 한꺼번에 몰리는 것을 막는다.
TCP 연결만으로는 "포트는 열렸지만 애플리케이션은 고장난" 상태를 걸러내지 못한다. HTTP 백엔드라면 실제 응답을 본다.
backend web
option httpchk GET /healthz
http-check expect status 200
server a a.example.com:80 check inter 2s fall 3 rise 2
# 쿠버네티스 API 서버처럼 TLS 이고 인증이 필요한 경우
backend k8s-api
mode tcp
option tcp-check
server m1 10.0.0.11:6443 check inter 2s fall 3 rise 2
mode tcp 백엔드에서는 option tcp-check 로 연결 가능 여부만 본다. HTTPS 경로를 검사하려면 check-ssl verify none 을 붙이되, 인증이 필요한 엔드포인트는 401 이 정상 응답이므로 http-check expect status 401 처럼 기대값을 맞춘다.
전용 헬스 엔드포인트를 두는 것이 가장 좋다. 메인 페이지를 체크에 쓰면 DB 가 죽어도 200 이 나오거나, 반대로 무거운 페이지 때문에 체크가 실패한다.
| 알고리즘 | 특징 |
|---|---|
roundrobin |
순서대로. 가중치 반영. 일반적인 기본 선택 |
leastconn |
연결 수가 가장 적은 서버로. 세션이 긴 서비스(LDAP · DB · WebSocket)에 적합 |
source |
클라이언트 IP 해시. 같은 IP 는 같은 서버로 |
uri |
요청 경로 해시. 캐시 서버에 적합 |
first |
앞 서버부터 채운다. 사용량 기반 축소 운영에 쓴다 |
source 는 세션 고정이 필요하지만 쿠키를 쓸 수 없을 때 선택한다. 다만 NAT 뒤 사용자가 몰리면 한 서버로 쏠린다.
HTTP 라면 쿠키 기반 고정이 더 정확하다.
backend web
balance roundrobin
cookie SRV insert indirect nocache
server a a.example.com:80 check cookie a
server b b.example.com:80 check cookie b
해시 계열(source · uri 등)은 hash-type 으로 분배 방식을 정한다.
balance source
hash-type consistent
map-based : 해시값을 서버 배열에 대응시킨다. 분포가 고르고 가중치를 반영하지만, 서버 수가 바뀌면 대부분의 매핑이 다시 계산된다. 즉 한 대가 빠지면 살아 있는 서버들 사이에서 배치가 크게 흔들려 기존 고정이 깨진다.consistent : 해시 링을 써서 변화 영향을 최소화한다. 서버가 빠지면 그 서버가 맡던 몫만 재배치되고 나머지는 유지된다. 캐시나 세션 고정이 중요한 구성에서는 이쪽을 쓴다.hash-type 을 지정하지 않았을 때의 기본 동작과, 대상 서버가 DOWN 일 때의 처리는 버전별 문서를 직접 확인하는 것이 좋다(확인 필요 - 이번에 공식 설정 매뉴얼의 해당 항목 원문을 확보하지 못했다). 확실한 것은 세션 고정이 필요한 구성에서는 hash-type consistent 를 명시하는 편이 안전하다는 점이다.
고정성이 필수가 아니라면 leastconn · roundrobin 이 장애 대응 면에서 단순하다.
backend web
server a a.example.com:80 check
server b b.example.com:80 check backup
backup 이 붙은 서버는 다른 서버가 모두 DOWN 일 때만 쓰인다. 액티브-스탠바이 구성이 필요할 때 쓴다. 여러 예비 서버를 동시에 쓰려면 option allbackups 를 함께 준다.
listen stats
bind *:9000
mode http
stats enable
stats uri /haproxy?stats
stats refresh 10s
stats auth admin:${STATS_PASSWORD}
# 런타임 소켓으로 상태 조회 · 수동 제어
echo "show stat" | socat stdio /var/run/haproxy.sock | cut -d, -f1,2,18,19
echo "disable server web/a" | socat stdio /var/run/haproxy.sock
echo "enable server web/a" | socat stdio /var/run/haproxy.sock
점검 시간에 서버를 뺄 때는 설정을 고치지 말고 런타임 소켓으로 disable 하면 기존 연결을 끝내고 자연스럽게 빠진다.
통계 화면은 외부에 노출하지 않는다. 백엔드 구조가 그대로 드러난다.