当時の年齢が三十代ということで衝撃を受けながら進めますが、4年前のkanshi de mirai (第12回：「サイレント障害」に挑む) で話題にした「サイレント障害」ですが、ここ最近多数の問い合わせをいただいておりますので、より具体的な内容をということで記載をいたします。
「サイレント障害とはなに？」という方は、まだ若いころのコラム第12回を見て頂くと参考になると思います。
下記のグラフ1は、外部にサービスを提供しているサーバーのトラフィックグラフになります。
【グラフ1 トラフィックグラフ】
1. 夜間はトラフィックが高くなり、日中帯に低くなる傾向
2. 日ごとのトラフィックのピーク値はほぼ同じ
3. 25日の昼以降からトラフィックの傾向が違う
上記が挙げられます。
ちなみに、このサーバーは25日からサイレント障害が発生したグラフデータになります。
障害の詳細として、プロセスは正常に稼働しながらも内部の処理遅延が発生したことで、データ受信がしづらい状態が継続していましたが、監視ツールはシステム異常とならず、利用ユーザーからのクレームで初めて障害を発見しました。
このデータを監視ツールの観点から見ると、
● 監視のリクエストに対して、サーバーからの応答がある
● トラフィックの送受信についてもある程度の値が測定されている
● プロセス監視等の問題もなし
上記から「正常」状態と判定できる内容です。
監視ツールは正常であっても、実際のサービスは障害となっていること、これが「サイレント障害」になります。
System Answer G2のベースライン機能を利用した、下記のグラフ2をご覧ください。
【グラフ2 トラフィックベースライングラフ】
System Answer G2では性能監視データの取得後に、グラフデータの生成に合わせて、ベースライン値を計算します。
ベースライン値とは「ホスト」ごと、ならびにトラフィックやCPUといった「監視項目」ごとに性能監視データの学習をおこない続け、曜日・時間別に算出される「予想値」(いつも通りの値)になります。
ベースラインの機能は、学習の結果から「ベースライン値(予測値)」を瞬時に算出することと、今回の様なケースでは、現在の性能監視データの値がベースライン値から一定以上の乖離率と乖離した回数より「いつもと違う」と判断します。
グラフ1 でもお分かりになったかと思いますが、サイレント障害によくある「いつもと違う」システムの状況を把握するのは人間の得意なところですが、監視ツールは非常に苦手です。
これが「サイレント」と言われる所以です。
トラブルの解決は最終的には技術者の腕にかかってきますが、System Answer G2を有効的に活用することでサイレント障害や障害予兆の早期の検知が可能となり、人には頼らない自動化につながります。
このベースラインの活用には、サービスの稼働が把握できる監視項目をベースライン検知の対象とすることがポイントになります。
システムにより異なりますが、今回例に挙げたトラフィックや、ネットワーク経路であればファイアウォールや負荷分散装置のセッション数も有効です。
サーバーであればサービス処理数の情報を取得することや、標準MIBしか対応していないサーバーであってもTCP Establish (接続確立) の数値で代用ができるケースもあります。
IBCではSystem Answer G2だけでなく、ベースラインを有効的に活用するためのコンサルティングサービスも提供しておりますので、サイレント障害の解決や障害予兆の早期検知を検討されている方は、是非IBCまでお問い合わせください。
by 技術部 塚本 浩之
