들어가며
세션에 대해 조금씩 이해를 하고 있지만, 세션을 어떻게 활용해야 잘 활용할 수 있는 것인지에 대해 정리해보고 싶었습니다. 세션을 쓸 때 어떤 것들을 고려해야 하는지에 대해 더 늦기 전에, 기초를 쌓고 싶어서 개념을 정리해보고자 합니다. 무지를 반성하는 마음으로 이 글을 적습니다.
세션 불일치란?
저번 자료에서 스케일 아웃을 할 때, 여러 대의 서버가 각각 세션 저장소를 독립적으로 갖기 때문에 데이터 불일치 문제가 발생한다는 것을 확인했습니다. 이번 시간에는 스케일 아웃을 했을 때 세션의 데이터 불일치 문제를 어떻게 해결하는지 알아보겠습니다.
먼저 Sticky Session을 활용해서 세션을 유지하는 방법에 대해 알아보겠습니다.
Sticky Session 방식
Sticky Session이란 말 그대로 고정된 세션을 의미합니다. 위의 그림을 보면, 예를 들어 User1이 1번부터 3번까지의 서버 중 1번 서버에 세션을 생성했다면, 이후에 User 1이 보내는 모든 요청은 1번 서버로만 보내지게 됩니다. 즉, Load Balancer는 User가 세션을 생성한 서버로 모든 요청을 리다이렉트 해서 고정된 세션만 사용하게 합니다.
이를 위해 로드 밸런서는 요청을 받으면 가장 먼저 요청에 쿠키가 존재하는지 확인합니다. 그리고 쿠키를 확인해서 해당 요청을 지정된 서버로 전송합니다. 쿠키가 없는 경우에는 로드 밸런서가 기존 로드 밸런싱 알고리즘을 기반으로 서버를 선정합니다.
동일한 사용자가 계속 해당 서버에 요청을 보낼 수 있도록 지속적으로 서버 정보가 쿠키를 통해 응답에 삽입되어 보내집니다. 이러한 방식을 사용하면 유저는 세션이 유지되는 동안 동일한 서버만을 사용하기 때문에 세션에 대한 데이터 불일치 문제에서 자유로워질 수 있습니다.
하지만 이 방식에도 단점은 존재합니다. 먼저, 고정된 세션을 사용한다는 것은 특정 서버에 트래픽이 집중될 위험이 있습니다. 사용자가 접속해야 하는 서버가 정해져 있기 때문에 하나의 서버에 트래픽이 집중될 때에도 다른 서버에 트래픽을 분산시키지 못합니다.
또한, 위 그림을 보면 서비스 중에 하나의 서버에 장애가 발생하게 되면 해당 서버를 사용하는 사용자들은 세션 정보를 잃어버리게 됩니다. 이렇게 되면, 다른 서버에 요청을 보내야 하고, 그렇게 되면 재로그인을 시켜야 하는 문제가 발생합니다.
즉, Sticky Session을 사용하면 세션에 대한 데이터 불일치 이슈를 해결할 수 있지만 스케일 아웃의 장점인 가용성과 트래픽 분산을 완벽히 사용할 수 없습니다. 그렇다면 세션에 대한 데이터 불일치 이슈를 해결하고, 가용성과 트래픽 분산까지 확보할 수 있는 세션 관리 방식은 없을까요? 지금부터 이를 고려한 세션 클러스터링 방식에 대해 알아보겠습니다.
WAS에서 지원하는 Session Clustering 방식
여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하도록 만드는 것을 클러스터링이라고 합니다. 서버 또한 컴퓨터로써 여러 대가 하나의 서비스를 하기 위해서는 클러스터링이 필요합니다. 그중 가장 대표적 WAS인 톰캣의 내용을 참고하여 세션 클러스터링을 통해 세션을 공유하는 방법에 대해 알아보겠습니다.
톰캣은 세션 클러스터링을 구현하는 방법으로 all-to-all 세션 복제 방식을 제안합니다. 위의 사진에서처럼, 해당 서버에 저장된 session의 정보를 다른 서버에 전파하는 방식을 취하고 있습니다. 예를 들어 WAS 1에서 login session이 저장되었다면, 서버 2와 서버 3에도 서버 1에 저장되어있는 세션을 전파(복사)하는 것입니다. 따라서 1번 방법의 문제점인 특정 서버에만 트래픽이 몰리는 문제를 해결할 수 있게 되었습니다. 그림과 같이 세션을 복제한다면 유저가 이후에 어떤 서버에 접속하더라도 로그인 정보가 세션에 복제되어 있으므로 세션 데이터 불일치 문제가 해결 가능합니다. 이로써 서버 하나에 장애가 발생하더라도 서비스는 중단되지 않고 운영 가능합니다. 하지만 Tomcat의 all-to-all 세션 복제 방식은 고려해야 할 단점들이 존재합니다.
우선, 모든 서버가 동일한 세션 객체를 가져야 하기 때문에 많은 메모리가 필요합니다. 또한 세션 저장소에 데이터가 저장될 때마다 모든 서버에 값을 입력해야 하므로 서버 수에 비례하여 네트워크 트래픽이 증가하는 등 성능 저하가 발생하게 됩니다.
그러므로 해당 방식은 소규모 클러스터에서 좋은 효율을 보여줍니다. 4개 이상의 서버를 가진 대규모 클러스터들에는 추천하지 않는 방식입니다. 정리하면, 세션 클러스터링은 정합성 이슈를 해결할 수 있지만, 성능적인 한계가 존재합니다. 그렇다면 위의 두 방식의 단점을 보완하여 다중 서버에서 세션을 공유할 수 있는 방법인 별도의 세션 서버를 사용하는 방법에 대해 알아보겠습니다.
세션 스토리지 분리 방식
별도의 세션 서버를 사용한다는 것은 무엇일까요? 이는 기존 서버가 갖고 있는 로컬 세션 저장소를 이용하는 것이 아니라, 별도의 세션 저장소를 사용하는 것을 의미합니다. 위의 그림을 통해 알아보겠습니다.
위와 같이 세션 스토리지가 서버에서 분리되면 서버가 아무리 늘어난다고 할 지라도 세션 스토리지에 대한 정보만 각각의 서버에 입력해주면 세션을 공유할 수 있게 됩니다. 이러한 방식을 사용한다면 로드밸런싱 알고리즘만 잘 구현되어 있다는 가정 하에 Sticky Session처럼 트래픽이 비정상적으로 몰리는 현상을 고려하지 않아도 됩니다. 또한 서버가 하나 장애가 발생하더라도 별도의 세션 저장소가 존재하기 때문에 서비스를 계속해서사용할 수 있습니다. 뿐만 아니라 여러 대의 서버가 하나의 세션을 사용하기 때문에 기존에 개별적으로 갖고 있던 로컬 세션 저장소의 데이터 불일치도 발생하지 않습니다. 그리고 세션 저장소가 하나이기 때문에 데이터 정합성 해결을 위한 별도의 세션 복제를 할 필요가 없어 이에 대한 성능적인 문제도 해결이 가능합니다.
하지만 세션 스토리지를 분리하는 방식에도 단점이 있습니다. 만약 독립된 세션 저장소에 문제가 생긴다면 모든 WAS의 서비스에 문제를 일으킬 수 있습니다. 이 문제를 해결하기 위해 동일한 세션 저장소를 하나 더 구성하는 방법(마스터-슬레이브 복제)으로 해당 문제를 해결하곤 합니다.
그럼 세션을 저장하는 저장소는 무엇을 사용해야 할까요? 이는 다음 포스팅에서 알아보겠습니다.
마치며
공부를 하며 그동안 아주 기초적인 것들을 제대로 공부하지 않았다는 것을 깨닫습니다. 좋은 기술을 배우는 것도 좋지만, 기술의 기반이 되는 기초적인 지식을 먼저 쌓는 것이 중요하다는 것을 다시금 깨달았습니다. 기초가 튼튼한 개발자가 되고 싶습니다.
출처
다중 서버 환경에서 Session은 어떻게 공유하고 관리할까? - 2편(Sticky Session, Session Clustering, Session St
개요 지난 시간에 서버의 성능을 업그레이드하는 두 가지 방법을 알아보았습니다. 그중 스케일 아웃을 하면 여러 대의 서버가 각각 세션 저장소를 독립적으로 갖게 되므로 정합성 이슈가 발생
hyuntaeknote.tistory.com
서버가 두 개 이상일 경우 발생하는 세션 불일치 문제 해결하기
서버가 두 개 이상일 경우 발생하는 세션 불일치 문제 해결하기 지난번에 포스팅했던 서버를 확장하는 방법에서 scale out 방식으로 서버를 확장했을때 발생하는 문제점 중 하나인 세션 불일치 문
1-7171771.tistory.com
'Web' 카테고리의 다른 글
| [Web] 다중 서버에서 세션을 관리해보자 - 4 (feat Redis, Memcached) (0) | 2022.01.11 |
|---|---|
| [Web] 다중 서버에서 세션을 관리해보자 - 3 (feat 세션 스토리지 선택) (0) | 2022.01.08 |
| [Web] 다중 서버에서 세션을 관리해보자 - 1 (feat Scale-up, Scale-out) (0) | 2021.12.29 |
| [Web] 세션을 알아보자 (0) | 2021.12.23 |
| [Web] 로컬 스토리지와 세션 스토리지 (0) | 2021.12.11 |
