push 구독

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

push 전달에서는 Pub/Sub가 구독자 애플리케이션에 메시지 수신을 요청합니다.

시작하기 전에

이 문서를 읽으려면 먼저 다음 항목에 익숙해야 합니다.

  • Pub/Sub 작동 방법과 여러 가지 Pub/Sub 용어

  • Pub/Sub가 지원하는 다양한 종류의 구독과 푸시 구독을 사용해야 하는 이유

push 구독의 속성

푸시 구독을 구성할 때 다음 속성을 지정할 수 있습니다.

  • 엔드포인트 URL(필수) 공개적으로 액세스 가능한 HTTPS 주소입니다. push 엔드포인트의 서버에는 인증 기관에서 서명된 유효한 SSL 인증서가 있어야 합니다. Pub/Sub 서비스는 Pub/Sub 서비스가 메시지를 저장하는 것과 동일한 Google Cloud 리전에서 엔드포인트를 push하는 메시지를 전송합니다. Pub/Sub 서비스는 최선의 방식으로 Google Cloud 리전에서 메시지를 전송합니다.

    Pub/Sub에는 push 구독 URL 도메인의 소유권 증명이 더 이상 필요하지 않습니다. 도메인에서 Pub/Sub의 예상치 못한 POST 요청을 받으면 악용 사례로 의심되는 항목을 신고할 수 있습니다.

  • 인증 사용 설정. 사용 설정하면 Pub/Sub에서 푸시 엔드포인트로 전달되는 메시지에는 엔드포인트가 요청을 인증할 수 있는 승인 헤더가 포함됩니다. 구독과 동일한 프로젝트에 호스팅된 App Engine Standard 및 Cloud Functions 엔드포인트에 자동 인증 및 승인 메커니즘을 사용할 수 있습니다.

인증된 푸시 구독의 인증 구성은 사용자 관리형 서비스 계정 및 create, patch, 또는 ModifyPushConfig 호출에 지정된 잠재고객 매개변수로 구성됩니다. 또한 다음 섹션에서 설명하는 것처럼 특정 Google 관리 서비스 계정에 특정 역할을 부여해야 합니다.

  • 사용자 관리형 서비스 계정(필수). push 구독과 관련된 서비스 계정입니다. 이 계정은 생성된 JSON 웹 토큰(JWT)의 email 클레임으로 사용됩니다. 다음은 서비스 계정의 요구사항 목록입니다.

  • 잠재고객. 특정 토큰의 의도한 잠재고객을 검증하기 위해 웹훅에서 사용하는 대소문자를 구분하지 않는 단일 문자열입니다.

  • Google 관리형 서비스 계정(필수).

    • Pub/Sub는 service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com 형식으로 서비스 계정을 자동으로 만듭니다.

    • Pub/Sub가 인증된 푸시 요청에 대한 JWT 토큰을 만들도록 허용하려면 이 서비스 계정에 roles/iam.serviceAccountTokenCreator 역할에 포함된 iam.serviceAccounts.getOpenIdToken 권한을 부여해야 합니다.

push 구독 및 VPC 서비스 제어

VPC 서비스 제어로 보호되는 프로젝트의 경우 푸시 구독의 다음 제한사항에 유의하세요.

  • push 엔드포인트는 기본 run.app URL을 사용하여 Cloud Run 서비스로 설정된 새로운 push 구독만 만들 수 있습니다. 커스텀 도메인은 작동하지 않습니다.

  • push 엔드포인트가 Workflows 실행으로 설정된 Workflows 대상으로 Eventarc를 통해 이벤트를 라우팅하는 경우 Eventarc를 통해서만 새 push 구독을 만들 수 있습니다.

  • 기존의 push 구독은 업데이트할 수 없습니다. 이러한 push 구독은 VPC 서비스 제어로 보호되지 않더라도 계속 작동합니다.

메시지 수신

Pub/Sub가 push 엔드포인트에 메시지를 전송하면 Pub/Sub는 POST 요청 본문에 메시지를 전송합니다. 요청의 본문은 JSON 객체이고 메시지 데이터는 message.data 필드에 있습니다. 메시지 데이터는 base64로 인코딩됩니다.

다음 예시는 push 엔드포인트에 대한 POST 요청의 본문입니다.

{
    "message": {
        "attributes": {
            "key": "value"
        },
        "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"
}

push 구독에서 메시지를 수신하려면 웹훅을 사용하고 Pub/Sub가 push 엔드포인트로 보내는 POST 요청을 처리합니다. App Engine에서 이러한 POST 요청을 처리하는 방법에 대한 자세한 내용은 Pub/Sub 메시지 쓰기 및 응답을 참조하세요.

push 요청을 받으면 HTTP 상태 코드를 반환합니다. 메시지를 확인하려면 다음 상태 코드 중 하나를 반환합니다.

  • 102
  • 200
  • 201
  • 202
  • 204

메시지에 부정 확인을 보내려면 다른 상태 코드를 반환합니다. 부정 확인을 보내거나 확인 기한이 만료되면 Pub/Sub에서 메시지를 다시 보냅니다. push 구독에서 수신하는 개별 메시지의 확인 기한을 수정할 수 없습니다.

push 구독 인증

push 구독에 인증이 사용되는 경우 Pub/Sub 서비스가 JWT를 서명하고 push 요청의 승인 헤더에서 JWT를 전송합니다. JWT에는 클레임 및 서명이 포함됩니다.

구독자는 JWT를 검증하고 다음 사항을 확인할 수 있습니다.

  • 클레임이 정확한가
  • Pub/Sub 서비스가 클레임에 서명했는가

구독자가 방화벽을 사용하는 경우 push 요청을 수신할 수 없습니다. push 요청을 받으려면 방화벽을 사용 중지하고 JWT를 확인해야 합니다.

JWT 형식

JWT는 헤더, 클레임 세트, 서명으로 구성되는 OpenIDConnect JWT입니다. Pub/Sub 서비스는 JWT를 마침표 구분 기호가 포함된 base64 문자열로 인코딩합니다.

예를 들어 다음 승인 헤더에는 인코딩된 JWT가 포함됩니다.

"Authorization" : "Bearer
eyJhbGciOiJSUzI1NiIsImtpZCI6IjdkNjgwZDhjNzBkNDRlOTQ3MTMzY2JkNDk5ZWJjMWE2MWMzZDVh
YmMiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJodHRwczovL2V4YW1wbGUuY29tIiwiYXpwIjoiMTEzNzc0M
jY0NDYzMDM4MzIxOTY0IiwiZW1haWwiOiJnYWUtZ2NwQGFwcHNwb3QuZ3NlcnZpY2VhY2NvdW50LmNvb
SIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJleHAiOjE1NTAxODU5MzUsImlhdCI6MTU1MDE4MjMzNSwia
XNzIjoiaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tIiwic3ViIjoiMTEzNzc0MjY0NDYzMDM4MzIxO
TY0In0.QVjyqpmadTyDZmlX2u3jWd1kJ68YkdwsRZDo-QxSPbxjug4ucLBwAs2QePrcgZ6hhkvdc4UHY
4YF3fz9g7XHULNVIzX5xh02qXEH8dK6PgGndIWcZQzjSYfgO-q-R2oo2hNM5HBBsQN4ARtGK_acG-NGG
WM3CQfahbEjZPAJe_B8M7HfIu_G5jOLZCw2EUcGo8BvEwGcLWB2WqEgRM0-xt5-UPzoa3-FpSPG7DHk7
z9zRUeq6eB__ldb-2o4RciJmjVwHgnYqn3VvlX9oVKEgXpNFhKuYA-mWh5o7BCwhujSMmFoBOh6mbIXF
cyf5UiVqKjpqEbqPGo_AvKvIQ9VTQ"

헤더 및 클레임 세트는 JSON 문자열입니다. 디코딩되면 다음과 같은 형식을 사용합니다.

{"alg":"RS256","kid":"7d680d8c70d44e947133cbd499ebc1a61c3d5abc","typ":"JWT"}

{
   "aud":"https://example.com",
   "azp":"113774264463038321964",
   "email":"gae-gcp@appspot.gserviceaccount.com",
   "sub":"113774264463038321964",
   "email_verified":true,
   "exp":1550185935,
   "iat":1550182335,
   "iss":"https://accounts.google.com"
  }

push 엔드포인트로 전송된 요청에 연결된 토큰은 최대 1시간이 걸릴 수 있습니다.

push 인증을 위한 Pub/Sub 구성

다음 예시에서는 푸시 인증 서비스 계정을 원하는 서비스 계정으로 설정하는 방법과 Google 관리 서비스 계정 service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com에 iam.serviceAccountTokenCreator 역할을 부여하는 방법을 보여줍니다.

Console

  1. Pub/Sub 구독 페이지로 이동합니다.

    구독 페이지로 이동

  2. 구독 만들기를 클릭합니다.

  3. 구독 ID 필드에 이름을 입력합니다.

  4. 주제를 선택합니다.

  5. 전송 유형으로 push를 선택합니다.

  6. 엔드포인트 URL을 입력합니다.

  7. 인증 사용 설정을 선택합니다.

  8. 서비스 계정을 선택합니다.

  9. Google 관리형 서비스 계정 service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com에 프로젝트의 IAM 대시보드에 대한 iam.serviceAccountTokenCreator 역할이 있는지 확인합니다. 서비스 계정에 역할이 부여되지 않은 경우 IAM 대시보드에서 권한 부여를 클릭하여 역할을 수행합니다.

  10. 선택사항: 잠재고객을 입력합니다.

  11. 만들기를 클릭합니다.

gcloud

# Configure the push subscription
gcloud pubsub subscriptions (create|update|modify-push-config) ${SUBSCRIPTION} \
 --topic=${TOPIC} \
 --push-endpoint=${PUSH_ENDPOINT_URI} \
 --push-auth-service-account=${SERVICE_ACCOUNT_EMAIL} \
 --push-auth-token-audience=${OPTIONAL_AUDIENCE_OVERRIDE}

# Your Google-managed service account
# `service-{PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com` needs to have the
# `iam.serviceAccountTokenCreator` role.
PUBSUB_SERVICE_ACCOUNT="service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
 --member="serviceAccount:${PUBSUB_SERVICE_ACCOUNT}"\
 --role='roles/iam.serviceAccountTokenCreator'

IAP(Identity-Aware Proxy)로 보호되는 App Engine 애플리케이션에 인증된 push 구독을 사용하는 경우 push 인증 토큰 대상으로 IAP 클라이언트 ID를 제공해야 합니다. App Engine 애플리케이션에서 IAP를 사용 설정하려면 IAP 사용 설정을 참조하세요. IAP 클라이언트 ID를 찾으려면 사용자 인증 정보 페이지에서 IAP-App-Engine-app 클라이언트 ID를 찾습니다.

클레임

JWT는 Google에서 서명한 email 및 aud 클레임을 포함한 클레임을 확인하는 데 사용할 수 있습니다. 인증 및 승인에 Google의 OAuth 2.0 API를 사용하는 방법에 대한 자세한 내용은 OpenID Connect를 참조하세요.

이러한 클레임을 의미 있게 하는 두 가지 메커니즘이 있습니다. 먼저 Pub/Sub에서는 CreateSubscription, UpdateSubscription 또는 ModifyPushConfig 호출을 수행하는 사용자 또는 서비스 계정이 push 인증 서비스 계정에 대해 iam.serviceAccounts.actAs 권한이 있는 역할이 있을 것을 요구합니다. 이러한 역할의 예시로는 roles/iam.serviceAccountUser 역할이 있습니다.

두 번째로 토큰 서명에 사용된 인증서에 대한 액세스는 엄격하게 제어됩니다. 토큰을 만들려면 Pub/Sub에서 Google 관리형 서비스 계정 service-${PROJECT_NUMBER}@gcp-sa-pubsub.iam.gserviceaccount.com인 별도의 서명 서비스 계정 ID를 사용하여 내부 Google 서비스를 호출해야 합니다. 이 서명 서비스 계정은 push 인증 서비스 계정(또는 프로젝트와 같은 push 인증 서비스 계정의 모든 상위 리소스)에 대해 iam.serviceAccounts.getOpenIdToken 권한 또는 서비스 계정 토큰 생성자 역할(roles/iam.serviceAccountTokenCreator)이 있어야 합니다.

토큰 검증

Pub/Sub에서 push 엔드포인트로 보낸 토큰 검증에는 다음이 포함됩니다.

  • 서명 유효성 검사를 사용하여 토큰 무결성을 확인합니다.
  • 토큰의 email 및 audience 클레임이 push 구독 구성에서 설정된 값과 일치하는지 확인

다음 예시는 IAP(Identity-Aware Proxy)로 보호되지 않는 App Engine 애플리케이션에 대해 push 요청을 인증하는 방법을 보여줍니다. App Engine 애플리케이션이 IAP로 보호되는 경우 IAP JWT를 포함하는 HTTP 요청 헤더가 x-goog-iap-jwt-assertion이고 그에 따라 검증되어야 합니다.

프로토콜

요청:

GET https://oauth2.googleapis.com/tokeninfo?id_token={BEARER_TOKEN}

응답:

200 OK
{
    "alg": "RS256",
    "aud": "example.com",
    "azp": "104176025330667568672",
    "email": "{SERVICE_ACCOUNT_NAME}@{YOUR_PROJECT_NAME}.iam.gserviceaccount.com",
    "email_verified": "true",
    "exp": "1555463097",
    "iat": "1555459497",
    "iss": "https://accounts.google.com",
    "kid": "3782d3f0bc89008d9d2c01730f765cfb19d3b70e",
    "sub": "104176025330667568672",
    "typ": "JWT"
}

C#

이 샘플을 시도하기 전에 빠른 시작: 클라이언트 라이브러리 사용의 C# 설정 안내를 따르세요. 자세한 내용은 Pub/Sub C# API 참조 문서를 확인하세요. 

        /// <summary>
        /// Extended JWT payload to match the pubsub payload format.
        /// </summary>
        public class PubSubPayload : JsonWebSignature.Payload
        {
            [JsonProperty("email")]
            public string Email { get; set; }
            [JsonProperty("email_verified")]
            public string EmailVerified { get; set; }
        }
        /// <summary>
        /// Handle authenticated push request coming from pubsub.
        /// </summary>
        [HttpPost]
        [Route("/AuthPush")]
        public async Task<IActionResult> AuthPushAsync([FromBody] PushBody body, [FromQuery] string token)
        {
            // Get the Cloud Pub/Sub-generated "Authorization" header.
            string authorizaionHeader = HttpContext.Request.Headers["Authorization"];
            string verificationToken = token ?? body.message.attributes["token"];
            // JWT token comes in `Bearer <JWT>` format substring 7 specifies the position of first JWT char.
            string authToken = authorizaionHeader.StartsWith("Bearer ") ? authorizaionHeader.Substring(7) : null;
            if (verificationToken != _options.VerificationToken || authToken is null)
            {
                return new BadRequestResult();
            }
            // Verify and decode the JWT.
            // Note: For high volume push requests, it would save some network
            // overhead if you verify the tokens offline by decoding them using
            // Google's Public Cert; caching already seen tokens works best when
            // a large volume of messages have prompted a single push server to
            // handle them, in which case they would all share the same token for
            // a limited time window.
            var payload = await JsonWebSignature.VerifySignedTokenAsync<PubSubPayload>(authToken);

            // IMPORTANT: you should validate payload details not covered
            // by signature and audience verification above, including:
            //   - Ensure that `payload.Email` is equal to the expected service
            //     account set up in the push subscription settings.
            //   - Ensure that `payload.Email_verified` is set to true.

            var messageBytes = Convert.FromBase64String(body.message.data);
            string message = System.Text.Encoding.UTF8.GetString(messageBytes);
            s_authenticatedMessages.Add(message);
            return new OkResult();
        }

Go

// receiveMessagesHandler validates authentication token and caches the Pub/Sub
// message received.
func (a *app) receiveMessagesHandler(w http.ResponseWriter, r *http.Request) {
	if r.Method != "POST" {
		http.Error(w, http.StatusText(http.StatusMethodNotAllowed), http.StatusMethodNotAllowed)
		return
	}

	// Verify that the request originates from the application.
	// a.pubsubVerificationToken = os.Getenv("PUBSUB_VERIFICATION_TOKEN")
	if token, ok := r.URL.Query()["token"]; !ok || len(token) != 1 || token[0] != a.pubsubVerificationToken {
		http.Error(w, "Bad token", http.StatusBadRequest)
		return
	}

	// Get the Cloud Pub/Sub-generated JWT in the "Authorization" header.
	authHeader := r.Header.Get("Authorization")
	if authHeader == "" || len(strings.Split(authHeader, " ")) != 2 {
		http.Error(w, "Missing Authorization header", http.StatusBadRequest)
		return
	}
	token := strings.Split(authHeader, " ")[1]
	// Verify and decode the JWT.
	// If you don't need to control the HTTP client used you can use the
	// convenience method idtoken.Validate instead of creating a Validator.
	v, err := idtoken.NewValidator(r.Context(), option.WithHTTPClient(a.defaultHTTPClient))
	if err != nil {
		http.Error(w, "Unable to create Validator", http.StatusBadRequest)
		return
	}
	// Please change http://example.com to match with the value you are
	// providing while creating the subscription.
	payload, err := v.Validate(r.Context(), token, "http://example.com")
	if err != nil {
		http.Error(w, fmt.Sprintf("Invalid Token: %v", err), http.StatusBadRequest)
		return
	}
	if payload.Issuer != "accounts.google.com" && payload.Issuer != "https://accounts.google.com" {
		http.Error(w, "Wrong Issuer", http.StatusBadRequest)
		return
	}

	// IMPORTANT: you should validate claim details not covered by signature
	// and audience verification above, including:
	//   - Ensure that `payload.Claims["email"]` is equal to the expected service
	//     account set up in the push subscription settings.
	//   - Ensure that `payload.Claims["email_verified"]` is set to true.
	if payload.Claims["email"] != "test-service-account-email@example.com" || payload.Claims["email_verified"] != true {
		http.Error(w, "Unexpected email identity", http.StatusBadRequest)
		return
	}

	var pr pushRequest
	if err := json.NewDecoder(r.Body).Decode(&pr); err != nil {
		http.Error(w, fmt.Sprintf("Could not decode body: %v", err), http.StatusBadRequest)
		return
	}

	a.messagesMu.Lock()
	defer a.messagesMu.Unlock()
	// Limit to ten.
	a.messages = append(a.messages, pr.Message.Data)
	if len(a.messages) > maxMessages {
		a.messages = a.messages[len(a.messages)-maxMessages:]
	}

	fmt.Fprint(w, "OK")
}

자바

@WebServlet(value = "/pubsub/authenticated-push")
public class PubSubAuthenticatedPush extends HttpServlet {
  private final String pubsubVerificationToken = System.getenv("PUBSUB_VERIFICATION_TOKEN");
  private final MessageRepository messageRepository;
  private final GoogleIdTokenVerifier verifier =
      new GoogleIdTokenVerifier.Builder(new NetHttpTransport(), new JacksonFactory())
          /**
           * Please change example.com to match with value you are providing while creating
           * subscription as provided in @see <a
           * href="https://github.com/GoogleCloudPlatform/java-docs-samples/tree/main/appengine-java8/pubsub">README</a>.
           */
          .setAudience(Collections.singletonList("example.com"))
          .build();
  private final Gson gson = new Gson();
  private final JsonParser jsonParser = new JsonParser();

  @Override
  public void doPost(HttpServletRequest req, HttpServletResponse resp)
      throws IOException, ServletException {

    // Verify that the request originates from the application.
    if (req.getParameter("token").compareTo(pubsubVerificationToken) != 0) {
      resp.setStatus(HttpServletResponse.SC_BAD_REQUEST);
      return;
    }
    // Get the Cloud Pub/Sub-generated JWT in the "Authorization" header.
    String authorizationHeader = req.getHeader("Authorization");
    if (authorizationHeader == null
        || authorizationHeader.isEmpty()
        || authorizationHeader.split(" ").length != 2) {
      resp.setStatus(HttpServletResponse.SC_BAD_REQUEST);
      return;
    }
    String authorization = authorizationHeader.split(" ")[1];

    try {
      // Verify and decode the JWT.
      // Note: For high volume push requests, it would save some network overhead
      // if you verify the tokens offline by decoding them using Google's Public
      // Cert; caching already seen tokens works best when a large volume of
      // messsages have prompted a single push server to handle them, in which
      // case they would all share the same token for a limited time window.
      GoogleIdToken idToken = verifier.verify(authorization);

      GoogleIdToken.Payload payload = idToken.getPayload();
      // IMPORTANT: you should validate claim details not covered by signature
      // and audience verification above, including:
      //   - Ensure that `payload.getEmail()` is equal to the expected service
      //     account set up in the push subscription settings.
      //   - Ensure that `payload.getEmailVerified()` is set to true.

      messageRepository.saveToken(authorization);
      messageRepository.saveClaim(payload.toPrettyString());
      // parse message object from "message" field in the request body json
      // decode message data from base64
      Message message = getMessage(req);
      messageRepository.save(message);
      // 200, 201, 204, 102 status codes are interpreted as success by the Pub/Sub system
      resp.setStatus(102);
      super.doPost(req, resp);
    } catch (Exception e) {
      resp.setStatus(HttpServletResponse.SC_BAD_REQUEST);
    }
  }

  private Message getMessage(HttpServletRequest request) throws IOException {
    String requestBody = request.getReader().lines().collect(Collectors.joining("\n"));
    JsonElement jsonRoot = jsonParser.parse(requestBody);
    String messageStr = jsonRoot.getAsJsonObject().get("message").toString();
    Message message = gson.fromJson(messageStr, Message.class);
    // decode from base64
    String decoded = decode(message.getData());
    message.setData(decoded);
    return message;
  }

  private String decode(String data) {
    return new String(Base64.getDecoder().decode(data));
  }

  PubSubAuthenticatedPush(MessageRepository messageRepository) {
    this.messageRepository = messageRepository;
  }

  public PubSubAuthenticatedPush() {
    this(MessageRepositoryImpl.getInstance());
  }
}

Node.js

app.post('/pubsub/authenticated-push', jsonBodyParser, async (req, res) => {
  // Verify that the request originates from the application.
  if (req.query.token !== PUBSUB_VERIFICATION_TOKEN) {
    res.status(400).send('Invalid request');
    return;
  }

  // Verify that the push request originates from Cloud Pub/Sub.
  try {
    // Get the Cloud Pub/Sub-generated JWT in the "Authorization" header.
    const bearer = req.header('Authorization');
    const [, token] = bearer.match(/Bearer (.*)/);
    tokens.push(token);

    // Verify and decode the JWT.
    // Note: For high volume push requests, it would save some network
    // overhead if you verify the tokens offline by decoding them using
    // Google's Public Cert; caching already seen tokens works best when
    // a large volume of messages have prompted a single push server to
    // handle them, in which case they would all share the same token for
    // a limited time window.
    const ticket = await authClient.verifyIdToken({
      idToken: token,
      audience: 'example.com',
    });

    const claim = ticket.getPayload();

    // IMPORTANT: you should validate claim details not covered
    // by signature and audience verification above, including:
    //   - Ensure that `claim.email` is equal to the expected service
    //     account set up in the push subscription settings.
    //   - Ensure that `claim.email_verified` is set to true.

    claims.push(claim);
  } catch (e) {
    res.status(400).send('Invalid token');
    return;
  }

  // The message is a unicode string encoded in base64.
  const message = Buffer.from(req.body.message.data, 'base64').toString(
    'utf-8'
  );

  messages.push(message);

  res.status(200).send();
});

Python

@app.route('/push-handlers/receive_messages', methods=['POST'])
def receive_messages_handler():
    # Verify that the request originates from the application.
    if (request.args.get('token', '') !=
            current_app.config['PUBSUB_VERIFICATION_TOKEN']):
        return 'Invalid request', 400

    # Verify that the push request originates from Cloud Pub/Sub.
    try:
        # Get the Cloud Pub/Sub-generated JWT in the "Authorization" header.
        bearer_token = request.headers.get('Authorization')
        token = bearer_token.split(' ')[1]
        TOKENS.append(token)

        # Verify and decode the JWT. `verify_oauth2_token` verifies
        # the JWT signature, the `aud` claim, and the `exp` claim.
        # Note: For high volume push requests, it would save some network
        # overhead if you verify the tokens offline by downloading Google's
        # Public Cert and decode them using the `google.auth.jwt` module;
        # caching already seen tokens works best when a large volume of
        # messages have prompted a single push server to handle them, in which
        # case they would all share the same token for a limited time window.
        claim = id_token.verify_oauth2_token(token, requests.Request(),
                                             audience='example.com')

        # IMPORTANT: you should validate claim details not covered by signature
        # and audience verification above, including:
        #   - Ensure that `claim["email"]` is equal to the expected service
        #     account set up in the push subscription settings.
        #   - Ensure that `claim["email_verified"]` is set to true.

        CLAIMS.append(claim)
    except Exception as e:
        return 'Invalid token: {}\n'.format(e), 400

    envelope = json.loads(request.data.decode('utf-8'))
    payload = base64.b64decode(envelope['message']['data'])
    MESSAGES.append(payload)
    # Returning any 2xx status indicates successful receipt of the message.
    return 'OK', 200

Ruby

post "/pubsub/authenticated-push" do
  halt 400 if params[:token] != PUBSUB_VERIFICATION_TOKEN

  begin
    bearer = request.env["HTTP_AUTHORIZATION"]
    token = /Bearer (.*)/.match(bearer)[1]
    claim = Google::Auth::IDTokens.verify_oidc token, aud: "example.com"

    # IMPORTANT: you should validate claim details not covered by signature
    # and audience verification above, including:
    #   - Ensure that `claim["email"]` is equal to the expected service
    #     account set up in the push subscription settings.
    #   - Ensure that `claim["email_verified"]` is set to true.

    claims.push claim
  rescue Google::Auth::IDTokens::VerificationError => e
    puts "VerificationError: #{e.message}"
    halt 400, "Invalid token"
  end

  message = JSON.parse request.body.read
  payload = Base64.decode64 message["message"]["data"]

  messages.push payload
end

위 코드 샘플에 사용된 환경 변수 PUBSUB_VERIFICATION_TOKEN에 대한 상세 설명은 Pub/Sub 메시지 작성 및 응답을 참조하세요.

이 웹사이트용 Google 로그인 가이드에서 Bearer JWT 유효성을 검사하는 방법의 추가 예시를 확인할 수 있습니다. JWT 검증에 도움이 되는 클라이언트 라이브러리 목록을 포함하여 OpenID Connect 가이드에서 OpenID 토큰에 대한 광범위한 개요를 확인할 수 있습니다.

다른 Google Cloud 서비스에서 인증

Cloud Run, App Engine, Cloud Functions는 Pub/Sub에서 생성한 토큰을 확인하여 Pub/Sub에서 HTTP 호출을 인증합니다. 유일하게 필요한 구성은 호출자 계정에 필요한 IAM 역할을 부여하는 것입니다.

이러한 서비스의 여러 사용 사례는 다음 가이드와 튜토리얼을 참조하세요.

Cloud Run:

App Engine:

Cloud Functions:

  • HTTP 트리거: push 인증 서비스 계정에는 Pub/Sub push 요청을 함수에 대한 HTTP 트리거로 사용하려는 경우 함수를 호출하려면 roles/cloudfunctions.invoker 역할이 있어야 합니다.
  • Google Cloud Pub/Sub 트리거: Pub/Sub 트리거를 사용하여 함수를 호출하면 IAM 역할 및 권한이 자동으로 구성됩니다.

메시지 전송 관리

메시지 전송 중지 및 재개

Pub/Sub가 push 엔드포인트로 요청을 보내지 않도록 일시적으로 중단하려면 구독을 pull로 변경합니다. 변경사항이 적용되는 데 몇 분 정도 걸릴 수 있습니다.

push 전달을 재개하려면 URL을 유효한 엔드포인트로 다시 설정하세요. 전달을 영구적으로 중단하려면 구독을 삭제해야 합니다.

push 백오프

푸시 구독자가 부정 확인을 너무 많이 전송하면 Pub/Sub에서 푸시 백오프를 사용해 메시지를 전송하기 시작할 수 있습니다. Pub/Sub는 푸시 백오프를 사용할 때 미리 정해진 시간 동안 메시지 전송을 중지합니다. 이 시간 범위는 100밀리초~60초입니다. 이 시간이 지나면 Pub/Sub에서 메시지를 다시 전송하기 시작합니다.

푸시 백오프 작동 방식

푸시 백오프는 지수 백오프 알고리즘을 사용하여 메시지 전송 사이에 사용되는 Pub/Sub 지연을 결정합니다. 이 시간은 푸시 구독자가 전송하는 부정 확인 수를 기준으로 계산됩니다.

예를 들어 push 구독자가 초당 5개의 메시지를 수신하고 초당 1개의 부정 확인을 보내면 Pub/Sub는 약 500밀리초마다 메시지를 전송합니다. 또는 푸시 구독자가 초당 부정 확인 5개를 보내면 Pub/Sub는 30~60초마다 메시지를 전달합니다.

푸시 백오프에 대한 다음 사항을 고려하세요.

  • 푸시 백오프는 사용 설정하거나 중지할 수 없습니다. 지연을 계산하는 데 사용된 값도 수정할 수 없습니다.
  • 푸시 백오프는 다음과 같은 경우 트리거됩니다.
    • 부정 확인이 수신되었습니다.
    • 메시지 확인 기한이 만료되었습니다.
  • 푸시 백오프가 구독의 모든 메시지(전역)에 적용됩니다.

전달 속도

Pub/Sub는 느린 시작 알고리즘을 사용하여 동시 push 요청 수를 조정합니다. 동시에 허용되는 최대 push 요청 수는 push 범위에 해당됩니다. push 범위는 전송 성공 시 증가하고 실패 시 감소합니다. 시스템은 작은 한 자릿수 창 크기로 시작합니다.

구독자가 메시지를 확인하면 기간이 기하급수적으로 증가합니다. 구독자가 메시지를 99% 넘게 확인하고 푸시 요청 지연 시간이 평균 1초 미만인 구독의 경우 푸시 기간을 충분히 확장하여 모든 게시 처리량을 처리할 수 있어야 합니다.

push 요청 지연 시간에는 다음이 포함됩니다.

리전당 3,000개의 미해결 메시지가 push되면 push 엔드포인트가 너무 많은 메시지를 수신하지 못하도록 기간이 선형적으로 증가합니다. 평균 지연 시간이 1초를 초과하거나 구독자가 요청의 99% 미만을 확인하면 범위가 3,000개의 미해결 메시지의 하한으로 감소합니다.

push 전송을 모니터링하는 데 사용할 수 있는 측정항목에 대한 자세한 내용은 push 구독 모니터링을 참조하세요.

할당량 및 한도

push 구독에는 할당량과 리소스 한도가 적용됩니다.