はじめに
こんにちは、バックエンドエンジニアのおおたわらです。
今回はGoogle Cloud Workflowsをマイクロサービス開発で使ってみての所感を紹介します。
導入の背景
当ブログでも何度かご紹介していますが、弊社ではマイクロサービス開発を行っています。
その中で、複数のマイクロサービスへの呼び出しを制御するオーケストレーターとしてGoogle Cloud Workflowsを採用しました。
今回構築したのは、Workflowsが各サービス（Cloud Run）を順番に呼び出していくようなものです。リクエストは同期・非同期どちらもあります。
良かった点
構築・運用や設定の手軽さ
Workflowsはサーバーレスです。
ワークフローはサーバーレスで、必要に応じてスケールアップします。また、アイドル状態の間に料金が発生することはありません。ワークフローにコードやライブラリの依存関係は含まれていないため、セキュリティ パッチは必要ありません。ワークフローをデプロイすると、メンテナンスを行わずに確実に実行できます。ワークフローでは、ステータスの保持、再試行、ポーリング、最大 1 年間の待機が可能です。
OSSのワークフローエンジン（digdagなど）をサーバー構築し自前で運用する場合、運用コストがかかります。
また、今回でしたらオーケストレーターのサービスをCloud Run等で用意するなども考えられますが、こちらもコストが気になります。
本格的なワークフローエンジンよりできることは少ないですが、その分インフラのことをあまり考えず、手軽に構築・運用できるのは良い点でした。
また、ワークフローの定義についてもYAMLファイルを作るだけという手軽さです。
必要な機能が揃っている
Workflowsには、マイクロサービスのオーケストレーターとして必要な以下の機能が揃っています。
まずリクエストについてですが、HTTPリクエストに対応しています。（ちなみに、記事公開段階ではgRPCはサポートされていないです。）
外部へのリクエストや、OIDCを使用した認証によりCloud RunやCloud FunctionsなどGoogle Cloud内サービスへのリクエストが可能です。
エラーハンドリングについてはHTTPリクエストの結果に応じた処理の出し分けなどが可能です。例えば、サービスAの結果がエラーならサービスBにこのようなリクエストを送る、などマイクロサービス呼び出しの制御を実現することができます。
リトライは以下のような細かな設定が可能です。
- リトライの条件
- リトライ回数上限
- バックオフの設定
非同期のAPI呼び出しに関しても、以下のような機能で対応が可能です。
料金が安い
（以下の料金の情報は記事公開時点のものです）
地味に嬉しいポイントでした。
実行された分の従量課金で、内部ステップと外部HTTP呼び出しでそれぞれ価格設定されています。例えば、内部ステップは1,000 ステップあたり $0.01です。
Google Cloudの他のワークフローサービスであるCloud Composerは、サーバーレスではないため料金が高めです。小規模環境・7 日間と 12 時間（合計 180 時間）稼働させた場合の金額感として、$83.62と記載があります。
料金 | Cloud Composer | Google Cloud
もちろんステップ数が増えると料金はかさんでしまいますが、今のところ安く運用できています。
また、無料枠もあるので気軽に試しやすいです。
難しかった点・注意点
独自の構文の学習が必要
構文の学習に時間を取られてしまいました。
習得したメンバーは良いですが、新しく入ったメンバーが新規構築や改修を行う際に日頃開発している言語に加えて学習が必要になってしまいます。チーム内で知見を貯めることを意識しました。
ちなみにざっと学習するには、公式のSyntax Cheat Sheetが役に立ちました。
制限事項に注意
（以下の制限事項は記事公開時点の情報です）
実行数、リソースなど様々な制限事項があります。
割り当てと上限 | ワークフロー | Google Cloud
例えば実行数に関しては、「プロジェクトあたり、リージョンあたりのアクティブなワークフロー実行の最大数」が2000という制限があり、大量に並列実行する処理での使用は諦めました。
テストの難しさ
これはどちらかというと開発方法の問題かもしれませんが、Workflowsをテストするためにはリクエスト先のCloud Runがデプロイされている必要があり、アプリケーションコードの開発が終わった後にテストを実施していました。
そのため、実行してから細かい間違い（URLの指定間違いなど）に気づいたり、認証の設定に詰まったりということがありました。
まだあまり良いテスト方法は見つけられていませんが、疎通テストは早い段階でやっておいたほうが良かったです。
デバッグの際にはログを出力する機能が便利でした。
おわりに
Workflowsを採用してみての所感を紹介しました。
機能がシンプルで制限事項なども多い分、ユースケースにはまれば手軽に・安く運用できるのがいいところだと思います。
エモーションテックでは顧客体験、従業員体験の改善をサポートし、世の中の体験を変えるプロダクトを開発しています。プロダクトに興味のある方、マイクロサービス開発をしたい方、ぜひ採用ページからご応募をお願いいたします。
