AWS ALB 스티키 세션(Sticky Session) 동작 원리 및 적용 방법

안녕하세요

AWS에서 애플리케이션을 운영하다 보면 한 번쯤은 마주치게 되는 기능, 바로 '스티키 세션(Sticky Session)'입니다. "로그인을 했는데 자꾸 풀려요!", "장바구니에 담은 물건이 사라졌어요!" 이런 문제를 해결해 주는 구원투수이자, 때로는 트래픽 불균형의 주범이 되기도 하는 양날의 검이죠.

 

오늘은 AWS ALB(Application Load Balancer)의 스티키 세션이 정확히 어떻게 동작하는지, 쿠키는 어떻게 생성되고 트래픽은 어떻게 흘러가는지 아주 깊이 있게 파헤쳐 보겠습니다. 

 

 

 

1. 스티키 세션, 도대체 왜 필요한가요? 

웹 서버는 기본적으로 '기억상실증(Stateless)' 환자입니다. 클라이언트가 A 서버에 "나 철수야"라고 말하고, 다음 요청을 B 서버에 보내면 B 서버는 "누구세요?"라고 묻습니다. 이런 문제를 해결하기 위해 우리는 세션(Session)을 유지해야 합니다. 가장 쉬운 방법은 "철수는 무조건 A 서버 하고만 대화해!"라고 정해주는 것입니다. 이것이 바로 스티키 세션(Sticky Session, 세션 고정)입니다.

• 주요 사용 사례: 로그인 세션 유지, 쇼핑몰 장바구니, 대화형 챗봇 등 연속성이 필요한 서비스
• ALB의 역할: 클라이언트에게 "너는 A 서버로 가라"는 표식(쿠키)을 붙여주고, 이 표식을 가진 요청은 무조건 A 서버로 배달합니다.

 

---

2. ALB는 어떻게 '기억'할까요? (동작 원리 심층 분석)

ALB의 스티키 세션은 100% 쿠키(Cookie) 기반으로 동작합니다. 하지만 상황에 따라 두 가지 방식이 있습니다.

2-1) 기간 기반 쿠키 (Duration-Based): "내가 정한 시간만큼만 붙어 있어!"

ALB가 자체적으로 쿠키를 발급하고 관리합니다. 가장 흔하게 쓰이는 방식입니다.

1. 최초 요청: 클라이언트가 요청을 보냅니다. (쿠키 없음)
2. 대상 선택: ALB는 기본 알고리즘(라운드 로빈 등)으로 Server-A를 선택합니다.
3. 쿠키 발급: 응답 헤더에 Set-Cookie: AWSALB=...를 추가합니다. 이 암호화된 값 안에 "Server-A로 가라"는 정보가 들어있습니다.
4. 후속 요청: 클라이언트가 AWSALB 쿠키를 달고 요청을 보냅니다.
5. 라우팅: ALB는 쿠키를 해독하고, 라운드 로빈을 무시한 채 Server-A로 직행시킵니다.
6. 만료: 설정한 시간(예: 1시간)이 지나면 쿠키가 만료되고, 다시 새로운 서버를 배정받습니다.

2-2) 애플리케이션 기반 쿠키 (App-Based): "앱 세션이랑 운명을 같이해!"

애플리케이션이 발급한 세션 쿠키(예: JSESSIONID)와 수명을 함께합니다. 로그아웃하면 스티키 세션도 끝나는, 좀 더 똑똑한 방식입니다.

1. 쿠키 매핑: 서버가 JSESSIONID를 발급하면, ALB가 이를 감지하고 짝꿍 쿠키인 AWSALBAPP를 추가로 붙여줍니다.
2. 샤딩(Sharding) 주의보: AWSALBAPP 쿠키는 꽤 큽니다. 브라우저 용량 제한(4KB)을 넘으면 ALB가 알아서 AWSALBAPP-0, AWSALBAPP-1 처럼 쪼개서(Sharding) 보냅니다. 헤더가 너무 커지지 않도록 주의해야 합니다!

 

 

---

3. ALB가 여러 개라면? (다중 로드 밸런서 시나리오)

"ALB를 거치고 또 다른 ALB를 거치는 구조라면 어떻게 될까요?"

• 정답: 스티키 세션은 단 하나의 로드 밸런서에서만 활성화해야 합니다.
• 이유: 첫 번째 ALB가 AWSALB 쿠키를 붙였는데, 두 번째 ALB가 또 자신의 AWSALB 쿠키로 덮어씌우면(Override), 클라이언트는 길을 잃어버립니다. 최종적으로 트래픽을 받는 ALB에서만 스티키 세션을 켜는 것이 정석입니다.

 

 

---

4. 서버가 죽으면 내 세션은? (Failover 메커니즘)

만약 내가 고정된 Server-A가 갑자기 고장(Unhealthy) 나면 어떻게 될까요? 내 장바구니는 사라질까요?

1. 즉시 손절: ALB는 쿠키에 적힌 대상이 비정상임을 감지하는 순간, 그 쿠키를 무시합니다.
2. 새 출발: 라운드 로빈으로 살아있는 Server-B를 새로 선택합니다.
3. 쿠키 갱신: 응답 시 Server-B 정보가 담긴 새로운 쿠키를 발급하여 클라이언트에게 줍니다.
4. 데이터 유실: 중요! 이때 Server-A의 메모리에만 있던 세션 데이터는 사라집니다. 그래서 Redis 같은 외부 세션 저장소(ElastiCache)를 쓰는 것이 진정한 해결책입니다.

 

 

 

---

5. 설정 방법 (AWS 콘솔 가이드)

설정은 매우 간단합니다. 클릭 몇 번이면 끝납니다.

1. AWS 콘솔 접속: EC2 대시보드 -> 로드 밸런싱 -> 대상 그룹(Target Groups)으로 이동.
2. 속성 편집: 원하는 대상 그룹 선택 후 [속성] 탭에서 [편집] 클릭.
3. 고정(Stickiness) 켜기:
   • 유형: '로드 밸런서 생성 쿠키' 또는 '애플리케이션 기반 쿠키' 선택.
   • 지속 시간: 유지할 기간 설정 (1초 ~ 7일).
4. 저장: 끝! 이제 트래픽이 끈끈하게 붙습니다.

 

 

 

6. 결론

간단한 웹 서비스나 레거시 앱이라면 스티키 세션이 여전히 유효합니다. 하지만 고성능 AI 서비스나 대규모 트래픽을 다룬다면, Redis로 세션을 밖으로 빼고 스티키 세션을 끄는 것이 정답입니다.

 

 

7. 참고자료

• https://mihirpopat.medium.com/understanding-elb-sticky-sessions-when-and-why-you-should-use-them-1a8ba7eb1eb2
• https://medium.com/@christyst10/setting-up-sticky-session-in-aws-load-balancer-762967ea7d84
• https://salfarisi25.wordpress.com/2024/04/28/1807/
• https://medium.com/@jinendra.p/a-problem-with-aws-alb-stickiness-c54fce0080f5
• https://andrewbaker.ninja/2025/11/06/deep-dive-aws-nlb-sticky-sessions-setup-behavior-and-hidden-pitfalls-stickiness/