stateless architecture

Summary

Why did you use a stateless architecture?

Because a stateless architecture makes the system much easier to scale. Since the server does not store client state, any request can be handled by any server. This allows us to add or remove servers automatically as traffic changes, improving scalability and availability.

 

 

Stateless(무상태) 웹 서버란 이전 요청의 상태(state)를 서버가 기억하지 않는 서버를 말합니다.

즉, 모든 HTTP 요청을 독립적인 요청으로 처리합니다.

---

예를 들어 설명해보겠습니다.

사용자가 쇼핑몰에 접속했다고 가정해봅시다.

첫 번째 요청

GET /product/123

 

서버 응답

상품 정보 반환

 

---

두 번째 요청

POST /cart

 

상품 123 장바구니 추가

 

Stateless 서버는

"아까 상품을 봤던 사람이네"

라는 것을 기억하지 않습니다.

매 요청마다 필요한 정보를 모두 받아야 합니다.

예를 들면

POST /cart

Authorization: Bearer JWT...
productId=123

 

처럼 인증 정보와 필요한 데이터를 함께 보내야 합니다.

---

왜 Stateless로 만들까?

가장 큰 이유는 확장성(Scalability) 때문입니다.

예를 들어 서버가 3대 있다고 가정합니다.

Client

     |
     |
Load Balancer
   /    |     \
 S1    S2     S3

 

첫 요청은

S1

 

으로 갈 수 있고

다음 요청은

S3

 

으로 갈 수도 있습니다.

만약 서버가 로그인 정보를 메모리에 저장한다면

S1 : 로그인 상태 있음

S2 : 모름

S3 : 모름

 

이 됩니다.

그러면

다음 요청이 S3으로 가면

로그인이 안 되어 있습니다.

 

라고 나옵니다.

그래서 서버 메모리에 상태를 저장하지 않습니다.

---

Stateless에서는 로그인은 어떻게 하나?

보통

1. JWT

Client
   ↓
로그인

↓

JWT 발급

↓

매 요청마다

Authorization: Bearer xxx

 

JWT 안에

userId

role

expireTime

 

등이 들어 있습니다.

서버는 JWT만 검증하면 됩니다.

---

2. Session + Redis

또는

Client
    ↓
Session ID

↓

Redis

 

에 로그인 상태를 저장합니다.

서버는

SessionID

↓

Redis 조회

 

만 합니다.

이 경우에도 특정 웹 서버가 상태를 갖는 것이 아니라, 상태를 외부 저장소(Redis 등)에 두므로 웹 서버 자체는 Stateless하게 운영할 수 있습니다.

---

Stateful와 Stateless 차이

StatefulStateless

서버가 사용자 상태를 기억	서버가 상태를 기억하지 않음
메모리에 Session 저장	요청마다 필요한 정보 전달
서버 교체 어려움	서버 추가/삭제 쉬움
수평 확장 어려움	수평 확장 쉬움
로드밸런싱 제약 있음	어떤 서버가 처리해도 됨

---

Spring Boot에서는?

Spring Boot REST API는 대부분 Stateless하게 설계합니다.

예를 들어

GET /orders

 

요청 시

Authorization: Bearer eyJhb...

 

를 항상 보내고,

서버는 매 요청마다 JWT를 검증한 뒤 사용자를 식별합니다.

---

 대규모 서비스에서 중요한 이유

차량 수백만 대가 지속적으로 서버와 통신하는 환경에서는 Stateless 아키텍처가 특히 유리합니다.

Vehicle A
Vehicle B
Vehicle C
      │
      ▼
Load Balancer
      │
 ┌────┼────┐
 ▼    ▼    ▼
API1 API2 API3

 

어떤 차량의 요청이든 로드밸런서가 아무 API 서버로 보내도, 각 서버는 요청에 포함된 인증 정보와 데이터를 이용해 동일하게 처리할 수 있습니다. 서버 간에 사용자나 차량의 연결 상태를 공유할 필요가 없기 때문에 서버를 쉽게 추가하거나 교체할 수 있고, 장애가 발생해도 다른 서버가 계속 요청을 처리할 수 있습니다.

핵심은 다음 한 문장입니다.

Stateless 웹 서버는 이전 요청을 기억하지 않고, 모든 요청을 독립적으로 처리하는 서버이며, 이를 통해 높은 확장성과 장애 대응 능력을 얻을 수 있습니다.