마이크로서비스 아키텍처 구축 : 6장 워크플로

6.1 데이터베이스 트랜잭션

• 모든 변경사항이 적용되거나 아니면 적용되지 않거나
  • ACID
    • 원자성, 일관성, 격리성, 내구성
  • NoSQL은 ACID 트랜잭션 제공 X
    • MongoDB는 단일 document에 대한 변경에 ACID 지원
• 마이크로서비스를 분리할 때 자기 데이터베이스에 대해 ACID 방식 사용
  • 데이터베이스가 여러 개라면 각 트랜잭션은 서로 독립적으로 작동
    • 모든 로직 직접 구현

6.2 분산 트랜잭션 - 2단계 커밋(Two-Phase Commit)

• 투표 단계, 커밋 단계로 나뉜다.

  • 투표 단계

    • 중앙 조정자는 트랜잭션에 참가할 모든 워커에 연락하고 일부 상태 변경이 가능한지 확인

      • 고객 상태 확인으로 변경하라는 요청

        • 모든 워커의 동의를 받으면 다음 단계

          • 변경할 수 있다고 알려준 직후에 즉시 변경 사항이 적용되지 않는다.
            • 어느 미래 시점에서 그 변경을 수행할 수 있음을 보장

              • 보장 이후 어느 시점에 보장한 내용이 유효하지 않게 된다면? 해당 레코드를 잠가야 할 가능성이 높다.

                • 분산 락

              • 트랜잭션을 진행하려고 투표를 했지만 나중에 커밋을 요청할 때 응답하지 않는 워커가 있다면?
                - 일부는 자동, 일부는 운영자가 수동으로 해결

                

        • 하나의 워커라도 요청받은 상태 변경이 일부 내부 조건을 위반해 변경을 수행할 수 없다고 하면 전체 연산 중단

          • 커밋에 찬성하지 않은 워커가 있는 경우 모든 당사자에게 롤백 메시지를 보내 로컬에서 정리하도록 보장

          • 모든 워커가 변경에 동의한 경우 커밋 → 잠금 해제

            • 두 커밋이 정확히 동시에 발생할 것이라고 보장하는 것은 불가능

              

              • ACID의 격리성은 2PC에는 이 보장이 사라진다.

      • 등록보류 테이블에서 행을 제거하라는 요청

• 문제 상황

  • 잠금 범위가 크거나 트랜잭션 지속 시간이 긴 경우 시스템에 엄청난 지연시간 주입
  • 일반적으로 수명이 짧은 작업에만 사용

6.3 분산 트랜잭션 - 그냥 안 된다고 하라

• 2PC 같은 분산 트랜잭션은 피하자.
• 그렇다면 대안은?
  • 데이터를 분리하지 않는 작업
    • 단일 데이터베이스에 남겨두고 해당 상태 관리

6.4 사가 패턴

• 2PC와 달리 여러 상태 변경을 조정할 수 있지만 자원을 잠금 필요가 없다.

• 관련된 단계를 독립적으로 실행할 수 있는 개별 활동으로 모델링

  • 비즈니스 프로세스를 명시적으로 모델링

• 예시

  

  • 주문 처리 프로세스는 하나의 사가로 표현
    • 각 흐름의 단계는 서로 다른 서비스에서 수행할 수 있는 작업
      • 각 서비스 내부의 모든 상태 변경은 로컬 ACID 트랜잭션 내에서 처리

• 사가 실패 모드

  • 역방향 복구
    • 실패 복구와 이후에 일어나는 정리 작업인 롤백 포함
    • 이전에 커밋된 트랜잭션을 취소하는 보상 조치 정의
  • 정방향 복구
    • 실패가 발생한 지점에서 데이터를 가져와 계속 처리
    • 트랜잭션 재시도
    • 기술적 실패가 아닌 비즈니스 실패로부터 복구할 수 있다는 점이 중요
      • 기술적 실패 : 결제 게이트웨이 time out
      • 비즈니스 실패 : 결제를 시도했지만 고객의 자금 부족

• 사가 롤백

  • 예시

    

    • 전체 주문을 되돌리는 경우

      • 보상 트랜잭션

        • 각 단계 롤백

          

        • 트랜잭션이 발생한 이후에 롤백

  • 롤백을 줄이는 워크플로의 단계 재정렬

    • 예시 : 주문이 실제로 발송된 경우에만 포인트 부여

    • 실패할 가능성이 가장 높은 단계를 앞으로 당겨 early return

      

  • 역방향 실패 및 정방향 실패 상황의 혼합

    • 주문 - 물품 포장 - 택배 발송 (여기서 실패 시)
      • 전체 주문 롤백은 이상하다.
        • 배송 재시도 or 수작업

• 사가 패턴 구현

  • 오케스트레이션형 사가
    • 중앙집중식 조장과 추적에 의존
    • 중앙 조정자 → 오케스트레이터

      • 실행 순서 정의, 필요한 보상 조치 트리거

      • 명령과 제어 방식

        

        - 중앙 주문 처리기는 연산을 수행하는 데 어떤 서비스가 필요한지, 언제 해당 서비스를 호출해야 하는지 결정
        - 호출 실패 시 분기처리
        - `서비스 간 요청/응답 호출`을 많이 사용
        - 주문 처리기 내부에서 비즈니스 프로세스를 명시적으로 모델링하면 동작 방식 이해에 도움된다.
        - 단점
            - 높은 결합도
            - 서비스에 전달돼야 할 로직이 오케스트레이터에 흡수되기 시작할 수 있다.
        - 높은 결합도를 피하는 방법
            - 서로 다른 흐름에 대해 서로 다른 서비스가 오케스트레이터 역할을 수행하도록 한다.
- 코레오그래피형 사가
    - 느슨하게 결합된 모델을 선호해서 중앙 집중식 조정이 필요하진 않지만 사가의 진행을 추적하는 작업을 더 복잡하게 만들 수 있다.
    - 신뢰하지만 검증간 아키텍처
    
    ![](https://velog.velcdn.com/images/bjo6300/post/22f74a8c-e234-442e-819f-4de2e737e4eb/image.png)


    
    - `이벤트 기반`
    - 이벤트를 발행하면 이벤트를 수신하고 적절히 동작
    - 병렬 처리를 용이하게 만든다.
    - 모든 서비스는 상대 서비스에 대해 전혀 모른다.
        - 자신이 할 일만 파악
    - 그러나 어떤 일이 일어나는지 파악하기 어렵다.
        - 각 서비스의 동작을 분리해서 살펴보고 머릿속에서 재구성
        - 각 사가가 어떤 상태에 있는지 파악할 방법이 부족해서 보상 조치를 취할 기회를 놓칠 수 있다.
    - 해결 방법 : `발행된 이벤트를 사용해 사가의 상태에 대한 뷰를 투영`
        - `사가에 대한 고유 ID`
- 혼합 방식
    - 혼합해 사용하는 모델
    - 여러 방식이 혼합된 단일 사가

• 사가 방식을 사용하는 기준
  • 사가의 진행 상황을 추적하는 복잡성 > 느슨하게 결합된 아키텍처를 통해 얻을 수 있는 이점
  • 한 팀이 전체 사가의 구현을 담당할 경우 오케스트레이션형 사가가 편하다.
  • 여러 팀이 관려하는 경우 코레오그래피형 사가 선호
    • 사가 구현에 대한 책임을 각 팀에 분배하기가 더 쉽고 독립적인 작업 가능