로드밸런싱 / 스티키 세션 Sticky Session / 세션 클러스팅 Session Clusting 방식 비교

 

 

로드 밸런싱이란, 클라이언트로부터 오는 요청을 여러 서버로 분배 해주는 것

대용량 트래픽을 장애 없이 처리하기 위해 여러 대의 서버에 적절히 트래픽을 분배하는 것

여러대의 서버 사용.

 

단순 Round Robin 방식이라면 로드밸런서로 각 서버 동일하게 리퀘스트가 나뉘어지는데 

이렇게 되면 동일한 클라이언트가 1번서버에 로그인 요청 및 성공 응답 하고서 

또 유저정보 조회 요청 했을 때 로드밸런서 때문에 다른 서버로 이 요청이 간다면 

로그인이 안돼서 또 로그인하라고 하는 사태가 일어날 수 있다. 

 

 

그래서 Sticky Session 사용. 

 

첫 request에 대한 응답을 준 서버에 껌딱지처럼 붙어있는 것!

특정 세션의 요청을 처음 처리한 서버로만 보내는 것

 

특정 서버로 요청 처리를 고정시키는 방법은 Cookie를 사용하거나

클라이언트의 IP tracking 을 통해 가능. 

 

 

실 예로 AWS ELB는 cookie를 사용하여 Http Response에 cookie를 이용해서 

해당 클라이언트가 가야하는 EC2 instance의 정보를 저장해두고 그걸 활용하여 특정 EC2로 요청을 고정.

 

이 Sticky Session은 로드밸런싱이 잘 동작하지 않을 수 있고 

특정 서버만 과부하가 올 수 있고 

특정 서버 Fail시 해당 서버에 붙어 있는 세션들이 소실될 수 있다.

 

 

 

그래서 추가로 Session Clustering 방식이 있다. 

 

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

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

하나의 WAS가 fail 발생하면 해당 WAS가 들고 있던 세션은 다른 WAS로 이동되고 

각 서버마다 세션 클러스터링 방식이 다르고, 지원하는 방식이 다르다. 

새로운 서버를 띄우면 기존 서버에 수정이 발생하고, 휴먼 에러가 발생할 수도 있다.

 

 

이를 대비하기 위해 Session server를 분리하기도 한다. 

그리고 레디스 세션서버를 이용해 연결한다.

그러면 새로운 서버를 띄우더라도 해당 서버에만 세션 서버의 정보를 적어주고 연결 해주면 된다. 

대신 Redis Session 서버의 중요성이 올라가고, 해당 세션 서버가 죽는 순간 모든 세션이 사라지므로 

Redis 서버의 다중화도 고려해야 한다. 

다행히(?) Redis의 Replication 설정은 쉽다고 한다.