Azure Internet Analyzer

解決する課題

• CDN やリージョン、配信構成を切り替えたいが、本当に速くなるのかを本番投入前に確かめたい
• 合成監視（特定地点からの定点観測）では、世界中に散らばる実ユーザーが体感する速度まではわからない
• 「東京リージョンへ寄せるべきか」「別の CDN のほうが速いか」を、実利用者の分布に基づく実測データで意思決定したい
• 移行や構成変更の効果を定量的に示し、関係者に納得感のある根拠を提示したい

主要概念と用語

• Internet Analyzer（廃止済み）: Web ページに埋め込んだ計測用 JavaScript で、実利用者のブラウザーから複数エンドポイントへ計測を流し、体感ネットワーク性能を比較していたサービス
• テスト（Test）: 何と何を比較するかを定義する単位。比較対象のエンドポイント群とサンプリング条件をまとめる
• エンドポイント: 計測先の URL/ホスト。現行構成・移行先候補・別 CDN・別リージョンなどを並べ、相対的に比較する
• クライアント側計測（RUM 型）: 実利用者の端末・回線・地理から計測するため、定点観測の合成監視と違い実際のユーザー体験を反映する
• 計測スクリプト: 各エンドポイントへ小さなリソースを取得しに行き、応答までの時間などを測ってバックエンドへ送る軽量な JavaScript
• A/B（プリファレンス）比較: 同一ユーザーから複数候補へ計測し、どちらが速いかという相対比較を集計する。絶対値より「どちらが優位か」を見る

仕様・制限・クォータ

• 旧 Internet Analyzer は計測に徹するツールであり、実トラフィックの経路には介在しなかった（プロキシでも CDN でもない）。計測結果は構成判断の材料だった
• サービスは 2024 年 3 月 15 日に廃止済み。新しいプロファイルを作成するのではなく、残存スクリプトと旧プロファイル参照を撤去し、代替計測へ移行する
• 計測はページを開いた実利用者のブラウザで実行される。十分な母数を得るにはある程度のアクセス量と計測期間が必要で、トラフィックが少ないと統計的に有意な差は出にくい
• 比較対象のエンドポイントは、計測スクリプトから到達でき、CORS など取得に必要な設定が整っている必要がある
• 1 テストに登録できるエンドポイント数や、サブスクリプション/リソースあたりのテスト数などに上限がある（最新値は公式ドキュメントで確認）
• 計測するのは主にネットワーク到達時間（レイテンシ）であり、アプリのレンダリング全体の体感（LCP などのページ表示性能）を直接最適化するものではない

内部の仕組み

旧サービスでは、利用者が計測スクリプトを含むページを開くと、ブラウザーが各エンドポイントから小さなリソースを取得し、応答までの時間を測っていました。その結果を集約し、地理やネットワーク（ASN）ごとに比較していました。

• 計測はバックグラウンドで非同期に行われ、利用者のページ表示を妨げない軽量設計が前提
• 同一ユーザーから複数候補を計測することで、回線・地理の差を相対比較で打ち消し、純粋な構成差を見やすくする
• 実ユーザーの地理分布・接続元 ASN がそのまま母集団になるため、合成監視では拾いにくい地域別の傾向が見える
• 十分なサンプルが集まると、地域ごとにどちらが速いかの傾向が統計的に表れ、移行判断の根拠になる

横にスクロール

旧構成からの移行 / ベストプラクティス

• 残存物を棚卸し: Web ページの旧計測スクリプト、CORS 許可、旧エンドポイント、運用手順、ダッシュボード参照を検索する
• 要件を分解: 定点からの可用性・遅延は合成監視、実端末の体感は RUM、Azure リソースのメトリクスとログは Azure Monitor など、観測目的ごとに候補を評価する
• 比較条件を維持: CDN やリージョンを比較する場合は、取得サイズ、キャッシュ条件、時間帯、地域、標本数をそろえ、平均値だけでなく分位点も見る
• 並行計測して差を確認: 代替の収集範囲、遅延、欠損、保持期間、個人情報の扱いを検証してから監視や判断フローを切り替える
• 旧コードを撤去: 代替の受け入れ後は旧スクリプトと不要な CORS 設定を削除し、クライアント通信と攻撃面を残さない

移行後の運用・監視

• 合成監視では成功率・名前解決・接続・TLS・応答時間を分け、複数地点から同一条件で測る
• 実利用者計測では同意、匿名化、標本率、地域・回線・端末の偏り、十分な母数を確認する
• Azure Monitor などのプラットフォーム指標とアプリ指標を同じ時刻軸で突き合わせ、ネットワーク差と処理時間を混同しない
• 構成変更の前後で同じ指標と期間を比較し、期待どおり改善したかを事後検証する

コスト

• 廃止済みの旧サービス料金ではなく、代替の試験実行数、RUM セッション数、ログ取り込み量、保存期間、可視化を分けて見積もる
• 実利用者計測は閲覧側にも通信が発生するため、取得量、標本率、モバイル回線への影響を含める
• 長期保存と高カーディナリティな地域・回線属性は分析費を増やす。意思決定に必要な粒度と保持期間に絞る

セキュリティ

• 旧計測スクリプトが残っていないか確認し、残存していれば配信元・送信先・収集データを特定して撤去する
• 比較先エンドポイントを公開する際は、内部 IP やプライベートな FQDN を露出しないよう登録内容に注意する
• 計測のために設定する CORS などの許可は最小限にし、計測に必要な範囲を超えて緩めない
• 計測結果には地理・ネットワークの集計情報が含まれる。保存・共有する場合はアクセス制御を適切に行う

関連サービス・比較

• 旧 Internet Analyzer は測定、Traffic Manager は DNS による本番振り分けという別の役割でした。Traffic Manager は旧計測機能の移行先ではありません
• 代替計測の結論を Traffic Manager や Front Door の設定へ反映する場合も、TTL、既存接続、ヘルスプローブを含む切替試験を別途行います
• 継続的な可観測性は、Azure Monitor を含む合成監視・実利用者計測・アプリ監視の候補を要件別に評価します

移行チェック

1. ソースコード、タグ管理、CDN キャッシュ、CSP、CORS から旧 Internet Analyzer の参照を検索する
2. 旧計測が支えていた判断を、可用性監視・比較実験・実利用者体感・地域分析へ分類する
3. 代替候補を並行評価し、収集遅延、欠損、粒度、保持、個人情報、料金を確認する
4. ダッシュボード、アラート、運用手順を切り替え、旧スクリプトと不要な許可設定を撤去する