ユーザーのリクエストがサーバーに届くまでの、全経路
「サーバーは正常。既存の監視ツールでもアラートなし。
でもユーザーから『繋がらない』の報告が来た」——この状況に心当たりはありませんか。
これはツールの問題ではなく、見ている場所の問題です。
ユーザーのリクエストがサーバーに届くまでの経路を分解すると、既存の監視ツールが主にカバーしているのは全体のごく一部です。
ユーザー端末からオリジンサーバーまでの全レイヤー
ユーザーのリクエストは、以下の経路をたどってサーバーに届きます。
- ユーザー端末
-
スマートフォン・PC。
OSのネットワークスタック、ブラウザのレンダリングエンジン、CPUとメモリの処理能力がすべて影響します。 - Wi-Fi / 有線LAN
-
家庭・オフィスの無線環境。
干渉・輻輳・ルーターの性能。 - キャリア網
-
docomo・au・SoftBank・楽天モバイルの4G/5G基地局。
基地局の混雑、パケット詰まり、キャリア間ピアリングの品質。
夕方の通勤帯に基地局が混雑すれば、スループットが低下します。 - ISP（インターネットサービスプロバイダ）
-
キャリア網からインターネットへの接続点。
ISP間のピアリング品質、帯域の逼迫。 - BGP（Border Gateway Protocol）
-
AS（自律システム）間の経路制御。
経路ハイジャックやルートリークが発生すると、「サーバーは正常なのに繋がらない」が起きます。
BGPの変化はサーバーログには現れません。 - IXP（インターネット交換点）
-
ISP同士が接続する物理的な拠点。
日本国内では東京・大阪が主要拠点ですが、地方ユーザーのトラフィックがここを経由する際の遅延は、クラウド監視では見えません。 - CDN（コンテンツデリバリーネットワーク）
-
エッジサーバーのキャッシュヒット率、エッジの地理的配置。
北海道・九州のユーザーに適切なエッジから配信できているか。
キャッシュが効いていなければ、遠方のオリジンサーバーまでリクエストが到達します。 - DNS（名前解決）
-
ドメインをIPアドレスに変換する処理。
キャリア別リゾルバの応答時間は大きく異なります。
DKIMのDNSタイムアウトは、メール到達率に直結します。 TTLの設定ミスは全ユーザーに影響します。 - SSL/TLS
-
証明書の検証、ハンドシェイクの処理時間。
証明書チェーンの不備や、OCSP応答の遅延は、接続開始時のレイテンシとして現れます。 - オリジンサーバー（ここだけを見ているSREが多い）
-
アプリケーションサーバー、データベース、キャッシュ。
既存のAPMツール・サーバー監視ツールが主に計測しているのはこの層です。
あなたの既存監視が主にカバーしているのは、この経路の末端だけです。
それは間違いではありません。
しかし、ユーザーが体験する品質は、経路全体の最も弱い部分によって決まります。
「サーバーは正常」なのに「繋がらない」が起きる理由
以下のケースは、すべてサーバーが正常であるにもかかわらず発生します。
- BGP経路の問題
-
自社ASへの経路広告が正しく伝播していない。
または他のASが誤った経路を広告している（ルートリーク）。
サーバーは動いているが、ユーザーのリクエストが届かない。 - キャリア網の輻輳
-
夕方のピーク時間帯に特定キャリアの基地局が混雑し、スループットが低下。
サーバーの応答は正常でも、ユーザー側でタイムアウトが発生する。 - DNSの障害
-
上流のDNSリゾルバに問題が発生。
ドメインの名前解決ができず、ユーザーはサーバーに到達できない。
サーバーのメトリクスには何も表れない。 - CDNのキャッシュ不整合
-
コンテンツの更新後、特定エッジのキャッシュが古いバージョンを返し続ける。
ユーザーには壊れたページが表示される。アプリケーションログには正常レスポンスが記録される。 - SSL証明書の問題
-
証明書の有効期限切れ、またはチェーンの不備。
ユーザーのブラウザはエラーを表示するが、サーバーのポート443は正常に開いている。
これらは「理論上あり得る話」ではなく、実際の障害として繰り返し発生しているパターンです。
そしてその多くは、サーバー側の監視ツールだけでは検知できません。