Distributed Architecture

Distributed Architecture

Distributed Architecture(분산 아키텍처) 는 시스템의 여러 구성 요소가 물리적으로 분리된 환경에서 네트워크를 통해 통신하며 하나의 논리적 시스템을 이루는 구조이다. 각 노드는 독립적으로 동작하면서도 전체 시스템의 일부로 협력하며, 장애 발생 시에도 서비스의 연속성과 확장성을 보장한다. 이 아키텍처는 마이크로서비스, 클라우드 네이티브, IoT(사물인터넷), 글로벌 서비스 등 다양한 현대 IT 서비스의 기반이 된다.

배경

분산 아키텍처의 등장 배경은 다음과 같다:

1. 모놀리식 아키텍처의 한계

   • 단일 장애점 (Single Point of Failure) 문제
   • 확장성 제약 (수직 확장의 한계)
   • 기술 스택 종속성
   • 배포와 업데이트의 복잡성

2. 클라우드 컴퓨팅의 발전

   • 분산 인프라의 활용 필요성 증대
   • 컨테이너 기술의 발전 (Docker, Kubernetes)
   • 서비스형 인프라 (IaaS, PaaS) 의 보편화

3. 비즈니스 요구사항 변화

   • 빠른 변화에 대한 대응력 필요
   • 글로벌 서비스 요구
   • 대용량 트래픽 처리 필요성

목적 및 필요성

분산 아키텍처의 주요 목적과 필요성은 다음과 같다:

1. 확장성 (Scalability)

   • 수평적 확장을 통한 처리 능력 증대
   • 필요에 따른 선택적 확장 가능

2. 가용성 (Availability)

   • 부분적 장애가 전체 시스템에 미치는 영향 최소화
   • 지리적 분산을 통한 서비스 연속성 확보

3. 유연성 (Flexibility)

   • 기술 스택의 다양성 허용
   • 독립적인 개발과 배포 가능

4. 성능 최적화

   • 지역별 최적화된 서비스 제공
   • 부하 분산을 통한 응답 시간 개선

핵심 개념

분산 아키텍처는 여러 독립적인 컴포넌트 (노드, 서버, 서비스 등) 가 네트워크를 통해 상호작용하며 하나의 시스템을 구성하는 구조이다. 각 컴포넌트는 물리적으로 분산되어 있으며, 서로 다른 위치에서 동작할 수 있다.

기본 개념

1. 분산 시스템 (Distributed System):
   네트워크로 연결된 여러 독립적인 컴포넌트가 하나의 시스템처럼 동작하는 구조로, 각 노드가 독립적으로 실행되며 메시지 전달을 통해 협력한다.

2. CAP 이론 (CAP Theorem):

   • 일관성 (Consistency): 모든 노드가 동시에 같은 데이터를 보는 상태
   • 가용성 (Availability): 모든 요청이 응답을 받는 상태
   • 분할 내성 (Partition Tolerance): 네트워크 분할에도 시스템이 계속 동작하는 능력

3. 마이크로서비스 아키텍처 (Microservices Architecture):
   애플리케이션을 독립적으로 배포 가능한 작은 서비스들의 집합으로 구성한다.

4. 서비스 간 통신 패턴

   • 동기 통신: HTTP/REST, gRPC
   • 비동기 통신: 메시지 큐, 이벤트 스트리밍

5. 분산 트랜잭션 관리

   • 사가 패턴 (Saga Pattern): 분산 환경에서의 트랜잭션 관리
   • 보상 트랜잭션 (Compensating Transaction): 실패 시 이전 상태로 롤백

실무 구현을 위한 연관성 분석

시스템 설계 측면:

• CAP 이론은 데이터베이스 선택과 아키텍처 설계 결정의 기준 제공
• 마이크로서비스는 팀 조직 구조와 개발 프로세스에 직접적 영향

운영 측면:

• 서비스 간 통신은 네트워크 지연시간과 장애 처리 전략 결정
• 분산 트랜잭션은 데이터 일관성과 시스템 복구 전략 수립

주요 기능 및 역할

분산 아키텍처의 주요 기능과 역할은 다음과 같다:

1. 서비스 분해 (Service Decomposition)

   • 비즈니스 도메인 기반 서비스 경계 설정
   • 독립적 생명주기 관리

2. 통신 관리 (Communication Management)

   • 서비스 간 메시지 전달 및 프로토콜 관리
   • API 게이트웨이를 통한 외부 인터페이스 제공

3. 데이터 관리 (Data Management)

   • 서비스별 독립적 데이터 저장소 운영
   • 분산 트랜잭션 및 데이터 일관성 관리

4. 장애 처리 (Fault Tolerance)

   • 서킷 브레이커 (Circuit Breaker) 패턴
   • 재시도 (Retry) 및 타임아웃 (Timeout) 관리

특징

분산 아키텍처의 핵심 특징은 다음과 같다:

1. 느슨한 결합 (Loose Coupling)

   • 서비스 간 독립성 보장
   • 변경이 다른 서비스에 미치는 영향 최소화

2. 높은 응집도 (High Cohesion)

   • 단일 책임 원칙 적용
   • 비즈니스 기능 중심의 서비스 설계

3. 자율성 (Autonomy)

   • 독립적 배포 및 확장
   • 팀별 기술 스택 선택 자유도

4. 탄력성 (Resilience)

   • 장애 격리 및 복구 능력
   • 우아한 성능 저하 (Graceful Degradation)

핵심 원칙

분산 아키텍처의 핵심 원칙들:

1. 단일 책임 원칙 (Single Responsibility Principle)

   • 각 서비스는 하나의 비즈니스 기능에 집중
   • 명확한 서비스 경계 설정

2. 인터페이스 분리 원칙 (Interface Segregation Principle)

   • 클라이언트별 최적화된 인터페이스 제공
   • 필요 이상의 의존성 방지

3. 의존성 역전 원칙 (Dependency Inversion Principle)

   • 추상화에 의존하여 구체적 구현에 대한 의존성 감소
   • API 계약을 통한 서비스 간 상호작용

4. 독립성 원칙 (Independence Principle)

   • 서비스별 독립적 생명주기 관리
   • 배포와 확장의 독립성 보장

구조 및 아키텍처

graph LR
  Client --> LB[Load Balancer / API Gateway]
  LB --> |REST/gRPC| ServiceA[Service A Node]
  LB --> |REST/gRPC| ServiceB[Service B Node]
  ServiceA --> MQ[Message Broker]
  MQ --> ServiceC[Service C Node]
  ServiceA --> DB1[Shard DB 1]
  ServiceB --> DB2[Shard DB 2]
  ServiceC --> Cache[Distributed Cache]
  DB1 & DB2 --> Replication[Replica Sets]

• Client: 외부 유저 또는 시스템 요청 생성
• Load Balancer / API Gateway: 요청 분산, 인증, 라우팅, 캐싱 등의 기능 수행
• Service Nodes (A, B, C): 기능별 독립 실행 단위 (마이크로서비스, API 등)
• Message Broker: 비동기 메시지 중개 역할 (Kafka, RabbitMQ 등)
• Database Shards: 데이터 파티셔닝 방식 적용
• Distributed Cache: 캐시 계층 (예: Redis Cluster)
• Replication: 복제본 구성으로 가용성과 복원력 강화

구성 요소 분류

➤ 필수 구성 요소: 노드, 통신 레이어, 분산 데이터 저장
➤ 선택 구성 요소: 메시징, 로드 밸런서, 복제 시스템, 모니터링 등은 요구에 따라 사용

작동 흐름 및 통신 방식

1. 클라이언트가 Load Balancer/API Gateway에 요청
2. 인증 및 라우팅 후 해당 서비스 노드로 전달
3. 서비스 노드 간 데이터 조회 및 작업 분배
   * 동기식 HTTP/gRPC 호출
   * 비동기 메시징 (Kafka 등)
4. 노드는 ** 데이터베이스 샤딩 (DB1, DB2 등)** 에 접근하여 읽기/쓰기 처리
5. 메시지 브로커는 작업 큐 또는 이벤트 전달 역할 수행
6. 분산 캐시로 빈번히 사용되는 데이터를 응답 속도 향상
7. 모든 흐름은 관찰성 (Tracing/Monitoring) 도구로 실시간 모니터링

아키텍처 예시

예시 1

graph TB
    subgraph "클라이언트 계층"
        C1[Web Client]
        C2[Mobile App]
        C3[API Consumer]
    end
    
    subgraph "API Gateway 계층"
        AG[API Gateway]
    end
    
    subgraph "서비스 계층"
        MS1[User Service]
        MS2[Order Service]
        MS3[Payment Service]
        MS4[Inventory Service]
    end
    
    subgraph "데이터 계층"
        DB1[(User DB)]
        DB2[(Order DB)]
        DB3[(Payment DB)]
        DB4[(Inventory DB)]
    end
    
    subgraph "메시징 계층"
        MB[Message Broker]
    end
    
    C1 --> AG
    C2 --> AG
    C3 --> AG
    
    AG --> MS1
    AG --> MS2
    AG --> MS3
    AG --> MS4
    
    MS1 --> DB1
    MS2 --> DB2
    MS3 --> DB3
    MS4 --> DB4
    
    MS1 -.-> MB
    MS2 -.-> MB
    MS3 -.-> MB
    MS4 -.-> MB

작동 원리 설명:

1. 요청 라우팅: API Gateway 가 클라이언트 요청을 적절한 마이크로서비스로 라우팅
2. 서비스 처리: 각 마이크로서비스가 독립적으로 비즈니스 로직 처리
3. 데이터 접근: 서비스별 전용 데이터베이스 사용 (Database per Service 패턴)
4. 비동기 통신: Message Broker 를 통한 서비스 간 이벤트 기반 통신

예시 2

graph TB
    subgraph "External Layer"
        CDN[Content Delivery Network]
        LB[Load Balancer]
    end
    
    subgraph "Gateway Layer"
        AG1[API Gateway 1]
        AG2[API Gateway 2]
    end
    
    subgraph "Service Mesh"
        subgraph "Business Services"
            US[User Service]
            OS[Order Service]
            PS[Payment Service]
            IS[Inventory Service]
        end
        
        subgraph "Platform Services"
            AS[Auth Service]
            NS[Notification Service]
            LS[Logging Service]
        end
    end
    
    subgraph "Data Layer"
        subgraph "Operational Data"
            UDB[(User DB)]
            ODB[(Order DB)]
            PDB[(Payment DB)]
            IDB[(Inventory DB)]
        end
        
        subgraph "Analytical Data"
            DW[(Data Warehouse)]
            CACHE[(Cache)]
        end
    end
    
    subgraph "Infrastructure"
        SR[Service Registry]
        CM[Config Management]
        MB[Message Broker]
        MO[Monitoring]
    end
    
    CDN --> LB
    LB --> AG1
    LB --> AG2
    
    AG1 --> US
    AG1 --> OS
    AG2 --> PS
    AG2 --> IS
    
    US --> AS
    OS --> NS
    PS --> LS
    
    US --> UDB
    OS --> ODB
    PS --> PDB
    IS --> IDB
    
    US -.-> SR
    OS -.-> SR
    PS -.-> SR
    IS -.-> SR
    
    US -.-> MB
    OS -.-> MB
    PS -.-> MB
    IS -.-> MB

이 아키텍처는 다음과 같은 특징을 가진다:

• 계층화된 구조: 각 계층이 명확한 책임을 가짐
• 서비스 메시: 마이크로서비스 간 통신과 관리
• 분산된 데이터: 각 서비스가 독립적 데이터 저장소 보유
• 플랫폼 서비스: 횡단 관심사를 처리하는 공통 서비스

구성요소

구현 기법

사가 패턴 (Saga Pattern)

사가 패턴 (Saga Pattern) 은 마이크로서비스 아키텍처에서 분산 트랜잭션을 처리하기 위한 대표적인 패턴이다. 특히, ACID 대신 BASE 원칙에 따라 장기 실행 트랜잭션 (Long-Running Transaction, LRT) 을 작은 로컬 트랜잭션으로 분해하여 **최종 일관성 (Eventual Consistency)**을 확보한다.

코레오그래피 Vs 오케스트레이션 비교

코레오그래피 (Choreography)

중앙 조정자 없이 각 마이크로서비스가 이벤트 기반으로 자율적으로 트랜잭션을 처리하고, 완료 후 이벤트를 발행하여 다음 서비스에 흐름을 위임하는 방식.

구성 방식:

특징:

동작 흐름:

sequenceDiagram
    participant OS as Order Service
    participant PS as Payment Service
    participant IS as Inventory Service
    participant ES as Event Store
    
    OS->>ES: Order Created Event
    ES->>PS: Trigger Payment
    PS->>ES: Payment Processed Event
    ES->>IS: Trigger Inventory Update
    IS->>ES: Inventory Updated Event
    ES->>OS: Order Completed Event

오케스트레이션 (Orchestration)

중앙 오케스트레이터 서비스가 전체 트랜잭션 흐름을 제어하며, 각 마이크로서비스에게 명령 (Command) 을 보내고 상태를 관리하는 방식.

구성 방식:

특징:

동작 흐름:

sequenceDiagram
    participant C as Client
    participant SO as Saga Orchestrator
    participant OS as Order Service
    participant PS as Payment Service
    participant IS as Inventory Service
    
    C->>SO: Create Order
    SO->>OS: Create Order
    OS->>SO: Order Created
    SO->>PS: Process Payment
    PS->>SO: Payment Processed
    SO->>IS: Update Inventory
    IS->>SO: Inventory Updated
    SO->>C: Order Completed

서킷 브레이커 패턴

서비스 안정성과 복원력 (Resilience) 이라는 목표를 가지고 있는 패턴으로, 외부 서비스나 시스템 호출에서 실패가 반복되면, 일시적으로 요청을 차단하여 시스템 리소스를 보호하고 장애 전파를 막는 보호 장치를 만든다.

목적:

• 장애 서비스로의 지속적인 호출 방지
• 전체 시스템의 연쇄 실패 (cascading failure) 차단
• 일정 시간 후 재시도하여 회복 가능성 탐색

핵심 구성 및 동작 흐름:

1
2

[CLOSED] → 실패율 초과 → [OPEN] → 타이머 만료 → [HALF-OPEN]
→ 성공 → [CLOSED], 실패 → [OPEN]

장점

단점 및 문제점

단점

문제점

도전 과제

분류 기준에 따른 종류 및 유형

실무 사용 예시

활용 사례

사례 1: Netflix 의 마이크로서비스 아키텍처

Netflix 는 분산 아키텍처의 대표적인 성공 사례로, 다음과 같은 시스템 구성을 가집니다:

시스템 구성:

graph TB
    subgraph "사용자 인터페이스"
        UI1[Web App]
        UI2[Mobile App]
        UI3[Smart TV App]
    end
    
    subgraph "API Gateway Layer"
        ZUL[Zuul Gateway]
    end
    
    subgraph "마이크로서비스"
        US[User Service]
        CS[Content Service]
        RS[Recommendation Service]
        PS[Playback Service]
        BS[Billing Service]
    end
    
    subgraph "데이터 저장소"
        CASS[(Cassandra)]
        ES[(Elasticsearch)]
        REDIS[(Redis)]
    end
    
    subgraph "메시징"
        KAFKA[Apache Kafka]
    end
    
    subgraph "모니터링"
        ATL[Atlas]
        TOUR[Tour]
    end
    
    UI1 --> ZUL
    UI2 --> ZUL
    UI3 --> ZUL
    
    ZUL --> US
    ZUL --> CS
    ZUL --> RS
    ZUL --> PS
    ZUL --> BS
    
    US --> CASS
    CS --> ES
    RS --> REDIS
    
    US -.-> KAFKA
    CS -.-> KAFKA
    RS -.-> KAFKA
    
    US -.-> ATL
    CS -.-> TOUR

Workflow 분석:

1. 사용자 요청 처리:

   • 클라이언트 앱에서 Zuul Gateway 를 통해 요청
   • Gateway 가 적절한 마이크로서비스로 라우팅

2. 콘텐츠 추천 프로세스:

   • User Service 에서 사용자 프로필 조회
   • Content Service 에서 이용 가능한 콘텐츠 확인
   • Recommendation Service 에서 개인화된 추천 생성

3. 실시간 이벤트 처리:

   • 사용자 행동 데이터를 Kafka 를 통해 실시간 수집
   • 추천 알고리즘과 콘텐츠 메타데이터 업데이트

분산 아키텍처 활용의 차이점:

• 분산 아키텍처 적용 전:
  • 모놀리식 DVD 배송 시스템
  • 단일 장애점으로 인한 서비스 중단 위험
  • 기능 추가 시 전체 시스템 배포 필요
• 분산 아키텍처 적용 후:
  • 1000+ 마이크로서비스로 구성
  • 일일 수억 건의 API 호출 처리
  • 99.99% 가용성 달성
  • 글로벌 확장과 지역별 최적화 가능

사례 1: 마이크로서비스 기반 글로벌 이커머스 플랫폼

시스템 구성: 사용자 인터페이스, API Gateway(게이트웨이), 여러 마이크로서비스 (주문, 결제, 배송 등), 메시지 브로커, 분산 데이터베이스, 모니터링 시스템

1
2
3
4
5
6
7
8
9

[사용자]
   |
[API Gateway]
   |
[주문 서비스] -- [메시지 브로커] -- [결제 서비스] -- [배송 서비스]
   |
[분산 데이터베이스]
   |
[모니터링/로깅 시스템]

워크플로우: 사용자가 주문 → API Gateway 가 요청 분배 → 주문/결제/배송 서비스가 비동기 메시지로 처리 → 데이터는 분산 DB 에 저장 → 장애 발생 시 자동 복구 및 트래픽 우회

분산 아키텍처 적용 시: 장애 복원력, 글로벌 확장성, 서비스 독립성, 성능 극대화
미적용 시: 단일 장애점 (SPOF), 확장성 한계, 장애 시 전체 서비스 중단

구현 예시:

다음은 사가 패턴을 활용한 주문 처리 시스템의 구현 예시입니다:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240

# saga_orchestrator.py
import asyncio
import json
from enum import Enum
from typing import Dict, List, Optional
from dataclasses import dataclass

class SagaState(Enum):
    """사가 상태 정의"""
    STARTED = "started"
    ORDER_CREATED = "order_created"
    PAYMENT_PROCESSED = "payment_processed"
    INVENTORY_RESERVED = "inventory_reserved"
    COMPLETED = "completed"
    FAILED = "failed"
    COMPENSATING = "compensating"
    COMPENSATED = "compensated"

@dataclass
class SagaStep:
    """사가 단계 정의"""
    service_name: str
    action: str
    compensate_action: str
    payload: Dict

class SagaOrchestrator:
    """사가 오케스트레이터 - 분산 트랜잭션 조정"""
    
    def __init__(self):
        self.saga_logs: Dict[str, Dict] = {}  # 사가 로그 저장소
        self.service_clients = {
            'order': OrderServiceClient(),
            'payment': PaymentServiceClient(),
            'inventory': InventoryServiceClient()
        }
    
    async def execute_saga(self, saga_id: str, steps: List[SagaStep]) -> bool:
        """
        사가 실행 메인 로직
        - 각 단계를 순차적으로 실행
        - 실패 시 보상 트랜잭션 수행
        """
        # 사가 로그 초기화
        self.saga_logs[saga_id] = {
            'state': SagaState.STARTED,
            'completed_steps': [],
            'current_step': 0,
            'steps': steps
        }
        
        try:
            # 각 단계 순차 실행
            for i, step in enumerate(steps):
                self.saga_logs[saga_id]['current_step'] = i
                
                print(f"사가 {saga_id}: {step.service_name}.{step.action} 실행 중…")
                
                # 서비스 호출
                client = self.service_clients[step.service_name]
                result = await client.execute_action(step.action, step.payload)
                
                if not result['success']:
                    # 실패 시 보상 트랜잭션 시작
                    print(f"사가 {saga_id}: {step.service_name}.{step.action} 실패")
                    await self._execute_compensation(saga_id)
                    return False
                
                # 성공한 단계 기록
                self.saga_logs[saga_id]['completed_steps'].append({
                    'step': step,
                    'result': result
                })
                
                print(f"사가 {saga_id}: {step.service_name}.{step.action} 성공")
            
            # 모든 단계 성공
            self.saga_logs[saga_id]['state'] = SagaState.COMPLETED
            print(f"사가 {saga_id}: 완료")
            return True
            
        except Exception as e:
            print(f"사가 {saga_id}: 예외 발생 - {str(e)}")
            await self._execute_compensation(saga_id)
            return False
    
    async def _execute_compensation(self, saga_id: str):
        """
        보상 트랜잭션 실행
        - 완료된 단계들을 역순으로 보상
        """
        self.saga_logs[saga_id]['state'] = SagaState.COMPENSATING
        completed_steps = self.saga_logs[saga_id]['completed_steps']
        
        # 역순으로 보상 실행
        for step_info in reversed(completed_steps):
            step = step_info['step']
            
            print(f"사가 {saga_id}: {step.service_name}.{step.compensate_action} 보상 실행 중…")
            
            try:
                client = self.service_clients[step.service_name]
                result = await client.execute_action(
                    step.compensate_action, 
                    step.payload
                )
                
                if result['success']:
                    print(f"사가 {saga_id}: {step.service_name}.{step.compensate_action} 보상 성공")
                else:
                    print(f"사가 {saga_id}: {step.service_name}.{step.compensate_action} 보상 실패")
                    
            except Exception as e:
                print(f"사가 {saga_id}: 보상 중 예외 발생 - {str(e)}")
        
        self.saga_logs[saga_id]['state'] = SagaState.COMPENSATED

class OrderServiceClient:
    """주문 서비스 클라이언트"""
    
    async def execute_action(self, action: str, payload: Dict) -> Dict:
        """주문 서비스 액션 실행"""
        if action == "create_order":
            # 주문 생성 로직 시뮬레이션
            order_id = f"order_{payload['user_id']}_{payload['product_id']}"
            print(f"  주문 생성: {order_id}")
            return {"success": True, "order_id": order_id}
            
        elif action == "cancel_order":
            # 주문 취소 로직 시뮬레이션
            print(f"  주문 취소: {payload.get('order_id', 'unknown')}")
            return {"success": True}
            
        return {"success": False, "error": "Unknown action"}

class PaymentServiceClient:
    """결제 서비스 클라이언트"""
    
    async def execute_action(self, action: str, payload: Dict) -> Dict:
        """결제 서비스 액션 실행"""
        if action == "process_payment":
            # 결제 처리 로직 시뮬레이션
            amount = payload.get('amount', 0)
            if amount > 1000:  # 고액 결제 실패 시뮬레이션
                return {"success": False, "error": "Payment failed"}
            
            payment_id = f"payment_{payload['user_id']}_{amount}"
            print(f"  결제 처리: {payment_id}, 금액: ${amount}")
            return {"success": True, "payment_id": payment_id}
            
        elif action == "refund_payment":
            # 환불 처리 로직 시뮬레이션
            print(f"  결제 환불: {payload.get('payment_id', 'unknown')}")
            return {"success": True}
            
        return {"success": False, "error": "Unknown action"}

class InventoryServiceClient:
    """재고 서비스 클라이언트"""
    
    async def execute_action(self, action: str, payload: Dict) -> Dict:
        """재고 서비스 액션 실행"""
        if action == "reserve_inventory":
            # 재고 예약 로직 시뮬레이션
            product_id = payload['product_id']
            quantity = payload.get('quantity', 1)
            
            # 재고 부족 시뮬레이션 (product_id가 'out_of_stock'인 경우)
            if product_id == 'out_of_stock':
                return {"success": False, "error": "Out of stock"}
            
            print(f"  재고 예약: 상품 {product_id}, 수량: {quantity}")
            return {"success": True, "reservation_id": f"res_{product_id}_{quantity}"}
            
        elif action == "release_inventory":
            # 재고 해제 로직 시뮬레이션
            print(f"  재고 해제: {payload.get('reservation_id', 'unknown')}")
            return {"success": True}
            
        return {"success": False, "error": "Unknown action"}

# 사용 예시
async def main():
    """분산 아키텍처 사가 패턴 사용 예시"""
    orchestrator = SagaOrchestrator()
    
    # 주문 처리 사가 정의
    order_saga_steps = [
        SagaStep(
            service_name='order',
            action='create_order',
            compensate_action='cancel_order',
            payload={'user_id': 'user_123', 'product_id': 'product_456'}
        ),
        SagaStep(
            service_name='payment',
            action='process_payment',
            compensate_action='refund_payment',
            payload={'user_id': 'user_123', 'amount': 500}
        ),
        SagaStep(
            service_name='inventory',
            action='reserve_inventory',
            compensate_action='release_inventory',
            payload={'product_id': 'product_456', 'quantity': 1}
        )
    ]
    
    print("=== 성공 케이스: 정상 주문 처리 ===")
    success = await orchestrator.execute_saga("saga_001", order_saga_steps)
    print(f"사가 결과: {'성공' if success else '실패'}\n")
    
    # 실패 케이스: 고액 결제 실패
    print("=== 실패 케이스: 고액 결제 실패 ===")
    fail_saga_steps = [
        SagaStep(
            service_name='order',
            action='create_order',
            compensate_action='cancel_order',
            payload={'user_id': 'user_456', 'product_id': 'product_789'}
        ),
        SagaStep(
            service_name='payment',
            action='process_payment',
            compensate_action='refund_payment',
            payload={'user_id': 'user_456', 'amount': 1500}  # 고액으로 실패 유발
        ),
        SagaStep(
            service_name='inventory',
            action='reserve_inventory',
            compensate_action='release_inventory',
            payload={'product_id': 'product_789', 'quantity': 1}
        )
    ]
    
    success = await orchestrator.execute_saga("saga_002", fail_saga_steps)
    print(f"사가 결과: {'성공' if success else '실패'}")

if __name__ == "__main__":
    asyncio.run(main())

이 구현 예시는 다음과 같은 분산 아키텍처의 핵심 개념을 보여준다:

1. 사가 오케스트레이션: 중앙 집중식 트랜잭션 관리
2. 서비스 간 통신: 독립적인 서비스 클라이언트를 통한 호출
3. 보상 트랜잭션: 실패 시 이전 상태로 복구
4. 상태 관리: 사가 진행 상황과 로그 추적

실무에서 효과적으로 적용하기 위한 고려사항

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 주목할 내용

반드시 학습해야할 내용

용어 정리

참고 및 출처

• Microservices Pattern: Microservice Architecture pattern
• What Is the CAP Theorem? | IBM
• Saga Design Pattern - Azure Architecture Center
• What is CAP theorem? - IBM Cloud Docs
• Understanding the Saga Design Pattern (With a Real-World Example)
• Saga Pattern for Distributed Transactions