개요

BXCM(BX Cloud Framework) LRA 분산 트랜잭션(Coordinator)은 MSA(Micro Service Architecture) 에서 분산 트랜잭션을 효과적으로 처리하기 위한 기능을 제공한다. 이 기능은 다수의 마이크로 서비스간에 발생하는 트랜잭션을 조율하고 관리하여 일관성과 신뢰성있는 분산 환경을 제공한다

본 장에서는 BXCM LRA 분산 트랜잭션에 대한 개요와 아키텍처에 대해서 소개한다.

1. 분산 트랜잭션

분산 트랜잭션을 관리하는 방법에는 보통 두 가지(Two Phase Commit, Saga Pattern) 방법이 있다. 각 방법은 특정 환경이나 요구사항에 따라 선택되며, 각각의 특징과 장단점을 가지고 있다.

1.1. Two Phase Commit (2PC)

2PC는 분산 환경에서 트랜잭션 일관성을 보장하기 위한 프로토콜로서 WAS에서 제공 혹은 솔루션(예:Atomikos)의 Transaction Manager(Coordinator)를 통하여 노드 간에 원자성을 유지하면서 트랜잭션을 커밋하거나 롤백하는 방법으로, 데이터 일관성을 유지한다.

일반적으로 Two Phase Commit (2PC)은 Monolithic 어플리케이션에서 사용한다.

2pc
Figure 1. Two Phase Commit (2PC)

2PC는 다음과 같은 특징을 가지고 있다.

  • WAS에서 제공하는 Transaction Manager (Coordinator) 혹은 2PC 지원 솔루션 (Atomikos 등)을 이용하여 사용 가능.

  • DB Vendor에서 제공하는 XA DataSource 사용

  • 하나의 어플리케이션에서 내부적으로 DB가 분산되어 있을 때 사용. 즉, Monolithic 어플리케이션에서 사용함.

  • 일반적인 어플리케이션 시스템에서는 1개의 DB만을 사용하기 때문에 2PC를 사용하는 경우가 거의 없음.

  • XA는 성능상의 이슈가 있어, WAS에서는 Non-XA를 2PC(XA) 처럼 사용 할 수 있도록 아래와 같은 별도의 기능을 제공함

    • JEUS : Local XA

    • WebLogic : Emulate Two-Phase Commit

1.2. Saga Pattern

Saga Pattern은 마이크로서비스 아키텍처에서 분산 트랜잭션을 관리하기 위한 디자인 패턴으로 어플리케이션에서 긴 작업을 여러 트랜잭션으로 분할하여 각 트랜잭션 단위를 컨트롤하여 전체 작업의 일관성을 유지하는 방법을 말한다. 단, 구현 시에는 복잡성과 총 실행 시간에 대한 고려가 필요하다.

saga_pattern
Figure 2. Saga Pattern 예

Saga Pattern은 다음과 같은 특징을 가지고 있다.

  • 어플리케이션 내에서 트랜잭션을 관리하는 패턴으로, 분산된 데이터베이스 및 서비스 환경에서 유용하게 사용됨.

  • 특히 마이크로서비스 아키텍처(MSA) 환경에서 트랜잭션의 일관성을 유지하고자 할 때 유용함

  • 각 서비스는 자체적인 로컬 트랜잭션을 수행하고, 이후 다음 단계의 트랜잭션을 위해 외부 서비스 호출 또는 이벤트 발행을 수행함

  • 만일, 중간에 어떤 단계에서 실패가 발생하면, 해당 단계의 역으로 보상 트랜잭션을 수행하여 일관성을 유지해야함

    즉, Commit / Rollback 처리를 어플리케이션 단에서 구현해야 함

  • 서비스/보상(정상/에러) 로직에 대한 부분은 업무 개발자가 직접 구현하여 개발하여야 함.

  • Saga Pattern은 여러 단계로 이뤄지며, 각 단계의 완료를 기다려야 하기 때문에 실행 시간이 길어질 수 있는 문제가 있음.

Saga Pattern 설계 및 구현 시 데이터 관점에서의 고려가 필요하다.

예를 들어, 회원 추가 및 수정을 한다고 가정한다면, 2PC 환경에서는 SQL 수행 후 Commit / Rollback 수행 시 실질적으로 DB에 반영된다.

반면에, Saga Pattern에서는 각 마이크로 서비스 간의 트랜잭션이 독립적으로 진행되기 때문에, 각 마이크로 서비스가 종료될 때 Commit이 수행되어 해당 데이터가 DB에 반영된다. 그러나 다른 마이크로 서비스에서 에러가 발생하는 경우, 보상 트랜잭션을 실행하여 변경된 데이터에 대한 롤백 작업을 수행해야 한다.

다음은 위의 예에 대해서 간단하게 정리한 그림이다.

2pc_saga_ok
Figure 3. 2PC / Saga Pattern 정상처리
2pc_saga_error
Figure 4. 2PC / Saga Pattern 에러(보상)처리

2. Saga Pattern 개발 복잡성

마이크로 서비스 환경에서 Saga Pattern은 주로 비동기 혹은 Remote 호출로 업무 로직을 처리하며, 각 마이크로 서비스 간의 통신, 동기화, 보상 거래 등을 구현하는 것은 개발 복잡성을 증가시킨다.

이로 인해 Saga Orchestrator를 구현하는 등의 작업이 필요하며, 이를 위한 러닝 커브가 일반적인 업무 개발자에게는 존재한다.

따라서, 프로젝트에서 업무 개발자가 Saga Pattern을 적용하여 설계 및 개발하기가 쉽지 않다.

그에 따라 BXCM에서는 Saga Pattern 즉, 분산 트랜잭션을 좀 더 쉽게 개발자가 개발할 수 있도록 LRA(Long Running Action)를 채택하여 이를 좀더 쉽게 개발 할 수 있도록 지원하고 있다.

3. LRA(Long Running Action)

LRA는 Saga Pattern을 더욱 효과적으로 구현할 수 있게 도와주는 분산 트랜잭션 아키텍처이다. "Long Running Action"이란 이름에서 알 수 있듯이, LRA는 여러 단계에 걸쳐 수행되는 분산 트랜잭션의 장기 실행을 지원한다.

LRA는 또한 개발자가 복잡한 분산 트랜잭션을 각 단계에서의 성공 또는 실패에 대한 관리를 쉽게할 수 있도록 관련 기능을 제공하며, 분산 환경에서의 데이터 일관성을 보장하고, 트랜잭션의 일부 단계에서 문제가 발생하더라도 전체 트랜잭션을 안전하게 처리할 수 있도록 지원한다.

3.1. LRA의 특징

LRA는 다음과 같은 특징을 가지고 있다.

  • 쉬운 분산 트랜잭션 개발 : LRA는 개발자가 복잡한 분산 트랜잭션을 쉽게 개발할 수 있도록 하는 강력한 기능을 제공한다.

  • 트랜잭션의 각 단계의 상태를 저장/관리 : LRA는 분산 트랜잭션의 각 단계에서 발생하는 상태를 효과적으로 저장하고 관리한다. 이로써 각 단계의 성공, 실패, 또는 보류 상태를 추적할 수 있다.

  • 중앙(LRA Coordinator) 관리 : LRA는 트랜잭션의 주체인 LRA Coordinator에 의해 전반적으로 관리된다. Coordinator는 각각의 트랜잭션 단계를 조율하고 필요한 조치를 취하여 일관성을 유지한다.

  • 재처리 : 보상 트랜잭션 처리 시 에러가 발생하더라도, LRA Coordinator는 안정성을 보장하기 위해 반복 호출하여 트랜잭션이 완료될 수 있도록 한다.

3.2. LRA 아키텍처

다음은 LRA가 어떻게 처리되고 동작하는 지, 처리 흐름에 대해서 표현한 그림이다.

lra-coordinator
Figure 5. LRA 아키텍처

LRA 처리 흐름

  • 1) LRA Transaction으로 선언된 서비스는 수행 시작. 이 때 프레임워크에서는 LRA Coordinator에 LRA 시작과, Service A를 실행한다고 Service A에 대한 정보(정상, 에러 호출 URL)를 전달한다.

  • 2) Service A 에서 다른 Service B를 Remote로 호출 한다.

  • 3) Service B가 실행 되기 전 프레임워크에서는 Service B에 대한 정보(정상, 에러 호출 URL)를 전달한다.

  • 4) Service B가 정상 종료 혹은 에러 종료가 되면, 종료 정보를 LRA Coordinator에 전달한다.

  • 5) Service A가 정상 종료 혹은 에러 종료가 되면, 종료 정보를 LRA Coordinator에 전달한다.

  • 6) LRA Coordinator에서는 Service의 최종 수행 결과에 따라 LRA Coordinator에 저장되어 있는 정상, 에러 처리에 대한 보상 URL을 호출한다.

개발자 작성 로직

  • A) 보상 처리를 위한 데이터 복원 정보를 저장

    • 오류 시 복원을 위해 Before Data 저장

    • 데이터의 Lock 처리 (예 : 다른 거래에서 수행하지 못하도록 상태 값을 이용한 Lock 처리 수행)

  • B) 서비스가 최종 정상/에러 종료가 되었다면 LRA Coodinator에서 정상/에러에 대한 보상 URL을 호출하여 보상 처리 수행

  • C) 업무적인 Lock 처리를 한 경우에는 Lock 해제 수행

SWLab Bankware Global
  • 전체
  • BXM
  • BXCM
  • BXCP
  • BXI
제품 선택 시 더 정확한 매뉴얼 가이드를 제공해드립니다.

Copyright© Bankwareglobal All Rights Reserved.