G2ネットワーク性能監視ツール販売を終了しております。第12回:「サイレント障害」に挑む第12回:「サイレント障害」に挑むシステム管理者様のお悩みをお聞きしている際に、最近よく耳にするのが「サイレント障害」です。いろいろな解釈がありますが、広い意味でいうと「エラーとして把握できないシステムトラブルの総称」とここでは定義いたします。具体的な事象でいうと、監視ツールを導入しており、通常はトラブルが発生するとアラートとして検知するが、アラート検知ではない(サイレント)状態でも利用ユーザーから「つながりにくい」「遅くて使いものにならない」といったクレームで発覚する障害です。皆さま口をそろえて「解決までに非常に時間がかかった」とおっしゃいます。ネットワークは冗長化構成であり、サーバーも仮想環境で安定的に稼働し、ロードバランサーの管理も万全という環境であっても、この「サイレント障害」は発生します。大規模や複雑なシステムで発生頻度が高い傾向にあります。システムのトラブルは大きく3つの事象に分けられると考えています。ハードウェアの限界」は、機器故障やファシリティの問題で発生します。このトラブルについては死活・稼働監視にて状態を把握することが可能です。システムの稼働状況の変化」は、大体が稼働監視ならびに性能監視で把握することが可能です。ならびに複合型の要因で発生いたしますので、今までの監視手法では捉えられないということになります。ここで、サイレント障害のトラブル例を上げさせていただきます。・冗長構成のルータが両系でActiveとなってしまって、トラフィックが正常に処理されず、有償サービスで提供しているWeb画面が表示されたり・されなかったりの状態となり、大クレームとなってしまった。上記の状態であっても、監視装置からするとネットワークの疎通も問題なく、稼働監視としてActiveを正としていたので正常状態だったのですが、サービス利用ユーザーから多数の連絡を貰い、初めてシステムにトラブルが発生したことを把握したとのことです。「サイレント障害」の特長として「解決までに非常に時間がかかった」との声を冒頭で紹介しましたが、監視装置でトラブル状況が把握できないので、大規模や複雑なシステムでは、「どこが問題か?」「影響範囲はどこまでか?」というトラブル特定作業に膨大な時間や人を費やさなくてはいけなくなります。クレームの連絡の応対や、トラブルの特定作業や修正・変更作業、そしてシステムが回復した後の報告やお詫びの対応で、結果的には膨大な損失と疲労感だけが残ったとのことです。システムを安定化させるといいますが、システム監視はどちらかというと安定的に動いているのかといったことよりも、「異常」を検知することがメインとなっています。一般的な監視手法である、疎通の確認や、Trap/Syslogで異常メッセージを検知するといったことでお分かり頂けるかと思います。この「サイレント障害」の対策として、我々は「システムが安定的に動いているのか」をベースにした今までの監視とは違う手法を用いることで対応できるのでは、と考えています。「いつも通りシステムが動いているか」を性能監視で取得した安定稼働中のデータを元に学習をさせ、そのデータから変化があった場合に「何か問題が起きた」として、判断させる手法になります。新たな性能監視機能「ベースライン監視」として機能化しております。いったリソースの変動を捉えることで可能と考えています。「サイレント障害」の発生頻度が高く、発生時の影響度が大きい大規模システムは、この周期性というものが非常に顕著に出ます。サービスが正常に稼働していればトラフィックが上がるべきところが、何らかの問題で上がっていないといった、「いつも通りに動いていない」ことを検知する事で、初期対応を迅速におこなえるのではないでしょうか。「ベースライン監視」により、システム管理者の悩みである「サイレント障害」の対応を迅速かつ的確におこなうことができます。xSPといった自社以外のシステム運用をされている事業者様では、対象システムのサービスの正常性を把握することが非常に難しいのですが、この機能を活用することでサービス状況を細かく把握しなくても、「いつも通りか?(正常状態なのか?)」といった観点で対応することで、運用の簡便化だけでなく運用サービスの品質向上が可能ではと考えております。次回のテーマは「SNMP監視の可能性と新たな挑戦」です。サイレント障害についての最新コラム「第39回:サイレント障害の解決に向けて」も合わせてご確認ください。