[개발 일기] 2025.02.12 - 스티키 세션

로드밸런서에 대해 공부하다가 스티키 세션이란 기술에 대해 알게 되었다.

오늘은 스티키 세션을 정리해 보자.

스티키 세션을 알기 위해선 세션에 대해 알고 있어야 한다.

세션이란 클라이언트와 서버 사이에 상태를 유지하는 방법 중 하나이다.

세션이라는 기술이 사용되는 이유는 HTTP는 클라이언트의 이전 요청을 기억하지 않는 무상태 프로토콜이기 때문이다.

세션이 유지되고 있다는 것은 서버가 클라이언트의 정보를 저장소에 보관하고 있다는 의미이다.

그렇기 때문에 세션이 유지되고 있는 상태에선 별도의 사용자 인증 없이 요청을 처리할 수 있다.

보통 세션 저장소는 인메모리나 데이터베이스에서 보관한다.

구조는 다음과 같다.

클라이언트 측의 쿠키에 저장된 세션 ID를 HTTP 요청에 포함한다면, 서버 측에서 해당 세션 ID와 일치하는 정보가 세션 저장소에 있는지 확인한 후, 인증되면 요청을 처리하는 것이다.

세션을 생성하고 삭제하는 과정은 다음과 같다.

1. 클라이언트가 서버에게 로그인 요청을 보낸다.

2. 클라이언트의 인증을 정상적으로 마친 경우, 세션 ID를 생성하고 세션 저장소에 세선 ID를 Key, 클라이언트 정보를 Value로 저장한다. 그리고 HTTP 응답 헤더에 세션ID를 포함한다.

3. 클라이언트 측에서 응답 헤더에 있는 세션ID를 쿠키 저장소에 저장하고, 다음 요청에 세션 ID를 헤더에 포함해 전달한다. 서버 측에선 전달받은 세션 ID가 유효한지 확인하고 유효한 경우, 요청을 처리한다.

4. 클라이언트가 로그아웃을 요청하는 경우 세션 ID와 사용자 정보를 세션 저장소에서 삭제한다.

스티키 세션은 로드 밸런서를 사용할 때 세션을 유지하기 위한 기법 중 하나로, 특정 사용자의 요청을 항상 동일한 서버로 전달하는 방식이다.

보통 MSA 같이 여러 개의 서버로 이루어진 경우, 요청을 분산 처리하기 위해 로드 밸런서를 사용한다.

만약 로드 밸런서와 세션을 함께 사용한다면 다음과 같은 문제가 발생하게 된다.

1. 클라이언트가 서버에게 로그인 요청을 보낸다.

2. 서버는 클라이언트의 정보를 저장하고, 세션 ID를 응답한다.

3. 클라이언트는 응답받은 세션 ID를 포함해 요청을 보내지만, 로드밸런서는 서버 2로 요청을 전달한다. 하지만 서버 2의 세션 저장소에는 클라이언트가 보낸 세션 ID와 클라이언트 정보 둘 다 없다. 그러므로 요청을 처리하지 못한다.

하지만 스티키 세션을 사용한다면 로드 밸런서는 세션이 생성된 곳으로 요청을 전달할 수 있다.

스티키 세션은 로드 밸런서에서 구현해야 한다.

쿠키 기반 스티키 세션 : 로드 밸런서가 특정 쿠키를 설정해 동일한 서버로 유도한다.

IP 해시 기반 스티키 세션 : 로드 밸런서에서 특정 IP에 해당하는 정보를 저장한 후, 해당 IP와 동일한 요청이 오면 특정 서버로 요청을 전달한다. 하지만 IP 주소가 변경된다면 재로그인이 필요할 수 있다.

구현 난도가 낮다.

로드 밸런서를 사용하는 이유는 요청을 최대한 분산하기 위함인데, 만약 특정 서버에 요청이 몰리게 될 경우, 로드 밸런서를 사용하는 의미가 없어진다. 이러한 이유 때문에 확장성이 떨어지는 기술이기도 하다.

현업에서 스티키 세션 말고 주로 사용되는 방안은 분산되어 있는 모든 서버가 같은 세션 정보를 유지하는 세션 공유 방식을 사용한다고 한다.

Redis엔 기본적으로 세션 공유 방식이 내재되어 있기 때문에 쉽게 구현할 수 있는 것 같기도 한다.

티스토리툴바