トラブルシューティングの極意―達人に訊く問題解決のヒント

第3回 [サーバ・インフラ・ネットワーク編]Webシステム障害時における―トラブルシューティングの手順

この記事を読むのに必要な時間:およそ 3 分

今回はWebシステム障害におけるトラブルシューティングの,とある一場面を紹介します。日々発生するトラブルの内容と対処方法は千差万別です。あらゆるトラブルに対応できるトラブルシューティング手法というものは残念ながら世の中に存在しませんが,どんなトラブルにおいても疑わしい個所を1つずつ潰していくといずれ障害原因にたどり着きます。本稿ではそんなトラブルシューティングの現場の雰囲気を簡単に紹介できればと思います。

トラシュー事例(初級編)
「特定Webサーバだけレスポンス低下」

図1のようなWebシステムにおいて,Web5サーバだけレスポンスが低いようだという連絡を受けたとします。この場合,何をどう調べていけばよいでしょうか?

図1 Webシステム構成図

図1 Webシステム構成図

前提として,各Webサーバは次のような構成になっているとします。

  • CPU:4core 1.86GHz
  • RAM:4GB
  • HDD:SAS 300GB×2(RAID1)
  • NIC:1Gbps
  • OS:CentOS6.6 64bit
  • Web:Apache2.4.12
  • 言語:PHP5.5.0

また各ネットワーク機器はアップリンク側,サーバ側がともに1000BASE-Tのポートを持っており,いずれもAuto negotiationで設定されているとします。

トラフィック量を見る

まずはネットワークのトラフィック量を示すグラフを見てみます。図2にてWeb5サーバと正常なサーバとを比較してみると,Web5サーバは70Mbpsあたりで頭打ちに見えますが,正常なサーバでは右側のように120Mbps程度まで使われていることがわかります。

図2 トラフィック量のグラフ

図2 トラフィック量のグラフ

サーバのハードウェアリソース使用状況を見る

次に,サーバのハードウェアリソース使用状況を見てみます。調べ方はいろいろありますが,図3のようにvmstatコマンドを使って調べてみることにします。結論から言うとハードウェアリソース的にはまだ十分余裕がある状況と言えます。

図3 ハードウェアリソース使用状況

図3 ハードウェアリソース使用状況

  • CPUは,Procsのr(実行キューに入っている実行待ちプロセス数)がなく,CPU使用率もidle率が99%,すなわち1%ほどしか使われていないというかなり余裕がある状況
  • ディスクI/Oはほとんど発生していない状態
  • メモリもかなり余裕がある状況

メモリは物理容量4GBに対して,未使用メモリ量(free)が約25MB,バッファキャッシュ注1に使用されているメモリ量(buf)が約68MB,そしてページキャッシュ注2として使用されているメモリ量(キャッシュ)が3,086MBとなります。こう書くと未使用領域がわずか25MBしか残ってないと思ってしまうかもしれませんが,メモリが足りなくなってきたらOSはバッファキャッシュやページキャッシュからメモリを割り当てるため,実際はまだ3GB以上のメモリが使える状況と読み取ることができます。

以上のことからハードウェアリソース使用状況としてはとくに問題ない状況と言えます。

注1)
バッファキャッシュとは,OSがブロックI/Oを最適化するために用いる領域のこと。
注2)
ページキャッシュは,ファイルI/Oを最適化するために用いる領域のこと。一度HDDから読み込まれたデータをメモリ上にキャッシュとして残し,再度読み取り要求が来たときはキャッシュから応答を返すことでディスクI/Oの発生を減らしパフォーマンス向上に貢献する。

ネットワークまわりを確認する

L2スイッチのステータス情報を見てみると,Web5とつながるポートだけが100M Halfと認識され,それ以外のポートは1,000M Fullと認識されていました。

そこでそれぞれの通信モード設定を確認してみると,Web5サーバだけが100M Full固定で設定されていたのに対し,それ以外のWebサーバはAuto negotiationで設定されていることがわかりました。

ここで2つの疑問が浮かびます。1つめはなぜ1,000M Fullではなく100M Full固定で設定されていたのか。2つめはなぜサーバ側は100MFull固定なのにL2スイッチ側では100M FullではなくHalfで認識されたのか。これらについてちょっと考えてみましょう。

1つめについては,1000BASE-TはそもそもAuto negotiationで使うよう規定されているので1,000M Full固定という設定自体が行えません(試しにL2スイッチやLinuxなどでネットワークインターフェースを1,000M Full固定で設定してみてください。エラーが出て設定できないはずです)⁠今回Web5サーバを設定した人は,おそらく1,000M Full固定設定をしようとしてうまくいかず,いろいろ試しているうちに誤って100MFull固定で設定して安心してしまったものと推測されます。

2つめについては,よくありがちな誤解として,片側が100M Full固定で設定されている場合,Auto negotiationが設定されている側では自動的に100Mbps Fullとして認識してくれそうな気がします。しかし実際は100Mbps Halfで自動設定されるため通信モードの不一致が発生します。

図4を見てみましょう。双方がAuto negotiationで設定されると,お互いがFLP(Fast Link Pulse)バーストという信号を投げ合って通信モードを決定します。しかし相手からFLPバースト信号が返ってこない場合は,10BASE-T対応機器が発信するNLP信号(Normal Link Pulse)や100BASE-TX対応機器が発するアイドル信号を検出することで,10BASE-Tか100BASE-TXのいずれかと判断されます。ただしこの場合FullとHalfまでは判断できず,必ずHalfとなります。

図4 通信モードが一致しない

図4 通信モードが一致しない

この結果,なんとか通信はできるものの大量の通信エラーが発生するだけでなく,帯域が100M Halfや10M Halfなどに制限されることになります。このような事象を防ぐためにネットワーク機器とサーバの通信モード設定は100M固定なら双方100M,Auto negotiationなら双方Auto negotiationに一致させる必要があります。

ということで,今回の場合はサーバ側もAutonegotiationに設定し直すことで,システムが正常な状態に戻りました。

なお蛇足ですが,双方Auto negotiationにしても,通信モードが一致しないことがまれに発生します。この場合はLANケーブル不良を疑い,新しいものに交換すると直ることが経験上多いです。

トラシュー事例(上級編)
「Web全体のレスポンスが不安定」

今度は,Web全体のレスポンスが不安定な状況を想定してみます。今回はとくにどのサーバのレスポンスが低下したということはなく,システム全体でレスポンスが低下しているとします。そこで先ほどの事例を参考にしてL2スイッチ/全サーバの通信モードを確認してみましたが,設定がすべてAuto negotiationに統一されていました。

今回は特定サーバだけが問題ではなさそうですので,ネットワークまわりを疑ってみることにします。

ファイアウォールを確認する

まずはDDoS(Distributed Denial of ServiceAttack)攻撃と呼ばれる,サービス妨害のために不特定多数のマシンから大量のパケットが送信される状況がなかったか確認します。そこでファイアウォールのログなどを確認しましたが,今回はとくにそのような攻撃は受けた跡はありませんでした。

L2スイッチを確認する

次にL2スイッチのログを見てみます。ここではバッファが溢れることで通信を一部取りこぼしていることを示す状況が確認できました。

一般的なL2スイッチでは,図5のように受信したフレームをいったんバッファに入れてから少しずつ転送するしくみを取ります。このバッファが溢れたとなると短時間に大量のパケットやフレームがスイッチに流入したのだと推測されます。バッファに収まらないほどのフレームを受け取るとそのフレームは破棄され,結果的に通信が不安定になります。

図5 スイッチのバッファが溢れる

図5 スイッチのバッファが溢れる

PCからスマートフォンの時代変化に伴い,ものすごく小さいパケットサイズの通信が大量に発生するようになり,ユーザ数がとくに多いサービスにおいては,L2スイッチのバッファサイズが足りなくなる状況が見られるようになりました。

このような場合には,バッファサイズの大きいL2スイッチに入れ替えるか,もしくはL2スイッチを増設して負荷を分散することが有効です。

最後に

トラブルシューティングの場面に遭遇したとき,一度経験したことのあるトラブルであれば容易に原因がつかめますが,実際は初めて遭遇するトラブルに出会う場面も多いでしょう。そんなときに必要となるのはあらゆる可能性を疑って根気強く原因を探すことです。

無論,現実的にはサービス復旧が最優先され,まずはリブートすることが求められる場面も多々あるかと思います。しかしトラブル発生のたびに原因究明する習慣をつけないと,いつまで経ってもトラブルシューティング力が向上しません。もしサービス復旧のためのリブートが要求されるのであれば,あとでトラブル分析ができるように各種ログ,画面イメージ,そのほか何でもいいので証拠となりそうなものを一通り収集してからにしましょう。

Software Design

本誌最新号をチェック!
Software Design 2017年6月号

2017年5月18日発売
B5判/184ページ
定価(本体1,220円+税)

  • 第1特集
    あなたのプログラミングを加速させるエディタ
    [決定版]これだけは知っておきたい設定と操作
  • 第2特集
    多用途に使いこなせ,コードが読みやすく保守しやすい
    今すぐはじめるPython
  • 一般記事
    ハッシュ関数を使いこなしていますか?【前編】
    ソフトウェア開発のクリティカルポイント
  • 一般記事
    Windows Server 2016で構築する最新ファイルサーバ【前編】
    進化した機能で効率化を推進
  • 一般記事
    [ニフティクラウド mobile backend]mBaaSのしくみ紹介【3】
    IoTドア監視アプリを作ろう

著者プロフィール

佐野裕(さのゆたか)

1973年生まれ。神奈川県出身。慶應義塾大学大学院 政策・メディア研究科修了後,富士通株式会社でSE職を経て,現在韓国系IT企業日本法人に創業メンバーとして勤務。当時国内最大規模のネットワーク構築と運用に携わる。

趣味はベルギービールと韓国語。システム管理Blogを運用中です。

http://nosa.cocolog-nifty.com/

バックナンバー

トラブルシューティングの極意―達人に訊く問題解決のヒント

バックナンバー一覧

コメント

コメントの記入