HAProxy
에이치에이프록시
는 또는 HTTP 요청을 받아 여러 뒤쪽 서버에 전달하는 프록시·부하 분산 프로그램이다. ·와 헬스 체크로 전달 대상을 구성하며 서버 상태에 따라 새 요청 배정 집합을 바꾼다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 연결과 HTTP 조건으로 적절한 backend를 선택한다.
- 사용 가능한 서버에 알고리즘·가중치 정책으로 작업을 분산한다.
- 능동 헬스 체크로 장애·복귀를 판정하여 배정 대상을 조정한다.
02어떤 순서로 동작하나
- 수신
주소에서 연결을 받고 mode와 진입 정책에 따라 요청을 해석한다.
- backend 선택
default_backend 또는 조건 규칙으로 처리할 서버 집합을 선택한다.
- 서버 배정
UP 상태와 가중치·분산 알고리즘 조건에 맞춰 server를 선택하고 별도 연결로 전달한다.
- 응답·상태 조정
응답을 중계하고 헬스 체크의 연속 실패·성공 기준을 적용해 이후 요청의 대상 집합을 갱신한다.
03먼저 알아둘 용어와 구성요소
- 는 클라이언트 연결을 받는 주소·포트와 진입 정책을 정한다.
- backend는 서버 목록과 분산 방식·상태 검사를 가지고 있고 server 항목이 실제 전달 대상이다.
- 는 스트림을 중심으로 중계하며 HTTP 경로나 Host를 기본 HTTP 규칙처럼 해석하지 않는다.
- 는 HTTP 메시지를 해석해 헤더·URI 기준 분기와 조작을 수행할 수 있다.
- 은 서버를 DOWN으로 제외하기까지 요구하는 연속 실패 횟수다. 한 번의 일시 실패로 상태가 계속 흔들리지 않도록 실패를 누적해 판정한다.
- 는 DOWN 서버가 UP으로 돌아올 때 요구하는 연속 성공 횟수다. 실패 판단과 복귀 판단을 별도로 두므로 첫 성공만으로 즉시 트래픽을 받지 않을 수 있다.
헬스 체크의 404와 사용자 503을 조건부로 연결하기
서버 등록· 검사·HTTP 상태 검사·사용자 응답을 구별하여 가용 서버가 사라지는 조건을 설명한다.
실습 구성과 전제
- 설정 화면, /healthz 패킷, 503 화면은 검사 조건을 달리한 실습 사례다. 첫 화면의 server check만으로 HTTP 404가 DOWN 판정의 원인이라고 단정하지 않는다.
- HTTP 상태를 기준으로 검사하려면 option httpchk 또는 http-check 설정이 실제 적용되어 있어야 한다. 아래 코드는 이를 명시한 재구성이다.
frontend의 분기와 backend의 서버 집합을 읽는다
- 는 수신 포트와 을 정의하고 는 static, 나머지는 app으로 보낸다. app에는 roundrobin과 두 server 행이 보인다.
- server의 check는 능동 검사를 켜지만 검사 종류는 주변 설정에 달려 있다. HTTP 검사가 없으면 기본 연결 검사가 HTTP 본문의 상태까지 읽는 것으로 해석해서는 안 된다.
원본 크기로 보기 ↗- frontend는 80에서 받고 경로·확장자 ACL에 따라 backend를 나눈다.
- backend app은 balance roundrobin이며 두 server 행에 check가 붙어 있다.
확인 기준요청이 어느 backend로 갔는지와 그 backend의 검사 설정을 함께 확인한다. 다른 backend의 정상 상태를 근거로 삼지 않는다.
HTTP 검사 경로와 기대 상태를 명시한다
- 패킷 사진은 연결 수립 뒤 GET /healthz 요청에 404를 받은 사례다. 연결 자체는 가능하지만 그 URI는 기대한 상태를 반환하지 않는다.
- 재구성 설정에서 기대 상태를 200으로 정하면 404는 실패로 누적된다. 3이면 연속 세 번의 실패 후 DOWN, 2이면 연속 두 번의 성공 후 UP 조건이 된다.
backend lab_app mode http option httpchk GET /healthz http-check expect status 200 server app1 192.0.2.21:80 check inter 2s fall 3 rise 2 server app2 192.0.2.22:80 check inter 2s fall 3 rise 2HTTP 200을 성공 기준으로 명시한 재구성이다. 사진의 초기 설정과 동일한 전체 설정이라고 가정하지 않는다.
원본 크기로 보기 ↗- TCP 연결 뒤 GET /healthz HTTP/1.0 요청이 보인다.
- 서버는 HTTP 404로 응답하므로 연결 성공과 준비 상태 URL의 성공이 구별된다.
확인 기준검사 URI가 실제 앱에 있는지, Host 헤더가 필요한지, 인증이 걸려 있지 않은지 확인한다. 404 자체가 곧 서버 종료를 뜻하지 않는다.
503을 서버 선택 상태와 맞춰 확인한다
- 선택한 backend에 요청을 처리할 가용 서버가 없으면 프록시가 503을 반환할 수 있다. 사용자 화면의 503을 특정 한 패킷의 404와 연결하려면 같은 backend·시간·검사 상태라는 추가 증거가 필요하다.
- 정상 복구는 건강한 응답 한 번만 보는 것이 아니라 설정된 조건을 통과해 선택 집합에 돌아오는 과정이다.
원본 크기로 보기 ↗- 브라우저 응답은 503 Service Unavailable이다.
- No server is available to handle this request라는 프록시 메시지가 보인다.
확인 기준상태·로그에서 선택 backend와 서버 UP/DOWN 사유를 대조한다. 앱이 직접 반환한 503과 프록시가 만든 503도 구별한다.
실습에서 확인한 동작 원리
- 연결 검사와 HTTP 준비 상태 검사는 성공 기준이 다르다.
- 검사 응답→연속 성공·실패 수→서버 선택 가능 여부→사용자 응답을 같은 조건과 시각으로 연결해야 한다.
동작·명령 참고 문서
04예제로 따라가기
- 3인 UP 서버의 검사 결과가 실패·실패·성공이면 연속 실패가 끊겨 세 번 실패한 것과 같은 상태 전이가 아니다.
- DOWN 서버가 2에서 성공을 두 번 연속 충족하면 복귀 조건을 만족할 수 있다.
- 한 서버 메모리에만 저장한 은 다음 요청이 다른 서버로 가면 없을 수 있다. 부하 분산 자체가 세션 복제를 제공하지 않는다.
05혼동하기 쉬운 점과 확인 기준
- 연결 성공은 리스너가 응답한다는 좁은 근거다. HTTP 상태나 본문을 검사하면 더 깊은 조건을 평가할 수 있지만 로그인·결제 등 모든 업무를 대신하지는 않는다.
- inter와 전이 상태의 fastinter, DOWN 상태의 downinter는 검사 주기를 바꾼다. 연결 시간 제한과 스케줄 지연도 있으므로 inter×을 항상 정확한 장애 탐지 시간으로 단정하지 않는다.
- 쿠키 기반 고정이나 hash로 같은 서버를 선택하는 것은 우회 수단이지만 서버 장애 때 세션을 다른 서버로 복제하지는 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.