はじめに
こんにちは。tosshyと申します。個人的にGoogle Cloud Pub/Subを使う機会があったのでこの機に調べた情報を自分なりにまとめます。
今回はGoogle Cloud Pub/Subの概要とこのサービスを使うことで何が嬉しいのかにフォーカスします。
Cloud Pub/Subとは
Pub/Subとは、サービス間で非同期にメッセージをやり取りするためのメッセージングサービスです。
単純に1対1のサービスを繋ぐ用途だけでなく1対多、多対1、多対多のバリエーションもサポートしています。
複数の送信側が送ったメッセージを、複数の受信側が受け取れます。
図中のトピックやサブスクリプションといった登場人物は、次回詳しく扱います。
出典: Pub/Sub サービスの概要（CC BY 4.0）
Pub/Subは何を解決するのか
公式の動画の例がわかりやすかったので、それをもとに整理します。
Pub/Subがない世界
動画では、Cat-OutというECサイトが例として挙げられています。
注文・梱包・発送・通知の4つのサービスからなるマイクロサービス構成です。
各サービスは非同期に通信を行います。メッセージを送った側は相手の処理完了を待たず、送りっぱなしで自分の処理を終えます。
具体的には、以下の3つのやり取りが発生します。
- 注文が確定したとき: 注文サービス → 梱包サービス・通知サービス
- 梱包が完了したとき: 梱包サービス → 発送サービス・通知サービス
- 発送が完了したとき: 発送サービス → 通知サービス
愚直に設計したらあるあるの構成です。しかしこの構成にはいくつか問題があります。
複雑性
メッセージをやり取りする関係が多すぎて、複雑化しています。
サービスが増えるほど、繋ぎ先の組み合わせは急激に増えていきます。
耐障害性
あるサービスに障害が起きている時、送信元のサービスはメッセージの送信をリトライし続け、共倒れになるかもしれません。
また、リトライを諦め、メッセージのロストが起きる可能性があります。
一時的に保存してリトライするなど工夫が必要です。
拡張性
新しく全体を分析するサービスを追加したくなったとき、既に動いている全てのサービスに手を入れることになります。
注文・梱包・発送のそれぞれに分析サービスへの送信を追加し、さらに分析サービス側は全サービスからのメッセージを受けるAPIを用意しなければいけません。
スケーラビリティ
あるサービスをスケールアウトさせたいとなった時、そのサービスの前段にロードバランサが必要になります。メッセージを受け取るサービスの数だけ用意することになります。
しかもロードバランサは流量を振り分けるだけで、溜めてはくれません。受信側の処理が追いつかなければ、あふれた分はエラーとして送信元に返ります。結局、送信元がリトライやバックオフを抱えることになります。
これらが同時に襲ってくると考えるだけでも悪夢ですね。
Pub/Subがあるとどうなる
このシステムにPub/Subを導入してみましょう。
注文が確定したとき、梱包サービスと通知サービスに直接メッセージを送るのではなく、Pub/Subにメッセージを送信します。
同じように梱包サービスと発送サービスもPub/Subにメッセージを送信します。
受信側は、Pub/Subから配信されるのを待つか、自分からPub/Subに取りに行くかのどちらかでメッセージを受け取ります。
複雑性
メッセージを送る側は、誰が受け取るのかを知らなくてよくなります。
注文サービスが気にするのはPub/Subにメッセージを送ることだけで、その先に梱包サービスがいるのか通知サービスがいるのか、何個いるのかを意識する必要はありません。
各サービスが繋がる相手はPub/Subだけになります。
サービスが1つ増えても、増える線は1本だけです。
耐障害性
あるサービスが落ちていても、送信元はPub/Subにメッセージを渡した時点で自分の仕事を終えられます。
落ちている相手にリトライを繰り返して共倒れになることはありません。
メッセージはデフォルトで7日間Pub/Subに保持されるので、その間に復旧すれば取りこぼさずに受け取れます。
永続化やリトライの仕組みを自前で用意する必要はありません。
拡張性
すでに各サービスはPub/Subにメッセージを送っているので、分析サービスはそれを受け取るようにするだけで済みます。
既存のサービスには一切手を入れません。
スケーラビリティ
受け取る側を増やしたいときは、Pub/Subから受け取るインスタンスを増やすだけです。
Pub/Subが振り分けてくれるので、ロードバランサを自分で用意する必要はありません。
処理が追いつかない間、メッセージはPub/Subに溜まっていきます。
送信元にエラーが返ることはないので、受け取る側の遅れが注文フローに波及することもありません。
おわりに
今回は主に動画をみながらPub/Subがもたらした恩恵にフォーカスして自分の理解をまとめました。
次回はPub/Subの中身や、Pub/Subにメッセージを送る・もらう点についてもう少し踏み込みます。