Session Clustering 방식

All-to-all Session Replication : DeltaManager

하나의 세션 저장소에 변경되는 요소가 발생하면 변경된 사항이 다른 모든 세션에 복제가 되는 것

이 방식대로 세션을 복제한다면 유저가 어떤 서버에 접속하더라도 로그인 정보가 세션에서 복제되어 있으므로 정합성 이슈가 해결 가능하다. 하지만 동일한 세션 객체를 가져야 하므로 많은 메모리가 필요하며, 서버 수에 비례하여 네트워크 트래픽이 증가할 수 있다.

하지만 4개 미만의 소규모 클러스터에서는 좋은 효율을 보여준다고 할 수 있다.

 

Primary-secondary Session Replication : BackupManager

서버 1과 서버 2에 세션 객체의 key-value 전체를 복제해두고 그 외 서버에서는 세션 key에 해당하는 값만을 복제하는 방식으로, all-to-all 방식에 비해 시간이 절약될 수 있다. 하지만 primary 서버와 secondary 서버를 제외한 서버에 세션 정보를 요청하게 되는 경우 세션 key에 해당하는 세션 객체를 얻기 위해 primary 서버에 질의하는 과정이 추가적으로 필요하게 되므로 성능적 한계가 존재한다.

 

Session Storage

Redis, Memcached 등의 서버와 분리된 세션 저장소를 활용하는 방법으로, 서버의 증감과 상관없이 세션 스토리지에 대한 정보만 각각의 서버에 입력해주면 세션을 공유할 수 있게 된다.

이러한 방식은 Sticky Session 사용 시 문제가 될 수 있는 트래픽 쏠림 현상을 해결할 수 있으며,  서버가 장애가 발생하더라도 별도의 세션 저장소가 존재하므로 서비스를 계속해서 제공할 수 있는 고가용성도 확보 가능하다.

그러나 SPoF가 될 여지가 있어, 세션 객체를 복제할 필요가 있다.

그래서 대규모 서비스에서는 ElastiCache와 같은 관리형 서비스를 활용해서 이 문제를 해결하기도 한다.