クラウドのステータスがグリーンでも、
ユーザーがアクセスできないことがある

サーバーは全部グリーンなのに、ユーザーから「繋がらない」と言われた

監視ツールのステータスは正常。アプリケーションサーバー・データベース・ロードバランサー、全て問題なし。エラーログにも何も出ていない。
それでもユーザーから「繋がらない」「開かない」という報告が続いた。調査に時間をかけたが、結局「ユーザー環境の問題では」という結論で終わった。
本当にそれだけでしたか。

インスタンスのスペックを上げたのに、「遅い」という声が変わらなかった

CPU使用率が高かったため、インスタンスのスペックをアップグレードした。コストは1.8倍になった。
しかしユーザーからの「重い」「遅い」という声は変わらなかった。「もっとスペックを上げる必要があるのか」という議論になった。
でも、本当にCPUが原因でしたか。

DBを最適化したのに、体感速度が改善しなかった

スロークエリの特定・インデックスの追加・接続プールの調整。数ヶ月かけてデータベースの応答時間を改善した。
しかしユーザーが体験する表示速度はほとんど変わらなかった。「何が原因かわからない」という状況になった。
本当にDBが原因でしたか。

リリース後、特定のユーザーからだけ不具合報告が来た

新バージョンをリリースした翌日、一部のユーザーから「ページが開かない」という報告が集中した。社内のテスト環境では再現しない。サーバーのエラーログには記録がない。
「ユーザーのデバイスや回線の問題では」という仮説で対応したが、すっきりしないまま時間が過ぎた。
本当にユーザー側の問題でしたか。

サーバーが正常でも、ユーザーがアクセスできない状況

クラウドプロバイダーの監視ツールが見ているのは、クラウドの内側だけ

クラウドプロバイダーの監視ツールはクラウドインフラの内部メトリクスを監視しています。クラウドインスタンスのCPU・メモリ・ディスク、ロードバランサーのリクエスト数、マネージドDBの接続数——これらはクラウドの内側の状態です。
ユーザーがどこからどのような回線で接続しているか、CDNからオリジンまでの経路品質、BGPルーティングの変動——これらはクラウド内部のツールには原理的に見えません。
さらに、クラウドの特定リージョンに障害が発生したとき、同じリージョンで動いている監視エージェント自体も影響を受けます。「監視が死んでいるから障害を検知できない」という状況が実際に起きます。監視システムは、監視対象と独立したインフラで動いていなければなりません。

インスタンスのスペックを上げても改善しない理由

CPU使用率が高いからといってインスタンスのスペックを上げると、コストは上がりますが問題が解決しないことがあります。それは、CPU使用率という集計値が「どのプロセスが何に時間を使っているか」を示していないからです。
ガベージコレクションが頻発している場合、問題はオブジェクトの生成パターンにあります。コンテキストスイッチが多発している場合、問題はプロセスの設計にあります。I/Oの待ちが支配的な場合、問題はストレージかネットワークにあります。
これらはスペックアップでは解決しません。「何に時間を使っているか」を知るためには、プロファイリングデータを見る必要があります。しかしこの視点を持つインフラエンジニアは希少です。

「重い」の原因はどこにあるか

ユーザーが「重い」「遅い」と感じる体験は、複数のレイヤーで発生します。DNS解決の遅延、TLSハンドシェイクのオーバーヘッド、CDNのキャッシュミス、サードパーティタグの読み込みブロック、フロントエンドのレンダリング処理——これらはすべて「遅い」として体験されますが、サーバーのメトリクスには現れません。
SpeedDataによる計測を通じて繰り返し発見されるのは、「DBチューニングに数ヶ月かけたが、原因はサードパーティタグの応答遅延だった」というパターンです。外側からレイヤー別に計測して初めて、調査の起点が正しいかどうかわかります。

クラウドが「隠している」もの

クラウドプロバイダーはハードウェア・OS・ネットワーク・ストレージの複雑さを抽象化し、APIで操作できるようにしました。これは生産性を大幅に向上させました。
しかし抽象化は「隠す」ことです。クラウドインスタンスの裏にある物理サーバーのハードウェア障害、ハイパーバイザーのオーバーヘッド、物理ネットワークの問題——これらはクラウドプロバイダーが責任を持ちますが、あなたがその存在を知らなければトラブルシューティングの仮説すら立てられません。
「原因がクラウドプロバイダー側にある」と判断するためにも、クラウドの外側から計測するデータが必要です。

マルチクラウド・オンプレミス混在環境での限界

単一のクラウドプロバイダーだけを使う組織は減っています。可用性要件・コスト・データ主権・既存投資の保護——様々な理由から複数のIaaSとプライベートクラウドが混在します。
この環境でサービスの可用性を管理するためには、特定クラウドベンダーの独自ツールへの依存を最小化し、クラウドに依存しない独立した計測インフラから全体を俯瞰する視点が必要です。
SpeedDataは特定のクラウドプロバイダーに依存せず、IaaS・オンプレミスのいずれで動くサービスに対しても、それらとは独立した物理インフラから計測します。特定クラウドに障害が起きても、計測は止まりません。

ベアメタルサーバーの障害モードを知らないリスク

クラウドの仮想マシンとベアメタルサーバーでは、障害のモードが異なります。仮想化レイヤーが隠蔽しているハードウェアの問題が、ベアメタルではそのまま表面に出ます。
エンタープライズ環境では複数のクラウドプロバイダー・オンプレミス・ベアメタルが混在します。特定のIaaSしか知らないインフラエンジニアは、この混在環境で発生する問題の多くに対して有効な仮説を立てられません。

DBチューニングを繰り返しても改善しなかった遅延の原因

「ページ表示が遅い」という報告を受け、スロークエリの最適化・インデックスの追加・接続プールの拡大を繰り返していた。数ヶ月かけてDBの応答時間を30%改善したが、ユーザーから見た体験はほとんど変わらなかった。
外側から計測してみると、ページ内に埋め込まれた広告タグのレスポンスが平均2.8秒かかっており、これがページ全体の表示完了をブロックしていた。DBの応答時間の改善は、全体の遅延のごく一部しか影響していなかった。
「何が遅いか」をレイヤー別に計測せずに「DBが原因のはず」という前提で始めた調査は、正しい問題に到達できなかった。

スペックアップ後も改善しなかったパフォーマンス

CPU使用率が高かったため、クラウドインスタンスのスペックをアップグレードした。コストは1.8倍になったが、ユーザーからの「遅い」という声は変わらなかった。
プロファイリングデータを確認すると、CPU使用率の大半はガベージコレクションによるものだった。オブジェクトの生成パターンを修正することで、インスタンスのスペックを元に戻してもパフォーマンスが大幅に改善した。
CPU使用率という集計値はスペックアップの根拠にならない。プロファイリングなしの増強は、正しい診断なしの処方です。

リリース後に特定ユーザーだけ発生した障害

新バージョンをリリースした翌日、特定のキャリアを使うユーザーから「ページが開かない」という報告が集中した。サーバーのメトリクスは正常、エラーログにも記録がなかった。社内の検証環境では再現しない。
計測すると、新バージョンで追加したSSL証明書の中間CA証明書チェーンに不備があり、特定のキャリアが使う旧モデルのスマートフォンでTLSハンドシェイクに失敗していた。
SSL証明書の問題はサーバーのアクセスログには現れない。外側からTLS接続を実際に確立して計測して初めてわかる。