[매일메일] 다중 서버 환경에서 세션 기반 인증 방식을 사용하는 경우 발생할 수 있는 문제점은?

세션 불일치 문제란?

 

 기존 서버의 사양을 업그레이드하여 시스템을 확장하는 방식인 스케일 업(Scale-Up)과는 달리 서버를 여러 대 추가하여 시스템을 확장하는 방식인 스케일 아웃(Scale-Out) 사용 시 각 서버(WAS)는 각각 세션 저장소를 독립적으로 가지기 때문에 데이터 불일치 문제가 발생할 수 있다.

 

 

 예를 들어 유저의 요청으로 유저의 세션 아이디가 서버 WAS1의 세션 저장소에 저장된다. 하지만 그 후 유저의 요청이 서버 WAS2로 보내진 경우 WAS2의 세션 저장소에는 유저의 세선 정보가 존재하지 않기 때문에 데이터 불일치 문제가 발생한다. 이를 세션 불일치 문제라 하고 이는 크게 3가지 방식(스티키 세션 방식, 세션 클러스터링 방식, 스토리지 분리 방식)으로 해결할 수 있다.

 

해결 방법

스티키 세션 방식

 

 스티키 세션 방식은 고정된 유저, 고정된 세션을 의미하는데, 로그인된 요청인 경우 로드 밸런서에 의해 해당 요청을 지정된 서버로 전송하는 방식이다.

 

 

 우선 로드 밸런서는 요청에 쿠키가 존재하는지 확인하고 쿠키가 없는 경우에는 기존 로드 밸런싱 알고리즘을 바탕으로 처리 서버를 선정하고, 만약 쿠키가 존재하면 쿠키를 확인하여 해당 요청을 지정된 서버로 전송한다.

 

 스티키 세션 방식은 단순하고 유저는 세션이 유지되는 동안 동일한 서버만을 사용하기 때문에 세션 불일치 문제를 해결할 수 있다. 하지만 사용자가 접속해야 하는 서버가 정해져 있기 때문에 특정 서버에 트래픽이 몰릴 수 있다. 또한 사용자의 세션 정보를 가지고 있는 서버가 다운되면 해당 서버에 고정되었던 사용자는 세션 정보를 잃어버려 다시 로그인해야 하는 문제점이 존재한다.

 

 정리하자면 스티키 세션 방식 사용 시 세션 불일치 문제를 해결할 순 있지만 스케일 아웃의 장점인 가용성과 트래픽 분산을 제대로 활용할 수 없다는 단점이 있다.

 

세션 클러스터링 방식

 

 세션 클러스터링 방식은 여러 서버들이 연결되어 하나의 시스템처럼 동작하도록 하는 방식으로 특정 서버에 사용자 세션 정보가 생성되면 이를 다른 서버들에게도 복제하는 방식이다.

 

 

 톰캣의 경우 세션 클러스터링의 구현 방법으로 all-to-all 방식을 사용하는데, 위 사진에서처럼 만약 WAS1에 요청이 들어와 세션에 저장되었으면 해당 세션 정보를 다른 서버의 세션 스토리지에 전파하는 방식이다. 이렇게 하면 유저가 이후 어떤 서버로 요청을 넣더라도 로그인 요청 처리가 가능해진다.

 

 이로써 스티키 세션 방식에 있던 트래픽 몰림 현상과 세션 정보 유실 문제를 해결할 수 있다. 하지만 세션 정보가 중복으로 저장되기 때문에 메모리가 비효율적으로 사용되며, 세션 정보 복제 과정에서 네트워크 트래픽 문제, 그리고 세션 정보 복제 지연으로 인한 일시적 세션 정보 유실 문제 등이 발생할 수 있다.

 

세션 스토리지 분리 방식

 

세션 스토리지 분리 방식은 기존 서버가 갖고 있는 로컬 세션 저장소를 이용하는 것이 아니라 별도의 세션 저장소를 사용하는 것을 의미한다.

 

 

 위 그림과 같이 별도의 세션 스토리지를 분리하면 각 서버는 세션을 공유하게 되고 스티키 세션에서 발생했던 트래픽 몰림 현상, 그리고 세션 정보 유실 문제를 해결할 수 있고 또한 세션 클러스터링에서 발생했던 메모리 비효율 문제, 그리고 네트워크 트래픽 문제, 세션 정보 복제 지연 문제들을 해결 할 수 있다.

 

 하지만 세션 스토리지에 문제가 발생하면 전체 시스템에 영향(단일 장애 지점,Single Point Of Failure)이 가며 이를 해결하기 위해 동일한 세션 저장소를 하나 더 구성하여 해결하여도 다시 복제 지연등으로 인한 일시적인 세션 정보 유실 문제가 발생할 수 있다. 또한 외부 스토리지를 관리하기 위한 추가 리소스가 요구될 수 있다.

 

 결국 상황에 따라 적절한 해결방식을 택하는 것이 중요할 것이라 생각한다.