요청자 "ㄱ"이 로그인 요청을 보냄

→ A서버가 받아서 처리 이후, 새로운 요청을 전송

→ C서버가 전달받았는데 C서버의 세션에는 로그인 정보가 없음

“대용량 트래픽 처리를 위한 부하 분산을 해결하는 과정에서
나타난 세션 관리의 문제”에 대한 해결 방안들

---

Sticky Session

특정 세션의 요청을 처음 처리한 서버로 전송

→ 첫 요청 이후의 해당 클라이언트의 모든 요청을 특정 서버로 고정하여 세션을 관리

= 이를 위해 Cookie를 사용하거나, IP tracking을 하는 방식이 있음.

• 단점

1. 로드 밸런싱이 의도한대로 작동하지 못할 수 있음
2. 특정 서버만 과부화가 올 수 있음
3. 특정 서버 Fail시 해당 서버에 붙어있는 세션이 모두 소실될 수 있음.

---

Session Clustering

세션들을 하나로 묶어 클러스터로 관리
각 WAS(Web Application Server)들은 세션을 각각 가지고 있는데,

이를 하나로 묶어 클러스터로 관리하는 기법

-> 하나의 WAS가 fail이 발생하면 세션은 다른 WAS로 이동되어 관리됨.

• 주의점

  1. 각 서버마다 세션 클러스터링 방식, 지원하는 방식이 달라서

     현재 사용하고 있는 WAS의 session clusturing 부분을 보고 확인해야 함.

  2. 새로운 서버가 추가될 때마다 기존에 존재하던 WAS에

     해당 서버의 IP/PORT를 입력하여 클러스터링 해줘야함.

---

Session Server 분리

세션만 관리하는 캐시 서버(Redis DB)를 두어 관리한다.

새로운 서버를 생성하더라도 해당 서버에만 세션 서버의 정보를 알려주고 연결해주면 됨.

-> 기존 서버의 수정이 발생하지 않음.

• 단점 : Redis Session Server가 죽는 순간 모든 세션이 사라진다.

Ref: 참조 : https://developer111.tistory.com/69