Tier Architecture, HTTP Session 그리고 Session Cluster

1. 3-Tier Architecture

- 가장 보편적이고 이해하기 쉬운 아키텍처
    - 프레젠테이션 레이어 — 사용자와의 접점 제공
    - 애플리케이션 레이어 — 트랜잭션 처리를 위한 비즈니스 로직 제공
    - 데이터 레이어 — 데이터를 저장하고 조회하는 기능 제공
- 그 외 많은 장점들
    - 프론트엔드, 백엔드 엔지니어 역할 분리에 따른 업무 효율화
    - 각 계층을 모듈화해 다른 계층에 미치는 영향을 최소화하며 확장이 용이함
    

• 서비스 이용자가 매우 빠르게 증가하고 있는 상황에서 백엔드 개발자가 당장 할 수 있는 일
  - 애플리케이션 레이어의 서버를 수평 확장 (Scale-Out)
  - 그리고 서비스 앞단에 로드 밸랜서를 배치하여 트래픽을 분산함
  

• 하지만 추가적으로 고려해야 하는 것 — 특정 서버에서 장애가 발생하면 어떤일이 벌어질까?
  - 서비스 가용성 측면에서는 문제가 없음 그러나...
  - 사용자 인증 처리에서 Session을 사용했고, 그 외 특별한 조치가 없었다면 일부 사용자는 문제가 될 수 있음
  - 장애가 발생한 서버에서 인증된 사용자는 인증이 풀리게 되고 다시 인증해야 함 → 결코 바람직한 사용자 경험이 아님
  

2. HTTP와 Session

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

3. Session Cluster

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

• 외부 스토리지는 조회 속도를 위해 보통 In-Memory 데이터베이스를 많이 사용함

• 특정 서버에 문제가 생겨도 다른 정상적인 서버에서 Session을 외부 스토리지에서 가져올 수 있으므로 사용자 인증이 풀리지 않음

• Sticky Connection(동일한 사용자가 발생시킨 요청은 동일한 WAS에서 처리됨을 보장) 제약에서 자유로움
  

• 단점

  • Session을 저장하기 위한 별도의 외부 스토리지가 필요 (관리 포인트 증가)
  • 외부 스토리지 장애 발생 시 대규모 장애 발생 가능성이 커짐
    • Session 클러스터를 위한 외부 스토리지가 SPOF 지점이 되는것을 방지하기 위해 외부 스토리지는 보통 클러스터로 구성됨