HAProxy 부하 분산·헬스 체크·장애 전환

01frontend·backend·server가 연결 하나를 처리하는 순서

• frontend·연결frontend는 클라이언트 연결을 받는 주소·포트와 진입 정책을 정한다.
• backend요청 조건을 평가한 뒤 default_backend 또는 use_backend 규칙으로 backend를 선택한다.
• backend·서버backend는 서버 목록과 분산 방식·상태 검사를 가지고 있고 server 항목이 실제 전달 대상이다.
• 클라이언트·백엔드 연결HAProxy는 보통 클라이언트와의 연결, 백엔드와의 연결을 각각 관리하므로 두 구간의 연결 수와 timeout도 구별한다.
• mode tcpmode tcp는 TCP 스트림을 중심으로 중계하며 HTTP 경로나 Host를 기본 HTTP 규칙처럼 해석하지 않는다.
• mode httpmode http는 HTTP 메시지를 해석해 헤더·URI 기준 분기와 조작을 수행할 수 있다.
• TLS 종료 위치암호화된 HTTPS 내용을 검사하려면 HAProxy에서 TLS를 종료하거나 해당 정보를 얻을 수 있는 구성을 선택해야 한다.

  • TLS 통과 전달과 종료 후 재암호화는 서로 다른 신뢰 경계다.

02roundrobin·leastconn·hash와 세션 상태

• roundrobinroundrobin은 사용 가능한 서버 사이에 순환하여 배정하는 방식이다.
• leastconn·연결leastconn은 현재 연결 수 등을 기준으로 선택하여 연결 지속시간 차이가 큰 상황에서 유용할 수 있다.
• hashhash는 지정한 키로 선택의 일관성을 제공한다.
• 가중치·알고리즘 조건구체적인 가중치와 동작은 구현·설정에 따라 달라지므로 알고리즘 이름만으로 정확한 처리량을 계산하지 않는다.
• 세션·서버앱의 로그인 세션이 한 서버 메모리에만 있으면 다음 요청이 다른 서버로 가서 로그인 상태를 잃을 수 있다.
• hash·서버쿠키 기반 고정이나 hash로 같은 서버를 선택하는 것은 우회 수단이지만 서버 장애 때 세션을 다른 서버로 복제하지는 않는다.
• 세션공유 세션 저장소·상태 없는 토큰·업로드 저장소·DB 구성은 분산과 별도로 설계해야 한다.
• HTTP 분산기HTTP 분산기가 HTTP 요청을 SQL 명령으로 바꾸는 것도 아니다.

03작은 HAProxy 설정을 한 줄씩 읽기

• HTTP 부하 분산 예제아래 예시는 실습 앱 두 개를 HTTP로 나누는 구조다.
• frontendfrontend의 bind가 진입 포트, default_backend가 선택 대상, backend의 balance가 배정 방식이다.
• server·상태 검사server의 check가 상태 검사 대상에 등록하는 부분이고 HTTP 검사에서는 실제 앱이 기대하는 Host와 URI를 전달한다.
• 문서용 IP문서용 IP를 사용하므로 실제 배포 전에 환경의 주소와 포트로 구체화해야 한다.
• timeoutdefaults의 timeout connect는 백엔드 연결 수립 대기, client와 server는 해당 구간의 비활동 시간 제한에 관여한다.
• timeout과 자원 점유값을 너무 길게 하면 자원을 오래 점유하고 너무 짧게 하면 정상적인 긴 요청을 끊을 수 있다.
• 구문 검사와 요청 성공설정의 문법 통과와 실제 요청 성공은 다르므로 각 값이 연결 생애의 어느 부분에 작용하는지 먼저 이해한다.

defaults
    mode http
    timeout connect 3s
    timeout client 30s
    timeout server 30s
frontend web
    bind :8080
    default_backend apps
backend apps
    balance roundrobin
    option httpchk
    http-check send meth GET uri /ready ver HTTP/1.1 hdr Host study.example
    http-check expect status 200
    server app1 192.0.2.11:8000 check
    server app2 192.0.2.12:8000 check

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

07연결 검사와 readiness 검사, DOWN에서 UP까지

• TCP 검사의 범위TCP 검사는 연결을 수락하는지 확인한다.
• HTTP 검사HTTP 검사는 경로와 Host에 요청을 보내 기대 상태·본문이 나오는지까지 확인할 수 있다.
• 정적 200 응답의 한계서버가 200을 반환하는 빈 정적 파일은 웹 서버 파일 제공 기능을 보여 주지만 DB·캐시·업무 처리까지 준비됐다는 증거는 아니다.

  • 반대로 외부 부가 기능 하나가 실패했다고 모든 서버를 DOWN시키는 health endpoint는 가용성을 불필요하게 떨어뜨릴 수 있다.
• fallfall은 연속 실패 몇 번 뒤 제외할지, rise는 연속 성공 몇 번 뒤 복귀시킬지와 관련된다.
• 실패·복구 임계값첫 실패에 즉시 상태가 뒤집히지 않도록 해 일시 변동을 완충한다.
• L4·L7 상태 표시L4CON은 연결 단계, L7STS는 HTTP 상태, L7OK는 성공적인 응답 판단을 해석하는 단서가 될 수 있으며 실제 표시 이름은 버전에 따른다.
• 검사 메서드와 응답HEAD에는 본문이 없으므로 본문 문자열 검사와 결합하려면 GET 등 맞는 메서드를 사용한다.

08Keepalived VIP 이동과 이미 연결된 세션

• 프록시백엔드가 두 개여도 HAProxy 한 대만 있으면 그 프록시가 단일 장애점이다.
• Keepalived·VRRPKeepalived의 VRRP 구성은 같은 가상 라우터 그룹에서 우선순위와 광고 상태를 바탕으로 VIP 소유자를 정한다.
• VRID·VIP 일치 조건VRID·VIP는 그룹에서 일치해야 하고 노드의 실제 주소와 우선순위는 다를 수 있다.

  • 예를 들어 기본 110 대 100이고 검사 실패 보정이 -20이면 90이 되어 상대가 더 높아지는 구조를 만들 수 있다.
• VIP 이동과 기존 세션VIP가 다른 호스트로 이동하면 새 연결을 그 호스트로 받을 수 있지만 진행 중 TCP 세션과 애플리케이션 메모리가 자동 복제되는 것은 아니다. standby에서 VIP가 아직 없을 때 HAProxy가 어떻게 bind할지도 선택해야 한다.
• pgrep 검사의 한계프로세스가 존재하는지만 보는 pgrep 검사는 실제 응답 준비를 보장하지 않는다.
• 상태 검사·VIP양쪽 설정·인증서·상태 검사와 VIP 소유권, 앱 상태의 수명을 함께 설명해야 장애 전환의 범위가 분명해진다.

09부하 분산기 자체의 가용성

• 분산기의 단일 장애점하나의 부하 분산기만 두면 그 장치가 단일 장애 지점이 될 수 있다.
• KeepalivedKeepalived와 가상 IP 등을 이용한 구성에서는 어느 노드가 주소를 소유하는지, 장애를 무엇으로 판단하는지, 중복 소유를 어떻게 방지하는지 확인한다.
• 인계되지 않는 연결 상태가상 IP가 이동해도 기존 연결이나 애플리케이션 상태가 자동으로 옮겨지는 것은 아니다.
• 연결·세션계획된 장애 실습에서 신규 연결, 기존 연결, 세션 유지와 복구 시간을 각각 확인해야 한다.

  • DB의 쓰기 주체 전환은 별도 문제이다.

10헬스 체크가 서버 선택 집합을 바꾸는 과정

• 정상 서버의 선택 집합하나의 HAProxy가 웹 서버 A와 B에 요청을 분산한다고 가정한다. 정상으로 판정된 서버들이 선택 후보가 되고 설정한 알고리즘과 조건에 따라 요청을 전달한다.
• 상태 검사A의 준비 상태 검사에서 실패가 누적돼 제외 조건을 만족하면 A를 신규 전달 대상에서 빼고 남은 B로 보낸다.
• 실패 판정 조건실패 한 번에 바로 제외할지, 여러 차례를 요구할지는 설정에 따라 다르며 실제 헬스 판정과 사용자 요청의 성공률은 따로 관찰해야 한다.
• 서버·DOWN서버를 DOWN으로 표시하는 것과 기존 TCP 연결을 모두 끊는 것은 동일한 동작이 아니다.
• 진행 중인 요청연결 유지·종료 정책과 프로토콜 모드에 따라 이미 진행 중인 요청의 결과가 달라질 수 있다.
• 후보 복귀 조건A가 회복해도 설정한 정상 검사 조건을 만족한 뒤 다시 선택 후보로 들어온다.
• 장애·복귀 시 부하서버가 빠진 동안 B가 전체 부하를 감당할 수 있는지, 복귀한 A에 갑자기 요청이 몰리지 않는지도 중요한 운영 조건이다.

1. 둘 다 정상A·B가 신규 전달 후보로 등록돼 있다.
2. A 검사 실패 누적설정한 실패 판정 조건에 도달했는지 확인한다.
3. A 제외신규 요청은 남은 후보 B로 전달한다.
4. A 회복 확인설정한 정상 판정 조건을 충족하면 다시 후보가 된다.

11검사 성공인데 사용자는 실패하는 이유

• TCP 검사와 응용 오류헬스 체크가 단순 TCP 연결이면 포트는 열렸지만 애플리케이션이 오류를 반환하는 상황을 놓칠 수 있다.
• 검사의 업무 범위HTTP 검사도 정적 페이지 하나만 확인하면 DB가 필요한 기능의 실패를 발견하지 못할 수 있다.

  • 반대로 모든 외부 의존성을 무거운 질의로 검사하면 검사 자체가 부하를 만들거나 부분 장애 때 모든 서버가 동시에 제외될 수 있다.
• 준비 상태의 의미준비 상태의 의미를 정하고 가벼운 검사와 실제 사용자 요청 관찰을 함께 사용한다.
• backend·재시도HAProxy의 접속·대기·응답 시간과 backend별 상태, 오류·재시도 횟수를 비교한다.
• 개별·공통 장애 분리특정 서버에만 실패가 집중되면 그 서버의 설정과 데이터 상태를 확인하고, 전체 실패면 공통 의존성과 분산기 자체를 조사한다.
• VIPVIP가 다른 분산기로 이동해도 기존 연결·세션·DB 쓰기 주체가 자동으로 이동하는 것은 아니다.
• 연결·세션장애 실습에서는 새 연결과 진행 중 요청, 로그인 세션, 변경 요청의 중복 여부를 별도로 확인해야 가용성 범위를 정확히 설명할 수 있다.
• 재시도재시도는 일시 장애에 도움이 되지만 이미 처리된 변경 요청을 반복하면 중복 작업이 생길 수 있다. 요청의 멱등성, 재시도 시점, 대상 변경 조건을 검토하고 응답 시간 제한을 다른 계층과 맞춘다.