SeokRae / spring-transaction

트랜잭션 관련 내용 공유를 위한 레포
1 stars 0 forks source link

모노리스 아키텍처에서 사가 패턴과 보상 트랜잭션 #8

Open SeokRae opened 1 week ago

SeokRae commented 1 week ago

References

모노리스에서 사가 패턴을 사용하는 이유

모노리스에서는 일반적으로 ACID 트랜잭션을 활용하여 데이터 일관성을 유지하지만, 복잡한 비즈니스 로직이나 다양한 모듈 간의 상호작용이 있을 때, 사가 패턴과 보상 트랜잭션을 도입할 수 있습니다.

  1. 복잡한 도메인 로직 관리

    • 모노리스 시스템에서도 여러 도메인이 복잡하게 얽힌 상황에서는 사가 패턴이 유용합니다.
    • 예를 들어, 주문 생성, 결제, 배송 등 여러 모듈 간에 트랜잭션이 걸쳐 있는 경우, 단일 트랜잭션으로 모든 단계를 처리하기 어려울 수 있습니다.
    • 하나의 큰 트랜잭션으로 모든 단계를 관리할 경우, 트랜잭션 잠금 시간이나 성능 문제가 발생할 수 있습니다. 이럴 때 사가 패턴을 사용해 각 도메인을 독립적으로 처리하면서도, 실패 시 보상 트랜잭션을 통해 데이터를 복구하는 방식이 유리할 수 있습니다.
  2. 긴 트랜잭션 처리

    • 긴 트랜잭션이 필요한 경우,
    • 예를 들어 주문 생성부터 결제 완료까지의 모든 과정이 트랜잭션에 포함되면, 트랜잭션 범위를 넓히는 것은 성능에 부정적인 영향을 미칠 수 있습니다.
    • 이런 경우 사가 패턴을 사용해 각 도메인에서 처리하는 작업을 개별 트랜잭션으로 나누고, 전체 트랜잭션을 분할하여 관리하면 더 나은 성능과 확장성을 얻을 수 있습니다.
  3. 비즈니스 일관성 vs 데이터 일관성

    • 모노리스에서도 모든 작업을 하나의 데이터베이스 트랜잭션으로 처리하는 대신, 비즈니스 일관성에 중점을 두어 사가 패턴을 적용할 수 있습니다.
    • 즉, 각 도메인 작업이 완료된 후에 전체 비즈니스 프로세스가 성공적으로 끝날 수 있도록 하고, 실패 시 보상 트랜잭션을 통해 비즈니스 일관성을 유지합니다.

모노리스에서의 보상 트랜잭션

모노리스 시스템에서도 보상 트랜잭션을 사용해 데이터를 복원하는 방식은 여전히 적용 가능합니다.

예를 들어:

모노리스 시스템에서는 이런 보상 트랜잭션을 동일한 데이터베이스 내에서 처리하므로 분산 트랜잭션 관리보다는 상대적으로 쉬운 편입니다. 하지만 여전히 트랜잭션 실패나 예외 발생에 대비한 보상 로직이 필요할 수 있습니다.

모노리스에서 사가 패턴의 필요성

  1. 간단한 경우:
    • 모노리스 시스템이 비교적 간단하고, 단일 데이터베이스에서 모든 트랜잭션을 처리할 수 있다면, 일반적으로는 ACID 트랜잭션을 사용하는 것이 더 적합합니다. 사가 패턴을 굳이 도입할 필요는 없습니다.
  2. 복잡한 비즈니스 로직
    • 모노리스 시스템에서도 비즈니스 로직이 복잡하거나 여러 도메인 간에 트랜잭션이 얽혀 있어 데이터베이스 잠금이나 성능 문제가 발생할 가능성이 있다면, 사가 패턴을 고려할 수 있습니다.
  3. 비즈니스 프로세스 흐름이 중요한 경우
    • 비즈니스 프로세스의 각 단계가 별도의 독립적인 트랜잭션으로 처리되어야 하고, 실패 시 되돌리는 보상 트랜잭션이 중요하다면, 모노리스에서도 사가 패턴이 적절할 수 있습니다.

모노리스 vs 마이크로서비스에서의 차이

SeokRae commented 1 week ago

사가 패턴(Saga Pattern) 개요

사가 패턴(Saga Pattern)은 분산 시스템에서 데이터 일관성을 보장하기 위한 트랜잭션 관리 개념에서 나온 패턴입니다. 분산 시스템이나 마이크로서비스 아키텍처에서는 각 서비스가 독립적으로 트랜잭션을 처리하기 때문에, 한 번에 모든 서비스에서 하나의 트랜잭션을 처리하는 것이 어렵습니다. 이런 환경에서는 기존의 ACID 트랜잭션(원자성, 일관성, 격리성, 지속성)을 유지하는 것이 도전 과제가 됩니다.

사가 패턴은 이러한 분산 환경에서 데이터의 최종 일관성(Eventual Consistency)을 보장하기 위해 등장한 개념입니다. 즉, 긴 트랜잭션을 여러 개의 작은 트랜잭션으로 나누어 처리하며, 각 트랜잭션이 실패할 경우 보상 트랜잭션을 통해 실패 이전의 상태로 데이터를 복원하여 전체 시스템의 일관성을 유지합니다.

SeokRae commented 1 week ago

사가 패턴이 등장한 배경

  1. ACID 트랜잭션의 한계

전통적인 ACID 트랜잭션은 단일 데이터베이스 또는 단일 시스템에서 트랜잭션을 처리할 때 데이터의 일관성을 보장하지만, 분산 시스템이나 마이크로서비스 환경에서는 모든 시스템을 하나의 트랜잭션으로 묶기 어렵습니다. 분산된 시스템에서는 각 서비스가 서로 독립적이기 때문에 트랜잭션 처리가 복잡해지고, ACID 트랜잭션의 보장을 받기 어렵습니다.

  1. CAP 이론

분산 시스템에서 CAP 이론(Consistency, Availability, Partition Tolerance)에 따라 일관성(Consistency)을 완벽히 보장하면서도 가용성(Availability)파티션 내성(Partition Tolerance)을 모두 만족하기 어렵습니다. 즉, 네트워크가 분리되거나 장애가 발생했을 때 데이터 일관성을 유지하면서도 시스템이 계속 가용하게 동작하도록 하기 위해서는 최종 일관성(Eventual Consistency)을 사용하는 방식이 필요하게 됩니다.

  1. 최종 일관성(Eventual Consistency)

사가 패턴은 분산 시스템에서 즉시 일관성을 포기하고, 최종적으로 일관성을 보장하는 방식입니다. 즉, 시스템 내에서 여러 단계에 걸쳐 처리되는 트랜잭션이 완료된 후에 모든 시스템이 일관된 상태에 도달하도록 하는 것을 목표로 합니다.

  1. 작은 트랜잭션의 중요성

사가 패턴에서는 한 번에 하나의 트랜잭션만 수행되며, 이 작은 트랜잭션들이 순차적으로 실행됩니다. 중간에 실패가 발생하면, 앞서 실행된 트랜잭션들을 되돌리기 위해 보상 트랜잭션이 실행됩니다.

SeokRae commented 1 week ago

사가 패턴의 핵심 개념

  1. 작은 트랜잭션의 연속(Long-running Transactions (LRTs))

하나의 긴 트랜잭션을 여러 개의 작은 트랜잭션으로 나누고, 이를 순차적으로 실행하여 트랜잭션이 성공적으로 완료되도록 합니다.

  1. 보상 트랜잭션(Compensating Transaction)

각 단계에서 실패가 발생했을 경우, 앞서 성공한 트랜잭션을 취소하거나 되돌리는 작업을 수행합니다. 이를 보상 트랜잭션이라고 합니다.

  1. 최종 일관성(Eventual Consistency)

각 단계가 순차적으로 실행되며, 성공 또는 실패한 결과에 따라 전체 시스템이 최종적으로 일관된 상태에 도달하게 됩니다.

SeokRae commented 1 week ago

사가 패턴이 유용한 이유

SeokRae commented 1 week ago

정리

사가 패턴은 분산 시스템에서 트랜잭션을 관리하고 데이터 일관성을 유지하기 위한 패턴입니다. 이 패턴은 ACID 트랜잭션이 분산 환경에서는 적합하지 않다는 점에서 발전되었으며, 작은 트랜잭션들을 나누어 처리하고, 보상 트랜잭션을 통해 데이터를 복원하여 최종 일관성을 보장하는 것이 핵심입니다.