Pub/Sub を使ってつまらない会議をなくし、システムをスケールアップさせましょう
Google Cloud Japan Team
※この投稿は米国時間 2021 年 12 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。
さて、モノリシック アプリケーションとはおさらばし、サービスにリファクタリングをしました。提供も早くなり、コードもわかりやすくなりました。しかし、サービス間のコミュニケーションの複雑さが、パフォーマンスにも悪影響を及ぼしています。さらに、新しいチームのインテグレーションのたびに、山ほどミーティングをしなければなりません。メッセージング システムによって確実に配信されるイベントに対して、サービスがパブリッシュとリアクションを行う非同期のコミュニケーションを検討する時期に来ています。
このモデルでは、サービスはイベントに対してコンピューティングを行い、それを Pub/Sub にパブリッシュするだけでいいのです。ダウンストリーム サービスのレイテンシや可用性の特性の違いに対応する必要はありません。実際のところ、それらについて知る必要さえありません。このため、インテグレーションに関するミーティングは不要になり、スケーリングが容易になります。各サービスやサービスチームは、分析やオペレーション データのインテグレーションを行っていても、即座の判断が必要なユーザー向けのアプリケーションを構築していても、時間に応じて役割を果たすことができます。
こういったことを可能にするにはもちろん、メッセージ サービスである Pub/Sub が利用可能で、信頼性があり、予測可能であるということを信頼できなければなりません。この記事では、Pub/Sub の概要と、その仕組みをご紹介します。
Pub/Sub には 2 つの種類があります。:
ほとんどのアプリケーションでデフォルトで用意されている、 「すべてひっくるめた」オプション。
サーバーレスで、必要に応じて自動スケーリングと自動プロビジョニングが可能。
地理的に関係なくイベントをパブリッシュし、サブスクリプションで受け取る機能を提供。
トピックごとに最大 1 万のサブスクライバー アプリを作成可能。パブリッシャーとサブスクライバーに対しそれぞれ独立した容量と請求方式を採用。
マイクロサービス間の通信に有用な push 型配信モデルをサポート。
信頼性よりも費用を重視した最適化。
Pub/Sub より最大 90% のコストダウンが可能。
容量管理が必要で、可用性のレベルは低め。
Pub/Sub の仕組み
パブリッシャー アプリケーションによってメッセージが作成されてトピックに送信され、サブスクライバー アプリケーションによってトピックに対するサブスクリプションが作成されてメッセージが受信されます。各メッセージは、サブスクライバーが十分にアクティブである限り、サブスクリプションごとに少なくとも 1 回は配信されることが保証されています。通信は 1 対多（ファンアウト）、多対 1（ファンイン）、多対多にできます。
Pub/Sub サービスでは、パブリッシャー アプリケーションによってトピックが作成され、そのトピックにメッセージが送信されます。メッセージには、ペイロードと、そのペイロードのコンテンツを説明するオプションの属性が含まれています。
このサービスでは、サブスクリプションの代わりに、パブリッシュされたメッセージが保持されるようにします。パブリッシュされたメッセージは、そのサブスクリプションからのメッセージを使用するサブスクライバーによって確認応答されるまで、そのサブスクリプションのために保持されます。
Pub/Sub が、トピックからそのすべてのサブスクリプションに個別にメッセージを転送します。
各サブスクリプションは、Pub/Sub がメッセージをサブスクライバーが選択したエンドポイントに push するか、サブスクライバーがメッセージをサービスから pull することで、メッセージを受け取ります。
サブスクライバーは、受信したメッセージごとに Pub/Sub サービスに確認応答を送信します。
このサービスは、確認済みのメッセージをサブスクリプションのメッセージ キューから削除します。
Pub/Sub の機能
グローバル ルーティング: 世界のどこからでも、トピックにメッセージをパブリッシュできます。低レイテンシの実現のため、最も近いリージョンに永続化されます。一方、任意のリージョンにデプロイされたサブスクライバーは、特別なことをしなくても、すべての公開拠点からのメッセージを受信することができます。
パーティションなしの順序指定配信: メッセージに同じ順序指定キーがあり、それが同じリージョンの場合、メッセージの順序指定を有効にすると、Pub/Sub サービスがメッセージを受信する順序でメッセージを受信できます。
デッドレター トピック: Pub/Sub サービスがメッセージの配信を試みてもサブスクライバーがそれを確認できない場合、Pub/Sub は配信不可能なメッセージをデッドレター トピックに転送し、後日配信を試みることができます。
シークと再生: メッセージの確認応答の段階を一括して変更する必要がある場合は、シークと再生機能を使えば可能です。
フィルタリング: メッセージの属性でメッセージをフィルタリングします。フィルタリングされたサブスクリプションからメッセージを受信すると、フィルタに一致するメッセージのみを受信できます。Pub/Sub は、フィルタに一致しないメッセージを自動的に確認応答します。
Pub/Sub のユースケース
ストリーム分析: ストリーム、バッチ、統合パイプラインのいずれを構築する場合も、分析と機械学習の基盤となるのはデータの取り込みです。Cloud Pub/Sub は、イベントデータの処理、保存、分析の過程で、イベントデータ用のシンプルかつ信頼性の高いステージング ロケーションを提供します。Cloud Dataflow と Cloud Pub/Sub を使用して、イベントの拡充、重複排除、順序付け、集計、ランディングを行います。Cloud Pub/Sub の耐久性のあるストレージを使用して、リアルタイム処理とバッチ処理を併用します。
非同期サービスのインテグレーション: Pub/Sub は、従来のサービス インテグレーションのためのメッセージング ミドルウェアとして、あるいは最新のマイクロサービスのためのシンプルなコミュニケーション メディアとして機能します。push サブスクリプションは、Cloud Functions、App Engine、Cloud Run のサーバーレス Webhook、Google Kubernetes Engine や Compute Engine のカスタム環境にイベントを配信します。Webhook を使用できない場合や、高スループットのストリームを効率よく処理する場合は、低レイテンシの pull 配信も利用できます。
Pub/Subの詳細については、ドキュメントをご覧いただくか、「Pub/Sub Made Easy（Pub/Sub を簡単に）」の動画シリーズをご覧ください。
#GCPSketchnote の詳細については、GitHub リポジトリをフォローしてください。同様のクラウド コンテンツについては、Twitter @pvergadia で発信しています。thecloudgirl.dev もぜひご覧ください。
- Google デベロッパー アドボケイトPriyanka Vergadia
- Google Cloud Pub/Sub プロダクト マネージャー Kir Titievsky
