コンテンツに移動
サーバーレス

Eventarc: Google Cloud で統合されたイベント エクスペリエンスを提供

2021年1月27日
Google Cloud Japan Team

Google Cloud を試す

$300 分の無料クレジットと 20 以上の無料プロダクトがある Google Cloud で構築を始めよう

無料トライアル

※この投稿は米国時間 2021 年 1 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

先日、マイクロサービスの接続におけるオーケストレーションとコレオグラフィーについての話題を取り上げると同時に、一元的なオーケストレーターのメリットを享受できるユースケースとして Workflows をご紹介しました。また、コレオグラフィー キャンプでは、より疎結合されたイベント ドリブン アーキテクチャに適した Eventarc と Pub/Sub についても言及しました。

このブログ投稿では、Eventarc による統合されたイベント エクスペリエンスについて詳しくご説明します。

Eventarc とは

昨年 10 月、60 を超える Google Cloud ソースから Cloud Run にイベントを送信できる新しいイベント機能、Eventarc を発表いたしました。Eventarc は、さまざまなソースから監査ログを読み取り、それらを CloudEvents 形式のイベントとして Cloud Run サービスに送信します。また、カスタム アプリケーションの Pub/Sub トピックからイベントを読み取ることもできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Diagram2_edit.max-1000x1000.max-1000x1000.png

Cloud Run へのイベントの送信

Cloud Run にイベントを送信する方法は他にもあるため、Eventarc の何が特別なのか不思議に思われるかもしれません。この質問にお答えする前に、まずは他の方法の一つである Pub/Sub について確認してみましょう。

こちらの Cloud Run チュートリアルで Pub/Sub を使用するで説明されているように、Cloud Run サービスは Pub/Sub トピックから push されたメッセージを受信できます。これは、イベントソースが Pub/Sub トピックに直接メッセージを公開できる場合に有効です。また、Pub/Sub と統合しているサービスでも有効で、その統合からイベントを公開できます。たとえば、Cloud Storage もそのようなサービスの一つであり、このチュートリアルには、中間にある Pub/Sub トピックを使用して Cloud Storage バケットから更新情報を受信する方法が示されています。

Pub/Sub に統合されていないその他のサービスの場合、Pub/Sub と統合して、Cloud Run にメッセージをルーティングするように Pub/Sub を構成するか、こうしたイベントを発生させる別の方法を見つける必要があります。これを実現することは可能ですが、決して容易なことではありません。そこで Eventarc の出番です。

すぐに得られる Eventarc のメリット

Eventarc は、イベントを受信するための簡単なパスを提供します。Pub/Sub トピックだけではなく、監査ログや Pub/Sub が統合されている多数の Google Cloud のソースからも受信します。監査ログが統合されているサービスや、Pub/Sub トピックにメッセージを送信できるアプリケーションが Eventarc のイベントソースとなり得ます。Eventarc を使用すると、基盤となるインフラストラクチャを気にする必要はありません。Eventarc は、マネージド サービスであり、クラスタの設定も維持も不要です。

また、簡単な統合のほかにも具体的なメリットがいくつかあり、イベントの生成、ルーティング、使用の方法において、一貫性のある体系化されたアプローチを提供します。それでは、これらのメリットについて確認してみましょう。

簡素化、一元化されたルーティング

Eventarc では、トリガーの概念が導入されています。トリガーは、イベントソースからイベントシンクへのルーティング ルールを指定します。たとえば、以下のように監査ログのトリガーを作成するだけで、Cloud Storage 内の新しいオブジェクト作成イベントをリッスンし、それらを Cloud Run サービスにルーティングすることができます。

読み込んでいます...

代わりに、Pub/Sub からのメッセージをリッスンする場合は、別のトリガーになります。

読み込んでいます...

このトリガーは、内部で Pub/Sub トピックを作成します。アプリケーションはそのトピックにメッセージを送信し、それらのメッセージは Eventarc により指定の Cloud Run サービスにルーティングされます。

ユーザーは、Google Cloud Console の Cloud Run のトリガー セクションでトリガーを作成することもできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/triggers_in_console.max-600x600.png

イベントのルーティングをトリガーとして定義することで、ユーザーはすべてのトリガーを Eventarc で一元管理して表示できます。作成されたすべてのトリガーを表示するには、次のコマンドを使用します。

読み込んでいます...

イベント形式とライブラリの整合性

Eventarc では、複数のソースからのさまざまなイベントが、CloudEvents に準拠したイベントに変換されます。CloudEvents は、イベントデータを標準的な方法で記述するための仕様であり、整合性、アクセス可能性、移植性を目的としています。

CloudEvent には、イベントに関するコンテキストとデータが含まれます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Context_and_Data.max-600x600.png

イベント ユーザーは、これらのイベントを直接読み取ることができます。また、イベントを読み取る CloudEvents SDK や、日付フィールドを解析する Google Events ライブラリで、さまざまな言語(Node.js、Python、Go、Java、C# など)を簡単に使用できるようにしています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Event_libraries.max-1200x1200.png

先ほどの Cloud Storage の例に戻りますが、以下は前述した 2 つのライブラリを使用して Node.js の監査ログにより Cloud Storage イベントを読み取る方法になります。

読み込んでいます...

同様に、以下は C# で Pub/Sub トリガーからメッセージを読み取る方法です。

読み込んでいます...

長期的なビジョン

Eventarc の長期的なビジョンは、より多くのソースやシンクのイベントハブとなり、Google Cloud はもとより、その他のサービスにおいても統一されたイベントを実現することです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Long_term.max-900x900.png

将来的には、より多くの Google Cloud のソース(例: Firestore、BigQuery、Storage)、Google のソース(例: Gmail、ハングアウト、Chat)、サードパーティのソース(例: Datadog、PagerDuty)から、監査ログを介さずにイベントを直接読み取り、それらのイベントをより多くの Google Cloud シンク(例: Cloud Functions、Compute Engine、Pub/Sub)やカスタムシンク(任意の HTTP ターゲット)に送信できることが見込まれます。

Eventarc の現状と将来的なビジョンにおける全体像を把握していただけましたでしょうか。

ご不明な点がございましたら、Twitter で @meteatamel までお気軽にお問い合わせください。

-デベロッパー アドボケイト Mete Atamel

投稿先