서버 2개 이상 세션 불일치 해결하기

세션 불일치란?

로드 밸런싱:

하나의 인터넷 서비스가 발생하는 트래픽이 많을 때, 여러 대의 서버가 분산 처리해 서버의 로드율 증가, 부하량, 속도 저하 등을 고려해 적절히 분산처리해 해결해주는 서비스이다.

스케일 아웃을 사용할 경우, 서버가 여러 대가 생기는데, 로드밸런서의 라운드 로빈 등의 로드밸런싱 전략에 의해 클라이언트가 서버1에서 세션을 저장한 후, 다음 요청을 진행했을 때, 세션이 저장된 서버 외의 다른 서버와 연결되어 기존 로그인이라던지 저장되어있던 상태가 풀리게 되는 현상을 의미한다.

Sticky Session

껌딱지 전략, 담당일진 전략이다. 즉, 처음 작업이 요청에 대한 응답을 준 서버에서 해당 클라이언트의 작업을 담당한다.

즉, 클라이언트가 서버1에서 로그인 작업을 통해 세션을 생성했다면, 해당 클라이언트에 대한 앞으로 모든 요청도 서버 1이 담당하게 되는 것이다.

Q. 어떤 방식으로 해당 클라이언트에 대한 앞으로 모든 요청도 서버 1이 담당하게 되죠?

이부분에 대해서는 리버스 프록시와 쿠키를 이용해 설명해보려고 한다.

위의 그림을 이용하자면(출처) HAProxy가 리버스 프록시라고 보면 된다.

리버스 프록시를 간단하게 설명해보자면, 여러 서버를 통합적으로 묶어 놓고 한 개의 서버인양 작동하게 도와준다. 로드밸런싱 또한 이 리버스 프록시에서 하는 역할 중 하나라고 생각하면 된다.

1. 클라이언트는 서버에게 처음 요청을 전달한다.(no cookie). 리버스 프록시는 서버들 중에 뽑기를 한다(라운드 로빈 등 뽑기 방식은 다양함.). 서버1이 뽑기에 당첨되어 클라이언트의 요청을 처리한다.
2. 서버1에서 클라이언트에 응답을 보낼 때, Set Cookie : SERVERID=서버1 ( 쉽게 , <너를 담당했던 서버는 서버1> )이런 형태로 정보를 쿠키에 담아 보낸다.
3. 이후, 클라이언트가 다시 서버에 요청을 보낼때 Cookie : SERVERID=서버1 을 함께 보낸다. (여기에서 쿠키는 마치, 놀이공원 팔찌 처럼 작용한다. 서버1에대한 프리패스 이용권이라고 생각하면 된다. )
4. 클라이언트의 요청을 받은 리버스 프록시는 클라이언트의 Cookie : SERVERID=서버1 을 확인 후,(서버1 프리패스 이용권) 서버1로 보내버린다.

이러한 방식을 통해 담당 일진을 만들 수 있다.

Sticky Session 단점

• 특정 서버에 트래픽이 집중되는 문제

  놀이기구 이용권이라고 생각하면 단골 많은 놀이기구는 곤란하단 소리다.

• 로드 밸런서는 열심히 일을 해서 서버마다 골고루 사용자 세션을 분배했다. 그 이후 사용자의 활동에 따라 문제가 생길 수 있다. 서버1에 서비스 단골 유저들(고인물)이 몰린다면, 서버1에만 트래픽이 집중되는 문제가 발생할 수 있다.

• 세션 정보의 유실

  서버가 다운되면 로그인 정보가 사라진다.

Session Clustering

tomcat 도큐먼트 참조 그림

• 세션을 생성될 때마다 복제하여 각 서버의 세션 정보를 일치시켜 정합성 이슈를 해결한다. (Tomcat 8 all-to-all 방식)

  session의 정보를 다른 서버에 전파하는 방식을 취하고 있다. (세션 클러스터링을 지원하는 방식이 여러가지 있다)

  • 즉, 여러 WAS의 세션을 동일한 세션으로 관리하는 것

예를 들어 서버1에서 로그인 세션이 저장됐다면, 서버2와 서버3에서 서버1에 저장된 세션을 전파, 복사하는 것이다. 따라서 1번 방법의 문제점인 특정 서버에만 트래픽이 몰리는 문제를 해결할 수 있다.포트와 주소가 함께 클러스터 구성원을 결정한다.

하지만, 이 방법은 소규모 클러스터에는 적합하지만, 4대 이상의 대규모 클러스터에서 적합한 방식이 아니다.(출처)

• 세션 전파하는 작업이 진행하기 때문에 모든 서버에 세션 정보가 저장된다. 즉, 효율적인 메모리 관리가 이뤄지지 않는다.
• 데이터 변경이 발생할 때마다 세션을 전파하는 작업이 일어나기 때문에 네트워크 트래픽이 증가한다.
• 세션 전파 작업 중 모든 서버에 세션이 전파되기 까지의 시간차로 인한 세션 불일치 문제와 같은 예상치 못한 문제가 발생할 가능성이 존재한다.
• 또한, 새로운 서버가 뜰 때마다 기존 WAS 에 새로운 서버 IP/Port 를 입력해 클러스터링해줘야한다.

유리할 때

• 적은 서버 개수(4개 이하) 유리
• (세션 불일치 가능성 적고, 네트워크 트래픽이 발생해도 소량의 서버에서는 성능상 크게 문제되지 않는다.)
• 위와 같은 방식은 새로운 서버를 띄우더라도 해당 서버에만 세션 서버의 정보를 적어주고 연결 해주면 되기 때문에 scale out 할 때 기존 서버의 수정이 발생하지 않는다는 장점이 있다.

<Tomcat 의 세션 복제 활성화 방법은 3가지 가 있다.>

1. 세션 지속성 사용 및 공유 파일 시스템에 세션 저장 (PersistenceManager + FileStore)

2. 세션 지속성 사용 및 공유 데이터베이스에 세션 저장 (PersistenceManager + JDBCStore)

3. 메모리 내 복제 사용, Tomcat과 함께 제공되는 SimpleTcpCluster 사용 (lib / catalina-tribes.jar + lib / catalina-ha.jar)

Tomcat은를 사용하여 세션 상태의 전체 대 전체 복제를 DeltaManager수행하거나 BackupManager. all-to-all 복제는 클러스터가 작은 경우에만 효율적인 알고리즘이다. 더 큰 클러스터의 경우 BackupManager를 사용하여 세션이 하나의 백업 노드에만 저장되는 1 차 보조 세션 복제 전략을 사용해야한다.(아래 세션 서버 저장소 따로 두기 참조)

Session 서버

분산 세션 서버는 확장 성과 안전성이 향상된 세션 클러스터링을 제공한다. 대규모 클러스터 환경에서 성능을 향상시킬 수 있다.

각각 서버에 세션 저장소(서버)를 구성해 로그인이 요청된 서버에 세션 정보를 저장하는 것이 아닌 ,

여러 서버들이 독립된 세션 저장소에서 세션 정보를 읽어오는 것이다.

장점

• 특정 서버로 트래픽이 몰리는 문제가 발생하지 않고
• 세션이 재설정되어도 모든 서버들이 수정되는 것이 아닌 세션저장소의 세션 정보만 수정하면 되기 때문에 WAS들끼리 불필요한 네트워크 통신 과정을 진행하지 않아도 된다.

단점

• 세션 저장소에 문제가 생기면 모든 WAS 서비스에도 영향을 끼친다.
  • 이러한 문제를 보완하기 위해 master-slave 복제 방법으로 동일한 세션 저장소를 하나 더 구성하는 방법을 쓰기도 한다.

세션 저장소 종류

• MySQL , OracleDB 등 RDBMS 를 사용할 수 있다.

• Redis 와 Memcached 와 같은 In Memory DB 를 사용 할 수 있다.

  세션의 정합성 문제에 대해서또한 프로젝트와 내부, 외부에 따른 진지한 고찰이 필요하다.

---

참고 문헌

https://1-7171771.tistory.com/126

https://d2.naver.com/helloworld/284659

https://smjeon.dev/web/sticky-session/

https://tomcat.apache.org/tomcat-8.5-doc/cluster-howto.html

https://tomcat.apache.org/tomcat-8.5-doc/config/cluster.html

https://technet.tmaxsoft.com/upload/download/online/jeus/pver-20141117-000001/session/chapter_session_server.html