학습목표
강의를 들으며 내가 알고 있는 내용을 점검하고,
새로 배운 내용을 정리하며,
궁금한 내용을 알아가며 학습해나가는 것을 목표로 합니다.
3-Tier Architecture, HTTP Session 그리고 Session Cluster
3-Tier Architecture
가장 보편적이고 이해하기 쉬운 아키텍처입니다.
- 프레젠테이션 레이어 : 사용자와의 접점 제공
- 애플리케이션 레이어 : 트랜잭션 처리를 위한 비즈니스 로직 제공
- 데이터 레이어 : 데이터를 저장하고 조회하는 기능 제공
그 외 많은 장점들
- 프론트엔드, 백엔드 엔지니어 역할 분리에 따른 업무 효율화
- 각 계층을 모듈화해 다른 계층에 미치는 영향을 최소화하며 확장이 용이함
그렇다면 이러한 3-tier 아키텍처에서 서비스 이용자가 매우 빠르게 증가하고 있는 상황을 가정합니다.
이런 상황에서 백엔드 개발자가 당장 할 수 있는 일은 어떤 것이 있을까요?
- 애플리케이션 레이어의 서버를 수평 확장 (Scale-Out)
- 그리고 서비스 앞단에 로드 밸랜서를 배치하여 트래픽을 분산함
하지만 추가적으로 고려해야 하는 것, 예를 들면 특정 서버에서 장애가 발생하면 어떤일이 벌어질까요?
서비스 가용성 측면에서는 문제가 없을 수도 있습니다. 그러나...
사용자 인증 처리에서 Session을 사용했고, 그 외 특별한 조치가 없었다면 일부 사용자는 문제가 될 수 있습니다.
장애가 발생한 서버에서 인증된 사용자는 인증이 풀리게 되고 다시 인증해야 하며 이는 결코 바람직한 사용자 경험이 아닙니다.
HTTP와 Session
근본적으로 HTTP는 무상태 프로토콜이며 어떤 정보도 저장하지 않습니다.
하지만 서버는 인증된 사용자 정보를 저장하기 위해 Session을 만들고, 식별자인 session-id를 클라이언트로 응답합니다.
클라이언트가 웹 브라우저인 경우 session-id는 보통 Cookie 에 저장됩니다.
클라이언트는 HTTP 요청에 session-id를 포함시켜, 서버가 클라이언트를 식별할 수 있도록 해야합니다.
Session은 서버 메모리를 사용하기 때문에 너무 많아질 경우 서버 메모리 부족이 발생할 수 있습니다.
서버 장애시 복제본이 없는 Session 정보는 유실 되는 문제점도 있습니다.
Session Cluster
Session 기반 인증 처리의 문제점이 Session이 서버 메모리에 저장되는 것이라면, Session을 별도의 외부 스토리지에 저장한다는 개념입니다.
외부 스토리지는 조회 속도를 위해 보통 In-Memory 데이터베이스를 많이 사용합니다.
특정 서버에 문제가 생겨도 다른 정상적인 서버에서 Session을 외부 스토리지에서 가져올 수 있으므로 사용자 인증이 풀리지 않습니다.
Sticky Connection(동일한 사용자가 발생시킨 요청은 동일한 WAS에서 처리됨을 보장) 제약에서 자유롭습니다.
그러나 단점도 있습니다.
Session을 저장하기 위한 별도의 외부 스토리지가 필요합니다. (관리 포인트 증가)
외부 스토리지 장애 발생 시 대규모 장애 발생 가능성이 커집니다.
Session 클러스터를 위한 외부 스토리지가 SPOF 지점이 되는것을 방지하기 위해 외부 스토리지는 보통 클러스터로 구성됩니다.
Spring Session
Spring Session 프로젝트는 Spring Boot 웹 어플리케이션에서 Session Cluster를 구현하는데 다양한 기능을 제공합니다.
특히 Session을 저장하기 위한 외부 스토리지를 추상화함으로써 일관된 API로 JDBC, Redis, Hazelcast 등 다양한 스토리지를 활용할 수 있습니다.
Spring Session의 핵심 : SessionRepository 그리고 SessionRepositoryFilter
💡 Spring Session provides transparent integration with HttpSession. This means that developers can switch the HttpSession implementation out with an implementation that is backed by Spring Session.
SessionRepository
Session의 생성, 저장, 조회, 삭제 처리에 대한 책임을 가지고 있습니다.
스토리지 종류에 따라 다양한 구현체를 제공합니다.
- MapSessionRepository In-Memory Map기반이며, 별도의 의존 라이브러리 필요 없습니다.
- RedisIndexedSessionRepository redis 기반이며, @EnableRedisHttpSession 어노테이션으로 생성됩니다.
- JdbcIndexedSessionRepository jdbc 기반이며, @EnableJdbcHttpSession 어노테이션으로 생성됩니다.
SessionRepositoryFilter
모든 HTTP 요청에 대해 동작합니다.
HttpServletRequest, HttpServletResponse 인터페이스 구현을 SessionRepositoryRequestWrapper, SessionRepositoryResponseWrapper 구현체로 교체합니다.
HttpServletRequest, HttpServletResponse 인터페이스의 Session 처리와 관련한 처리를 Override 합니다.
- Session 관련 생성 및 입출력은 SessionRepository 인터페이스를 통해 처리합니다.
- HttpSession 인터페이스에 대해 Spring Session 구현체 HttpSessionWrapper를 사용하도록 합니다.
- HttpSessionWrapper 구현체는 org.springframework.session.Session 인터페이스를 포함하고 있습니다.
- 스토리지 종류에 따라 org.springframework.session.Session 인터페이스 구현체가 달라집니다.
(- Session 스토리지가 GemFire 이지만, 아키텍처는 스토리지 종류에 관계없이 모두 동일합니다.
