背景
GCSにファイルがuploadされたら、そのイベントをトリガーにそのファイルを処理してBigQueryにLoadする処理を作りたい
先に結論
- Cloud Run + Eventarcの組み合わせが良さそうでした
- コンテナベースでの開発が可能
- CloudFunction(1st gen)に比べるとtimeoutやmemoryなど採用できるリソースが大きい
- 第二世代はCloudRunにかなり寄ってきているらしいがpreviewなのでここでは取り扱わない
- GCSのファイルuploadをトリガーとする場合はEventarcのdirect eventによるトリガーが良さそうでした
Cloud Function? Cloud Run?
イベントドリブンと聞いてまず思い浮かんだのはCloud Functionでした。イベントをトリガーとして処理を動かす場合、以前はCloud Functionが一番手っ取り早く作れた記憶がありました。
現在はEventarcというものが登場していて、お手軽にCloud Runをイベントトリガーで起動可能ということがわかりました。
Cloud Function か Cloud Run か? という選択になると個人的には俄然Cloud Runを使いたい派です。
まずコンテナベースで開発ができる。これが大きいです。
また、Cloud Function(1st gen)比較すると、使用可能なリソースがCloudRunの方が大きいです
- timeoutの最大: Cloud Function 9min vs Cloud Run 1hour
- 最大メモリ搭載: Cloud Function 約8GB vs Cloud Run 32GiB
- cloud run は同時リクエスト 1000 まで可能などなど
Cloud Runを使う前提で考えていくことにしました。
Eventarc
Eventarcとは何なんでしょうか。
イベントドリブンアーキテクチャを実現するための、イベントトリガーの仕組みのようなものですかね。各サービスのイベントのトリガーの仕掛け先として、現在はCloud Run, Cloud Workflows, GKEなどがあります。
Eventarcには3種類あります。
1. Direct Event
Cloud Storage バケットの更新や Firebase Remote Config テンプレートの更新など、Google Cloud プロバイダからの直接イベントによって Eventarc をトリガーできます(サポートされているイベント)
2. Cloud Audit Log経由
Eventarc トリガーのフィルタ条件に一致する監査ログが作成されると、イベントがルーティングされます。 1でサポートされていないイベントは大体ここでサポートされます。
3. Pub/Sub経由
Eventarc トリガーのフィルタ条件で指定された Pub/Sub トピックにメッセージが公開されると、イベントがルーティングされます。これは、サービスによるイベントトリガーではなく、独自のイベントを発生させたい場合などに使うのではないでしょうか。
どれも、Eventarcでのイベントトリガーであれば、CloudEvent形式というHTTPの形式でデータがやり取りされ、統一されたHTTPのヘッダープロトコル上での開発が可能になっています。
で、どれを使えばいいの？
Eventarcの3種類に加え、既存のPubSubを使ったトリガー方法(非Eventarc)も存在します。この4種類のうちどれを使うべきかというのが、公式ドキュメントでフローチャートで解説されています。
優先度としては
- Eventarc(direct event)
- Eventarc(Audit Log経由)
- Eventarc(Pub/Sub経由)
- 既存のPubSub方式
という順序になりそうです。まずは、Eventarc(direct event)で実装できるかを検討しましょう。今回のGCSのファイルuploadはこのEventarc(direct event)で実装可能でした。
参考