Eventarc

解決する課題

サービス間を直接呼び合う密結合をやめ、「イベントが起きたら処理する」形で連携できます。

• 「S が起きたら T を実行」を 疎結合に組みたい
• Cloud Storage へのアップロードや BigQuery のジョブ完了など、多数のソースのイベントを宛先へ振り分けたい
• 各サービスごとにバラバラなイベント形式を CloudEvents という統一フォーマットで受け取りたい
• イベント受信側を Cloud Run でサーバーレスに保ち、インフラ管理を避けたい

主要概念と用語

• トリガー（Trigger）: 「どのイベントを」「どの宛先へ」送るかを定義する中心リソース。イベントフィルタと送信先をひも付ける
• イベントプロバイダ / イベントタイプ: イベントの発生元と種類。google.cloud.storage.object.v1.finalized（オブジェクト作成）のように type で識別する
• 3 つのソース種別:
  • Cloud Audit Logs 経由: 90 以上の Google Cloud サービスの操作を監査ログ経由で捕捉（serviceName と methodName でフィルタ）
  • Pub/Sub 経由: 既存の Pub/Sub トピックに届いたメッセージをトリガーに
  • 直接イベント: Cloud Storage など一部プロバイダからの直接配信
• イベント宛先（送信先）: Cloud Run サービス / Cloud Run functions / GKE のサービス / Workflows
• CloudEvents: CNCF 標準のイベント記述フォーマット。HTTP POST の本文＋ヘッダーとして宛先に届く
• Eventarc Advanced（バス／パイプライン／登録）: 中央集権の バス にイベントを集め、パイプラインで変換・宛先振り分けを行う上位機能

仕様・制限・クォータ

• 配信は at-least-once（最低 1 回）。同一イベントが複数回届きうるため、宛先は 冪等（idempotent） に設計する
• 内部的に Pub/Sub を配送基盤として利用し、リトライや指数バックオフが効く
• Cloud Audit Logs 経由のトリガーは、対象サービスで データアクセス監査ログ（特に管理読み取り/データ読み取り/データ書き込み）の有効化が必要なものがある
• トリガーは原則 単一リージョン、または global（一部プロバイダ）に作成する。宛先と同一リージョン推奨
• プロジェクト/リージョンあたりのトリガー数などに 割り当て（クォータ） があり、引き上げ申請が可能
• イベント本文の最大サイズは Pub/Sub のメッセージ上限（10 MB）に準じる

内部の仕組み

イベントプロバイダで事象が発生すると、Eventarc はそれを CloudEvents 形式に変換し、配送基盤である Pub/Sub を介して宛先へ HTTP POST で届けます。Cloud Audit Logs ソースの場合は、サービスの操作が監査ログに記録 → Eventarc がログをフィルタ条件と突き合わせ → 一致したものだけをトリガーの宛先へ転送する、という流れです。

• 宛先が Cloud Run の場合、イベントは push 配信で HTTP リクエストとして到達する。Ce-Type などの Ce- プレフィックスのヘッダーにメタデータが入る
• 配送に失敗した場合は Pub/Sub のリトライ機構で再送され、デッドレタートピックへ退避することもできる

設計パターン / ベストプラクティス

• イベント駆動のマイクロサービス連携: Cloud Storage 取り込み → Eventarc → Cloud Run で後続処理、のように疎結合化する
• 冪等な宛先設計: at-least-once のため、イベント ID（id 属性）で重複排除し、二重処理を防ぐ
• フィルタは具体的に: methodName やリソース属性で絞り込み、不要なイベントの受信・課金・誤起動を避ける
• デッドレターと再試行ポリシーを設定し、宛先障害時にイベントを失わない
• 複雑なルーティングや変換が必要なら Eventarc Advanced のバス＋パイプラインでメッセージ変換・条件分岐を集中管理する

運用・監視・トラブルシュート

• Cloud Monitoring / Cloud Logging でトリガーの配信状況・エラーを監視する
• トリガーが発火しない → イベントフィルタ（type / serviceName / methodName）と、必要な 監査ログが有効かを確認
• イベントが宛先に届かない → 宛先サービスの 権限（トリガー用サービスアカウントの呼び出し権限）と リージョン整合を確認
• 監査ログ経由は数十秒〜の遅延が生じうる点を考慮する（ニアリアルタイム）
• 重複到達が疑われる場合は宛先の冪等性とイベント id の扱いを点検する

コスト

Eventarc 自体は配信したイベント数に応じた料金体系で、配送基盤として使う Pub/Sub の利用分も加味して考えます。

セキュリティ

• トリガーには サービスアカウントを割り当て、最小権限の IAM ロール（例: roles/eventarc.eventReceiver）のみ付与する
• 宛先が Cloud Run の場合、トリガー用サービスアカウントに roles/run.invoker を与え、認証付きで呼び出す
• Cloud Audit Logs 経由を使うには、対象サービスでデータアクセス監査ログを有効化する（権限と監査の両立に注意）
• イベントは Google Cloud 内で 転送時に暗号化され、必要に応じて CMEK（顧客管理鍵） で保護できる

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# 宛先となる Cloud Run サービスを先にデプロイしておく前提

# Cloud Storage バケットへのオブジェクト作成イベントを
# Cloud Run サービス(my-service)へ送るトリガーを作成
gcloud eventarc triggers create storage-trigger \
  --location=asia-northeast1 \
  --destination-run-service=my-service \
  --destination-run-region=asia-northeast1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-input-bucket" \
  --service-account=eventarc-sa@PROJECT_ID.iam.gserviceaccount.com

# Cloud Audit Logs 経由: BigQuery のジョブ実行をトリガーにする例
gcloud eventarc triggers create bq-job-trigger \
  --location=asia-northeast1 \
  --destination-run-service=my-service \
  --destination-run-region=asia-northeast1 \
  --event-filters="type=google.cloud.audit.log.v1.written" \
  --event-filters="serviceName=bigquery.googleapis.com" \
  --event-filters="methodName=jobservice.jobcompleted" \
  --service-account=eventarc-sa@PROJECT_ID.iam.gserviceaccount.com

# 作成済みトリガーの一覧と詳細確認
gcloud eventarc triggers list --location=asia-northeast1
gcloud eventarc triggers describe storage-trigger --location=asia-northeast1