클라이언트-서버 구조에서 서비스 사용자가 급증하여 서버로 유입되는 트래픽이 급증하는 문제가 있다. 그래서 보통 백엔드 서버의 부하를 줄이기 위해 서버를 증설한다.
클라이언트-서버에서 세션처리할 때, 각각의 백엔드 서버에서 관리하는 세션 정보는 서로 공유하고 있지 않다. 즉, 세션 정보가 일치하지 않는 상황이 발생할 수 있다.
1) AWS Sticky Session 방법
AWS 의 해당 서비스는 로드 밸러서에서 클라이언트가 동일한 백엔드 API 서버에 접근할 수 있도록 한다. 즉, 클라이언트는 자신의 세션 정보를 갖고 있는 특정 백엔드 서버에만 접속하기에 세션이 일치하지 않는 상황은 없다. 그러나, 이 서비스는 로드 밸러싱의 기본적인 역할인 트래픽 부하 분산 역할을 완벽하게 수행하지 못하는 단점이 있다.
2) 별도 세션 저장소 구축 Redis
아래 두 가지의 이유로 Redis 를 사용
세션 저장소는 백엔드 서버와 별도로 분리하는 것이 좋다는 판단.
대용량 트래픽 환경에서 백엔드 서버의 확장 속도와 저장소의 확장 속도는 항상 비례하지 않는다고 한다. 웹서버만 확장해야 할 수도 있고 세션 저장소만 확장해야 하는 경우도 있다고 한다. 분산 환경에서 효율적 서비스 확장이 가능하기에 분리한다고 한다.
jwt 를 사용한다고 했을 시, 리프레시 토큰에는 유효기간이 있기 때문에 RDB 에 저장하게 되면 배치를 이용하여 주기적으로 삭제를 해줘야 하는 번거로움이 있다.
클라이언트-서버 구조에서 서비스 사용자가 급증하여 서버로 유입되는 트래픽이 급증하는 문제가 있다. 그래서 보통 백엔드 서버의 부하를 줄이기 위해 서버를 증설한다.
클라이언트-서버에서 세션처리할 때, 각각의 백엔드 서버에서 관리하는 세션 정보는 서로 공유하고 있지 않다. 즉, 세션 정보가 일치하지 않는 상황이 발생할 수 있다.
1) AWS Sticky Session 방법 AWS 의 해당 서비스는 로드 밸러서에서 클라이언트가 동일한 백엔드 API 서버에 접근할 수 있도록 한다. 즉, 클라이언트는 자신의 세션 정보를 갖고 있는 특정 백엔드 서버에만 접속하기에 세션이 일치하지 않는 상황은 없다. 그러나, 이 서비스는 로드 밸러싱의 기본적인 역할인 트래픽 부하 분산 역할을 완벽하게 수행하지 못하는 단점이 있다.
2) 별도 세션 저장소 구축 Redis 아래 두 가지의 이유로 Redis 를 사용
세션 저장소는 백엔드 서버와 별도로 분리하는 것이 좋다는 판단. 대용량 트래픽 환경에서 백엔드 서버의 확장 속도와 저장소의 확장 속도는 항상 비례하지 않는다고 한다. 웹서버만 확장해야 할 수도 있고 세션 저장소만 확장해야 하는 경우도 있다고 한다. 분산 환경에서 효율적 서비스 확장이 가능하기에 분리한다고 한다.
jwt 를 사용한다고 했을 시, 리프레시 토큰에는 유효기간이 있기 때문에 RDB 에 저장하게 되면 배치를 이용하여 주기적으로 삭제를 해줘야 하는 번거로움이 있다.