세션관리 방법

세션관리 방법

1. Sticky Session

• 끈적한 세션. 첫 request에 대한 reponse를 준 서버에 껌딱지 처럼 붙어있는것
• 특정 세션의 요청을 처음 처리한 서버로만 보내는 것

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

1. vsh123, oeeen 은 모두 로드 밸런서를 통해 첫 요청을 보낸다.
2. vsh123의 첫요청은 C 서버로, oeeen의 첫요청은 B 서버로 로드 밸런싱 되었다.
3. 그 이후로 들어오는 vsh123의 모든 요청은 C 서버로, oeeen의 모든 요청은 B 서버로 가게 된다.

첫 요청 이후의 모든 요청을 특정 서버로 고정하는 방법으로 세션관리를 한다.

특정 서버로 요청 처리를 고정 시키는 방법은 쿠키를 사용하거나 클라이언트의 ip tracking 하는 방식이 있음

ex)

참고로 AWS ELB는 cookie를 사용하여 Http Response에 cookie를 이용해서 해당 클라이언트가 가야하는 EC2 instance의 정보를 저장해두고 그걸 활용하여 특정 EC2로 요청을 고정한다.

단점

• 로드밸런싱이 잘 동작하지 않을 수 있다
• 특정 서버만 과부하가 올 수 있다.
• 특정 서버 Fail시 해당 서버에 붙어 있는 세션들이 소실될 수 있다.

이러한 단점들을 고려한 세션 관리 기법 중Session Clustering 방식이 있다.

2.Session Clustering

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

WAS들은 세션을 각각 가지고 있지만, 이를 하나로 묶어 하나의 클러스터로 관리하는 것

이 상태에서 하나의 WAS가 fail 발생하면 해당 WAS가 들고 있던 세션은 다른 WAS로 이동되어 그 WAS가 해당 세션을 관리한다.

각 서버마다 세션 클러스터링 방식이 다르고, 지원하는 방식이 다르기 때문에 현재 사용하고 있는 WAS의 session clustering 부분을 보고 확인해야 한다.

단점

• scale out 관점에서 새로운 서버가 하나 뜰 때마다 기존에 존재하던 WAS에 새로운 서버의 IP/Port를 입력해서 클러스터링 해줘야 하는 단점이 있다.

새로운 서버를 띄우면 기존 서버에 수정이 발생하고, 휴먼 에러가 발생할 가능성도 충분히 있다. 그렇기 때문에 Session server를 따로 두고 관리하는 방식도 있다.

3.Session Server 분리

 

 

 

위와 같은 방식은 새로운 서버를 띄우더라도 해당 서버에만 세션 서버의 정보를 적어주고 연결 해주면 되기 때문에 scale out 할 때 기존 서버의 수정이 발생하지 않는다는 장점이 있다.

대신 Redis Session 서버의 중요성이 올라가고, 해당 세션 서버가 죽는 순간 모든 세션이 사라지기 때문에 이 Redis 서버의 다중화도 고려해보아야 할 점이다. (사용해 본 적은 없지만 Redis가 Replication 설정이 쉽다고 한다.)

 

 

 

출처:

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