지난 시간에 대규모 트래픽을 수용을 대비해 서버를 확장하는 방법 알아보았다. 그중 Scale Out 방식은 여러 대의 서버는 각각의 세션 저장소를 가지게 되므로 세션 불일치 문제 발생한다. 그래서 이번 시간에는 Scale Out 방식에서 발생하는 세션 정합성 문제를 해결하는 방법을 알아보고자 한다.
세션 불일치(정합성)?
단일 서버 환경에서는 session을 통한 로그인을 구현할때 session 불일치 문제를 신경쓸 필요가 없었다. 하지만 우리가 만든 프로젝트가 유명해져서 한대의 서버로 운영하는것이 불가능해졌다고 가정해보자.
Scale-Out 방식을 사용해서 서버를 여러대로 늘렸을 때 발생하는 문제점중 하나가 바로 세션 불일치 문제다. 아래 그림들을 통해 무슨뜻인지 이해해보자.
- Scale-Out 방식을 적용하여 3대에 서버로 구성한 서버 중 서버1에서 로그인을 진행했다. 이 경우, 서버1에서는 클라이언트의 요청을 직접 처리하였기에 Login Session이 존재하지만 서버2와 서버3에서는 해당 클라이언트의 Login Session이 존재하지 않는다.
- 클라이언트는 로그인을 한 후 글을 작성하기 위해 글쓰기를 서버로 요청을 보냈고 해당 요청은 로드 밸런서에 의해 서버2에서 처리하도록 되었다.
로드 밸런서?
하나의 인터넷 서비스에서 발생하는 트래픽이 많을 경우 여러 대의 서버로 로드율 증가, 부하량, 속도 저하 등을 고려하여 적절히 분산처리하여 해결해주는 서비스를 로드 밸런싱(Load Balancing)이라며 그 서비스를 제공하는 서비스 또는 장치를 로드 밸런서(Load Balancer)라 합니다.
- 서버2에는 해당 클라이언트의 Session이 저장되어있지 않기 때문에 서버2에서는 로그인 후 이용하라는 응답을 클라이언트로 전송한다. 클라이언트 입장에서는 분명히 로그인한 상태이지만 다시 로그인 요청을 해야 하는 처음 상황으로 되돌아가는 상황이 된다.
해결 방법
Sticky Session
처음 작업이 요청에 대한 응답을 준 서버에서 해당 클라이언트의 작업을 담당하는 것이다. 쉽게 말해서 특정 서버에 고정한다라고 생각하면 된다.
위 그림처럼 user1에 요청을 로드 밸런서를 통해 서버1에서 처리하도록 설정하면 user1에 모든 요청은 서버1이 담당해서 처리한다. 항상 동일한 서버에 요청을 하는 것이 아닌 클라이언트의 요청에 쿠키가 존재하는지 확인 후 요청 작업이 이루어진다.
만약 쿠키가 존재하지 않는다면 기존 로드밸런싱 방법에 의해 요청이 이루어진다.
하지만 이 방식에도 단점은 존재한다.
-
고정된 세션을 사용한다는 것은 즉 특정 서버에 트래픽 집중될 위험이 있다.
사용자가 접속해야 하는 서버가 정해져 있기 때문에 하나의 서버에 트래픽이 집중되어 있더라도 사용자는 자신의 세션이 없는 다른 서버를 사용할 수 없습니다. -
세션 정보가 유실될 수 있다.
서버가 어떠한 장애로 인해 다운된다면, 로드 밸런서는 서버를 제외한 나머지 서버로 요청을 보낸다. 그러면 결국 세션 데이터를 가지고 있지 않은 서버로 요청이 전송되므로 요청은 처리하지 못하고 세션 불일치 문제가 발생한다.
Session Clustering
세션 클러스터링은 WAS가 2대 이상 설치되어 있으면 동일한 세션으로 세션 관리 하는 것을 의미합니다. 그중 가장 대표적 WAS인 톰캣이 지원하는 방식은 all-to-all 방식으로 해당 서버에 저장된 session의 정보를 다른 서버에 전파하는 방식을 취하고 있다.
All-to-all Session Replication?
all-to-all 세션 복제란 하나의 세션 저장소에 변경되는 요소가 발생하면 변경된 사항이 다른 모든 세션에 복제가 된다는 것을 말합니다.
예를 들어 서버1에서 login session이 저장되었다면, 서버2와 서버3에도 서버1에 저장되어있는 세션을 전파(복사)하는 것이다. 따라서 1번 방법의 문제점인 특정 서버에만 트래픽이 몰리는 문제를 해결할 수 있게 되었다.
하지만 이 방법은 소규모 클러스터에는 적합하지만 4대 이상의 대규모 클러스터에는 적합한 방식이 아니다.
-
세션을 전파(복사)하는 작업을 진행하기 때문에 모든 서버에 동일한 세션 정보다 저장된다. 즉, 오버헤드가 크고 효율적인 메모리 관리가 이루어지기 어렵다.
-
데이터 변경이 발생할 때 마다 세션을 전파(복사)하는 작업이 일어나기 때문에 네트워크 트래픽이 증가하게 된다.
-
세션 전파 작업 중 모든 서버에 세션이 전파되기까지의 시간차로 인한 세션 불일치 문제와 같은 예상치 못한 문제가 발생할 가능성이 존재한다.
all-to-all 세션 복제 방식을 사용하면 스케일아웃에 한계 해결 방법
BackupManager 참고
Session Storage
마지막으로 독립된 세션 스토리지로 세션을 관리하는 방법이다.
각 서버와 연결된 독립된 세션 저장소(서버)에 로그인이 요청된 서버에 세션 정보를 저장하는 것이 아닌 앞서 언급한 독립된 세션 저장소(서버)에 세션 정보를 저장하고 여러 서버들이 독립된 세션 저장소에서 세션 정보를 읽어오는 방식이다.
해당 방법을 사용하면 Sticky Session의 문제점인 특정 서버로 트래픽이 집중되는 문제는 발생하지 않고, 또한 세션이 재설정되어도 모든 서버에 세션을 수정할 필요 없이, 세션 저장소에 있는 세션 정보만 수정하면 되기 때문에 WAS들끼리 불필요한 네트워크 통신 과정을 진행하지 않아도 된다는 장점이 있다.
이 방법에도 단점은 존재한다. 만약 독립된 세션 저장소에 문제가 생긴다면 모든 WAS의 서비스에도 영향을 끼친다는 것이다. 이러한 문제를 보완하기 위해 동일한 세션 저장소를 하나 더 구성하는 방법(마스터-슬레이브 복제)으로 해당 문제를 해결한다.
저장소로는 MySQL, OracleDB 등 RDBMS과 Redis와 Memcached 같은 In memory DB를 사용한다. 물론 해당 방법도 세션 정합성 문제가 발생한 경우 해결하기 위해 어떤 저장소를 사용하고, 사용에 따른 이유가 뒷받침 되어야한다.
정리하기
-
Sticky Session 방식은 서버를 최초로 세션을 생성한 서버로 고정하는 방식이다. 세션 정합성 문제를 해결할 수 있지만 트래픽 집중과 관련된 로드 밸런싱과 가용성에 문제가 있을 수 있다.
-
Session Clustering 방식은 세션이 생성과 변경 등에 작업이 있을 때 마다 해당 세션이 속한 모든 서버에 세션 정보를 전파하여 정합성을 해결하는 방식이다. 하지만 매번 세선 정보 작업을 진행됐을 경우 매번 세션 정보를 전파를 과정에 오버헤드가 발생하므로 이점을 고려해야 한다.
-
Session Storage 방식은 별도의 세션 저장소를 사용하는 것으로, 서버가 아무리 늘어난다고 할지라도 세션 스토리지에 대한 정보만 각각의 서버에 입력해주면 세션을 공유할 수 있게 됩니다. 다만 세션 저장소에 문제가 발생 시 전체 서버에 영향을 끼치며 이 문제를 해결하기 위해 하나의 저장소를 추가로 구성한다.
참조
- AWS - Classic Load Balancers
- NaverD2 - Open Source Load Balancers HAProxy
- Imperva - Sticky Session
- Slideshare - Session Clustering
- Thenewstack - Session Storage
Project Link
신뢰할 만한 사람들이 모인 공간에서 비즈니스 인맥을 만들고,
업무 스킬 및 트렌드 정보를 공유하는 Careerly를 모티브로 한 API 서버 프로젝트입니다.
