예전에 면접볼 때 질문을 너무 못했던 바로 그 주제… ㅠㅠ..
면접보고나서 바로 플젝 회의할때 그 주제가 나와서 땅을 치고 후회했드랩죠…
그래도 머 킵고잉해야하니까 용기내서 간단하게 정리해봅니당
그때 면접때 MSA 아키텍쳐 이야기를 많이 하면서 서버 여러대로 scael out 된 상황을 가정했었다. 그리고 jwt 통해서 로그인 기능 구현하는 이야기를 나눴었는데, 그렇다면 당연히 scale out한 상황에서 세션 일관성을 어떻게 유지할지가 중요하다.
1. scale out 상황에서의 세션 관리
scale out : 트래픽 증가 등의 이유로 서버 장비를 추가하는 것 (같은 일을 하는 서버를 추가하기에 수평적으로 확장)
이 상황이면 같은 일을 하는 서버가 여러대 있고, 앞에서 이에 트래픽을 분배해주는 load balancer 가 있다.
로그인후 세션에 토큰 등을 넣어서 로그인 상태를 관리한다고 하면, 세션은 서버에 저장되기에 사용자가 다른 서버에 붙어도 같은 값을 이용할 수 있도록 하는게 중요하다.
즉 어떻게 세션을 공유해 사용하고자 하는가에 대한 내용이다.
2. 세션 공유의 방법
1) sticky session
말 그대로 고정된 세션이다. 처음 세션을 생성할때, 어떤 서버에 세션을 만들었는지 쿠키에 보내준다.
클라이언트는 쿠키에 연결됐었던 서버 정보를 가지고 재요청하게되고, lb 는 이걸 보고 그 서버에 보내준다.
그럼 한 사용자는 한 서버에만 계속 붙게 되기 때문에 다른 서버에 붙어서 세션을 사용하지 못할까봐 걱정할 필요가 없다.
단점
- 같은 사용자는 같은 서버에만 붙음 -> 트래픽 분산 안됨.
- 특정 서버 fali down 시 그 서버에 붙었던 사용자 세션 다 날아감.
scale out의 장점을 누리지 못한다.
2) session clustering (세션 클러스터링)
클러스터링 : 여러 대를 하나처럼 사용할 수 있도록 하는 것
각 서버의 세션을 다 복사 (all to all) 하거나 primary-seconday 식으로 복사해서 결국은 어느 서버에 붙어도 세션 사용할 수 있도록 한다.
단점
- 세션 붙을 때마다 복사하는데 자원이 소모된다.
3) 세션 스토리지 분리
방법 3은 아예 공통으로 사용할 세션 스토리지를 분리시키는 것이다.
이렇게 하면 세션은 각 서버에 종속되지 않는다.
대신 세션을 저장하고 읽어오고 하는게 많아지기에 빈번한 읽기쓰기에 맞는 스토리지가 필요하다.
즉, 보통의 rdb 같은 디스크 IO를 하는 스토리지는 성능에 무리가 갈 수 있기에 빠르게 읽고 쓰기 쉬운 인메모리 db를 사용한다.
이게 redis 를 세션스토리지로 주로 사용하는 이유이다.