ネットワーク問題における論理的推論

クラシックケース1

多くのソフトウェアプロフェッショナルはTCP/IPの論理的推論に深い知識がなく、これがしばしば問題を神秘的な問題と誤解させる原因となります。TCP/IPネットワーキングの文献の複雑さに落胆する者もいますし、Wiresharkの混乱する詳細に誤解されることもあります。たとえば、パフォーマンスの問題に直面しているDBAは、Wiresharkでのパケットキャプチャデータを誤解し、TCPの再送信が原因だと誤って結論付けるかもしれません。

再送信が疑われる場合、その性質を理解することが重要です。再送信は基本的にタイムアウト再送信を含みます。再送信が実際に原因であるかどうかを確認するためには、タイム関連の情報が必要ですが、上記のスクリーンショットには提供されていません。DBAから新しいスクリーンショットを要求した後、タイムスタンプ情報が含まれました。

ネットワークパケットを分析する際には、タイムスタンプ情報が正確な論理的推論にとって重要です。2つの重複パケット間のマイクロ秒レベルの時間差は、タイムアウト再送信または重複パケットキャプチャを示唆します。通常のLAN環境では、ラウンドトリップタイム（RTT）が約100マイクロ秒であり、TCP再送信には少なくとも1つのRTTが必要です。RTTの1/100で再送信が行われる場合、実際のタイムアウト再送信ではなく重複パケットキャプチャを示している可能性が高いです。

クラシックケース2

ネットワークの問題分析における論理的推論の重要性を示す別のクラシックケースです。

ある日、ビジネス開発者が慌ててやってきて、MySQLデータベースミドルウェアを使用したスケジュールされたスクリプトが早朝に応答なしで失敗したと伝えました。この問題を聞いた私は、MySQLデータベースミドルウェアのエラーログを確認しましたが、有益な手がかりは見つかりませんでした。それで、開発者たちに問題を再現できるか尋ねました。再現可能になれば、問題は解決しやすくなるからです。

開発者たちは何度も問題を再現しようとしましたが、成功しませんでした。しかし、彼らは新たな発見をしました。それは、昼間に同じSQLクエリを実行すると、早朝とは異なる応答時間が得られることでした。彼らは、SQLの応答が遅いときにMySQLデータベースミドルウェアがセッションをブロックし、クライアントに結果を返さないのではないかと疑いました。

この洞察に基づいて、データベース運用チームにスクリプトのSQLを修正して遅いSQL応答をシミュレーションするように依頼しました。その結果、MySQLデータベースミドルウェアは早朝に見られたハングの問題に直面することなく、結果を返しました。

しばらくの間、根本原因は特定できず、開発者たちはMySQLデータベースミドルウェアに機能上の問題があることを発見しました。したがって、開発者とDBA運用チームはMySQLデータベースミドルウェアが応答を遅延させているという確信を深めました。実際には、これらの問題はMySQLデータベースミドルウェアの応答時間とは関係がありませんでした。

初日の出来事から、問題は確かに発生しました。関係者全員が原因を突き止めようと努力し、さまざまな推測を立てましたが、真の理由は依然としてつかめませんでした。

翌日、開発者たちは、スクリプトの問題が早朝に再発したと報告しましたが、日中には再現できませんでした。スクリプトが間もなくオンラインで使用されるため、開発者たちはプレッシャーを感じ、この状況に不満を訴えました。私の唯一の提案は、問題を避けるために日中にスクリプトを使用することでした。すべての疑いがMySQLデータベースミドルウェアに集中していたため、他の視点から問題を分析することは難しい状態でした。

MySQLデータベースミドルウェアの責任者として、このような神秘的な問題は簡単に見過ごすことはできません。それを無視すると、その後のMySQLデータベースミドルウェアの使用に影響を及ぼす可能性があり、問題を迅速に解決するようリーダーシップからの圧力もあります。最終的に、低コストのパケットキャプチャ分析ソリューションを実装することが決定されました。早朝にスクリプトが実行される際、サーバーでパケットキャプチャを行い、その時に何が起こっているのかを分析することになりました。目標は、MySQLデータベースミドルウェアが全く応答を送信しなかったのか、クライアントスクリプトが受信しなかった応答を送信したのかを特定することでした。MySQLデータベースミドルウェアが応答を送信したことが確認できれば、その問題はMySQLデータベースミドルウェアの開発者には帰属しないことになります。

3日目に、開発者たちは早朝の問題が再発しなかったと報告し、パケットキャプチャ分析も問題が発生しなかったことを確認しました。慎重に検討した結果、問題がMySQLデータベースミドルウェアのみに起因する可能性は低いと思われました。早朝に頻発し、昼間にはまれに発生するのは不可解でした。唯一の対処法は、問題が再発するのを待ち、パケットキャプチャに基づいて分析することでした。

4日目には、問題は再び現れませんでした。

しかし、5日目に問題がついに再発し、解決の希望がもたらされました。

パケットキャプチャファイルは多数あります。まず、開発者に問題が発生した時刻を提供してもらい、その後、膨大なパケットキャプチャデータを検索して、問題を引き起こしたSQLクエリを特定します。最終結果は以下の通りです：

上記のパケットキャプチャ内容（サーバーからキャプチャされたもの）から、SQLクエリは午前3時に送信されたようです。MySQLデータベースミドルウェアは、クライアントへのSQL応答を返すのに630秒（03:10:30.899249-03:00:00.353157）かかり、MySQLデータベースミドルウェアがSQLクエリに対して実際に応答したことを示しています。しかし、わずか238マイクロ秒後（03:10:30.899487-03:10:30.899249）に、サーバーのTCP層はリセットパケットを受信しましたが、それは非常に迅速でした。このリセットパケットがクライアントからのものであると即座に仮定することはできないことに注意が必要です。

まず、リセットパケットを送信したのがクライアントか、途中でインターミディエイトデバイスによって送信されたのかを確認する必要があります。パケットキャプチャはサーバーサイドのみで実行されたため、クライアントのパケット状況に関する情報は利用できません。サーバーサイドからのパケットキャプチャファイルを分析し、論理的な推論を適用することで、問題の根本原因を特定することが目的です。

クライアントがリセットを送信したと仮定すると、クライアントのTCPレイヤーはこの接続のTCP状態を認識しなくなったことを意味し、確立された状態から存在しない状態に移行します。このTCP状態の変化により、クライアントアプリケーションに接続問題が通知され、クライアントスクリプトが直ちにエラーになります。しかし実際には、クライアントスクリプトはまだ返信を待っています。したがって、クライアントがリセットを送信したという仮定は成り立ちません – クライアントはリセットを送信していません。クライアントの接続はまだアクティブですが、サーバーサイドでは、対応する接続がリセットによって終了しています。

では、リセットを送信したのは誰でしょうか？主な容疑者はAmazonのクラウド環境です。このパケットキャプチャ分析に基づき、DBAオペレーションはAmazonのカスタマーサービスに問い合わせ、以下の情報を受け取りました：

顧客サービスの回答は、分析結果と一致し、AmazonのELB（Elastic Load Balancer、LVSに類似）がTCPセッションを強制的に終了したことを示しています。彼らのフィードバックによると、レスポンスが350秒の閾値を超えると（パケットキャプチャで観測された630秒）、AmazonのELBデバイスはリセットを応答側（この場合はサーバー）に送信します。開発者が展開したクライアントスクリプトはリセットを受信せず、サーバー接続がまだアクティブであると誤って想定しました。このような問題に対する公式な推奨事項には、これらの問題を緩和するためにTCPキープアライブメカニズムを使用することが含まれます。

公式な回答を得たことで、問題は完全に解決されたと見なされました。

この具体的なケースは、オンラインの問題が非常に複雑であり、発生した状況を理解するために重要な情報（この場合はパケットキャプチャデータ）をキャプチャする必要があることを示しています。論理的推論と帰謬法の適用により、原因が特定されました。