HAProxy 세션 지속성 완벽 가이드
HAProxy는 TCP/HTTP 로드 밸런서로, 웹 애플리케이션의 트래픽을 효과적으로 관리하고 분산시키는 데 널리 사용됩니다. 다양한 환경에서 서버의 부하를 조절하고, 서비스의 가용성을 높이며, 사용자의 요청을 최적의 서버로 연결하는 역할을 합니다. HAProxy 세션 지속성 은 핵심 기능 중 하나입니다.
HAProxy 세션 지속성은 두 가지 형태로 지원됩니다:
- HTTP 쿠키에 기반한 지속성. 이 옵션은 백엔드에서 http mode가 설정된 경우에만 사용할 수 있습니다.
- Client IP 주소에 기반한 지속성. 이 옵션은 http mode와 tcp mode 모두에서 사용할 수 있습니다.
목차
1. 세션 지속성이란?
2. HAProxy 세션 지속성 – HTTP 쿠키 기반
2-1. HAProxy 세션 지속성 테스트 – HTTP 쿠키 기반
3. HAProxy 세션 지속성 – IP 기반
3-1. HAProxy 세션 지속성 테스트 – IP 기반
4. 결론
1. 세션 지속성이란?
세션 지속성이란 로드 밸런서가 클라이언트를 한 번 해당 서버로 라우팅하면 동일한 백엔드 서버로 라우팅하는 것을 의미합니다. 항상 동일한 서버가 선택되므로 요청이 있을 때마다 새 서버에서 클라이언트 상태를 다시 설정하는 오버헤드를 피할 수 있습니다. 애플리케이션 서버의 상태를 공유 데이터베이스에 저장하는 등 서비스를 상태 비저장 방식으로 구축하여 세션 지속성을 완전히 피하는 것이 가장 좋은 경우가 많습니다. 그러나 특정 애플리케이션의 경우 이것이 불가능할 수도 있습니다.
2. HAProxy 세션 지속성 – HTTP 쿠키 기반
HTTP 쿠키를 기반으로 세션 지속성을 활성화하려면 다음과 같습니다.
- backend 섹션에 cookie 지시문을 추가합니다. 이 지시문은 로드 밸런서가 클라이언트의 브라우저에 쿠키를 배치하도록 지시하며, 이 쿠키는 클라이언트가 이전에 라우팅된 서버를 기억하는 데 사용됩니다.
- 또한 각 server line에 cookie 인수를 배치합니다. 이는 쿠키에 저장될 값을 설정하며 각 서버마다 고유해야 합니다.
아래는 이전 포스트에서 사용한 간단한 Round-Robin 로드 밸런싱 구성입니다.
global
log /dev/log local0 # 로깅 설정: local0 로그를 /dev/log에 기록
log /dev/log local1 notice # 로깅 설정: local1 로그를 /dev/log에 기록, notice 레벨로
chroot /var/lib/haproxy # HAProxy의 루트 디렉토리를 /var/lib/haproxy로 설정
pidfile /var/run/haproxy.pid # HAProxy 프로세스 ID를 저장할 파일 경로
maxconn 4000 # 최대 동시 연결 수를 4000으로 설정
user haproxy # HAProxy 프로세스를 실행할 사용자
group haproxy # HAProxy 프로세스를 실행할 그룹
daemon # HAProxy를 데몬 모드로 실행 (주석 처리됨)
# 통계 UNIX 소켓 활성화
stats socket /var/lib/haproxy/stats # HAProxy 통계 정보를 제공할 소켓 경로
defaults
mode http # 기본 모드를 HTTP로 설정
log global # 글로벌 로깅 설정 사용
option httplog # HTTP 로그 옵션 활성화
option dontlognull # NULL 요청에 대한 로그 기록하지 않음
retries 3 # 요청 실패 시 재시도 횟수
timeout http-request 10s # HTTP 요청 타임아웃 설정
timeout queue 1m # 요청 대기열 타임아웃 설정
timeout connect 10s # 서버 연결 타임아웃 설정
timeout client 1m # 클라이언트 타임아웃 설정
timeout server 1m # 서버 타임아웃 설정
timeout http-keep-alive 10s # HTTP Keep-Alive 타임아웃 설정
timeout check 10s # 건강 체크 타임아웃 설정
maxconn 3000 # 최대 동시 연결 수를 3000으로 설정
errorfile 400 /etc/haproxy/errors/400.http # 400 오류에 대한 사용자 정의 에러 페이지 경로
errorfile 403 /etc/haproxy/errors/403.http # 403 오류에 대한 사용자 정의 에러 페이지 경로
errorfile 408 /etc/haproxy/errors/408.http # 408 오류에 대한 사용자 정의 에러 페이지 경로
errorfile 500 /etc/haproxy/errors/500.http # 500 오류에 대한 사용자 정의 에러 페이지 경로
errorfile 502 /etc/haproxy/errors/502.http # 502 오류에 대한 사용자 정의 에러 페이지 경로
errorfile 503 /etc/haproxy/errors/503.http # 503 오류에 대한 사용자 정의 에러 페이지 경로
errorfile 504 /etc/haproxy/errors/504.http # 504 오류에 대한 사용자 정의 에러 페이지 경로
frontend main
bind *:80 # 80번 포트를 바인딩하여 HTTP 요청 수신
stats enable # 통계 기능 활성화
stats uri /stats # 통계 정보에 접근할 URI 설정
default_backend app # 기본 백엔드 서버 그룹 설정
backend app
balance roundrobin # 요청을 라운드 로빈 방식으로 분산
server app1 192.168.200.10:81 check # 첫 번째 서버: 192.168.200.10의 81번 포트
server app2 192.168.200.10:82 check # 두 번째 서버: 192.168.200.10의 82번 포트
server app3 192.168.200.10:83 check # 세 번째 서버: 192.168.200.10의 83번 포트해당 구성에 HTTP 쿠키 기반 HAProxy 세션 지속성 을 구성하려면 아래와 같이 backend 섹션에 cookie 지시문을 추가하면 됩니다.
backend app
balance roundrobin
cookie SERVER_USED insert indirect nocache
server app1 192.168.200.10:81 check cookie s1
server app2 192.168.200.10:82 check cookie s2
server app3 192.168.200.10:83 check cookie s3여기서 사용된 설정 항목은 다음과 같습니다.
- cookie SERVER_USED – 클라이언트와의 세션을 유지하기 위해 사용할 쿠키의 이름을 ‘SERVER_USED’로 지정합니다.
- insert – 이 지시문은 HAProxy가 서버 응답에 쿠키를 삽입하도록 합니다.
- indirect – 이 옵션이 지정되면, 메시지를 서버로 전달하기 전에 들어오는 각 요청에서 쿠키를 제거하고
- nocache – Cache-Control: private HTTP 헤더를 설정하여 HAProxy와 사용자 사이의 캐시 서버가 응답을 캐시하지 않도록 합니다.
각각 cookie s1, cookie s2, cookie s3은 각 백엔드 서버에 연결된 클라이언트에게 설정할 쿠키 값의 이름을 지정합니다.
2-1. HAProxy 세션 지속성 테스트 – HTTP 쿠키 기반
Postman을 사용하여 여러 번의 요청을 보내 세션 지속이 되는지 확인합니다.
Request Header를 확인해보면 “Cookie: SERVER_USED=s3″으로 s3 서버에 연결되어 세션 지속이 되는 것을 확인할 수 있습니다.
3. HAProxy 세션 지속성 – IP 기반
클라이언트의 IP 주소에 따라 HAProxy 세션 지속성 을 활성화하려면:
- backend 섹션에 stick-table line을 추가합니다. Client IP 주소를 보관하기 위한 메모리 내 저장소를 만듭니다. stick table의 항목은 사용하지 않으면 30분 후에 만료됩니다.
- stick on src line을 추가하면 client ip 주소를 stick table에 저장하고 라우팅된 서버와 연결합니다. 이후 방문 시 동일한 서버를 사용합니다.
IP 기반 세션 지속성은 여러 클라이언트가 동일한 IP 주소에서 시작될 수 있기 때문에 쿠키 기반 지속성보다 덜 정확할 수 있습니다.
IP 기반 HAProxy 세션 지속성 구성 방법은 다음과 같습니다:
backend app
balance roundrobin
stick-table type ip size 1m expire 30m
stick on src
server app1 192.168.200.10:81 check
server app2 192.168.200.10:82 check
server app3 192.168.200.10:83 check - stick-table type ip – 테이블의 기본 키는 IP 유형입니다.
- size 1m – 테이블은 최디 100만 개(1048576개)의 레코드를 보유합니다.
- expire 30m – 레코드의 만료 시간은 30분입니다.
- stick on src – Client IP 주소를 stick table에 저장하고 라우팅된 서버와 연결합니다.
3-1. HAProxy 세션 지속성 테스트 – IP 기반
IP 기반 세션 지속성 또한 Postman을 사용하여 확인합니다.
해당 IP에서의 요청이 하나의 서버에 연결되어 있는 것을 확인할 수 있습니다. 쿠키 기반 세션 지속성과의 차이점은 쿠키를 사용하지 않기 때문에 Request Header 부분에 cookie 헤더가 없는 것을 확인할 수 있습니다.
4. 결론
HAProxy 세션 지속성 기능은 웹 애플리케이션의 사용자 경험을 개선하는 데 중요한 역할을 합니다. HTTP 쿠키 기반 세션 지속성과 IP 기반 세션 지속성은 각각의 장점과 단점을 가지고 있으며, 서비스의 요구 사항에 따라 적절한 방법을 선택해야 합니다.
HTTP 쿠키 기반 세션 지속성은 클라이언트의 브라우저에 쿠키를 설정하여 특정 서버에 대한 연결을 유지하는 방식으로, 사용자가 동일한 서버에서 세션을 유지할 수 있도록 합니다. 이 방법은 상태 정보를 관리하는 데 유리하지만 쿠키 설정이 필요하다는 점에서 사용자의 환경에 따라 영향을 받을 수 있습니다.
반면, IP 기반 세션 지속성은 client IP 주소를 활용하여 요청을 처리하는 방식으로, 쿠키를 사용하지 않시 때문에 쿠키 차단이나 비활성화 문제에 영향을 받지 않습니다.
HAProxy에 대한 기술지원 문의나 NGINX Plus로 마이그레이션 지원이 필요하시면 아래 폼을 통해 문의해주세요.
댓글을 달려면 로그인해야 합니다.