このページは Cloud Translation API によって翻訳されました。

Eventarc Standard の概要

Eventarc を使用すると、基盤となるインフラストラクチャを実装、カスタマイズ、またはメンテナンスすることなく、イベントドリブンアーキテクチャを構築できます。

Eventarc には、Eventarc Advanced と Eventarc Standard の 2 つのエディションがあります。どちらのエディションも、スケーラブルでサーバーレスのフルマネージドイベントソリューションを提供します。このソリューションを使用すると、ソースからターゲットにイベントを非同期でルーティングできます。詳細については、Eventarc Advanced または Eventarc Standard を選択するをご覧ください。

Eventarc Standard は、分離されたマイクロサービス間の状態変更（イベント）フローを管理するための、標準化されたソリューションを提供します。トリガーされると、Eventarc Standard は配信、セキュリティ、認可、オブザーバビリティ、エラー処理の管理を行いながら、これらのイベントをさまざまな宛先にルーティングします（このドキュメントのイベントの宛先を参照）。

Eventarc は、 Google Cloud コンソール、gcloud CLI を使用したコマンドライン、または Eventarc API を使用して管理できます。

Eventarc はイベントプロバイダで発生したイベントをイベントの宛先にルーティングします — Eventarc Standard を使用すると、イベントプロバイダからイベントの宛先にイベントをルーティングできます（図をクリックすると拡大します）。

¹ Google プロバイダからのイベントは、ソース（Cloud Storage など）から直接送信されるか、Cloud Audit Logs のエントリを介して送信されます。これらのイベントは、トランスポート層として Pub/Sub を使用します。Pub/Sub ソースからのイベントは、既存の Pub/Sub トピックを使用できます。または、Eventarc によりトピックが自動的に作成され、管理されます。

² Google Kubernetes Engine（GKE）クラスタで実行されている Knative serving サービスなど、GKE の宛先のイベントの場合、Eventarc のイベントフォワーダーを使用して新しいイベントを Pub/Sub から pull し、宛先に転送します。このコンポーネントは、Pub/Sub トランスポート層とターゲットサービスの間の仲介役として機能します。これにより、設定やメンテナンスが簡素化されます。これは既存のサービスで動作するだけでなく、シグナリングサービス（フルマネージドクラスタ外に公開されていないサービスを含む）もサポートします。イベントフォワーダーのライフサイクルは Eventarc によって管理されるため、誤ってイベントフォワーダーを削除すると、Eventarc はこのコンポーネントを復元します。

³ ワークフロー実行用のイベントは、変換されてランタイム引数としてワークフローに渡されます。Workflows は、定義された順序で Google Cloud と HTTP ベースの API サービスを組み合わせてオーケストレーションを行います。

⁴ Cloud Run functions のすべてのイベントドリブン関数は、Eventarc トリガーを使用してイベントを配信します。Cloud Run functions インターフェースを使用して Cloud Run functions をデプロイするときに、Eventarc トリガーを構成できます。

主なユースケース

Eventarc は、宛先のアプリケーションの多くのユースケースをサポートしています。以下に例を示します。

構成とモニタリング	システム構成: 新しい VM が起動したら、構成管理ツールをインストールします。自動修正: サービスが適切に応答していないことを検出して、自動的に再起動します。アラートと通知: 暗号通貨ウォレットアドレスの残高をモニタリングし、通知をトリガーします。
調整	ディレクトリへの登録: 新しい従業員が入社したら、従業員バッジを有効にします。データの同期: CRM システムで、見込み顧客がコンバージョンに至ったときに財務のワークフローをトリガーします。リソースのラベル付け: VM の作成時にラベルを付けて作成者を識別します。
分析	感情分析: Cloud Natural Language API を使用して、カスタマーサービスチケットの完成時に満足度スコアを関連付ける ML モデルをトレーニングしてデプロイします。画像のレタッチと分析: 小売店がオブジェクトストアに画像を追加する際に、背景を削除して画像を自動的に分類します。

イベント

イベントとは、オカレンスとそのコンテキストを表すデータレコードです。イベントは、他のイベントから独立した個別の送受信の単位です。たとえば、データベース内のデータの変更、ストレージシステムへのファイルの追加、スケジュールされたジョブなどがイベントに該当します。

Eventarc でサポートされている Google イベントタイプをご覧ください。

イベントプロバイダ

イベントは、イベントプロバイダ（送信元）から関心のあるイベントコンシューマーにルーティングされます。ルーティングはイベントに含まれている情報に基づいて実行されますが、イベントは特定のルーティング先を識別しません。Eventarc は、130 を超える Google プロバイダのイベントをサポートしています。これらのプロバイダは、ソースから直接、または Cloud Audit Logs のエントリを介してイベント（Cloud Storage バケット内のオブジェクトの更新や、Pub/Sub トピックへのメッセージの公開など）を送信します。

イベントの宛先

イベントは、Pub/Sub push サブスクリプションを介して、イベントレシーバ（またはコンシューマ）と呼ばれる特定の宛先（ターゲット）に転送されます。

Cloud Run

Cloud Run にデプロイ可能なイベントレシーバーサービスをビルドする方法を確認してください。

Cloud Run サービスに対するイベントの最適なルーティング方法を決定するには、イベントルートをご覧ください。

Cloud Run functions

Cloud Run functions のすべてのイベントドリブン関数は、Eventarc トリガーを使用してイベントを配信します。Eventarc トリガーを使用すると、Eventarc でサポートされている任意のイベントタイプで関数をトリガーできます。Cloud Run functions インターフェースを使用して Cloud Run functions をデプロイするときに、Eventarc トリガーを構成できます。

GKE

Eventarc は、Google Kubernetes Engine（GKE）サービスをターゲットとするトリガーの作成をサポートしています。これには、GKE クラスタで実行される限定公開サービスと公開サービスのパブリックエンドポイントが含まれます。

Eventarc で、任意のクラスタ内のサービスをターゲットにして管理するには、Eventarc サービスアカウントに必要な権限を付与する必要があります。
宛先サービスが実行されている GKE クラスタで Workload Identity Federation for GKE を有効にする必要があります。Workload Identity Federation for GKE は、イベントフォワーダーを適切に設定するために必要です。セキュリティのプロパティと管理性が優れているため、GKE 内で実行されているアプリケーションから Google Cloud サービスにアクセスする場合におすすめの方法です。詳細については、Workload Identity を有効にするをご覧ください。

VPC ネットワークの内部 HTTP エンドポイント

Virtual Private Cloud（VPC）ネットワークの内部 HTTP エンドポイントへのイベントルーティングを構成できます。トリガーを構成するには、ネットワークアタッチメント ID も指定する必要があります。詳細については、VPC ネットワークの内部 HTTP エンドポイントにイベントを転送するをご覧ください。

Workflows

ワークフローの実行をトリガーできます。Workflows では、Eventarc トリガーがワークフロー実行の呼び出しに使用する IAM サービスアカウントのメールアドレスが必要です。必要なリソースにアクセスするために必要な最小権限を持つサービスアカウントを使用することをおすすめします。詳細については、サービスアカウントの作成と管理をご覧ください。

イベントの形式とライブラリ

Eventarc は、プロバイダに関係なく、バイナリコンテンツモードで HTTP リクエストを使用して、ターゲットの宛先に CloudEvents 形式でイベントを配信します。CloudEvents は、イベントメタデータを一般的な方法で記述するための仕様です。

イベントプロバイダに応じて、イベントペイロードデータのエンコードを application/json または application/protobuf として指定できます。プロトコルバッファ（Protobuf）は、構造化データをシリアル化するための拡張可能なメカニズムで、言語やプラットフォームに依存しません。次の点にご注意ください。

カスタムソースまたはサードパーティプロバイダの場合、または Pub/Sub からの直接イベントの場合、このフォーマットオプションはサポートされていません。
JSON 形式のイベントペイロードは Protobuf 形式のイベントよりも大きく、イベントの宛先とイベントサイズの制限によっては信頼性に影響する可能性があります。詳細については、既知の問題をご覧ください。

Cloud Run functions、Cloud Run、GKE などの宛先は、HTTP 形式のイベントを使用します。Workflows の宛先の場合、Workflows サービスがイベントを JSON オブジェクトに変換し、ランタイム引数としてワークフロー実行に渡します。

標準的な方法でイベントメタデータを記述すると、整合性、ユーザー補助、ポータビリティが維持されます。イベントコンシューマーはこれらのイベントを直接読み取ることも、さまざまな言語（C++、C#、Go、Java、Node.js、PHP、Python、Ruby など）で Cloud クライアントライブラリを使用してイベントを読み取り、解析することもできます。言語固有の CloudEvents SDK もあります。

すべてのイベントの HTTP 本文の構造は、Google CloudEvents GitHub リポジトリで入手できます。

Eventarc は CloudEvents 形式でイベントを配信します。これらのイベントは直接読み取ることができます。また、Google CloudEvents SDK またはライブラリを使用してイベントを解析することもできます。 — **図 2.** Eventarc は、イベントを CloudEvents 形式でイベントの宛先に配信します。これらのイベントは直接読み取ることができます。また、CloudEvents SDK または Google ライブラリを使用して、イベントの読み取りと解析を行うこともできます。

下位互換性

Eventarc では、次の属性とフィールドの追加で下位互換性が考慮されています。

オプションのフィルタリング属性または出力専用属性
イベントペイロードへのオプションフィールド

Eventarc トリガー

イベントは、ターゲットの宛先が反応するかどうかにかかわらず発生します。イベントへのレスポンスは、トリガーを作成して行うこともできます。トリガーの使用は、ユーザーが特定イベントや複数のイベントに関心があることを示すものです。トリガーを作成するときに、イベントソースからターゲット宛先へのルーティングなど、特定のイベントをキャプチャして処理できるフィルタを指定します。詳細については、トリガーリソースの REST 表現とイベントプロバイダと宛先をご覧ください。

Eventarc 用に作成された Pub/Sub サブスクリプションは、アクティビティに関係なく保持され、期限切れになることはありません。サブスクリプションのプロパティを変更するには、サブスクリプションのプロパティをご覧ください。

Eventarc は、以下のイベントタイプのトリガーをサポートしています。

Cloud Audit Logs（CAL）イベント
説明	Cloud Audit Logs では、Cloud のプロジェクト、フォルダ、組織ごとに管理アクティビティとデータアクセス監査ログが提供されます。 Google Cloud サービスは、これらのログにエントリを書き込みます。監査ログの `serviceName` 値と `methodName` 値を使用して、Eventarc トリガーのフィルタを作成できます。正確な値については、監査ログを使用するGoogle Cloud サービスをご覧ください。詳細については、Cloud Audit Logs のイベントフィルタを決定するをご覧ください。
イベントフィルタの種類	`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 の再試行の特性と一致します。Eventarc によって設定されたデフォルトのメッセージ保持期間は 24 時間です（指数バックオフ遅延があります）。

Eventarc トリガーに関連付けられた Pub/Sub サブスクリプションを介して、再試行ポリシーを更新できます。詳細については、イベントの再試行をご覧ください。

オブザーバビリティ

Google Cloud Observability は、モニタリング、ロギング、診断ツールを提供します。これらのツールを使用すると、Eventarc のアクティビティと増加をモニタリングして分析し、アプリケーションの動作、健全性、パフォーマンスを把握できます。詳細については、Eventarc のオブザーバビリティをご覧ください。

Eventarc、Cloud Run、Cloud Run 関数、GKE、Pub/Sub、Workflows の詳細ログは、Cloud Audit Logs から取得できます。

障害復旧

ゾーンとリージョンを利用すると、停止時の信頼性を確保できます。Eventarc を使用する場合のバックアップと復旧の時間について RTO（目標復旧時間）と RPO（目標復旧時点）を満たすようにする方法については、クラウドインフラストラクチャの停止に対する障害復旧の設計をご覧ください。

コンプライアンス標準

Eventarc Standard は、特定の認証と標準に準拠しています。準拠していない Eventarc Advanced リソースの使用を避けるには、Eventarc Advanced リソースを無効にするカスタム組織のポリシーを作成します。詳細については、Eventarc Advanced リソースを無効にするをご覧ください。