Eventarc のイベント フィルタを理解する
Google Cloud Japan Team
※この投稿は米国時間 2021 年 3 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。
Eventarc を使用すると、Google Cloud ソース（監査ログの統合を経由）やカスタムソース（Pub/Sub の統合を経由）からイベントを読み取り、Cloud Run サービスにルーティングできます。
イベントのルーティング ルールは、トリガーによって定義されます。トリガーでは、サービス名、メソッド名、リソース（実質的なイベントソースの定義）、イベントのターゲット（現時点では、Cloud Run サービスのみ）などの適切なイベント フィルタを指定します。
適切なイベント フィルタを使用してトリガーを構成する方法を詳しく見てみましょう。
Cloud Console でのトリガーの作成
適切なフィルタを使用してトリガーを作成するための最も簡単な方法は、Cloud Console を使用することです。[Cloud Run] > [トリガー] に移動してトリガーを作成する際、Pub/Sub または監査ログの統合を経由してサポートされるサービスの一覧が表示されます。
サービス（例: Cloud Storage）を選択すると、そのサービスからトリガーできるイベントの一覧が表示されます。
あとは、その一覧から対象のイベントを選択するだけです。Cloud Console が、適切なフィルタ（サービス名、メソッド名、リソース）を使用してトリガーを作成します。
Cloud Console での作成方法は以上です。では、コマンドラインからトリガーを作成する場合や、API から自動的にトリガーを作成する場合はどうすればよいでしょうか。これらの方法で作成する場合は、適切なフィルタを特定するためにちょっとした作業が必要になります。
gcloud による Pub/Sub トリガーの作成
Pub/Sub トリガーは、コマンドラインから gcloud を使用して非常に簡単に作成できます。
実は、このトリガーは内部で新しい Pub/Sub トピックを作成します。そして、そのトピックからのすべてのメッセージを、指定した地域の Cloud Run サービスにルーティングするルールを設定します。トピック ID を見つける方法について詳しくは、Eventarc ドキュメントをご確認ください。
ここで、既存の Pub/Sub トピックがある場合の対応について疑問に思われるかもしれません。この場合は、transport-topic フラグを使用して Pub/Sub トリガーを作成すると、既存のトピックからのイベントを確実に読み取ることができます。
イベント フィルタは、新規トピックでも既存トピックでも同じです。
gcloud による監査ログのトリガーの作成
監査ログのトリガーは、Pub/Sub だけでなく複数のイベントソースの種類を処理するため、より複雑であるといえます。つまり、目的のイベントをキャプチャするには、より高度なイベント フィルタが必要になります。
たとえば、バケットに新しいオブジェクトが作成されたときに Cloud Storage イベントをキャプチャする場合は、次のようにトリガーを作成できます。
イベントタイプは（Pub/Sub ではなく）監査ログであり、イベント フィルタとして指定されている点にご注意ください。加えて、サービス アカウントについての記載もあります。これは、監査ログベースのイベントソースでは、イベントタイプとサービス アカウントの両方の定義が必要になるためです。
他の 2 つのイベント フィルタ（サービス名とメソッド名）はどうでしょうか。これらのイベント フィルタはイベントソースをさらに絞り込み、特定のサービスにおいて、特定の操作（つまりメソッド）が行われた場合にのみトリガーします。
すべてのサービスで、これらイベント フィルタを見つけるにはどうすればよいでしょうか。これには、次の 3 段階のプロセスが必要です。
サービスの監査ログが有効になっていることを確認する
対象のサービスで操作を行う
監査ログを確認してフィルタに変換する
それぞれのステップについて詳しくご説明します。
監査ログを使用してイベント フィルタを見つける方法
ステップ 1: 監査ログが有効になっていることを確認する
監査ログのトリガーを作成する前に、まずは対象のサービスの監査ログが有効になっていることを確認します。これを行うには、Google Cloud Console の [IAM と管理] > [監査ログ] に移動します。すると、サービスの一覧が表示されます。
対象のサービスを特定したら、そのサービスのすべての監査ログを有効にして保存します。
注意点としては、一部のサービス（例: BigQuery）では、監査ログがデフォルトで有効になっているものがあり、これらは無効にすることができません。このようなサービスはサービス一覧には表示されませんが、問題はありません。監査ログが有効になっているとみなして、次のステップに進みます。
ステップ 2: 対象のサービスで操作を行う
次に、対象のサービスで操作を行います。たとえば、Cloud Storage 内のオブジェクト作成イベントが対象の場合、バケットにオブジェクトを作成するかコピーします。
これはバケットにオブジェクトを作成するだけでなく、そのオブジェクトの監査ログエントリも生成します。次のステップでは、この監査ログを確認します。
ステップ 3: 監査ログを確認してイベント フィルタに変換する
最後のステップでは、前のステップで生成したイベントの監査ログを確認します。
Cloud Console で [ロギング] > [ログ エクスプローラ] に移動します。クエリ結果のセクションには、最近生成されたログが一覧表示されます。クエリビルダーのセクションは、ログのフィルタリングに使用できます。
この例では、Cloud Storage イベントの特定のバケットのみを対象としています。以下のクエリを実行して、結果をフィルタリングします。
特定のバケットだけのログが表示されます。
このログに、storage.objects.create タイプがあるのがわかります。このログタイプは、新しいオブジェクトの作成時に生成されます。展開すると、protoPayload の下に、フィルタリングできるフィールドが表示されます。
serviceName と methodName に注目してください。これらのフィールドは、トリガーで event-filters として使用できます。他には、resourceName フィールドも役立ちます。この省略可能なフィールドは、操作の対象となるリソースまたはコレクションを参照します。省略した場合は、指定した serviceName と methodName のすべてのイベントが配信されます。この例では、作成されたオブジェクトの名前が事前にわからないため、resourceName でフィルタリングしませんでした。現在、イベントのフィルタリングは完全一致にのみ対応しており、そのため活用が難しい場合があります。しかし今後のリリースで、より高度な正規表現やワイルドカード タイプのマッチングに対応する予定です。
次のステップ
Eventarc でイベントソースのトリガーを作成する方法をより深く理解できたところで、次は独自のトリガーを作成してみましょう。開始にあたっては次のリンクも参考になります。
ご不明な点やフィードバックがございましたら、Twitter で @meteatamel までお気軽にお問い合わせください。
-デベロッパー アドボケイト Mete Atamel
