Workflows のパターンとベスト プラクティス - パート 3
Google Cloud Japan Team
※この投稿は米国時間 2022 年 12 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。
この記事は、Workflows とサービス オーケストレーションのパターンについてまとめた 3 つの投稿のうちのパート 3 になります。最後の投稿となる今回は、ワークフローのライフサイクル管理と、Workflows で Firestore を使用する利点について説明します。
サブワークフローと Terraform を使用してワークフロー定義を管理する
YAML や JSON で作成したワークフロー定義は、うっかりしているとすぐに管理しづらいものになる可能性があります。サブワークフローを使用して、再利用可能なワークフローのスニペットを複数のワークフローから定義することは可能ですが、Workflows ではこのようなサブワークフローのインポートがサポートされていません。ありがたいことに、Terraform などの役立つツールが他にもあります。
ブログ投稿「Terraform で複数の YAML ワークフロー定義をデプロイする」で、Terraform を使用してワークフローを定義し、それを Terraform 構成ファイルにインポートする方法を取り上げています。その中で、同じワークフロー定義にサブワークフローをインポートする方法についても触れています。この方法なら、ワークフローとサブワークフローの定義管理が容易になります。
ワークフローを定義する際は、Terraform などのツールでサブワークフローを定義し、再利用する戦略を立てるようにしましょう。
GitOps でサービスをオーケストレーションする
GitOps は、バージョン管理や CI / CD のようなアプリケーション開発に使用される DevOps のベスト プラクティスをインフラストラクチャの自動化に適用しています。独自の定義ファイルとデプロイ サイクルを持つサービス オーケストレーションは、GitOps アプローチの恩恵を受けることもできます。
ブログ投稿「GitOps でサービスをオーケストレーションする」で、ワークフローの変更の公開を Cloud Build を使用して管理する方法、すなわち、途中でテストを行ってリスクを最小限に抑えながら、自動的かつ段階的にワークフローの変更を公開していく管理手法についてご説明しています。
マルチ環境オーケストレーションを計画する
GitOps はワークフローのデプロイ ライフサイクルを管理するのに役立ちますが、別の環境にデプロイする前に、ワークフローの変更が必要な場合があります。つまり、複数の環境を想定してワークフローを設計する必要があります。たとえば、ワークフローから呼び出される URL をハードコードする代わりに、ワークフローがデプロイされる場所に応じて、URL をステージング URL と本番環境 URL に置き換えます。
ブログ投稿「Multi-environment service orchestrations(マルチ環境サービスのオーケストレーション)」で、ワークフローの URL を置き換える 3 つの方法(URL をランタイム引数として渡す方法、Cloud Build を使用して複数のバージョンをデプロイする方法、Terraform を使用して複数のバージョンをデプロイする方法)についてご説明しています。
Firestore で外部状態を管理する
ワークフロー YAML / JSON をレシピとして定義し、そのレシピの個別の分離インスタンスとして、任意のランタイム引数とともに実行します。場合によっては、あるワークフローの実行上のいずれかのステップで状態(通常は Key-Value ペア)を保存し、その後にワークフローの実行時に別のステップでその状態を読み取る必要があります。Workflows には固有の Key-Value ストアがありませんが、Firestore を使用して、Workflows から Key-Value ペアの保存と読み取りを行うことができます。
ブログ投稿「Workflows state management with Firestore(Firestore を使用した Workflows の状態管理)」とその関連サンプルで、Firestore を使用して Workflows から Key-Value ペアを保存および取得するためのサブワークフローをいくつか紹介しています。このパターンは、ワークフローで状態を管理する必要がある場合に非常に有用です。
信頼性の高い処理のための Workflows とリアクティブ UI のための Firestore
Workflows を使用すれば、長時間に及ぶ処理を確実に実行できます。また、Google Cloud コンソールまたは Workflows API を使用すれば、管理者はワークフローのステータスと現在進行中のステップを確認できます。では、ワークフローのステータスについて、常にエンドユーザーに最新の状態を伝えるにはどうすればよいでしょうか。この種のリアクティブ UI を実現するには、ワークフローからそのステータスを Firestore ドキュメントに書き込み、接続されているエンドユーザーに Firestore からリアルタイムで通知するようにします。
Google I/O では、2 つの例を使ってこのパターンについて説明しました。経費報告書アプリケーションでは、UI によって従業員とマネージャーの両方の承認プロセス ステータスが更新されます。コールバックを使用する翻訳アプリケーションでは、進行中の翻訳のステータスの表示に Firestore が使用されます。
これで全 3 回のシリーズは終了です。ご意見やご質問がある場合、またはお客様独自のベスト プラクティスやパターンをお寄せいただける場合は、Twitter @meteatamel または @glaforge までお気軽にお問い合わせください。
- Cloud デベロッパー アドボケイト Guillaume Laforge
- デベロッパー アドボケイト Mete Atamel