コンテンツに移動
管理ツール

オブザーバビリティを強化する Pub/Sub 指標ダッシュボードの発表

2022年9月27日
Google Cloud Japan Team

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

Pub/Sub では豊富な指標を使用して、リソースや使用状況をモニタリングできます。これまでの指標はいわば埋もれた宝でした。これらの指標は Pub/Sub の使用状況を把握するのに役立ちますが、あちこち探し回って掘り出す必要があったからです。本日発表する、Google Cloud コンソールの [トピック] ページと [サブスクリプション] ページからワンクリックでアクセスできる Pub/Sub 指標ダッシュボードにより、オブザーバビリティがコンテキストにおいて強化され、Pub/Sub でより優れたソリューションを構築できるようになります。

ワンクリックでアクセスできる、Google の新しいモニタリング ダッシュボードの紹介

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_qrCvIfm.max-2200x2200.jpg
プロジェクト内のすべてのトピックに対応するモニタリング ダッシュボードの [概要] セクション

今回追加した指標ダッシュボードでは、すべてのトピックとサブスクリプションの健全性を 1 か所でモニタリングできるほか、個々のトピックとサブスクリプションのダッシュボードにもアクセスできます。新しいモニタリング ダッシュボードにアクセスする手順は次のとおりです。

  • プロジェクト内のすべてのトピックに対応するモニタリング ダッシュボードを表示するには、Pub/Sub の [トピック] ページを開き、[指標] タブをクリックします。このダッシュボードには、[概要] と [割り当て] の 2 つのセクションがあります。

  • 単一トピックのモニタリング ダッシュボードを表示するには、Pub/Sub の [トピック] ページでいずれかのトピックをクリックし、そのトピックの詳細ページを表示してから、[指標] タブをクリックします。このダッシュボードには最大 3 つのセクションがあります。具体的には、[概要]、[サブスクリプション] のセクションと、トピックの保持が有効にされている場合に表示される [保持] セクションです。

  • プロジェクト内のすべてのサブスクリプションに対応するモニタリング ダッシュボードを表示するには、Pub/Sub の [サブスクリプション] ページを開き、[指標] タブをクリックします。このダッシュボードには、[概要] と [割り当て] の 2 つのセクションがあります。

  • 単一サブスクリプションのモニタリング ダッシュボードを表示するには、Pub/Sub の [サブスクリプション] ページで任意のサブスクリプションをクリックし、そのサブスクリプションの詳細ページを表示してから、[指標] タブをクリックします。このダッシュボードには最大 4 つのセクションがあります。具体的には、[概要]、[健全性] のセクションと、確認済みメッセージの保持が有効にされている場合は [保持] セクション、さらにサブスクリプションの配信タイプに応じた [pull] または [push] セクションです。

主な特長

新しい Pub/Sub 指標ダッシュボードを探索すると、たとえば以下の点を確認できます。これらのダッシュボードは進行中の取り組みであり、皆様のご意見を反映して更新していきたいと考えています。最近の更新内容については、Pub/Sub モニタリングのドキュメントをご覧ください。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_f7ZFyNO.max-1500x1500.jpg
単一トピックのモニタリング ダッシュボードの [概要] ページ

上記に示されているように、単一トピックのモニタリング ダッシュボードで利用可能な指標は互いに密接に関連しています。大まかに言うと、[パブリッシュのスループット(バイト単位)] は、[パブリッシュされたメッセージ数] と [平均メッセージ サイズ] を乗算して算出できます。パブリッシュ リクエストは一連のメッセージからなるため、[パブリッシュされたメッセージ数] を [パブリッシュ リクエスト数] で除算すると、[バッチあたりの平均メッセージ数] を算出できます。パブリッシャー クライアントでバッチ処理が有効にされている場合は、パブリッシュされたメッセージ数はパブリッシュ リクエスト数よりも多くなると想定してください。

単一トピックのモニタリング ダッシュボードを確認すると、次のような興味深い質問の答えを見つけることができます。

  • メッセージのサイズが経時的に変化したか?

  • パブリッシュ リクエスト数が急増した時点はあったか?

  • パブリッシュのスループットは期待に沿ったものか?

  • バッチサイズを大きくするとパブリッシュのレイテンシが増えることを踏まえると、達成しようとしているレイテンシに適切なバッチサイズとなっているか?

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_2mEAqoW.max-2200x2200.jpg
単一サブスクリプションのモニタリング ダッシュボードの [概要] ページ

単一サブスクリプションのモニタリング ダッシュボードでは、いくつかの強力な複合指標を確認できます。具体的には、[配信の指標]、[確認応答に対するパブリッシュの差分]、[確認応答に対する pull の差分] です。これら 3 つの指標はいずれも、受信メッセージに対するサブスクライバーの対応状況を把握できるようにすることを目的としています。[配信の指標] には、パブリッシュ レート、pull レート、確認応答(ack)レートが横並びに表示されます。[確認応答に対する pull の差分] と [確認応答に対するパブリッシュの差分] では、特定のボトルネックにドリルダウンできます。たとえばサブスクライバーがメッセージを確認応答するよりもはるかに頻繁に pull している場合、[確認応答に対する pull の差分] のほとんどでゼロを超えた数値が報告されるはずです。このシナリオでは、[リージョン別の未確認メッセージ] と [バックログのバイト数] の値が大きくなることも考えられます。この状況を是正するには、メッセージの処理能力を増やすか、サブスクライバーのフロー制御を設定します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_bAZuLXq.max-2200x2200.jpg
単一サブスクリプションのモニタリング ダッシュボードの [健全性] セクション

単一サブスクリプションのモニタリング ダッシュボードで使用できる強力な複合指標には、[健全性] セクションの [配信レイテンシの健全性スコア] もあります。この指標は、サブスクリプションの健全性を調べるためのワンストップ ショップとして扱うことができます。この指標が追跡する合計 5 つのプロパティは、いずれも 0 または 1 の値を取ります。サブスクライバーが対応しきれていない場合、「ack_latency」プロパティや「expired_ack_deadlines」プロパティのスコアがゼロであれば、実質的に理由がそのプロパティにあることがわかります。これらのプロパティのゼロのスコアに対処する方法については、こちらのドキュメントをご覧ください。サブスクリプションが Dataflow などのマネージド サービスによって実行されている場合は、「使用率」を表すスコアがゼロでも心配する必要はありません。Dataflow では、メッセージを受信するためのオープン ストリームの数が最適化されるため、オープン ストリームの数を増やすという最適化案は適用されません。

単一サブスクリプションのモニタリング ダッシュボードでは、次のような質問の答えを見つけることができます。

  • 確認応答レイテンシの 99 パーセンタイルの値は何か?メッセージの大半が 1 秒未満で確認応答されて、ほぼリアルタイムでアプリケーションを実行できる状態になっているか?

  • サブスクライバーはパブリッシャーの処理速度にどの程度追い付いているか?

  • バックログが増えているリージョンはどこか?

  • サブスクライバーが原因でメッセージの確認応答が期限切れになる頻度はどれくらいか?

モニタリング エクスペリエンスをカスタマイズする

既存のダッシュボードで問題の診断に十分対応できることを願いますが、少々変更を加える必要がある場合も考えられます。その場合は、モニタリング ダッシュボードのリストにあるプルダウン メニューで [カスタム ダッシュボードとして保存] をクリックしてダッシュボード全体をカスタム ダッシュボードとして保存するか、特定のグラフで [カスタム ダッシュボードに追加] をクリックして、そのグラフをカスタム ダッシュボードに保存します。これにより、カスタム ダッシュボードで任意のグラフ構成や MQL クエリを編集できるようになります。

たとえば、単一トピックのモニタリング ダッシュボードの [サブスクリプション] セクションにある [確認応答メッセージ数が上位 5 件のサブスクリプション] グラフには、デフォルトで、メッセージの確認応答レートが高い上位 5 件のサブスクリプションが表示されます。ダッシュボードに変更を加えて、上位 10 件のサブスクリプションが表示されるようにできます。この変更を行うには、まず、グラフをエクスポートします。次にエクスポートしたグラフをクリックし、「| top 5, .max()」とある MQL の行を「| top 10, .max()」に変更します。MQL の編集方法について詳しくは、クエリエディタの使用 | Cloud Monitoringをご覧ください。

やや複雑な例として、現在のデータを過去のデータと比較するグラフも作成できます。たとえば、すべてのトピックに対応するモニタリング ダッシュボードの [概要] セクションにある [バイト数単位の費用] グラフを、Metrics Explorer に表示できます。[MQL] タブに表示されるコード スニペットの最後に、以下の行を追加します。

読み込んでいます...

元のグラフは上記の行により、前日の同じ時間のデータと比較するグラフに変換されます。たとえば、Pub/Sub トピックがタクシー乗車リクエストなどのアプリケーション イベントからなる場合、前日のデータをベースラインとして現在のデータを比較し、現在のビジネスやアプリケーションに対する適切な期待値を設定できます。必要に応じて、グラフの種類を [折れ線グラフ] に変更して比較しやすくすることもできます。

アラートを設定する

思いも寄らぬときに割り当て上限に近づいている場合があります。そのような状況を防ぐには、特定のしきい値に達した時点で通知を受け取るためのアラートを設定します。Pub/Sub ダッシュボードには、そのようなアラートを設定するための組み込み関数が用意されています。まず、トピックまたはサブスクリプションのモニタリング ダッシュボードのいずれかで、[割り当て] セクションにアクセスします。次に、ダッシュボードの上部にある [割り当てアラートの設定] セクションで [アラートの作成] をクリックします。すると、MQL クエリによるアラート作成フォームが表示され、容量の 80% を超えた割り当て指標に対してトリガーされるアラートを作成できます(しきい値は変更可能です)。
https://storage.googleapis.com/gweb-cloudblog-publish/images/5_ZgbhHPW.max-2200x2200.jpg
プロジェクト内のすべてのトピックに対応するモニタリング ダッシュボードの [割り当て] セクション

実際のところ、用意されているグラフのすべてでアラート ポリシーを設定できます。アラート ポリシーを設定するには、最初にグラフをカスタム ダッシュボードにエクスポートします。次に、プルダウン メニューを使用して [Convert to alert chart] を選択し、指定のグラフをアラートグラフに変換します。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/6_rvZhsgW.gif
指定のグラフのアラートグラフへの変換

たとえば、12 時間のうちの 90% を超えて [応答確認に対する pull の差分] が正の値になっている場合にアラートをトリガーすることが考えられます。この状況は、サブスクリプションでメッセージを pull する頻度がメッセージに応答確認する頻度よりも高いことを意味します。その場合はまず、[確認応答に対する pull の差分] グラフをカスタム ダッシュボードにエクスポートし、それをアラートグラフに変換してから、表示される MQL クエリの最後に以下の行を追加します。

| condition gt(val(), 0)

次に、[トリガーの設定] をクリックします。[Alert trigger] を [時系列の違反の割合] に設定し、[違反している時系列の最小割合] を 90% に、[この期間に条件が満たされた場合にトリガーします] を 12 時間に設定します。アラートが正常に作成されると、赤い水平線でしきい値を表す新しいグラフが表示されます。このグラフでは、条件に違反する対応待ちのインシデントがある場合、テキストのふきだしでそれが通知されます。

[最も古い未確認メッセージ] 指標のアラートも追加できます。Pub/Sub では、サブスクリプションにメッセージ保持期間を設定できるようになっています。最も古い未確認メッセージが構成済みのサブスクリプション保持期間を超えないようにする目的で、想定される処理時間を超えて応答確認されていないメッセージがあると、アラートを起動します。

Google にとって重要なのは、指標ダッシュボードを使いやすくし、ユーザーのニーズに対処できるようにすることです。Google が提供するダッシュボードとグラフに対する皆様からのご意見やご提案をお待ちしております。Cloud コンソールの右上にある質問アイコンをクリックし、[フィードバックを送信] を選択して、ご意見、ご提案をお寄せください。グラフを気に入っていただいた場合も、ぜひお知らせください。ご連絡を心よりお待ち申し上げます。

- デベロッパーリレーションズ エンジニア Tianzi Cai
- ソフトウェア エンジニア Charles Thorson

投稿先