요즘은 뜸해졌지만 한동안 교육생들에게 MSA구조에 대해 많은 질문을 받은 적이 있다.

‘진정한 Micro Service Architecture’가 어떤것인가?

하나의 서비스에 각각 DB가 매칭이 되어야 할 것이다. 아래는 그 샘플 아키텍처이다. (from 「가상면접사례로 배우는 대규모 시스템 설계기초2」)

image-20250618231712863

각 서비스 별로 DB, 또는 DB + 캐시를 가지고 있다.

그런데 여기에서는 안나왔지만 이 시스템에서는 사용자 DB는 예약 DB에 같은 DB를 쓰고 있다. MSA의 원자적원칙이 깨진 부분인데 이 책에서는 이를 ‘하이브리드 MSA’ 라고 부른다. 나쁘지 않은 것 같다.

이 책에서 우려하는 것은 ‘완벽한’ MSA를 주장하는 사람이었다. 만일 사용자DB와 예약DB를 분리해야 한다고 하면, 다시말하면 정말 각각 DB로 써야 한다고 하면 데이터의 일관성이 깨지기 쉽다고 경고한다.

예약시 사용자의 트랜젝션과 예약 트랜젝션이 따로 일어나는데 사용자만 성공하고 예약 트랜젝션이 실패했다면 문제가 될 수 있지 않겠는가?

굳이 ‘순수한’ MSA로 운영하기 위해 이 책에서는 두 가지 방법을 제시한다.

  • 2단계 커밋(two-phase-commit; 2PC)
    • 여러노드의 원자적 트랜젝션의 실행을 보증하는 프로토콜
    • 하나의 노드에 실행이 중단되면 전체 실행을 막아버린다.
  • 사가(Saga)
    • 국지적으로 발행되는 트랜젝션을 하나로 묶은것
    • 트랜젝션하나가 성공하면 다음 트랜젝션 실행을 위한 트리거를 만들어 보냄.
    • 어느 한 트랜젝션 실패시 이전 트렌젝션의 결과를 전부 되돌리는 트랜젝션을 순차적으로 실행

결국 별도의 트랜젝션관리 도구를 통해 문제 발생시 대처하는 것이 방법인 셈이다. 여기에서는 사가(Saga)를 추천하고 있다.

MSA의 장점이 굳이 필요가 없다면… 하이브리드 방식도 좋을 것 같다.