DNSの設定ミスは、誰にでも起こりうる問題です。重要なのは、それをどれだけ早く発見できるかということです。

実際のユーザエクスペリエンスを監視するには？

2024年9月27日
著者: Dritan Suljoti
翻訳: 逆井 晶子

この記事は米Catchpoint Systems社のブログ記事「DNS misconfiguration can happen to anyone - the question is how fast can you detect it?」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

ウェブアプリケーションの構築や本番環境でのトラブルシューティングを何年も行ってきた今でも、ランダムなウェブサイトがなぜ失敗するのかを解明するスリルは色褪せません。

先週、同僚が今秋にニューヨークで開催されるONUGのイベントについてのリンクをシェアしてくれました。

私はそのリンクをクリックして、待って、待って、そしてまた待っていたのですが、ページは全く読み込まれませんでした。
最終的に約30秒後、Chromeが「ERR_CONNECTION_TIMED_OUT」と表示しました。

初期トラブルシューティング

すぐに他のウェブサイトにアクセスしてみました（ブラウザ内ですでに接続されているかどうかを確認するのが一番速い方法です）が、思いつく限りのサイトはすべて正常に動作していました。
さらに興味深いことに、そのリンクは一部の同僚には正常に動作していたのです。

「Open Networking User Group」という名前を持つ組織でこうした問題が発生するとは思いませんでした。
ONUGは大企業のITリーダーを対象にしている組織ですから、この問題に興味を持ちました。

そこで、何が起きているのか確認するために、デベロッパーツールを起動して再度ONUGのサイトにアクセスしました。
再び接続に失敗し、Chromeが自動的にURLを再読み込みしようとしましたが、「このサイトにアクセスできません - onug.netが応答するのに時間がかかりすぎています」というメッセージが再び表示されました。

直感的に、デベロッパーツールで失敗したリクエストの1つをクリックして、ブラウザがどのIPアドレスに接続しようとしているか確認しようとしましたが、IPアドレスは表示されませんでした。

残念ながら、Chromeは、サーバからの応答を受け取らない限り、デベロッパーツールにIPアドレスを表示しないことを思い出しました。
11年前に、こういった場合に備えてChromiumにIPアドレスをデベロッパーツールやAPIに追加する改善を要望しましたが、約100バージョン後の現在でも、ユーザは接続できなかったIPアドレスを確認することができないままです。

しかし、Chromeは、リクエストを何度もリロードすることで、サーバへの接続の問題が何らかの形で解決されるだろうと考えていたのは親切でした。（あらゆる失敗の解決策が「マシンの再起動」だったことを思い出してください）

pingとtracerouteでの詳細な調査

次にデスクトップ上の便利なツールであるPingとTracerouteを使いましたが、「162.159.135.42」への接続は正常で、パケットロスや高い遅延もありませんでした。

状況がつかめなかったので、Catchpointで構築したIPMプラットフォームを起動し、世界中の1,274拠点からonug.netの監視を開始しました。
数秒で問題が明らかになりました。
IPv4アドレスに到達すると正常に動作しましたが、IPv6アドレスにアクセスすると接続が確立できませんでした。

ネットワークテストのデータでは、ONUGのIPv6アドレスへの接続が100%失敗していることがはっきりと示されていました。

ネットワークパスは、onug.netがIPv6トラフィックをAkamai Linodeに、IPv4トラフィックをCloudflareに送信していることを示していました。
このウェブサイトのDNSはAレコードとAAAAレコードの両方を持っており、IPv4のみのユーザは問題なく動作していますが、デュアルスタックのIPv4とIPv6のユーザは、OSやChromeがどちらのレコードを選択するかに左右されます。
AAAAレコード（IPv6）が選ばれた場合、私と同じ問題が発生し、Aレコード（IPv4）が選ばれた場合は正常に動作します。

学んだ重要な教訓

この経験から学んだ教訓はいくつかあります：

1. まず、エンドユーザがサービスがダウンしていることやその原因を報告することに頼らないでください。

すべてのユーザがトラブルシューティングを行い、問題を報告するわけではありません。
ほとんどのユーザは別のサイト（競合他社）を利用したり、そもそもサイトにアクセスした理由を忘れてしまうだけです。

2. サービス障害をグローバルなダウンタイムとして考えるのをやめましょう。

サービス障害は、一部のユーザがサービスから期待しているエクスペリエンスを得られないことを意味します。
これは、あなた自身またはベンダー/パートナーが原因であり、あなたの制御下にあります。
近年、クラウドインフラストラクチャとサービスの増加に伴い、マイクロアウトレージ（少数のユーザに影響を与える障害）がITチームが直面する最も一般的な問題になっていることは明らかです。

3. APMやフローベースのネットワークツールなどの「内部から外部」のツールを使用して、実際のユーザエクスペリエンスを監視することはできません。

このような問題により、IT部門が「私の環境では正常に動作する」や「APMにエラーが表示されない」または「ネットワークは正常であり、トラフィックは通過して要求されたものを取得している」と結論付け、ユーザエラーであると判断する可能性があります。
ユーザの視点から、プロアクティブに監視する必要があります。

4. IPv6をサポートする際の注意点。

IPv6をサポートする際は、IPv4とIPv6の両方をシンセティックにモニタリングし、観測ツールの特定の場所からのシンセティックテストが状況を正確に反映していると仮定しないようにしてください。

5. DNSをモニタリングし、正しいエントリがあることを検証する。

誤設定（前のCDN、データセンター、またはホスティングプロバイダーのAAAAレコードが残っているなど）を検出できるようにしてください。

6. 「問題の原因はいつもDNSだ」とよく言われます。

しかし、実際には常にDNSが原因ではありません。
より正確に言うと、「トラブルシューティングはDNSから始まる」が適切かもしれませんが、これはそれほど耳に残る表現ではありません。
しかし結局のところ、サービスが正常に動作する責任は「常にあなた」にあります。
それがあなたやチームの原因であれ、ベンダーの原因であれ、責任を転嫁せず、主体性を持って対処しましょう。

このような状況では、マイクロアウトレージ、断続的なエラー、地域的なエラーが検出されず、ユーザの責任にされることが多くなります。
DNS解決からISPのパフォーマンス、ルーティング、その他数十もの要素が特定の地域でのアプリケーションのパフォーマンスや可用性に影響を与えることを認識しなければなりません。

このシンプルな状況は、ユーザのいる場所からの継続的で積極的な監視と、問題が発生する前にエラーを検出し解決するための適切な技術の重要性を強調しています。