Stateful vs Stateless

Stateful, Stateless라는 용어는 네트워크, 프로그래밍, 데이터베이스, 애플리케이션 아키텍처 등 다양한 기술적 맥락에서 사용되며, 기본적으로 상태(state)를 유지하는지 여부에 따라 대상을 구분하는 개념이다.

Stateful

클라이언트-서버 관계에서 Stateful하다는 것은 서버가 클라이언트의 상태를 기억하고, 요청 간의 맥락(context)을 유지한다는 것을 의미한다.

클라이언트의 상태를 서버에서 관리하면,

• 중앙 집중화

  • Props:

    • 시스템 안정성과 데이터 일관성을 보장하기 용이하다.
    • 사용자가 작업을 중단하거나 연결이 일시적으로 끊어져도, 이전 상태를 복원(failover)할 수 있다.

  • Cons:

    • 상태 관리의 책임이 서버에 있으며, 클라이언트의 상태 관리를 위한 저장 공간이 추가로 요구된다.
    • 서버당 관리할 수 있는 클라이언트의 수가 한정적이며, 클라이언트 수가 증가할수록 서버의 부하도 비례하여 증가한다.
    • 서버 설계가 상대적으로 복잡해지며, 이를 구현하는 데 추가적인 노력이 필요하다.
      • 특정 사용자의 요청이 항상 동일한 서버에 도달(sticky)해야 하며,
      • 모든 서버에서 각 사용자의 상태를 동기화해야 한다.

• 종속적인 클라이언트-서버

  • Props:

    • 트랜잭션의 연속성을 보장하므로, 매 요청마다 클라이언트가 모든 데이터를 전송할 필요가 없다.
    • 실시간 상호작용이나 지속적인 세션 유지가 가능하여 사용자 경험이 향상된다.

  • Cons:

    • 상태를 저장하는 서버가 장애가 발생하면, 해당 서버에 저장된 클라이언트에 대한 정보가 손실될 수 있다. → SPOF
    • 대규모 시스템에서 수평적 확장(scale-out)이 제한적이며, 성능 확장에 어려움을 겪을 수 있다.

Stateful 프로토콜 (=상태 프로토콜)

• TCP

  • 3-Way Handshake

    신뢰할 수 있는 연결을 설정하고, 클라이언트와 서버 간의 데이터 전송을 안전하게 보장한다.

    • 클라이언트가 서버에 SYN(연결 요청 메시지)를 전송하고
    • 서버가 클라이언트의 요청을 수락하고, SYN-ACK(연결 수락 메시지)를 보낸다.
    • 클라이언트가 서버의 수락 메시지를 확인하고, ACK(확인 메시지)를 보낸다.
• FTP

Stateless

클라이언트-서버 관계에서 Stateless하다는 것은 서버가 클라이언트의 상태를 유지하지 않으며, 각 요청은 독립적인 트랜잭션으로 처리한다는 것을 의미한다.

클라이언트의 상태를 유지하지 않으면,

• 책임의 이동

  • Props:

    • 서버는 클라이언트의 상태를 관리하지 않으므로 리소스 사용이 감소하고, 트랜잭션 처리 속도와 효율성이 향상된다.
    • 클라이언트와 서버 간의 느슨한 결합(Loose Coupling) 으로 시스템 아키텍처가 단순해지고, 관리가 용이해진다.

  • Cons:

    • 클라이언트와 서버의 연결 유지가 필요한 경우, 외부에서 상태를 별도로 관리해야 한다.
    • 서버가 이전 요청의 상태를 기억하지 않으므로, 오류 처리가 더 복잡할 수 있다.
    • 데이터 동기화 및 일관성 보장 어려울 수 있다.
      • 모든 요청이 독립적이기 때문에 요청 간의 처리 순서 보장이 어렵다.
      • 분산된 여러 서버가 동일한 데이터를 처리할 때, 클라이언트 요청 간 데이터의 동기화가 추가적으로 필요하다.

• 독립적인 클라이언트-서버

  • Props:

    • 서버가 장애가 발생하더라도, 다른 서버로 요청을 전환할 수 있으므로 시스템의 가용성이 유지된다. → Fault Tolerance
    • 높은 부하가 발생하더라도 서버를 신속하게 프로비저닝할 수 있어 수평적 확장(scale-out)이 용이하다.

  • Cons:

    • 서버는 클라이언트의 모든 요청에 대해 상태를 확인하고 인증을 수행해야 하며, 동일한 데이터가 반복적으로 처리될 가능성이 높다.
    • 클라이언트는 매 요청마다 필요한 모든 상태 정보(인증 토큰, 사용자 데이터 등)를 포함해야 하므로, 요청 크기가 커지거나 네트워크 비용이 증가할 수 있다.

Stateless Protocol (= 무상태 프로토콜)

• HTTP

  기본적으로 HTTP는 Stateless, Connectionless한 특성을 가진 프로토콜이다.
  클라이언트와 서버 간의 연결을 유지하려면 클라이언트의 브라우저 단에 상태를 저장하거나 인증하는 방법이 필요하다.

  • Cookie & Session
  • JWT(JSON Web Tokens)
• UDP
• DNS

모든 것을 무상태로 설계할 수 없다.

과거의 서버 중심 아키텍처에서는 클라이언트의 역할이 제한적이었고, 대부분의 작업이 Stateful하게 처리되었다.
그러나 시간이 흐르고 대규모 시스템의 필요성이 증가하고, 클라우드 환경과 마이크로서비스 아키텍처가 발전하면서 Stateless 아키텍처의 장점인 확장성, 신뢰성, 유연성 등이 주목받게 되었다.

Stateless만으로 해결할 수 없는 문제들

Stateless 아키텍처는 많은 장점이 있지만, 여전히 모든 것을 Stateless만으로 설계할 수는 없다.

1. 사용자의 인증 및 세션 관리

   Stateless에서는 서버가 클라이언트의 상태를 저장하지 않기 때문에 사용자 인증 상태나 세션을 관리하는 데 어려움이 있다. JWT와 같은 방법으로 클라이언트 측에서 상태를 관리하더라도, 복잡한 세션 관리나 권한 제어 등에서는 추가적인 고려가 필요하다.

2. 실시간 시스템

   실시간 시스템은 사용자와 서버 간의 지속적인 연결과 상태를 유지하는 것이 중요하다. 예를 들어 채팅 시스템이나 실시간 온라인 게임, 실시간 거래 시스템 등에서는 클라이언트와 서버 간에 지속적인 상태 관리가 필수적이다.

3. 미션 크리티컬 시스템

   안전과 관련된 시스템에서는 여러 개의 상태를 지속적으로 추적하여 오류를 방지해야 한다. 예를 들어, 항공기 제어 시스템, 의료 모니터링 시스템 등에서는 여러 센서에서 수집된 데이터와 각 상태를 실시간으로 추적하며, 문제가 발생할 경우 즉각적인 조치를 취해야 한다.

4. 복잡한 비즈니스 로직이나 상태를 관리해야 하는 시스템

   금융 거래 시스템과 같은 시스템에서는 트랜잭션의 일관성을 보장해야 하며, 여러 단계를 거쳐 상태를 관리해야 한다. 이와 같은 시스템에서는 각 요청이 독립적이지 않으며, 상태가 중요한 요소이다.

결론

Stateless 아키텍처는 확장성, 신뢰성, 유연성 이외에도 많은 장점을 제공하며, 대규모 시스템, 클라우드 환경, 마이크로서비스 아키텍처에서 중요한 역할을 한다. 하지만 모든 시스템을 Stateless하게 설계할 수는 없다. 사용자 인증 및 세션 관리, 실시간 시스템, 미션 크리티컬 시스템, 복잡한 비즈니스 로직을 처리해야 하는 시스템에서는 여전히 상태 관리가 필수적이며, 이에 대한 추가적인 고려가 필요하다.

결국, Stateful과 Stateless 아키텍처는 각각 장단점을 가지고 있으며, 이를 어떻게 활용할지를 고민하는 것은 설계에서 중요한 부분이다. 일부 시스템에서는 두 가지 아키텍처를 적절히 결합하여 사용하는 것도 하나의 방법이 될 수 있다.