突然のネットワーク不通、サーバのパフォーマンス問題……ITインフラエンジニアには日々さまざまな課題が降りかかってきます。これらの課題に効率的に対処していくには、効率的な切り分け、分析、対処、場合によっては改善策が必要です。今回は、筆者が経験した比較的シンプルなネットワーク、サーバの障害例を紹介しながら、問題解決に向けて押さえておきたいポイントを紹介します。
トラシュー事例（初級編）
筆者はスノーボードを満喫するため、ある山の旅館に宿泊していました。この旅館には無料の無線LANサービスがあります（図1 ） 。夜、無線LANに接続したのですが、アクセスポイントには接続できるものの、インターネットとの通信ができません。「 あれ？ なんかおかしいな？」と思いましたが、使えないものはしかたがないと思い、深追いはしませんでした[1] 。しかし、翌日の朝食時に旅館の支配人に声をかけられたのをきっかけに、通信を復旧させるお手伝いをすることになりました。
図1 某旅館の当初のネットワーク構成（イメージ図） 現状を把握する
この旅館のネットワークは、電話会社の光回線向けにレンタルされるPPPoE（Point-to-Point Protocol over Ethernet）が可能なインターネット接続用ルータ、および複数の家庭向け無線LANアクセスポイントで構成されていました。とりあえず、ルータの設定Webページにログインして再起動したところ、それだけでインターネット通信ができるようになったので、しばらく様子を見てもらうことにしました。その後、スノーボードを終え、遅めのランチをとっていたところ、あらためて支配人から相談を受けました。
「またインターネットがつながらなくて……クレジットカードの決済機も使えないんです」
事務所に入り、Windows端末のコマンドプロンプトからGoogleのDNSサーバ8.8.8.8[2] へpingを打ってみても返事がありません。朝方にはちゃんとインターネット通信ができていたのにおかしいなと思い、端末からルータにpingを打ってみましたが返事がありません。
Windowsホストマシンでipconfigコマンドを実行してみたところ、ルータがあるはずのサブネット、192.168.xxx.0/24とは異なる空間のIPアドレス／サブネットマスクがホストのネットワークインターフェースに設定されていました（図2 ） 。
図2 ひとつのセグメントに複数のDHCPサーバが……まさかと思いながら、Windowsのインターフェース情報から見つけたDHCPサーバのアドレスにpingを打ちながら宿泊者向けの無線LANアクセスポイントのLANケーブルを抜くと、そのDHCPサーバのIPアドレスからのICMP応答が絶えました。そのあと。WindowsホストでIPアドレスを取得しなおしてみると、今度は192.168.zzz.0/24のIPアドレスが……同じセグメントに、まさかの3つめのDHCPサーバがあるようです。
さらにDHCPサーバを探すため、ルータやハブに刺さっているLANケーブルを1本1本抜いていくと、やがて意図したとおり192.168.xxx.0/24のIPアドレスがリースされるようになり、サービスが復旧しました。どうやら、旅館内に設置された無線LANアクセスポイントのほとんどが、自動設定機能によって、DHCPサーバとして動作していたようです[3] 。
すべての機器を再設定し対処
状況が見えてきたところで、具体的なサービス復旧作業にとりかかります。念のため無線LANアクセスポイントの設定を初期化・再設定し[4] 、すべて再設定および最新ファームウェアを適用しました。また、今後の混乱を防ぐために不要な自動設定機能は無効化します。再設定後のアクセスポイントに接続し、tracerouteコマンドで8.8.8.8までの経路を調べ、意図どおりのルートでパケットが送受信できていることも確認できました。今後のために、何につながっているかわかるよう各Ethernetケーブルにタグをつけ、本日時点のネットワーク図を書いて作業完了です[5] 。
今回筆者が遭遇したシチュエーションは、インターネットの接続性に関するトラブルとしては最も単純な類のものですが、実際に小規模のオフィスで経験しやすいものだと思います。うっかり失敗しがちな今どきのパターンとしては、仮想マシン上で立ち上げたDHCPサービスのパケットを上位ネットワークに流してしまい、隣の席の上司のコンピュータがそのDHCPサーバからアドレスをリースされて通信ができなくなり大騒ぎになった、なんてこともよくあります。ITエンジニアであれば、TCP/IPネットワークの最低限のトラブルシューティング手法やコマンド（表1 ）は知っておきたいものです。
表1 TCP/IPネットワークの障害調査のために最低限覚えておきたいコマンド集
コマンド 説明 ifconfig、ipconfig（Windows） ホストのIPアドレス情報などを表示する ping 指定したIPアドレスにICMP ECHOパケットを送信し、相手と通信ができるか確認する traceroute、tracert（Windows） 指定したIPアドレスへの到達経路を調査する netstat -r ルーティング情報を確認する
トラシュー事例（上級編）遅くなったデータベース」
とある日、1通のメールが届きました。筆者が取り扱った案件で、FlashストレージとMySQLを組み合わせたのですが、そのシステムでレプリケーションが遅延し、本来の性能の10％も得られないという内容でした。それに加えて、普通にDBを運用していると性能が出ないのに、同時に読み込みワークロード[6] を実行していると、負荷が増しているにもかかわらず、データベースの処理性能が10倍近くに跳ね上がるというのです（図3 ） 。
図3 問題を示すIOPSグラフ（イメージ） そんな不可解な状態だったので、早速、実機を確認しに伺いました。この問題で使用されていたMySQLは、レプリケーションのスレーブとなっていました。MySQLであればレプリケーションを受けている際に遅延している秒数が確認できますが、レプリケーションを受けていると、その遅延秒数が増えていきます[7] 。HDDでのライトバックキャッシュが有効に動作する状況であれば、下手なFlashメモリストレージより最高性能が出ることもありますが、しかしHDDで捌かれたワークロードがまったくFlashストレージで捌けないというのは、何か問題がありそうです。
まずは、ログに何か出力されていないかを確認しました。ログには、ソフトウェアの開発中のデバッグ情報であったり、もしくはユーザがそのソフトウェアを利用する際に有益となる情報が出力されるものですから、問題解決の糸口が見つかればラッキーです[8] 。残念ながら、今回はOSやミドルウェアのログには、解決の糸口となりそうな内容はありませんでした。
次に、MySQLのパラメータをひとつひとつ変更しながら状況が変化するかを確認していきました。問題の糸口が何かをつかめるまでは、地道な作業です。しばらくして、バイナリログの同期書き込みを無効化すると問題が大幅に改善し、バイナリログの書き込み速度に関連した問題だと絞り込めました。
客先での現地調査も一段落し、お客様と相談して、まずは暫定対処としてバイナリログの同期書き込みをオフで利用いただくことにしました。アプリケーションやミドルウェアの特性を把握していれば、何が起きているか、抱えている問題がどのような影響を与える可能性があるか、どのような暫定対処策があるかをある程度推測、判断できます。本来であればデータの永続性を保証するために、同期書き込みを勧めたいのですが、プライマリデータが別にも保存されており、有事の復旧も可能であると見込み、同期書き込みなしでも最低限の信頼性を保って運用いただけるのでは、と判断しました。
その後、「 バイナリログの同期書き込みがなぜ想定より遅いのか」に焦点を絞り、検討を始めました。経験上、先の構成であれば、同期書き込みを行ったとしても、もっと高い性能が得られるはずです。MySQLのInnoDBストレージエンジンの場合、トランザクションの永続性を保証するため、ログ書き込みが終わった時点でトランザクションが完了します。このため、バイナリログの同期書き込みが遅延すれば、それだけトランザクションに必要な時間が増えることになります（図4 ） 。
図4 ログの同期書き込み問題の再現方法がわかったため、同様の問題を再現させるための環境を手元に構築し、より根本的な原因を調査しました。ftraceでカーネル内のブロックI/Oのイベントを調べたところ、特定のLinuxカーネルに、デバイスへのI/Oがすぐ開始されない現象が確認されました。この場合、数ミリ秒してからカーネル内のウォッチドッグタイマが発動し、I/Oが遅れて開始されることがわかりました[9] 。最終的には社内のLinuxカーネルメンテナが、ドライバに細工を入れて問題を解消しました。
調査・分析のとっかかりになるポイント集
最後に、問題の調査・分析にあたり、まずチェックしたいポイント（ログファイル、コマンド）を紹介します。システムトラブルにあたったが、何を見たらいいかわからない……そんな場合には、これらのポイントを参考にしてみてください（表2～4 ） 。
表2 まず最初にチェックしたいログファイル
ログファイル 説明 dmesgコマンド 最近、カーネルから出力されたログを確認する /var/log/messagesファイル カーネルやアプリケーションから出力されたログが出力される その他 利用しているプログラムのログファイル、統計情報を確認するとよい
表3 OS側から問題調査を行うための基本コマンド（Linux）
コマンド名 説明 sar カーネルのカウンタ情報を時系列に表示する。過去24時間の負荷状況を把握する場合などに便利 top システム上の上位プロセスをモニタリングできる。ソート機能も便利 vmstat メモリやプロセッサ稼働率などをモニタリングできる。ユーザプログラム／カーネルのCPU処理 iostat ハードディスクやSSDなどのディスク稼働状況をモニタリングできる。性能問題の原因がストレージにあるかを切り分けるために利用する mpstat 各論理プロセッサの処理状況を確認する dstat vmstat/iostatに代わるLinuxカーネルのモニタリングツール
表4 さらに細かな調査で役立つツール（Linux）
perf 性能プロファイリングツール。プロセッサがどの処理（関数）に時間を費やしているか、
などを確認できる ftrace、trace-cmd Linuxカーネルのトレース機構と利用するためのツール w＋L 各論理プロセッサで実行中のプロセスのバックトレースを出力
第1特集 MySQL アプリ開発者の必修5科目 不意なトラブルに困らないためのRDB基礎知識 第2特集 「知りたい」「 使いたい」「 発信したい」をかなえる OSSソースコードリーディングのススメ 特別企画 企業のシステムを支えるOSとエコシステムの全貌 ［特別企画］Red Hat Enterprise Linux 9最新ガイド 短期連載 今さら聞けないSSH ［前編］リモートログインとコマンドの実行 短期連載 MySQLで学ぶ文字コード ［最終回］文字コードのハマりどころTips集 短期連載 新生「Ansible」徹底解説 ［4］Playbookの実行環境（基礎編）
