28장 세션과 상태가 롤링 배포의 진짜 경계다
두 Tomcat에 WAR를 올렸다고 무중단이 되는 것은 아니다. 로그인 session이 인스턴스 메모리에만 있으면 트래픽이 다른 노드로 이동할 때 로그아웃되거나 장바구니가 사라질 수 있다. 먼저 상태를 분류한다.
| 상태 | 위치 | 배포 영향 | 선택지 |
|---|---|---|---|
| HTTP session | Tomcat 메모리 | 재시작·노드 전환 | sticky, replication, 외부 session |
| 로컬 cache | JVM heap | 버전 간 불일치 | 만료·버전 key·외부 cache |
| 업로드 임시 파일 | 로컬 disk | 다른 노드가 못 봄 | object/shared storage, 업로드 고정 |
| 예약 작업 상태 | 메모리/DB | 중복 실행 | durable state, leader/lock |
Tomcat cluster의 session replication은 설정 한 줄로 끝나지 않는다. session attribute가 직렬화 가능해야 하고, 모든 노드의 class와 설정이 맞아야 하며, replication 네트워크를 신뢰된 구간으로 제한해야 한다. 전체 복제는 노드와 session이 늘수록 비용이 커질 수 있다. sticky session은 복제를 줄이지만 노드 장애 때 상태 손실 가능성을 없애지 않는다.
새 WAR가 session 객체 class를 바꾸면 구버전이 만든 session을 새 버전이 읽지 못할 수 있다. 롤링 window에서는 세션 스키마를 양방향으로 읽거나, session을 비우는 사용자 영향과 공지를 승인해야 한다.
실습 28 세션 failover
가상 사용자 S-104가 node-a에 로그인했다고 가정한다. node-a drain, node-b 이동, 구·신 WAR 혼재, rollback 네 시점에서 session 기대 결과를 쓴다. “sticky니까 안전” 대신 노드 장애와 쿠키 route가 바뀔 때의 결과를 시험한다.