세션 클러스터링: 스티키 세션과 데이터그리드로 무중단 확장하기

로드 밸런싱, Failover, Auto Scaling 어느 상황에서든 사용자의 세션이 끊기지 않아야 한다는 요구는 WAS를 두 대 이상 이중화하는 순간부터 따라온다. 세션 클러스터링은 노드 간 사용자 세션 상태를 공유·복제·외부화해 무정지, 확장성, 장애 조치를 함께 달성하는 기술이다.

구성 방식

WAS 간 세션 복제는 각 세션에 Primary/Backup을 지정하거나 클러스터 전체에 복제하는 방식이다. Delta 복제로 네트워크 비용을 줄일 수 있고 외부 컴포넌트가 없어 단순하지만, 노드 수가 늘어나면 복제 스톰과 네트워크 병목이 생기기 쉽다. Session Server 방식은 Redis·Memcached 같은 별도 세션 서버에 세션을 외부화해 로드밸런서가 스티키 여부와 무관하게 자유롭게 라우팅할 수 있게 한다. Auto Scaling과 궁합이 좋고 일관성 제어가 쉽지만, SPOF 위험과 네트워크 왕복에 따른 지연·비용이 따른다. Session Data Grid는 Hazelcast·Infinispan·Coherence 같은 인메모리 분산 데이터그리드로 세션을 파티션·백업한다. 선형 확장성과 고성능, 장애 도메인 분리가 장점이지만 별도 서버·라이선스·운영 포인트가 늘어난다. 데이터그리드를 도입하면 동일 트래픽 기준으로 노드 수를 20~40% 감축할 수 있다(세션 외부화로 GC·힙 압력이 줄어드는 효과).

구성 방안	성능	확장성	일관성	안정성/가용성	운영 편의
WAS 간 세션 복제	스티키+델타 복제 시 고성능, 풀 복제 시 네트워크 오버헤드 증가	노드 수 증가 시 복제 비용 비선형 증가	강/최종 일관성 모두 가능, 직렬화 호환성 이슈	노드 1대 장애에 견고, 다수 노드 장애 시 리스크	비교적 단순, 멀티캐스트 제한 환경에서는 설정 복잡
Session Server(예: Redis)	네트워크 RTT 영향, 파이프라이닝·TTL 최적화로 개선	수평 확장 쉬움(샤딩/레플리카)	단일 저장소로 일관성 관리 용이	SPOF 제거 필요(멀티 AZ/클러스터)	운영 자동화 풍부, 외부 의존성 증가
Session Data Grid	인메모리로 매우 높음	파티션+백업으로 선형 확장	분산락/원자 연산 제공	노드/존 장애에도 자동 재배치	전용 운영 지식 요구, 관리 포인트 증가

통신 방식과 부하분산이 맞물리는 지점

세션 변경분은 멀티캐스트나 유니캐스트로 복제된다. 멀티캐스트는 구성이 단순하지만 클라우드 네트워크에서 제한되는 경우가 많고, 유니캐스트·정적 멤버십을 쓰면 설정 관리가 늘어난다. 스티키 세션은 네트워크·직렬화 비용을 줄여 처리량을 끌어올리지만 세션 손실 위험은 Failover 경로로 완화해야 하고, 비스티키 구성은 분산 효율은 높아지는 대신 복제 비용이 커진다 — 트래픽 패턴과 세션 크기에 따라 최적점을 찾아야 하는 부분이다. 스티키 세션을 적용하면 처리량이 3070% 향상되고, 풀 복제 대비 네트워크 오버헤드는 520%p 줄어든다. 노드가 죽으면 백업 세션이나 외부 세션 저장소에서 재구성되고, RTO는 헬스체크 주기와 세션 복구 비용으로 결정된다. 세션 복구 12 RTT를 기준으로 RTO 1030초를 달성하는 것이 목표이고 세션 손실률은 0%를 지향한다. Auto Scaling 이벤트가 발생하면 신규 노드가 멤버십에 반영되고 세션 파티셔닝·백업이 재배치된다. 다만 세션 동시 업데이트, 분산락, 직렬화 호환성 문제로 운영 복잡도가 올라가기 때문에 세션은 최소화·불변화하는 정책이 사실상 필수이고, 관측성과 카나리 롤아웃·세션 마이그레이션 전략도 함께 갖춰야 한다.

⤢✕

Tomcat으로 직접 구성하기

수평 확장은 머신·컨테이너 수를 늘리는 방식으로 Auto Scaling과 궁합이 좋다. 이 경우 스티키 세션과 외부 세션(또는 데이터그리드)을 결합해 복제 비용을 최소화하는 편이 권장된다. 수직 확장은 단일 머신의 리소스를 늘리는 방식으로 세션 복제 비용 자체는 달라지지 않지만 메모리 여유가 늘어난다. 이 경우 세션 크기 제한과 오브젝트 풀·GC 튜닝을 병행하는 것이 좋다.

Tomcat 9/10, JDK 11+ 환경을 기준으로, 동일한 애플리케이션 버전과 동일한 session serialization 규약이 전제되고, 멀티캐스트가 불가능한 환경에서는 정적 멤버십이나 외부 세션을 쓴다. DeltaManager 기반 유니캐스트 구성은 server.xml에서 이렇게 정의한다.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
  <Manager className="org.apache.catalina.ha.session.DeltaManager"/>
  <Channel className="org.apache.catalina.tribes.group.GroupChannel">
    <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
              address="0.0.0.0" port="4000" autoBind="100" selectorTimeout="5000"/>
    <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
      <Transport className="org.apache.catalina.tribes.transport.nio.NioSender"/>
    </Sender>
    <Membership className="org.apache.catalina.tribes.membership.StaticMembershipService">
      <Member className="org.apache.catalina.tribes.membership.StaticMember"
              host="10.0.0.10" port="4000" domain="prod"/>
      <Member className="org.apache.catalina.tribes.membership.StaticMember"
              host="10.0.0.11" port="4000" domain="prod"/>
    </Membership>
  </Channel>
  <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"/>
</Cluster>

네트워크 비용을 더 줄이고 싶다면 BackupManager로 1:1 백업만 유지하는 대안도 있다.

<Manager className="org.apache.catalina.ha.session.BackupManager" expireSessionsOnShutdown="false"/>

운영에서는 로드밸런서에 스티키 세션을 우선 적용하고 장애 시에만 비스티키로 폴백하는 편이 안전하다. 헬스체크 간격은 25초로 두고 연속 실패 카운트를 기준으로 노드를 격리한다. 세션은 416KB를 목표로 불변 DTO에 담고 대용량 객체는 외부 저장소로 분리하며, 직렬화 버전 UID를 관리하고 순환 참조는 피해야 한다. 트래픽 급증·노드 장애·스케일 아웃 이벤트가 발생하면 신규 노드가 조인하고 멤버십이 갱신된 뒤 세션 파티션·백업이 재배치되며, 목표는 세션 지속성을 유지한 채 RTO 내에 정상화하는 것이다. 직렬화에 실패하면 세션을 재생성하고 사용자에게 재인증을 유도하는 로그·알람이 필요하다. 자동 Failover와 관측성을 갖추면 장애당 인시던트 처리 시간을 50% 이상 단축할 수 있다.

어디에 쓰는가

이커머스 트랜잭션에서는 장바구니·체크아웃 도중 노드 장애가 나도 세션이 무손실로 유지돼야 하고, 재시도·결제 이중화와 결합해 환불·중복 처리를 최소화한다. 모바일 API 백엔드는 오토스케일링 트래픽 스파이크에 대응해야 하고, 토큰과 세션을 하이브리드로 써서 속도와 보안의 균형을 잡으며 지역 간 레이턴시 차이는 데이터그리드 레플리카 정책으로 완화한다. SaaS 멀티테넌트 환경에서는 테넌트 파티션별로 세션을 격리·백업하고, 롤링 업그레이드 시에도 세션을 공유해 무중단 배포를 실현한다.

스티키 세션과 외부 세션(또는 데이터그리드) 조합이 오토스케일링·클라우드 환경에는 가장 잘 맞고, 온프레미스·고정 토폴로지에서는 Tomcat의 Delta·BackupManager 복제만으로도 충분히 단순하게 운영할 수 있다. 세션을 최소화·불변화하고 직렬화 규약을 엄수하며 장애 복구 리허설을 정례화하는 것이 기본이고, 초기에는 관리형 Redis 같은 세션 서버로 빠르게 시작한 뒤 트래픽·비용 곡선에 따라 데이터그리드로 확장하는 순서가 현실적이다.