Eventarc を使用すると、基盤となるインフラストラクチャを実装、カスタマイズ、またはメンテナンスすることなく、イベント ドリブン アーキテクチャを構築できます。Eventarc は、分離されたマイクロサービス間の状態変更（イベント）フローを管理するための、標準化されたソリューションを提供します。トリガーされると、Eventarc は配信、セキュリティ、認可、オブザーバビリティ、エラー処理の管理を行いながら、これらのイベントをさまざまな宛先にルーティングします（このドキュメントのイベントの宛先を参照）。
Eventarc は、Google Cloud コンソール、gcloud CLI を使用したコマンドライン、または Eventarc API を使用して管理できます。
Eventarc は、これらの認証と標準に準拠しています。
1 Google プロバイダからのイベントは、ソース（Cloud Storage など）から直接送信されるか、Cloud Audit Logs のエントリを介して送信されます。これらのイベントは、トランスポート層として Pub/Sub を使用します。Pub/Sub ソースからのイベントは、既存の Pub/Sub トピックを使用できます。または、Eventarc によりトピックが自動的に作成され、管理されます。
2 Google Kubernetes Engine（GKE）クラスタで実行されている Knative serving サービスなど、GKE の宛先のイベントの場合、Eventarc のイベント フォワーダーを使用して新しいイベントを Pub/Sub から pull し、宛先に転送します。このコンポーネントは、Pub/Sub トランスポート層とターゲット サービスの間の仲介役として機能します。これにより、設定やメンテナンスが簡素化されます。これは既存のサービスで動作するだけでなく、シグナリング サービス（フルマネージド クラスタ外に公開されていないサービスを含む）もサポートします。イベント フォワーダーのライフサイクルは Eventarc によって管理されるため、誤ってイベント フォワーダーを削除すると、Eventarc はこのコンポーネントを復元します。
3 ワークフロー実行用のイベントは、変換されてランタイム引数としてワークフローに渡されます。Workflows は、定義された順序で Google Cloud と HTTP ベースの API サービスを組み合わせてオーケストレーションを行います。
4 Cloud Functions（第 2 世代）のすべてのイベント ドリブン関数は、Eventarc トリガーを使用してイベントを配信します。Cloud Functions インターフェースを使用して Cloud Functions の関数をデプロイするときに、Eventarc トリガーを構成できます。
主なユースケース
Eventarc は、宛先のアプリケーションの多くのユースケースをサポートしています。以下に例を示します。
| 構成とモニタリング |
|
| 調整 |
|
| 分析 |
|
イベント
イベントとは、オカレンスとそのコンテキストを表すデータレコードです。イベントは、他のイベントから独立した個別の送受信の単位です。たとえば、データベース内のデータの変更、ストレージ システムへのファイルの追加、スケジュールされたジョブなどがイベントに該当します。
Eventarc でサポートされているイベントタイプをご覧ください。
イベント プロバイダ
イベントは、イベント プロバイダ（送信元）から関心のあるイベント コンシューマーにルーティングされます。ルーティングはイベントに含まれている情報に基づいて実行されますが、イベントは特定のルーティング先を識別しません。Eventarc では次のプロバイダのイベントがサポートされています。
- 130 を超える Google Cloud プロバイダ。これらのプロバイダは、ソースから直接、または Cloud Audit Logs のエントリを介してイベント（Cloud Storage バケット内のオブジェクトの更新や、Pub/Sub トピックへのメッセージの公開など）を送信します。
- サードパーティ プロバイダ。これらのプロバイダは、ソースから直接イベントを送信します（Datadog や Check Point CloudGuard プラットフォームといったサードパーティの SaaS プロバイダなど）。
イベントの宛先
イベントは、Pub/Sub push サブスクリプションを介して、イベント レシーバ（またはコンシューマ）と呼ばれる特定の宛先（ターゲット）にルーティングされます。
Cloud Functions（第 2 世代）
Cloud Functions（第 2 世代）のすべてのイベント ドリブン関数は、Eventarc トリガーを使用してイベントを配信します。Eventarc トリガーを使用すると、Eventarc でサポートされている任意のイベントタイプで関数をトリガーできます。Cloud Functions インターフェースを使用して Cloud Functions の関数をデプロイするときに、Eventarc トリガーを構成できます。
Cloud Run
Cloud Run にデプロイ可能なイベント レシーバー サービスをビルドする方法を確認してください。
Cloud Run サービスに対するイベントの最適なルーティング方法を決定するには、イベント ルーティング オプションをご覧ください。
GKE
Eventarc は、Google Kubernetes Engine（GKE）サービスをターゲットとするトリガーの作成をサポートしています。これには、GKE クラスタで実行される限定公開サービスと公開サービスのパブリック エンドポイントが含まれます。
Eventarc で、任意のクラスタ内のサービスをターゲットにして管理するには、Eventarc サービス アカウントに必要な権限を付与する必要があります。
宛先サービスが実行されている GKE クラスタで Workload Identity を有効にする必要があります。Workload Identity は、イベント フォワーダーを適切に設定するために必要です。セキュリティのプロパティと管理性が優れているため、GKE 内で実行されているアプリケーションから Google Cloud サービスにアクセスする場合におすすめの方法です。詳細については、Workload Identity の有効化をご覧ください。
VPC ネットワークの内部 HTTP エンドポイント
Virtual Private Cloud（VPC）ネットワークの内部 HTTP エンドポイントへのイベント ルーティングを構成できます。トリガーを構成するには、ネットワーク アタッチメント ID も指定する必要があります。詳細については、VPC ネットワークの内部 HTTP エンドポイントにイベントを転送するをご覧ください。
Workflows
ワークフローの実行は、以下によってトリガーされます。
- Pub/Sub トピックにメッセージがパブリッシュされた場合
- トリガーのフィルタ条件に一致する監査ログが作成された場合
- Cloud Storage バケット内のオブジェクトの更新など、仲介されていないイベントが発生した場合
Workflows では、Eventarc トリガーがワークフロー実行の呼び出しに使用する IAM サービス アカウントのメールアドレスが必要です。必要なリソースにアクセスするために必要な最小権限を持つサービス アカウントを使用することをおすすめします。詳細については、サービス アカウントの作成と管理をご覧ください。
イベントの形式とライブラリ
Eventarc は、プロバイダに関係なく、バイナリ コンテンツ モードで HTTP リクエストを使用して、ターゲットの宛先に CloudEvents 形式でイベントを配信します。CloudEvents は標準的な方法でイベント メタデータを記述するための仕様で、Cloud Native Computing Foundation の Serverless Working Group が管理しています。
イベント プロバイダに応じて、イベント ペイロード データのエンコードを application/json または application/protobuf として指定できます。プロトコル バッファ（Protobuf）は、構造化データをシリアル化するための拡張可能なメカニズムで、言語やプラットフォームに依存しません。次の点にご注意ください。
- カスタムソースまたはサードパーティ プロバイダの場合、または Pub/Sub からの直接イベントの場合、このフォーマット オプションはサポートされていません。
- JSON 形式のイベント ペイロードは Protobuf 形式のイベントよりも大きく、イベントの宛先とイベントサイズの制限によっては信頼性に影響する可能性があります。詳細については、既知の問題をご覧ください。
Cloud Functions、Cloud Run、GKE などの宛先は、HTTP 形式のイベントを使用します。Workflows の宛先の場合、Workflows サービスがイベントを JSON オブジェクトに変換し、ランタイム引数としてワークフロー実行に渡します。
標準的な方法でイベント メタデータを記述すると、整合性、ユーザー補助、ポータビリティが維持されます。イベント コンシューマーはこれらのイベントを直接読み取ることも、さまざまな言語（C#、Go、Java、Node.js、Python など）で Google CloudEvents SDK およびライブラリを使用してイベントを読み取り、解析することもできます。
すべてのイベントの HTTP 本文の構造は、Google CloudEvents GitHub リポジトリで入手できます。
下位互換性
Eventarc では、次の属性とフィールドの追加で下位互換性が考慮されています。
- オプションのフィルタリング属性または出力専用属性
- イベント ペイロードへのオプション フィールド
Eventarc トリガー
イベントは、ターゲットの宛先が反応するかどうかにかかわらず発生します。イベントへのレスポンスは、トリガーを作成して行うこともできます。トリガーの使用は、ユーザーが特定イベントや複数のイベントに関心があることを示すものです。トリガーを作成するときに、イベントソースからターゲット宛先へのルーティングなど、特定のイベントをキャプチャして処理できるフィルタを指定します。詳細については、トリガー リソースの REST 表現とイベント プロバイダと宛先をご覧ください。
Eventarc 用に作成された Pub/Sub サブスクリプションは、アクティビティに関係なく保持され、期限切れになることはありません。サブスクリプションのプロパティを変更するには、サブスクリプションのプロパティをご覧ください。
Eventarc は、以下のイベントタイプのトリガーをサポートしています。
| Cloud Audit Logs（CAL）イベント | |
|---|---|
| 説明 | Cloud Audit Logs では、Cloud のプロジェクト、フォルダ、組織ごとに管理アクティビティとデータアクセス監査ログが提供されます。Google Cloud サービスは、これらのログにエントリを書き込みます。サポートされているイベントのリストには、serviceName 値と methodName 値のディレクトリが含まれています。 |
| イベント フィルタの種類 | type=google.cloud.audit.log.v1.written の Eventarc トリガーは、トリガーのフィルタ条件に一致する監査ログが作成されたときに、サービスまたはワークフローにリクエストを送信します。 |
| 直接イベント | |
| 説明 | Eventarc は、Cloud Storage バケットの更新、Firebase Remote Config テンプレートの更新、Google Cloud サービスのリソースに対する変更など、さまざまな直接イベントによってトリガーされます。 また、Eventarc は、Pub/Sub トピックに公開されたメッセージによってトリガーできます。Pub/Sub は、グローバルに分散されたメッセージバスで、必要に応じて自動的にスケーリングされます。Eventarc は、Pub/Sub トピックのメッセージで呼び出すことができるため、宛先として Pub/Sub をサポートする他のサービスと統合できます。 |
| イベント フィルタの種類 | 特定のイベント フィルタ タイプの Eventarc トリガーは、トリガーのフィルタ条件に一致するイベントが発生すると、サービスまたはワークフローにリクエストを送信します。たとえば、type=google.cloud.storage.object.v1.finalized（Cloud Storage バケットにオブジェクトが作成された場合）や type=google.cloud.pubsub.topic.v1.messagePublished（指定した Pub/Sub トピックにメッセージがパブリッシュされた場合）に一致するとリクエストが送信します。 |
トリガーのロケーション
Cloud Storage などの Google Cloud サービスは、リージョンまたはマルチリージョンに設定できます。Cloud Build などの一部のサービスはグローバルに設定できます。
Eventarc では、リージョン トリガーを作成できます。また、一部のイベントに対しては、グローバル トリガーを作成して、すべてのリージョンからイベントを受信することもできます。詳細については、Eventarc のロケーションについてをご覧ください。
イベントを生成する Google Cloud サービスのロケーションと一致するように、Eventarc トリガーのロケーションを指定する必要があります。これにより、グローバル トリガーによって発生するパフォーマンスやデータ所在地の問題を回避できます。
各コマンドで --location フラグを使用して、トリガーのロケーションを指定します。宛先が Cloud Run の場合、--destination-run-region フラグを指定しないと、サービスはトリガーと同じリージョンにあるとみなされます。詳細については、Google Cloud CLI リファレンスをご覧ください。
信頼性と配信
配信の期待値は次のとおりです。
- Cloud Audit Logs を使用するイベントは 1 分未満で配信されます（ただし、Cloud Audit Logs トリガーは直ちに作成されますが、トリガーが伝播されてイベントがフィルタされるまでに最大で 2 分かかることがあります）。
- Pub/Sub を使用するイベントは秒単位で配信されます。
配信で先着順や先入れ先出しの保証はありません。厳密な順序付けを行うと、Eventarc のトランスポート層である Cloud Pub/Sub の可用性とスケーラビリティの機能が低下するので注意してください。詳細については、メッセージの順序指定をご覧ください。
レイテンシとスループットはベスト エフォートです。これらは、Eventarc トリガーがリージョン、マルチリージョン、グローバルかどうか、特定のサービスの構成、Google Cloud リージョン内のリソースのネットワーク負荷など、複数の要因によって変わります。
Eventarc には使用量の割り当てと上限があります。また、Workflows 固有の使用量の割り当てと上限もあります。
イベントの再試行ポリシー
Eventarc の再試行の特性は、そのトランスポート層である Cloud Pub/Sub の再試行の特性と一致します。詳細については、リクエストの再試行と push バックオフをご覧ください。
Eventarc によって設定されたデフォルトのメッセージ保持期間は 24 時間です（指数バックオフ遅延があります）。
Eventarc トリガーに関連付けられた Pub/Sub サブスクリプションを介して、再試行ポリシーを更新できます。
- トリガーの詳細ページを開きます。
- トピックをクリックします。
- [サブスクリプション] タブをクリックします。
Eventarc によって自動的に作成されるサブスクリプションの形式は、projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID です。サブスクリプションの上限の詳細については、Pub/Sub リソースの上限をご覧ください。
Pub/Sub がメッセージの配信を試み、宛先がメッセージを確認応答できない場合、Pub/Sub は最小指数バックオフ（10 秒）でメッセージを再送します。宛先がメッセージの確認応答を返さない状態が続くと、再試行が行われるまでの待機時間が増え（最大 600 秒）、その待機時間の後に宛先に対してメッセージが再送されます。
ワークフロー実行が開始するとすぐに、Workflows はイベントの確認応答を行います。
デッドレター トピック
宛先がメッセージを受信しない場合は、配信不能メッセージをデッドレター トピック（デッドレター キュー）に転送できます。デッドレター トピックには、宛先が認識できないメッセージを格納できます。デッドレター トピックは、Pub/Sub トピックの作成時や Eventarc による Pub/Sub トピックの作成時ではなく、Pub/Sub サブスクリプションを作成または更新するときに設定する必要があります。詳細については、メッセージ エラーの処理をご覧ください。
再試行が保証されないエラー
アプリケーションがイベントソースとして Pub/Sub を使用し、イベントが配信されない場合、イベントは自動的に再試行されます。ただし、再試行を保証しないエラーの場合は再試行されません。ワークフローが実行されなければ、任意のソースからワークフローの宛先へのイベントは再試行されません。ワークフロー実行が開始して、その後失敗した場合、実行は再試行されません。このようなサービスの問題を解決するには、ワークフロー内でエラーや再試行に対処する必要があります。
重複するイベント
重複するイベントがイベント ハンドラに配信される場合があります。CloudEvents 仕様により、source 属性と id 属性の組み合わせは一意と見なされるため、同じ組み合わせを持つイベントは重複と見なされます。一般的なベスト プラクティスとして、べき等イベント ハンドラを実装する必要があります。
オブザーバビリティ
Eventarc、Cloud Run、GKE、Pub/Sub、Workflows の詳細ログは、Cloud Audit Logs から取得できます。
障害復旧
ゾーンとリージョンを利用すると、停止時の信頼性を確保できます。Eventarc を使用する場合のバックアップと復旧の時間について RTO（目標復旧時間）と RPO（目標復旧時点）を満たすようにする方法については、クラウド インフラストラクチャの停止に対する障害復旧の設計をご覧ください。