ネットワークの診断

現象の見え方... 原因は見えにくい

例えば DMZ にある IIS から内側の DB へ接続しているようなときに、ある日何らかの理由でファイヤウォールの設定が変ってしまい IIS 上のプログラムからデータベースへ接続できなくなってしまったとしましょう。

この時に、システムエラーとして直ちに「DB に接続できない」という旨が記録されれば、問題は「なぜ DB へ接続できないか」ということをポイントとして原因究明できます。

しかし、大抵は「あれれ IIS が動かない。なぜだろう」と右往左往してしまいます。

なぜなら Web-DB システムでは、ユーザーが直接操作しているのは Web サーバー側であり、そのバックエンドのプログラムを直接触っていないからです。

直接触っていないから、たとえバックエンドとか環境に原因があるとしても、動かないのは Web サーバーであるように見えます。

こういう事情がデバッグを難しくします。

問題が発生したときの第一歩は、適切に問題を切り分けていくことです。

ウェブシステムは、大きく分けてクライアント、サーバー、データベース等のバックエンドシステムにわけることができます。これらの問題を切り分けるためにどうしたらよいでしょうか？

まず、IIS とデータベース間で停止しているようなときは、ある特定の操作で Web アプリが停止しているよう見えるのが普通です。

そのような場合は、IIS プロセスのダンプファイルを採取します。ダンプを解析すればたいてい、どこの呼び出しで停止しているか、ほぼコード行を特定することが可能です。

解析の仕方はまた別のページで解説します。

つかみどころのない感じでまだらに停止あるいは応答がないような場合は、ネットワークの問題であることが多いです。

この場合はクライアント側、サーバー側両方で、netstat の結果と、ネットワークモニターを使ってパケットをキャプチャします。

パケットを解析すれば、「要求が届いていない」あるいは「応答が届かない」などの状況が見えてきます。