Sticky Session vs Stateless 아키텍처(Redis, JWT)

Stateless 아키텍처가 무엇인지 궁금했었다. 

Load Balancer를 공부하며 Sticky Session에 대해 알게 되었고,

요즘에는 Sticky Session 대신 어떤 것을 더 선호하는지 알아보자.

 

Stick Session(Session Affinity)

출처: 네이버

Affinity는 친밀감을 뜻한다.

• Session Affinity는 말 그대로 세션을 특정 서버에 붙여두는 것을 뜻한다.
• 서버가 세션 데이터를 로컬 메모리에 저장하기 때문에
• 같은 사용자의 요청을 같은 서버로 보내야
• 저장된 세션에 접근이 가능하다.

보통 이것을 쿠키로 구현하는데

• Duration-based cookie(기간 기반)
• Application-based cookie(애플리케이션 기반)

항목	Duration-based	Application-based
쿠키 생성	ALB	애플리케이션
쿠키 이름	AWSALB (고정)	커스텀 (예: SESSIONID)
만료 시점	시간 기반	애플리케이션 로직
로그아웃 처리	불가능	가능
구현 난이도	쉬움	보통
유연성	낮음	높음

 

(AWS SAA 강의에 나오길래 정리해봤다.)

 

하지만 요즘은 마이크로 서비스 아키텍처를 구성하며 Sticky Session을 쓰지 않는 방향으로 바뀌고 있다.

 

Sticky Session을 사용했던 이유는 특정 서버의 메모리에 세션이 저장되어 있어

사용자의 요청이 무조건 "그" 서버로 가야 했었다. 즉 서버를 늘리더라도 기존 사용자는 새로운 서버를 쓰지 못한다.

 

하지만 어떤 서버가 죽어도 다른 서버는 작동되는 것을 목적으로 하는 마이크로 서비스 아키텍처에서

Sticky Session처럼 서버의 메모리에 세션이 저장되어 있으면 

• 특정 서버가 죽으면 그 서버의 세션 정보가 사라져 해당 서버 사용자들이 로그아웃 됨
• 다른 서버들은 정상 작동하지만, 세션 정보가 없어 해당 사용자 처리 불가능

즉, 수평 확장이 어렵고, 서버 간 부하 불균형이 발생할 수 있다. (고가용성을 달성하기 어렵다.)

---

따라서 Redis/DynamoDB 사용하여 중앙에서 관리하도록 하거나,

JWT를 사용하여 Stateless 하도록 하는 것이다. 

Redis/DynamoDB

(DynamoDB는 AWS의 noSQL 서비스다.)

Redis나 DynamoDB를 사용하면 여기에 세션을 저장해 둔다. 

 

사용자 로그인 → 서버 1 → Redis에 세션 저장

다음 요청 → 서버 2로 가도 OK → Redis에서 세션 읽어옴

또 다음 요청 → 서버 3으로 가도 OK → Redis에서 세션 읽어옴

 

이런 식으로 Redis에서 중앙관리를 하기 때문에 어떤 서버로 가도 상관없게 만들 수 있다. 

 

JWT

Jwt 토큰을 사용하면 완전 stateless로 구현이 가능하다. 이거는 아예 서버에 세션 저장을 안 하는 방법이다.

 

사용자 로그인 → 서버가 JWT 토큰 발급 (서버에 저장 안 함)

다음 요청 → 서버 2 → JWT 검증만 함

또 다음 요청 → 서버 3 → JWT 검증만 함

 

마치 신분증을 들고 다니면서 서버에서는 검증만 하는 구조이다. 

 

하지만 전부 장점만 있는 건 아니다. 

---

Redis 세션 관리 시 단점

• 만약 redis가 다운되면 전체 서비스 세션이 불가해진다.
• redis를 조회하는 오버헤드가 발생한다.
• redis를 운영하는 인프라 비용이 발생한다.
• 데이터 일관성 문제가 발생할 수 있다. 
  • 서버 1에서 세션을 업데이트하는 동시에 서버 2가 읽으면 문제가 발생할 수 있다. (Race condition)

JWT의 단점

• 즉시 무효화가 불가능하다. (토큰 탈취가 가능할 수 있다.)
• 상태 변경이 반영되지 않는다. (토큰 만료까지 기다려야 함.)

---

이것을 어느 정도 보완하는 하이브리드 방식을 이전 프로젝트 때 사용했다.(현업에서도 가장 많이 쓰이는 거 같다.)

JWT + Redis 블랙리스트

여기서 JWT는 access token과 refresh token을 함께 사용한다.

 

핵심은

• Access Token 재발급 시에만 Redis를 확인한다.
• 로그아웃 하면 Refresh Token을 Redis에 블랙리스트에 등록한다. 

 

따라서 Access Token이 유효할 때는 JWT의 강점인 stateless 한 상태를 유지할 수 있다. 

redis를 거칠 필요 없이 바로 검증만 진행하는 것이다.

 

하지만 Access Token이 만료되었을 때 Refresh Token이 유효한지 Redis로 확인한 후 발급한다.

Pure JWT의 문제점

로그아웃해도 토큰이 만료될 때까지 유효하다.

Access Token(15분)은 그렇다 치고,

Refresh Token(7일)까지 계속 작동한다.

→ 로그아웃이 의미가 없다

Redis 블랙리스트로 개선

Refresh Token을 블랙리스트에 등록하여

더 이상 새 Access Token을 발급받을 수 없게 한다.

→ Access Token 만료(15분) 후 완전 차단

→ "즉시 무효화"는 아니지만 "짧은 시간 내 무효화" 달성

 

 

이렇게 요즘은 무상태 인증을 통해 서버를 수평확장하는 것이 더 유리한 상황이다. 

 

Sticky Session을 사용하면 구현이 간단하고 추가 인프라가 불필요하지만 확장성이 떨어진다는 점을 알고

각 Redis를 이용한 세션, JWT만 쓴 방법, 그리고 JWT+ Redis를 쓰는 방식의 장단점을 알고 있으면 좋을 거 같다.