> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/5-1.-msa.md).

# 5-1. MSA

MSA에 대하여

### SOA vs MSA 아키텍처 사상 비교

비즈니스 기능을 독립적인 단위로 분리하여 고가용성과 확장성을 확보하기 위한 아키텍처적 진화 과정과 그 사상적 차이점이다.

**SOA (Service Oriented Architecture)의 특징과 한계** SOA는 Monolithic 아키텍처와 동일한 개념이 절대 아니며, 오히려 한 단계 발전된 개념이다. 비즈니스 기능을 서비스 단위로 분리하고 서비스 간의 네트워크 통신을 통해 연동하는 구조를 취한다. 이때 통신의 중심 축으로 ESB(Enterprise Service Bus)를 활용하며, SOAP/XML 기반의 통신 프로토콜을 표준 체계로 채택한다. 

그러나 이 구조는 결과적으로 중앙의 거대한 Enterprise Service Bus 체계에 모든 서비스와 라우팅 제어권이 집중되므로, 트래픽 폭증 시 ESB 자체가 전체 시스템의 병목 구간이자 단일 장애점(SPOF, Single Point of Failure)으로 작용하는 치명적인 아키텍처적 한계를 지닌다.

**MSA (Microservices Architecture)의 혁신** SOA 패러다임에서 서비스를 훨씬 더 미세하게 세분화하여, 각 서비스가 완전히 별개로 독립적으로 운용되고 배포되는 고도의 분산 구조를 의미한다. 서비스 간 통신은 무거운 ESB 대신 가벼운 gRPC나 REST API 기반, 혹은 Kafka와 같은 가벼운 이벤트 스트림 레이어를 채택하여 수행하며, 각 서비스별로 완전히 독립적인 전용 데이터베이스(Database per Service)를 운용하는 것이 핵심이다. 

더불어 DevOps 체계(지속적 통합 및 배포, CI/CD) 및 도커/쿠버네티스 등 컨테이너 기반의 인프라 환경을 필수적으로 구성함으로써 시스템 전체의 수평적 확장성(Scalability)과 고가용성을 극대화한다.

### MSA 데이터 관리 전략 및 Polyglot Persistence

마이크로서비스 아키텍처에서는 서비스 및 도메인 영역마다 저장하고 관리하는 데이터의 성격과 비즈니스 목적이 완전히 상이하므로 데이터 저장소 역시 다원화되어야 한다.

**Polyglot Persistence (폴리글랏 퍼시스턴스)** 단일한 거대 RDBMS에 시스템의 모든 데이터를 획일적으로 밀어 넣던 방식에서 탈피하여, 각 도메인과 서비스의 비즈니스 특성에 가장 최적화된 최적의 저장소를 선택하여 유기적으로 조합하는(Choose Right Database) 아키텍처 전략이다. 예를 들어 데이터의 정합성과 트랜잭션 처리가 극도로 중요한 '주문' 도메인의 경우에는 ACID 특성을 완벽히 보장하는 RDBMS를 채택하여 운용한다. 반면, 데이터의 구조가 정형화되어 있지 않고 빈번한 동적 확장이 필요한 '상품' 도메인의 경우에는 유연한 스키마 확장이 가능한 NoSQL(MongoDB 등) 저장소를 매핑하여 다원화된 지속성을 달성한다.

### 분산 환경에서의 데이터 일관성 확보 전략 (SAGA 패턴)

각 마이크로서비스가 독립된 데이터베이스를 보유함에 따라, 전통적인 단일 데이터베이스 환경의 로컬 트랜잭션(ACID) 및 2단계 커밋(2PC) 방식을 통한 강한 원자성(Strong Consistency) 확보가 불가능해진다. 이에 따라 최종적 일관성(Eventual Consistency)을 달성하기 위한 분산 트랜잭션 관리 기법이 요구된다.

**SAGA Pattern (사가 패턴) 정의** 본래 SAGA 패턴은 시스템 내에서 오랜 기간 수행되는 장기 실행 트랜잭션(Long Lived Transaction)에 안정적으로 대응하기 위해 고안된 방법론이었다. 그러나 현대의 분산 환경 및 MSA 패러다임 하에서는 데이터베이스가 파편화된 긴 트랜잭션의 서사를 안전하게 제어하고 구성하는 핵심 개념으로 표준화되어 널리 활용되고 있다. 강한 원자성을 다소 희생하는 대신, 비즈니스 흐름에 따라 각 마이크로서비스의 로컬 트랜잭션을 순차적으로 진행하며 이벤트를 통해 서로를 유기적으로 연결한다. 만약 진행 도중 특정 서비스에서 예외나 실패가 발생할 경우, 이전 단계들에서 이미 커밋 완료된 데이터들을 트랜잭션 발생 전의 상태로 되돌리기 위해 역방향으로 취소 명령을 수행하는 보상 트랜잭션(Compensating Transaction) 메커니즘 및 멱등성 기반의 Retry, DLQ, Outbox 패턴 등의 철저한 예외 방어 전략을 필수적으로 수반한다.

**Choreography SAGA (코레오그래피 사가)** 분산 환경에서의 트랜잭션을 하나의 오케스트라에 비유할 때, 별도의 중앙 지휘자(Orchestrator)를 두지 않고 각 무용수들이 자율적인 안무에 맞춰 결합하는 형태로 본다. 각 마이크로서비스들이 개별적인 안무가처럼 주체적으로 구동되며, 자신이 맡은 로컬 트랜잭션을 완료한 후 이벤트를 발행하면 이를 구독하고 있던 다음 서비스가 이어서 자율적으로 트랜잭션을 수행하는 이벤트 구동(Event-Driven) 방식이다. 구조가 단순하고 서비스 간의 결합도가 낮아 빠른 구현이 가능하지만, 트랜잭션의 서사가 길어질 경우 현재 전체 비즈니스의 진행 상태를 한눈에 추적하기 어렵고 복잡한 보상 트랜잭션 발생 시 흐름 제어가 매우 난해해진다는 단점이 있다.

**Orchestration SAGA (오케스트레이션 사가)** Choreography 방식의 추적 난해성을 극복하기 위해, 트랜잭션의 전체 흐름과 서사를 중앙에서 완벽히 통제하고 관리하는 전용 '지휘자(Orchestrator)' 컴포넌트를 아키텍처 전면에 배치하는 방안이다. 

오케스트레이터가 각 마이크로서비스에게 어떤 로컬 트랜잭션을 실행해야 하는지 순차적으로 직접 명령을 하달하며, 서비스들로부터 처리 결과를 수신하여 다음 단계로 진행할지 혹은 실패 시 역방향 보상 트랜잭션을 일제히 트리거할지 여부를 중앙 집중식으로 결정한다. 비즈니스 워크플로우 상태를 직관적으로 모니터링하고 중앙에서 제어할 수 있어 복잡한 분산 트랜잭션 환경에 매우 적합하나, 지휘자 컴포넌트 자체가 비대해지거나 또 다른 단일 장애점(SPOF) 및 병목 구간으로 전락할 수 있으므로 설계 관점의 세밀한 관리가 요구된다.

### 메시지 발행 무결성을 위한 원자성 보장 전략 (Outbox & CDC)

마이크로서비스가 자신의 로컬 데이터베이스에 비즈니스 데이터를 저장하는 행위와, 타 서비스로 트랜잭션 전이를 알리기 위해 카프카 등의 메시지 큐로 이벤트를 발행하는 행위는 물리적으로 상이한 데이터소스를 사용하므로 두 작업의 완전한 원자성(Atomicity)을 보장해야만 데이터 유실 및 정합성 파괴를 막을 수 있다.

**Transactional Outbox (아웃박스 패턴)** 메시지 큐로 이벤트를 직접 즉시 발행할 때 발생할 수 있는 네트워크 유실 리스크를 차단하기 위해, 애플리케이션의 핵심 비즈니스 로직과 동일한 로컬 데이터베이스의 단일 트랜잭션 범위 내에 별도의 `OUTBOX` 테이블을 생성하여 활용하는 아키텍처 전략이다. 

비즈니스 엔티티 데이터를 저장할 때, 발행해야 할 이벤트 메시지 내용 역시 Outbox 테이블에 엔티티 상태로 함께 INSERT 처리하여 물리적인 원자성을 100% 확보한다. 로컬 DB 트랜잭션이 성공적으로 커밋되면, 별도로 구동되는 전용 메시지 릴레이 프로세스나 스케줄러가 Outbox 테이블에 쌓인 커밋 데이터를 순차적으로 읽어 메시지 큐(Kafka)로 유기적으로 전달함으로써 메시지 발행의 신뢰성을 완벽하게 담보한다.

**CDC (Change Data Capture, 체인지 데이터 캡처)** Outbox 테이블을 별도로 운용하고 관리하는 소프트웨어적 오버헤드를 완전히 소거하기 위해, 데이터베이스가 자체적으로 기록하는 로우 레벨의 변경 로그 파일(MySQL의 binlog 등)을 직접적으로 활용하는 고도화된 방식이다. 

데이터베이스에 INSERT, UPDATE, DELETE 등의 쓰기 연산이 발생하는 순간 데이터베이스 엔진 레벨의 변경 로그를 전문 수집기(Debezium 등)가 직접 실시간으로 pattern화하여 읽어내고 데이터 변경을 예리하게 감지한다. 변경 건이 탐지되는 즉시 애플리케이션 레이어를 거치지 않고 직접 카프카(Kafka) 등의 이벤트 스트림 공간으로 이벤트를 자동 발행하는 매커니즘을 취하므로, 애플리케이션 코드의 수정 없이도 초고속의 데이터 동기화와 발행 무결성을 완벽하게 동시 확보할 수 있는 강력한 MSA 인프라 전략이다.

### 분산 환경에서의 데이터 조회 아키텍처 설계 방안 (Aggregator & Polyglot)

각 마이크로서비스가 자신만의 독립적인 데이터베이스를 운용하는 데이터 격리 환경(Database per Service)에서는 단일 DB 환경처럼 단순한 SQL JOIN 문을 사용하여 여러 도메인의 데이터를 통합 조회하는 것이 구조적으로 불가능해진다. 이를 해결하고 조회 성능을 극대화하기 위한 아키텍처 패턴이다.

**API Aggregator (API 어그리게이터 패턴)** 분산된 서비스들로부터 데이터를 통합하여 클라이언트에게 제공하기 위한 가장 직관적이고 1차적인 조회 설계 방안이다. 클라이언트가 각각의 마이크로서비스를 개별적으로 호출하는 대신, 앞단에 전용 API Aggregator(또는 API Gateway) 컴포넌트를 배치한다. 클라이언트로부터 단일 조회 요청이 인입되면, 어그리게이터가 하부의 여러 마이크로서비스(예: 주문 서비스, 회원 서비스, 상품 서비스 등)를 네트워크를 통해 각각 호출하여 필요한 데이터 조각들을 퍼 올린다. 이후 메모리 상에서 이 데이터들을 유기적으로 결합하고 가공하여 클라이언트에게 최종 결과물로 반환하는 메커니즘을 취한다. 구현이 비교적 단순하다는 장점이 있으나, 호출해야 하는 하부 서비스가 많아질수록 네트워크 지연(Latency)이 중첩되어 전체 조회 속도가 느려질 수 있으며, 특정 서비스의 장애가 전체 조회 레이어의 병목으로 전이될 수 있으므로 비동기 논블로킹(Non-blocking) I/O 및 타임아웃 격리 전략이 필수적으로 수반되어야 한다.

**Polyglot 기반의 통합 조회 레이어 및 CQRS 설계** API Aggregator 패턴이 유발하는 실시간 네트워크 호출 병목과 데이터 가공 오버헤드를 근본적으로 타파하기 위해, 조회(Read) 전용의 독립된 데이터 저장소를 고유하게 다원화하여 구축하는 고도화된 폴리글랏(Polyglot) 전략이다. 명령(CUD)을 담당하는 저장소와 조회(R)를 담당하는 저장소를 철저히 분리하는 CQRS(Command Query Responsibility Segregation) 사상과 긴밀하게 맞물려 구동된다. 비즈니스 쓰기 연산은 각 서비스의 로컬 RDBMS 등에서 처리되지만, 쓰기가 발생할 때마다 변경 이벤트를 카프카(Kafka) 등의 메시지 큐로 즉시 발행한다. 조회 서비스는 이 이벤트를 컨슈밍하여 조회 연산 및 복잡한 검색, 대규모 정렬에 압도적인 성능을 발휘하는 NoSQL(MongoDB 등)이나 검색 엔진(Elasticsearch 등)에 데이터를 실시간으로 동기화 및 적재해 둔다. 결과적으로 클라이언트가 조회를 요청할 때 여러 서비스를 조인하거나 어그리게이트할 필요 없이, 이미 통합 가공되어 있는 폴리글랏 조회 전용 저장소에서 단 한 번의 인덱스 쿼리로 초고속 응답을 실현함으로써 분산 환경의 조회 성능 병목을 완벽하게 파괴한다.

### 분산 시스템에서의 설계방안, CAP 이론 (CAP Theorem)

네트워크를 통해 물리적으로 분리된 다수의 노드로 데이터베이스를 분산 및 복제하여 운용할 때, 시스템이 보장할 수 있는 역량의 한계와 설계 원칙을 규명한 핵심 이론이다. 분산 시스템은 일관성(Consistency), 가용성(Availability), 분산 지속성/네트워크 분할 허용성(Partition Tolerance)이라는 3가지 핵심 가치를 동시에 모두 완벽하게 만족시킬 수 없으며, 반드시 최대 2가지만 선택할 수 있다는 트레이드오프(Trade-off) 체계를 지닌다.

**Consistency (일관성)** 분산 클러스터 내의 어떠한 노드로 접근하여 데이터를 조회하더라도, 모든 클라이언트가 동시 시점에 완벽하게 일치하는 최신의 동일한 데이터를 바라볼 수 있도록 보장하는 특성이다. 즉, 특정 노드에 데이터 쓰기(Update)가 발생했다면 이 변경 사항이 클러스터 내의 모든 복제본 노드에 완벽하게 동기화가 완료될 때까지는 전 노드에서 이전 데이터가 조회되거나 조회가 차단되어야 하므로, 시스템의 동기식 무결성을 극대화하는 성격이다.

**Availability (가용성)** 분산 클러스터 내부의 특정 물리 노드에 심각한 장애가 발생하여 시스템이 다운되거나 정상 구동을 멈추더라도, 생존해 있는 다른 노드를 통해 클라이언트의 인입 요청에 대해 언제든지 에러 없이 정상적인 응답(Read/Write)을 완전히 제공할 수 있는 역량을 의미한다. 비록 일부 노드의 일관성이 깨져서 과거의 데이터를 반환할지언정, 시스템 전체가 서비스를 거부하지 않고 24시간 내내 지속적으로 응답성을 유지하는 고가용성의 척도가 된다.

**Partition Tolerance (분산 지속성 / 네트워크 분할 허용성)** 분산 환경에서 각 노드들을 상호 연결하는 물리 네트워크 망에 단선, 패킷 유실, 통신 순단 등의 사유로 노드 간 통신이 단절되는 '네트워크 분할(Partition)' 장애가 발생하더라도, 분산된 시스템 전체가 붕괴하지 않고 각자 분리된 영역 내에서 비즈니스를 정상적으로 지속하여 유지할 수 있는 내결함성 역량이다. 현대의 거대 분산 시스템 인프라 환경에서는 네트워크 장애가 상시 필연적으로 발생할 수밖에 없으므로, P(Partition Tolerance) 속성은 선택의 대상이 아닌 무조건적으로 기본 전제하여 확보해야 하는 아키텍처적 필수 자격 요건이다.

**네트워크 분할(P) 상황에서의 CP vs AP 현실적 선택 기준** 현대 분산 아키텍처 설계에서 네트워크 분할 장애(P)는 피할 수 없는 현실이므로, 실제 아키텍트가 직면하는 선택은 결국 일관성(C)과 가용성(A) 중 어느 가치를 비즈니스 우선순위로 삼을 것인가로 귀결된다.

* **CP 시스템 (일관성 + 분할 허용성 선택)**: 네트워크 분절로 인해 노드 간 데이터 동기화가 불가능해진 상황이라면 데이터의 무결성을 지키는 것이 절대 우위이다. 따라서 일관성을 사수하기 위해, 데이터 최신화가 단절된 장애 노드로 유입되는 클라이언트의 모든 조회 및 쓰기 요청을 의도적으로 거부하고 에러를 반환하는 방식을 취한다. 돈의 흐름과 잔액이 정확해야 하는 '금융/뱅킹' 시스템이나 '결제' 레이어에서는 일시적인 서비스 거부(가용성 저하)를 감수하더라도 반드시 CP 형태의 아키텍처를 강제해야 한다.
* **AP 시스템 (가용성 + 분할 허용성 선택)**: 네트워크 분절로 인해 복제 노드 간의 통신이 완벽히 차단되더라도, 시스템은 멈추지 않고 살아있는 노드를 통해 클라이언트에게 무조건 정상 응답을 제공하는 것이 서비스 관점에서 우위라고 판단하는 전략이다. 이 경우 노드 간 데이터가 일시적으로 불일치하여 사용자가 구버전 데이터를 보게 되는 현상이 발생하지만, 네트워크가 정상 복구되는 시점에 이벤트를 통해 사후 동기화를 수행하는 최종적 일관성(Eventual Consistency) 패러다임을 수용한다. 실시간성 정보 제공이 최우선인 '조회 전용 뷰', 'SNS 피드', '상품 추천 레이어' 등에서는 가용성을 극대화하기 위해 AP 형태의 아키텍처를 영리하게 채택하여 전체 가용성을 사수한다.