Sticky Session
Sticky Session이 나오게 된 배경
일반적으로 대용량 트래픽을 장애 없이 처리하기위해 여러 대의 서버에 적절히 트래픽을 분배하는 로드 밸런서를 사용합니다. 그림으로 살펴보면 아래와 같은 상태로 서버가 구성되어 있을 수도 있습니다.
이렇게 로드 밸런싱이 필요한 서비스에는 세션 관리에 문제가 생길 수도 있습니다.
- 먼저 로그인 요청을 A 서버로 보냅니다.
- A 서버의 세션에는 martin이라는 값이 저장됩니다.
- A 서버에서는 로그인 성공이라는 응답을 보냅니다.
- 동일한 클라이언트는 로드 밸런서에 새로운 요청을 보냅니다.
- 그러나 이 요청은 C 서버로 전달됩니다.
- C 서버의 세션에는 이 사용자가 로그인 한 사용자라는 정보가 없기 때문에, 조회 실패 후 로그인 페이지로 리다이렉트 하도록 응답을 보 냅니다.
위의 설명과 같이, 방금 로그인을 했는데 다시 로그인을 하라는 사태가 발생할 수 있습니다. 이러한 세션 관리의 문제를 해결하기 위해 Sticky Session을 사용합니다.
Sticky Session이란
Sticky Session의 개념
Sticky Session이란 특정 세션의 요청을 처음 처리한 서버로만 전송하는 것을 의미합니다.
위의 그림과 같이 첫 요청 이후의 모든 요청을 특성 서버로 고정하는 방법으로 세션을 관리합니다. 일반적으로 Sticky Session을 유지하기 위해 Cookie를 사용하거나 클라이언트의 IP tracking하는 방식이 있습니다.
Sticky Session의 단점
- 로드 밸런싱이 의도한대로 잘 동작하지 않을 수도 있습니다.
- 특정 서버만 과부하가 올 수 있습니다.
- 특정 서버 Fail시 해당 서버에 붙어있는 세션들이 모두 소실될 수 있습니다.
Sticky Session의 단점을 해결하는 방안
Session들을 하나로 묶어 클러스터로 관리
각 WAS들은 세션을 각각 가지고 있지만, 이를 하나로 묶어 하나의 클러스터로 관리하는 방법이 있습니다. 이 상태에서 하나의 WAS가 fail이 발생하면 해당 WAS가 들고 있던 세션은 다른 WAS로 이동되어 관리됩니다. 다만, 각 서버마다 세션 클러스터링 방식이 다르고 지원하는 방식이 다르기 때문에 현재 사용하고 있는 WAS의 session clusturing 부분을 보고 확인해야 합니다. 그리고 이 방식은 새로운 서버가 하나 추가될 때마다 기존에 존재하던 WAS에 새로운 서버의 IP/PORT를 입력해서 클러스터링 해줘야 하는 단점이 있습니다.
Session Server 분리
위의 그림과 같은 방식은 새로운 서버를 생성하더라도 해당 서버에만 세션 서버의 정보를 적어주고 연결해주면 되기 때문에 기존 서버의 수정이 발생하지 않는다는 장점이 있습니다. 다만 세션 서버의 중요성이 올라가고, 세션 서버가 죽는 순간 모든 세션이 사라지기 때문에 세션 서버의 다중화도 고려해보아야 할 점입니다.