はじめに

はじめまして。2023年1月キャリア入社の添田です。1月から参画させていただいているプロジェクトでGoogle Cloud PlatformのPubSub(以降PubSub)を使用した開発を行うことになり、苦戦した部分が多々ありました。そこで今回はPubSubについて噛み砕いて説明していきます。今後PubSubを使用した開発をする方の助けになれればと思います。

(Google Cloud Platform PubSubについての公式ドキュメントはこちらです。)

メッセージについて
メッセージとは、異なるコンポーネントや、アプリケーションに対して送信するデータのことです。要は非同期的に処理させたいデータをメッセージとして作成します。最終的にpublishする際にはメッセージの形式をバイト配列にする必要があります。(publishに関しては後ほど解説します)
publisherについて
publisherとは、メッセージを送信する役割をもつアプリケーションのことを指します。publisherがメッセージを送信することをpublishする、と言います。
subscriberについて
subscriberとは、メッセージを受信する役割を持つアプリケーションのことを指します。つまり、publisherからpublish(送信)されたメッセージを受け取り、非同期的に受け取り、それに応じた処理を行うアプリケーションと言えます。
topicについて
topicとは、PubSubのコンポーネントでありメッセージの送信元であるpublisherと、メッセージの受信先であるsubscriberを結ぶ中継地点と言えます。つまり、publisherはsubscriberへ直接メッセージをpublishするのではなく、topicにメッセージをpublishしています。topicについては特に重要な概念となります。
subscriptionについて
subscriptionとはPubSubのコンポーネントでありtopicからのメッセージの受信先と言え、subscriptionからsubscriberへのメッセージの配信が行われます。また、topicからメッセージを受信するsubscriptionは必ずしも１つである必要はなく、複数のsubscriptionを作成し１つのメッセージに対し、複数のsubscriberにメッセージを一度に配信することで全く違う処理を同時に非同期的に行うことが可能です。
確認応答（Ack）について
subscriberがメッセージを正常に受け取ったらsubscriptionに対して正常にメッセージを受信したことを通知します。確認応答を受信すると正常にメッセージが受信されたと見なされ、そのメッセージはtopicから削除されます。また、subscriberがメッセージの処理に失敗した場合、Nack（Negative Acknowledgement）を通知することができます。Nackが通知された場合、再度メッセージの配信を行います。この辺りの詳細な設定もsubscriptionで決めることが可能です。

3. 実際の処理の流れの解説

上図がPubSubの基本的な処理の流れになっています。

流れとしては以下のような流れとなります。

1. publisherがメッセージを作成、topicへpublishする
1. publishされたメッセージはMessageStorageへ格納される（MessageStorageについては説明していませんが、要はメッセージの一時保存場所のイメージです）
1. topicにpublishされたメッセージはsubscriptionの設定内容に応じてsubscriberへ配信されます。
4~5. subscriberがメッセージを正常に受信したことをsubscriptionへ通知します（Ackされる）

また、下図のような1対N・N対1のような使い方をすることも可能です。

例えば下図のpublisher Cから複数のsubscriberへメッセージを配信するユースケースは以下のようなシナリオが考えられると思います。

ECサイトの注文管理システムの注文通知機能
1. Publisher Cが注文データをメッセージとしてpublish
2. PublishされたメッセージをTopic Cが受信
3. Topic cがSubscription YCとSubscription ZCへメッセージを配信
4. Subscriber YとSubscriber Zがメッセージを受信
5. Subscriber Yはユーザへの注文確定のメール通知を行う・Subscriber Zは管理者ダッシュボードへの注文通知を表示する

上記はあくまでPubSubを用いた一例ですが、このように異なるサービスやシステム間での効率的な処理が可能になるのがPubSubの凄さだと思っています。

4. PubSubを使用したユースケース考えてみた

用語の解説から実際の処理の流れの解説までできたところで、今度はユースケースを考えてみます。

例えば下図のような証券会社のシステムがあったとします。

このシステムは10年以上前に構築されたもので以下のような課題がありました。

課題①：各種取引商品データ更新の遅延
- 10年前と比較して取引商品が増えたため、更新処理時間が増加していた。
課題②：システム依存度の高さ
- 現行のシステムではデータプロパイダと直接的に連携していることにより、他のデータプロパイダの使用やシステムのアップグレードが非常に難しくなっていた。

下図のようにPubSubを導入することによってこれらの課題を解決することが可能です。（あくまで一例です）

課題①：各種取引商品データ更新の遅延
- 現行のシステムでは大量のデータを１つのシステムが処理をしていたが、データをメッセージとして受け取り複数のsubscriberで並列的に処理をさせる（データを表示するsubscriber、データを登録するsubscriberなどで役割を分ける）ことで効率的に処理を行う。
課題②：システム依存度の高さ
- PubSubを介することでデータプロパイダと証券会社システム間は疎結合な関係になることで他のデータプロパイダの使用やアップグレードが現行システムより容易になる。

5.まとめ

PubSubを理解するうえで必要な用語の解説からユースケースまで説明しました。

今回はPubSubの解説を、主にイベントドリブンなアーキテクチャで例えて解説しましたが、他にもリアルタイム分析や、マイクロサービスアーキテクチャの実現など様々な用途に使用することが可能です。

私は現在のプロジェクトで初めてPubSubを触りましたが、とても感動しました。

6.さいごに

今回はPubSubの基礎的な部分とユースケースの解説をさせていただきました。

Pull型配信やPush型配信、デッドレターキュー（DLQ）など、まだまだ解説できていない箇所がありますが、次回以降の投稿で解説していこうと思います。

GCP Pub/Subの概念をかみ砕いて説明してみた