분산 시스템에서 세션 관리를 위한 3가지 방법
세션 관리 방법 3가지
- Sticky Session: 클라이언트마다 담당 처리 서버를 지정하는 방법
- Session Clustering: 서버끼리 실시간으로 싱크를 맞추는 방법
- Session Storage: 외부 세션 저장소를 활용하는 방법 (ex Redis)
고정 세션(Sticky Session) 방식
이 방식은 클라이언트 요청을 특정 서버로 고정시키는 방법이다. 문제는 특정 서버에 트래픽이 몰릴 수 있고, 장애가 발생하면 해당 서버에 고정된 클라이언트들이 로그인을 다시 해야 하는 가용성 문제가 발생할 수 있다.
Session Clustering 방식
각 서버의 세션 저장소를 클러스터로 묶고, 클러스터 내 저장소들 간에 세션을 실시간으로 동기화하는 방식이다. 이때 사용되는 전파 방식에는 모든 서버로 세션을 복제하는 All-to-All Replication 방식과, Primary 서버와 Secondary 서버에만 세션을 복제하고 나머지 서버에는 세션ID만 복제하는 Primary-Secondary Session Replication 방식이 있다. 두 방식 모두 전파 과정에서 많은 네트워크 트래픽 사용, 복제로 인한 메모리 낭비, 시간차로 인한 세션 불일치 문제 등이 있다.
Session Server 방식
세션 저장소를 외부 서버로 분리하여 관리하는 방식이다. 저장소는 주로 In-Memory DB인 [[Redis]]를 사용한다. Disk-based DB(Ex: Mysql, PostgreSQL, MongoDB, ...)를 선택할 수도 있지만 I/O로 인한 오버헤드가 크며, 세션은 소멸성 데이터이기 때문에 영속성을 보장할 필요가 없다. 또한, 메모리 휘발에 의해 세션 데이터가 소멸되더라도 피해가 상대적으로 적기 때문에 In-Memory DB 사용을 권장한다.
세션 저장소를 분리함으로써 Sticky Session의 트래픽 몰림 문제와 Session Clustering의 메모리 낭비, 세션 불일치 문제 등을 해결할 수 있다.
그러나 단일 세션 서버로 구성한 경우에는 아직 가용성 문제가 남아있다. 서버에 장애가 발생하면 모든 서버에 영향을 미칠 수 있기 때문에 일반적으로는 1개의 Master 서버와 N개의 Slave 서버로 구성하여 가용성을 향상시키는 것이 권장된다. Master 서버는 Write 작업을 처리하고, Slave 서버는 Master 서버의 데이터를 복제하여 Read 작업을 처리하는 역할을 한다.
REFERENCE