Workflows 向けの新しいコネクタのご紹介
Google Cloud Japan Team
※この投稿は米国時間 2021 年 4 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。
Workflows は、Cloud Functions、Cloud Run、機械学習 API をはじめとする各種 Google Cloud サービスのほか、外部サービスもオーケストレートするサービスです。オーケストレーターという語から想定できるとおり、Workflows を使用すると、定義言語である YAML や JSON で、ビジネス ロジックのフローを手順として定義することができます。これにより、実行用の API と UI を用意してワークフローの実行をトリガーできます。Workflows の利点の詳細については以前の記事をご覧ください。
今回は、Workflows 向けの新しいコネクタをご紹介します。このコネクタにより、Google Cloud サービスとその API の呼び出しを簡素化できます。
General Availability に Workflows を導入するプレビューで提供され、最初に文書化されたコネクタは次のとおりです。
Cloud Tasks
Compute Engine
Firestore
Pub/Sub
Secret Manager
新たに導入されたコネクタは次のとおりです。
BigQuery
Cloud Build
Cloud Functions
Cloud Scheduler
Google Kubernetes Engine
Cloud Natural Language API
Dataflow
Cloud SQL
Cloud Storage
Storage Transfer Service
Cloud Translation
Workflows および Workflow Executions
コネクタは、ワークフロー手順から Google Cloud サービスを簡単に呼び出せるようにするほか（呼び出し先の URL を手動で編集する必要がありません）、エラー処理と再試行にも対応しているので、これらの処理をユーザー側で実施する必要がありません。また、長時間実行オペレーションで API を扱い、バックオフ アプローチでサービスをポーリングして、その処理結果を取得します。この場合も、ユーザー自身による操作を必要としません。
コネクタの動作を明確に理解できる例をいくつかご紹介します。
REST API 呼び出しによる Compute Engine VM の作成
指定のプロジェクトとゾーンで Compute Engine の仮想マシン（VM）を作成するとします。Compute Engine API の instance.insert メソッドを使用し、適切な URL、本文、OAuth2 認証を指定して HTTP POST リクエストを作成することで、この VM 作成を実現できます。次の create-vm.yaml に、この処理を示します。
このコードは機能しますが、適切なパラメータと認証メカニズムを指定した適切な URL の作成で誤りを誘発しやすい性質があります。また、ワークフローを終了する前に、次のようにインスタンスのステータスをポーリングして、そのインスタンスが稼働していることを確認する必要もあります。
前述の HTTP GET 呼び出しが失敗する可能性があったとしても、再試行ロジックでは、この呼び出しをラップすることが得策です。
Workflows のコンピューティング コネクタによる Compute Engine VM の作成
今度は、次の create-vm-connector.yaml に示すように、Compute Engine 専用のコンピューティング コネクタを使用して、同じ VM を作成します。
これら 2 つの例の全体的な構造と構文は互いに類似していますが、2 番目の例では、ユーザー側で URL を作成する必要も、認証方法を指定する必要もありません。この YAML 宣言では、エラー処理と再試行ロジックが Workflows で直接処理されていて、ユーザーには認識されません。1 番目の例では、これらの処理をユーザー自身が扱う必要があります。
長時間実行オペレーションの透過的待機
クラウド サービスのオペレーションの中には、直ちには実行されず、実行までにいくらかの時間を要するものがあります。このようなオペレーションに対する同期呼び出しは、その長時間実行オペレーションのステータスを示すオブジェクトとともに直ちに戻ります。
ワークフローの実行では、長時間実行オペレーションを呼び出した場合に、そのオペレーションが完了したときにのみ次の手順に移動することが必要な場合があります。標準的な REST アプローチでは、オペレーションが終了しているかどうかを一定の間隔で確認する必要があります。そのような反復と待機の面倒な作業を省くには、コネクタの使用が効果的です。
Compute Engine を使用した別の例で、この処理を示します。VM の停止には、ある程度の時間を必要とすることがあります。Compute Engine の REST API に対して VM を停止するリクエストを発行すると、オペレーションが完了しているかどうかを示すステータス フィールドを持つオブジェクトが返されます。
Workflows のコンピューティング コネクタとその instances.stop オペレーションは VM の停止まで適切に待機されるので、ユーザーは VM が停止するまでそのステータスを確認し続ける必要がありません。これにより、次の create-stop-vm-connector.yaml に示すように、ワークフローの定義を大幅に簡素化できます。
ここでは、サブワークフローで引き続き instances.get オペレーションを使用して、VM のステータスが本当に TERMINATED であるかどうかを確認しています。VM の停止を instances.stop で待機したうえで戻るようにはしていますが、この確認処理があるに越したことはありません。
コネクタでは、コネクタ呼び出しの合計待機時間を指定するタイムアウトのフィールドを設定できます。再試行とポーリングのロジックはいずれも表示されません。この例を、コネクタを使用せずにワークフローで VM を停止する stop-vm.yaml と比較します。停止呼び出しの HTTP 再試行ポリシーおよび VM が実際に停止していることを確認するポーリング ロジックがあることにより、YAML が長くなっていて、そのロジックが複雑であることがわかります。
コネクタの再試行による信頼度の向上
最良のサービスであっても、トラフィックの急増やネットワークの障害によって一時的に停止することがあります。Google Cloud の Pub/Sub は 99.95 の SLA を実現しています。この SLA は、1 日あたりの平均ダウンタイムが 43 秒以下、1 か月あたりの平均ダウンタイムが 22 分未満であることに相当します。当然のことながら、ほとんどのプロダクトは、ヘルスマージンによって常にこの SLA を凌ぐ信頼性を発揮します。各プロダクトがその SLA の範囲で稼働を維持している場合、ワークフローに障害が発生しない確かな保証が必要であるとしたらどうでしょうか。Workflows のコネクタは数分にわたってオペレーションを再試行するので、短時間の停止があってもそのオペレーションは成功し、同様にワークフローも成功します。
つながろう
コネクタの詳細については、Google の workflows-samples リポジトリをいくつかご覧ください。Compute Engine、Cloud Pub/Sub、Cloud Firestore、Cloud Tasks の使用方法を確認できます。このブログ投稿で取り上げている例は workflows-demos/connector-compute にあります。
これは、コネクタのほんの手始めにすぎません。専用のコネクタの作成が予定されている Google Cloud プロダクトが多数あります。作成を優先すべきコネクタや重点的な対応が望まれるコネクタについて、皆様のご意見をいただければ幸いです（こちらのフォームでお知らせください）。Twitter でも、@meteatamel および @glaforge にぜひご意見をお寄せください。
-デベロッパー アドボケイト Guillaume Laforge
-デベロッパー アドボケイト Mete Atamel
