상태 저장 및 상태 비저장 애플리케이션: DevOps에 미치는 영향

Stateful 및 Stateless는 애플리케이션이 수명이 긴 프로세스를 관리하는 방법을 정의하는 두 가지 유형의 컴퓨팅 아키텍처입니다. 일부 시스템은 본질적으로 상태 비저장이며 다른 시스템은 상태 저장 모델링되는 경향이 있습니다. 어떤 접근 방식을 선택하든 설계 및 운영 팀이 솔루션을 구축하고 유지 관리하는 방법에 영향을 미칩니다.

이 문서에서는 스테이트풀(Stateful) 앱과 스테이트리스(Stateless) 앱의 차이점과 각각을 사용할 수 있는 경우에 대해 알아봅니다. 또한 두 모델이 DevOps 구현 요구 사항에 어떤 영향을 미치는지 확인할 수 있습니다.

상태란 무엇입니까?

서비스의 “상태”는 한 트랜잭션 또는 이벤트 중에 기록된 다음 다른 트랜잭션 또는 이벤트 중에 호출되는 영구 정보입니다. 상태의 가장 간단한 예 중 하나는 데이터베이스 서버입니다. 데이터베이스 서버는 안전하게 저장해야 하는 저장된 데이터를 관리합니다. 한 세션에 저장된 레코드는 다음 세션에 사용할 수 있어야 합니다.

상태는 앞으로 사용할 수 있도록 세심하게 관리해야 합니다. 외부 시스템은 이전 이벤트를 참조하기 위해 많은 정보를 제공할 필요가 없습니다. 결제 거래 번호와 같은 간단한 식별자를 통해 서비스는 결제 금액 및 배송 주소와 같은 작업과 관련된 기타 데이터를 복구할 수 있습니다.

상태 비저장 애플리케이션이란 무엇입니까?

모든 애플리케이션에 상태가 있는 것은 아닙니다. 일부 시스템은 수명이 긴 데이터로 작동하지 않거나 성능 향상을 위해 캐시합니다. 이전에 저장한 데이터가 손실된 경우에도 계속 작동합니다.

상태 비저장 애플리케이션은 각 이벤트를 개별적으로 처리합니다. 이벤트는 서로 또는 애플리케이션이 실행 중인 더 큰 컨텍스트를 인식하지 못합니다. 이 품질은 상태 비저장 시스템의 고려를 단순화합니다. 이전 활동이 현재 작업에 영향을 줄 위험은 없습니다.

내 애플리케이션이 스테이트풀(Stateful)입니까 아니면 스테이트리스(Stateless)입니까?

일부 애플리케이션은 상태 저장 모델과 상태 비저장 모델 사이의 경계를 흐리게 합니다. 접근하는 관점에 따라 동일한 시스템을 상태가 있거나 없는 상태로 볼 수 있습니다.

클라이언트 측 웹 애플리케이션은 일반적으로 서비스 운영자의 관점에서 무상태로 간주됩니다. 다른 구성 요소와 독립적인 정적 웹 서버에서 호스팅할 수 있습니다. 애플리케이션은 사용자의 기기에 저장된 설정 및 최근 페이지 기록과 같은 사용 중 상태를 계속 누적할 수 있습니다. 이 형태의 상태는 애플리케이션 배포에 영향을 미치지 않기 때문에 DevOps 팀과 관련이 없습니다.

애플리케이션이 데이터를 저장하는 방법을 살펴봄으로써 애플리케이션에 상태 저장 또는 상태 비저장 배포 모델이 필요한지 여부를 결정할 수 있습니다. 지속성이 없거나 데이터가 사용자의 장치에만 저장되거나 Amazon S3와 같은 관련 없는 저장소 공급자에만 저장되는 경우 상태가 없습니다. 파일 시스템 쓰기 및 기타 변경 사항을 통해 환경을 직접 변경한 다음 이러한 변경 사항을 무기한 유지해야 하는 경우 응용 프로그램은 상태를 유지합니다.

컨테이너 및 클라우드로 상태

최신 애플리케이션은 클라우드에 컨테이너로 배포되는 경우가 많습니다. 컨테이너는 부작용 없이 교체할 수 있는 임시 기능 단위로 설계되었습니다. 이는 주로 상태 비저장 계산 구성 요소임을 의미합니다.

그러나 컨테이너를 사용하여 상태 저장 시스템을 캡슐화할 수 있습니다. 영구 볼륨은 개별 컨테이너 인스턴스보다 오래 지속되는 내구성 스토리지를 탑재하는 수단을 제공합니다. 기존 VM 및 베어메탈 배포와 비교할 때 차이점은 컨테이너 상태를 관리하려는 내부 의도에 달려 있습니다.

상태 저장 시스템을 컨테이너화하려면 상태가 발생하는 위치와 저장 방법을 예상해야 합니다. 임의의 파일 시스템 경로는 볼륨에 매핑되지 않기 때문에 순진하게 작성할 수 없습니다. 볼륨이 없으면 컨테이너가 중지되거나 교체되면 데이터가 손실됩니다. 애플리케이션이 마운트된 볼륨에 대한 경로를 일관되게 기록하도록 하려면 리팩토링 기간이 필요할 수 있으므로 사전에 데이터 스토리지 요구 사항을 결정해야 합니다.

상태가 DevOps에 미치는 영향

스테이트풀(Stateful) 서비스를 사용하는지, 스테이트리스(Stateless) 서비스를 사용하는지에 따라 DevOps 프로세스를 조정해야 합니다. 상태 비저장 배포 모델은 훨씬 더 많은 여유를 제공합니다. 상태에 대한 지속적인 액세스에 대해 걱정할 필요 없이 새 컨테이너를 쉽게 시작하고 여러 분산 노드로 확장할 수 있습니다.

스테이트풀(Stateful) 서비스는 관리에 대한 보다 사려 깊은 접근 방식이 필요합니다. 각 애플리케이션 인스턴스에는 공유 상태에 대한 액세스 권한이 부여되어야 합니다. 이로 인해 크기 조정이 제한될 수 있습니다. 예를 들어, 여러 노드가 동시에 쓰기 액세스 권한이 있는 볼륨을 탑재할 수 있는 Kubernetes 배포는 거의 없습니다 .

두 가지 유형의 응용 프로그램 모두 문제가 발생하기 전에 미리 알 수 있도록 사전 모니터링이 필요합니다. 이는 스토리지 요구 사항을 미리 파악하고 볼륨 탑재가 컨테이너 일정 옵션에 영향을 미치는 시점을 결정해야 하기 때문에 상태 저장 솔루션에 더 중요합니다. 상태 저장 배포는 일반 백업 전략으로도 지원되어야 합니다.

또한 상태는 환경을 정확하게 재현하기 어렵게 하여 DevOps 프로세스를 복잡하게 만듭니다. 개발자의 컴퓨터에서는 파악하기 어려운 상태로 남아 있으면서도 문제가 프로덕션에 존재하는 것이 가능해집니다. 이러한 문제는 진단하기 어려울 수 있습니다. 개발자가 샌드박스에서 문제를 재현할 수 있도록 환경을 복제할 수 있는 메커니즘을 제공하여 관리하기 쉽게 만들 수 있습니다.

상태는 항상 복잡성과 오버헤드를 추가합니다. 볼륨 및 데이터베이스와 같은 상태 관리 솔루션을 구성하고 제공해야 하므로 지속적인 통합 파이프라인을 더 복잡하고 유지 관리하기 어렵게 만듭니다. 상태는 대부분의 주요 응용 프로그램에서 피할 수 없으므로 시스템을 상태 비저장 상태로 유지하기 위해 너무 열심히 노력하는 것은 헛된 청어가 될 수 있습니다. 더 많은 작업이 필요하더라도 도구와 교육을 사용하여 상태 저장 애플리케이션을 DevOps 루틴에 원활하게 통합하는 것이 좋습니다.

요약

스테이트풀(Stateful) 애플리케이션과 스테이트리스(Stateless) 애플리케이션을 구분하는 것은 DevOps의 성공에 중요합니다. DevOps 관점에서 스테이트풀(Stateful) 애플리케이션은 각 인스턴스에 영구 데이터 저장소에 대한 액세스 권한을 부여해야 하기 때문에 배포 및 유지 관리가 더 어렵습니다.

상태 비저장 애플리케이션은 환경과 완전히 분리되어 일반적으로 클라우드에서 더 쉽게 컨테이너화하고 확장할 수 있습니다. 그러나 진정한 상태 비저장 시스템은 상대적으로 드물기 때문에 일반적으로 상태 저장 데이터 저장소와 결합됩니다. 상태 저장 배포를 지원하는 도구를 구축하면서 가능한 경우 상태 비저장 구성 요소로 리팩토링하는 것은 일반적으로 최적화된 DevOps와 시스템의 기능 요구 사항의 균형을 맞추는 가장 효과적인 방법입니다.