목표

프로그래머스 강의 듣기

결과

3-Tier Architecture

: 가장 보편적이고 이해하기 쉬운 아키텍처

• 구성
  1. 프레젠테이션 레이어 : 사용자와의 접점
  2. 애플리케이션 레이어 : 트랜잭션 처리를 위한 비즈니스 로직 제공
  3. 데이터 레이어 : 데이터를 저장하고 조회하는 기능 제공
• 장점
  1. 프론트엔드, 백엔드 엔지니어 역할 분리에 따른 업무 효율화
  2. 각 계층을 모듈화해 다른 계층에 미치는 영향을 최소화하며 확장이 용이함

서비스 이용자가 매우 빠르게 증가하고 있는 상황에서 백엔드 개발자가 당장 할 수 있는 일

• 애플리케이션 레이어의 서버를 수평 확장 (Scale-Out)
• 서비스 앞단에 로드 밸랜서를 배치하여 트래픽을 분산
• 특정 서버에서 장애가 발생한다면?
  • 서비스 가용성 측면에서는 문제가 없음
  • 사용자 인증 처리에서 Session을 사용했고, 그 외 특별한 조치가 없었다면 일부 사용자는 문제가 될 수 있음
  • 장애가 발생한 서버에서 인증된 사용자는 인증이 풀리게 되고 다시 인증해야 함 → 바람직한 UX ❌, 해결 방법 : Session Cluster 사용

HTTP와 Session

• HTTP는 무상태 프로토콜이고 어떤 정보도 저장하지 않음
• 서버는 인증된 사용자 정보를 저장하기 위해 Session을 만들고, 식별자인 session-id를 클라이언트로 응답
  • Session은 서버 메모리를 사용하기 때문에 너무 많아질 경우, 서버 메모리 부족이 발생할 수 있음
• 클라이언트는 HTTP 요청에 session-id를 포함시켜, 서버가 클라이언트를 식별할 수 있도록 해야함
• 서버 장애시, 복제본이 없는 Session 정보는 유실됨 → 해결 방법 : Session Cluster

Session Cluster

: Session 기반 인증 처리의 문제점이 Session이 서버 메모리에 저장되는 것이라면, Session을 별도의 외부 스토리지에 저장한다는 개념

• 외부 스토리지는 조회 속도를 위해 보통 In-Memory 데이터베이스를 많이 사용
• 특정 서버에 문제가 생겨도 다른 정상적인 서버에서 Session을 외부 스토리지에서 가져올 수 있으므로 사용자 인증이 풀리지 않음
• Sticky Connection(동일한 사용자가 발생시킨 요청은 동일한 WAS에서 처리됨을 보장) 제약에서 자유로움
• 단점
  • Session을 저장하기 위한 별도의 외부 스토리지가 필요 → 관리 포인트 증가
  • 외부 스토리지 장애 발생 시, 대규모 장애 발생 가능성이 커짐
    • Session 클러스터를 위한 외부 스토리지가 SPOF(Single Point Of Failure) 지점이 되는 것을 방지하기 위해 외부 스토리지는 보통 클러스터로 구성됨
• Spring Session 프로젝트가 Session Cluster를 구현하는데 다양한 기능 제공

Spring Session

: Spring Session 프로젝트가 Spring Boot 웹앱에서 Session Cluster를 구현하는데 다양한 기능 제공

• Session을 저장하기 위한 외부 스토리지를 추상화함으로써 일관된 API 제공
• JDBC, Redis, Hazelcast 등 다양한 스토리지 활용 가능

의존성 추가 및 설정 (스토리지 : JDBC)

<dependency>
  <groupId>org.springframework.session</groupId>
  <artifactId>spring-session-jdbc</artifactId>
</dependency>

• H2 운영 모드 변경 및 Spring Session 관련 테이블 초기화

  datasource:
    driver-class-name: org.h2.Driver
    url: "jdbc:h2:file:./database/spring_security.db;MODE=MYSQL;DB_CLOSE_DELAY=-1"
    username: sa
    password:
    hikari:
      minimum-idle: 1
      maximum-pool-size: 5
      pool-name: H2_DB
  sql:
    init:
      platform: h2
      mode: always
      schema-locations: classpath:sql/schema_new.sql, classpath:org/springframework/session/jdbc/schema-h2.sql
      data-locations: classpath:sql/data_new.sql
      encoding: UTF-8

  • 지금까지는 H2 데이터베이스를 In-Memory 모드로만 사용했지만, 본 예제에서는 파일 모드로 사용함
    • datasource.url 수정 : jdbc:h2:file:./database/spring_security.db;MODE=MYSQL;DB_CLOSE_DELAY=-1
      • h2:mem 수정 : h2:file:파일경로.db
  • sql.init.mode 부분을 always로 변경
    • 기존에는 embedded (기본값) 이였으며, H2가 In-Memory 모드일 경우 해당됨
    • H2를 파일 기반 모드로 변경하면 embedded 에 해당하지 않으므로, 항상 초기화를 의미하는 always로 변경이 필요함
  • spring-session-jdbc는 session 정보를 저장하기 위해 2개의 테이블을 사용함
    • sql.init.schema-locations 부분에 spring-session-jdbc에서 사용하는 테이블 생성 SQL 쿼리 파일을 지정
    • 테이블을 추가하기 위한 SQL 쿼리는 spring-session-jdbc jar 내부에 위치함

• Spring Session 관련 설정

    session:
      store-type: jdbc
      jdbc:
        initialize-schema: never

  • session.store-type 부분에 jdbc 를 입력함

  • session.jdbc.initialize-schema 부분에 never를 입력함

    • sql.init.schema-locations 부분에 spring-session-jdbc에서 사용하는 테이블 생성 SQL 쿼리 파일을 지정했기 때문에 사용하지 않음

  • @EnableJdbcHttpSession 어노테이션을 추가하여, jdbc 기반 spring session을 활성화

    • org.springframework.session.SessionRepository와 org.springframework.session.web.http.SessionRepositoryFilter 2개의 클래스는 Spring Session에서 가장 핵심적인 역할을 수행한다. 이들 클래스의 Bean 설정은 Spring Session Jdbc의 경우 JdbcHttpSessionConfiguration 클래스에서 처리

Spring cluster가 제대로 동작하는지 확인하는 과정 (로드 밸런서와 여러대의 서버 환경을 구축하지 못하는 경우)

1. 최초 서비스 시작 및 정상 로그인 (브라우저는 종료하지 않음)
2. 서비스를 종료함 : H2를 파일 모드로 설정했기 때문에 지정된 경로에 db 파일이 생성됨 (jdbc url 경로에 따라 파일 경로는 상이할 수 있음)
   • 서비스를 종료하는 것은 WAS에 장애가 발생하고, 다른 WAS에서 요청을 처리하게 되는 것을 시뮬레이션하기 위함
3. sql.init.mode를 never로 변경하고 서비스를 시작
   • 서비스 시작시 테이블이 중복 초기화 되는 것을 막기 위함
   • Spring Security에서 Cookie 설정을 5분으로 했기 때문에 Cookie가 만료되기 전 재시작해야 함 — 5분 이내
4. 최초 정상 로그인을 수행했던 브라우저로 https://localhost/me 페이지 접근하여 정상 접근 확인
   • 이것은 최초 로그인을 수행했던 WAS가 아닌 다른 WAS에서 Session Cluster 기능을 통해 정상적으로 인증을 처리할 수 있음을 의미함

SessionRepository 그리고 SessionRepositoryFilter

• 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 인터페이스 구현체가 달라짐

Spring Security, Spring Session

• Spring Session의 SessionRepositoryFilter 클래스는 Spring Security의 DelegatingFilterProxy 보다 먼저 실행됨
• Spring Security의 SecurityContextPersistenceFilter는 SecurityContextRepository 인터페이스 구현체를 통해 사용자의 SecurityContext를 가져오거나 갱신함
  • SecurityContextRepository 인터페이스 기본 구현은 Session을 이용하는 HttpSessionSecurityContextRepository 클래스
  • HttpServletRequest 인터페이스의 getSession() 메소드를 통해 Session을 가져옴
    • 바로 이 지점에서 HttpServletRequest 인터페이스의 스프링 세션 구현체인 SessionRepositoryRequestWrapper 클래스가 사용됨
• 결과적으로, Spring Security는 아무것도 수정할 필요가 없음
  • Spring Session은 HttpSession과의 투명한 통합(transparent integration)을 제공함

Reference
1. 프로그래머스 백엔드 데브코스
2. https://insightsoftware.com/logi-analytics/
3. https://cscie12.dce.harvard.edu/lecture_notes/2007-08/20080423/slide51.html
4. https://ignite.apache.org/use-cases/caching/web-session-clustering.html
5. https://docs.spring.io/spring-boot-data-geode-build/1.1.x/reference/html5/guides/caching-http-session.html