다중 서버에서의 세션 (Sticky Session, Session Clustering, Session Storage)
사용자가 많아져서 트래픽이 많아지고 요청이 늘어나 부하가 많이 생긴다면 서버를 업그레이드 해야하는 일이 생긴다.
이러한 서버 업그레이드에서는 각 서버마다 세션을 일치시켜주는 것이 중요하다.
단일 서버환경이라면 세션일치를 고려할 필요는 없을것이다. 하지만 모든부하가 집중되고 만약 단일서버가 다운된다면 서비스 이용에 에러가 생긴다.
보통 서버 업그레이드는 두가지 방법으로 나뉜다.
1. Scale-Up : 단일 서버에서 물리적인 서버 자체의 스펙을 높여서 요청을 감당한다.
이 방법은 한대의 서버에 트래픽이 몰리면 성능저하가 있을 수 있고 다운되면 위험하다.
그리고 물리적으로 서버한대를 아무리 높혀봤자 한계가 존재한다.
2. Scale-out : 서버대를 여러대로 늘려서 각 서버에 로드밸런싱을 통해 트래픽을 분산시킨다. 그렇기에 다른 서버에 이슈가 생겨도 서비스 다운으로는 이어지지 않을 수 있다. 하지만 여러대의 서버를 두었기에 세션을 공유하는 것에 대해 문제가 생긴다.
세션 불일치에 대한 해결 방식
1. Sticky Session
이 방식은 사용자가 최초로 세션이 생성되었던 서버를 기억하여 그 사용자는 해당 서버에 고정적으로 접근을 하게 하는 방식이다.
✔ 특징
• 로드밸런서가 클라이언트의 세션을 특정 서버에 고정시킴.
• 사용자는 해당 서버에 고정적으로 접근
✔ 장점 :
• 구현이 간단하다.
• 로컬 서버 메모리에 세션을 가지고 있어 접근이 빠르다 -> 성능이 좋다.
✔ 단점 :
• 특정 서버에 트래픽이 집중 될수 있다. -> 로드밸런싱의 의미가 없어진다.
• 특정 서버에 장애가 발생할 시 일부 유저들은 서비스 이용에 장애를 느낀다. -> 세션정보가 유실된다.
2. Session Clustering
이 방식은 각 서버마다 세션 데이터를 똑같이 복사하여 전파하는 방식이다.
모든 서버가 같은 세션을 가지고 있어 불일치문제를 해결할 수 있다. 어느 한 서버가 다운되더라도
다른 서버에서 세션을 가지고 있어서 사용자는 원할한 이용이 가능하다.
✔ 특징
• 세션 정보를 **서버 간에 복제(공유)**하여 어디서든 접근 가능.
• WAS 간에 세션을 동기화
✔ 장점 :
• 한 서버가 다운되더라도 다른 서버에서 세션을 가지고 있어서 사용자는 원할한 이용이 가능
✔ 단점 :
• 세션 복제에 따른 네트워크 트래픽 증가
• 세션 복제 동기화 시 성능 저하 가능.
3. Session Storage
이 방식은 세션을 각 서버에 저장하는게 아닌 외부에 세션 저장소를 두어 모든 서버가 하나의 세션 저장소 (Redis, Memcached, DB 등) 를 바라보게 하는 방식이다.
✔ 특징
• 모든 서버가 동일한 저장소에서 세션을 읽고 씀.
✔ 장점 :
• 서버가 추가적으로 증설이 되어도 추가 작업이 원할하다. (그냥 세션 저장소만 연결하면 된다.)
• 로드밸런싱의 목적이 퇴색되지 않고, 클러스팅 방식처럼 복제전파에 대한 네트워크 비용과 메모리 소모가 없다.
✔ 단점 :
• 외부 저장소 장애 시 모든 세션 영향
• 외부 저장소에 접근에 대한 네트워크 I/O 부담 . -> 물리적으로는 로컬 세션 접근보다 느리다.
* 소규모 서비스 -> Sticky Session 적합
* 중간규모 -> Session Clustering 적합
* 대규모 / 클라우드 환경 -> Session Storage 적합
Session Storage에서 보통 외부 저장소는 인메모리방식과 디스크방식이 있는데 인메모리 방식을 압도적으로 많이 사용한다.
이유는 ?
세션은 일정시간 이후에 소멸되어야 하고 영구적으로 저장할 필요가 없다. --> 디스크에 장점을 취할 필요가 없음.
그리고 디스크에 접근하여 가져온다면 입출력비용이 들기때문에 성능면에서 인메모리 방식보다 느리다.
만약 디스크로 관리한다면 세션에 대한 데이터를 주기적으로 삽입/삭제가 이루어질텐데 번거롭기도 하고 IO 비용이 막대해진다.