세션 관리와 클러스터링 개요

로드밸런싱 환경에서 가장 먼저 마주치는 문제가 **세션 불일치(Session Inconsistency)**입니다. 사용자가 로그인한 서버와 다음 요청을 처리하는 서버가 달라지면, 로그인 정보가 없다는 이유로 다시 로그인 페이지로 튕겨나가게 됩니다. 이 챕터에서는 세션 불일치 문제의 원인을 이해하고, 세 가지 해결 전략과 각각의 장단점을 체계적으로 학습합니다.

세션이란?

HTTP는 무상태(Stateless) 프로토콜입니다. 서버는 각 요청을 독립적으로 처리하며, 이전 요청의 정보를 기억하지 않습니다. 로그인, 장바구니, 사용자 설정 등 상태를 유지해야 하는 경우 **세션(Session)**을 사용합니다.

[클라이언트]                         [서버]
   │                                   │
   │  1. POST /login (ID/PW)           │
   │ ─────────────────────────────────▶│
   │                                   │  세션 생성
   │  2. Set-Cookie: JSESSIONID=ABC    │  {userId: 1001, role: admin}
   │ ◀─────────────────────────────────│
   │                                   │
   │  3. GET /dashboard                │
   │     Cookie: JSESSIONID=ABC        │
   │ ─────────────────────────────────▶│  세션 조회 → 인증됨
   │  4. 200 OK (대시보드 응답)          │
   │ ◀─────────────────────────────────│

세션은 서버 메모리(또는 파일, DB)에 저장되며, 클라이언트는 세션 ID가 담긴 쿠키만 보관합니다.

로드밸런싱 환경에서의 세션 불일치 문제

Session Inconsistency Problem

서버가 여러 대로 늘어나면 세션이 저장된 서버와 요청을 처리하는 서버가 달라질 수 있습니다.

요청1 → App1 로그인 → 세션 ABC를 App1 메모리에 저장
요청2 → App2 처리  → 세션 ABC 없음 → 로그인 안 됨!
요청3 → App3 처리  → 세션 ABC 없음 → 로그인 안 됨!

이것이 세션 불일치(Session Inconsistency) 문제입니다.

세션 불일치가 발생하는 상황

상황	설명
라운드 로빈 로드밸런싱	요청마다 다른 서버로 분배됨
배포 후 서버 재시작	메모리에 있던 세션이 사라짐
서버 장애 → 페일오버	장애 서버의 세션이 유실됨
서버 추가 (스케일 아웃)	기존 세션이 없는 새 서버로 라우팅될 수 있음

세 가지 해결 전략

세션 불일치 문제를 해결하는 방법은 크게 세 가지입니다.

전략 1: Sticky Session (세션 고정)

같은 사용자의 요청은 항상 같은 서버로 보냅니다. 로드밸런서가 쿠키나 IP 해시로 사용자와 서버를 묶습니다.

사용자 A → 항상 App1
사용자 B → 항상 App2
사용자 C → 항상 App3

장점: 애플리케이션 변경 없이 즉시 적용 가능. 단점: App1이 다운되면 사용자 A의 세션 유실. 서버 부하가 균등하지 않을 수 있음.

전략 2: 세션 클러스터링 (인메모리 복제)

Tomcat 클러스터 기능으로 각 서버의 세션을 다른 서버들과 실시간 동기화합니다.

App1 세션 변경 → App2, App3에 복제
→ 어느 서버에서도 동일한 세션 접근 가능

장점: 서버 장애 시에도 세션 유지. Sticky Session 불필요. 단점: 서버 간 네트워크 트래픽 증가. 서버 수가 많아질수록 복제 부하 증가.

전략 3: 외부 세션 저장소 (Redis)

모든 서버가 Redis(인메모리 데이터 저장소)를 공유 세션 저장소로 사용합니다.

App1 → Redis에 세션 저장/조회
App2 → Redis에 세션 저장/조회 (동일 데이터)
App3 → Redis에 세션 저장/조회 (동일 데이터)

장점: 가장 확장성이 높음. 서버 추가·제거가 자유로움. 단점: Redis 인프라 추가 필요. Redis 장애 시 전체 세션 유실 위험 (Redis 클러스터로 해결).

전략 비교표

항목	Sticky Session	세션 클러스터링	Redis 세션 공유
구현 난이도	낮음	중간	높음
서버 장애 시 세션 유지	❌ 유실	✅ 유지	✅ 유지
스케일 아웃 자유도	낮음	중간	높음
애플리케이션 변경	없음	없음	코드 추가 필요
운영 복잡도	낮음	중간	높음
적합한 서버 수	소규모 (2~3대)	소규모 (2~5대)	대규모

챕터 학습 순서

이 챕터는 다음 순서로 학습합니다:

Sticky Session — Nginx ip_hash·cookie, Apache jvmRoute
Tomcat 인메모리 클러스터링 — DeltaManager, BackupManager
Redis 기반 세션 공유 — Tomcat Redis Session Manager, Spring Session
세션 직렬화 — Serializable 구현과 성능 최적화

각 방법의 설정 방법과 장단점을 직접 실습하며 익힙니다.

세션이란?​

로드밸런싱 환경에서의 세션 불일치 문제​

세션 불일치가 발생하는 상황​

세 가지 해결 전략​

전략 1: Sticky Session (세션 고정)​

전략 2: 세션 클러스터링 (인메모리 복제)​

전략 3: 외부 세션 저장소 (Redis)​

전략 비교표​

챕터 학습 순서​