마이크로서비스: 분해 기준과 통신

모놀리스:
- 1개 코드베이스, 1개 배포
- 트랜잭션 강력
- 시작 빠름
- 100명+ 팀 시 비효율

모듈러 모놀리스:
- 1개 배포 + 도메인 분리
- DB는 schema 분리 또는 공유
- 점진적 분해 가능

MSA:
- 다수 서비스 + 다수 배포
- 팀 자율성
- 운영 복잡 (대량의 도구·문화 필요)

시작:
- 모놀리스 (NoYAGNI)

분해 시그널:
- 팀 분리 (5+ 팀)
- 다른 배포 주기 필요
- 다른 기술 스택 필요
- 독립 확장 필요 (예: 검색만 트래픽 폭주)
- 한 부분의 장애가 전체 영향


→ 너무 일찍 분해 = 운영 지옥
→ 너무 늦게 분해 = 개발 속도 저하
→ 보통 50명+ 팀에서 검토

[DDD (Domain-Driven Design) 기반]

❌ 기능별 분해 (CRUD 단위)
- UserService, ProductService, OrderService
- 너무 작음 → 통신 폭주


✅ 비즈니스 도메인별
- Catalog Service (상품·검색)
- Order Service (주문·결제)
- Customer Service (사용자·인증)
- Fulfillment Service (배송)
- Notification Service (이메일·푸시)


[Inverse Conway Maneuver]
- 조직이 코드 구조 결정
- 팀 구조 ≈ 서비스 구조

[동기] REST/gRPC
- 요청-응답
- 결합 강함
- 카스케이딩 실패 위험

[비동기] 메시지 큐 (Kafka·SQS·RabbitMQ)
- 발행-구독
- 결합 느슨
- 최종 일관성


→ 요청 응답 필요: REST/gRPC
→ 이벤트 통지·비동기: 메시지 큐

// proto/order.proto
syntax = "proto3";

service OrderService {
  rpc GetOrder (GetOrderRequest) returns (Order);
  rpc CreateOrder (CreateOrderRequest) returns (Order);
  rpc ListOrders (ListOrdersRequest) returns (stream Order);
}

message Order {
  string id = 1;
  string user_id = 2;
  repeated OrderItem items = 3;
  double total = 4;
  string status = 5;
}

// 클라이언트 (Node.js)
import * as grpc from '@grpc/grpc-js';
import { OrderServiceClient } from './generated/order_grpc_pb';

const client = new OrderServiceClient(
  'order-service:50051',
  grpc.credentials.createInsecure()
);

const order = await new Promise((resolve, reject) => {
  client.getOrder({ id: '123' }, (err, res) => {
    err ? reject(err) : resolve(res);
  });
});

모든 외부 트래픽 → API Gateway → 내부 서비스


기능:
- 라우팅 (path 기반)
- 인증·권한 (JWT 검증)
- Rate limit
- 캐싱
- 로깅


도구:
- Kong (오픈소스)
- AWS API Gateway
- Tyk
- Nginx + custom


// 예: /api/orders/* → order-service
// /api/users/* → user-service
// /api/search/* → search-service

[패턴 1] DB per Service (권장)
- 각 서비스 자기 DB
- 다른 서비스는 API로 접근
- 결합 최소

[패턴 2] Shared DB (안티패턴)
- 여러 서비스가 같은 DB
- 강한 결합
- 마이그레이션 지옥


→ DB per Service이 정답
→ 데이터 중복 OK (eventual consistency)

모놀리스: 단일 DB 트랜잭션
MSA: 분산 트랜잭션 → Saga로 해결


[Saga 패턴]
주문 → 결제 → 재고 → 배송

각 단계 성공 시 다음 단계
실패 시 보상 트랜잭션 (rollback)


[Choreography] 이벤트 기반
order.placed → payment.processing
payment.success → inventory.reserve
inventory.reserved → shipment.create


[Orchestration] 중앙 조정
SagaCoordinator가 단계별 명령
실패 시 보상 명령