Workflows 実行ステップ履歴の発表

はじめに

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

Workflows を使用してオーケストレートするサービスが増えるにつれて、ステップ、ジャンプ、反復処理、並列ブランチが多くなり、ワークフローは複雑さを増します。ワークフローの実行がある時点で必ずエラーになる場合は、デバッグして、エラーが発生するステップとその理由を特定する必要があります。今までは、実行のデバッグには入出力による実行の概要とログしか利用できませんでした。基本的なワークフローであればこれで十分ですが、ステップレベルのデバッグ情報は提供されていませんでした。

新しくリリースされた実行ステップ履歴なら、この問題を解決できます。Google Cloud コンソールまたは REST API で各実行のステップレベルのデバッグ情報を表示できるため、多数のステップや並列ブランチを含む複雑なワークフローの場合に特に有用です。

このブログでは、Workflows 実行ステップ履歴について具体的な例を挙げて詳しく見ていきます。

BigQuery ジョブの並列実行

「Workflows に並列ステップを導入」という過去のブログ投稿と、それに関連するチュートリアルでは、処理を高速化するために Workflows の並列ブランチを使用して 5 つの BigQuery テーブルをクエリするワークフロー（workflow-parallel.yaml）をご紹介しました。

このワークフローの概要は以下のとおりです。

runQueries ステップでは 5 つの並列ブランチが組み合わされており、テーブルに対するクエリが並列で実行されます。

実行ステップ履歴を使用したデバッグ

ここで、いずれかのテーブルの名前を間違って、存在しないテーブルを指定していたとします。このような間違いをデバッグする際に、新しい実行ステップ履歴はどのように役立つでしょうか。

まず、実行中に、Google Cloud コンソールの実行の詳細の下に新しい [STEPS] タブがあることに気づくでしょう。

[STEPS] タブには、各ステップの状態（[Succeeded]、[Running]、[Failed]）が表示されています。

これだけでも、内部で何が起こっているかを目で見て把握するのにとても役立ちます。

実行が完了すると、最上位の runQueries ステップが失敗したことが表示されます。フィルタして子ステップを確認しましょう。

runQueries の反復処理（テーブル）の 1 つが失敗したことがわかります。

runQueries.3 ステップをさらにフィルタすると、 runQuery.3 が失敗したとわかります。

最後に、runQuery.3 をさらに詳しく見ていくと、このステップが、問題のテーブルが存在しないことを示唆する HTTP ステータス 404 を受信していることがわかります。

この時点で、ログを調べて、HTTP 404（テーブルが存在しない）の正確な理由を知ることができます。

ここまでで、実行が失敗したことを受け、並列ブランチ内の失敗したステップを突き止めて実際の HTTP 404 エラーを確認するまでの手順をざっとご紹介しました。

まとめ

新しい実行ステップ履歴は、実行の内部で何が起こっているかを把握しやすくしてくれます。ほとんどのデベロッパーは Google Cloud コンソールを使用してステップ履歴を表示するかと思いますが、REST API からも同じ情報にアクセスできます。Google ではデベロッパー エクスペリエンスの改善に引き続き取り組んでいきます。その一環として、Workflows の実行に関してさらに 2 つの機能追加が予定されています。ループ、並列ブランチ、再試行の進行状況の表示や、入出力とユーザー変数の詳細ビューの表示もできるようになります。今後の情報にご注目ください。

次のステップ

詳しくは、実行ステップの履歴の表示のドキュメントと、Guillaume Laforg によるブログ投稿「Visualize and Inspect Workflows Executions」をご覧ください。また、Workflows の公式サンプルを使用して、実行ステップ履歴がどのように役立つかをご確認いただけます。ご不明な点やフィードバックがございましたら、Twitter で @meteatamel までお気軽にお問い合わせください。

ー デベロッパー アドボケイト Mete Atamel

ー プロダクト マネージャー Archie Gautam