GCP의 메시징 서비스로 Kafka나 래빗MQ와 같은 오픈소스 메시징 서비스와 동일한 서비스
글로벌 규모에서도 낮은 지연 시간과 안정적인 메시지 전달을 제공해주고, 서버리스 환경이기 때문에 별도의 인스턴스를 관리할 필요없이 사용량에 따라 초당 수억 개까지 메시지를 확장할 수 있다.
메시지를 생산하는 Topic(게시) 와 메시지를 해당 주제로부터 받는 Subscription(구독)으로 구성되어 1:다, 다:1, 다:다 구성을 가진다.
메시징 서비스란 간단히 말하면 메시지(데이터)들을 큐에 넣고 차례로 전달해주는 서비스.
일반적인 서버 - 클라이언트 구조에서는 사용자가 요청하면 서버가 그에 대한 처리를 한 후 사용자에게 응답한다.
하지만 서버가 동시에 처리할 수 있는 양은 한정적인 관계로 요청 메시지를 큐에 쌓아놓고 처리할 수 있기 때문에 응답을 하는 서버가 죽더라도 그 사이에 요청이 들어온 메시지들은 메시지 큐에 쌓여있어서 서버가 살아났을 때 처리를 할 수도 있다. 또하 부하 분산 처리에도 유리한데, 여러 대의 서버가 하나의 큐를 바라보도록 하면 처리할 데이터가 많아져도 서버는 자신의 처리량에 맞는 요청만 가져와서 처리할 수도 있다.
Push, Pull 비교
- Pull
Pub/Sub << "Message(데이터) 줘!" << Subscriber
Pub/Sub >> "여기 있어" >> Subscriber
Pub/Sub << "잘 받았어, 이제 지워도 돼" << Subscriber- Push
Pub/Sub >> "Message(데이터) 왔다 받아!" >> Subscriber
Pub/Sub << "잘 받았어, 이제 지워도 돼" << Subscriber
Pull(가져오기) | Push(내보내기) | |
---|---|---|
엔드포인트 | 자격을 증명한 인터넷상 모든 기기는 API 호출 가능 | 자격 증명이 어려운 서비스(구독자)에서 사용할 수 있다. |
부하 분산 | 여러 구독자가 Share와 같은 Pull요청을 구성할 수 있다. | 엔드포인트가 부하분산기가 될 수 있다 |
구성 | 필요x | GCP 콘솔에서 내보내기 엔드포인트를 구성해야 한다. |
흐름 관리 | 구독자가 전달 속도를 조절 | Pub/Sub 서버가 자동으로 흐름 제어를 구현 |
효율성 및 처리 | ||
지침 | 대량 메시지, 메시지 처리의 효율성과 처리량이 중요할 경우 | GCP 종속 서비스외의 환경, 동일한 webhook에 의한 여러 주제를 처리해야 하는 경우 |