가이드라인: 서비스 상태 관리
이 가이드라인에서는 Stateful 및 Stateless 서비스 사용과 관련된 문제를 성능 및 견고성에 대한 영향의 관점에서, 또한 상호작용에 트랜잭션 접근 방식이 필요한 경우에 대해 설명합니다. SOA 환경에서의 상태 관리 개념은 세 가지 기본 카테고리(트랜잭션 상태, 보안 상태 및 기능적 상태)로 나눌 수 있습니다.
관계
관련 요소
기본 설명

소개

Stateful 및 Stateless 컴포넌트 개념은 특히 분산 응용프로그램 및 시스템 개발에 있어 중요합니다. 그러나 이 개념은 최근에 와서야 공통 용어에 포함되었습니다. 이 개념의 핵심은, 두 컴포넌트 또는 서비스가 통신을 수행하고 클라이언트와의 대화 시 일부 상태를 서버 컴포넌트로 관리하는 경우 서버 컴포넌트의 충돌(또는 네트워크 장애)로 인해 클라이언트가 대화를 완료하지 못하고 다시 시작해야 한다는 것입니다. 또한 클라이언트 요청을 컴포넌트 세트 중 하나로 다시 지정해야 합니다. 이 경우 컴포넌트 세트는 대화 상자에 대한 공통 스토어를 공유하지 않습니다. 이는 웹 응용프로그램 개발과 관련하여 잘 알려진 문제이며 이 경우 해당 상태는 가능한 발생하지 않도록 주의깊게 관리되며 클라이언트가 대화 자체로(각 메시지로 상태 전달) 관리하거나 Stateful 서버측 컴포넌트에서 주의깊게 디자인됩니다. 예를 들어, 일반적인 Stateful 웹 상호작용의 예제는 장바구니입니다. 사용자가 잠시 자리를 비운 동안에도 장바구니가 지속되는 것으로 예상하지만 동시 사용자가 100,000명인 경우의 대처 방법도 고려해야 합니다.

Stateful 컴포넌트는 근본적으로 올바르지 않은 컴포넌트로서 주의 깊게 관리하여 보다 엄격한 표준에 맞게 개발하지 않으면 성능 및 복원이 실패할 수 있는 영역만을 나타내는 것은 아닙니다. 실제로는 모든 비즈니스 응용프로그램에 해당 속성이 근본적으로 Stateful 상태인 엔티티를 관리 또는 나타내는 서비스를 포함하거나 특정 논리 시퀀스로 액세스해야 하는 서비스가 포함되어 있습니다. 또한 J2EE 아키텍처는 별도 Stateless 및 Stateful 세션 Bean을 정의함으로써 이러한 문제를 명확하게 나타내고 Stateful 컴포넌트에 대한 특정 제한사항을 정의합니다. 이를 통해 Stateful 서비스를 간단하게 분류할 수 있으며 이러한 서비스를 우선적으로 막지 못한 이유를 이해할 수 있습니다. Stateful 서비스의 이유는 다음과 같습니다.

서비스가 클라이언트 대신 상태를 유지합니다(예: 장바구니). 클라이언트와 서비스 간 호출 사이에 일부 데이터가 지속되어야 합니다. 이 데이터는 대화의 일부이므로 특별한 주의 없이 클라이언트와 해당 서버 자원을 바인드할 수 있습니다.

서비스가 Stateful 자원을 관리합니다. 이 경우 일반적으로 서비스가 각각 상태를 갖는 자원 또는 엔티티 세트를 관리합니다. 예를 들어, 고객 주문에 상태가 포함되는 경우 네트워크 스위치에도 상태가 포함되는 방식입니다. 따라서 주문을 완료 또는 지연시키거나 스위치를 재부팅하여 해당 오브젝트를 관리하는 서비스 인터페이스는 특정 엔티티 상태를 변경합니다.

서비스에 Stateful 프로토콜이 포함됩니다. 이 경우 서비스가 자신이 제공하는 오퍼레이션에 대한 논리 정렬을 포함합니다. 예를 들어, login(), dostuff() 및 logoff() 오퍼레이션이 포함되며 이로 인해 login()을 호출해야 dostuff() 또는 logoff() 오퍼레이션을 호출할 수 있음을 유추할 수 있습니다.

여러 컴포넌트 아키텍처에서 사용되지만 서비스 영역에는 적용되지 않는 다른 상태 양식은 트랜잭션 상태 개념입니다. 컴포넌트의 경우 클라이언트가 작성하고 유지보수하는 트랜잭션 범위 내에서 해당 클라이언트가 컴포넌트에 대해 get() 및 update() 메소드를 호출할 수 있는 것으로 표시할 수 있습니다. update() 메소드는 일부 기본 트랜잭션 스토어를 변경하는 것으로 가정됩니다. 이를 위해서는 대부분의 경우 미들웨어 플랫폼이 개입하여 트랜잭션을 조정해야 하며 클라이언트가 공개 트랜잭션으로 트랜잭션이 필요한 메소드를 호출할 수 있도록 해야 합니다. 서비스의 경우 일반적인 2단게 확약 관점의 트랜잭션을 여러 서비스 호출에서 공개 상태로 유지하는 모델을 따르는 것은 적합하지 않은 것으로 간주됩니다. 이제 서비스 호출을 통한 트랜잭션에 대한 표준이 개발되지만 이러한 표준은 근본적으로 다른 패러다임(보상)을 따르며 미들웨어 플랫폼에서 다르게 지원됩니다.

위의 내용에서도 알 수 있듯이 성공적인 Stateful 서비스 개발을 위한 가장 명확한 기법은 서비스 상태를 구체화하는 것입니다. 이 방법을 사용하는 경우 서비스에 상태가 포함될 뿐만 아니라 이 상태를 서비스 스펙의 일부로 식별할 수 있습니다. 이 내용은 아래 Stateful 서비스의 두 클래스와 관련하여 설명합니다.

대부분의 소프트웨어 서비스는 J2EE 또는 Microsoft .NET와 같은 기존 미들웨어 플랫폼 위에서 개발되므로 상태 관리를 지원하기 위해 해당 플랫폼 아키텍처에서 설명되는 구현 기법이 있습니다. 따라서 이 가이드라인은 Stateful 서비스의 특정 클래스에 대한 디자인 기법에 초점을 맞춥니다. 또한 이는 새로운 관심사항 영역이 아닙니다. 초록색 화면(실제 3270 터미널)을 사용하여 CICS(IBM Customer Information Control System)에서 대화 및 비대화 트랜잭션을 개발하는 메인프레임 개발의 경우, 클라이언트는 오랫 동안 개발자, 디자이너 및 설계자가 인식하여 설명해 왔습니다.

지속적 대화 상태

이 경우 우선 해당 상황을 막는 것이 가장 쉬운 방법입니다. 즉, 가능한 경우 서비스와 해당 이용자 간의 대화에서 디자인에 상태 관리가 필요한 경우 다른 접근 방식을 사용할 수 있는지 결정하는 것이 가장 효과적입니다. 사용할 수 없는 경우 모든 필수 상태 데이터를 서비스와 이용자 간에 전달하여 이 상태를 구체화합니다. 이 때 각 메시지가 전체 대화를 구성합니다. 이 접근 방식은 메시지 크기는 현저히 증가하지만 서비스 자체는 현재 전적으로 Stateless 상태임을 의미합니다. 다른 접근 방식은 각 메시지 내부에 대화 ID를 포함하고 데이터베이스와 같은 영구 저장 영역에 모든 대화 상태를 보존하는 것입니다. 이 방법은 서버측의 성능에 중대한 영향을 미치지만, 보다 짧은 메시지로 저장된 네트워크 및 클라이언트 성능에는 도움이 될 수 있습니다.

이러한 서비스를 Stateless 상태로 유지하는 기본 목적 중 하나는 로드 밸런싱 기법을 사용하여 클라이언트를 분배하는 요청을 서비스할 수 있는 동일한 서비스 세트를 제공하기 위해서입니다. 이 로드 밸런싱은 모든 상태가 완전히 구체화되거나 공통 스토어에서 지속되는 경우 가능합니다.

Stateful 자원 관리

이 경우 기본적으로 명시적인 상태를 갖는 자원 관리를 참조합니다. 실제로 해당 상태는 자원의 중요 측면입니다. 상태 머신을 사용하여 위에서 설명한 자원, 고객 주문 또는 네트워크 스위치의 상태를 설명할 수 있습니다. 이 때 올바른 상태뿐만 아니라 서비스에서 제공하는 오퍼레이션이 기본 자원 상태에 영향을 주는 방식 또한 설명합니다.

이 설명을 수행하는 데 있어 이 상태가 자원의 본질적인 파트임을 나타내야 합니다. 그러나 이는 자원을 나타내는 정보 모델에 명확하게 표현되지 않을 수 있습니다. 또한 엔티티 세트를 관리하는 경우, 명시적인 ID 보유 여부에 관계 없이, 작업을 수행하는 개별 자원을 식별할 수 있어야 합니다.

서비스가 네트워크 스위치 또는 프로세스 제어 요소와 같은 실제 엔티티의 상태에 대한 액세스 또는 조회를 나타내는 경우 엔티티 상태 구체화를 고려할 수 없습니다. 값의 상태는 해당 값을 조회해야 알 수 있습니다. 현재 값 상태를 설명하는 메시지를 구성하고 응답하지만 영구적인 상황은 아닙니다. 값의 상태는 이 메시지를 전송하거나 처리하는 동안 변경될 수 있습니다.

웹 서비스 영역에는 WSRF(Web Services Resource Framework)라는 새로운 표준 세트가 있습니다. 이 표준은 특히 Stateful 자원 관리를 나타내는 서비스의 경우 Stateful 서비스의 패턴과 상태 인코딩에 대한 접근 방식을 설명합니다. 자세한 정보는 IBM WS-ResourceFramework 사이트를 참조하십시오.

Stateful 서비스 스펙

위에서 언급한 예제에는 해당 오퍼레이션에 대한 일부 논리 시퀀스를 갖는 서비스가 포함됩니다. 대부분의 서비스는 이 양식의 인터페이스를 제공합니다. 경우에 따라 Stateful 자원과도 관련이 있습니다(오퍼레이션 순서가 관리 대상 자원의 상태를 기반으로 하는 경우 제외). 이러한 경우 해당 순서는 대화 자체를 기반으로 합니다. 다음 예제는 연관된 프로토콜이 있는 서비스 스펙을 보여줍니다. 먼저 구조 스펙이 표시되며 다음으로 동작 스펙을 설명하는 상태 머신이 표시됩니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

구매 주문서는 {개설, 취소됨, 이행됨, 처리완료됨} 상태 중 하나를 나타내며 위의 스펙이 제공하는 오퍼레이션을 기반으로 상태를 변경합니다. 또한 개설 상태에 대한 자체 전이의 경우, 변경 알림을 송신하는 OrderChanged 오퍼레이션을 실행합니다.

다이어그램은 텍스트 컨텐츠에서 설명합니다.

모든 서비스가 단일 비즈니스 및 기술 범위에서 개발되는 대부분의 경우, 세부 동작 스펙은 개발되지 않거나 보다 비공식인 텍스트로 설명됩니다. 서비스가 해당 범위 밖(예를 들어, 파티션 간)에서 제공되는 경우, 파티션 간 상호작용의 논리 스펙을 나타내며 보다 세부적으로 개발되어야 합니다. 또한 세부 스펙을 통해, 서비스를 자주 재사용해야 하는 경우 이용자가 보다 효율적이고 효과적으로 재사용할 수 있습니다.