Google Cloud でのサービス オーケストレーション
Google Cloud Japan Team
※この投稿は米国時間 2021 年 10 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
モノリシック アーキテクチャからマイクロサービスに移行することには、再利用性、スケーラビリティ、変更のしやすさといった、明確なメリットがあります。多くの場合、ビジネス上の問題は、複数のマイクロサービスを連携させることで解決します。この連携は、イベント ドリブン型のアーキテクチャに基づいており、コレオグラフィーとオーケストレーションという 2 つのアプローチで実現できます。
サービス コレオグラフィーとサービス オーケストレーション
サービス コレオグラフィー - サービス コレオグラフィーでは、各サービスは独立して動作し、イベントを通じて他のサービスと疎結合の状態で相互に作用します。疎結合されたイベントは、独立して変更やスケーリングが可能です。つまり、単一障害点がありません。ただし、サービス間で多くのイベントが飛び交っているため、モニタリングが非常に困難です。ビジネス ロジックは分散されていて、複数のサービスにまたがっているため、トラブルシューティングを行うための一元化された場所がありません。システムを理解するための信頼できる唯一の情報源がないのです。システムを理解して、アップデートやトラブルシューティングをすることすべてが分散されています。
サービス オーケストレーション - コレオグラフィーが持つモニタリングの課題に対処するために、デベロッパーはイベント ドリブン サービスの疎結合の性質を維持しつつ、イベントのフローに構造をもたらす必要があります。サービス オーケストレーションを使用すると、サービス間のすべてのインタラクションをコントロールする一元的なオーケストレーターによって、サービスが相互に作用します。このオーケストレーターでは、ビジネス プロセスの概要を示し、実行の追跡や問題のトラブルシューティングを行います。Google Cloud ではWorkflows を使用して、サービス オーケストレーションを行います。
ご自分のアプリケーションに適したアプローチがどちらなのかを決定した後は、サービスの特性とユースケースに関する設計上の疑問が出てくると思います。マイクロサービスという制限付きのコンテキスト内ではオーケストレーションの方が、制限されたコンテキスト間ではコレオグラフィーの方が好ましいと判断されるはずです。つまり、同じシステムの中でも、おそらくは上位レベルではコレオグラフィーを行い、下位レベルではオーケストレーションを行うことになるでしょう。
Google Cloud はオーケストレーションとコレオグラフィーの両方のアプローチをサポートするサービスを提供します。Pub/Sub と Eventarc はどちらも、イベント ドリブン サービスのコレオグラフィーに適しています。一方 Workflows は、一元的にオーケストレートされたサービスに適しています。
サービス オーケストレーションに対する Google Cloud サポート
Workflows
Workflows は、サーバーレスのワークフローを使用して、Google Cloud サービスや HTTP ベースの API サービスのオーケストレーションと自動化を行うサービスです。Workflows は、ビジネス プロセスを定義し、複数のサービスへの呼び出しをオーケストレートするための、フルマネージドされた、スケーラブルで監視可能な方法です。Workflows では、サービスをシンプルなウェブ API として呼び出します。Workflows を利用すると、YAML ベースのワークフロー定義言語でビジネス ロジックのフローを定義し、UI や API を使用してワークフローをトリガーできます。Workflows を使用して、イベント ドリブンなジョブやバッチジョブ、エラー処理のロジック、一連の操作など、複雑なプロセスを自動化できます。 Workflows の使用は、長時間実行オペレーションを行う Google Cloud サービスに最適です。Workflows は、たとえ数時間かかるプロセスであっても、完了するまで待機するためです。コールバックを使用すると、Workflows に外部イベントの完了を日単位または月単位で待機させることができます。
サービス コレオグラフィーに対する Google Cloud サポート
Pub/Sub
Pub/Sub を使用すると、サービスが 100 ミリ秒程度のレイテンシで非同期に通信できます。Pub/Sub は、サービスの統合を目的としたメッセージング指向のミドルウェア、または、タスクを同時に読み込むキューとして使用されます。パブリッシャーは、イベントが処理される方法やタイミングとは無関係に、Pub/Sub サービスにイベントを送信します。その後、Pub/Sub によって、イベントに反応する必要のあるすべてのサービスにイベントが配信されます（サブスクライバー）。Pub/Sub は、データを取り込んで配布するためのストリーミング分析とデータ統合パイプラインにも使用されます（データ分析に関する投稿で取り上げています）。
Eventarc
Eventarc を使用すると、基盤となるインフラストラクチャを実装、カスタマイズ、またはメンテナンスすることなく、イベント ドリブン アーキテクチャを構築できます。これは、分離されたマイクロサービス間の状態変更（イベントとも呼ばれる）のフローを管理する標準化されたソリューションを提供します。Eventarc は、配信、セキュリティ、認証、オブザーバビリティ、エラー処理を管理し、これらのイベントを Cloud Run にルーティングします。Eventarc は、イベントを受信するための簡単な方法を提供します。Pub/Sub トピックだけではなく、監査ログや Pub/Sub が統合されている多数の Google Cloud のソースからも受信します。監査ログが統合されているサービスや、Pub/Sub トピックにメッセージを送信できるアプリケーションが Eventarc のイベントソースとなり得ます。
コレオグラフィーとオーケストレーションの両方をサポートする追加サービス
Cloud Tasks
Cloud Tasks を使用すると、メインのアプリケーション フローの外部で独立して実行できる作業を分離し、作成したハンドラを使用した非同期の処理に回すことができます。 このような独立した作業は、タスクと呼ばれます。Cloud Tasks は、データベースの更新など、処理速度に影響を及ぼすバックグラウンド オペレーションをワーカーに委任し、ユーザーのレスポンス時間を短縮します。ユーザーに直接関係のないタスクをメインユーザーのフローから削除し、トラフィックの急増を抑えることもできます。
Pub/Sub と Cloud Tasks の違い。Pub/Sub は暗黙の呼び出しをサポートします。パブリッシャーは、イベントを公開することで、サブスクライバーにイベントを実行するよう暗黙的に要求します。Cloud Tasks は、明示的な呼び出しを前提としていて、各メッセージを配信するエンドポイントの指定など、パブリッシャー側で実行を完全に制御します。Cloud Tasks は、Pub/Sub とは異なり、具体的な配信時間のスケジュール、レート制御、再試行、重複除去など、キューおよびタスク管理向けのツールが用意されています。
Cloud Scheduler
Cloud Scheduler では、作業単位のスケジュールを設定して、定義した回数または一定の間隔で実行できます。これは通常、cron ジョブと呼ばれます。Cloud Scheduler を使用すると、ワークフローのトリガー（オーケストレーション）や、Pub/Sub メッセージの作成（コレオグラフィー）が可能です。一般的なユースケースとしては、レポートメールを毎日送信する、X 分ごとに一部のキャッシュ データを更新する、概要情報を 1 時間に 1 回更新するといったものがあります。
この投稿で取り上げたサービスをさらに詳しく知りたい方はこちらのドキュメントをご覧ください。
#GCPSketchnote をさらにご覧になるには、GitHub リポジトリをフォローしてください。同様のクラウド コンテンツについては、Twitter で @pvergadia をフォローしてください。thecloudgirl.dev もぜひご覧ください。
- Google デベロッパー アドボケイト Priyanka Vergadia
