오늘은 Kafka 조사 및 테스트를 진행하면서 학습한 rollback 정책에 대해 기록해보자.

📘 Rollback 정책

롤백 정책에는 크게 2가지가 있었다.

• Choreography SAGA rollback
• Orchestration SAGA rollback

📜 Choreography SAGA rollback

Choreography SAGA rollback 원리는 위와 같이 순차적으로 이벤트가 전달되면서 트랜잭션이 관리되는 방식이다.

만약 위와 같이 배송정보 생성 중 오류가 발생할 경우, 배송에서는 재고관리 서비스로
재고 복원 이벤트를 전달하게 되며, 재고 복원이 만료되면 결재서비스로 결재 취소 이벤트를 전달하여
결재가 취소되는 방식으로 관리된다.

이 트랜잭션 관리 로직은 이벤트를 따로 발행하는 방법으로 처리하는 것이다.
그에 따른 보상 로직도 작성하여 rollback 처리를 수행한다.

장점 : 구현 단순, 느슨한 결합
단점 : 테스트 및 디버깅 어려움, 서비스 간 순환 의존성 증가, 각 서비스는 항상 리슨 상태 유지, 트랜잭션 상태 알기 어려움 등등

📜 Orchestration SAGA rollback

Orchestration SAGA rollback 원리는 중앙 오케스트레이터가 별도로 존재하며
트랜잭션에 관여하는 모든 서비스는 이 오케스트레이터에 의해 점진적으로 트랜잭션을 수행 후 결과를 전달하며
만약 오류 발생으로 인한 rollback이 필요한 경우 보상 트랜잭션을 오케스트레이터에 요청하여 일관성을 유지시키는 방식이다.

장점 : 순환적 의존성 X, 서비스 복잡성 줄어듬, 관심사의 분리, 추적 가능
단점 : 오케스트레이터에 비즈니스 로직 포함되지 않도록 주의, 인프라 복잡성 증가

✏ 마무리

Choreography-based SAGA 패턴을 이용하여 rollback을 처리하는 방법이 제일 적합하다고 생각하여 제안했었다.