Stateful vs Stateless
Stateful vs Stateless Architecture: Why Stateless Won를 번역 및 정리한 글입니다.
그림. Stateless vs Stateful.
Quorum: 실행을 위해 최소한의 인스턴스 수가 필요하는 것을 의미합니다.
Stateless vs Stateful 아키텍쳐
Stateful, Stateless 개념은 대부분의 서버 아키텍처 설계의 기반입니다.
Stateful 서비스는 세션이나 트랜잭션을 기록하여 동일한 입력에도 다르게 반응합니다.
Stateless 서비스는 클라이언트에 의존하여 세션을 유지하고 상태가 아닌
리소스를 조작합니다.
Stateless 및 Stateful 아키텍처를 고려할 때 혼동을 일으킬 수 있는 두 가지는
다음과 같습니다:
-
Stateless 서비스는 일반적으로 어떤 형태로든 상태를 처리해야 합니다.
Stateless 란 서버측 세션에서 이 상태가 추적되지 않는다는 의미 입니다. -
“상태”란 의미가 광범위한 용어입니다.
여기에서는 특히 인증 및 유사한 다중-작업 프로세스 를 위한 세션 유지를 의미합니다.
그러나 이는 Stateless 서비스가 일반적으로 수행하는 데이터를 데이터베이스에
영구저장하는 것과는 관련이 없습니다.
간단한 역사적인 맥락
역사적으로 클라이언트 시스템은 하드웨어와 소프트웨어에서 매우 제한적이었고(thin)
모든 무거운 작업은 강력한 서버에서 수행했습니다.
월드 와이드 웹의 폭증과 관련된 HTTP(HyperText Transfer Protocol)의 성장으로,
웹 브라우저, PC 및 기타 최종 사용자 소프트웨어 및 하드웨어가 더욱 강력해졌고 클라이언트는
이전에 서버에서 처리했던 더 많은 기능을 처리(thicker)하게 되었습니다.
소프트웨어 및 디지털 시스템이 복잡해짐에 따라 세션 요구 사항도 증가했습니다.
HTTP는 Stateless 프로토콜이기 때문에 소프트웨어가 이전에 발생한 일에 따라 시스템 동작이
달라지는 장기 트랜잭션(long-running transaction)들을 수행하기가 어렵습니다.
영화 ‘니모를 찾아서’ 를 본 적이 있다면, 끊임없이 잊어버리는 도리와 대화를 나누는 것이
다단계 프로세스에서 HTTP를 사용하는 것이라고 생각할 수 있습니다.
이 “건망증” 문제를 처리하는 두 가지 주요 방법이 있습니다:
- Stateful: 서버에 추가 정보, 현재 트랜잭션의 상태를 기록하고 다음 명령을 기다립니다.
- Stateless: 추가 정보를 클라이언트 측에서 저장하고 각 단계에서 이전 단계를 ‘알려주는’
추가 정보를 전달합니다. 이 기능은 일반적으로 쿠키나 localStorage를 사용하여 구현됩니다.
Stateful 과 Stateless 비교
그림. SOAP, REST 및 GraphQL 기반 웹 서비스.
Stateless 솔루션의 장점
Stateless 솔루션의 웹 또는 앱 서비스는 Stateful 구현에 비해 많은 장점이 있습니다.
우선 Stateful 서버 구현은 초보자들에게 어렵습니다.
시스템 전체에서 많은 불완전한 트랜잭션과 세션이 발생할 수 있는 (잠재적으로 다중의)
상태를 참조할 수 있어야 합니다.
클라이언트에서 서버로의 연결 관리도 한 요인입니다: 각 클라이언트와 서버 사이에
“끈적하게 고정된” 연결이 필요한데, 이는 본질적으로 확장하기-어려운 제한입니다.
Stateful 아키텍처의 가장 큰 단점 중 하나는 쉽고 효율적으로 확장할 수 없다는 것입니다.
상태가 서버 측에서 관리된다면, 장기 트랜잭션의 각 단계를 동일한 서버에서 처리해야 합니다.
물리적인 서버가 하나만 필요한 소규모 서비스의 경우 상태를 추적하는 것은 쉽습니다.
그러나 수 백만 명의 사용자들의 부하를 처리하기 위해 더 많은 서버가 필요한 경우
다음과 같은 불편함을 감수해야 합니다.
- 특정 사용자의 요청이 항상 동일한 서버에 도달해야 하고
- 모든 서버에서 각 사용자의 상태를 동기화해야 합니다.
Stateless 아키텍처를 사용하면 서버 중 하나가 너무 바쁘거나 다운되는 것은
중요하지 않기 때문에 사용자는 트랜잭션의 각 단계에서 다른 서버에 접속할 수 있습니다.
Stateless: 클라우드-기반의 마이크로 서비스를 위한 기반 마련
서버 측 복잡성에 크게 의존하는 Stateful 솔루션을 개발할 때
클라이언트와 서버 간의 독립성 또는 느슨한 결합을 적용하면 유연성이 증가합니다.
현대 기술 스택에서 이것은 더 모듈화되었다는 의미입니다.
Stateless 아키텍처는 과거의 모놀리식 솔루션에서 벗어나는 데 도움이 되는,
더 작고 단순한 마이크로 서비스의 사용을 지지하고 있습니다.
Stateless 서비스는 마이크로 서비스 또는 클라우드 기반 솔루션과 약간의
상관 관계가 있습니다.
이미 Stateless 서비스를 구현한 비즈니스는 다른 마이크로 서비스로 기능들을
더 쉽게 분리할 수 있습니다. 그리고 이미 마이크로 서비스를 구현한 기업은
클라우드로의 단계별 마이그레이션을 보다 쉽게 수행할 수 있습니다.
이전의 모놀리식 Stateful 서비스 패턴과 비교하면, Stateless 서비스는
전 세계적으로 확장해야하고 애자일 방법론에 따라 자주 새 기능을 출시해야 하는
현대적인 요구 사항에 더 적합합니다.
Stateless 서비스를 통해 서비스의 수평적 확장은 더 쉬워집니다.
서버가 상태를 추적할 필요가 없다면 플릿(Fleet)에 더 많은 서버를 추가하는 것이
훨씬 간단합니다. 그러면 최대 수요를 처리하기 위해 더 많은 서버들을 신속하게
프로비저닝할 수 있으므로 비즈니스 비용을 절감할 수 있습니다.
예를 들어, 이러한 패턴에 따라 수요가 감소할 때 추가 컴퓨팅 성능을 지불하지 않고
수요가 있을 때만 컴퓨팅 용량을 늘릴 수 있습니다.
프로비저닝(Provisioning)이란 IT 인프라를 설정하는 프로세스입니다.
이 요소들을 바탕으로, 오늘 날의 온라인 서비스는 Stateless 아키텍처를 선택하는 것은
거의 항상 올바른 선택입니다.
댓글남기기