Azure Internet Analyzer (Preview) を試してみた (フィードバック編)

前回の記事の「スコアカードを確認」した際は、「カスタムエンドポイントの測定がカウントされない」と書きました。その後、いろいろ進展がありましたので、続きを書いていきます。

気持ちを改めて

その後、年明けて、改めてプロファイルを作成して、テストを構成して、JavaScript クライアントを組み込んでみた (以前と変わらない設定、手順で) ところ、スコアカードにカスタムエンドポイントのログが出力されるようになりました。

※検証シナリオは以下のとおりでした。(おさらい)

• Web アプリケーション... Azure 東日本の Web Apps 上のアプリケーション
• Endpoint A (ETROBOJP-EP)... 上記アプリケーション内に設置 (カスタムエンドポイント)
  • 現 Web サーバーとの間のレイテンシを測定
• Endpoint B (JAPANWEST-EP)... Azure 西日本の構成済みエンドポイント
  • ここに置いたら…と仮定した場所との間のレイテンシを測定

それでは、前回の記事でちゃんとできていなかった「スコアカードを確認」してみましょう。

スコアカードを確認 (改めて)

参考：スコアカードの解釈

測定数

公式ドキュメントに書かれているとおり、「カウントが大きいほど、結果は正確」となり、分析の信頼性が高くなります。エンドポイント A と B の測定カウントは近い値になるはずです (わずかな違いはあるが、問題なし) が、あまりにも測定カウントに大きな違いがある場合、信頼できない分析結果となってしまいます。

パーセンタイル

「パーセンタイル」とは、データを昇順に並べて、小さいほうから数えて任意の％に位置する値のことを指します。
たとえば、「P50」は、データの真ん中に位置する測定値を示しています。一般的な待機時間を把握する場合はこの値を見ます。最も悪い待機時間は「P95」の値を見ます。

差分 (Delta)

エンドポイント A と B のメトリック値の差です。この値が正の値の場合はエンドポイント B が A より優れている、負の値の場合はその逆となります。

95% CI (信頼区間)

95% の頻度で測定値が示した範囲となったことを表します。
たとえば、「P50 の 95% CI」は、「中央値に位置するほとんどの測定カウントの待機時間 (ms) はこの範囲でした」ということを示しています。

時系列

測定値が時間とともにどのように変化しているかを表します。
平日・休日、日中・夜間のレイテンシーの違いが分かりやすく、イチバン目に付くところだと思います。

フィードバックしました

前回の記事に書いたとおり、Azure Internet Analyzer プロダクトマネージャーである Megan Beatty さんとお話しする機会を得ることができました。

そのやり取りする際、「英語が上手に話せず、伝えたいことがちゃんと伝わるかとても心配だ」ってメールを返したら、通訳してくれる方もアサインしていただけました。恐れずトライしてみるものですね。とてもやさしい対応で感動しました。

ミーティングのメンバー

• Megan Beatty さん
  • Azure Internet Analyzer のプロダクトマネージャー。Microsoft Ignite The Tour Tokyo で私がお話していたところを見つけた方。
• Diego Perez Botero さん
  • Azure Internet Analyzer のテックリード ("テックリード"をわかりやすく言うと「エンジニアチームの窓口兼リーダー」)。当日、私が困ったことをいろいろと調べてくれり、答えてくれた方。この記事のチェックもしてくれた！
• Kayoko Nakano Gray さん
  • サービスエンジニア (CXP)。当日、私のおぼつかない日本語 (英語も?) を通訳していただいた方。
• 筆者
  • 興味本位で Azure Internet Analyzer を試してみたひと。

いろいろ聞いてみた

フィードバックなので、主にちょっと困っていることを質問してみました。

Q. カスタムエンドポイントの測定値がスコアカードに反映されるタイミングは？

ひととおりにセットアップしてもすぐに結果が見えるものではないので、この設定が正しいのか否か分かりづらいですね。

A.
エンドポイントの測定値がスコアカードに反映されるのに現在の仕様では「通常 6 時間」かかる。2 ～ 3 日かかる場合もある。
1 回の測定で、エンドポイントに複数回アクセスしているが、そのうちひとつでも失敗した場合はその測定カウントは「0 (ゼロ)」となる (要するにカウントされない)。

※ちなみに https://www.etrobo.jp/trans.gif は失敗するよ (筆者のところからだと 200 OK なんだけど、アクセス元によるのか？)

スコアカードが表示されない場合の注意点がトラブルシューティングに書いてあるからそれも確認してね。
参考：Azure Internet Analyzer のトラブルシューティング

Q. スコアカードのパーセンタイル (Latency Scorecard) に分析結果が表示される条件は？

なんとなく平日は見ることはできず、土日になるとその週の分析結果が反映されているように感じました。
どういう状態になるとスコアカードが表示されるのかが公式ドキュメントから読み取れません。

※このスクリーンショットは 2020/1/28 に取ったもの

A.
その日 (上のスクリーンショットでいうと 2020/1/28) に収集された測定値の分析結果は、翌日 (2020/1/29) 中にはスコアカードに反映されるよ。

※このスクリーンショットは 2020/1/29 に取ったもの

なお、この点に関して、公式ドキュメントから読み取りづらいのはおっしゃるとおりでわれわれも認識しているし、Public Preview になれば製品自体が安定する。今後、公式ドキュメントにもどういう状態になったらスコアカードが表示されるのかということは明確に記載する。 (がんばっているよ！ )
参考：スコアカードの解釈

Q. エンドポイント A と B の構成は？

エンドポイント A と B にはそれぞれどういう位置付けで置いたら良いのでしょうか。
私は以下のように解釈しています。

ひとつのテストは「A」と「B」の 2 つのエンドポイントで構成されます。エンドポイント B はエンドポイント A に対して相対的に分析されます。つまり、エンドポイント A の測定結果を基準に、エンドポイント B の測定結果が評価されて分析されるということ。

つまり、私がやった検証だと

• Endpoint A ... 現 Web サーバーとの間のレイテンシを測定するため
• Endpoint B ... ここに置いたら…と仮定した場所との間のレイテンシを測定するため

このようなかんじでの各エンドポイントの置き方は正しいのでしょうか？

A.
ご認識どおり。

• Endpoint A ... 基準となるもの、比較元、Source
• Endpoint B ... 比較する対象のもの、比較先、Target

参考：Internet Analyzer とは (プレビュー) > 推奨されるテスト シナリオ
参考：ポータルを使用して Internet Analyzer テストを作成する (プレビュー) > 構成

その他

その他、私が取り扱ったシナリオについてもご意見いただきました。

今回の検証は東日本リージョンと西日本リージョンのレイテンシを比較しようというものだけど、そもそも東日本と西日本はかなり近い位置にあるので、レイテンシの違いはほとんどないよね (10ms ～ 20ms 程度の差)。 だからシナリオ的には向いてないね。やるなら、東アジアや東南アジアと比較したほうが良いと思うよ。

まとめ

ということで検証した結果、東日本リージョン、西日本リージョン、どちらにデプロイしてもレイテンシはほぼ変わらないということですね...

※Azure Internet Analyzer のまとめは前回の記事でやったので割愛。