Sticky Session, Session Clustering, Session Storage 분리

Sticky Session

고정된 세션을 말합니다. 클라이언트는 자신의 세션이 저장된 서버에서만 응답을 받게 됩니다. 로드벨런서는 클라이언트의 요청을 받으면 쿠키에 지정된 서버 정보를 확인하고 그 서버로만 요청을 보내게 됩니다. 해당 서버는 클라이언트가 로그인할 때 세션 정보를 저장하고 전달해준 서버이기 때문에 해당 클라이언트에 대한 세션을 가지고 있습니다. 만약 자신의 세션을 저장하고 있는 서버에 대한 정보가 없는 클라이언트의 요청이 온다면 로드 벨런서는 알고리즘을 기반으로 서버를 골라 보내줍니다. 클라이언트는 세션이 유지되는 동안 동일한 서버만을 사용하기 때문에 정합성 이슈에서 자유로워집니다.

 

단점

1. 고정된 세션을 사용한다는 점에서 특정 서버에 트래픽이 집중될 위험이 있습니다. 하나의 서버에 트래픽이 집중되더라도 사용자는 자신의 세션이 없는 다른 서버를 사용할 수 없습니다. 
2. 서비스 중에 하나의 서버에 장애가 발생하게 되면 해당 서버를 사용하는 사용자들은 세션 정보를 잃어버리게 됩니다. 즉, 재로그인이 필요해집니다. → 가용성이 떨어진다.

결론

정합성 이슈를 해결할 수는 있지만 스케일 아웃의 장점인 가용성과 트래픽 분산을 완벽히 사용할 수 없어 보입니다. -> 가용성과 트래픽 분산 때문에 OUT

세션 클러스터링

Tomcat이 제공하는 세션 클러스터링 

1. 'DeltaManager'를 사용한 all-to-all 세션 복제 방식

2. 'BackupManager'를 활용한 primary-secondary세션 복제 방식

 

All-To-All Session Replication

하나의 세션 저장소에서 값 변경이 발생하면 변경된 사항을 다른 모든 세션에 복제하는 것을 말합니다.

단점

1. 모든 서버가 동일한 세션 객체를 가져야 하기 때문에 많은 메모리를 가져야 합니다. 
2. 서버 수에 비례하여 값이 변경될 때마다 서버에 통신하여 저장해야 하므로 네트워크 트래픽이 증가하여 성능 저하가 발생합니다. 

결과

Sticky Session에서 발생한 가용성과 트래픽 분산 문제를 해결한 듯 보이지만 비효율적인 메모리 관리 시스템으로 더 나은 대안을 생각하게 됩니다. 

Primary-Secondary Session Replication

Primary서버는 자신의 Secondary 서버 즉, 백업 서버에게만 세션 객체의 Key-Value 전체를 복제하여 넘겨주고, 다른 서버에게는 Key에 해당하는 JSESSION ID만을 복제하여 넘겨줍니다. 따라서 객체 전체를 넘겨주던 All To All 방식 보다는 메모리 사용이 줄어들게 되고 시간 효율이 좋아집니다. 

단점

Primary 서버와 Secondary 서버를 제외한 Proxy 서버에 정보를 요청할 경우 다시 Primary 서버에 요청하여 해당 Key에 해당하는 객체를 받아와야만 합니다.

세션 스토리지 분리

세션 스토리지를 분리한다는 것은 별도의 세션 저장소를 사용한다는 것을 의미합니다. 

세션을 각 서버마다 가지고 있는 것이 아니고 별도의 저장소에 저장하여 관리하면 서버가 아무리 늘어난다 하더라도 세션 스토리지에 대한 정보만 가지고 있으면 세션을 공유하고 정합성 문제를 해결할 수 있게 됩니다. 이렇게 된다면 하나의 서버가 장애를 일으켜도 다른 서버가 대신 서비스를 제공해줄 수 있게 되면서 가용성을 확보할 수 있게 되고 병행처리 또한 가능해집니다. 또한 하나의 데이터 스토리지를 사용하므로 데이터 정합성 문제도 해결 가능하고 신경 쓸것 없이 로드 벨런싱을 할 수 있어 병목 현상도 발생하지 않을 것입니다. 

따라서 세션 관리는 세션 스토리지 방식으로 사용하는 것이 최선으로 보입니다.