MSA에서 API Gateway 중심의 서버 간 통신 방식 비교

1. 개요

MSA(Microservice Architecture)에서는 하나의 거대한 애플리케이션 대신, 역할별로 쪼개진 여러 서비스가 독립적으로 배포/확장됩니다. 이때 모든 외부 트래픽은 API Gateway를 통해 유입되며, Gateway는 인증/인가, 라우팅, 로깅/모니터링, 속도 제한, 응답 집계(데이터 통합) 같은 공통 관심사를 담당합니다.

[Client]
   ↓
[API Gateway]  ← 인증/인가 · 라우팅 · 로깅 · 캐싱 · 속도 제한 · 응답 집계
   ↓
 ┌───────────────┬────────────────┐
 │               │                │
[Auth Service]  [Event Service]  [Other Services...]

---

2. 주요 통신 방식

Gateway와 내부 서비스(또는 서비스 간) 통신은 단일 해법이 아닌 목적에 따라 다양한 방식을 조합합니다.

구분	프로토콜	통신 형태	대표 용도
(1)	HTTP REST	요청/응답(동기)	범용 API, 인증/인가, 간단한 CRUD
(2)	gRPC	요청/응답(동기) + 스트리밍	고성능 내부 RPC, 다량 조회
(3)	Message Queue(Kafka/RabbitMQ/Redis Streams)	비동기	이벤트 발행/구독, 비동기 CUD 처리
(4)	GraphQL Federation	질의 기반(동기)	다수 서비스 데이터의 통합 조회
(5)	WebSocket / SSE	실시간 양방향/단방향 스트림	실시간 알림, 상태 갱신

---

3. 통신 방식별 특징과 장단점

3.1 HTTP REST

특징

• 가장 널리 쓰이는 동기 통신. 브라우저/네이티브 클라이언트 친화적, 디버깅이 단순.
• JSON 직렬화와 HTTP 헤더로 인한 오버헤드가 존재.

장점

• 구현/운영/문서화(Swagger/OpenAPI) 용이.
• 캐싱, 로드밸런싱, 프록시 등 주변 생태계가 성숙.

단점

• 트래픽이 매우 많거나 내부 호출이 잦은 경우 성능/지연 비용이 커질 수 있음.
• 고정 응답 구조로 인해 Overfetching/Underfetching 발생 가능.

권장 사용처

• 인증/인가, 설정/메타데이터, 단순한 조회/명령, 외부 공개 API.

---

3.2 gRPC

특징

• HTTP/2 + Protocol Buffers 기반의 고성능 RPC. 양방향 스트리밍 지원.
• 엄격한 스키마(.proto)로 타입 안정성·성능 확보.

장점

• REST 대비 높은 직렬화 효율(저용량·저지연).
• 내부 서비스 간 대량 조회·저지연 처리에 적합.

단점

• 브라우저 직접 호출 곤란(Gateway에서 변환 필요).
• 디버깅/관측 난이도, .proto 관리 오버헤드.

권장 사용처

• 내부 서비스 간 Read 중심 호출(상태/구성/참조 데이터 조회), 대량 트래픽.

---

3.3 Message Queue (Kafka / RabbitMQ / Redis Streams)

특징

• 비동기 메시지 기반. 발행/구독으로 서비스 결합도 감소, 장애 격리에 유리.
• 재시도/재처리, 소비자 수평 확장에 강함.

장점

• 요청-처리 분리로 시스템 탄력성↑, 피크 완화.
• 트랜잭션 경계를 느슨하게 가져가며 결과적 일관성 모델 구현 용이.

단점

• 즉시 응답이 어려움(최종적 반영). 순서/중복/멱등성 관리 필요.
• 운영 복잡도(Kafka 클러스터 등)와 비용.

권장 사용처

• Create/Update/Delete(CUD) 중심의 상태 변경 이벤트 처리, 보상/쿠폰 지급, 사후 파이프라인.

---

3.4 GraphQL Federation

특징

• 여러 서비스의 스키마를 게이트웨이에서 합쳐 단일 GraphQL 엔드포인트로 제공.
• 클라이언트가 필요한 필드만 선택하여 통합 조회 가능.

장점

• Over/Underfetching 최소화, 스키마가 곧 문서.
• 다수 서비스의 데이터를 한 번의 질의로 조합.

단점

• Federation 구성·관리가 복잡. N+1 쿼리·캐싱 전략 설계 필요.
• 쓰기(CUD)보다 조회(Read) 통합에 강점.

권장 사용처

• 복합 화면/집계 조회 레이어, 데이터 카탈로그형 API.

데이터 통합이란?

• 서로 다른 서비스가 소유한 데이터를 게이트웨이(또는 GraphQL Gateway)가 조합해 하나의 응답으로 제공하는 것.
• 예: User는 사용자 서비스, Attendance는 이벤트 서비스가 관리하지만, 클라이언트는 “사용자 이름 + 출석 현황”을 한 번에 요청.

---

3.5 WebSocket / Server-Sent Events(SSE)

특징

• 실시간 스트림 전송(양방향 또는 서버→클라이언트 단방향).

장점

• 즉시성 요구(알림/상태 표시/대시보드)에 적합.

단점

• 연결 상태 관리, 수평 확장 시 세션 문제, 관측 난이도.

권장 사용처

• “7일 연속 출석 달성” 같은 실시간 알림, 진행 현황 스트림.

---

4. 동기 vs 비동기와 CRUD 매핑

• 동기 통신(REST/gRPC) → Read 중심
  • 사용자가 즉시 화면에 보여줄 데이터를 가져올 때 적합.
  • 내부 고성능 조회는 gRPC, 외부·범용 조회는 REST.
• 비동기 통신(MQ) → CUD 중심
  • 상태 변경을 이벤트로 발행하여 느슨한 결합과 재처리를 보장.
  • 예: 출석 체크 성공 → “AttendanceRecorded” 이벤트 발행 → 포인트/쿠폰 서비스가 비동기 수신 후 반영.

분류	선호 통신	이유
Read(조회)	gRPC(내부), REST(외부)	지연 최소화/범용 접근성
Create/Update/Delete	MQ	멱등/재시도/탄력성/확장성
복합 조회	GraphQL 또는 Gateway 집계	다수 서비스 데이터의 단일 응답

---

5. 통신 방식 비교 요약

방식	형태	속도	결합도	실시간성	CRUD 적합성	주요 용도
HTTP REST	동기	중간	중간~높음	낮음	Read(범용), 간단 CUD	외부/범용 API, 인증
gRPC	동기	빠름	중간	중간(스트리밍)	Read(내부 고성능)	내부 RPC 조회
MQ	비동기	빠름(버퍼링)	낮음	낮음	CUD(비동기 반영)	이벤트 드리븐 처리
GraphQL Federation	동기	중간	중간	낮음	Read(복합/집계)	통합 조회 레이어
WebSocket/SSE	스트림	빠름	중간	높음	실시간 피드백	알림/대시보드

---

6. 실무 구성 예시

계층	통신 방식	비고
Client ↔ Gateway	REST 또는 GraphQL	JWT 검증/속도 제한/로깅
Gateway ↔ Auth	REST 또는 gRPC	로그인/토큰 검증/유저 조회
Gateway ↔ Event	REST	출석/보상 API
Event ↔ Reward/Coupon	MQ(Kafka 등)	CUD 이벤트 비동기 반영
Gateway ↔ Client(실시간)	WebSocket/SSE	보상 달성 알림

---

7. 통신 구조 다이어그램

graph TD
    Client -->|HTTP/GraphQL| Gateway
    Gateway -->|HTTP REST| AuthService
    Gateway -->|HTTP REST| EventService
    EventService -->|Kafka Topic (CUD)| RewardService
    Gateway -->|WebSocket/SSE| Client

---

8. 결론

1) 단일 해법은 없다. 도메인 특성과 경험적 지표에 따라 혼합한다.
2) 동기(Read) / 비동기(CUD) 분할을 기본 축으로 삼으면 설계가 단순해진다.
3) 복합 조회가 많다면 GraphQL 또는 Gateway 집계 레이어로 데이터 통합을 제공한다.
4) 실시간 피드백이 중요하면 WebSocket/SSE를 보조로 도입한다.
5) 관측성(Tracing/Logging/Metrics)과 멱등성/재처리 전략을 초기부터 포함해 운영 복잡도를 낮춘다.