세션 관리 방법

- 서버를 다중화했을 때 내가 한 요청이 여러 서버에 가고, 응답이 올 텐데

  로그인을 했을 경우 어떻게 여러 서버에 트래픽이 분산되어도 세션을 인식할 수 있는걸까

 

1. Sticky Session (스티키 세션)

  - '고정된 세션'

  - 로드밸런서에서 요청쿠키(세션ID)를 읽고 지정된 서버(세션이 있는)로만 요청 전달

  - 장점: 서버간 필요한 만큼의 세션만 생성이 된다.

    단점: 한 쪽 서버에 많은 세션이 누적되거나

           특정 세션들에 많은 리소스가 필요하면 과부하에 노출될 수 있다.

           즉, 여러 서버에 트래픽 분산이 어렵다.

 

2. Session Clustering (세션 클러스터링)

  - 클러스터링: 병렬 처리 => 여러 개를 하나처럼 사용하는 것

  - 즉, 세션을 서버 각각에 복사해서 모든 서버가 모든 세션을 보유

  - 어떤 서버로 요청이 가도 세션이 남아있고, 어떤 서버가 죽는다고해도 세션이 날라가지 않는다.

  - 장점: 여러 서버에 트래픽 분산 가능.

            특정 서버가 죽어도 세션이 소실되지 않는다.

    단점: 세션이 저장될 때마다 모든 서버에 세션을 넣어줘야해서 서버 수에 비례해 트래픽이 증가 (4개↑ 서버 비추천)

           기존세션 * 서버수 만큼의 메모리를 차지한다.

            새로운 서버를 추가할 때마다 기존 서버들에 이 서버 IP와 PORT를 설정해야한다.

            

3. Session Storage (세션 스토리지)

  - 세션DB를 따로 놓고 모든 서버가 여기를 참조

  - 어떤 서버로 요청이 와도 세션을 유지시켜줄 수 있다.

  - 장점: 여러 서버에 트래픽 분산 가능

            새로운 서버를 추가해도 기존 서버를 수정할 일이 없다.

    단점: 한 곳에서 관리하니 장애가 발생하면 취약하다. (이것도 분산관리 필요)

 

 

참조:

https://www.imperva.com/learn/availability/sticky-session-persistence-and-cookies/ (Sticky Session) 

https://tigerbum.tistory.com/20 (클러스터링이란)

https://hyuntaeknote.tistory.com/6 (세션클러스터링, 세션 스토리지 설명)