ワークフローによるサービス オーケストレーションの向上
Google Cloud Japan Team
※この投稿は米国時間 2020 年 12 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。
1 つのモノリシック アプリケーションから、一連の小さな独立したマイクロサービスに移行することには、明らかなメリットがあります。マイクロサービスは、再利用性を実現し、アプリをオンデマンドで変更したりスケールしたりしやすくします。同時に新たな課題も生じます。すべてのビジネス ロジックが整然と揃い、サービス通信が単純なメソッド呼び出しで行われる単一のモノリスはもはや存在しません。マイクロサービスの世界では、通信は REST またはある種のイベント メカニズムを使用してネットワーク経由で行われる必要があり、独立したマイクロサービスを共通の目標に向けて機能させる方法を見つけなくてはなりません。
オーケストレーションとコレオグラフィー
サービス間のすべての相互作用を制御する一元的なオーケストレーターが必要なのか、それとも各サービスが独立して機能し、イベントを通じてのみ相互作用する必要があるのか。これはオーケストレーションかコレオグラフィーかを議論する際に中心となる論点です。
オーケストレーションでは、中央サービスがサービス間の通信フローを定義、制御します。一元化により、フローの変更とモニタリングや、一貫性のあるタイムアウトとエラーポリシーの適用が容易になります。
コレオグラフィーでは、必要に応じて各サービスがイベントを登録、発行します。通常、メッセージを分配する中央イベント ブローカーがありますが、通信フローの定義や指示は行ないません。これにより、フローやポリシーの追跡と管理は難しくなりますが、まったく独立したサービスが可能になります。
Google Cloud はオーケストレーションとコレオグラフィーの両方のアプローチをサポートするサービスを提供します。Pub/Sub と Eventarc はどちらも、イベント ドリブン サービスのコレオグラフィーに適しています。一方ワークフローは、一元的にオーケストレートされたサービスに適しています。
ワークフロー: オーケストレーターなどの機能
ワークフローは、Cloud Functions や Cloud Run などの Google Cloud サービスだけでなく、外部サービスもオーケストレートするためのサービスです。
オーケストレーターで想定されるように、ワークフローを使用すると、YAML ベースのワークフロー定義言語でビジネス ロジックのフローを定義でき、そのフローをトリガーするワークフロー実行 API とワークフロー UI が提供されます。
ワークフローは単なるオーケストレーターではなく、以下の構成可能な組み込み機能を備えています。
ステップ間の柔軟な再試行とエラー処理により、ステップを確実に実行できます。
JSON 解析とステップ間の変数の受け渡しにより、グルーコードを回避できます。
決定の表現式により、条件付きステップを実行できます。
モジュール式で再利用可能なワークフローのサブワークフローを備えています。
外部サービスのサポートにより、Google Cloud 以外のサービスのオーケストレーションが可能になります。
Google Cloud と外部サービスの認証サポートにより、安全なステップ実行が可能になります。
Pub/Sub、Firestore、Tasks、Secret Manager などの Google Cloud サービスへのコネクタにより、統合が容易になります（まもなく非公開プレビューされます）。
ワークフローがフルマネージド型のサーバーレス プロダクトであることは言うまでもありません。サーバーの構成やスケーリングは不要で、使用分に対してのみ料金が発生します。
ユースケース
ワークフローは幅広いユースケースに適しています。
たとえば、e コマース アプリケーションでは、サービスのチェーンを特定の順序で実行する必要があることがあります。いずれかのステップが失敗した場合は、チェーン全体を再試行するか失敗させます。エラー処理や再試行処理が組み込まれたワークフローは、このユースケースに最適です。
別のアプリケーションでは、ワークフローの条件付きステップ実行の条件に応じて、異なるチェーンの実行が必要となる場合があります。
長時間実行されるバッチデータ処理のようなアプリケーションでは通常、相互に依存する小さなステップをいくつも実行する必要があり、プロセス全体をまとめて完了しなくてはなりません。ワークフローが適している理由をご紹介します。
長時間実行されるワークフローをサポートします。
さまざまな Google Cloud コンピューティング オプションに対応します。たとえば、長時間実行の場合は Compute Engine や GKE を、有効時間が短いデータ処理の場合は Cloud Run や Cloud Functions をサポートします。
システム障害に対する耐性があります。ワークフローの実行が中断されても、最後のチェック ポイントの状態から再開されます。
オーケストレーションとコレオグラフィーの議論には正しい答えがありません。制限付きのコンテキストで明確に定義されたプロセスを実装する場合は、フロー図で描くことができるもの、つまりオーケストレーションが適切なソリューションになることがよくあります。異なるドメインに分散したアーキテクチャを作成する場合は、そのようなシステムを連携させるのにコレオグラフィーが役立ちます。また、オーケストレートされたワークフローがイベントを介して相互に通信するハイブリッド アプローチを使用することも可能です。
ワークフローをアプリで使用できることをとても嬉しく思います。ユーザーの皆様が Google Cloud やその他のサービスでワークフローをどのように使用するのか楽しみです。
詳細については、ワークフローのドキュメントをご覧ください。ご不明な点やフィードバックがございましたら、Twitter の @meteatame でお気軽にお問い合わせください。
-デベロッパー アドボケイト Mete Atamel
