이 문서에서는 push 구독, 워크플로, 관련 속성을 간략하게 설명합니다.
push 전달에서는 Pub/Sub가 구독자 애플리케이션에 메시지 수신을 요청합니다. 메시지는 HTTPS POST 요청과 같이 공개적으로 주소를 지정할 수 있는 서버 또는 웹훅으로 전송됩니다.
push 구독은 Pub/Sub 관련 클라이언트 라이브러리 및 인증 메커니즘에 대한 종속 항목을 최소화합니다. 또한 Cloud Run Functions, Cloud Run, Google Kubernetes Engine과 같은 서버리스 및 자동 확장 서비스 기술에서도 잘 작동합니다.
시작하기 전에
이 문서를 읽으려면 먼저 다음 항목에 익숙해야 합니다.
Pub/Sub 작동 방법과 여러 가지 Pub/Sub 용어
Pub/Sub가 지원하는 다양한 종류의 구독과 push 구독을 사용해야 하는 이유
push 구독 워크플로
push 구독에서 Pub/Sub 서버는 구독자 클라이언트에 메시지 전송을 요청합니다.
다음은 구독자 클라이언트와 push 구독 간의 워크플로를 보여주는 이미지입니다.
다음은 그림 3을 참조하는 워크플로에 대한 간략한 설명입니다.
- Pub/Sub 서버는 각 메시지를 미리 구성된 엔드포인트에 있는 구독자 클라이언트에 하나의 HTTPS 요청으로 전송합니다. 이 요청은 이미지에서
PushRequest로 표시됩니다. - 엔드포인트가 HTTP 성공 상태 코드를 반환해 메시지를 확인합니다. 성공적이지 않은 응답은 Pub/Sub가 메시지를 다시 전송해야 한다는 뜻입니다. 이 응답은 이미지에서
PushResponse로 표시됩니다. - Pub/Sub는 성공 응답을 수신하는 속도에 따라 push 요청의 비율을 동적으로 조정합니다.
push 구독의 속성
push 구독으로 구성하는 속성은 구독에 메시지를 쓰는 방법을 결정합니다. 자세한 내용은 구독 속성을 참조하세요.
push 엔드포인트가 메시지를 수신하는 방법
Pub/Sub가 push 엔드포인트로 메시지를 전송할 때 이를 래핑되거나 래핑되지 않도록 선택할 수 있습니다. 기본적으로 메시지는 래핑되어 전송됩니다.
- 래핑됨. Pub/Sub는
POST요청의 JSON 본문에 메시지를 전송합니다. - 래핑되지 않음. Pub/Sub는 원시 메시지 데이터를 HTTP 본문으로 직접 전송합니다.
다음 예시에서는 message.data 필드에 Hello there 문자열이 포함된 푸시 엔드포인트에 대한 JSON POST 요청의 래핑된 본문을 보여줍니다.
POST 요청의 본문은 JSON 객체입니다. 메시지 데이터는 message.data 필드에 있으며 base64로 인코딩됩니다.
최솟값을 사용하는 요청의 예시
{ "message": { "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==", "messageId": "2070443601311540", "message_id": "2070443601311540", "publishTime": "2021-02-26T19:13:55.749Z", "publish_time": "2021-02-26T19:13:55.749Z" }, "subscription": "projects/myproject/subscriptions/mysubscription" }
최댓값을 사용하는 요청의 예시
이 예시에서는 시간이 지나면서 변경될 수 있는 현재 최댓값을 보여줍니다. 또한 속성 맵에는 다양한 값이 포함될 수 있습니다.
{ "deliveryAttempt": 5, "message": { "attributes": { "key": "value" }, "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==", "messageId": "2070443601311540", "message_id": "2070443601311540", "orderingKey": "key", "publishTime": "2021-02-26T19:13:55.749Z", "publish_time": "2021-02-26T19:13:55.749Z" }, "subscription": "projects/myproject/subscriptions/mysubscription" }
push 구독에서 메시지를 수신하려면 웹훅을 사용하고 Pub/Sub가 push 엔드포인트로 보내는 POST 요청을 처리합니다. App Engine에서 이러한 POST 요청을 처리하는 방법에 대한 자세한 내용은 Pub/Sub 메시지 쓰기 및 응답을 참조하세요.
push 요청을 받으면 HTTP 상태 코드를 반환합니다. 메시지를 확인하려면 다음 상태 코드 중 하나를 반환합니다.
102200201202204
메시지에 부정 확인을 보내려면 다른 상태 코드를 반환합니다. 부정 확인을 보내거나 확인 기한이 만료되면 Pub/Sub에서 메시지를 다시 보냅니다. push 구독에서 수신하는 개별 메시지의 확인 기한을 수정할 수 없습니다.
push 구독 인증
push 구독에 인증이 사용되는 경우 Pub/Sub 서비스가 JWT를 서명하고 push 요청의 승인 헤더에서 JWT를 전송합니다.
인증 설정에 대한 자세한 내용은 push 요청 인증을 참조하세요.
메시지 전송 중지 및 재개
Pub/Sub가 push 엔드포인트로 요청을 보내지 않도록 일시적으로 중단하려면 구독을 pull로 변경합니다. 변경사항이 적용되는 데 몇 분 정도 걸릴 수 있습니다.
push 전달을 재개하려면 URL을 유효한 엔드포인트로 다시 설정하세요. 전달을 영구적으로 중단하려면 구독을 삭제해야 합니다.
push 백오프
push 구독자가 부정 확인을 너무 많이 전송하면 Pub/Sub에서 push 백오프를 사용해 메시지를 전송하기 시작할 수 있습니다. Pub/Sub는 push 백오프를 사용할 때 미리 정해진 시간 동안 메시지 전송을 중지합니다. 이 시간 범위는 100밀리초~60초입니다. 이 시간이 지나면 Pub/Sub에서 메시지를 다시 전송하기 시작합니다.
push 백오프는 지수 백오프 알고리즘을 사용하여 메시지 전송 사이에 사용되는 Pub/Sub 지연을 결정합니다. 이 시간은 push 구독자가 전송하는 부정 확인 수를 기준으로 계산됩니다.
예를 들어 push 구독자가 초당 5개의 메시지를 수신하고 초당 1개의 부정 확인을 보내면 Pub/Sub는 약 500밀리초마다 메시지를 전송합니다. 또는 push 구독자가 초당 부정 확인 5개를 보내면 Pub/Sub는 30~60초마다 메시지를 전달합니다.
push 백오프에 대한 다음 사항을 고려하세요.
- push 백오프는 사용 설정하거나 중지할 수 없습니다. 지연을 계산하는 데 사용된 값도 수정할 수 없습니다.
- push 백오프는 다음과 같은 경우 트리거됩니다.
- 부정 확인이 수신되었습니다.
- 메시지 확인 기한이 만료되었습니다.
- push 백오프가 구독의 모든 메시지(전역)에 적용됩니다.
전달 속도
Pub/Sub는 느린 시작 알고리즘을 사용하여 동시 push 요청 수를 조정합니다. 동시에 허용되는 최대 push 요청 수는 push 범위에 해당됩니다. push 범위는 전송 성공 시 증가하고 실패 시 감소합니다. 시스템은 작은 한 자릿수 창 크기로 시작합니다.
구독자가 메시지를 확인하면 기간이 기하급수적으로 증가합니다. 구독자가 메시지를 99% 넘게 확인하고 push 요청 지연 시간이 평균 1초 미만인 구독의 경우 push 기간을 충분히 확장하여 모든 게시 처리량을 처리할 수 있어야 합니다.
push 요청 지연 시간에는 다음이 포함됩니다.
Pub/Sub 서버와 push 엔드포인트 간의 왕복 네트워크 지연 시간
구독자 처리 시간
리전당 3,000개의 미해결 메시지가 push되면 push 엔드포인트가 너무 많은 메시지를 수신하지 못하도록 기간이 선형적으로 증가합니다. 평균 지연 시간이 1초를 초과하거나 구독자가 요청의 99% 미만을 확인하면 범위가 3,000개의 미해결 메시지의 하한으로 감소합니다.
push 전송을 모니터링하는 데 사용할 수 있는 측정항목에 대한 자세한 내용은 push 구독 모니터링을 참조하세요.
할당량 및 한도
다음 단계
주제의 push 구독 만들기
gcloud CLI를 사용하여 구독을 만들거나 수정하기
REST API로 구독을 만들거나 수정하기
RPC API로 구독을 만들거나 수정하기