Workflows のパターンとベスト プラクティス - パート 2

※この投稿は米国時間 2022 年 11 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

この記事は、Workflows とサービス オーケストレーションのパターンについてまとめた 3 つの投稿のうちのパート 2 になります。これらのパターンを応用することで、Google Cloud 上の Workflows とサービス オーケストレーションをより効果的に活用できるようになります。

パート 1 では、一般的なヒントとコツ、イベント ドリブン オーケストレーションのパターン、並列ステップ、コネクタなどを紹介しました。パート 2 では、より高度なパターンについて説明します。  

それでは詳しく見ていきましょう。

再試行と Saga パターンにより復元性をもたらす設計

当該サービスで障害が発生しないことを前提とすれば、一連のサービスをつなぐワークフローは簡単に構築できます。ただしこの前提は、一般的な分散システムでは通用しません。なぜなら、サービスではいつか必ず障害が発生するからです。そのサービスを呼び出すワークフローのステップで障害が発生すれば、ワークフロー全体で障害が発生します。これでは、復元性のあるアーキテクチャは望めません。幸いなことに、Workflows は一時的なサービス障害と永続的なサービス障害の両方に対応できるビルディング ブロックを備えています。

Workflows における Saga パターン（および関連する e コマースのサンプル）の実装についての投稿では、Saga パターンを適用し、永続的なサービス障害に対して try/except ブロックで 1 つまたは複数の以前のステップを元に戻す補償ステップについて紹介しました。

また、Workflows の try/retry ブロックを使ってデフォルトの HTTP 再試行ポリシーを追加し、一時的なサービス障害に対処する方法を紹介しました。非べき等のステップがある場合、再試行ポリシーを default_retry_non_idempotent に適合させる必要があります。ほとんどの場合、デフォルトの再試行ポリシーは最大で 8 秒待機するため、より長いバックオフを持つカスタム再試行ポリシーが必要になります。短期間の障害よりも長い期間での結果整合性が重視される場合、数分あるいは数時間の障害に対して大きな乗数で長い再試行ポリシーを適用することで、一時的なサービス停止に対処できる可能性が高くなります。

ネットワーク呼び出しを、当たり前のものとして捉えないでください。再試行や Saga パターンを使用して、復元性を考慮したオーケストレーションを設計しましょう。

ポーリングではなく HTTP とイベントのコールバックを待つ

オーケストレーションが残りのステップを続行する前に、他のシステムでの非同期イベントや、長時間動作しているジョブを待つ必要がある場合があります。ワークフローは、エンドポイントやキューをポーリングすることで入力を求めることができますが、これには複雑なポーリング ロジックが必要になるため、ポーリング サイクルが無駄になり、レイテンシの発生確率が非常に高くなります。より適切な方法は、Workflows のコールバックを使用して、HTTP の呼び出しまたはイベントを待つことです。  

これらの投稿では両方とも HTTP コールバックの待機に焦点を当てていますが、Creating Workflows that pause and wait for events（イベントを一時停止して待機するワークフローを作成する）という投稿では、ワークフローが Pub/Sub と Cloud Storage のイベントを待機する仕組みを紹介しています。Workflows that pause and wait for human approvals from Google Sheets（Google スプレッドシートから、一時停止して人間の承認を待つワークフロー）の投稿で紹介したように、人間の承認を得るための迅速でシンプルなフロントエンドとして Google スプレッドシートを活用することもできます。

ワークフローを設計する際には、ポーリングではなく、HTTP 呼び出しとイベントの待機について検討します。 

長時間実行するバッチジョブのオーケストレーション

長時間実行するジョブを実行する必要がある場合、Google Cloud では Batch や Cloud Run のジョブなどのサービスを利用できます。これらのサービスは、Compute Engine インスタンスやコンテナ上で長時間実行するジョブを完了させるうえで最適ですが、Batch と Cloud Run ジョブサービスを作成し、管理する必要があります。Workflows を使用して、バッチジョブを実行するこれらのサービスを管理することが、非常に効果的なパターンになります。

長時間実行するバッチジョブに適したサービスを使用し、Workflows を使ってそのライフサイクルを管理します。

Workflows を使用して、サーバーフルなワークロードをサーバーレスとして扱う

なんらかのサーバーレスの制約で、どうしてもサーバーが必要になる場合があります。GPU で実行したり、数週間から数か月に及ぶ長期間の処理を実行したりする必要がある場合です。そのような場合、Compute Engine はカスタマイズされた仮想マシン（VM）を提供できますが、その VM を自分で管理する手間が生じます。

このような IT 自動化のシナリオでは、必要なカスタマイズを行った VM を Workflows で作成し、必要な期間（Workflows の実行は最長で 1 年間継続可能）ワークロードを実行し、最後に結果を返します。このパターンでは、サーバーを使用しながらも、サーバーの管理は Workflows を使ってサーバーレス サービスのように実行できます。

Long-running containers with Workflows and Compute Engine（Workflows と Compute Engine を利用したコンテナの長時間実行）の投稿では、Workflows を使って VM をスピンアップし、VM 上で素数ジェネレータを起動して必要な期間だけ実行し、結果を返す方法を紹介しました。

次回 VM のスピンアップが必要な時には、Workflows を使用してサーバーレス サービスのように扱います。

Workflows と Cloud Build でコマンドライン ツールを実行する

多くの場合、Google Cloud のリソース管理には gcloud、Kubernetes のクラスタ管理には kubectl といったコマンドライン ツールを使います。これらのツールを Workflows から呼び出して、リソースの管理をオーケストレートできれば便利ですよね？

Executing commands (gcloud, kubectl) from Workflows（Workflows からの gcloud、kubectl コマンドの実行）の投稿では、Cloud Build を使ってこれらのツールを実行する方法と、Cloud Build コネクタを使って Workflows からその Cloud Build ステップを作成して呼び出す方法を紹介しました。

このパターンは、gcloud や kubectl だけに当てはまるものではありません。コンテナで実行できるツールであれば、Cloud Build を使うことで Workflows を活用できる可能性があります。

Workflows から Cloud Build ステップを呼び出すことで、必要に応じてコマンドライン ツールをワークフローに統合できます。

- Cloud デベロッパー アドボケイト Guillaume Laforge
- デベロッパー アドボケイト Mete Atamel