Google Cloud Pub/Sub とは

Google Cloud Pub/Sub は、エンタープライズ メッセージ指向ミドルウェアが持つ拡張性、柔軟性、および信頼性をクラウドにもたらします。送信者と受信者を分離する多対多で非同期のメッセージングを提供することで、独立して作成されたアプリケーション間で安全かつ高可用性が確保された通信を行えるようにします。Google Cloud Pub/Sub は、Google Cloud Platform や外部にホストされているシステムをデベロッパーがすばやく統合するのに役立つ、低レイテンシで耐久性のあるメッセージングを提供します。

パブリッシャー アプリケーションによって、メッセージが作成され、トピックに送信されます。サブスクライバー アプリケーションによって、トピックに対するサブスクリプションが作成され、それからメッセージが受け取られます。通信は 1 対多(ファンアウト)、多対 1(ファンイン)、および多対多にすることができます。

一般的なシナリオ

Google Cloud Pub/Sub に関するいくつかの一般的なユースケースを以下に示します。

  • ネットワーク クラスタでの負荷のバランス調整。 たとえば、Google Compute Engine インスタンスなど、複数の作業者間で、タスクの大規模なキューを効率的に分配できます。
  • 非同期ワークフローの実装。 たとえば、順序処理アプリケーションによってトピックに順序を設定し、そこから 1 人以上の作業者によって処理できるように設定できます。
  • イベント通知の配布。 たとえば、ユーザーのサインアップを受け入れるサービスによって、新規ユーザーが登録するたびに通知を送信したり、ダウンストリーム サービスでイベントの通知を受け取るようにサブスクライブしたりすることができます。
  • 分散キャッシュの更新。 たとえば、アプリケーションで無効なイベントをパブリッシュし、変更されたオブジェクトの ID を更新できます。
  • 複数のシステムへのログイン。 たとえば、Google Compute Engine インスタンスによってモニタリング システムにログを書き込み、後の照会などのためにデータベースに書き込むことができます。
  • さまざまなプロセスまたはデバイスからのデータ ストリーミング。 たとえば、居住センサーによって、クラウドにホストされているバックエンド サーバーにデータをストリーミングできます。
  • 信頼性の向上。 たとえば、単一ゾーンの Compute Engine サービスによって、一般的なトピックをサブスクライブしたり、ゾーンまたは領域からリカバリすることで、追加ゾーンで操作できます。

Benefits and features

  • 統合メッセージング: 単一プロダクトで、永続的で低レイテンシな配信を提供
  • グローバルなプレゼンス: 世界中のどこで提供されているサービスにも接続
  • 柔軟な配信サービス: プッシュとプルの両方の形式のサブスクリプションを提供
  • データの信頼性: ストレージの複製と、最低 1 回のメッセージ配信を保証
  • エンドツーエンドの信頼性: 明示的なアプリケーション レベルの受信確認
  • データのセキュリティーと保護: 接続時と停止時にデータを暗号化
  • フロー制御: Pub/Sub システムによって動的なレート制限を実施
  • シンプル: 使いやすい REST/JSON API

Pub/Sub の概念とメッセージ フロー

次に、Pub/Sub システムの概念と、それらの間をメッセージがどのようにフローするかについて簡単に説明します。

  1. 「パブリッシャー」アプリケーションは Google Cloud Pub/Sub サービスで「トピック」を作成し、「メッセージ」をトピックに送信します。メッセージには、ペイロードと、そのペイロードのコンテンツを説明するオプションの「属性」が含まれています。
  2. メッセージは、サブスクライバーによって配信され、確認応答があるまで、「メッセージ ストア」に保持されます。
  3. Pub/Sub サービスは、トピックから、そのすべてのサブスクリプションに、個別にメッセージを転送します。各サブスクリプションは、Pub/Sub がメッセージをサブスクライバーが選択したエンドポイントに「プッシュ」するか、サブスクライバーがメッセージをサービスから「プル」することで、メッセージを受け取ります。
  4. サブスクライバーは保留中のメッセージをそのサブスクリプションから受け取り、Pub/Sub サービスに対してそれらへ個別に確認応答します。
  5. サブスクライバーからメッセージへの確認応答があると、サブスクライバーのメッセージ キューからメッセージは削除されます。

パブリッシャーとサブスクライバーのエンドポイント

パブリッシャーになりうるのは、googleapis.com に HTTPS リクエストを行えるアプリケーションです。たとえば、App Engine アプリ、Google Compute Engine または他のサードパーティー ネットワークにホスティングされているウェブサービス、デスクトップやモバイル デバイスにインストールされているアプリ、さらにはブラウザもパブリッシャーにすることができます。

プル サブスクライバーは、googleapis.com に HTTPS リクエストを行えるアプリケーションにすることもできます。

現在、プッシュ サブスクライバーは、HTTPS を介した POST リクエストを受け入れられる Webhook エンドポイントにする必要があります。

データモデル

リソースのタイプとモデル

次に、Pub/Sub API によって使用されるオブジェクトのタイプを示します。トピックとサブスクリプションが、REST コレクションとして公開される唯一のリソースタイプです。

トピック
パブリッシャーによるメッセージの送信先となる、名前付きのリソース。
サブスクリプション
単一の特定のトピックから、サブスクライブするアプリケーションに配信されるメッセージのストリームを示す、名前付きのリソース。サブスクリプションとメッセージ配信体系の詳細については、サブスクライバー ガイドをご覧ください。
メッセージ
パブリッシャーがトピックに送信し、最終的にはサブスクライバーに配信される、データと属性(任意)の組み合わせ。
メッセージ属性
メッセージにパブリッシャーが定義できるキーと値のペア。たとえば、キー iana.org/language_tag と値 en をメッセージに追加して、英語を使用するサブスクライバーが読めるものとしてメッセージにマークを付けることができます。

リソース名

Pub/Sub のトピックとサブスクリプション名はプロジェクトにスコープ指定されている必要があります。形式は次のとおりです。

projects/project-identifier/collection/resource-name
  • collectionsubscriptions または topics にする必要があります。
  • project-identifier は、Google Cloud Platform Console から取得可能なプロジェクト ID にする必要があります。例: projects/myproject/topics/mytopic
  • resource-name は、文字で開始し、文字([A-Za-z])、数字([0-9])、ダッシュ(-)、下線(_)、ピリオド(.)、波形符号(~)、プラス記号(+)、またはパーセント記号(%)のみが含まれている必要があります。3~255 文字の長さにする必要があります。文字列 goog で開始することはできません。
この形式では、URL エンコーディングを使用して、リソース名に特殊文字を含めることができます。たとえば、mi-tópico というトピック名は Cloud Pub/Sub では無効なリソース名ですが、mi-t%C3%B3pico のようにエンコーディングして有効な名前にすることができます。

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

フィードバックを送信...