HTTP/REST, gRPC, 메시지 브로커 기반 이벤트 소개

🔗 HTTP/REST, gRPC, 메시지 브로커 기반 이벤트 소개

1. HTTP/REST: 가장 널리 쓰이는 표준 API 통신

• 방식: 클라이언트-서버 방식의 동기 통신 (Request/Response)
• 전송 포맷: 일반적으로 JSON
• 장점:
  • 직관적인 URI 설계
  • 브라우저 친화적
  • 거의 모든 언어/프레임워크에서 지원
• 단점:
  • 동기 통신: 호출자가 응답을 기다려야 함 → 시스템 결합도 높음
  • 에러나 타임아웃 발생 시 실패 처리 필요
• 사용 예: 사용자 인증, 주문 요청, 리소스 CRUD 등 명령형 API 호출

2. gRPC: 고성능 이진 프로토콜 기반 RPC

• 방식: 동기 또는 비동기 Remote Procedure Call
• 전송 포맷: Protocol Buffers (Protobuf)
• 장점:
  • 빠르고 효율적인 바이너리 전송
  • 자동 코드 생성 → 인터페이스 일관성 보장
  • 양방향 스트리밍 지원
• 단점:
  • 디버깅이 어렵고 가독성 낮음
  • 브라우저 직접 접근 어려움 (gRPC-Web 필요)
• 사용 예: 마이크로서비스 간 고속 통신, 실시간 데이터 처리

3. 메시지 브로커 기반 이벤트 아키텍처

• 방식: 비동기 메시지 기반 통신, Pub/Sub 모델
• 대표 브로커: Apache Kafka, RabbitMQ, NATS 등
• 이벤트 드리븐 아키텍처(Event-Driven Architecture):
  • 하나의 서비스가 이벤트를 발행(Publish) 하면,
  • 다른 서비스들이 구독(Subscribe) 하여 비동기로 반응

✅ 장점:

• 강한 확장성: 이벤트 수신자는 동적으로 늘릴 수 있음
• 비동기 처리: 느린 서비스나 실패한 서비스도 독립적으로 복구 가능
• 낮은 결합도: 발행자는 수신자를 몰라도 됨 → 유연한 서비스 확장

❌ 단점:

• 시스템 상태 파악이 어려움 → 이벤트 추적과 모니터링 필요
• 트랜잭션 처리 복잡성 증가 (Eventually Consistent)
• 메시지 중복, 순서 문제 처리 필요

---

🧭 선택 가이드

 

기준	HTTP/REST	gRPC	메시지 브로커 기반 이벤트
통신 방식	동기	동기/비동기	비동기
성능	보통	높음	매우 높음 (비동기 병렬)
결합도	높음	중간	낮음
확장성	제한적	좋음	매우 좋음
트랜잭션 일관성 관리	간단	복잡	어려움 (보상 트랜잭션 필요)
디버깅/모니터링	쉬움	보통	어려움
사용 예	API 게이트웨이, 외부 호출	마이크로서비스 내부 통신	비즈니스 이벤트 처리

---

🧩 비교 예시 다이어그램

[ REST API 호출 흐름 ]
Client → [ API Gateway ] → [ Service A ] → [ Service B ]

[ gRPC 통신 흐름 ]
Service A → gRPC call → Service B → gRPC call → Service C

[ 메시지 브로커 이벤트 흐름 ]
Service A → [ Kafka Topic (주문 생성됨) ]
                      ↓
          [ Service B (재고 차감) ]
                      ↓
          [ Service C (알림 전송) ]

---

✨ 마무리

• REST와 gRPC는 명령형, 요청 기반 통신에 적합
• 메시지 브로커는 이벤트 기반, 반응형 시스템 설계에 적합
• 실제 마이크로서비스 아키텍처에서는 이들을 혼합 구성하는 경우가 많음
  • 예: REST로 주문 요청 → Kafka로 이벤트 발행 → 다른 서비스는 이벤트 기반 처리