← 전체 목록
📡
Google Cloud Pub/Sub
통합비동기 메시징 서비스
▶아키텍처 다이어그램
점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
왜 필요한가요?
서비스가 여럿이면 서로 직접 호출하게 되고, 한 서비스가 느려지면 호출한 쪽도 대기합니다. 서비스가 늘수록 호출 그래프가 복잡해지고 장애가 연쇄적으로 퍼집니다.
안에서 어떻게 동작하나요?
Pub/Sub는 Topic과 Subscription으로 구성됩니다. 발행자가 Topic에 메시지를 보내면, 각 Subscription에 복사되어 구독자가 Pull로 가져가거나 Push로 전달받습니다. 메시지는 구독자가 확인(ack)할 때까지 보관됩니다.
무엇과 헷갈리나요?
Pub/Sub와 직접 HTTP 호출은 둘 다 서비스 간 통신이지만, HTTP 호출은 동기적이고 수신자가 반드시 살아 있어야 합니다. Pub/Sub는 수신자가 잠시 다운되어도 메시지가 유실되지 않고 대기합니다. 즉시 응답이 필요하면 HTTP, 비동기 처리와 내결함성이 필요하면 Pub/Sub입니다.
왜 이런 방식이 등장했나요?
마이크로서비스 아키텍처가 확산되면서, 서비스 간 직접 호출의 결합 문제가 부각되었습니다. 메시지 큐를 직접 운영(RabbitMQ, Kafka)하는 부담을 없애면서 비동기 통신을 제공하는 완전관리형 서비스가 필요해졌습니다.
언제 쓰나요?
이벤트 기반 마이크로서비스, 실시간 데이터 파이프라인, 비동기 작업 큐, 팬아웃 패턴에 적합합니다. 메시지 순서가 엄격하게 보장되어야 하거나 즉시 응답이 필요한 경우에는 맞지 않습니다.
이벤트 기반 아키텍처스트리밍 데이터 수집작업 큐팬아웃
Official Docs
GCP더 깊게 보기
현재 페이지의 개념 설명을 본 뒤 공식 문서로 바로 이동합니다.