클라우드에서 서버 이중화 시, 세션은 어떻게 설계해야 하는가

 

클라우드에서 서버 이중화는 어렵지 않다.

• VPC 구성
• 서로 다른 AZ에 WAS 2대 이상 배치
• Load Balancer 연결
• Auto Scaling 설정

이 정도는 이제 기본이다.

하지만 실제 운영에서 문제를 일으키는 지점은 따로 있다.

서버 이중화의 핵심은 인프라가 아니라 세션 설계다.

---

1. 왜 세션이 문제인가

서버가 1대일 때는 문제가 없다.

 

사용자 → WAS(메모리 세션)

하지만 2대 이상이 되면 상황이 달라진다.

 

사용자 → LB → WAS1 → WAS2

로그인 후 다음 요청이 다른 서버로 전달되면
세션이 존재하지 않아 로그인이 풀릴 수 있다.

특히 공공기관 시스템이나 SSO 연동 구조에서는
로그인 이후 애플리케이션이 자체 세션을 유지하는 경우가 많다.

이때 세션이 서버 메모리에 있다면 이중화는 불완전하다.

---

2. 클라우드 이중화 시 세션 설계 방식

① Sticky Session (임시방편)

Load Balancer가 특정 사용자를 항상 동일 서버로 보낸다.

장점:

• 설정 간단
• 코드 수정 거의 없음

단점:

• 서버 장애 시 세션 소멸
• Auto Scaling 의미 감소
• 근본 해결 아님

---

② Spring Session + RDB

세션을 데이터베이스에 저장한다.

 

WAS1 \ → PostgreSQL WAS2 /

장점:

• 구현 쉬움
• 공공/SI 환경에 적합
• 기존 MVC 구조 유지 가능

단점:

• 요청마다 세션 갱신으로 DB write 증가
• 고트래픽 환경에서는 병목 가능성

---

③ Spring Session + Redis

세션을 인메모리 캐시에 저장한다.

장점:

• 성능 우수
• 확장성 높음
• 실무에서 가장 일반적인 방식

단점:

• Redis 장애 시 로그인 전체 영향
• 별도 인프라 운영 필요

---

④ JWT 기반 Stateless 설계

애플리케이션이 세션을 저장하지 않는다.

 

Client (JWT 보관) ↓ WAS (토큰 검증만 수행)

장점:

• 서버 수와 무관
• Auto Scaling 최적화
• 멀티 리전에도 유리

단점:

• 로그아웃/토큰 만료 설계 필요
• 보안 설계 중요

---

3. SSO 연동 시스템에서의 주의점

많은 시스템이 SSO를 사용한다고 해서
자동으로 이중화가 된다고 생각한다.

하지만 SSO는 인증 과정을 처리할 뿐이다.

SSO 로그인 이후 애플리케이션이 JSESSIONID를 발급하고
서버 메모리에 세션을 저장한다면,
이중화 시 동일한 세션 문제가 발생한다.

따라서 반드시 확인해야 한다.

• 로그인 유지가 서버 세션인가?
• LB 뒤에 세션 외부화가 되어 있는가?
• 세션 암호화 키가 서버 간 동일한가?

---

4. 결론

클라우드는 서버를 쉽게 늘릴 수 있다.
그러나 세션을 자동으로 해결해주지는 않는다.

이중화의 핵심은
“서버 메모리에 상태를 두지 않는 것”이다.

Sticky는 편의,
RDB/Redis는 외부화,
JWT는 무상태.

시스템 특성에 맞는 선택이 필요하다.

---

한 줄 요약

서버를 두 배로 늘리는 것보다 중요한 것은
세션을 어디에 둘 것인지 결정하는 것이다.