Load Balancing과 세션

여러 WAS로 트래픽을 분산할 때 로드밸런싱 방식과 세션 유지 문제를 정리한다.

트래픽이 나뉘는 지점

Client
  -> Load Balancer / Web Server
  -> WAS #1
  -> WAS #2
  -> WAS #3

핵심 개념

Load Balancing은 여러 서버로 요청을 나누는 기술이고, 세션 관리는 분산된 요청 속에서 사용자 상태를 유지하는 문제다.

왜 필요한가

단일 WAS는 장애와 부하에 취약하다. 여러 WAS로 나누면 처리량과 가용성을 높일 수 있다.

하지만 로그인 상태처럼 사용자별 상태를 WAS 메모리에 저장하면 문제가 생긴다.

요청 1 -> WAS #1: 로그인 성공, 세션 생성
요청 2 -> WAS #2: 세션 없음, 다시 로그인 필요

따라서 로드밸런싱을 설계할 때 세션 저장 방식을 같이 봐야 한다.

로드밸런싱 방식

방식설명
Round Robin요청을 순서대로 분산
Least Connections연결 수가 적은 서버로 분산
IP Hash클라이언트 IP 기준으로 같은 backend 선택
Weighted서버 성능에 따라 가중치 부여
Health Check장애 서버를 분산 대상에서 제외

Nginx upstream 예시

upstream tomcat_backend {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

server {
    listen 80;

    location / {
        proxy_pass http://tomcat_backend;
    }
}

세션 유지 방식

방식설명장점주의점
Sticky Session같은 사용자를 같은 WAS로 보냄구현이 단순특정 서버 장애 시 세션 손실
Session ClusteringWAS 간 세션 복제애플리케이션 변경 적음복제 비용, 설정 복잡도
External Session StoreRedis 등 외부 저장소 사용WAS 무상태화에 가까움외부 저장소 가용성 필요
StatelessJWT 등으로 서버 세션 최소화확장성 좋음토큰 보안, 만료 정책 중요

Health Check

로드밸런서는 backend가 살아 있는지 확인해야 한다. 단순 포트 체크만으로는 부족할 수 있다.

체크의미
TCP port프로세스가 포트를 열고 있는가
HTTP status애플리케이션이 정상 응답하는가
DB 포함 healthDB 연결까지 정상인가
readiness트래픽을 받아도 되는 상태인가
liveness프로세스를 재시작해야 하는 상태인가

장애 유형

증상확인 지점
특정 사용자만 로그인 풀림sticky session, cookie, session store
일부 요청만 500특정 WAS 인스턴스 로그
간헐적 502backend 일부 down, health check 설정
배포 후 일부만 구버전backend 버전 불일치
응답 지연특정 backend 부하, connection 편중

점검 포인트

  1. backend 목록이 현재 운영 서버와 일치하는가?
  2. health check가 실제 애플리케이션 상태를 반영하는가?
  3. 세션은 WAS 메모리, 외부 저장소, 토큰 중 어디에 있는가?
  4. 장애 서버가 자동으로 제외되는가?
  5. 배포 중 신구 버전이 섞여도 안전한가?

관련 블로그 기록

닫기 전 질문

  • 같은 사용자의 두 요청이 서로 다른 WAS로 가도 문제가 없는가?
  • backend 하나가 죽었을 때 세션과 진행 중 요청은 어떻게 되는가?
  • health check는 포트만 보는가, 애플리케이션 상태까지 보는가?