ITシステムやネットワークにつきものの「遅い」現象。しかし、誰もが一度は体験したことがあろうその身近な現象の正確な原因を突き止めることは難しく、ほとんどの「遅い」現象の原因はわからずじまいのまま一時的に解消してはまた再発を繰り返します。
ここでは「仮想化環境上に構築したアプリケーションが遅い」「仮想マシンへのログインが遅い」という現象を例に、現状と問題点、解決策を探ります。
時折発生する「遅い」の声。調査するも原因不明
仮想環境上に構築している業務アプリケーションの利用者から「業務アプリケーションの動作が遅くなった」という声を時折聞くようになりました。
アプリケーションの管理者がアプリログの調査をするも、アプリ側で問題が発生しているようには見受けられませんでした。
このアプリケーションが稼働している仮想マシンと仮想ホストのパフォーマンスは監視しているので、サーバー管理者が監視データを確認しましたが、アプリケーションの動作に影響を及ぼすほど仮想マシンや仮想ホストのパフォーマンスが低下している様子は見受けられませんでした。また、同じ仮想ホスト上に稼働している仮想マシンのパフォーマンスも確認しましたが、負荷の高すぎる仮想マシンは存在していません。
同時期に別の仮想環境上の作業端末へのログインに時間が掛かるようになったとの声も聞くようになりました。
今度はネットワーク管理者がハードウェアの故障かと思い、ネットワーク監視ツールでネットワーク機器の死活を確認し、実際にネットワーク機器の様子も見ましたが、エラーが出ている様子もなく、ハードウェアの故障でもないようです。
ネットワーク管理は一見完璧に見えるが…
現在この現場で実施している管理・監視の環境は以下の通りです。
- サーバー管理ツールによる仮想環境の管理
- アプリケーションログからアプリのパフォーマンス解析
- ネットワーク監視ツールによるネットワーク機器の管理
上記を全て実践できている現場は、一見完璧に見えます。しかし、唯一ここでは実施できていない調査があります。
それは、サーバーとネットワーク機器の間の通信の調査です。
現時点において「アプリケーション/ログインが遅い」原因としてサーバーのパフォーマンスやリソース不足ではなく、アプリケーションのバグ等でもなく、またネットワーク機器の故障などではないということが判明しています。
通信内容を調査して上記で判明している以上のことを突き止めるには、トラフィックの内訳を調査する必要があります。
しかし、パケットキャプチャで取得できるデータは膨大であり、膨大なデータの中から1つの事象の原因を突き止めるには膨大な時間と手間がかかってしまいます。
また、普段はアプリケーション管理者、サーバー管理者、ネットワークインフラ管理者と管理組織が分業化しており、サーバーとネットワークインフラの境界となるトラフィックの部分を管理する担当が決まっていないことも問題です。
このような場合、「遅い」原因を調査しても各部署には問題が無いため、
「サーバーの問題ではない。ネットワークの問題ではないか」
「ネットワーク機器にどこも問題は無い。アプリの問題ではないのか」
など、アプリケーション管理者、サーバー管理者、ネットワークインフラ管理者間で軋轢が生じてしまうこともあります。
「遅い」原因をパケットキャプチャせず特定するには
この原因調査をパケットキャプチャ無しで時間と手間をかけずに実施するには、トラフィック解析のツールを導入することが望ましいです。
しかし、トラフィック解析用のツールを新たに導入してトラフィック解析用の担当者を配置したり新たな部署を設置するには、ツールの導入費用も人件費も掛かるため、組織的に実現が難しい場合も多いでしょう。
ここで最も望ましい方法は、ネットワーク機器・サーバー・トラフィック解析を全て1つのコンソールで見られるツールを使用することです。
ネットワーク機器・サーバー・トラフィック監視が同時に可能な監視ツールを使用することで、複数のツールを使い分ける必要がなくなります。また、管理者や管轄組織が分かれている場合にも、同一ツール上からシステム全体のステータスやパフォーマンスを確認できるため、共通認識を持つことが可能になります。
ネットワーク経路の監視・輻輳の原因調査には
「ManageEngine NetFlow Analyzer」
