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

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

この数年間、私たちは Google Cloud のサービス オーケストレーターである Workflows を使用して、サーバーレス マイクロサービス アーキテクチャの整理に取り組んできました。Workflows を使用してサービス オーケストレーションの経験を重ねながら、学んだことをカンファレンスでの講演やブログ投稿、サンプル、チュートリアルで共有してきました。その過程で見えてきた、一般的なパターンとベスト プラクティスがいくつかあります。

Google Cloud 上で Workflows とサービス オーケストレーションをより効果的に活用していただくために、この全 3 回からなるブログ投稿シリーズで、これらの実証されたパターンとベスト プラクティスをまとめたいと思います。

早速パート 1 を開始しましょう。

通信スタイルについて、事前に意識的な選択をする

通信スタイルの選択は、パターンというよりはむしろタスクですが、この重要なタスクを完了してからでなければ、サービス オーケストレーションについて検討することすらできません。

複数のサービスを使用するときは、それらのサービス間の通信方法を決定する必要があります。通信方法には次のオプションがあります。

• サービス間の直接通信

• 間接的なイベント ドリブン型通信（コレオグラフィとも言う）

• オーケストレーター（Workflows など）による通信の一元管理

どれが正解か不正解かということではありません。いずれの方法にしても、利点と欠点があります。サービス間の直接通信は簡単に実装できますが、サービスが密結合になります。イベント ドリブン型の通信ではサービスが疎結合になりますが、この場合、問題が発生したときのモニタリングとデバッグが難しくなるという犠牲が伴います。オーケストレーターは柔軟性に欠けるとはいえ、サービス間の直接通信による密結合や、コレオグラフィ アーキテクチャでのイベントのカオスを招くことなく、通信に秩序をもたらします。

過去に投稿した Workflows による Pic-a-Daily サーバーレス アプリのオーケストレーションでは、イベント ドリブン型アプリケーションをオーケストレートされたアプリケーションに変換した方法と、そうすることのメリットを説明しました。また、Google Cloud での適切なオーケストレーターの選択という投稿では、オーケストレーションの異なるニーズ（スケジュール、サービス、データ）のそれぞれに対応する適切なサービスを紹介しています。

アーキテクチャを設計する際は、通信スタイルそれぞれの利点と欠点を念頭に、どのスタイルを採用するかを意識的に決めてください。オーケストレーションを使用することに決めた場合は、タスクに応じた適切なオーケストレーターを使用する必要があります。

Workflows に関して覚えておくべきヒントとコツ

サービス オーケストレーションに Workflows を使用することにした場合、Workflows には独自の強みと特異性があることに気づくはずです。私たちが Workflows を使用するうえで役立った、一般的なヒントとコツを以下に紹介します。

• 環境間で移植しやすいワークフローにするために、URL のハードコード化を回避する

• サブステップを使用して、一般的な一連の手順を 1 つの論理ユニットにまとめる

• 文字列式をラップして、解析の問題を回避する

• ロジックレスのサービスを宣言型 API 呼び出しに置換して、ボイラープレート コードを使わなくても済むようにする

• 必要なものを保管し、解放できるものは解放して、メモリ消費量を管理する

• サブワークフローの使用と外部ワークフローの呼び出しによって、再利用を促す

以上の点についての詳しい説明は、Workflows のヒントとコツに関する投稿をご覧ください。

イベント ドリブン型オーケストレーションを検討する

通信スタイルの選択は、オール オア ナッシングではありません。異なる複数の通信スタイルを組み合わせることも可能であり、そうすることが合理的であれば、そうすべきです。たとえば一般的なパターンとして、互いに密接に関連するサービスは Workflows などのオーケストレーターで管理しつつ、そのオーケストレーションが Eventarc などのサービスからのイベントによってトリガーされるようにすることができます。同様に、他のオーケストレーションやサービスに対する Pub/Sub メッセージでオーケストレーションが終了するというアーキテクチャもあります。

こうした通信スタイルを組み合わせて両方の利点を活かすことができます。すなわち、サービス間の密結合が必要な場面ではオーケストレーションを使用しつつ、他のオーケストレーションとはイベントを介した疎結合が可能です。

可能な限りコネクタを使用する

Workflows には、他の Google Cloud サービスを呼び出すための豊富なコネクタが揃っています。これらのコネクタはリクエストのフォーマットを処理するだけではありません。これらのコネクタが提供するメソッドと引数を使用すれば、Google Cloud API の詳細を把握する必要がなくなります。さらに重要なことに、コネクタを使用することで、長時間実行される Cloud API 呼び出しをワークフローが透過的に待機できます。これにより、退屈な反復作業や、呼び出しが完了するまで待機するといったことを、まるごとコネクタに任せることができます。

Workflows 向けの新しいコネクタのご紹介という投稿で、Compute Engine コネクタが仮想マシンの作成と停止を簡素化する方法を説明しています。

Workflows からいずれかの Google Cloud API を呼び出す必要がある場合は常に、その API の呼び出しを対象としたコネクタがあるかどうかを確認してください。該当するコネクタがあれば、作業が大幅に楽になるはずです。該当するコネクタがなければ、こちらでいつでも新しいコネクタをリクエストできます。

可能な限り並列処理する

Workflows に関しては、1 つずつ順次実行されるステップを取り上げるのが一般的です。Workflows は目立った遅延を生じさせないほど高速にステップを順次実行できるとはいえ、すべてのステップの実行を「順次」にする必要はありません。実は、独立したステップについては並行して実行できます。場合によっては、こうした並列処理がワークフローの実行速度の大幅な向上につながることもあります。

ステップをできるだけ独立させて、並列ステップを活用するようにしてください。

このパート 1 でご紹介したパターンとヒントを利用すれば、Workflows をさらに有効に活用できるようになります。シリーズのパート 2 では、さらに高度なパターンをご紹介します。ご不明な点やフィードバックがございましたら、Twitter の @meteatamel および @glaforge までご連絡ください。