Cloud Monitoring の通知チャネルとして Pub/Sub が利用可能に

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

運用業務の担当者にとって、機械的な作業（いわゆる「手間のかかる仕事」）にとられる時間を減らし、もっと有益な作業に時間を費やしたいというのは世界共通の願いであり、こうした背景から、モニタリング ワークフローやアラート送信ワークフローの自動化が進められています。たとえば、Google のサイト信頼性エンジニアリング（SRE）部門は、SRE の業務のうち、機械的な作業にとられる時間を 50% 未満に抑えることを目標に掲げ、より意義深いエンジニアリング プロジェクトに時間を充てることを目指しています。

Google の Cloud Monitoring サービスでは、多様な通知チャネルからアラートを送信することが可能です。たとえば、通知チャネルの一つである Webhook は、アプリケーション内で発生したエラーや異常に対してプログラムで対応できるのが特長であり、この仕組みを利用すれば、システムの一部を自動化することが可能です。

本日、新たな通知チャネルとして Cloud Pub/Sub が加わることを発表いたします。現在ベータ版であるこの統合により、アラートに対応する、プログラムを使用した自動化ワークフローを作成できます。Pub/Sub とは、疎結合のアプリケーションを構築できるパブリッシュ / サブスクライブ キューです。Pub/Sub を通知チャネルとして使用すれば、アラート送信やインシデント対応のワークフローで、サードパーティのプロバイダと統合しやすくなります。Pub/Sub は、API や Google Cloud Console を通じて、通知チャネルとして使用できます。

Pub/Sub と Webhook

サードパーティのパッケージとの統合には、Webhook を利用することも可能です。では、Webhook よりも Pub/Sub のほうが適しているのはどんな場合でしょうか。この 2 つには、それぞれに適した使い方があります。Pub/Sub と Webhook の主な違いは、呼び出しが暗黙的か明示的かと、持続性、そして認証方法です。

Webhook が適しているケース

Webhook は明示的な呼び出しを前提としており、Webhook の実行処理は、常にパブリッシャー（クライアント）側で制御します。一方、実行のタイミングやアラート メッセージの処理は、サーバーが行います。また、エラーが発生した場合、Webhook は再配信を数回試みますが、対象のエンドポイントが利用不可な状態が長く続くと、通知は完全に破棄されます。また、Webhook でサポートされているのは基本認証またはトークン認証のみとなります。

Webhook が適しているのは、たとえば、一元的なインシデント レスポンス管理（IRM）ソリューションをすでに導入している場合です。具体的には、ウェブサーバー上で、サードパーティのアラート送信ソリューションから呼び出し可能なエンドポイントの URL を公開します。クライアントが Webhook を呼び出すと、サーバーがリクエストを受信して、メッセージを解析、処理し、インシデントの作成、更新、解決を行います。メッセージの解析はサーバーで行うので、複数のサードパーティがそれぞれ異なる JSON ペイロードを送信する場合でも、同じ 1 つのエンドポイントを使用できます。または、サードパーティやメッセージの形式ごとに、異なるエンドポイントを公開することも可能です。

複数のサードパーティがこの Webhook を使用する可能性があるので、呼び出し元を基本方式またはトークン方式で認証できます。また、サーバーの保守や管理はオンプレミスで行うので、サーバーが常に着信メッセージを確実に受信できる状態にすることができます。

Pub/Sub が適している場合

Pub/Sub は、明示的な呼び出し（push）と暗黙的な呼び出し（pull）の両方をサポートしています。pull モードでは、メッセージをキューから pull するタイミングやアラート メッセージの処理方法を、サブスクライバー側が制御します。Pub/Sub の持続的なキューでは、メッセージはサブスクライバーから pull されるまで、必要なだけ長く待機します。

Pub/Sub は、Cloud Identity and Access Management によってアクセスが管理されるキューであるため、サブスクライバーはユーザー アカウントまたはサービス アカウントを使って認証を受ける必要があります。Pub/Sub に配信されたメッセージは、決して Google ネットワークの外に出ることはありません。

Pub/Sub は、たとえば、アラート メッセージを処理側に送信する前に、変換しなければならない場合に適しています。次のようなシナリオを考えてみましょう。ロードバランサの状態をチェックするために、稼働時間チェックを構成したところ、アラートが発生し、メッセージが Pub/Sub チャネルにパブリッシュされます。新しいメッセージが Pub/Sub トピックをヒットすると、Cloud Functions の関数がトリガーされます。この関数は、メッセージを読み取って、エラーが発生したロードバランサを特定します。この関数は続けて、フェイルオーバーするロードバランサを指すように DNS レコードを変更するコマンドを送信します。

Pub/Sub の通知チャネル機能は、アラート通知を定義する際の柔軟性を高め、作業の負担を軽減する目的で開発されました。Pub/Sub 通知チャネルの使用方法については、こちらのガイドをご覧ください。メーリング リストのディスカッションにもぜひご参加ください。