概要

Pub/Sub を使用すると、アプリケーションで効率的なメッセージ キューを利用できます。 このサービスはさまざまな Google Cloud サービスと互換性があり、このラボでは、Cloud Run との統合方法を学びます。

このラボは、サーバーレス インフラストラクチャを使用してお客様のユースケースを解決することを題材にしています。このラボは、技術的な問題を解決するため、大きく 3 つのセクションに分かれています。

• 状況の概要
• 要件の整理
• 実用最小限の製品を開発する

目標

このラボでは、次のタスクの実行方法を学びます。

• Cloud Run API を有効にする。
• マイクロサービスを Cloud Run にデプロイする。
• Pub/Sub トピックを作成する。
• Pub/Sub サブスクリプションから Cloud Run サービスを呼び出す。

前提条件

これらのラボは、Google Cloud に関する中級レベルの知識を前提としています。必要な手順はコンテンツで説明されていますが、以下のプロダクトのいずれかに慣れていれば、より理解が深まります。

• Pub/Sub
• Cloud Run

設定と要件

[ラボを開始] ボタンをクリックする前に

注: 以下の説明をお読みください。

ラボには時間制限があり、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

この Google Skills ハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを実施できます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

必要なもの

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）
• ラボを完了するために十分な時間

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、ラボでは使用しないでください。 注: Pixelbook を使用している場合は、このラボをシークレット ウィンドウで実施してください。

ラボを開始してコンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側のパネルには、このラボで使用する必要がある一時的な認証情報が表示されます。

   

2. ユーザー名をコピーし、[Google Console を開く] をクリックします。 ラボでリソースが起動し、別のタブで [アカウントの選択] ページが表示されます。

   注: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

3. [アカウントの選択] ページで [別のアカウントを使用] をクリックします。[ログイン] ページが開きます。

   

4. [接続の詳細] パネルでコピーしたユーザー名を貼り付けます。パスワードもコピーして貼り付けます。

注: 認証情報は [接続の詳細] パネルに表示されたものを使用してください。Google Skills の認証情報は使用しないでください。請求が発生する事態を避けるため、Google Cloud アカウントをお持ちの場合でも、このラボでは使用しないでください。

5. その後次のように進みます。

• 利用規約に同意します。
• 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
• 無料トライアルには登録しないでください。

しばらくすると、このタブで Cloud コンソールが開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。

Google Cloud Shell の有効化

Google Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。

Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

   

2. [続行] をクリックします。

環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

• 次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

Credentialed accounts: - @.com (active)

出力例:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project =

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: gcloud ドキュメントの全文については、 gcloud CLI の概要ガイド をご覧ください。

状況の概要

このラボでは、Critter Junction の開発チームが要件に見合った Pub/Sub の活用方法を検討するのを支援します。チームは、アプリケーション内でキュー処理を効率的に行う方法を探りたいと考えています。

要件の整理

Critter Junction のチームには、Google Cloud 上に構築された一般公開のウェブアプリケーションと複数のマイクロサービスがあります。マイクロサービス間の通信は重要であり、各アプリケーション コンポーネント間で復元力のあるメッセージング形式を確立する必要があります。

開発チームのこれまでの試みは、マイクロサービス間で相互に多くの情報を把握する必要があったため（高い結合度）、成功しませんでした。また、サービスが一時的に利用できなくなった場合には、メッセージが失われていました。

チームには、システムに追加のサービス依存関係を導入することなく（低い結合度）、一定の復元力を備えたソリューションが必要です。Critter Junction とその直面している課題について理解できたところで、ソリューションの主要な評価基準に優先順位を付けてみましょう。

Critter Junction の優先事項の整理

主要なユースケースと優先事項を明らかにするため、まず Critter Junction のステークホルダーと話し合いを行いました。 その結果は以下のとおりです。

Ref	ユーザー ストーリー
1	リード開発者として、メッセージングの復元力を確保し、手動介入なしでサービス オペレーションを復元できるようにしたいと考えています。
2	プログラム マネージャーとして、サービスがシームレスにスケーリングできるようにしたいと考えています。そうすれば、トランザクション負荷の増加によってシステムが不安定になることはありません。
3	オペレーション リードとして、重要なメンテナンス作業からスタッフを再割り当てする必要がないように、サービスを管理したいと考えています。

チームリーダーとの話し合いから、次の大まかなタスクが定義されました。

Ref	完了の定義
1	サービス間通信用の非同期コンポーネントを確立する。
2	ソリューションに実証済みのスケーラビリティを実装する。
3	サービスは人手による監視なしで稼働できる必要がある。

Critter Junction のチームは、迅速に実装できるソリューションを定義したいと考えています。要件を考慮して、開発チームは選択肢を以下に絞り込みました。

• Pub/Sub
• Cloud Tasks

詳しくは、Pub/Sub と Cloud Tasksをご覧ください。

プロダクト	ユースケース	選択肢
Pub/Sub	「実行に対する制御がある程度制限されてもよい、汎用的なイベントデータの取り込みと配信パターンに適しています。」
Cloud Tasks	「タスクのプロデューサーが特定の Webhook またはリモート プロシージャ コールの実行のタイミングを延期または制御する必要があるユースケースに適しています。」

要件を検討した結果、必要なのはプッシュベースの配信パターンに限られるため、開発チームは Pub/Sub を選択します。以下のアーキテクチャ概要図は、検証対象となる実用最小限の製品（MVP）の概要を示しています。

提案されたソリューションでは、Pub/Sub を使用してサービス間の非同期メッセージを処理します。

タスク 1. Pub/Sub API が有効になっていることを確認する

必要な API にアクセスできるようにするには、Pub/Sub API を再度有効にします。

1. Google Cloud コンソールのナビゲーション メニュー（）で、[API とサービス] の下にある [ライブラリ] をクリックします。

2. 検索ボックスに「Pub/Sub」と入力します。

3. 検索結果の [Cloud Pub/Sub API] をクリックします。

4. [管理] をクリックします。

5. [API を無効にする] をクリックします。確認を求められたら、[無効にする] をクリックします。

6. [Cloud Pub/Sub API とその依存 API を無効にしますか？] と表示されたら、[確認] をクリックします。

7. API を再度有効にするには、[有効にする] をクリックします。

   API が再度有効になると、ページに API に関する情報が表示されます。

タスク 2. 実用最小限の製品（MVP）を開発する

Critter Junction には、Pub/Sub と統合する複数の Cloud Run サービスがあります。MVP を構築するには、次のタスクが必要です。

• プロデューサー サービスをデプロイする
• コンシューマー サービスをデプロイする
• サービス アカウントを作成する
• Pub/Sub トピックを作成する

プロデューサー サービスをデプロイする

Critter Junction は、外部に公開する store service をパブリック エンドポイントとして構成するよう指定しており、以下が要件として示されています。

タイプ	権限	説明
URL アクセス	--allow-unauthenticated	サービスを [公開] にする（認証されていないユーザーも閲覧可能）。
呼び出し権限	allUsers	サービスを誰でも呼び出し / トリガーできるようにする。

プロデューサーの store service は、注文を処理するために公共のインターネット経由の接続を受け入れます。 これを行うには、サービスで認証を必要とせず、誰でもトリガーできるようにする必要があります。

このサービスによって収集された情報は、バックエンドのコンシューマー サービスに渡されます。

Cloud Run で store service を構成してデプロイします。Cloud Shell で次のコマンドを実行します。

1. Cloud Run API を有効にして、シェル環境を構成します。

   gcloud services enable run.googleapis.com

2. LOCATION 環境変数を作成します。

   LOCATION={{{project_0.default_region|REGION}}}

3. コンピューティング リージョンを設定します。

   gcloud config set compute/region $LOCATION

4. store service をデプロイします。

gcloud run deploy store-service \ --image gcr.io/qwiklabs-resources/gsp724-store-service \ --region $LOCATION \ --allow-unauthenticated

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Run の store service をデプロイする

デプロイが完了すると、store service がインターネット経由で一般公開されます。

コンシューマー サービスをデプロイする

開発チームは、プライベート エンドポイントでアクセスできる order service も構成する必要があります。 store service とは異なり、order service はインターネット経由で一般公開されることを想定しておらず、適切な権限を持つアカウントによってのみ呼び出される必要があります。

Cloud Run ベースのサービスの場合、これは次の設定を使用して実現できます。

タイプ	権限	説明
URL アクセス	--no-allow-unauthenticated	サービスを非公開にする（認証されたユーザーのみが閲覧可能）。
呼び出し権限 / ロール	Cloud Run 起動元	Cloud Run 起動元ロールを持つアカウントのみがサービスを呼び出せるようにする。

order service を構成してデプロイします。

gcloud run deploy order-service \ --image gcr.io/qwiklabs-resources/gsp724-order-service \ --region $LOCATION \ --no-allow-unauthenticated

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Run の order service をデプロイする

これで、認証されたアカウントのみがサービスにアクセスして呼び出すことができるようになりました。

Pub/Sub の概要

Pub/Sub は、イベントを処理するサービスとイベントを生成するサービスを切り離す非同期メッセージング サービスです。

Pub/Sub 基本コンセプト:

• トピック
• サブスクリプション
• メッセージ
• メッセージ属性

Pub/Sub を正常にデプロイするには、いくつかのオプションを事前に完了する必要があります。 Google Cloud コンソールでは、[ビッグデータ] メニュー オプションから Pub/Sub にアクセスできます。

フィールド	説明
トピック	パブリッシャーによるメッセージの送信先となる、名前付きのリソース。
サブスクリプション	単一の特定のトピックから、サブスクライブするアプリケーションに配信されるメッセージのストリームを示す、名前付きのリソース。サブスクリプションとメッセージ配信体系の詳細については、サブスクライバー ガイドをご覧ください。
メッセージ	パブリッシャーがトピックに送信し、最終的にはサブスクライバーに配信される、データと属性（オプション）の組み合わせ。
メッセージ属性	パブリッシャーがメッセージに設定できる Key-Value ペア。たとえば、キー iana.org/language_tag、値 en をメッセージに付加すれば、英語圏のサブスクライバー向けメッセージとして識別できるようになります。

Pub/Sub はさまざまなユースケースで使用できます。最も一般的なユースケースは次のとおりです。

ユースケース	例
ネットワーク クラスタでのワークロードのバランス調整	たとえば、Google Compute Engine インスタンスなど、複数のワーカー間で、タスクの大規模なキューを効率的に分配できます。
非同期ワークフローの実装。	たとえば、注文処理アプリケーションで発注をトピックに対して行い、そこから 1 つ以上のワーカーによって注文を処理するように設定できます。
イベント通知の配信。	たとえば、ユーザーからの登録を受け付けるサービスで、新規ユーザーが登録するたびに通知を送信することや、ダウンストリーム サービスがイベントの通知を受け取るようにサブスクライブすることができます。
分散キャッシュの更新。	たとえば、アプリケーションで無効なイベントをパブリッシュし、変更されたオブジェクトの ID を更新できます。
複数のシステムへのロギング。	たとえば、Google Compute Engine インスタンスでモニタリング システムにログを書き込み、後でデータベースにクエリしたりできます。
さまざまなプロセスまたはデバイスからのデータ ストリーミング。	たとえば、クラウドにホストされているバックエンド サーバーに人感センサーからデータをストリーミングできます。
信頼性の向上。	たとえば、シングルゾーンの Compute Engine サービスがゾーンやリージョンで発生した障害から回復できるようにするため、共通のトピックにサブスクライブして他のゾーンでもそのサービスを実行する方法があります。

タスク 3. Pub/Sub をデプロイする

プロデューサー（store service）とコンシューマー（order service）のサービスが正常にデプロイされたところで、Pub/Sub の主な機能を見ていきましょう。Pub/Sub を使用するには、次の 2 つのアクティビティが必要です。

• トピックを作成する
• サブスクリプションを作成する

トピックを作成する

非同期（push）イベントがトピックで作成されると、そのトピックをサブスクライブしているアプリケーションは、関連するメッセージを処理できるようになります。Pub/Sub を使用した push イベント処理は、Google Cloud でメッセージングを処理するためのスケーラブルな方法です。

新しい Pub/Sub トピックには次の値が設定されます。

フィールド	値
名前	ORDER_PLACED
暗号化	Google が管理する鍵

1. Pub/Sub でトピックを作成する。

gcloud pubsub topics create ORDER_PLACED 注: Pub/Sub を使用して送信されるメッセージは、送信時に base64 としてエンコードされ、受信時にデコードする必要があります。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Pub/Sub トピックを作成する

Pub/Sub トピックを作成したことで、メッセージを個別に保存し、堅牢に配信できるようになりました。

サブスクリプションは、次のタスクで作成します。

タスク 4. サービス アカウントを作成する

Pub/Sub メッセージを Cloud Run サービスに配信するには、Pub/Sub サブスクリプションが必要です。サブスクリプションは、適切な権限を持つサービス アカウントを使ってサービスを呼び出せる必要があります。このラボでは、サービス アカウントを使ったサブスクリプションによってコンシューマーの order service が呼び出されます。

この機能を実現するには、次の作業が必要です。

• サービス アカウントを作成する
• 起動元ロールの権限をサービス アカウントにバインドする

サービス アカウントの作成

認証されたアクセスを提供する新しいサービス アカウントを作成します。

1. Order Initiator という新しいサービス アカウントを作成します。

   gcloud iam service-accounts create pubsub-cloud-run-invoker \ --display-name "Order Initiator"

2. サービス アカウントが作成されていることを確認します。

   gcloud iam service-accounts list --filter="Order Initiator"

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。

サービス アカウントを作成する

この時点で、Order Initiator サービス アカウントが利用可能になります。ただし、ロールや権限は割り当てられていません。IAM 権限を割り当てるには、ロール権限をサービス アカウントに適用またはバインドする必要があります。

ロールの権限をバインドする

Cloud Run でサービスを呼び出すために使用するアカウントに権限をバインドするには、次の情報が必要です。

カテゴリ	説明
サービス名	呼び出されるデプロイ済みサービスの名前。
メンバー	ロールの権限を付与するアカウント。
リージョン	サービスがデプロイされているリージョン。
プラットフォーム	プラットフォームのタイプ（Cloud Run Managed、Cloud Run for Anthos、Cloud Run for VMware）

1. order service で、サービス アカウントを Cloud Run 起動元ロールにバインドします。

   gcloud run services add-iam-policy-binding order-service --region $LOCATION \ --member=serviceAccount:pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com \ --role=roles/run.invoker --platform managed

   これで、新しいサービス アカウントに Cloud Run サービスを呼び出す権限が付与されました。

2. プロジェクト番号を格納する環境変数を作成します。

   PROJECT_NUMBER=$(gcloud projects list \ --filter="qwiklabs-gcp" \ --format='value(PROJECT_NUMBER)')

3. プロジェクトのサービス アカウントでトークンを作成できるようにします。

   gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \ --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com \ --role=roles/iam.serviceAccountTokenCreator

タスク 5. Pub/Sub サブスクリプションを作成する

このタスクでは、Pub/Sub サブスクリプションを作成し、新しいサービス アカウントを使用するように構成します。

1. order service のエンドポイントを格納する環境変数を作成します。

   ORDER_SERVICE_URL=$(gcloud run services describe order-service \ --region $LOCATION \ --format="value(status.address.url)")

2. サブスクリプションを作成し、order service にバインドします。

   gcloud pubsub subscriptions create order-service-sub \ --topic ORDER_PLACED \ --push-endpoint=$ORDER_SERVICE_URL \ --push-auth-service-account=pubsub-cloud-run-invoker@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 サブスクリプションを作成する

タスク 6. アプリケーションをテストする

アプリケーションをテストするには、サンプル JSON ペイロードを store service に送信します。

1. 次の内容の test.json というファイルを作成します。nano、vi、Cloud Shell エディタなど、任意のエディタを使用できます。

   { "billing_address": { "name": "Kylie Scull", "address": "6471 Front Street", "city": "Mountain View", "state_province": "CA", "postal_code": "94043", "country": "US" }, "shipping_address": { "name": "Kylie Scull", "address": "9902 Cambridge Grove", "city": "Martinville", "state_province": "BC", "postal_code": "V1A", "country": "Canada" }, "items": [ { "id": "RW134", "quantity": 1, "sub-total": 12.95 }, { "id": "IB541", "quantity": 2, "sub-total": 24.5 } ] }

2. store service のエンドポイントを格納する環境変数を作成します。

   STORE_SERVICE_URL=$(gcloud run services describe store-service \ --region $LOCATION \ --format="value(status.address.url)")

3. マイクロサービス間の通信をテストし、注文 ID を生成するには、store service にメッセージを投稿します。

   curl -X POST -H "Content-Type: application/json" -d @test.json $STORE_SERVICE_URL

   コマンドの出力は、注文が正常に作成されたことを示しており、次のようになります。

   {"status":"success","order_id":"6pa5mmh"}

store service

store service（公開エンドポイント）は Pub/Sub を使用して、order service（非公開エンドポイント）に情報を送信します。

1. Google Cloud コンソールのナビゲーション メニュー（）で、[Cloud Run] をクリックします。

2. store-service へのリンクをクリックします。

3. サービスログを表示するには、[ログ] をクリックします。store service のログを確認して、生成された注文 ID を表示します。

4. ログフィルタ ORDER ID を追加して、store service によって生成された ID を確認します。

   

order service

order service は、store service から Pub/Sub で渡されたメッセージを受信します。

1. order service のログをチェックして、JSON データが正常に転送されたことを確認します。

2. ログフィルタ Order Placed を追加して、order service に渡された生成済みの注文 ID を確認します。

   

Critter Junction は、Pub/Sub を活用するためにソリューションを更新しました。 以下のアーキテクチャ概要図は、デプロイされたソリューションの概略を示しています。

これで、Google Cloud に Pub/Sub をデプロイして、Cloud Run サービス間で非同期通信を行うことができました。

お疲れさまでした

このラボでは、Google Cloud インフラストラクチャで Cloud Run サービスを Pub/Sub と統合する方法を学びました。 具体的には、以下の方法について学習しました。

• Cloud Run にサービスをデプロイする
• 適切なロールと権限を持つサービス アカウントを作成する
• Pub/Sub トピックを定義する
• Pub/Sub サブスクリプションをサービス アカウントにバインドする

次のステップと詳細情報

プロジェクト内でこれらのプロダクトを使用する方法について詳しくは、Serverless Expeditions の動画シリーズをご覧ください。

• Cloud Run
• Cloud Tasks
• Cloud Functions

マニュアルの最終更新日: 2024 年 2 月 20 日

ラボの最終テスト日: 2024 年 2 月 20 日

Copyright 2026 Google LLC All rights reserved. Google および Google のロゴは、Google LLC の商標です。その他すべての社名および製品名は、それぞれ該当する企業の商標である可能性があります。