Saga 디자인 패턴은 분산 트랜잭션 시나리오에서 마이크로 서비스 간의 데이터 일관성을 관리하는 방법입니다. Saga는 각 서비스를 업데이트하고 메시지 또는 이벤트를 게시하여 다음 트랜잭션 단계를 트리거하는 일련의 트랜잭션입니다. 단계가 실패하면 Saga는 이전 트랜잭션을 상쇄하는 보상 트랜잭션을 실행합니다.
컨텍스트 및 문제점
트랜잭션은 논리 또는 작업의 단일 단위이며 때로는 여러 작업으로 구성됩니다. 트랜잭션 내에서 이벤트는 엔터티에 발생하는 상태 변경이며 명령은 작업을 수행하거나 이후 이벤트를 트리거하는 데 필요한 모든 정보를 캡슐화합니다.
트랜잭션은 ACID(원자성, 일관성, 격리성 및 내구성)여야 합니다. 단일 서비스 내의 트랜잭션은 ACID이지만 서비스 간 데이터 일관성에는 서비스 간 트랜잭션 관리 전략이 필요합니다.
다중 서비스 아키텍처에서
- 원자성은 모두 발생하거나 발생하지 않아야 하는 불가역적이고 돌이킬 수 없는 작업 세트입니다.
- 일관성은 트랜잭션이 유효한 상태의 데이터만 다른 유효한 상태로 가져온다는 것을 의미합니다.
- 격리는 동시 트랜잭션이 순차적으로 실행된 트랜잭션이 생성한 것과 동일한 데이터 상태를 생성할 수 있도록 보장합니다.
- 내구성을 통해 시스템 오류 또는 정전 시에도 커밋된 트랜잭션이 커밋된 상태로 유지됩니다.
마이크로 서비스당 데이터베이스 모델은 마이크로 서비스 아키텍처에 많은 이점을 제공합니다. 도메인 데이터를 캡슐화하면 각 서비스에서 최상의 데이터 저장소 형식 및 스키마를 사용하고, 필요에 따라 자체 데이터 저장소의 크기를 조정하고, 다른 서비스의 오류로부터 격리할 수 있습니다. 그러나 서비스별 데이터베이스 간에 데이터 일관성을 보장하는 데서 문제가 발생합니다.
2PC(2단계 커밋) 프로토콜과 같은 분산 트랜잭션은 트랜잭션의 모든 참가자가 트랜잭션을 계속 진행하기 전에 커밋하거나 롤백해야 합니다. 그러나 NoSQL 데이터베이스 및 메시지 조정과 같은 일부 참가자 구현은 이 모델을 지원하지 않습니다.
또 다른 분산 트랜잭션 제한 사항은 IPC(프로세스 간 통신) 동시성 및 가용성입니다. 운영 체제에서 제공하는 IPC를 사용하면 별도의 프로세스에서 데이터를 공유할 수 있습니다. 분산 트랜잭션이 커밋되려면 참여하는 모든 서비스를 사용할 수 있어야 하므로 전체 시스템 가용성이 감소할 수 있습니다. IPC 또는 트랜잭션 제한이 있는 아키텍처 구현에 Saga 패턴을 적용할 수 있습니다.
해결 방법
Saga 패턴은 일련의 로컬 트랜잭션을 사용하여 트랜잭션 관리를 제공합니다. 로컬 트랜잭션은 Saga 참가자가 수행하는 원자성 작업입니다. 각 로컬 트랜잭션은 데이터베이스를 업데이트하고 메시지 또는 이벤트를 게시하여 Saga에서 다음 로컬 트랜잭션을 트리거합니다. 로컬 트랜잭션이 실패하면 Saga는 이전 로컬 트랜잭션에 의해 변경된 내용을 실행 취소하는 일련의 보상 트랜잭션을 실행합니다.
Saga 패턴에서
- 보상 가능한 트랜잭션은 반대 효과를 가진 다른 트랜잭션을 처리하여 잠재적으로 되돌릴 수 있는 트랜잭션입니다.
- 피벗 트랜잭션은 Saga의 이동/이동 없음 지점입니다. 피벗 트랜잭션이 커밋되면 Saga가 완료될 때까지 실행됩니다. 피벗 트랜잭션은 Saga에서 보상 또는 다시 시도할 수 없는 트랜잭션이거나, 보상할 수 있는 마지막 트랜잭션이거나, 다시 시도할 수 있는 첫 번째 트랜잭션일 수 있습니다.
- 다시 시도 가능한 트랜잭션은 피벗 트랜잭션을 따르는 트랜잭션이며 성공이 보장됩니다.
연출과 오케스트레이션의 두 가지 일반적인 Saga 구현 방법이 있습니다. 방법마다 워크플로를 조정하기 위한 고유한 과제 및 기술 세트가 있습니다.
연출
연출은 참가자가 중앙 집중식 제어 지점 없이 이벤트를 교환하는 Saga를 조정하는 방법입니다. 각 로컬 트랜잭션은 연출을 사용하여 다른 서비스에서 로컬 트랜잭션을 트리거하는 도메인 이벤트를 게시합니다.
이점
- 참가자가 거의 없고 조정 논리가 필요하지 않은 간단한 워크플로에 적합합니다.
- 추가 서비스 구현 및 유지 관리가 필요하지 않습니다.
- 책임은 Saga 참가자에게 분산되므로 단일 실패 지점을 도입하지 않습니다.
단점
- 어떤 Saga 참가자가 어떤 명령을 수신 대기하는지 추적하기 어렵기 때문에 새 단계를 추가할 때 워크플로가 혼동될 수 있습니다.
- 서로의 명령을 소비해야 하기 때문에 Saga 참가자 간에 순환 종속성이 발생할 위험이 있습니다.
- 트랜잭션을 시뮬레이션하기 위해 모든 서비스를 실행해야 하므로 통합 테스트는 어렵습니다.
오케스트레이션
오케스트레이션은 중앙 집중식 컨트롤러가 Saga 참가자에게 실행할 로컬 트랜잭션을 알려주는 Saga 조정 방법입니다. Saga 오케스트레이터는 모든 트랜잭션을 처리하고 이벤트에 따라 수행할 작업을 참가자에게 알려줍니다. 오케스트레이터는 Saga 요청을 실행하고, 각 작업의 상태를 저장 및 해석하며, 보상 트랜잭션을 사용하여 오류 복구를 처리합니다.
이점
- 시간이 지남에 따라 많은 참가자가 관여하거나 새 참가자가 추가되는 포함된 복잡한 워크플로에 적합합니다.
- 프로세스의 모든 참가자를 제어하고 활동 흐름을 제어할 수 있는 경우에 적합합니다.
- 오케스트레이터는 일방적으로 Saga 참가자에 의존하기 때문에 순환 종속성을 도입하지 않습니다.
- Saga 참가자는 다른 참가자의 명령에 대해 알 필요가 없습니다. 문제의 명확한 분리는 비즈니스 논리를 간소화합니다.
단점
- 추가 디자인 복잡성을 위해서는 조정 논리를 구현해야 합니다.
- 오케스트레이터가 전체 워크플로를 관리하기 때문에 추가 실패 지점이 있습니다.
문제 및 고려 사항
Saga 패턴을 구현할 때는 다음 사항을 고려해야 합니다.
- Saga 패턴은 트랜잭션을 조정하고 여러 마이크로 서비스에 걸친 비즈니스 프로세스에 대한 데이터 일관성을 유지하는 방법에 대한 새로운 사고 방식이 필요하기 때문에 처음에는 어려울 수 있습니다.
- Saga 패턴은 특히 디버그하기 어렵고 참가자가 증가함에 따라 복잡성이 증가합니다.
- Saga 참가자가 로컬 데이터베이스에 변경 내용을 커밋하기 때문에 데이터를 롤백할 수 없습니다.
- 구현은 잠재적인 일시 오류 세트를 처리할 수 있어야 하며 부작용을 줄이고 데이터 일관성을 보장하기 위한 멱등성을 제공해야 합니다. 멱등성은 초기 결과를 변경하지 않고 동일한 작업을 여러 번 반복할 수 있음을 의미합니다. 자세한 내용은 메시지를 처리하고 상태를 함께 업데이트할 때 멱등성을 보장하는 방법에 대한 지침을 참조하세요.
- Saga 워크플로를 모니터링하고 추적하는 가시성을 구현하는 것이 가장 좋습니다.
- 참가자 데이터 격리가 부족하면 내구성 문제가 발생합니다. Saga 구현에는 변칙을 줄이기 위한 대책이 포함되어야 합니다.
적절한 조치 없이 다음과 같은 변칙이 발생할 수 있습니다.
- 업데이트 손실: 한 Saga가 다른 Saga의 변경 내용을 읽지 않고 쓸 때 발생합니다.
- 더티 읽기: 트랜잭션 또는 Saga는 아직 해당 업데이트를 완료하지 않은 Saga에 의해 만들어진 업데이트를 읽을 때 발생합니다.
- 퍼지/반복 불가 읽기: 읽기 간에 데이터 업데이트가 발생하므로 다른 Saga 단계가 다른 데이터를 읽을 때 발생합니다.
변칙을 줄이거나 방지하기 위한 제안된 대책은 다음과 같습니다.
- 의미 체계 잠금: Saga의 보상 가능한 트랜잭션이 세마포를 사용하여 업데이트가 진행 중임을 나타내는 애플리케이션 수준 잠금입니다.
- 통근 업데이트: 순서에 따라 실행되고 동일한 결과를 생성할 수 있습니다.
- 비관적 보기: 한 Saga는 작업을 롤백하기 위해 보상 가능한 트랜잭션을 실행하고 있는 동안 다른 Saga가 더티 데이터를 읽을 수 있습니다. 비관적 보기는 Saga를 다시 정렬하여 재시도 가능한 트랜잭션에서 기본 데이터가 업데이트되므로 더티 읽기의 가능성이 제거됩니다.
- 값 다시 읽기는 데이터가 변경되지 않았는지 확인한 다음, 레코드를 업데이트합니다. 레코드가 변경되면 단계가 중단되고 Saga가 다시 시작될 수 있습니다.
- 버전 파일은 레코드가 도착하는 동안 레코드에 대한 작업을 기록한 다음, 올바른 순서로 실행합니다.
- 값별로 각 요청의 비즈니스 위험을 사용하여 동시성 메커니즘을 동적으로 선택합니다. 위험 수준이 낮은 요청은 Saga를 선호하지만 위험 수준이 높은 요청은 분산 트랜잭션을 선호합니다.
이 패턴을 사용해야 하는 경우
다음을 수행해야 하는 경우 Saga 패턴을 사용합니다.
- 긴밀한 결합 없이 분산 시스템에서 데이터 일관성을 보장합니다.
- 시퀀스의 작업 중 하나가 실패하는 경우 롤백하거나 보상합니다.
Saga 패턴은 다음에 덜 적합합니다.
- 강력하게 결합된 트랜잭션.
- 이전 참가자에서 발생하는 보상 트랜잭션.
- 순환 종속성.
예제
Serverless의 오케스트레이션 기반 Saga는 성공 및 실패 워크플로로 송금 시나리오를 시뮬레이션하는 오케스트레이션 접근 방식을 사용하는 Saga 구현 참조입니다.
다음 단계
- 분선 데이터
- Richardson, Chris. 2018: 마이크로 서비스 패턴. 게시 만들기.
관련 참고 자료
이 패턴을 구현할 때 유용한 패턴은 다음과 같습니다.
- 연출에서는 시스템의 각 구성 요소가 중앙 제어 지점을 사용하는 대신 비즈니스 트랜잭션의 워크플로에 대한 의사 결정 프로세스에 참여하도록 합니다.
- 트랜잭션 보상은 일련의 단계에 의해 수행된 작업을 실행 취소하고 하나 이상의 단계가 실패할 경우 일관된 작업을 정의합니다. 복잡한 비즈니스 프로세스 및 워크플로를 구현하는 클라우드 호스팅 애플리케이션은 종종 이 최종 일관성 모델을 따릅니다.
- 다시 시도는 실패한 작업을 다시 시도하여 서비스 또는 네트워크 리소스에 연결하려 할 때 애플리케이션을 사용하여 일시적 오류를 처리합니다. 다시 시도는 애플리케이션의 안정성을 개선할 수 있습니다.
- 회로 차단기는 원격 서비스 또는 리소스에 연결할 때 복구하는 데 걸리는 시간이 유동적인 오류를 처리합니다. 회로 차단기는 애플리케이션의 안정성 및 복원력을 향상시킬 수 있습니다.
- 상태 엔드포인트 모니터링은 외부 도구가 노출된 엔드포인트를 통해 주기적으로 액세스할 수 있는 기능 검사를 애플리케이션 내부에 구현합니다. 상태 엔드포인트 모니터링 구현은 애플리케이션과 서비스가 올바르게 수행되고 있다는 것을 확인하는 데 도움을 줄 수 있습니다.