（2016年時点での内容をアーカイブとして掲載しているため、一部の掲載内容が最新情報とは異なる場合がありますので、ご了承ください。最新のIBM Cloudの情報は IBM Cloud Docs や IBM Cloud アップデート情報 、柔らか層本をご参照ください。）
解決したい課題
ウェブ・アプリケーションの不具合によって販売機会を逃すことは、ビジネス上の損失であり、重要な課題である。 ところが、監視システムのエージェントを使ってサーバーやプロセスを内部から監視するだけでは、この様な問題の発見は難しいという課題がある。
ソリューション・パターン
ロードバランサーからアプリケーションの動作チェックに加えて、他地域のデータセンターの仮想サーバーからアプリケーションを監視することで、応答時間などユーザーの体感に近いモニタリングを実施できる。
インプリメンテーション
外部からURLアドレスをアクセスして、アプリケーション・サーバーとデータベース・サーバーの接続などを監視するための設定を行う。
ヘルスチェック対象のウェブ・サーバーが2台、そして、ローカル・ロードバランサーを配置する。
ローカル・ロードバランサーに対して、HTTPのカスタムチェックに、チェック・プログラムのURLを設定する。
このチェック・プログラムは、データベースやLDAPなどのサービスをアクセスする確認プログラムである。 このプログラムが問題を発見した場合、ローカル・ロードバランサーへ正常時と異なる文字列を返すことで異常を通知する。
さらに、他地域のデータセンターに、アプリケーションのモニタリング用の仮想サーバーを配置する。
このモニタリング用の仮想サーバーから、ウェブサーバーのパブリックIPアドレス、ロードバランサーのサービス用のIPアドレスを通じて、定期的にチェック・プログラムをアクセスして健全性を確認する。
監視対象のURLアドレスから異常を示す応答が返ってきたら監視システムへ異常を通知する。
このモニタリングでは、時間ごと機能別の応答時間などの分析を加えることが可能となり、サイトのサービス品質を高めることができる。
効果
アプリケーションの異常を素早く検知して、対応を開始できるため、営業的損失を最小に抑えることができる。
仮想サーバーとエントリーレベルのローカル・ロードバランサーを使って、購入価格数百万円クラスのロードバランサーと同等のヘルスチェックが実現できる。
このパターンでは、インターネット側からチェックするため、利用者のアクセス経路に近い形で状態を把握できる。
ヘルスチェックを実行する仮想サーバーは、通信料を含めても数千円以内に抑えることができ、経済的である。
懸念事項・注意点
ヘルスチェックのプログラムの実行負荷が大きい場合、サーバーのリソースを大量に消費して、本番サービスへ影響を与えるなどの懸念がある。 この様な場合、チェックの間隔を長くするか、ヘルスチェック・プログラムの見直しなどが必要である。
なんらかの障害が発生した場合、チェック間隔ごとに異常が通知され、他の重要な通知が埋もれてしまう可能性がある。 このため、ヘルスチェック用のサーバーのシェルでは、正常から異常へ変わった場合だけ通知するといった工夫が必要である。
利用料金が高くなってしまうが、次の図の様にNetScalerを利用して、ウェブ・サーバーの応答文字列を監視しておき、期待値と異なれば、SNMPのトラップを通知できる。 NetScalerの豊富な機能、高い性能、高可用性も利用できるので、費用対効果を鑑みて選択することをお勧めする。
参考資料
3.3 ロードバランサーを導入するには？
3.3.1 ローカル・ロードバランサーを使うには？
3.3.2 専用ロードバランサー(Citrix NetScaler)を使うには？
6.8 NetScalerを2重化するには？