스테이트풀 vs. 스테이트리스

스테이트풀 애플리케이션과 스테이트리스 애플리케이션의 차이는 스테이트풀 애플리케이션이 과거와 현재 정보를 저장하는 반면, 스테이트리스 애플리케이션은 그렇지 않다는 데 있습니다. 

스테이트풀 애플리케이션 및 프로세스의 사용자는 인터넷을 통해 이미 확립된 정보와 프로세스를 저장 및 기록하고, 다시 불러올 수 있습니다. 스테이트풀 애플리케이션에서는 서버가 각 사용자 세션의 상태를 추적하고 사용자의 상호작용 및 과거 요청에 관한 정보를 유지합니다. 스테이트풀 애플리케이션은 온라인 뱅킹이나 이메일처럼 반복해서 사용할 수 있으며, 이전 트랜잭션의 컨텍스트를 통해 수행되므로 현재 트랜잭션은 이전 트랜잭션에서 발생한 내용의 영향을 받을 수 있습니다. 이러한 이유로 스테이트풀 애플리케이션은 사용자 요청을 처리할 때마다 동일한 서버를 사용합니다.  

스테이트풀 트랜잭션이 중단되는 경우 컨텍스트와 이전 내용이 저장되므로 중단된 부분부터 어느 정도는 다시 시작할 수 있습니다. 스테이트풀 애플리케이션은 창 위치, 기본 설정 사항, 최근 활동 등을 추적합니다. 스테이트풀 트랜잭션을 동일한 사람과 주기적으로 나누는 대화라고 생각할 수 있습니다.

우리가 일상에서 사용하는 애플리케이션의 대다수가 스테이트풀입니다. 그러나 기술의 발전에 따라 마이크로서비스와 컨테이너를 통해 클라우드에서 애플리케이션을 더 쉽게 빌드하고 배포할 수 있게 되었습니다.

스테이트리스 애플리케이션을 위한 API 사례 설명서 보기

스테이트리스 프로세스 또는 애플리케이션은 사용자의 이전 상호작용에 관한 정보를 유지하지 않습니다. 그리고 과거 트랜잭션에 대해 저장하는 지식 또는 참조도 없습니다. 각 트랜잭션은 마치 처음부터 시작하는 것처럼 진행됩니다. 스테이트리스 애플리케이션은 하나의 서비스 또는 기능을 제공하고 Content Delivery Network(CDN, 콘텐츠 전달 네트워크), 웹 또는 프린트 서버를 사용하여 이러한 단기 요청을 처리합니다.

스테이트리스 트랜잭션의 예시로는 질문에 대한 답을 찾기 위해 온라인에서 검색하는 것을 들 수 있습니다. 검색 엔진에 질문을 입력한 뒤 Enter 키를 누릅니다. 트랜잭션이 의도치 않게 중단되거나 종료되어도 새로운 트랜잭션을 시작하면 됩니다. 스테이트리스 트랜잭션을 요청 하나에 응답 하나가 제공되는 자동판매기처럼 생각하면 됩니다. 

스테이트풀과 스테이트리스의 주된 차이점은 애플리케이션이 사용자 상호작용의 현재 상태에 대한 정보를 유지하는지 아니면 애플리케이션이 각 요청을 별도의 단일 트랜잭션으로 취급하는지 여부입니다. 그러나 다음과 같은 구체적인 차이점도 있습니다.

• 확장성: 스테이트리스 애플리케이션의 경우 각 요청이 독립적이고 모든 사용 가능한 서버에서 처리될 수 있으므로 일반적으로 확장성이 더 좋습니다. 스테이트풀 애플리케이션에는 부하 분산과 세션 관리를 위해 더 복잡한 메커니즘이 필요할 수 있습니다.
• 내결함성: 스테이트리스 애플리케이션의 경우 서버의 손실이 사용자 세션에 영향을 미치지 않으므로 내결함성이 더 높을 수 있습니다. 반면 스테이트풀 애플리케이션에서는 세션 복제나 클러스터링 같은 추가 조치가 마련되어 있지 않을 경우 서버의 손실이 세션 데이터의 손실로 이어질 수 있습니다.
• 리소스 활용도: 스테이트리스 애플리케이션은 세션 데이터를 저장하고 관리할 필요가 없으므로 리소스 활용도가 낮은 경우가 많습니다. 스테이트풀 애플리케이션이 세션 정보를 처리하고 유지하려면 더 많은 메모리와 처리 능력이 필요할 수 있습니다.
• 개발 복잡성: 스테이트리스 애플리케이션의 경우 여러 요청의 상태를 관리할 필요가 없으므로 개발과 유지 관리가 더 간편합니다. 반면 스테이트풀 애플리케이션은 세션 데이터와 상태 관리를 신중하게 처리해야 합니다.

클라우드 컴퓨팅과 마이크로서비스의 인기가 높아지면서 스테이트풀 또는 스테이트리스 여부에 상관없이 애플리케이션 컨테이너화의 인기도 높아졌습니다. 컨테이너는 애플리케이션 코드를 라이브러리 및 종속성과 함께 패키징하는 단위입니다. 따라서 이동이 쉽고 데스크톱, 기존 IT 인프라, 클라우드를 막론하고 어느 환경에서든지 실행될 수 있습니다. 

이식성과 유연성이 좋은 컨테이너는 원래 스테이트리스로 개발되었습니다. 그러나 컨테이너 사용이 크게 늘면서 사람들은 기존 스테이트풀 애플리케이션을 컨테이너화(컨테이너에서 실행할 목적으로 재설계 및 재패키징)하기 시작했습니다. 그 결과 컨테이너 사용의 유연성과 속도를 확보하면서 동시에 스테이트풀의 스토리지와 컨텍스트를 이용할 수 있게 되었습니다.

이러한 이유로 스테이트풀 애플리케이션이 스테이트리스 애플리케이션과 매우 유사하게 보일 수 있으며 그 반대의 경우도 마찬가지입니다. 장기 스토리지가 필요 없는 스테이트리스 애플리케이션이면서도 서버가 쿠키를 사용하여 동일한 클라이언트에서 비롯된 요청을 추적할 수 있는 경우가 그 예시입니다. 

컨테이너가 대중화되면서 기업들은 데이터 스토리지, 쿠버네티스, StatefulSet를 사용하여 스테이트리스 컨테이너와 스테이트풀 컨테이너를 모두 관리하는 방법을 제공하기 시작했습니다. 스테이트풀은 컨테이너 스토리지의 주요 부분이며, 이제는 스테이트풀 컨테이너를 사용할지 여부가 아니라 언제 사용할지가 중요한 문제가 되었습니다. 

컨테이너를 스테이트풀 또는 스테이트리스로 사용할지 여부는 결국 어떤 종류의 애플리케이션을 어떤 용도로 빌드하는지에 따라 결정됩니다. 스테이트리스는 정보를 일시적이고 신속하게 임시로 필요로 하는 경우에 적합합니다. 그러나 애플리케이션의 한 세션에서 다음 세션까지 발생하는 상황에 대한 메모리가 더 많이 필요한 경우 스테이트풀이 적합합니다.

스테이트풀과 스테이트리스 모두 Red Hat이 지원합니다. Red Hat의 엔터프라이즈 레디 쿠버네티스 플랫폼인 Red Hat OpenShift에서 스테이트풀 컨테이너를 오케스트레이션하든, Red Hat Integration을 통해 애플리케이션 개발을 위한 통합 환경을 구축하든, 권위 있는 어워드를 수상한 Red Hat의 지원과 업계 최대 파트너 에코시스템으로 뒷받침합니다. 

Red Hat OpenShift는 보안 중심의 통합 하이브리드 클라우드 애플리케이션 플랫폼을 제공하여 조직이 애플리케이션 개발 및 배포와 운영 프로세스를 현대화함으로써 혁신을 가속화하도록 지원합니다. 또한 조직이 애플리케이션 플랫폼을 실행하는 위치와 방법을 자유롭게 선택할 수 있는 완전한 유연성을 제공합니다.

Red Hat Integration은 서비스 구성 및 오케스트레이션, 애플리케이션 연결 및 데이터 트랜스포메이션, 실시간 메시지 스트리밍, 변경 데이터 캡처, API 관리 기능을 제공하며 클라우드 네이티브 플랫폼 및 툴체인과 결합되어 현대적인 애플리케이션 개발 전체 과정을 지원합니다.

Red Hat의 전체 제품이 오픈소스 방식으로 솔루션을 구축하고 개발자 생산성을 개선하며 혁신을 촉진하는 방법을 확인하세요.

클라우드에서 스테이트풀 애플리케이션을 컨테이너화하는 방법에 대해 알아보기