4.1 마이크로서비스 아키텍처에서의 트랜잭션 관리
단일 DB의 모놀리식 애플리케이션의 트랜잭션 관리는 어렵지 않다. 하지만 다중 DB, 다중 메시지 브로커를 사용하는 모놀리식 애플리케이션이나 자체 DB를 가진 여러 서비스로 구성된 마이크로서비스 아키텍처는 관리가 어렵다!
데이터 일관성 유지: 사가 패턴
- 사가: 마이크로서비스 아키텍처에서 분산 트랜잭션 없이 데이터 일관성 유지
- ACID 와 달리 (1) 격리성이 없고 (2) 로컬 트랜잭션마다 변경분을 거밋하므로 보상 트랜잭션을 걸어야 한다.
각 서비스 별로 로컬 트랜잭션이 각각 존재한다. 도중 하나가 에러 발생하면 변경분을 어떻게 롤백시킬 것 인가? -> 보상 트랜잭션
4.2 사가 편성
사가는 단계를 편성하는 로직으로 구성된다.
시스템 커맨드가 사가를 시작할 때 첫 번째 사가 참여자를 정해 로컬 트랜잭션 실행을 지시하고, 트랜잭션이 완료되면 그다음 사가 참여자를 호출하는 과정이 모든 단계가 실행될 때까지 반복된다.
- 코레오그래피: 의사 결정과 순서화를 사가 참여자에게 맡김, 사가 참여자는 주로 이벤트 교환 방식으로 통신
- 오케스트레이션: 사가 편성 로직을 사가 오케스트레이터에 중앙화, 사가 오케스트레이터는 사가 참여자에게 커맨드 메시지 보내서 수행할 작업 지시
코레오그래피 사가
중앙 편성자 없음, 사가 참여자가 서로 이벤트 구독
성공
실패
확실한 이벤트 기반 통신
두 가지 통신 이슈 고려해야 한다.
- 사가 참여자가 자신의 DB를 업데이트하고 DB트랜잭션의 일부로 이벤트를 발행하도록 해야 한다.
- 사가 참여자는 자신이 수신한 이벤트와 자신이 가진 데이터를 연관 지을 수 있어야 한다.
- 데이터를 매핑할 수 있도록 상관관계 ID가 포함된 이벤트를 발행해야 한다.
장점
- 단순, 느슨한 결함
단점
- 이해하기 어렵다, 순환 의존성, 단단히 결합될 위험성
오케스트레이션 사가
사가 참여자가 할 일을 알려주는 오케스트레이터 클래스를 정의한다.
사가 참여자가 작업을 마치고 응답 메시지를 오케스트레이터에 주면, 오케스트레이터는 응답 메시지를 처리한 후 다음 사가 단계를 어느 참여자가 수행할지 결정한다.
장점
- 의존관계 단순화, 낮은 결합도, 관심사 분리
단점
- 너무 많이 중앙화하면 똑똑한 오케스트레이터 하나가 깡통 서비스에 일일이 할 일을 지시하는 모양새
-> 가급적 오케스트레이션 방식 권장
4.3 비격리 문제 처리
사가의 한 트랜잭션이 커밋한 변경분을 다른 사가가 즉시 바라볼 수 있다는 문제 존재, 해당 문제는 아래 두 가지 문제가 발생할 수 있다.
- 한 사가가 실행 중에 접근하는 데이터를 도중에 다른 사가가 바꿔치기 가능
- 한 사가가 업데이트를 하기 이전 데이터를 다른 사가가 읽을 수 있어 데이터 일관성 깨질 수 있음
비정상 개요
- 소실된 업데이트: 한 사가의 변경분을 다른 사가가 미처 못 읽고 덮어씀
- 더티 읽기: 사가 업데이트를 하지 않은 변경분을 다른 사가가 읽음
- 퍼지/반복 불가능한 읽기: 한 사가의 상이한 두 단계가 같은 데이터를 읽어도 결과가 달라지는 현상, 다른 사가가 그 사이에 업데이트
비격리 대책
*_PENDING 상태도 이상 현상을 예방하는 전략 중 하나, 현재 주문을 사가로 업데이트 중이니 그에 맞게 행동하라고 다른 사가에게 알리는 것?!
사가의 구조
사가는 다음 세 가지 트랜잭션으로 구성된다.
- 보상 가능 트랜잭션: 보상 트랜잭션으로 롤백 가능
- 피봇 트랜잭션: 사가의 진행/중단 지점, 피봇 트랜잭션이 커밋되면 사가는 완료될 때까지 실행
- 재시도 가능 트랜잭션: 피봇 트랜잭션 직후의 트랜잭션
- 보상가능 트랜잭션: 보상 트랜잭션을 가지거나 읽기 전용이거나
- 피봇 트랜잭션: 소비자 신용카드가 승인되면 이 사가는 반드시 완료
- 재시도 가능 트랜잭션: 완료 보장
대책: 시맨틱 락
보상 가능 트랜잭션이 생성/수정하는 레코드에 무조건 플래그 세팅, 플래그를 통해 락을 걸어 놓는다.
대책: 교환적 업데이트
어떤 순서로도 실행 가능하게 설계
예시 뭔말이야 !
대책: 비관적 관점
더티 읽기(업뎃안했는데 다른 사가가 읽음)로 인한 비즈니스 리스크를 최소화하기 위해 사가 단계의 순서 재조정
대책: 값 다시 읽기
소실된 업데이트 방지, 레코드를 업데이트 하기 전에 값을 다시 읽어 변경되지 않았는지 확인
대책: 버전 파일
레코드에 수행한 작업을 하나하나 기록
예를 들어
- 주문 생성 -> 신용카드 승인 취소 -> 신용카드 승인
이런 경우가 있다고 친다면, 취소 요청을 기록해두고 승인 요청이 온다면 승인 작업을 생략하는 것을 인지할 수 있다.
대책: 값에 의한
애플리케이션 차원에서 각 요청의 속성을 보고 사가를 쓸지, 분산 트랜잭션을 쓸지 판단
--> 분산 트랜잭션 알아볼것 ..
