🔧 확장성을 고려한 서비스 분리 및 트랜잭션 관리 전략

개요

---

트랜잭션 범위를 효율적으로 관리하고, 서비스 확장 시 고려해야 할 서비스 분리 전략 및 트랜잭션 관리 전략을 분석합니다.
이를 통해 확장성과 유지보수성을 향상시키는 해결 방안을 조사합니다.

주요 내용

• 서비스 간 결합도 완화: 서비스의 독립성을 높여 확장성과 유지보수성을 개선합니다.
• 트랜잭션 관리 전략: 분산 시스템에서 발생할 수 있는 트랜잭션 문제를 해결하기 위한 방법을 조사합니다.

비즈니스 로직과 트랜잭션의 범위

무분별한 비즈니스 로직과 트랜잭션의 규모 또한 우리가 예측하지 못한 문제를 발생시킬 수 있습니다.

문제점

• 트랜잭션 범위가 과도하게 넓은 경우
  • 단일 트랜잭션에서 너무 많은 작업을 처리하면 데드락 및 성능 저하 발생 가능성이 높아집니다.
  • 롤백 시, 불필요하게 많은 리소스가 영향을 받습니다.
• 트랜잭션 내 DB와 무관한 작업 수행
  • 파일 입출력, 외부 API 호출 등 트랜잭션 외부에서 처리해야 할 작업이 포함될 경우 성능 저하와 롤백 불가 문제가 발생합니다.

해결 방안

• 비즈니스 로직과 트랜잭션 범위 분리: 트랜잭션 내에서 최소한의 작업만 처리하고, 나머지 작업은 비동기 처리 또는 이벤트 기반 처리로 분리합니다.

애플리케이션 이벤트를 통한 관심사 분리

ApplicationEventPublisher와 EventListener

• ApplicationEventPublisher: 애플리케이션 내 이벤트를 발행하여 서비스 간 결합도를 낮춥니다.
• EventListener / TransactionalEventListener: 특정 이벤트가 발생했을 때 비동기 방식 또는 트랜잭션 경계 내에서 이벤트를 처리할 수 있도록 합니다.
• @TransactionalEventListener와 @Async를 함께 사용하는 경우, 트랜잭션 종료 후 비동기로 이벤트를 처리할 수 있어 성능과 응답 속도를 개선할 수 있습니다.

설계 방향

1. 이벤트 발행: ApplicationEventPublisher를 사용하여 비즈니스 로직에 이벤트를 발행합니다.
2. 이벤트 리스너 설정: 이벤트를 구독하여 부가 기능을 작성합니다.
3. 오류 및 재시도 처리: 비동기 작업에서 예외가 발생할 경우 이를 로깅하거나, 재시도 로직을 추가해야합니다.

분산 트랜잭션 관리 패턴을 통한 관심사 분리

Saga 패턴

• 분산 트랜잭션 환경에서 트랜잭션의 일관성을 유지하기 위한 패턴.
• 각 서비스가 로컬 트랜잭션을 처리한 후 이벤트를 발행하여 다음 작업을 이어나갑니다.

Choreography(크레오그래피) 패턴

• 이벤트 기반으로 트랜잭션 흐름을 조율. 각 서비스가 자체 이벤트를 처리하여 트랜잭션 실행.
  • 각 서비스는 자신의 로컬 트랜잭션을 실행하고, 작업 완료 후 이벤트를 발행.
  • 다른 서비스는 해당 이벤트를 구독하여 자신의 작업을 실행.

설계 방향

1. 서비스 분리 및 이벤트 발행
2. 이벤트 흐름 정의
   PaymentService는 PaymentStartedEvent를 발행합니다.
   PointService는 PaymentProcessedEvent를 구독하여 포인트 차감 후 PointsSubtractedEvent를 발행합니다.
   SeatService는 PointsSubtractedEvent를 구독하여 좌석 예약 후 SeatsReservedEvent를 발행합니다.
   PaymentHistoryService는 SeatsReservedEvent를 구독하여 결제 이력을 생성합니다.
3. 보상 트랜잭션: 실패한 단계가 발생할 경우 해당 단계에서 보상 트랜잭션을 발행합니다. 포인트 차감에 실패하면 이전 단계의 작업을 보상하는 이벤트를 발행합니다.

장점 및 고려사항

• 장점: Orchestrator가 없어 서비스 간 결합도가 낮아지고, 각 서비스는 자신의 책임만 처리합니다.
• 고려사항: 이벤트 순서 및 복구 로직이 잘 설계되어야 합니다.

Orchestration(오케스트레이션) 패턴

• 중앙 조정자가 트랜잭션 흐름을 제어하여 실행 순서를 결정.
• Saga 오케스트레이터는 단계를 인식하고 필요한 순서대로 실행합니다. T3 단계가 실패하면(결제 실패) 오케스트레이터는 보정 트랜잭션 C1과 C2를 실행하여 데이터를 초기 상태로 복원합니다.

설계 방향

1. Saga Orchestrator 설계: 각 단계의 이벤트를 수신하고 적절한 서비스 호출을 하여 작업을 관리하는 Orchestrator을 생성합니다.
2. 각 서비스 분리 및 이벤트 핸들링: 로컬 트랜잭션을 개별 서비스에서 처리하고 각각의 작업이 끝난 후 성공/실패 이벤트를 발행합니다.
3. 이벤트 정의: 이벤트 객체를 생성합니다.
4. 보상 트랜잭션 정의: 실패 시 보상 작업을 수행합니다. 포인트 차감에 실패하면 이미 차감된 포인트를 복구해야 합니다.
5. 메시지 브로커 또는 이벤트 발행: 메시지 브로커를 사용하거나 Spring의 ApplicationEventPublisher를 활용합니다.

장점 및 고려사항

• 장점
  • Orchestrator가 전체 프로세스를 중앙에서 관리하므로 흐름이 명확합니다.
  • 서비스 간 결합도를 줄이고 비즈니스 로직의 가독성을 향상시킵니다.
• 고려사항
  • Orchestrator가 단일 장애점이 될 수 있으므로 장애 대비 및 복구 전략이 필요합니다.
  • 메시지 지연이나 실패에 대비한 재시도 및 보상 메커니즘을 잘 설계해야합니다.

디자인 패턴 비교

분류	장점	단점
Orchestration	- 중앙에서 모든 트랜잭션 제어 가능	- 중앙 조정자가 시스템 병목이 될 수 있음
Choreography	- 트랜잭션 이벤트 기반. 서비스 간 독립성 높음	- 실패 시 이벤트 복구가 복잡함

참고

• 12가지 디자인 패턴으로 알아보는 클라우드 네이티브 마이크로서비스 아키텍처
• Saga 분산 트랜잭션 패턴
• Saga 오케스트레이션 패턴
• Saga 코레오그래피 패턴