株式会社HRBrainの非同期ファイル処理アーキテクチャにおけるEventarc

Eventarcを導入した背景は、以下の通りです。

大容量の動画やPDFファイルをAPIサーバー経由で受け取る構成では、ファイルアップロードの処理により、APIサーバーの他APIの処理や、共通APIゲートウェイに影響を与えてしまう可能性があります。そのため、APIサーバーを介さず、安定したCloud Storageへ直接アップロードできる仕組みが必要でした。

また、ファイルの変換処理はCPUリソースを大量に消費し、完了までに時間を要するため、同期的な処理ではAPIサーバーのタイムアウト許容値を超えてしまい、現実的ではありませんでした。そのため、ユーザーのファイルアップロード完了を検知して、処理を担うCloud Runを非同期で起動する仕組みが求められました。

そこで、「google.cloud.storage.object.v1.finalized（アップロード完了）」イベントを直接検知し、後続のファイル処理を行うCloud Runへ自動的にルーティングする連携役として、Eventarcを採用しました。

非同期でイベントをルーティングする仕組みとして、以下を比較検討しました。

• API経由で通知

  • クライアントが、APIサーバーに対してCloud Storageの「アップロード完了」のイベントを送信し、APIサーバーがジョブを起動する構成。

• Pub/Subで通知

  • Cloud Storageの「アップロード完了」のイベントをPub/Subトピックへ通知し、サブスクリプション経由でCloud Runを起動する構成。

API経由のアプローチでは、システムメンテナンス時にAPIサーバー側でリクエストを一律に拒否できるといったメリットがありました。しかし、このメンテナンス時のリクエスト制限については、APIサーバーが発行するCloud Storageの事前署名URLの有効期限を調整することでも代替可能であるため、API方式ならではの決定的な優位性とは言えませんでした。

API経由の構成では、クライアントがCloud Storageへファイルをアップロードした直後に通信の瞬断などが起きた場合、「ファイルのアップロード」と「APIサーバーへのジョブ起動リクエスト」という一連のステップが途中で分断されるリスクがありました。このステップ分断によってファイルだけがストレージに残存する問題自体は、変換前バケットのオブジェクトライフサイクル設定によって自動削除することで解決可能です。しかし、「ファイルはアップロードされたのに処理が開始されない」という不整合な状態に陥るリスクは残ります。したがって、後続処理のトリガーを、通信状態という不確実な要素を含むクライアントの挙動に依存させる構成は、システムの信頼性に欠けると判断しました。そのため、Google Cloud側でのファイルアップロード検知を起点として、確実に処理を実行するイベント駆動アーキテクチャを採用しました。

また、イベント駆動を実現するにあたり、「Cloud Storageの更新通知を受け取る」というシンプルな要件であったため、変換前バケットのオブジェクト更新の検知からCloud Runの起動までを一気通貫で仲介してくれるEventarcを採用しました。これにより、実装および運用コストを抑えつつ、イベント連携を実現できると判断しました。

イベントのルーティング設計において、フォルダ構成（変換前バケットパス）に起因する依存関係をインフラとアプリケーションのどちらに担わせるかは検討課題でした。

Eventarcには、Cloud Storageのパス単位で直接イベントをフィルタリングできないという技術的な制約がありました。また、仮にEventarc側でパスごとの振り分けを実現しようとした場合、変換前バケットパス情報がインフラ側に漏れ出ることになります。その結果、フォルダ構成が変更されるたびにインフラ側の修正が必要となり、インフラとアプリケーションが密結合に陥る懸念がありました。

そこで本設計では、Eventarc側での振り分けは行わず、すべてのアップロードイベントをCloud Runの単一エンドポイントへ転送する構成を採用しました。イベントを受信したアプリケーション側でバケットのパス情報を解析し、内容に応じて適切なハンドラーへ動的にルーティングしています。