Sticky Sesisons(Session Affinity)
클라이언트가 로드 밸런서에 두 번의 요청을 할 때 백엔드에서 동일한 인스턴스가 요청에 응답하도록 하는 것
=> 여러 대의 서버가 있어도, 특정 사용자의 요청을 계속 같은 서버로 보내주는 기능
CLB, ALB, NLB에서 활성화 할 수 있음
- 동작 방식
클라이언트가 로드 밸런서로 요청을 보낼 때 쿠키(스티키니스 + 만료날짜 포함된)가 함께 전송
=> 이 쿠키가 만료되면 클라이언트가 다른 EC2 인스턴스로 리다이렉션 될 수 있음
-
ALB에서 sticky session의 동작
1) 쿠키 기반 세션 고정
ALB는 쿠키(cookie) 를 사용해서 세션을 고정
-
사용자가 ALB에 요청을 보냄
-
ALB가 자기 마음대로(정책에 따라) EC2 하나를 골라서 보냄 (예: EC2 #2)
-
그리고 응답할 때 특별한 쿠키를 내려 줌:
예: AWSALB, AWSALBTG 같은 이름
이 쿠키 안에는:
- “이 사용자 → 어떤 Target Group/Target으로 붙었는지”에 대한 정보가 들어 있음
그 다음 요청부터는:
-
브라우저가 ALB에 요청을 할 때 그 쿠키를 같이 보냄
-
ALB는 쿠키를 보고:
“아 이 유저는 예전에 EC2 #2에 붙어 있던 애네?”
→ 다시 EC2 #2로 고정해서 보냄
2) 세션 지속 시간(만료 시간)
ALB의 sticky session은 “타임아웃(지속 시간)”을 설정할 수 있음예: 300초(5분), 3600초(1시간) 등
즉, 그 시간 동안은 → 같은 Target으로 고정
시간이 지나면:
쿠키가 만료 → 다시 로드 밸런서 정책(라운드 로빈 등)에 따라 다른 서버로 갈 수도 있음
-
-
Sticky Session의 Use-case
-
세션을 서버 메모리에 저장하는 레거시 애플리케이션
-
서버가 사용자 상태를 메모리에 들고 있을 때
- 시험 시스템(남은 시간/문제 상태가 메모리에 저장)
- 실시간 설문/게임 룸 상태
-
WebSocket / Long Polling 기반 서비스
- WebSocket 핸드셰이크나 Long Polling 요청은 서버와 계속 이어지는게 안정 적
-
큰 파일 업로드
- 대용량 업로드 과정에서 서버가 "현재 몇 MB 전송됨" 같은 상태를 메모리에 보유
-
-
Sticky Session의 단점
-
트래픽 분산이 불균형해질 수 있음(특정 서버에 트래픽 몰림)
-
서버가 죽으면 그 유저의 세션도 바로 날아감
-
Auto Scaling 시 새 서버로 교체되면 sticky가 무용지물될 수 있음
-
Stateless 아키텍처의 장점을 못 가져감
Sticky Session을 위한 쿠키의 종류
-
-
애플리케이션 기반 쿠키
-
커스텀 쿠키(Custom Cookie)
- 애플리케이션 자체(target group?)에서 생성하는 사용자 정의 쿠키
- 애플리케이션에서 필요로 하는 모든 사용자 정의 속성 포함 가능
- 쿠키 이름은 각 타켓 그룹마다 개별적으로 지정
- AWSALB, AWSALBAPP, AWSALBTG와 같은 이름들은 사용해선 안 됨!! => 예약어
-
애플리케이션 쿠키(Application Cookie)
- 로드 밸런서 자체에서 생성
- 쿠키 이름 = AWSALBAPP
-
-
지속 시간 기반 쿠키
- 로드 밸런서에서 생성
- 쿠키이름: ALB => AWSALB / CLB => AWSELB
- 특정 시간에 따라 만료되며 지속 시간은 로드 밸런서 자체에서 생성
- 애플리케이션 기반 쿠키가 있을 때는 지속 시간을 애플리케이션 자체에서 지정 가능
Sticky Session 설정 실습
대상그룹(Target Group) => 속성 변경(Edit Attributes) => Stickiness 옵션
새로고침 후 DNS Name 주소로 접근하면
