Pub/Subを使った非同期処理

ツール導入前の課題

enechainではmicroservicesアーキテクチャを導入しています。 microserviceとプロダクトアプリケーションが直接API連携を行っている場合にAPIリクエストがエラーとなると、両方のシステムの状態に齟齬が発生する可能性があります。 この齟齬を解消するために、運用によるリカバリ処理などが必要なことが課題となっていました。

どのような状態を目指していたか

一時的なエラーの場合にはシステム的に自動でリカバリされる状態を目指していました。 リカバリ時に手動の対応が必要になると運用コストが高いため、人が介在しなくても良い運用を目標にしていました。

• Cloud Tasks

• マネージドなサービスであること
• サービス同士を疎結合な作りにできること
• 流量制限ができること

今回、Pub/Subを採用した理由は、Cloud Tasksと比較して以下の点が要件により適合していたためです。

• ファンアウトに対応している ：一つのトピックから複数のサブスクライバーがメッセージを受信できるため、効率的に全プロダクトにメッセージが配信できます。

• Pull型に対応している：サブスクライバーが必要なタイミングでメッセージを取得するPull型を使用することで、HTTPのエンドポイントを公開しているサービス以外でもメッセージを受け取ることができます。HTTP経由でのオートスケールを有効活用したPush型を扱いたい場合にはPush型で問題ありませんが、今回のケースではリアルタイム性よりもエンドポイントへの負荷をかけたくなかったのと、順列制御を行いたいためこちらが一つの決め手になりました。

Cloud Tasksでもこれらの要件を満たすことは可能ですが自前の実装を行わないといけません。 今回の要件においてはファンアウトの機能が欲しかったため、Pub/Subが最適な選択肢であると判断しました。

改善したかった課題はどれくらい解決されたか

システムとして疎結合なものにできて、サブスクライブするサービスが一時的にAPIに繋がらないような状態になってもパブリッシャー側はその影響を受けないようにすることができました。

どのような成果が得られたか

一時的なエラーが発生してもリトライで復旧できて、サービス間の連携が完全に疎結合化できました。サービスの停止を行った時にお互いの状態を気にしなくて良くなるという効果を得ています。

2021年3月にメッセージスキーマがリリースされるまではメッセージの型がフリーフォーマットであったことによりデータ整合性を保つことがコード依存になってしまい、データ構造を変更するにはパブリッシャーとサブスクライバーでコードの変更を同時に行わなければいけませんでした。

メッセージスキーマの登場により送信されるメッセージのバリデーションが可能になったことでメッセージの構造が保証された状態で受け取れるようになりました。我々はPub/Sub導入時にメッセージスキーマを利用しなかったことで構造が暗黙知になってしまい苦労しました。メッセージスキーマを最初から導入しておけば、各チームへの展開が楽になったと思います。

Pub/Subは疎結合なイベントドリブン型のシステムを構築するための非常に優れたツールです。しかし、その特性を十分に理解した上で、導入が最適かどうかを検討することが重要です。例えば、Ack/Nack（確認応答）のレスポンスに最大で10分の遅延が発生する可能性があることや、メッセージの重複が起こる点は考慮する必要があります。

そのため、長時間にわたる複雑な処理を要する場合には、Pub/Sub以外のツールを選択したほうが効率的な場合があります。一方で、短時間で終了する処理や非同期通信が求められる場面では、Pub/Subは有力な選択肢となります。

また、膨大なログ収集を行うなど大量のメッセージを送信するシステムを構築する場合には最適解ではないことがあるため、Pub/Sub以外のメッセージングサービスも検討する価値があります。