# 문제점
현재 프로젝트로 구현한 어플리케이션이 실제 배포가 되어 서비스를 제공할 경우, 이용자의 수가 늘어남에 따라 처리해야 할 트래픽의 수는 증가합니다. 이때 하나의 서버가 감당하기 힘들만큼의 트래픽을 처리해야 할 정도로 이용자 수가 증가했다면, 서버는 이를 버티지 못하고 다운되어 서비스 장애가 발생할 수 있는 위험이 있습니다.
이를 예방하기 위해선 Scale Up 과 Scale Out 방법으로 구분해 해결해 볼 수 있습니다.
- Scale Up : 단일 서버의 사양을 증가시켜 성능을 확장하는 방법
- Scale Out : 같은 사양의 서버를 다중으로 연결하여 성능을 확장하는 방법
추후 추가적인 확장 소요가 발생할 수 있다는 것을 고려한다면 하나의 서버의 사양만을 높히는 Scale Up 방식은 확장 유연성의 측면에선 한계가 있을 수 밖에 없습니다. 또한 의도치 않게 서버가 다운되는 상황이 발생한다면 단일 서버에 모든 데이터를 저장하는 구조는 치명적인 결함을 가질 수 밖에 없습니다.
그러므로 위 두 문제점에 대해 상대적으로 강점을 가진 Scale Out 방식을 채택할 것으로 방향성을 정했고 구체적인 Scale Out 방식에 대해 고민해 보기로 했습니다.
그러나 Scale Out 방식으로 WAS의 수를 증가했지만 로그인 회원 정보를 저장하기 위해 사용되는 Session 또한 각 WAS별로 하나씩 구성되기에 하나의 WAS에서 로그인 회원으로 처리된 사용자의 요청을 다른 WAS에선 로그인된 회원으로 인지하지 못해 제대로 된 서비스를 제공할 수 없게됩니다.
이러한 문제를 해결하기 위해 다음과 같은 방법들을 제시해 볼 수 있습니다.
# 해결 방안
Sticky Session
가장 단순히 사용할 수 있는 방식은 Sticky Session 방식입니다. 말 그대로 하나의 WAS 서버 당 하나의 세션을 가지고 데이터를 저장하는 구조를 의미합니다.
로드 밸런서
Scale Out 방식처럼 여러 서버를 하나의 서비스를 위해 활용하기 위해선 로드 밸런서라는 것을 도입할 필요가 있는데, 서버의 부하를 분산하는 역할을 하는 것을 의미합니다.
Sticky Session 방식은 각 세션에 저장된 데이터가 상이할 수 있다는 단점을 극복하기 위해 요청을 처리해준 사용자별 접근 가능한 WAS를 지정하고 해당 WAS에서만 요청 처리가 되도록 합니다.
그래서 Sticky Session 방식에선 특정 WAS에서만 모든 트래픽이 집중되고 다른 WAS는 대기만 하고 있는 현상이 발생할 수 있다는 단점이 존재합니다.
게다가 하나의 서버가 다운된다면 해당 서버에 저장된 정보는 사라지게 되면서 문제가 발생할 가능성도 존재합니다.
Session Clustering
Sticky Session의 문제를 해결하기 위해 생겨난 방법이 Session Clustering 방식입니다.
위 그림처럼 Session Clustering 방식은 모든 서버에 저장된 데이터를 공유하고 모든 세션이 같은 정보를 가지고 있게끔 하면서 Sticky Session에서 발생하는 문제를 해결하고자 했습니다. 즉, 정합성에 대한 고민을 해결한 셈이라 볼 수 있습니다.
모든 세션에 데이터를 복제하는 것을 all-to-all Session Replication 방식이라고 합니다.
하지만 모든 요청에 대해 각 세션에 같은 정보를 복제한다면 메모리 활용적인 측면에서 비효율적인 방식이라 볼 수 있고, 트래픽이 많은 경우엔 성능적인 측면에서도 영향을 줄 수 있다는 단점이 존재합니다.
all-to-all Session Replication 방식을 보안하기 위해 Tomcat에선 primary-secondary 세션 복제 방식을 제시하기도 했습니다. 이는 모든 세션에 데이터를 복제하는 것이 아닌 Primary-Secondary 세션을 선정해 복제하는 방식을 의미합니다.
Session Storage
Session Storage는 모든 WAS가 공유할 수 있는 별도의 세션 저장소를 구성하는 것을 의미합니다.
이렇게 된다면 Session Clustering 처럼 세션 복제를 모든 요청마다 해줘야 하는 오버헤드를 방지하고 성능적인 향상도 기대해 볼 수 있습니다.
# 마치며
결국 저는 Session Storage 방식으로 발생한 문제를 해결했고, Spring에서 제공하는 Session-data-redis 라이브러리를 의존성에 추가해 손쉽게 Session Storage 방식을 적용할 수 있었습니다.
# 참고자료
- https://hyuntaeknote.tistory.com/6
- https://hyuntaeknote.tistory.com/8