Sticky Session의 정의
여러 대의 서버로 트래픽을 분산시키는 로드밸런싱 환경에서는, 같은 사용자의 요청이 매번 다른 서버로 전달될 수 있습니다. 이때 특정 사용자의 요청을 항상 동일한 서버로만 보내도록 고정하는 기법을 ‘Sticky Session(고정 세션)’이라고 합니다. ‘Session Affinity’라는 이름으로도 불립니다. 로드밸런서가 클라이언트를 식별해 ‘이 사용자는 무조건 A서버로 보낸다’라는 규칙을 적용하는 것이 핵심입니다.
동작 원리와 예시
Sticky Session은 보통 쿠키를 이용해 구현됩니다. 사용자가 처음 요청을 보내면 로드밸런서가 임의의 서버(예: 서버 A)로 연결을 분배하고, 이후 응답에 ‘AWSALB’나 ‘JSESSIONID’ 같은 쿠키를 심어줍니다. 이 쿠키에는 ‘이 사용자는 서버 A로 연결됨’이라는 정보가 담겨 있어서, 다음 요청부터는 로드밸런서가 쿠키를 확인하고 계속 서버 A로만 트래픽을 보냅니다.
비유하자면 병원 접수처와 비슷합니다. 처음 방문했을 때 배정받은 담당 의사가 있다면, 다음 진료부터는 접수처(로드밸런서)가 ‘이 환자는 원래 김 선생님 담당이니 그쪽으로 보내주세요’라고 안내하는 것과 같습니다. 매번 다른 의사에게 배정되면 환자의 이전 진료 기록을 처음부터 다시 설명해야 하는 불편함이 생기는데, Sticky Session은 이런 문제를 막아줍니다.
AWS ELB나 Nginx 같은 로드밸런서에서는 설정을 통해 이 기능을 켤 수 있습니다. 예를 들어 Nginx에서는 ip_hash 지시어를 사용해 클라이언트의 IP를 기준으로 항상 같은 서버로 연결되도록 만들 수 있습니다.
실무에서 왜 필요한가
웹 애플리케이션에서는 로그인 정보나 장바구니 데이터 같은 세션 상태를 서버의 메모리에 저장하는 경우가 많습니다. 이런 구조에서는 사용자의 요청이 다른 서버로 넘어가는 순간 로그인이 풀리거나 장바구니가 비어버리는 문제가 발생합니다. Sticky Session은 이런 상황을 간단하게 막아주는 방법입니다.
- 구현이 비교적 간단하고 빠르게 적용 가능
- 서버 간 세션 데이터를 공유할 필요가 없어짐
다만 단점도 있습니다. 특정 서버로 트래픽이 몰리면 부하 분산 효과가 떨어지고, 해당 서버에 장애가 발생하면 그 서버에 연결된 사용자들은 세션을 잃게 됩니다. 그래서 최근에는 Redis 같은 외부 저장소에 세션을 통합 관리하는 ‘세션 클러스터링’ 방식을 함께 고려하는 경우가 많습니다. Sticky Session은 빠른 해결책이지만, 서비스 규모가 커질수록 세션 저장소를 분리하는 아키텍처 전환을 고민해볼 필요가 있습니다.