
HAProxy는 오늘날 가장 빠르고 널리 사용되는 로드 밸런싱 솔루션 중 하나입니다. 이미 HAProxy를 사용 중이거나, 환경에 HAProxy 도입을 고려하고 있다면 HAProxy를 이해하는 것이 매우 중요합니다.
이제, 로깅이 로드 밸런서 구현의 중요한 구성 요소인 이유와, HAProxy가 제공하는 로깅 기능, 그리고 각자의 필요에 맞게 HAProxy 로그를 관리·구성하는 방법을 살펴보겠습니다.
로드 밸런서 로깅이 중요한 이유
애플리케이션을 외부 세계와 연결할 때 로드 밸런서는 핵심 역할을 합니다. 로드 밸런서는 모든 인바운드 요청을 분석하고 검증한 뒤 적절한 백엔드 서버로 전달합니다. 하지만 로드 밸런서는 단순히 트래픽만 라우팅하는 것이 아닙니다. 애플리케이션의 정상 인스턴스에 요청을 균등하게 분산시키고, 비정상 인스턴스에는 전달되지 않도록 하여 고가용성을 유지하는 데 기여합니다.
로드 밸런서는 모든 요청을 처리하기 때문에, 연결 문제 발생 시 조사 과정의 중심이 되는 경우가 많습니다. 그렇기 때문에 HAProxy 로깅이 중요한 것입니다. HAProxy 로그를 살펴보면 요청 흐름, 성능 지표, 잠재적 오류 등을 상세하게 알 수 있습니다. 따라서 HAProxy 로그를 분석하면 이상 징후를 파악하여 안정적인 운영을 유지할 수 있습니다.
HAProxy 로그 모니터링이 중요한 이유
HAProxy 로그는 밀리초 단위의 정밀도를 제공하며, 인프라 상태를 거시적·미시적으로 파악하고 실행 가능한 데이터를 제공합니다. HAProxy 로그에서 얻을 수 있는 주요 정보와, 각 로그 항목이 애플리케이션에 대한 전반적인 옵저버빌리티를 제공하는 데 어떤 도움이 되는지 살펴보겠습니다.
트래픽 지표
애플리케이션을 통과하는 트래픽 양을 추적하면 리소스 할당에 필요한 내용을 이해하고, 장애가 발생할 수 있는 시점·원인·패턴에 대한 중요한 인사이트를 얻을 수 있습니다.
요청 및 응답 정보
특정 사용자 또는 지역에 영향을 미치는 오류 조건을 분석할 때, 요청 헤더·응답 헤더·페이로드·상태 코드를 살펴보면 문제의 정확한 원인을 빠르게 파악할 수 있습니다. 또한 클라이언트가 어떤 동작을 보게 되는지에 대한 상세한 정보도 제공합니다.
라우팅 결정
HAProxy 로그에는 요청이 어떻게 라우팅되었는지, 어떤 백엔드에 할당되었는지, 그리고 필터나 지속성(persistence) 규칙이 적용되었는지에 대한 정보가 포함됩니다. 이 데이터는 효율적인 트래픽 분산과 보안 규정 준수를 보장하는 데 도움이 됩니다.
오류 추적
마지막으로, HAProxy 로그에는 요청 수명 주기에서 오류가 발생한 지점을 식별하는 데 사용할 수 있는 정보가 포함되어 있습니다. 이 로그에는 세션의 활성 상태와 종료 상태에 대한 정보도 포함될 수 있습니다.
HAProxy 로깅: 기본 및 사전 구성된 로깅 형식
HAProxy의 로깅 형식은 HAProxy 구성 파일의 설정에서 파생됩니다. 구성에서 옵션 지시어를 제외하여 기본 로깅 형식을 사용할 수도 있고, 사전 구성된 두 가지 로깅 형식 중 하나를 설정하여 사용할 수도 있습니다.
HAProxy의 두 가지 기본 로깅 옵션은 다음과 같습니다.
- TCP 또는 4계층 운영 모드: tcplog이라는 옵션의 지시어를 사용해야 합니다.
- HTTP 또는 7계층 운영 모드: 구성에 사용하는 지시어는 httplog이라는 옵션입니다.
이제 각 로그 형식이 어떻게 작동하고 어떤 데이터를 제공하는지 자세히 살펴보겠습니다.
아래의 예제 로그는 AWS Linux 4.14에서 실행되는 AWS 인스턴스에 설치된 HAProxy 버전 2.4.2에서 가져온 것입니다. 이 인스턴스는 동일한 서브넷 내의 두 HTTP 서버 간 트래픽을 관리하도록 구성된 것입니다. 로그는 RSyslog를 사용해 캡처되어, 호스트 서버에 로컬로 저장되었습니다.
기본 로그 형식 (옵션 미구성)
Jul 12 06:32:30 localhost haproxy[2679]: Connect from 67.171.183.156:50871 to 172.31.30.201:80 (http_front/TCP)
| Jul 12 06:32:30 | 로그 타임스탬프 |
| localhost | HAProxy 호스트명 또는 IP 주소 |
| haproxy[2679]: | HAProxy 프로세스의 프로세스 ID |
| Connect from 67.171.183.156:50871 to 172.31.30.201:80 | Connect from 소스 IP: 소스 포트To 대상 IP:대상 포트 |
| (http_front/TCP) | 프런트엔드 이름 / 프런트엔드 모드 |
TCP/4 계층 로그 형식(옵션 tcplog)
Jul 12 06:24:02 localhost haproxy[2590]: 67.171.183.156:54500 [12/Jul/2021:06:23:21.058] http_front http_back/webserver1 1/0/40996 383 -- 2/2/1/0/0 0/0
| Jul 12 06:24:02 | 로그 타임스탬프 |
| localhost | HAProxy 호스트명 또는 IP 주소 |
| haproxy[2590]: | HAProxy 프로세스의 프로세스 ID |
| 67.171.183.156:54500 | 소스 IP:소스 Port |
| [12/Jul/2021:06:23:21.058] | 타임 스탬프 수락 시점(밀리초 단위 정밀도) |
| http_front | 프런트엔드 이름 |
| http_back/webserver1 | 요청이 라우팅된 대상 |
| 1/0/40996 | 대기열에서 기다린 시간(ms) /대상 서버에 연결 설정까지 걸린 시간(ms) /요청 수신부터 마지막 종료까지의 전체 시간(ms) |
| 383 | 읽은 바이트 수 |
| — | — 앞에 표시되는 종료 상태 |
| 2/2/1/0/0 | 활성 연결 수 /프런트엔드 연결 수 /백엔드 연결 수 /서버 연결 수 /재시도 횟수 |
| 0/0 | 서버 큐/백엔드 큐 |
HTTP/7계층(httplog 옵션)
Jul 12 05:54:55 localhost haproxy[1060]: 67.171.183.156:64978 [12/Jul/2021:05:54:55.077] http_front http_back/webserver1 0/0/0/1/1 200 288 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.1"
| Jul 12 05:54:55 | 로그 타임스탬프 |
| localhost | HAProxy 호스트명 또는 IP 주소 |
| haproxy[1060]: | HAProxy 프로세스의 프로세스 ID |
| 67.171.183.156:64978 | 소스 IP:소스 Port |
| [12/Jul/2021:05:54:55.077] | 타임 스탬프 수락 시점(밀리초 단위 정밀도) |
| http_front | 프런트엔드 이름 |
| http_back/webserver1 | 요청이 라우팅된 대상 |
| 0/0/0/1/1 | 클라이언트로부터 전체 요청을 수신하기 위해 대기한 시간(ms) /대기열에서 기다린 시간(ms) /대상 서버와 연결을 설정하는 데 걸린 시간(ms) /대상 서버가 응답을 보내는 데 걸린 시간(ms) / HAProxy에서 요청이 활성화된 총 시간(ms) |
| 200 | HTTP 응답 코드 |
| 288 | 읽은 바이트 수 |
| – – | 옵션값: 캡처된 요청 쿠키 캡처된 응답 쿠킹 |
| —- | — 앞에 표시되는 종료 상태 |
| 2/2/0/0/0 | 활성 연결 수 /프런트엔드 연결 수 /백엔드 연결 수 /서버 연결 수 /재시도 횟수 |
| 0/0 | 서버 큐 크기/백엔드 큐 크기 |
| “GET / HTTP/1.1” | HTTP 요청 |
HAProxy 로그 형식 사용자 지정
기본 및 사전 구성된 HAProxy 로그 형식은 상당한 인사이트를 제공하지만 SSL 암호화, 헤더 및 페이로드 자체를 지원하는 활동과 관련된 중요한 메트릭 및 로그 요소가 부족할 수 있습니다. 이러한 요소들은 로그 데이터의 양을 크게 늘리고 문제 해결에 중요한 정보를 제공합니다.
사용자 정의 로그 형식을 사용하려면 옵션 지시어를 로그 형식 지시어로 바꾸고 원하는 로그 메시지의 구성 요소와 형식을 나타내는 문자열을 뒤에 지정하면 됩니다. 위에서 설명한 HTTP 로그 형식을 그대로 복제한다고 가정하면, 지시자는 다음과 같습니다.
log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r"
사용 가능한 모든 옵션과 정확한 사용법은 HAProxy 문서에 목록으로 정리되어 있습니다. 고급 문제 해결을 위해 포함할 수 있는 옵션의 예시는 다음과 같습니다.
- 연결 핸드셰이크 시간(%Th)
- SSL 암호 스위트 및 버전(%sslc / %sslv)
- 요청 헤더(%hr, CLF 형식은 %hrl)
- 응답 헤더(%hs, CLF 형식은 %hsl)
- 전체 HTTP 요청(%r)
대규모 HAProxy 로그 볼륨 관리
HAProxy는 현재 사용 가능한 가장 효율적인 로드 밸런싱 솔루션 중 하나로, 초당 수천 건의 요청을 처리할 수 있습니다. HAProxy는 각 요청마다 로그 항목을 쉽게 생성할 수 있지만, 트래픽이 증가함에 따라 로그 데이터도 함께 늘어나 디스크 저장 공간을 빠르게 차지하므로 수작업을 통한 로그 분석이 어려워질 수 있습니다.
이를 효율적으로 관리하려면 Sumo Logic과 같은 중앙 집중식 로그 관리 솔루션을 활용하고, 자동화된 이상 징후 탐지 기능을 구현하여 문제 발생할 때 담당팀에 이를 알려야 합니다. 실시간 로그 집계와 자동 알림을 통해 담당팀은 문제를 사전에 탐지하고, 해당 로그 볼륨을 처리하며, 성능을 최적화할 수 있습니다.
HAProxy를 Sumo Logic과 통합 하는 방법을 더 알아보고, 로그 관리가 얼마나 간소화되는지 경험할 수 있도록 무료 체험에 가입 해 보세요.



