Opt Technologies Magazine

オプトテクノロジーズ 公式Webマガジン

GCP Workflows のワークフローを動的に生成するバッチ処理

FeedTerminal プロダクト内での、GCP Workflows の使用事例を紹介します。

あいさつ

こんにちは。データテクノロジー開発部の勝島と申します。
FeedTerminal というフィード広告の運用補助ツールの開発を主に行なっております。

概要

担当プロダクト FeedTerminal で現在フルリプレースの試みが進行しているのですが、 その一環で、バッチ処理の計算リソースの管理に GCP Workflows を使用するようになりました。
その中で、Workflows の本来の想定用途とは若干異なりそうな使い方をしている箇所があるので、Workflows 使用の一事例の紹介を目的としてこの記事を執筆しました。

Workflowsとは

Workflowsは、実行フロー制御用のGCPサービスです。

公式ドキュメントによると、

ワークフローは、フルマネージドのオーケストレーションプラットフォームで、定義した順序(ワークフロー)でサービスを実行します。これらのワークフローでは、Cloud Run や Cloud Functions でホストされているカスタムサービス、Cloud Vision AI や BigQuery などの Google Cloud サービス、任意の HTTP ベースの API を含むサービスを組み合わせることができます。

と説明されています。

Workflows 選定背景

担当プロダクトの FeedTerminal では、諸々の理由*1から現在フルリプレースを試みています。

このプロダクトは、DFO*2 ツールに分類されるもので、フィード広告運用の補助機能を提供しています。

その主な機能の1つとして、以下の一連の処理を定期実行しています。

  1. フィードの基データのインポート*3
  2. フィードデータの加工処理*4
  3. 広告媒体へのフィードデータの送信*5

リプレース前は、この一連の処理は同一の計算リソース上で行っていたのですが、
各処理は実際のところほぼ独立して扱えるものであるため、リプレースの機に乗じて各処理を実行環境ごと分離することになりました。

この分離した各実行環境のリソースの確保や連動、ハンドリングなどの管理を投げられるサービスが必要でした。GCP をインフラ基盤に使うこと、が今回のリプレースの前提条件としてあったので、GCPサービス内から妥当そうなものを探したところ、Workflows で概ねやりたいことはできそうだったので採用しました*6

しかしながら、一部マッチしない部分があったため、表題のバッチを作る必要がありました。
詳しい内容について次章で説明します。

Workflows を使う上での問題点

Workflows は、事前に一連の処理(ワークフロー)の内容を記述した設定ファイルをもとにデプロイをしておくのが通常の使い方なのですが、
FeedTerminal の場合、ワークフローはアカウント*7ごとに異なるため、その構成は事前には決まりません。
例えば、フィードの基データのインポート処理は基データの個数分だけ発生するため、処理ステップの数はその個数に応じて変わります。他にも、フィードデータの加工処理では操作クエリの実行を複数回行うのですが、各クエリ実行がそれぞれ1ステップに相当するため、これまたアカウントによってその処理ステップ数は変わってきてしまいます。

このように、設定ファイルを事前に記述することはできないため、ワークフローの実行の前に、動的に設定ファイルを生成しデプロイする処理を挟むことにしました。

次章でその実装について簡単に説明します。

設定ファイル生成部分の実装

「Workflows 選定背景」の章で記載した各処理は、Workflows の設定上の観点ではほぼやることは同一で、「指定した Docker イメージのコンテナをオンデマンドに実行する」となります。そのため、どの処理も以下の手順で統一して表せます。

  1. Cloud Run*8 のサービスの作成
  2. 指定したDockerイメージを、1で作成した Cloud Run サービス上で実行
  3. 1で作成したサービスの削除

このため、各処理のパラメータになる部分*9だけ解決した上で、上記の処理を必要な回数呼び出せば求める挙動が得られます。

Workflows 設定ファイル内では、サブワークフローという、プログラミング言語の関数相応の仕組みが提供されています。
これを用いて上記の共通処理は設定ファイル上でプロシージャー化してしまい、コード生成時はそれにパラメータを付与して呼び出す記述を作るだけで済むようにしました。

もう少し具体的には、上述の処理をサブワークフローとして記述したものを固定ファイルとして事前に用意しておいて、バッチ処理でそのサブルーチンの呼び出し部分の記述を生成して、そのファイルに追記する形を取りました。

このバッチ処理は、Cloud Scheduler*10 から定期呼び出しする形で Cloud Run 上で動かしています。

まとめ

GCP Workflows 使用の一例として、FeedTerminal におけるフィードデータの取得・加工・送信の一連の処理の管理の例を紹介しました。
ワークフローの実行ごとに設定ファイルを動的に生成する点が多少特殊な事例だったかなと思います。

Opt Technologies ではエンジニアを募集中です。カジュアル面談も可能ですので、下記リンク先よりお気軽にご応募ください。

https://opt-technologies.jp/#recruit

*1:本題とあまり関係がないので詳しくは触れません

*2:Data Feed Optimization の略

*3:e.g. 商品データ

*4:具体的には、テーブルデータに対する操作になります。

*5:広告媒体によって、求められるデータのフォーマットや送信プロトコルが変わってくるので、その部分をクッションしています。

*6:他にも Cloud Composer が似たような用途で使えるサービスとして候補に上がりましたが、機械学習ワークフロー向けに特化したサービスに見えたので避けました。

*7:アカウントは顧客ごとに割り当てられます。

*8:フルマネージドでサーバーレスなコンテナ実行環境を提供するGCPサービス

*9:使用するDockerイメージだったり、どのアカウントのフローであるかの情報だったり。

*10:cron のように、定期的にプロセスを呼び出してくれる GCP サービス