運用を支える監視システムを構築する
障害検知の技（3） HTMLに含まれる文字列を監視
WebページのHTMLソースに書かれている文字列を判断して監視することもできます。文字列の検索には「grep」コマンドを利用します。
--------------------------------------------------------------------------------
$ wget -q --no-check-certificate --tries=2 --timeout=5 -O - http://boowy.jp/ | nkf | grep body
（結果）
$
--------------------------------------------------------------------------------
上記の例では、HTMLソースの中で「body」という文字列を含んだ行を表示しています。このページでは、bodyタグを2つ検索できました。
このコマンド結果の行数をカウントしてみましょう。行数のカウントには「wc」コマンドを使います。
--------------------------------------------------------------------------------
$ wget -q --no-check-certificate --tries=2 --timeout=5 -O - http://boowy.jp/ | nkf | grep body | wc -l
（結果）
2
$
--------------------------------------------------------------------------------
結果は「2」（2行）となりました。 この2という数字は、正常（5秒以内で2回のリトライ以内）にページが見える状態で、HTMLソースのbodyタグが2個とも表示できている場合にだけ、2となります。コンテンツが変わらなければ、いつも「2」となるはずです。
このコマンドが便利なのは、検索する文字列として「body」の部分を変えることで、さまざまな使い方ができることです。
例えば、Webページのソースの中に1つだけある「FAI BOOWY.JP」をカウントすることができます（この場合、grepの後ろの文字列をダブル・クォーテーションで囲む必要があります）。この1つだけある文字列を監視すれば、特定サイトのページが正しく表示されているかを確認できます。
--------------------------------------------------------------------------------
$ wget -q --no-check-certificate --tries=2 --timeout=5 -O - http://boowy.jp/ | nkf | grep "FAI BOOWY.JP" | wc -l
（結果）
1
$
--------------------------------------------------------------------------------
以下の例では、ページの著作権表示（コピーライト）部分が正しく表示されているかどうかを確認しています。
--------------------------------------------------------------------------------
$ wget -q --no-check-certificate --tries=2 --timeout=5 -O - http://777works.jp/ | nkf | grep "Copyright （c） 2010 777works.Inc" | wc -l
（結果）
1
$
--------------------------------------------------------------------------------
同様に、DOCTYPE HTML PUBLICが正しく表示されていることを確認したい場合は、以下のようにします。
--------------------------------------------------------------------------------
$ wget -q --no-check-certificate --tries=2 --timeout=5 -O - http://livejp.net/ | nkf | grep "DOCTYPE HTML PUBLIC" | wc -l
（結果）
1
$
--------------------------------------------------------------------------------
コメント文も監視ポイントとして利用
さらに応用で、HTMLソース内のコメント・タグをして監視ポイントとして利用できます。監視を目的としたコメント・タグを埋め込んでおくのです。コメント・タグは、HTML内にある「」の形状をした文字列です。
また、HTMLを動的に生成することで、wgetを用いたHTML監視の枠組みの中で、外部のDBサーバーが動作しているかどうかを調べることができます。例えば、PHP言語を用いたWeb連携アプリケーションからDBサーバーへ接続して常に200という数字を表示する監視ポイントを設計できます。
監視ポイントのURLは「http://livejp.net/db_test.php」としました。このphpスクリプトは、アクセスされるたびにDBと通信し、いつも200という決まった数値をHTMLに埋め込んで表示します。DBが停止している場合は、このページに200という数字を埋め込みません。
このように、Webページにphpによる監視ポイントを設計／設定し、その文字列をチェックすることにより、WebサーバーとDBサーバーが正常で、なおかつphpが動作してコンテンツを返している状態を、1回で確認できるようになります。
--------------------------------------------------------------------------------
$ wget -q --no-check-certificate --tries=2 --timeout=5 -O - http://livejp.net/db_test.php
（結果）
200
$
--------------------------------------------------------------------------------
この結果に対して、200の文字列をカウントすることで、「1であればDBが正常に動いている」「1以外であれば障害」と判断することができます。
--------------------------------------------------------------------------------
$ wget -q --no-check-certificate --tries=2 --timeout=5 -O - http://livejp.net/db_test.php | grep 200 | wc -l
（結果）
1
$
--------------------------------------------------------------------------------
これらをスクリプトにして保存しておくことで、日常の監視業務に役立てることができます。正常/異常の判定のほか、メールによる通知機能なども盛り込んでおくことで、実践的な監視が可能になります。
“人”が運用を支える
運用監視に際して、大切なポイントがあります。それは、人が運用を支えているということです。このことは技術者の方々には当然のことですが、エンドユーザーと顔を合わせる営業担当者や管理職の方には、ぜひ知ってほしい部分です。
24時間365日の運用というのは、必ず誰かが年末年始でもお盆休み中であっても待機していることを指しています。監視システムが障害を検知した場合、その検知された情報から本当に障害が発生しているかどうかを確認するために、必ず人間の目が必要になります。
例えば、Webの障害を検知した場合、Webブラウザで実際にアクセスし、遅延しているのか、タイム・アウトしてしまうのか、一部の表示ができるのか、DNSでの名前解決ができていないのか、エラー・ページを表示中なのか、といったさまざまな確認を実施します。こうした人間による確認によって障害の全体像がつかめてきます。人的な介入があって初めて障害の内容が判明するのです。
サポート・チームが障害の内容を把握した後は、技術チームの出番です。サポート・チームはまず、目視確認で判明した異常の内容を技術チームに伝えます。技術チームは、必要に応じて障害発生サーバーにログインし、調査から復旧までの作業を実施します。
筆者が所属するスリーセブンワークスでは、障害の検知から復旧までの一連の作業をおよそ30分以内に行います。また、障害の一時切り分けの段階で、エンドユーザーにメールで報告しています。障害を検知してから瞬時に初動を開始することで、サービス・ダウンの時間を大幅に減らすことができるほか、不正な攻撃を防ぐ手段を考えることができます。
障害の内容に応じて対処方法を柔軟に変えることも大切です。例えば、メール・サーバーが停止した場合、顧客からの重要なメールが届かないかもしれません。システムが攻撃されていることに気がつかなければ、後で重大な被害に結び付く場合もあります。APIの通信ができなければ決済ができず、販売のチャンスを逃すことになります。RAIDディスクが破損した場合、ホット・スペア構成であれば翌日対応でもよいでしょう。複数のサーバー構成で行っているサービスで、1台のサーバーだけに異常が発生しているのであれば、そのサーバーを一時的にサービスから切り離すことで解決できるでしょう。
こうした判断を下すのは、サービスやシステムに精通したエンジニアです。このため、監視システムからの通知を受けてからエンジニアが素早く対応できる人的ネットワークが何よりも重要になります。さらに、きちんと障害報告を行って再発防止の提案を行う部分までが、本来の意味での運用サービスであると考えます。
第3回はこれで終わりです。ほとんどの案件において構築や設計のみが重要視されている中、現在では可用性／耐障害性の高いシステムが求められています。こうしたシステムを守り続けていく“人”の部分も、システムに増して重要であることを、この記事をきっかけに見直していただけると幸いです。
最終回となる次回は、ネットワークの性能を高く維持するための方策を解説します。机上計算と実践の違いを指摘しながら、職人としての心構えについて述べます。
