2023.07.24 コラム
【テックコラム】 Google Cloud の Workflows について
● はじめに
こんにちは、DataCurrent の不破です。
今回は、Google Cloud サービスの1つである Workflows ついてご紹介したいと思います。
※本コラムの内容は2023年7月時点の内容である点にご留意ください。
● Workflows の概要
Workflows は、YAML または JSON 形式でデータフローを定義し各サービスを実行できる、オーケストレーションプラットフォームです。Google Cloud のコンソール画面から、Workflows を利用することが可能です。
Workflows はサーバーレスでオートスケールにも対応しているため、基本的にユーザーはインフラ面を気にすることなく利用することができます。
また Workflows を利用して様々な Google Cloud サービスや API を組み合わせることで、複数のサービスを利用するアプリケーションやデータパイプラインの構築、プロセスの自動化等が実現できます。以下は、Workflows で利用できる Google Cloud サービスの例です。
・Cloud Storage
・BigQuery
・Cloud Run
・Cloud Functions
・Firestore
● Workflows のユースケース
下図は、公式サイト に掲載されている Workflows のユースケースです。
このユースケースでは、以下の流れで Workflows による複数サービスのオーケストレーションが行われています。
- Cloud Storage へファイルがアップロードされたら、そのイベントをトリガーに Workflows を実行開始
- Workflows から Cloud Functions を実行し、Cloud Functions 内のプログラムでファイルの拡張子を判別（.txt / .jpg / .png / .mpg / .mpeg）
- ファイルの拡張子に応じて異なる Google Cloud の API を実行
- .txt の場合、Cloud Natural Language APIを呼び出し
- .jpg, .png の場合、Cloud Vision APIを呼び出し
- .mpg, .mpeg の場合、Cloud Video Intelligence APIを呼び出し
- API から返されたデータを Firestore へ保存
このように、特定のイベント発生をトリガーとして Workflows を実行することも可能です。
Workflows で利用できるトリガーは、以下の4種類です。
| トリガーの種類 | 説明 |
|---|---|
| 手動実行 | コンソールまたはCLIから実行 |
| 自動実行 | Workflows API の Cloud クライアントライブラリまたは REST API を使用して実行 |
| 定期実行 | Cloud Scheduler から特定のスケジュールを指定して実行 （毎週月曜午前 9 時や 15 分毎など） |
| イベント駆動型実行 | Eventarc API を有効にして、イベントトリガーで実行 （Cloud Storage へのオブジェクトアップロードイベントや Pub/Subトピックへのメッセージ送信イベント等） |
● Workflows の料金
Workflows の料金は 公式サイト に記載の通り、実際に実行されたワークフローの「ステップ数」に応じた従量課金となっています。ステップとは、ワークフロー内に定義された個別のタスクのことを指します。
| ステップの 種類 | 月間の費用 |
|---|---|
| 内部ステップ | 最初の 5,000 ステップ：無料 5,000 ステップ以降 ：1,000 ステップあたり $0.01 |
| 外部ステップ | 最初の 2,000 ステップ：無料 2,000 ステップ以降 ：1,000 ステップあたり $0.025 |
ステップには「内部」と「外部」の2種類があり、「内部ステップ」とは、ワークフロー実行時に Google Cloud 内部で実行されるステップのことを指します。それに対して「外部ステップ」とは、Google Cloud の外部にあるリソースに対する HTTP リクエストを行うステップや、Google Cloud リソースであってもカスタムドメインを使用しているエンドポイントへのリクエスト等を指します。
月間の無料枠があるので、テスト的に実行するワークフローや小規模なワークフローは無料枠に収まる可能性もあり、比較的費用を抑えられる料金体系となっています。
● YAML/JSON形式の定義ファイルの書き方
それでは、具体的に Workflows の使い方について見ていきましょう。Workflows では、YAML または JSON 形式でデータフローを定義します。以下は、YAML形式の構文の例です。
基本的にワークフローは、上から下へ記述した順にステップ（step）が実行されます。
ステップとは各処理の単位を表し、各ステップ内では変数の定義、Cloud Run や Cloud Functions の実行、BigQuery への SQL の投入、サブワークフローの呼び出しなどの、個別の処理を行います。ワークフロー内で実行されたステップ（内部/外部）の数が、「Workflows の料金」の章で説明した月額の利用料金に影響します。
定義ファイルは１個のメインワークフローと０個以上のサブワークフローで構成され、全てのワークフロー（メイン/サブ）には１個以上のステップが含まれます。
ワークフローでは、下記の表のとおり分岐・繰り返し・並列処理を含む複雑な処理を使用した構築が可能です。
| 機能 | 説明 |
|---|---|
| 条件分岐 | switch 条件式によるワークフローの分岐処理 |
| 繰り返し | for文による繰り返し処理 |
| 並列処理 | parallel によるステップの並列実行 |
| サブワークフロー | プログラミング言語の関数のように、特定の処理を任意のタイミングで実行 |
● Workflows の作成・デプロイ・実行方法
定義ファイルが用意できたら、いよいよコンソール画面でワークフローを作成します。
Workflows のコンソール画面では、複数のワークフローを設定することができます。
ワークフローを作成し、ワークフロー名やリージョン、サービスアカウント等の項目を設定します。使用するサービスアカウントには、事前に適宜権限を付与する必要があります。例えば Cloud Logging にワークフローのログを送信するには [ログ書き込み] 権限、ワークフローから Cloud Run を実行するには [Cloud Run 起動元] 権限の付与が必要です。
次の画面で、事前に用意した YAML または JSON 形式の定義ファイルの中身を貼り付けます。そうすると、右側の画面にデータフローが可視化されます。デプロイボタンからデプロイをすると、ワークフローが作成されます。
デプロイが完了したら実行画面にアクセスし、ワークフローを実行します。
ワークフロー実行時にはオプションとして、コンソール画面からワークフローに対してランタイム引数を受け渡すことができます。ランタイム引数は、JSON形式の文字列で記述します。（例：{“firstName”:”Taro”,”lastName”:”Yamada”}）
引数を受け渡す場合は、定義ファイル側も予め引数を受け取れるように記述しておく必要があります。特に引数の受け渡しが必要無い場合は、そのまま実行します。
ワークフローの実行が開始すると下記のような画面になります。
実行状態の箇所には、今処理されているステップの名前や、実行ステータスが表示されます。
またワークフローから出力された結果やログも表示されますので、想定通りにワークフローが実行できているかどうかを確認することができます。
● Workflows でできることの例
ここからは、Workflows で実行できる処理の例をいくつかご紹介します。
例えば、ワークフローから Cloud Run や Cloud Functions に設定したプログラムを実行する場合は、各エンドポイントURLへのHTTPリクエストを「call: http.get」で実行します。
下記のYAMLでは、Cloud Run または Cloud Functions から返却（return）された値を 2つ目のステップの ${theMessage.body} に代入し、最終的に実行結果の出力画面に表示するよう設定しています。
また、ワークフローを使用して Cloud Storage 上にあるファイルの内容を BigQuery へ書き込む場合は、「call: googleapis.bigquery.v2.jobs.insert」という記述でBigQueryのコネクタを利用します。
下記のYAMLでは、1つ目のステップで変数を定義し、2つ目のステップで「call: googleapis.bigquery.v2.jobs.insert」を実行して、Cloud Storage → BigQuery のデータ連携を行っています。BigQuery のクエリ結果は3つ目のステップの ${query_result} に代入され、最終的に実行結果の出力画面に表示されます。
上記の例のように、Workflows には Google Cloud の各種サービス間のデータ連携を容易に実現するためのコネクタが多数用意されています。
下記のリンクにサポートされているコネクタの一覧が記載されていますので、ご参考ください。Connectors reference | Workflows | Google Cloud
上記にあげた2つの例を組み合わせて、下記のような処理を行うことも可能です。
下記のYAMLでそのデータフローを定義しています。
この例では、コンソール画面から {“firstName”:”Taro”,”lastName”:”Yamada”} というランタイム引数をワークフローに受け渡し、Cloud Run → Cloud Storage → BigQuery の順に値を受け渡して最終的に BigQuery テーブルへ「Hello Taro Yamada!」という文言を書き込む処理を行っています。
このように、YAML または JSON 形式でワークフローの中で実行したい処理をステップとして順に記述し、HTTPリクエストやコネクタを組み合わせることによって、複数のサービス間のデータ連携を実現することができます。
また、先述の通りワークフローは Cloud Scheduler と組み合わせて定期的に自動実行することもできるので、定期的に決まった処理を実行したいバッチ処理にも、ワークフローを活用することができます。
● Workflows と Composer との比較
Workflows とよく似た機能で Composer という別の Google Cloud のサービスがあり、弊社ではケースバイケースで両機能を使い分けています。
Composer も Workflows と同じワークフローの機能を持ちますが、Workflows が Google独自のソフトウェアであるのに対して、Composer は Airflow というオープンソースのソフトウェアを使用しています。
下記は、弊社にてまとめた Workflows と Composer の比較表です。
| 項目 | Workflows | Composer |
|---|---|---|
| 役割 | ワークフロー | ワークフロー |
| ソフトウエア | Google独自 | Airflow という OSS |
| インフラ管理 | サーバレス （利用者はサーバの存在を意識しなくてよい） | フルマネージド （利用者はサーバの存在を意識する必要があるが、 管理の多くはベンダーが対応） |
| スケジュール管理 | Cloud Sheduler と連携して利用可能 | Composer の機能として利用可能 |
| 開発言語 | YAML、JSON | Python |
| オペレータ | 各 Google Cloud サービス のオペレータ、HTTPリクエスト | Airflow のオペレータ （独自に作ることもできる） |
| エラー対応 | リトライではなく、再実行 | リトライや、途中のタスクからの実行 |
| コスト | 実行されたワークフローのステップ数による従量課金 | 最小構成で月額 約7万円程度～従量課金だが、一時停止できないので実質月額ほぼ固定 |
Workflows はGoogle独自のソフトウェアということもあり、1つのコンソール画面上で作業が完結するのでデプロイ方法は至ってシンプルです。Composer は Airflow を使用しているので、Composer の画面と Airflow の画面で見え方が異なったり、Python 形式の定義ファイルをアップロードする先が Cloud Storage であったりとデプロイ方法は少し複雑になっています。
一方で、機能面では Composer の方が充実している点が多く、任意の環境変数を設定したり、外部ファイルを読み込んだり、処理に失敗したときに途中のタスクから再実行したりすることができますので、より複雑な依存関係がある処理を回す場合は Composer の方が向いているケースがあります。機能面が充実している分、料金面では Composer の方が Workflows よりも割高となっています。
下記に、それぞれのメリット・デメリットをまとめていますのでこちらもご参考ください。
| Workflows | Composer | |
|---|---|---|
| メリット | ・利用料が比較的安い ・従量課金なので小規模から始めやすい ・サーバレスなのでインフラ管理不要 ・Google Cloud サービスのコネクタが多数用意されている | ・複雑な依存関係のあるフローでも可 ・通知なども比較的容易 ・Airflowなので可搬性が高い ・トラブル時に Airflow OSS コミュニティの情報が利用可能 |
| デメリット | ・独自構文の学習が必要 ・Google独自サービスなので可搬性が低い ・トラブル時のサポートが Google のみ | ・Airflow の学習が必要 ・Python の知識が必要 ・利用料が高い ・インフラ管理が大変 |
Composer や Airflow については下記のテックブログでもご紹介していますので、是非ご一読ください。
》【テックコラム】Cloud Run で Cloud Composer の重いタスクを分離する
》【テックコラム】Airflowでslack通知を簡単に実装する方法
● Workflows の使いどころ
Workflows、Composer それぞれ開発言語が異なり学習コストがかかるため、実際の業務の中で両方を天秤にかけることは難しいかもしれませんが、そこまで複雑ではない処理を回す場合や、Google Cloud の世界の中で完結するような処理については、まずはスモールステップとして Workflows を試してみてはいかがでしょうか。
● さいごに
今回は Google Cloud の Workflows という機能についてご紹介しました。
弊社がご提供する「CDP Maker Google Cloud Edition」というサービスでは、Workflows を組み込んだアーキテクチャについてもご提案することが可能です。まずはどんなことができるのか、ご興味がありましたらお気軽にお問合せください。
》CDP利活用の課題とソリューション「CDP Maker Google Cloud Editon」のご紹介
また、弊社では事業会社様のデジタルマーケティング活動の支援を行っています。
自社に専門人材がいない、リソースが足りない等の課題をお持ちの方に、エンジニア領域の支援サービス（Data Engineer Hub）をご提供しています。
お困りごとございましたら是非お気軽にご相談ください。
