Http Session과 Session Clustering 개념

개발자 도구(F12) - Application - Storage > Cookies 에서 JSESSIONID는 Spring boot 내장되어 있는 tomcat 서버가 만드는 키로, 세션을 tomcat에서 관리합니다.

 

tomcat에서 관리하는 htttp session으로,  쿠키의 유무에 따라서 http session의 데이터가 있느냐 없느냐를 Spring boot가 판단합니다. 쿠키의 값을 바탕으로 tomcat이 세션을 조회하고, (Dispatcher Servlet에 넘겨) 조회된 session을 @GetMapping으로 보내줍니다.(Dispatcher Servlet의 GetMapping 인자로 넘겨준다.)

 

사용자의 요청 양이 증가할 경우, 해결 방안은

1. Scale-Up : 8GB → 16GB →  32GB 기계 성능을 올림. 비용적 한계가 있음.

2. Scale-Out : 서버를 2-3대로 늘림. 사용자에 따라 서버를 늘려서 요청을 분산하는 방식.

 

해결 방안 2번 Scale-Out 처럼
서버를 여러대 늘릴 경우에 sticky session에 의해 A 서버에만 반복적인 요청이 들어오면 장기적으로 볼 때, A 서버의 부하가 집중됩니다. 결과적으로 부하 분산이 정상적으로 일어나지 않고, A 서버 다운이 일어나면 A 서버 세션도 함께 날아가는 문제가 발생합니다.

Sticky Session
로드밸런서가 요청을 A 서버로만(한쪽으로만) 보내주는 것

 

Redis를 통해서 앞선 Scale-Out에서 발생할 수 있는 문제점을 해소하려고 합니다.

서로 다른 서버 구현을 하면 예를 들어 A, B 서버가 각자 자신의 세션 정보만 알고 가지고 있는 문제점이 있습니다.

 

A 든 B 든 어떤 서버든 간에 자신이 저장한 세션 정보를 자기 내부에 저장하지 않고, 외부 저장소에 세션을 저장하는 것이 Session Clustering 방식이다.

EX)
사용자가 A로 요청을 보내면 외부 저장소에  'AB'라는 세션 생성 및 정보를 넣어주고 사용자에게 'AB'라는 세션 ID를 돌려줍니다. 다음 요청이 B 서버로 보내져서 세션에 AB를 전달해도 외부 저장소에서 AB를 요청해서 사용자를 확인할 수 있습니다. 결론은 외부 저장소를 사용할 경우, 여러 application이 데이터를 같이 공유하여 사용할 수 있는 장점이 있습니다. 서버를 추가하고 제거하는 측면에서 더 편리해진다. 여러 서버 중 한쪽 서버의 문제가 생겨도 다른 서버로 균등하게 배분하면 됩니다. 세센의 정보가 손실되는 문제가 사라집니다.

그러나 외부에 관리해야하는 저장소가 1개 늘어난다는 점과 외부 DB를 확인하는 통신 과정에서 약간의 딜레이가 발생할 수 있습니다. 딜레는 사용자 경험과 직결되어 있어, 외부 저장소는 대표적으로 인메모리인 Redis를 사용하는 경우가 많습니다.