Session Storage Strategy

세션 저장소 전략이 필요한 이유

SpringBoot 를 활용하여 웹서비스를 만들 때에 보통 내장 톰캣을 사용합니다.

웹 서비스를 구축 할 때에 세션 저장소를 고려하지 않고 단순히 로그인 기능을 구현 할 경우 애플리케이션을 재실행하면 기존 로그인이 풀립니다.

풀리는 이유는 로그인 정보를 세션에 담고 있는데 세션이 내장 톰캣의 메모리에 저장되기 때문입니다.

기본적으로 세션은 실행되는 WAS(Web Application Server)의 메모리에서 저장되고 호출됩니다.

메모리에 저장되다 보니 내장 톰캣처럼 애플리케이션 실행 시 실행되는 구조에선 항상 초기화가 됩니다.

즉, 배포할 때마다 톰캣이 재시작되는 것!

그리고 한 가지 문제가 더 있습니다.

일반적으로 서비스의 서버는 2대 이상의 서버를 운영하는 경우가 많습니다.

2대 이상의 서버를 사용한다면 톰캣마다 세션 동기화 설정을 해야만 합니다.

그래서 세션 저장소에 대해 다음 3가지 중 한 가지를 선택합니다.

세션 저장소 전략

1. 톰캣 세션을 사용

• 일반적으로 별다른 설정을 하지 않을 때 기본적으로 선택되는 방식
• 이렇게 될 경우 톰캣(WAS)에 세션이 저장되기 때문에 2대 이상의 WAS가 구동되는 환경에서는 톰캣들 간의 세션 공유를 위한 추가 설정이 필요합니다.

2. MySQL과 같은 데이터베이스를 세션 저장소로 사용

• 여러 WAS 간의 공용 세션을 사용할 수 있는 가장 쉬운 방법
• 많은 설정이 필요 없지만, 결국 로그인 요청마다 DB IO가 발생하여 성능상 이슈가 발생할 수 있습니다.
• 보통 로그인 요청이 많이 없는 백오피스, 사내 시스템 용도에서 사용합니다
• 설정이 간단하고 사용자가 많은 서비스가 아니면 비용 절감이 됩니다.

3. Redis, Memcached와 같은 메모리 DB를 세션 저장소로 사용

• B2C 서비스에서 가장 많이 사용하는 방식
• 실제 서비스로 사용하기 위해서는 Embedded Redis 와 같은 방식이 아닌 외부 메모리 서버가 필요합니다.
• AWS 에서 사용한다면, 레디드와 같은 서비스 (엘라스틱 캐시)에 별도로 사용료 지불이 필요합니다.

 

 

#참고 : 스프링 부트와 AWS로 혼자 구현하는 웹 서비스