서버가 여러 개일 때 유저 정보를 어떻게 유지할 수 있을까?

현대 웹 애플리케이션은 높은 트래픽을 효율적으로 처리하기 위해 여러 대의 서버를 운영하는 경우가 많다.
이러한 환경에서는 트래픽을 여러 서버에 분산시키는 로드 밸런서(load balancer)의 필요성이 강조되어 많이 사용하지만 세션(Session)을 사용하는 인증 시스템에서 트래픽 분배는 몇 가지 문제를 발생시킬 수 있다.

 

세션 기반 인증이 가질 수 있는 문제점

세션 기반 인증은 사용자가 서버에 로그인하면 서버에서 세션을 생성하고 이를 통해 사용자의 상태를 관리한다.
세션 데이터는 보통 서버의 메모리에 저장되며 각 요청에 대해 세션 ID를 확인하여 사용자를 식별한다.

 

만약 단일 서버 환경라면?
서버가 한 대만 존재할 때는 사용자의 모든 요청이 동일한 서버로 전송되기 때문에 세션을 통해 문제 없이 인증 상태를 유지할 수 있어 문제가 없다.

 

하지만 다중 서버 환경라면?
여러 대의 서버가 있는 환경에서 사용자의 요청이 다른 서버로 분배된다면 새로 요청을 받은 서버는 사용자의 세션 정보를 알 수 없어 인증이 유효하지 않을 수 있다. 이를 방지하기 위해 특정 사용자의 요청을 항상 동일한 서버로 보내는 Sticky Session 방법을 사용할 수 있습니다.

 

Sticky Session

Sticky Session이란 사용자의 세션을 유지하기 위해 사용자가 최초로 접속한 서버로 모든 요청을 보내는 방법을 의미한다.

예를 들어 user1이 1번 서버에 세션을 생성했다면 이 후 세션 기간 동안 user1이 보내는 모든 요청은 1번 서버에서 담당하게 된다. 이는 로드 밸런서가 user1의 첫 번째 세션이 생성된 서버로 모든 요청을 리다이렉트하기 때문에 생기는 구조이다. 좀 더 원리를 자세히 살펴보면
먼저 로드 밸런서는 요청을 받으면 가장 먼저 요청에 쿠키가 존재하는지 확인 후 쿠키가 존재하면 쿠키에서 지정된 서버로 해당 요청을 전송한다. 쿠키가 없다면 기존의 로드 밸런싱 알고리즘을 통해 서버를 정하게 된다.

 

이러한 Sticky Session을 도입했을 때 가질 수 있는 장점은 다음과 같다.

• 사용자가 하나의 서버에서 세션을 유지하여 다수의 인증문제를 피할 수 있다.
• 여러 서버들끼리 세션 데이터를 교환할 필요가 없다.
• 정합성 이슈 발생 확률이 줄어든다.

하지만 단점 또한 존재한다.

• 서버가 다운되면 서버의 세션을 사용하는 사용자들이 모두 로그아웃 될 수 있다.
• 트래픽이 특정 서버에 집중되어
  • 부하 분산 효과가 줄어들 수 있다.
  • 해당 서버만 과부하가 발생할 수 있다.
  • 과부하가 발생한 서버를 피해 로드 밸런서가 다른 서버로 라우팅할 경우 기존 세션 데이터가 사라져 다시 로그인해야하는 문제가 발생할 수 있다.

Sticky Session 방식을 사용한다면 정합성 이슈를 피할 수 있지만 트래픽 분산에 어려움을 겪으며 다른 문제들을 마주할 수 있다.

정합성 이슈를 피하면서 동시에 해당 문제들을 해결할 수 있는 방식은 없을까?

 

Session Clustering

Session Clustering이란 서버 간 세션 데이터를 공유하여, 어떤 서버로 요청이 가더라도 사용자의 세션 상태를 유지할 수 있게 해주는 방법을 의미한다.

Session Clustering에는 여러 가지 방법이 있는데 이번 글에서는 DeltaManager를 활용한 All to all Session Replication을 살펴보려고 한다.

 

All to all Session Replication

All to all 세션 복제는 하나의 세션 저장소에 변경되는 요소가 발생할 경우 다른 모든 세션에 변경 사항이 복제가 되는 것을 의미한다.

예를 들어 user1이 1번 서버에 session을 남기게 되면 이 정보가 2, 3번 서버에 복제된다. 

이를 통해 정합성 이슈를 피할 수 있으며 하나의 서버에 문제가 발생해도 서비스를 중단없이 제공할 수 있다.

 

하지만!

 

변경 사항이 생길 때 마다 모든 서버에 동일한 세션 객체를 주어야 하기 때문에 많은 메모리가 소요된다.

뿐만 아니라 모든 서버에 데이터를 저장하기 때문에 서버 수에 비례하여 네트워크 트래픽이 증가하여 성능 저하가 초래될 수 있다.

따라서 해당 방식은 4개 이상의 서버를 가진 서비스에서는 추천되지 않는 방식이다.

 

이보다 개선된 형태의 방식도 존재한다.

 

primary-secondary Session Replication

위의 그림과 같이 1번 서버(primary)의 세션 객체를 2번 서버(secondary)에만 복제하고 이외의 서버에는 세션 객체의 key값만 복제해준다. 이 후 1,2 번 서버 이외의 서버에 요청이 들어온다면 해당 서버는 가지고 있는 key를 활용해 primary 서버에 질의한 후 해당 value를 구한다.
이런 방식은 모든 서버에 객체 전체를 복제했던 all to all 방식보다 효율적인 자원 사용, 트래픽 감소 등의 이유로 성능적 이점을 가질 수 있으나 상대적일 뿐 primary 서버에 질의하는 과정으로 인해 이 방식 또한 성능의 한계를 가질 수 있다.

 

Session Storage

세션 정합성의 문제를 해결할 수 있는 또다른 방법으로 최근 이 방식이 많이 채택되는 Session Storage가 있다.

Redis, Memcached 등의 세션 저장소를 활용하는 것으로 세션 데이터를 서버의 메모리가 아닌 외부 스토리지에 저장하여 모든 서버가 동일한 세션 정보를 참조할 수 있게 한다.

위의 그림과 같은 구조에서 외부의 세션 스토리지를 사용한다면 서버가 늘어나도 결국 같은 저장소의 값을 참조하기 때문에 정합성의 문제를 피할 수 있게 된다.

이 때 로드밸런서의 구현이 잘 되어 있다면 트래픽이 몰려 발생하는 과부하의 문제, 서버 장애로 인해 발생하는 세션 유지문제, 세션 복제로 인해 발생한 성능 문제 모두 어느 정도 해결이 가능할 것이다.

물론 세션 스토리지도 세션 객체를 복제해둘 필요가 있다. 이는 데이터의 정합성 문제 때문이 아닌 스토리지에 장애가 발생했을 경우를 대비하여 가용성을 확보하기 위한 목적이다.

 

그럼 이번 프로젝트에서는 로그인을 위해 Session Storage를 사용하는가?

아니다..!

나는 JWT를 활용하여 로그인 기능을 구현하였다.

위에서 정리했던 세션 기반 인증들은 서버가 상태(클라이언트와 서버가 연결되는 과정에서 생기는 정보)를 보존하고 있다.

즉 Stateful 구조이다.

이러한 구조는 앞에서 많이 보았듯 다중 서버일 경우 데이터 정합성 등 다양한 문제를 마주하게 된다.

 

하지만 사용자의 상태를 서버가 아닌 클라이언트가 보존한다면 즉 stateless 구조라면 서버를 추가하거나 제거하는 과정에서도 서버 간 세션 데이터 공유 및 동기화 때문에 고민할 필요가 없어 수평적 확장에 용이하고 특정 서버에 장애가 발생해도 사용자의 세션 유지 문제를 신경쓸 필요 없이 복구할 수 있으며 서버의 부담은 줄어들어 로직에만 집중할 수 있는 환경을 구축할 수 있다.

 

이러한 Stateless 구조의 이점때문에 세션 기반 인증 대신 JWT를 활용하여 로그인 기능을 구현하게 되었다!!

 

 

---

참고

https://woo0doo.tistory.com/26

스티키 세션(Sticky Session), 세션 클러스터링(Session Clustering)이란? + 세션, 로드 밸런싱, Session Storage

https://velog.io/@mirrorkyh/%EC%84%B8%EC%85%98-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0%EB%A7%81%EC%9D%B4%EB%9E%80

세션 클러스터링이란?