2. Scale Out의 세션 불일치 문제

 

  이전 글에서는 Scale Up과 Scale Out을 비교하고, 진행 중인 프로젝트에 적합한 방법으로 Scale Out을 선택하였다. 현재 프로젝트는 세션 방식의 로그인을 구현하고 있기 때문에, 이번 글에서는 세션 방식의 로그인에서 Scale Out이 일으킬 수 있는 문제점을 중점적으로 다루고자 한다. 해당 문제의 해결책은 다음 글에서 자세히 다루게 될 것 같다.

 

---

 

Scale Out의 세션 불일치 문제

 

세션 방식의 로그인

 

출처: https://velog.io/@junhok82/로그인은-어떻게-이루어질까Cookie-Session

 

  Scale Out의 문제점을 살펴보기 전에 세션 방식의 로그인이 어떤 과정을 거치는지 정확히 알면 좋을 것 같아 관련 내용부터 찾아보았다. 위 이미지를 참고하면 해당 내용을 이해하기 쉬울 것 같다. 클라이언트로부터 최초 요청(로그인 요청)이 오면, 서버는 세션을 생성하여 서버의 세션 저장소에 로그인 정보를 저장한다. 서버는 각 클라이언트를 구분해주는 Session id를 발급하고 쿠키에 담아 클라이언트에 응답을 준다. 쿠키는 클라이언트의 웹 브라우저에 저장되어 있다가 추후 서버에 요청이 있을 때 함께 전송된다. 그러면 서버는 쿠키 헤더에 담긴 Session id를 조회하여 세션 저장소에 저장된 정보를 확인하고, 클라이언트에게 응답한다. 여기까지가 대략적인 세션 방식의 로그인 과정일 것이다.

 

단일 서버의 세션 방식 로그인

  서버를 하나만 둘 경우에는 위 그림처럼 한 서버가 클라이언트의 모든 요청을 받는다. 최초 요청과 이후 요청들의 경로가 달라지지 않는다. 요청이 있을 때마다 Session id를 조회하고 세션 저장소에서 그에 해당하는 정보를 확인하는 과정은 어렵지 않을 것이다. 최초 요청 시 저장된 정보가 있는 곳과 이후 요청들로 Session id를 조회하는 곳이 동일하기 때문이다.

 

Scale Out 전략의 세션 방식 로그인

 

  더 이상 단일 서버만으로 밀려드는 요청을 감당할 수 없어 Scale Out 전략을 선택하게 되었다면? 여러 대의 서버를 두기 때문에 트래픽을 고르게 분산하는 로드 밸런싱 작업이 필수적이라고 했다. 클라이언트의 요청들이 오면 로드 밸런서는 여러 서버로 요청들을 분산시킬 것이다. 단일 서버는 요청이 한 곳으로 오기 때문에 세션 불일치를 걱정하지 않아도 됐었지만, 여러 서버로 요청이 분산되는 환경에서는 세션 불일치 문제가 발생하게 된다.

  그림을 보면, 각각의 서버에는 각각의 세션 저장소가 존재한다. 클라이언트 A가 로그인을 하면 로드 밸런서는 내부 알고리즘을 거쳐 서버 1에 요청을 보낸다. 요청을 받은 서버 1은 Session id를 생성하고, 해당 로그인 정보를 세션 저장소에 저장한다. 서버 1이 로드 밸런서를 거쳐 A에게 Session id를 포함한 응답을 주면, A의 쿠키 저장소에 서버 1이 발급한 Session id가 보관된다. 이후 비밀번호를 변경하고 싶은 A가 회원정보 수정 버튼을 클릭한다. 로드 밸런서가 내부 알고리즘을 거쳐 이번에는 회원정보 수정에 관한 요청을 서버 2에 보낸다. 이때 해당 요청과 함께 A가 보관하던 Session id도 서버 2로 전송된다. 서버 1이 발급한 Session id를 엉뚱하게도 서버 2의 세션 저장소에서 조회하게 된다. 당연히 일치하는 정보가 확인될 리 없다. 해당 Session id에 맞는 정보는 서버 1의 세션 저장소에만 존재하기 때문이다. A는 서버 2에게는 로그인했다고 판단되지 않는다. 로그인을 했음에도 로그인하라는 응답을 받은 A는 무척이나 황당할 것이다.

 

---

 

  위와 같은 세션 불일치 문제를 어떻게 해결하면 좋을까? 대표적인 해결 방식은 세 가지가 있다고 한다. 바로 Sticky Session, Session Clustering, Session Storage 방식이다. 어떤 방식인지 간단하게만 알아보자면, 먼저 Sticky Session은 한 클라이언트의 모든 요청을 첫 요청과 동일한 서버로 고정시키는 방식이다. 같은 서버에 계속 붙어있기 때문에 '달라붙는'의 뜻을 가진 Sticky가 용어로 쓰이게 된 것 같다. Session Clustering은 각각 서버의 세션 저장소가 같은 세션 정보를 공유하도록 하는 방식이다. 마지막으로 Session Storage는 서버 내부가 아닌 외부에 별도의 세션 저장소를 두어 모든 서버가 하나의 저장소를 공유하도록 만드는 방식이다. 세 가지 방식의 자세한 내용과 장점 및 단점, 진행 중인 프로젝트에 어떤 방식을 선택할지는 이어지는 글들에서 살펴보고자 한다.

 

 

 

프로젝트 링크: https://github.com/f-lab-edu/DeliDeli.git

GitHub - f-lab-edu/DeliDeli: (Delicious Delivery) 음식 배달을 제공하는 딜리버리 서비스입니다.

참고:

• https://velog.io/@junhok82/%EB%A1%9C%EA%B7%B8%EC%9D%B8%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%9D%B4%EB%A3%A8%EC%96%B4%EC%A7%88%EA%B9%8CCookie-Session

로그인은 어떻게 이루어질까❓(Cookie, Session)

• https://jaesika.tistory.com/2

대용량 트래픽을 위해 확장성 있는 세션 구조 설계 #1

• https://1-7171771.tistory.com/126

서버가 두 개 이상일 경우 발생하는 세션 불일치 문제 해결하기

• https://junshock5.tistory.com/84

다중 서버 환경에서 Session 공유법 (Sticky Session, Session Clustering, Inmemory DB)