일련의 단계로 구성된 최종적으로 일관된 작업을 사용하는 경우 보상 트랜잭션 패턴이 유용할 수 있습니다. 특히 하나 이상의 단계가 실패하는 경우 보상 트랜잭션 패턴을 사용하여 단계가 수행한 작업을 실행 취소할 수 있습니다. 일반적으로 복잡한 비즈니스 프로세스 및 워크플로를 구현하는 클라우드 호스팅 애플리케이션에서 최종 일관성 모델을 따르는 작업을 찾습니다.
컨텍스트 및 문제점
클라우드에서 실행되는 애플리케이션은 데이터를 자주 수정합니다. 이 데이터는 때때로 서로 다른 지리적 위치에 있는 다양한 데이터 원본에 분산됩니다. 분산 환경에서 경합을 방지하고 성능을 향상시키려면 애플리케이션이 강력한 트랜잭션 일관성을 제공하려고 하면 안 됩니다. 대신 애플리케이션은 최종 일관성을 구현해야 합니다. 최종 일관성 모델에서 일반적인 비즈니스 작업은 일련의 개별 단계로 구성됩니다. 작업에서 이러한 단계를 수행하는 동안 시스템 상태의 전체 보기가 일치하지 않을 수 있습니다. 그러나 작업이 완료되고 모든 단계가 실행되면 시스템이 다시 일관성을 유지해야 합니다.
데이터 일관성 입문서에서는 분산 트랜잭션이 잘 확장되지 않는 이유에 대한 정보를 제공합니다. 이 리소스에는 최종 일관성 모델의 원칙도 나열됩니다.
최종 일관성 모델의 과제는 실패한 단계를 처리하는 방법입니다. 오류가 발생한 후 작업의 이전 단계가 완료된 모든 작업을 실행 취소해야 할 수 있습니다. 그러나 애플리케이션의 다른 동시 인스턴스가 변경되었을 수 있으므로 데이터를 항상 롤백할 수는 없습니다. 동시 인스턴스가 데이터를 변경하지 않은 경우에도 단계를 실행 취소하는 것이 원래 상태를 복원하는 것보다 더 복잡할 수 있습니다. 다양한 비즈니스별 규칙을 적용해야 할 수도 있습니다. 예를 들어 예제 섹션이 이 문서의 뒷부분 에서 설명하는 여행 웹 사이트를 참조하세요.
최종 일관성을 구현하는 작업이 여러 다른 유형의 데이터 저장소에 걸쳐 있는 경우 작업의 단계를 실행 취소하려면 각 데이터 저장소를 차례로 방문해야 합니다. 시스템이 일관성 없는 상태를 유지하지 않도록 하려면 모든 데이터 저장소에서 수행한 작업을 안정적으로 실행 취소해야 합니다.
최종 일관성을 구현하는 작업의 영향을 받는 데이터가 항상 데이터베이스에 보관되는 것은 아닙니다. 예를 들어 SOA(서비스 지향 아키텍처) 환경을 고려합니다. SOA 작업은 서비스에서 작업을 호출하고 해당 서비스에서 보유한 상태가 변경될 수 있습니다. 작업을 실행 취소하려면 이 상태 변경도 실행 취소해야 합니다. 이 프로세스에서 서비스가 다시 호출되고, 처음 작업의 결과를 되돌리는 다른 작업이 수행됩니다.
솔루션
해결 방법은 보상 트랜잭션을 구현하는 것입니다. 보상 트랜잭션의 단계는 원래 작업의 단계 효과를 실행 취소합니다. 직관적인 방법은 현재 상태를 작업 시작 시 시스템이 있던 상태로 바꾸는 것입니다. 그러나 보상 트랜잭션은 애플리케이션의 다른 동시 인스턴스가 변경한 내용을 덮어쓸 수 있으므로 항상 이러한 접근 방식을 사용할 수는 없습니다. 대신, 보상 트랜잭션은 동시 인스턴스가 수행하는 모든 작업을 고려하는 지능형 프로세스여야 합니다. 이 프로세스는 일반적으로 원래 작업이 수행하는 작업의 특성에 따라 애플리케이션에 따라 다릅니다.
일반적인 방법은 워크플로를 사용하여 보정이 필요한 최종적으로 일관된 작업을 구현하는 것입니다. 원래 작업이 진행됨에 따라 시스템은 단계가 수행하는 작업을 실행 취소하는 방법을 포함하여 각 단계에 대한 정보를 기록합니다. 작업이 어느 시점에서든 실패하면 워크플로는 완료된 단계를 통해 되감습니다. 각 단계에서 워크플로는 해당 단계를 되돌리는 작업을 수행합니다.
두 가지 중요한 점은 다음과 같습니다.
- 보상 트랜잭션은 원래 작업의 정확한 역순으로 작업을 실행 취소할 필요가 없습니다.
- 실행 취소 단계 중 일부를 병렬로 수행할 수 있습니다.
이 방법은 클레멘스 Vasters의 블로그에 설명된 Sagas 전략과 유사합니다.
보상 트랜잭션은 결국 일관된 작업 자체이므로 실패할 수도 있습니다. 시스템은 오류 발생 지점에서 보정 트랜잭션을 다시 시작하고 계속할 수 있어야 합니다. 실패한 단계를 반복해야 할 수 있으므로 보상 트랜잭션의 단계를 idempotent 명령으로 정의해야 합니다. 자세한 내용은 Jonathan Oliver 블로그에서 멱등성 패턴을 참조하세요.
경우에 따라 수동 개입이 실패한 단계에서 복구하는 유일한 방법일 수 있습니다. 이러한 경우 시스템은 경고를 발생시키며 실패 이유에 대한 가능한 많은 정보를 제공해야 합니다.
문제 및 고려 사항
이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.
최종 일관성을 구현하는 작업의 단계가 실패하는 경우를 확인하기가 쉽지 않을 수 있습니다. 단계가 즉시 실패하지 않을 수 있습니다. 대신 차단될 수 있습니다. 제한 시간 메커니즘을 구현해야 할 수도 있습니다.
보정 논리를 일반화하는 것은 쉽지 않습니다. 보정 트랜잭션은 애플리케이션마다 다릅니다. 실패한 작업에서 각 단계의 효과를 실행 취소할 수 있는 충분한 정보가 있는 애플리케이션에 의존합니다.
보상 트랜잭션이 항상 작동하는 것은 아닙니다. 보정 트랜잭션의 단계를 멱등원 명령으로 정의해야 합니다. 이 경우 보상 트랜잭션 자체가 실패하는 경우 단계를 반복할 수 있습니다.
단계를 처리하는 인프라는 다음 조건을 충족해야 합니다.
- 원래 작업 및 보상 트랜잭션에서 복원력이 있습니다.
- 실패한 단계를 보상하는 데 필요한 정보는 손실되지 않습니다.
- 보정 논리의 진행률을 안정적으로 모니터링합니다.
보상 트랜잭션이 원래 작업을 시작할 때 시스템 데이터를 해당 상태로 반드시 반환하지는 않습니다. 대신 트랜잭션은 작업이 실패하기 전에 성공적으로 완료된 작업을 보정합니다.
보상 트랜잭션의 단계 순서가 원래 작업의 단계와 정확히 반대되는 것은 아닙니다. 예를 들어 한 데이터 저장소는 다른 데이터 저장소보다 불일치에 더 민감할 수 있습니다. 이 저장소에 대한 변경 내용을 취소하는 보상 트랜잭션의 단계가 먼저 수행되어야 합니다.
특정 측정값은 전체 작업이 성공할 가능성을 높이는 데 도움이 될 수 있습니다. 특히 작업을 완료하는 데 필요한 각 리소스에 단기 시간 제한 기반 잠금을 배치할 수 있습니다. 이러한 리소스를 미리 가져올 수도 있습니다. 그런 다음 모든 리소스를 획득한 후에만 작업을 수행합니다. 잠금이 만료되기 전에 모든 작업을 완료합니다.
평소보다 더 관대한 재시도 논리는 보상 트랜잭션을 트리거하는 오류를 최소화하는 데 도움이 될 수 있습니다. 최종 일관성을 구현하는 작업의 단계가 실패하면 오류를 일시적인 예외로 처리하고 단계를 반복해 보세요. 작업을 중지하고 단계가 반복적으로 실패하거나 복구할 수 없는 경우에만 보상 트랜잭션을 시작합니다.
보상 트랜잭션을 구현할 때 최종 일관성을 구현할 때 직면하는 것과 동일한 많은 문제에 직면하게 됩니다. 자세한 내용은 데이터 일관성 입문서의 "최종 일관성 구현에 대한 고려 사항" 섹션 을 참조하세요.
이 패턴을 사용해야 하는 경우
실패할 경우 실행 취소해야 하는 작업에만 이 패턴을 사용합니다. 가능한 경우 보정 트랜잭션에 따른 복잡성을 피하도록 솔루션을 디자인합니다.
워크로드 디자인
설계자는 워크로드 디자인에서 보상 트랜잭션 패턴을 사용하여 Azure 잘 설계된 프레임워크 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:
| 핵심 요소 | 이 패턴으로 핵심 목표를 지원하는 방법 |
|---|---|
| 안정성 디자인 결정은 워크로드가 오작동에 대한 복원력을 갖도록 하고 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 하는 데 도움이 됩니다. | 보정 작업은 데이터 변경 내용을 직접 롤백하거나 트랜잭션 잠금을 끊거나 네이티브 시스템 동작을 실행하여 효과를 되돌리는 등의 프로세스를 사용하여 중요한 워크로드 경로의 오작동을 해결합니다. - RE:02 중요 흐름 - RE:09 재해 복구 |
디자인 결정과 마찬가지로 이 패턴을 통해 도입 가능한 다른 핵심 요소의 목표에 관한 절충을 고려합니다.
예시
고객은 여행 웹 사이트를 사용하여 여행 일정을 예약합니다. 단일 여정은 일련의 항공편과 호텔로 구성될 수 있습니다. 시애틀에서 런던으로 이동한 다음 파리로 여행하는 고객은 여정을 만들 때 다음 단계를 수행할 수 있습니다.
- 시애틀에서 런던으로 가는 F1 항공편의 좌석을 예약합니다.
- 런던에서 파리로 가는 F2 항공편의 좌석을 예약합니다.
- 파리에서 시애틀로 가는 F3 항공편의 좌석을 예약합니다.
- 런던의 호텔 H1에서 객실을 예약합니다.
- 파리의 호텔 H2에서 객실을 예약합니다.
각 단계는 별도의 작업이지만 이러한 단계는 결과적으로 일관된 작업을 구성합니다. 이러한 단계를 수행하는 것 외에도 시스템은 각 단계를 실행 취소하기 위한 카운터 작업도 기록해야 합니다. 이 정보는 고객이 여정을 취소하는 경우에 필요합니다. 카운터 작업을 수행하는 데 필요한 단계는 보상 트랜잭션으로 실행할 수 있습니다.
보상 트랜잭션의 단계는 원래 단계와 정반대일 수 있습니다. 또한 보상 트랜잭션의 각 단계의 논리는 비즈니스별 규칙을 고려해야 합니다. 예를 들어 항공편 예약을 취소해도 고객에게 완전한 환불을 받을 수 없습니다.
다음 그림에서는 여행 일정 예약을 위한 장기 실행 트랜잭션의 단계를 보여줍니다. 트랜잭션을 실행 취소하는 보정 트랜잭션 단계를 볼 수도 있습니다.
참고 항목
각 단계에 대한 보상 논리를 디자인하는 방법에 따라 보상 트랜잭션의 단계를 병렬로 수행할 수 있습니다.
많은 비즈니스 솔루션에서 단일 단계가 실패한다고 해서 반드시 보정 트랜잭션을 사용하여 시스템을 롤백해야 하는 것은 아닙니다. 예를 들어 여행 웹 사이트 시나리오를 고려해 보세요. 고객이 F1, F2 및 F3 항공편을 예약하지만 호텔 H1에서 객실을 예약할 수 없다고 가정합니다. 항공편을 취소하는 대신 동일한 도시에 있는 다른 호텔의 객실을 고객에게 제공하는 것이 좋습니다. 고객은 여전히 취소를 결정할 수 있습니다. 이 경우 보상 트랜잭션이 실행되고 항공편 F1, F2 및 F3 예약이 취소됩니다. 그러나 고객은 시스템이 아닌 이 결정을 내려야 합니다.
다음 단계
- Data Consistency Primer(데이터 일관성 입문서). 보상 트랜잭션 패턴은 최종 일관성 모델을 구현하는 작업을 실행 취소하는 데 자주 사용됩니다. 이 입문서에서는 최종 일관성의 이점과 장단점에 대한 정보를 제공합니다.
- Idempotency 패턴입니다. 보상 트랜잭션에서는 idempotent 명령을 사용하는 것이 가장 좋습니다. 이 블로그 게시물에서는 idempotency를 구현할 때 고려해야 할 요인에 대해 설명합니다.
관련 참고 자료
- Scheduler 에이전트 감독자 패턴입니다. 이 문서에서는 분산 서비스 및 리소스를 사용하는 비즈니스 작업을 수행하는 복원력 있는 시스템을 구현하는 방법을 설명합니다. 이러한 시스템에서는 경우에 따라 보상 트랜잭션을 사용하여 작업이 수행하는 작업을 실행 취소해야 합니다.
- 재시도 패턴. 트랜잭션 보상은 계산적으로 까다로울 수 있습니다. 다시 시도 패턴을 사용하여 실패한 작업을 다시 시도하는 효과적인 정책을 구현하여 사용을 최소화할 수 있습니다.
- Saga 분산 트랜잭션 패턴입니다. 이 문서에서는 사가 패턴을 사용하여 분산 트랜잭션 시나리오의 마이크로 서비스에서 데이터 일관성을 관리하는 방법을 설명합니다. Saga 패턴은 보상 트랜잭션을 사용하여 오류 복구를 처리합니다.
- 파이프 및 필터 패턴입니다. 이 문서에서는 복잡한 처리 작업을 다시 사용할 수 있는 일련의 요소로 분해하는 데 사용할 수 있는 파이프 및 필터 패턴에 대해 설명합니다. 분산 트랜잭션을 구현하는 대신 보상 트랜잭션 패턴과 함께 파이프 및 필터 패턴을 사용할 수 있습니다.
- 자체 복구를 위한 디자인 . 이 가이드에서는 자체 복구 애플리케이션을 디자인하는 방법을 설명합니다. 자동 복구 방법의 일부로 보상 트랜잭션을 사용할 수 있습니다.