9장. 상태와 무상태의 이해
1. 상태란 무엇인가
상태(State)란
어떤 시스템이 이전 요청의 정보를 기억하고 있는 것을 의미한다.
예를 들어:
- 로그인 후 세션 정보가 서버 메모리에 저장됨
- 장바구니 정보가 특정 서버에 저장됨
- 사용자의 임시 데이터가 서버 내부에 보관됨
이 경우, 서버는 이전 요청의 정보를 “기억”하고 있다.
이를 상태가 있는 서버라고 한다.
2. 상태가 있는 서버의 문제점
상태가 있는 서버는 처음에는 단순해 보인다.
하지만 확장성과 연결되면 문제가 발생한다.
1) 로드밸런싱 문제
사용자가 로그인 후
서버 A에 세션이 저장되었다고 가정하자.
이후 요청이 서버 B로 전달되면
B는 로그인 정보를 알지 못한다.
즉, 특정 사용자가 특정 서버에 묶이게 된다.
이를 세션 종속성(Session Affinity) 문제라고 한다.
2) 서버 장애 시 데이터 손실
서버 A가 장애로 종료되면
그 서버 메모리에 있던 세션 정보도 사라진다.
사용자는 다시 로그인해야 할 수 있다.
3) 수평 확장의 제약
클라우드에서는 서버를 여러 대로 늘리는 것이 일반적이다.
하지만 상태가 서버 내부에 있다면
서버를 자유롭게 늘리고 줄이기 어렵다.
Auto Scaling이 제대로 동작하기 힘들다.
3. 무상태란 무엇인가
무상태(Stateless)는
각 요청이 독립적으로 처리되는 구조를 의미한다.
즉,
- 어떤 서버가 요청을 받아도 동일한 결과를 낼 수 있어야 한다.
- 이전 요청 정보에 의존하지 않는다.
서버는 단순히 요청을 처리하는 역할만 한다.
4. 왜 클라우드에서는 무상태가 중요한가
클라우드는 다음을 전제로 설계된다.
- 서버는 언제든지 종료될 수 있다.
- Auto Scaling으로 서버 수가 변한다.
- 다중 AZ 환경에서 서버가 분산된다.
이 환경에서 상태를 서버 내부에 저장하면
구조가 복잡해진다.
따라서 클라우드에서는
무상태 설계를 기본 전략으로 사용한다.
5. 무상태 설계는 어떻게 구현하는가
무상태가 되기 위해서는 상태를 서버 외부로 분리해야 한다.
1) 세션을 데이터베이스에 저장
- 로그인 정보
- 사용자 설정 정보
모든 서버가 같은 DB를 참조한다.
2) 캐시 서버 사용
Redis 같은 외부 캐시에 세션 저장.
장점:
- 빠른 속도
- 서버 간 공유 가능
3) JWT 방식 사용
로그인 정보를 토큰 형태로 사용자에게 전달하고
서버는 토큰을 검증만 수행.
서버가 세션을 저장하지 않아도 된다.
6. 상태와 무상태 비교
| 구분 | 상태 있음 | 무상태 |
|---|---|---|
| 세션 저장 위치 | 서버 내부 | 외부 저장소 |
| 확장성 | 제한적 | 매우 유리 |
| 장애 대응 | 취약 | 유리 |
| 로드밸런싱 | 복잡 | 단순 |
7. 현실적인 접근
완전한 무상태가 항상 가능한 것은 아니다.
예를 들어:
- 파일 업로드 중 임시 저장
- 대용량 처리 작업
- 트랜잭션 처리
이 경우에도
핵심 원칙은 같다.
서버 내부가 아니라 외부 저장소에 상태를 둔다.
8. 설계 철학으로서의 무상태
온프레미스 사고:
- 서버는 오래 살아있다.
- 메모리에 저장해도 괜찮다.
클라우드 사고:
- 서버는 언제든지 교체될 수 있다.
- 서버는 일시적인 존재다.
- 상태는 외부에 둔다.
이 사고 전환이
클라우드 네이티브 설계의 핵심이다.
9. 이 장의 핵심 정리
- 상태는 이전 요청 정보를 기억하는 것이다.
- 상태가 서버 내부에 있으면 확장이 어렵다.
- 무상태는 요청이 독립적인 구조다.
- 클라우드에서는 무상태 설계를 권장한다.
- 상태는 외부 저장소에 분리하는 것이 원칙이다.