상태 유지 웹 서버 아키텍처
상태 유지(Stateful)란 웹 서버가 사용자의 요청과 관련된 세션 정보, 로그인 상태 등의 사용자별 상태 정보를 서버 측에서 직접 관리하는 방식을 의미한다.
특징 및 장점
간단한 관리 및 구현 용이성
: 상태 정보가 서버에서 유지되므로 세션 관리를 쉽게 구현할 수 있다.
서버 중심의 제어
: 중요한 세션 데이터가 서버에 저장되어 있어 보안과 접근 제어를 보다 엄격하게 관리할 수 있다.
단점 및 고려사항
확장성 제한
: 상태 정보가 서버에 유지되기 때문에 여러 대의 서버로 확장할 때 세션 데이터의 동기화나 공유 문제를 해결해야 한다.
서버 리소스 과부하
: 많은 사용자 세션 정보를 유지하면 서버 메모리나 저장소의 부담이 커질 수 있다.
장애 대응 어려움
: 서버가 다운되거나 재시작될 경우 메모리에 저장된 세션 데이터가 유실될 가능성이 있어, 장애 시 복구 방안을 추가적으로 고려해야 한다.
무상태 웹 서버 아키텍처
그림의 공유 저장소는 RDBMS나 NoSQL일 수도 있고 Redis일 수도 있다.
무상태 웹 서버 아키텍처는 웹 서버가 사용자 상태 정보를 직접 관리하지 않고, 공유 저장소(RDBMS, NoSQL, Redis 등) 에 별도로 관리하여 서버가 독립적으로 동작할 수 있도록 설계된 구조다.
이를 통해 서버의 확장성 및 장애 대응력이 높아진다.
그림의 무상태 웹 서버 아키텍처는 상태 정보를 공유 저장소에 저장된 상태 정보를 참조한다.
- 사용자의 모든 요청은 HTTP 요청으로 전달되고, 요청을 받은 웹 서버는 공유 저장소에서 상태를 읽어 처리하므로, 요청을 처리하는 서버 간 종속성이 없다.
- 웹 서버가 상태를 갖지 않기 때문에, 확장성과 장애 복원력이 우수한 구조
특징 및 장점
높은 확장성
: 각 요청이 독립적이므로 서버 수를 쉽게 늘릴 수 있고, 로드밸런싱과 같은 분산 시스템 구성이 간편해진다.
SPOF(Single Point of Failure, 단일 장애 지점) 제거를 통한 장애 내성 향상
: 개별 서버가 장애가 나더라도 서비스 전체의 연속성에 영향을 최소화할 수 있다. 즉, 특정 서버가 다운되더라도 나머지 서버들이 요청을 처리할 수 있어 시스템의 전체적인 안정성이 높아진다.
서버 자원 관리 효율성
: 서버가 세션 데이터를 유지할 필요가 없으므로 메모리 및 저장소 자원을 효율적으로 사용할 수 있다.
단점 및 고려사항
클라이언트 측 복잡성 증가
: 상태 정보 관리를 클라이언트나 별도 시스템에서 처리해야 하므로 클라이언트의 구현 복잡도가 높아질 수 있다.
보안 관리 요구 증가
: 상태 정보가 클라이언트를 통해 전달될 때 정보 보호 및 데이터 무결성에 추가적인 보안 조치가 필요할 수 있다.
무상태 아키텍처로 전환하는 적절한 시점과 판단 기준
1. 확장성과 트래픽 증가
스케일 아웃(Scale-Out)이 필요한 시점
- 하나의 서버에서 세션이나 상태 정보를 관리하면 로드밸런싱 시에 반드시 세션 고정이 필요하게 된다.
- 세션 고정 방식으로 인해 로드밸런싱이 어려워지거나, 특정 서버의 부하가 급증할 때 외부 저장소를 도입할 필요성 고려
2. 장애 대응 및 복원력
- 상태 정보가 특정 서버 내에 존재하면 장애 발생 시 해당 서버의 세션 정보가 손실된다.
- 장애로 인한 서비스 중단이 발생하거나 데이터 손실 이슈가 한 번이라도 발생했다면 무상태 아키텍처 전환을 검토한다.
- Redis나 S3등으로 상태를 외부에 저장하면 서버 장애가 서비스 전체 장애로 이어지는 일을 예방할 수 있다.
3. 배포 자동화 및 CI/CD
- 서버 내 상태 저장은 무중단 배포를 어렵게 한다.
- 무중단 배포 요구가 커질수록 상태 관리가 외부로 빠져나가는 것이 필수적이므로, 배포 자동화가 활성화될 때 무상태로 전환하는 것이 좋다.
4. 인프라의 이중화 및 DR 전략
- 재해복구나 이중화 전략을 구성할 때 상태 정보가 외부화되어 있지 않다면 구성 및 관리 복잡도가 매우 높아진다.
- DR 전략이 중요한 시점(금융 서비스, 커머스 서비스 등)에는 처음부터 상태를 외부 저장소에 관리하도록 권장한다.
DR(Disaster Recovery)이란 재난 상황(자연 재해, 인재, 시스템 장애 등)으로 인해 IT 인프라가 중단되었을 때, 빠르게 정상 상태로 복구하고, 서비스를 연속적으로 유지하기 위한 전략핵심 목표 ➡️
업무 연속성,데이터 무결성,이중화
DR 전략의 예시
핫 사이트(Hot Site)
: 실시간으로 서비스 환경과 데이터를 동일하게 유지하는 별도의 데이터 센터로, 장애 발생 시 즉시 서비스를 전환할 수 있는 상태를 유지
콜드 사이트(Cold Site)
: 미리 최소한의 인프라만 준비해 두고, 장애가 발생했을 때 빠르게 데이터를 복구하고 시스템을 재구축하는 방식
외부화된 상태 관리(Externalized State Management)
: 데이터를 애플리케이션 내에서 관리하지 않고, 별도의 외부 스토리지에 저장해 놓는다.
5. 유지보수성 및 운영 효율성
- 여러 서버에서 상태 정보를 관리하면 디버깅과 장애 추적이 어렵다.
- 유지보수가 복잡해지거나 운영 비용이 증가하는 시점이라면 외부 저장소로 상태를 이동하는 것이 적합하다.
초기 설계 무상태? 상태 유지?
처음부터 상태 유지 관리를 지향하는 경우
아래와 같은 경우라면 상태 유지가 개발 편의성과 속도 측면에서 유리할 수 있다.
- 초기 스타트업 단계로 빠른 MVP 구현과 빠른 기능 검증이 중요할 때
- 아직 서비스 규모가 작고 예측 가능한 트래픽을 처리하는 프로토타입을 만드는 단계
- 향후 서비스 확장 계획이 명확하지 않고, 변화가 심한 단계
처음부터 무상태 설계를 지향하는 경우
- 향후 서비스 확장 계획이 명확한 경우
- 장기적으로 높은 확장성, 가용성, 배포 자동화가 필수적인 서비스
- 금융, 커머스, 의료 등 무중단 운영 및 데이터 신뢰성이 절대적으로 중요한 도메인
무상태 아키텍처가 도입 비용이 초기에 조금 더 들 수 있지만, 향후 빠르게 증가하는 관리 비용과 기술의 부재를 사전에 방지할 수 있다.
정리
| 상황 | 권장 사항 |
|---|---|
| 초기 MVP/프로토타입, 빠른 개발이 중요한 단계 | 내부 관리 권장 |
| 향후 명확한 확장 계획, 중요한 서비스, 장기적 안정성 필요 | 처음부터 무상태 설계를 권장 |
| 초기 상태 유지로 시작한 경우 전환 시점 | 트래픽 증가, 장애 대응, 배포 자동화 등이 주요 시그널 |
전환 지표&시그널
상태 유지에서 무상태로 전환할 시점을 판단하는 지표나 시그널의 요약(중요도 순)은 아래와 같다.
- 서비스의 확장성 및 트래픽 증가 여부
- 장애 발생 경험 또는 장애 복원성 요구
- 무중단 배포 및 CI/CD 자동화 필요성
- 인프라 이중화, DR 요구 수준
- 유지보수 및 운영 효율성 하락
