Workflows 向けの Eventarc トリガーのご紹介
Google Cloud Japan Team
※この投稿は米国時間 2022 年 4 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。
Workflows デスティネーションを直接ターゲットとした Eventarc トリガーを作成できるようになりましたので、お知らせいたします。プレビュー機能として使用可能で、中間サービスを介さずに Eventarc イベントを Workflows にルーティングできるため、イベント ドリブン オーケストレーションを簡素化することができます。
Eventarc と Workflows の統合
以前の投稿では、Eventarc と Workflows を統合する方法についてお話ししました。この 2 つのサービスには直接的な連携がなかったので、まず仲介となる Cloud Run サービスをデプロイして Eventarc イベントを受け取り、それから Workflows API を使用して Workflows を実行しなければなりませんでした。実際の例を見てみましょう。
画像処理パイプライン(旧)
Workflows デスティネーション機能が使用可能になる前は、画像処理パイプラインを設計していました。(コード)


このパイプラインでは、ユーザーは Cloud Storage バケットに画像を保存し、これによって、Eventarc トリガーを介して Cloud Storage イベントが Cloud Run サービスにトリガーします。Filter サービスは、画像が安全かどうかを確認し、Workflows API を使用して画像処理ワークフローを開始します。画像処理ワークフローでは、3 つの Cloud Functions を呼び出します。画像からラベルを抽出する Labeler と、画像を 400x400 にサイズ変更する Resizer と、サイズ変更した画像に上位 3 つのラベルの透かしを追加する Watermarker です。最後に、サイズ変更され、ラベル付けされた画像が出力バケットに保存されます。


これはイベント ドリブン オーケストレーションとして機能しましたが、理想的なものではありませんでした。
Filter サービスは、画像をフィルタするだけでなく、ワークフローの実行を開始します。Eventarc と Workflows には直接的な連携がなかったので、Cloud Run サービスを使用する必要がありました。コードが不必要に複雑で、結果的に脆弱になります(例えば、ワークフローが成功しない場合のエラー処理や再試行がない)。
Filter サービスは Cloud Run サービスで、その他のサービスは Cloud Functions です。Cloud Run も好きですが、Cloud Functions のシンプルさがとても気に入っていて、コンテナについてはまったく気にしていません。このアプリケーションの反復処理では、Eventarc はイベントを Cloud Run サービスにしかルーティングできないので、よりシンプルな Cloud Function に頼るのではなく、他のサービスタイプを持つ必要がありました。
画像処理パイプライン(新)
Workflows のデスティネーション機能が使えるようになったとき、それを活用するためにアプリケーションを書き直しました(コード)。その結果、よりシンプルで均一なアーキテクチャが実現したのです。


ワークフローをトリガーするために、別途 Cloud Run サービスを用意する必要はありません。Eventarc は、Cloud Storage イベントを直接 Workflows にルーティングします。
Filter サービスは、受信画像のフィルタリングという 1 つの仕事のみをするシンプルな Cloud Function です。
Filter サービスは、同じエラーと再試行のポリシーを持つ全体的なオーケストレーションの一部となりました。
このセットアップでは、適切な Cloud Storage イベントとワークフローのデスティネーションを持つ Eventarc トリガーを作成するだけです。
Google Cloud Console からトリガーを作成することもできます。新しい Workflows イベント デスティネーションにご注目ください。


このワークフローでは、Eventarc から CloudEvent をランタイム パラメータとして受け取り、イベントからバケットとファイル情報を抽出します。
残りのワークフロー タスクは、適切な入力で Cloud Functions を呼び出し、出力をキャプチャします。workflow.yaml ファイルとセットアップ手順の詳細はこちら。
ドキュメントおよび Eventarc と Workflows の統合の例については、以下のリソースをご覧ください。
ご不明な点やフィードバックがありましたら、Twitter で @meteatamel までお気軽にお問い合わせください。
- デベロッパー アドボケイト Mete Atamel