시작하기 전에...
Sticky Session과 Session Clustering을 정리하기 전에, 미리 알아둬야 되는 개념이 있습니다.
쿠키와 세션이 무엇인지 인지를 하고 있어야 하고, 내용을 다루다가 언급될 Redis에 대해서 이해하고 있으면 편합니다.
추가적으로, 해당 내용은 사용자의 세션 관리에 관련된 내용이므로 JWT와 비교하는 것이 언급될 수 있다는 점을 적어놓고 시작하겠습니다.
필요성
현대 네트워크는 트래픽의 규모가 커짐에 따라 서버의 인스턴스도 늘어나고 있습니다. 과거의 서버들과는 다르게 논리적인 서버는 1개일지라도 물리적인 서버가 여러 개인 상황이 늘어나고 있다는 것입니다.
보통 이러한 환경에서는 요청을 적절하게 분산하기 위해서 로드 밸런서를 활용합니다.
이러한 분산된 환경에서 세션의 사용은 어렵습니다. 세션은 사용자가 웹 사이트를 방문할 때 서버측에 저장되는 일시적인 데이터이기 때문에 분산된 환경에서는 각각의 물리적인 서버의 세션이 별도로 관리됩니다.
Sticky Session
Sticky Session은 이러한 단점을 극복하기 위해서 등장한 개념입니다.
스티키 세션은 로드 밸런싱 환경에서 사용되는 세션 관리 전략입니다. 이 전략의 목적은 사용자의 요청을 항상 동일한 서버로 라우팅하여, 사용자의 세션 데이터의 일관성을 유지하는 것입니다.
스티키 세션의 주요 특징
- 세션 일관성:
- 사용자가 서버에 세션을 생성하면, 해당 세션은 특정 서버와 "붙어(Sticky)" 있게 됩니다. 사용자의 후속 요청들은 모두 동일한 서버로 라우팅됩니다.
- 로드 밸런서의 역할:
- 로드 밸런서는 사용자의 요청을 받아 처음 요청을 처리한 서버로 후속 요청을 계속 전달합니다. 이는 쿠키, IP 주소, 또는 다른 세션 식별자를 사용하여 구현될 수 있습니다.
- 세션 데이터의 로컬 저장:
- 각 서버는 자신에게 할당된 사용자의 세션 데이터를 로컬에 저장합니다. 이는 네트워크 오버헤드를 줄이고 세션 접근 속도를 향상시킵니다.
- 서버 간의 세션 데이터 공유 부재:
- 스티키 세션을 사용하는 경우, 다른 서버들은 사용자의 세션 데이터에 접근할 수 없습니다. 따라서, 사용자는 "붙어있는" 서버에 문제가 생길 경우 세션 데이터가 유실될 수 있습니다.
스티키 세션의 장단점
장점
- 세션 데이터에 대한 빠른 접근이 가능합니다.
- 복잡한 세션 데이터 관리 및 동기화 매커니즘이 필요 없습니다.
- 서버 간의 세션 데이터 공유에 따른 오버헤드를 피할 수 있습니다.
단점
- 서버 장애 시 세션 데이터가 유실될 위험이 있습니다.
- 로드 밸런싱의 효율성이 감소될 수 있습니다. 특정 서버에 과부하가 걸릴 수 있습니다.
- 확장성에 제한이 있을 수 있습니다. 세션 데이터가 서버에 종속되기 때문에 수평적 확장이 어렵습니다.
여기서 언급되어 있는 가장 큰 문제는 특정 서버에 과부하가 걸리는 상황입니다. 특정 서버에 과부화가 걸려서 해당 요청이 결국 다른 서버에 보내야되는 상황이 발생한다면 사용자의 데이터는 날라갈 것이고, 재로그인을 요구하던가 불편한 사용자 경험을 제공하게 될 것입니다.
이러한 단점을 극복하기 위해서 여러 서버에서 관리하고 있는 세션 데이터 자체를 공유하는 방식을 고려해볼 수 있습니다.
이를 위해서 사용될 수 있는 것이,
- Session Cluster
- Redis
둘 다 정리를 하도록 하겠습니다.
Session Clustering
Session Clustering은 간단하게 말하자면 각 서버가 가지고 있는 세션들을 공유하여 관리하는 것을 의미합니다. 이는 고가용성과 확장성을 제공해줍니다.
세션 클러스터링 방법에는 여러 가지가 있을 수 있는데, 아래 두 가지를 살펴보겠습니다.
All-to-all Session Replication
'DeltaManager'을 활용한 All-to-all Session Replication는 하나의 세션 저장소에 변경되는 요소가 발생하면 변경된 사항을 다른 모든 세션에 복제가 된다는 것을 의미합니다.
위의 그림과 같이 세션 복제가 모든 서버에서 수행된다면, 데이터의 정합성(값의 일치)를 가져갈 수 있습니다. 하나의 서버에서 장애가 발생하더라도 다른 서버가 해당 값을 가지고 있기 때문에 문제가 없습니다.
하지만, 이것은 모든 서버가 동일한 세션 객체를 가지고 있어야 하기 때문에 많은 메모리가 요구됩니다. 또한, 세션 저장소에 데이터가 저장될 때마다 모든 서버에 값을 입력해야 하므로 서버의 수에 비례하여 네트워크 트래픽이 증가하는 등 성능 저하가 발생합니다.
이를 다소 해결해주는 방법이 primary-secondary Session Replication입니다.
primary-secondary Session Replication
'BackupManager'을 활용한 primary-secondary 세션 복제 방식은 다른 서버에 key 값만을 복제하여 요청이 들어왔을 때 value를 질의하는 방식으로 동작합니다.
서버1(primary)과 서버2(secondary)에 세션 객체의 key-value 전체를 복제해두고 그 외의 서버에는 세션의 key만 복제하는 방식으로, 객체 전체를 복사해야 했던 위의 방식보다 시간이 절약됩니다. 하지만 primary 서버와 secondary 서버를 제외한 서버에 세션 정보를 요청하게 되는 경우 위의 그림과 같이 세션 key에 해당되는 value를 얻기 위해 추가 트래픽이 요구됩니다.
결국 데이터의 정합성을 지키면서 네트워크 트래픽도 고려를 하려면 별도의 Session Storage 서버를 구현하는 것이 좋을 것 같습니다.
여기서, DB를 사용하는 것도 고려할 수 있지만 DB를 사용할 만큼 많은 용량을 요구하는 것이 아니며 빠른 조회를 수행할 수 있어야 하기 때문에 우리는 Redis를 고려해볼 수 있습니다.
Redis를 이용한 Session 관리
레디스 서버를 별도로 구현하여 Session을 관리할 경우, 사용자의 요청이 들어왔을 때 Redis 서버로 질의를 수행하여 사용자의 세션 정보를 가져올 수 있을 것입니다.
Redis는 TTL 기능도 구현할 수 있기 때문에 Session 데이터를 관리하기 적합하며, 빠른 속도로 조회 작업을 수행할 수 있습니다.
하지만 단일 저장소에서 모든 세션 데이터를 관리한다는 것은 단일 장애 지점으로 이어질 수 있기 때문에 이것을 위해서 별도의 작업을 고려해보기도 해야 합니다.
보통 Redis에서는 고가용성을 충분히 제공하기 위해서 사용하는 아키텍처로 Sentinel 구조와 Cluster 구조를 고려해볼 수 있습니다.
참고한 자료
