[Infra Ops] Tomcat 세션 클러스터링과 Redis 세션 외부화

WAS를 이중화하면 트래픽 분산이라는 목적은 달성하지만, 세션이라는 새로운 문제가 즉시 발생합니다. 각 WAS 인스턴스는 자신의 JVM 메모리에 세션을 독립적으로 관리하기 때문에, 로드밸런서가 요청을 다른 WAS로 보내는 순간 그 사용자의 로그인 상태는 사라집니다. 이 문제를 해결하지 않고 WAS 이중화를 운영하면 사용자에게는 "자꾸 로그아웃된다"는 민원이 반복됩니다.

확대

HTTP는 상태가 없는(stateless) 프로토콜입니다. 로그인 정보, 장바구니처럼 사용자별로 유지해야 하는 데이터는 서버 쪽에서 세션이라는 형태로 보관합니다. 각 WAS는 세션을 자신의 JVM 힙(메모리)에 저장합니다.

WAS가 1대일 때는 문제가 없습니다. 모든 요청이 같은 JVM으로 들어오므로 세션을 찾을 수 있습니다. WAS를 2대로 늘리면 달라집니다. 로드밸런서는 요청마다 Tomcat1과 Tomcat2 중 하나를 고릅니다. 세션이 Tomcat1 메모리에 있는데 Tomcat2가 요청을 받으면, Tomcat2는 세션을 모르므로 "인증되지 않은 사용자"로 취급합니다.

해결 방법은 세 가지입니다. 각각 구현 복잡도와 장애 허용 범위가 다릅니다.

사용자가 로그인하고 장바구니에 상품을 담습니다. WAS가 2대인데도 새로고침할 때마다 로그인이 유지되려면, 그 세션이 노드 사이에서 살아남아야 합니다. 이 과정은 LB 라우팅 → 세션 생성 → 데이터 저장 → 복제·외부화 → 재요청 라우팅 → 페일오버 → 세션 복원의 순서로 일어납니다. 이 단계를 나눠 두면 "왜 매 요청마다 로그아웃되지", "왜 노드 하나 죽으니 세션이 사라지지", "왜 배포 직후에만 로그아웃되지"를 특정 단계로 좁힐 수 있습니다.

[사용자]  로그인 요청  →  Nginx(LB)
   │
   ① LB 라우팅 결정                         (sticky: ip_hash·jvmRoute로 고정 / 비sticky: round-robin)
   │
   ② tomcat1 도착 → 세션 생성               (new HttpSession, JSESSIONID=ABC.tomcat1 쿠키 발급)
   │
   ③ 세션에 데이터 저장                      (로그인 정보·장바구니 → tomcat1 JVM 힙)
   │
   ④ 복제 or 외부화                          (DeltaManager=전체 / BackupManager=백업1대 / Redis=외부저장)
   │    → 세션 객체를 직렬화(byte)해 전파·저장
   │
   ⑤ 다음 요청 재도착                        (sticky면 tomcat1, 아니면 tomcat2로 갈 수도)
   │
   ⑥ tomcat1 다운 → 페일오버                (LB가 살아있는 tomcat2로 넘김)
   │
   ⑦ tomcat2가 세션 복원                    (복제본 or Redis에서 로드 → 로그인 유지)
   ▼
[사용자]  로그인·장바구니 그대로 유지

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 세 가지 세션 전략이 각각 어느 단계를 책임지는지가 한눈에 보입니다. sticky는 ①⑤(라우팅 고정)만 담당하고, 복제·외부화는 ④⑦(다른 노드에서 복원)을 담당합니다 — 그래서 sticky만으로는 ⑥ 페일오버를 못 버팁니다. 증상으로 단계를 역추적하면: 매 요청마다 로그아웃이면 ①(sticky도 공유도 없음), 노드가 죽을 때만이면 ⑥(복제·외부화 없음), 배포 직후에만이면 ⑦(직렬화 비호환)입니다. 어디서 세션이 사라지는지를 이 단계로 좁힌 뒤 해당 계층(LB·클러스터·직렬화)을 고칩니다.

Tomcat 클러스터는 추가 인프라 없이 WAS 노드끼리 세션을 동기화하는 방법입니다. 멀티캐스트로 클러스터 멤버를 발견하고, 세션 변경이 생길 때마다 그 차이(delta)를 전체 노드에 전파하는 방식이라 어느 WAS로 요청이 가도 동일한 세션을 읽을 수 있습니다. 단, 이 방식은 노드 수가 늘어날수록 복제 트래픽이 N-1배로 늘어나는 구조적 한계가 있어, 소규모 클러스터(2~3대)에 적합합니다.

확대

서버를 2대로 늘린 직후부터 장바구니가 비워진다는 민원이 쏟아집니다. Nginx 로그에는 이상이 없고, 두 Tomcat 모두 정상 동작 중입니다. 문제는 세션이 각자의 메모리에만 있다는 것입니다. 이 문제를 Tomcat 레벨에서 해결하는 방법이 DeltaManager 클러스터입니다. 세션이 변경될 때마다 변경분을 클러스터 전체로 전파해, 어떤 WAS로 요청이 가도 동일한 세션 데이터를 읽게 합니다.

Tomcat 내장 클러스터 기능을 사용하는 방법입니다. 세션이 변경될 때마다 그 차이(delta)를 클러스터 내 모든 노드에 멀티캐스트로 전파합니다. 어떤 WAS로 요청이 가도 최신 세션을 찾을 수 있습니다.

DeltaManager와 BackupManager의 차이는 복제 범위입니다. DeltaManager는 All-to-All — 클러스터 전체에 뿌립니다. 노드가 2~4대일 때 단순하고 효과적입니다. BackupManager는 Primary-Backup — 지정된 백업 노드 1개에만 복제해 트래픽을 아낍니다. 노드가 많을수록 BackupManager가 유리합니다.

server.xml에 <Cluster> 블록을 추가합니다. 두 Tomcat 서버 모두 동일하게 설정하되, jvmRoute 값만 다르게 줍니다.

<!-- /opt/tomcat/conf/server.xml — Tomcat1 -->
<Server port="8005" shutdown="SHUTDOWN">
  <Service name="Catalina">
    <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">

      <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
               channelSendOptions="8">

        <Manager className="org.apache.catalina.ha.session.DeltaManager"
                 expireSessionsOnShutdown="false"
                 notifyListenersOnReplication="true"/>

        <Channel className="org.apache.catalina.tribes.group.GroupChannel">

          <!-- 멀티캐스트로 클러스터 멤버 발견 -->
          <Membership className="org.apache.catalina.tribes.membership.McastService"
                      address="228.0.0.4"
                      port="45564"
                      frequency="500"
                      dropTime="3000"/>

          <!-- 세션 복제 수신 포트 -->
          <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                    address="auto"
                    port="4000"
                    autoBind="100"
                    selectorTimeout="5000"
                    maxThreads="6"/>

          <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
            <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
          </Sender>

          <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
          <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/>
        </Channel>

        <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
        <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
      </Cluster>

      <Host name="localhost" appBase="webapps">
        <!-- ... -->
      </Host>

    </Engine>
  </Service>
</Server>

Tomcat2는 jvmRoute="tomcat2"로만 바꾸면 됩니다. 나머지는 동일합니다.

클러스터가 동작하려면 애플리케이션의 web.xml에 <distributable/> 태그가 있어야 합니다. 이 태그가 없으면 Tomcat이 세션을 분산 가능한 형태로 관리하지 않습니다.

<!-- WEB-INF/web.xml -->
<web-app>
  <distributable/>
  <!-- ... -->
</web-app>

멀티캐스트 포트(45564)와 복제 수신 포트(4000)는 방화벽에서 열어야 합니다.

# firewalld 환경
firewall-cmd --permanent --add-port=45564/udp
firewall-cmd --permanent --add-port=4000/tcp
firewall-cmd --reload

세션 복제 없이 세션 소실 문제를 빠르게 막아야 할 때 Nginx ip_hash가 현실적인 첫 번째 선택지입니다. 코드나 애플리케이션 설정 변경 없이 Nginx 설정 파일 한 줄로 적용되기 때문에, 긴급 패치나 일정이 촉박한 상황에서도 즉시 투입할 수 있습니다. 다만 NAT 환경에서 트래픽 집중이나 WAS 장애 시 세션 전체 소실 같은 구조적 한계가 있으므로, 근본 해결책보다는 임시 대응으로 사용해야 합니다.

확대

DeltaManager를 설정하기엔 일정이 촉박하고, 당장 이번 주 배포에서 세션 소실 문제만 막아야 하는 상황이 있습니다. Nginx 설정 몇 줄로 같은 클라이언트를 항상 같은 WAS로 보내는 것이 ip_hash sticky session입니다. 코드 변경 없이 Nginx 레이어에서 처리하기 때문에 빠르게 적용할 수 있습니다.

세션 복제 없이 로드밸런서 레이어에서 세션 문제를 해결하는 방법입니다. Nginx가 동일한 클라이언트 IP를 항상 같은 Tomcat으로 보내면, 세션이 항상 같은 JVM에 있으므로 소실되지 않습니다.

ip_hash는 클라이언트 IP의 처음 세 옥텟(xxx.xxx.xxx)으로 해시를 계산합니다. upstream 서버 목록이 변경되지 않는 한 같은 클라이언트는 항상 같은 서버로 갑니다.

# /etc/nginx/conf.d/tomcat-cluster.conf
upstream tomcat_cluster {
    ip_hash;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://tomcat_cluster;

        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_connect_timeout 10s;
        proxy_read_timeout    60s;
    }
}

jvmRoute를 설정하면 JSESSIONID 쿠키가 ABC123XYZ.tomcat1처럼 노드 식별자를 포함합니다. Nginx는 쿠키의 .tomcat1 접미사를 파싱해 해당 노드로 정확히 라우팅할 수 있습니다. ip_hash보다 더 정확한 sticky session이 필요하다면 nginx-sticky-module(쿠키 기반)을 사용합니다.

ip_hash의 한계:

이런 한계 때문에 ip_hash는 보조 수단으로 쓰고, 근본 해결책으로 세션 외부화를 선택하는 경우가 많습니다.

세션을 WAS 메모리에 두는 한, WAS 재시작이나 스케일 아웃은 항상 세션 소실 위험을 동반합니다. Redis 외부화는 세션의 소유권을 WAS에서 분리해 이 문제를 구조적으로 해결합니다. 어느 WAS로 요청이 가든 같은 Redis를 읽기 때문에 세션 복제 트래픽도 없고, WAS를 마음대로 재시작하거나 늘려도 사용자 세션이 유지됩니다. Auto Scaling 환경이라면 세션 외부화 없이는 WAS를 탄력적으로 운영하기가 사실상 불가능합니다.

확대

세션 복제(DeltaManager)의 근본 문제는 노드가 늘어날수록 복제 트래픽도 늘어난다는 점입니다. 노드가 N개이면 세션 변경 1건당 N-1번 복제가 발생합니다. 또한 WAS 재시작 시 메모리가 초기화되므로 배포 시 세션 소실이 일어납니다.

Redis 외부화는 이 문제를 구조적으로 해결합니다. WAS는 세션 ID(쿠키)만 클라이언트에 보내고, 실제 세션 데이터는 Redis에 저장합니다. 어떤 WAS로 요청이 가도 동일한 Redis를 읽으므로 세션이 항상 일치합니다. WAS를 재시작해도 Redis 데이터는 그대로이므로 세션이 유지됩니다.

Spring Boot 프로젝트 기준 설정입니다.

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

# application.properties
spring.session.store-type=redis
spring.redis.host=redis-server
spring.redis.port=6379

# 세션 만료 시간 (초) — 기본값 1800초 (30분)
spring.session.timeout=1800

# Redis 커넥션 풀 설정
spring.redis.lettuce.pool.max-active=8
spring.redis.lettuce.pool.max-idle=8
spring.redis.lettuce.pool.min-idle=2

@EnableRedisHttpSession 어노테이션을 구성 클래스에 추가하면 spring-session이 Tomcat 기본 세션 관리자를 대체합니다.

// SessionConfig.java
@Configuration
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 1800)
public class SessionConfig {
    // Redis 연결은 application.properties 설정으로 자동 구성됨
}

Redis에 저장된 세션은 spring:session:sessions:SESSION_ID 키로 Hash 자료구조로 보관됩니다. spring:session:expirations:TIMESTAMP로 만료 인덱스도 관리됩니다.

세션 전략을 '평소에 세션이 유지되는가'로만 보면 절반만 본 것입니다. 진짜 차이는 노드가 죽을 때와 새 버전을 배포할 때 드러납니다.

• sticky만: tomcat1이 죽으면 ip_hash가 클라이언트를 tomcat2로 넘기는데, 세션은 tomcat1 메모리에만 있었으니 그대로 소실됩니다. sticky는 '평소 고정'일 뿐 페일오버 안전장치가 아닙니다.
• sticky + 복제(DeltaManager): tomcat2에도 세션이 복제돼 있어 유지됩니다. 그런데 JSESSIONID 접미사는 여전히 .tomcat1이라, tomcat1이 복구되면 sticky가 세션을 원래 노드로 되돌리려 합니다. 이때 JvmRouteBinderValve가 페일오버를 감지해 세션의 jvmRoute 접미사를 현재 처리 노드인 .tomcat2로 재기록합니다. 그래서 세션이 살아난 원래 노드로 튕겨가지 않고 새 노드에 안정적으로 눌러앉습니다(세션 재귀속).
• 외부화(Redis): 세션이 WAS 밖에 있으니 노드가 죽어도 유지되고, 이론상 sticky조차 필요 없습니다. 대신 Redis가 SPOF가 되지 않게 HA가 전제입니다.

핵심 한계: 복제와 외부화는 둘 다 직렬화된 바이트를 다룹니다. 그래서 세션에 담기는 클래스가 배포로 바뀌면(필드 추가·타입 변경) 저장소에 남은 이전 버전 바이트를 역직렬화하다 실패합니다. 특히 세션 클래스에 serialVersionUID를 고정해 두지 않으면 재컴파일마다 UID가 달라져, 필드를 하나도 안 바꿔도 배포만으로 역직렬화가 깨질 수 있습니다. 단일 WAS 메모리 세션에서는 절대 안 보이다가 다중화·외부화하는 순간 배포 때 터지는 함정입니다.