EthernetやTCP/IPが、一般的なコンピュータネットワークとして利用されはじめてから30年近く経ちました。近年、ネットワークトラブルといっても機器障害などのハードウェア的な故障か、外部からのDDoS攻撃、セキュリティホールクラックなどが多く、ネットワークトポロジーに関わるフラッディングやブロードキャスト、ブリッジループによるパケットストームが発生することは非常にまれになってきています。運用においても設定をデプロイするまえにグループ内で必ずクロスチェックやレビューを行っているでしょう。一般ユーザがネットワークに影響を及ぼすようなアプリケーションをインストールできないような処置を施したり、実験的なネットワークを隔離したり、設定ミスやプログラムのバグでネットワーク全体が落ちるというケースはほとんどありません。
それでもトラブルは発生していますが、最近耳にする障害の多くは設定ミスやプロトコル上のバグなどではなく、設計者、運用者による間違った認識や思い込みによる些細な原因で発生しています。
トラシュー事例（初級編）アプリケーションからサーバ上のファイルをアクセスすると、時折そのレスポンスが非常に遅くなる」
障害報告を受けて、サーバ管理者はサーバ障害の可能性を考え、該当するファイルサーバにリモートログインしてサーバの状態を確認します。まず、topコマンドでプロセスの状態を見ますが、CPU使用量の高いプロセスもなく、大量にメモリを消費しているプロセスはありません。次に、sarやiostat、mpstat、vmstatなどのコマンドを実行してプロセスやメモリの状態をチェックしても、iowaitプロセスやwait run timeプロセスもそれほど多くなく通常の状態です。
サーバに異常なし
さてはDoS攻撃かと思ってnetstatを見ても、アタックされたときに多く発生するSYN_RECV、WAIT_FIN、LAST_ACK状態のセッションは見当たりません。またNagiosやZabbixなどの監視ツールを見ても、ポートのトラフィック量は正常です。NICの障害かと考えてシステムログを見ても、とくにエラーは見当たりません。念のため、同じスイッチに接続されているサーバ間でiperfを実行すると、GbEインターフェースで945 Mbpsの性能が出ています。ログからファイルシステムもしくはディスクに問題はないかどうか確認しても、とくにディスクI/Oエラーなどの障害は発生していません。どうみてもサーバの健康状態は正常に見えます。
ネットワーク経路のチェック
管理者はどうやら問題はサーバではなくネットワークにあると考えましたが、iperfによるパフォーマンスチェックに問題はなかったので、サーバのネットワークインターフェースではなさそうです。次に疑ったのはネットワークの経路です。まず各クライアントマシンからサーバへの到達性を確認するためpingを実行しました。これもすべてレスポンスがあり、疎通はできています。次にtracerouteによってIPネットワークの経路を確認しました。クライアントからサーバへのホップ数は設計どおりになっており、経路が迂回されていたり特定のリンクに経路が集中している様子もありません。
一通りのチェックを実行した結果、サーバにもネットワークにも問題は見受けられませんでした。しかしレスポンスが遅いという問題は解消していないので、どこかに原因があるはずです。もしかするとツールやコマンドでのヘルスチェックでは検出できない物理的現象の問題かもしれません。誰かがサーバをメンテナンスした際、ケーブルを折り曲げたり、ポートへの差し込みが甘かったりしている可能性があります。
サーバラック内部のチェック
管理者はマシンルームへと向かい、該当するサーバが格納されているラックを開け、RJ45コネクタの差し込み具合をチェックしたり、ケーブルを交換したり、接続ポートを変えたりしながらサーバを再起動して様子をみます。レスポンスが異常に遅いという障害がいったん解消されますが、数時間後、サーバの反応が不安定になり再び障害が露見しました。ケーブルやポートなどではなく、スイッチ本体に障害があるのではないかと考え、ネットワーク管理者に依頼してスイッチを交換してもらいました。しかし同じようにいったん障害が復旧しますが、しばらくするとまた同じ症状になってしまいます。
違和感の正体
管理者は原因がわからなくなってしまい、次に何をチェックするといいのかさえ思いつかず、ラックの前後を行ったり来たりしながら、スイッチやサーバを眺め回すしかありませんでした。ふと、ラック内に設置されているパッチパネルを眺めているときのことです。
管理者は何か違和感を感じました。それが何を意味するのかハッキリと考えがまとまりませんでしたが、ジロジロとラックの中を見回し、再びサーバとスイッチを凝視して思わず声をあげます。
そのパッチパネルに、バックボーン側から接続されているファイバケーブルの色が黄色だったのです。今では橙、青、緑、ピンクなど各メーカーがさまざまな色のマルチモードケーブルを提供していますが（写真1 ） 、ケーブルの色が黄色であるということは、それが例外なくシングルモードケーブルであることを意味します。しかも、スイッチのアップリンクポートからパッチパネルへ接続されているケーブルの色はオレンジなのです。
写真1 シングルモードファイバとマルチモードファイバ（※イメージ） スイッチ側の光ピックアップポートを確認すると、1000BASE-SXと刻印されており、本来ならばこのスイッチとバックボーンはマルチモードで接続されるべきでした。障害の原因はスイッチとバックボーンのファイバモードミスマッチだったのです。
おそらく機器調達者は、スイッチを設置するラックから集約スイッチまでの距離が1000BASESXの最大有効距離よりもかなり短かったので、マルチモードで十分だと判断したのでしょう。しかしファイバ工事担当者は、フロアにまたがる長距離配線や複数のパッチパネルを介する配線などを行っているため、とくに念を押されない限り、ファイバの敷設はシングルモードファイバを手配していたと思われます。つまり原因は、ネットワーク機器調達の担当者と配線工事の担当者との間で、情報が正確に伝達していなかったためだったのです。
思い込みは危険
このケースの厄介なところは、ファイバモードが異なっていてもある程度の通信は可能であり、パフォーマンスが劣化したり、エラーが頻発したりするのは、接続してから時間が経過し、かつ高トラフィック負荷が掛けられたときに初めて露見するということです。まったく通信できないわけではないので、通常のトラブルシューティング手法ではなかなか原因がつかめず、直接マシンルームまで足を運ばないと原因が特定できません。
初めて光インターフェースを導入したりファイバーを敷設したりするときでは、シングルモードかマルチモードか、マルチモードはSPかGIか、コネクタ形状はLCかSCかなどを注意深くチェックするものです。しかし、運用が長期に渡ると、しだいに繰り返し習慣化している調達や作業など、各人の思い込みのままに行ってしまいがちになり、このようなまったく初歩的なミスによる障害に多くの時間を取られることになってしまいます。そのため、各人の思い込みではなく、常に作業者間で正確な情報の確認を行うことが大切です。
トラシュー事例（上級編）
システム管理者が詳細を聞いてみると、サービスの状態を監視する監視サーバを入れ替えた途端、監視サーバから今までアクセスできていたデータベース（以後DB）サーバへ接続しようとしてもタイムアウトしてつながらないとのことです。
まずDBサーバにログインし、データベースプロセスが起動しているかどうか確認しました。問題ありません。次に監視サーバとDBサーバとの疎通を確認するためDBサーバから新しい監視サーバへpingを実行すると正常にレスポンスが返ってきます。
OSのiptablesとデータベースのセキュリティフィルタで監視システムのIPアドレスがブロックされていないかどうかを確認すると、これも該当するIPアドレスからのアクセスはすべて許可されています。ネットワーク的疎通に問題があるようには思えません。
データベースのログをチェック
データベースのログを見ると、監視サーバからの接続要求を受け取ってはいますが、接続が確立されぬままタイムアウトでクローズしています。そこで、netstatで確認してみるとインターフェースにいくつものSYN_RECVセッションがありました。これは監視サーバからのSYN要求が正常に処理されておらず、OSレベルでもTCPセッションが確立できていないことを示しています。監視サーバからのSYN要求は届いているので、問題はDBサーバがSYN_ACKを返していないか、監視サーバがSYN_ACKに対するACKを返していないかのどちらかです。
そこで、tcpdumpを使ってDBサーバのネットワークインターフェースをパケットトレースすると、DBサーバは監視サーバのSYN要求にSYN_ACKを返していません。するとDBインスタンスか、OSのTCP/IPドライバのどちらかに問題があると考えられますが、監視サーバ以外のホストとは問題なくTCPセッションを確立できているので、DBにもOSにも問題があるとは思えません。監視サーバとの間に限ってTCPセッションが確立されないという不可思議な現象です。
問題を切り分けして原因を特定する
障害対応は暗礁に乗り上げてしまいましたが、このままにしておくわけにも行かないので、管理者は再び障害の切り分け作業を繰り返しました。DBサーバから監視サーバにpingをすると、問題なくレスポンスが返ってきます。念のため監視サーバのアカウントをもらい、監視サーバからDBサーバにpingを実行してみると、レスポンスが戻ってきません。つまりpingの送信方向によっては接続の疎通が取れない状態となっています。
問題を整理すると、
（1）DBサーバが監視サーバへSYN_ACKを返していない
（2）DBサーバから監視サーバへの疎通はあるが、逆方向の疎通はない
ということです。(1)の原因はわかりませんが、(2)の問題はサーバ間の経路が非対称となっていて、それが原因なのではないかと想像できます。DBサーバのネットワークインターフェースを「netstat -i」で確認するとプライマリとセカンダリという2つのインターフェースによってマルチホーム接続をしていました。そこでDBサーバのセカンダリインターフェースに対してtcpdumpを実行し、監視サーバから接続要求を出してみると、DBサーバはたしかにセカンダリインターフェースからSYN_ACKを返しています。しかし、監視サーバではそのSYN_ACKを受け取っていません。
SYN_ACKがネットワークの途中で消失しているのでしょうか？ しかしそれはちょっと考えにくい現象です。そこで、監視サーバが接続されているスイッチポートをミラーし、別のサーバをミラーポートに接続して監視サーバのポートまでSYN_ACKが届いているかどうかを確認してみると、SYN_ACKはたしかに監視サーバのポートまで届いています。つまり、監視サーバはDBサーバからのSYN_ACKを受け取っても、OSのTCP/IPレイヤで破棄しているのです。
再び、DBサーバのインターフェースアドレスを確認すると、セカンダリインターフェースのIPセグメントは監視サーバのIPセグメントと同じアドレス空間でした。つまりサーバ間のネットワークは図1 のような状態にあるわけです。
図1 非対称経路システム管理者は監視サーバをインストールした担当者に詳しく聞いたところ、監視サーバはDBサーバのプライマリインターフェースに紐付いたホスト名でサーバへの接続を行っているとのことです。
パケットの追跡
ここでパケットの流れを追跡してみましょう。監視サーバはDBサーバへの接続要求をsdb01というホスト名で行おうとしています。sdb01はhostsファイルで192.168.1.1/24であり、これはDBサーバのプライマリインターフェースのアドレスです。したがってsdb01への接続要求パケットは、監視サーバの192.168.2.2/24のインターフェースからデフォルトルータの192.168.2.254に対して送られ、ルータは受け取ったパケットを192.168.1.254インターフェースからDBサーバの192.168.1.1/24へ向けてパケットを転送します。DBサーバは受け取ったパケットを解釈してSYN_RECVモードになり、SYN_ACKを192.168.2.1/24のセカンダリインターフェースから監視サーバへ送り返します。なぜなら、監視サーバのIP セグメントはセカンダリと同じなので、プライマリではなくセカンダリから直接配送できるからです。しかし、監視サーバはそのセカンダリから送られたパケットを破棄しています。
OSアップデートの落とし穴
再び管理者は監視サーバ担当者にアップデートする前と後で何か変更したことはないかを尋ねると、アプリケーションをアップデートする前にサーバOSのメジャーバージョンを1つ上げているとのことです。ここで管理者の脳裏には、非対称経路におけるセキュリティ問題が浮かび上がりました。そこで管理者がOSのリリースノートを確認すると、新しいOSリリースでは非対称経路で送られてきたパケットをセキュリティ上の処置として破棄する、となっています。逆に古いOSリリースでは非対称経路パケットはデフォルトで受信するという仕様です。結局原因はネットワークのトポロジーとサーバ運用とがミスマッチであった（同セグメントリンクがあるにもかかわらず、ルータ経由のホスト名で接続していた）ことと、監視アプリケーションのインストールに伴い、OSもアップグレードしたことによるセキュリティ障害でした。
ネットワークのトポロジ設計と、サーバとアプリケーションの運用が、連携せずに別々に行うことによる障害はよく発生します。システム開発設計と運用設計と運用作業を別々のチームで別々に考えるのではなく、これらは「安定したサービスを継続して提供する」という同じ目的を実現するための同じチーム内における作業分担にすぎないという認識が必要なのかもしれません。
まとめ
トラブルシューティングは単に机上の理論や知識だけではなく、実際の環境で起こり得るさまざまな原因に対処するための経験や担当者間の情報伝達、チームワーク、コミュニケーション力など属人的要素が大きく影響します。筆者が主宰する学生を対象としたICTトラブルシューティングコンテスト や、Webシステムのチューニング技術を競うISUCON など、現実問題に対処するコンテストやセミナーなどに積極的に参加し、トラブルシューティング力を上げることを心がけたいものです。
第1特集 MySQL アプリ開発者の必修5科目 不意なトラブルに困らないためのRDB基礎知識 第2特集 「知りたい」「 使いたい」「 発信したい」をかなえる OSSソースコードリーディングのススメ 特別企画 企業のシステムを支えるOSとエコシステムの全貌 ［特別企画］Red Hat Enterprise Linux 9最新ガイド 短期連載 今さら聞けないSSH ［前編］リモートログインとコマンドの実行 短期連載 MySQLで学ぶ文字コード ［最終回］文字コードのハマりどころTips集 短期連載 新生「Ansible」徹底解説 ［4］Playbookの実行環境（基礎編）
