왜 SAGA 패턴이랑 2PC 기법을 쓸까?

https://azderica.github.io/01-architecture-msa/

[Architecture] MSA : SAGA 패턴이란 - Azderica

https://kadensungbincho.tistory.com/125

Two-Phase Commit이란? (2PC)

 

해당 게시글은 위 블로그를 참조하여, 작성 되었습니다.

---

기존의 Monolithic 환경에서는 DBMS가 기본적으로 제공해주는 트랜잭션을 통해서 commit이나 rollback을 통해 일관성있게 관리하였습니다. 하지만, Application과 DB가 분산처리되면서 단일 DBMS가 제공하는 기능으로는 처리할 수 없습니다.

 

Two-Phase-Commit 기법(2PC)

• 여러 노드들 상에서의 원자적 트랜잭션 커밋을 이루기 위한 알고리즘 기법입니다.
• 이 또한 분산 트랜잭션 내에서 모든 노드가 동일하게 커밋하거나, 실패처리하는 것을 보장합니다.

클러스터 시스템에서 싱글 노드와 같은 방식만으로 분산 트랜잭션을 지원하면 다음 문제가 발생 가능합니다.

• 일부 노드에서는 제약위반 발생을 감지하여, 커밋 실패가 발생하나 일부 노드에서는 성공적으로 커밋 됩니다.
• 커밋 요청이 네트워크 상에서 손실되고, 결국 타임아웃으로 커밋 실패가 발생하나 일부 노드에서는 성공적으로 커밋될 수 있습니다.

 

 

2PC는 일반적인 싱글 노드 트랜잭션에 존재하지 않는 Coordinator를 사용합니다.

2PC 트랜잭션은 애플리케이션이 여러 데이터베이스 노드들에 읽고 쓰면서 시작됩니다.

 

Coordinator는 phase1을 시작하며, 각 노드에 prepare 요청을 보내어 커밋할 수 있는지 질의합니다. Coordinator는 각 노드의 응답을 추적합니다.

• 모든 참여자가 Yes라고 응답을 하면, 코디네이터는 phase 2로 넘어가 commit 요청을 보내어 커밋이 수행되도록 합니다.
• 어느 하나라도 no를 응답하면, 코디네이터는 phase 2로 넘어가 모든 노드들에 abort 요청을 보냅니다.

 

2PC의 취약점

Coordinator가 다운되는 경우에는, 참여자가 Prepare 요청을 받고, Yes를 응답한 이후에 Coordinator가 다운된다면, 참여자는 혼자서 abort를 수행할 수 없습니다.

Coordinator로부터, 추가적인 도움 없이는 참여자가 커밋되었는지 abort 되었는지 알 수가 없습니다.

또한 이 방법은 하나의 서비스가 장애가 있는 경우나 각각의 서비스에 동시에 Rocking이 걸리게 되면 성능의 문제가 발생하기 때문에 비효율적입니다.

왜 SAGA 패턴이 필요한가?

위의 문제를 해결하기 위해서 SAGA 패턴이 등장했습니다.

SAGA 패턴이란 마이크로서비스들끼리 이벤트를 주고 받아 특정 마이크로서비스에서의 작업이 실패하면 이전까지의 작업이 완료된 마이크로서비스들에게 보상 이벤트를 소싱함으로써 분산 환경에서 원자성을 보장하는 패턴입니다.

 

SAGA 패턴의 핵심은 트랜잭션의 관리주체가 DBMS에 있는 것이 아닌 Application에 있습니다.

Application이 분산되어 있을때는 각 Application의 하위에 존재하는 DB는 local 트랜잭션만 담당합니다.

즉, 각각의 Application의 트랜잭션 요청의 실패로 인한 Rollback 처리(보상 트랜잭션)은 Application에서 구현합니다.

 

 

SAGA 패턴의 종류

Choreography based SAGA pattern

 

 

Choreography-based Saga 패턴은

보유한 서비스 내의 Local 트랜잭션을 관리하며 트랜잭션이 종료하게 되면 완료 Event를 발행합니다.

만약 그 다음 수행해야할 트랜잭션이 있으면 해당 트랜잭션을 수행해야하는 App으로 이벤트를 보내고, 해당 App은 완료 Event를 수신받고 다음 작업을 진행합니다.

이때 Event는 Kafka와 같은 메시지 큐를 통해서 비동기 방식으로 전달할 수 있습니다.

 

 

Choreography-base Saga 패턴에서는 각 App별로 트랜잭션을 관리하는 로직이 있습니다.

이를 통해서 중간에 트랜잭션이 실패하면 해당 트랜잭션 취소 처리를 실패한 App에서 보상 Event를 발행해서 Rollback 처리를 시도합니다.

 

Orchestration based SAGA pattern

 

Orchestration-Based Saga 패턴은 트랜잭션 처리를 위해 Saga 인스턴스(Manager)가 별도로 존재합니다.

트랜잭션에 관여하는 모든 App은 Manager에 의해 점진적으로 트랜잭션을 수행하며 결과를 Manager에게 전달하게 되고, 비지니스 로직상 마지막 트랜잭션이 끝나면 Manager를 종료해서 전체 트랜잭션 처리를 종료합니다. 만약 중간에 실패하게 되면 Manager에서 보상 트랜잭션을 발동하여 일관성을 유지합니다.