PR

岡崎 俊二氏 マーキュリー・インタラクティブ・ジャパン 副社長

図2 特定ドメインからのレスポンスが悪くなったB社の障害
B社のWebサイトで特定ドメインからのアクセスが遅くなるという障害が発生した。最初はそのドメインに関係するネットワークの障害を疑っていたが,実際の問題はHTTPサーバー側にあった。

原因はドメイン別の負荷分散

 意外な結果に驚いたB社は,Webサイト内部の調査を開始した。すると,1台のHTTPサーバーの処理の一部が正常に動作していないことが分かった(図2[拡大表示])。

 B社の負荷分散装置は,パケット送信元のドメイン名を基に接続するHTTPサーバーを割り当てる設定にしていた。B社が表示するWebページは,顧客企業ごとにカスタマイズしてある。HTTPサーバーの処理効率を上げるために,あるドメインからのアクセスは特定のHTTPサーバーに処理させる設計だったのだ。

 ところが,C社からのアクセスが集中する1台のHTTPサーバーでサーバー・プロセスに異常が生じたため,処理能力が著しく低下していた。このHTTPサーバーには,負荷分散装置がC社以外のアクセスを転送しなかった。結果として,C社からのアクセスだけレスポンスが悪くなっていた。

 B社は,HTTPサーバーのボトルネックになっていたプロセスを修正した。ただ,それだけでは今後アクセスが増加したり,異常が発生したときの処理に不安が残る。このため,B社では負荷分散装置の設定を一部変更し,同一ドメインからのアクセスであっても,2台以上のHTTPサーバーにトラフィックを分散するようにした。

全アクセスの監視で問題を洗い出し

写真2 B社が導入したアクセス元ドメイン別パフォーマンス監視ツールの画面
特定ドメインでの問題発生を体験したB社は,すべてのドメインからのパフォーマンスを監視するツールを導入した。この画面では送信元IPアドレスが「64.0.0.0」(左側の白抜き部分)のドメインからのアクセスに問題が発生している。
 この問題をきっかけにB社は,すべてのトラフィックを監視するツールの導入を決意した。Webサイトの外からのパフォーマンス監視も有効だが,それだけでは発見できないトラブルもあることを痛感したからだ。

 B社が導入したのは,プローブ型の監視ツール。パフォーマンス監視ツールの付加機能として提供されているものを利用した。パフォーマンス監視ツールの中には,このような形で単体では測定できないアクセスごとの問題を監視する機能を提供するものがある。

 B社は,プローブ型の監視ツールを負荷分散装置とファイアウォールの間に設置し,すべてのトラフィックのレスポンスやエラー発生状況を監視した。すべてのトラフィック状況をチェックすれば,パフォーマンス監視では発見が難しい送信元ドメインごとやアクセスごとの問題の分析も可能になる。

 監視の結果,障害とは言えないが,ほかのドメインからのアクセスにも改善すべきポイントが見つかった(写真2[拡大表示])。B社のWebサイトでは,特定顧客用にカスタマイズしてあるアプリケーションがいくつか存在する。このうちの一つが関係するアクセスのレスポンスがやや低下していたのだ。

 調査してみると,不要な処理をアプリケーションが実行していた。開発の際に不要になった処理をアプリケーションから削除するのを怠っていたようだった。この部分を改良した結果,関係するページのレスポンスは従来より2秒程度短くなり,平均6秒になった。Webサイトのレスポンスは8秒を超えると問題ありとされる。C社は,わずか2秒の改善でも意味があったと評価している。