【教科書】 ITシステム監視の重要性(その4)

こんにちは。SolarWinds Japanの山田晃嗣<Kozy>です。

前回の(その3)に続き、「【教科書】 ITシステム監視の重要性」の(その4)です。これでこのシリーズも完結です。


“オブザーバビリティ”(可観測性)とは

IT監視の分野では最近よく使われる言葉ですが、「可観測性」という言葉にはより深いルーツがあり、IT監視を理解しようとする人にとってはより大きな意味を持っています。このドキュメントで1つの独立したセクションに渡って解説する意味は大いにあるでしょう。

工学や数学の分野である「制御理論」の一部として1960年代に作られたこの言葉は、外部出力から内部状態を判断できるシステムを「観測可能」としています。分かりやすい例としては、自動車用エンジンの内部温度を表示する外部ディスプレイが挙げられます。少なくともエンジン内部の温度に関しては、エンジンは名目上「観測可能」と考えられます。

ITの世界での「オブザーバビリティ(可観測性)」は、継続的に動作するシステム(アプリケーション、もっと言えば相互に関連するアプリケーションの集合)が上の例えの「エンジン」に相当します。観測可能とは、アプリケーションのすべての要素の状態が出力から把握できることを意味します。プログラムを止めてコードを調べたり、メモリダンプを見たりする必要はありません。

このような考え方が定着したのは、2010年代初頭にDevOpsが台頭した頃からでした。より良いサービスを提供する激しい競争の中で、ITの開発側と運用側の両方を担当できるような文化の醸成が求められるようになりました。新しい変更を本番環境に迅速に(必要に応じて1日に何度も)デプロイすること、システムのパフォーマンスや安定性を判断するためだけでなく本番環境でのユーザーの行動や体験に関する教訓を引き出すためにIT監視を使用すること...これらを達成するために、この分野の初期のリーダーたちは、部分的なメトリクス情報だけでは十分でないことに気づきました。結局のところ、アプリケーションをその場で変更し、「本番環境でのテスト」というリスクを冒すのであれば、どのような変更がどのような影響を与えるのかを、可能な限りリアルタイムに正確に知る必要があるのです。

これを実現するには1つのツールや技術では対応できません。そこで「メトリクス」、「ログ」、「トレース」という「オブザーバビリティの3つの柱」という概念が注目されました。しかし、単にメトリクスやログ、トレースを収集する監視ツールがあるだけでは不十分です。真のオブザーバビリティを実現するためには、すべてのデータを組み合わせて新たな知見を得ることが必要です。

オブザーバビリティは、それをお金で買って今ある監視ツールに取り付けるようなものではなく、「概念」なのです。その概念に十分精通していれば、どのような監視システムが基準に適合するのかを正しく理解することができます。

ITシステム監視のためのヒント

このセクションでは、仕事を効率的に進めるための、IT監視に関する様々な問題点、得策、トリック、哲学的なアイデアなどを、順不同に列挙しています。

フラッピング (または “のこぎり波振動”)
アラートが繰り返し発生する場合(デバイスが何度も再起動したり、ディスクドライブが満杯に近い状態で推移したり、プロセスが一時ファイルの削除や作成を繰り返したりして、しきい値を超えたかと思うと、次の瞬間には下回っていたりする)、フラッピングやのこぎり歯振動と呼ばれる状態になります。

これを避けるために、ツールセットに応じた方法がいくつかあります。

» 期間内の同一イベントの抑制:ソフトウェアによっては、一定期間内の重複したイベントを無視することができます。
» トリガー前の遅延時間:障害状態が本物であることを確認したい場合、いくつかのIT監視ツールでは、アラートをトリガーする前にXX分(またはアラートがXX回発生する間)待つことができます。
» 元のアラートのリセットまでの同種の新規アラートの抑制:より洗練されたIT監視ツールは、同種の新しいアラートをトリガーする前に、リセットイベントを待ちます。アラートのリセットはトリガーに似ていますが、一般的にはその逆になります(アラートが90%以上の場合、リセットは90%未満かもしれません)。良いツールでは、トリガーとリセットの条件を個別に設定することができます。例えば、ディスクが90%を超えたときにアラートをトリガーするようにできますが、80%未満になるまでリセットされないようにできます。さらに、アラートのトリガーとアラートのリセットの両方に遅延を加えることができれば、デバイスが2分間ダウンしたときにトリガーし、10分間アップした後にのみリセットすることができます。
» チケットやアラート管理システムとの双方向通信:これにより、人間が元の問題を修正してチケットをクローズするまで、同じデバイスに対して同じアラートを出さないようにできます。

依存関係(親子関係)
シンプルな環境を想像してみてください。遠隔地にルーターがあり、ルーターにスイッチが接続され、スイッチにサーバーが接続されているとします。そして、あなたはホームオフィスから監視しています。デバイスがダウンしたとき(pingが効かなくなったときなど)にアラートを出したいとします。

とりたてて特別な方法を使わなかったとしたら、ルーターがダウンした場合、ルーターそのものに加えて、ルーターの先にあるスイッチとサーバーにもpingは届かなくなりますから、それら3つのアラートが(少なくとも)トリガーされることになります。

依存関係(通常、デバイスのセットごとに手動で設定する必要があります)とは、各デバイスが他のどのようなデバイスとどのように接続されているかを監視システムに伝える方法です。これにより、親デバイスがダウンした場合(ルーターはスイッチの親、スイッチはサーバーの親であると仮定します)、子デバイスに関連するアラートは抑制されます。ルーターがダウンしていても、スイッチがダウンしているとは限らないのです。ルーターのダウンによって単に到達できないだけかもしれません。

さらに洗練されたツールでは、あるデバイスをダウンとしてマークする前に、その上流にある親デバイスをチェックし、最上位の応答しないデバイスを見つけるまで、チェーンをさかのぼってチェックすることがあります。これをアップストリーム・ベリフィケーション(逆はダウンストリーム・サプレッション)と呼びます。これ以外の多くの場合、余分なポーリングサイクルで依存関係の管理が実現されますが、アップストリーム・ベリフィケーションなら、親機の状態を通常のポーリングルーチンで検証することができ、サーバーの負荷を増大させません。

デルタの監視
ディスクの空き容量を監視する場合など、特定の容量を基準にしたしきい値(例えばディスクの使用率が90%以上になったら警告するなど)は、意味の無いものになりつつあります。これはディスクのサイズがあまりにも大きくなり過ぎたためです。仮にディスク容量が残り1%だとしても、すぐに警告を発するべきとは必ずしも言えません(1テラバイトのドライブの残り容量が1%だったとしても、なんと100ギガバイト以上の容量が余っているのです)。

むしろ、デルタ(変化率)を監視したい場合が増えています。例えばディスク使用率がYY分の間にXX%以上上昇した場合、使用量の急増を示しています。これを放置しておくと、短時間でディスクが満杯になってしまう可能性があるのです。

もちろんディスクの空き容量の少なさも障害の要因のひとつです。しかし、現在の多くの企業環境では、そのあるべきしきい値は大きく変化しています。

イベントの相関関係
イベント相関はとても大きなテーマです。大き過ぎてこのドキュメントの1つのセクションでは対応しきれませんが、ある程度説明しないといけないでしょう。

イベント相関ツールは、フラップ(のこぎり波振動)の検出と抑制、および親子間の依存関係(前述)をうまく扱えます。さらに、イベント相関ツールは次のようなことを行うことができます。

»Xが起きたらYを見る:ある1つのイベントが起きたら、最近のイベント(秒単位、分単位)から別のイベントを検索し、両方が発生していたらトリガーされます。

» Xが起きたら YY分待ったうえでZを見る:前述の状況と似ていますが、この場合、Xは原因となるイベントまたは最初のイベントであり、タイマーを開始します。タイマーで設定した期間内で2回目の特定のイベントが発生した場合、アラートがトリガーされます。

» 重複排除:フラッピングを「修正」するための2つの手法のうちの1つです。一般的には、最初の発生時にアラートを発生させそれ以降の発生を無視します。ただし、1)最初のイベントで追跡可能なチケットが作成され、オペレータ(人間)によってクローズされた場合と、2)一定の時間が経過した場合の2つは除きます。

» XX回目以降に警告:フラッピングに対処するための2つの手法のうちの2つ目です。この場合、フラッピング自体が指標となります。一度だけの発生であれば無視できますが、繰り返し発生することで問題の存在を示します。そのため、イベント相関システムは特定のシステムに対して特定のエラーが何回発生したかを記録する必要があります。このカウントが十分に高いレベルに達したとき(おそらく特定の時間枠内で)、アラートが作成されます。

エージェントベースかエージェントレスか?

IT監視技術の大きなバリエーションの一つに、エージェント(監視対象の各デバイス上で動作する小さなソフトウェア)をベースにしたツールか、エージェントレスで動作するツールかという点があります。それぞれにメリットとデメリットがあります。本当の意味でのハイブリッド・アプローチを採用しているIT監視ソリューションは多くはありません。ほとんどのソリューションは、どちらか一方を強調しています(完全ではないにしてもそれなりに強調しています)。

エージェントベースの監視には、ネットワークに依存しないという利点があります(エージェントはデバイスが動作している限り実行され、データがサーバーに転送されるまでローカルデバイス上で保存されます)。また通常は管理者権限で実行され、高速で実行され(デバイス自体と同じ速度で実行される)、ネットワーク越しのリモートでは不可能な特定のアクションを実行することができます。

エージェントベースの監視の欠点は、エージェント自体の展開、管理、健全性の監視に多大な労力を要することです。さらに監視エージェントは、デバイスに問題を引き起こす可能性があります。デバイスに性能面で悪い影響を与えることなく、邪魔にならないように状態を監視することは難しいと言えます。

一方、エージェントレスでは、監視対象のデバイスへの影響はほとんどありません。ただし中には監視対象のデバイス上でスクリプトを実行する手法が取られ、僅かな負荷を監視対象のデバイスに与える場合があります。しかしよほど悪いスクリプトでない限り、その負荷は無視して良いでしょう。

エージェントレス監視のもう一つの利点は、継続的な管理と維持の容易さです。パッチやアップグレードが必要なエージェントがそもそも存在しないため、その労力は非常に小さくなります。エージェントレス監視ソリューションを維持するために必要な作業は、ポーリングエンジンとデータベースの健全性の維持が中心になります。

もちろん、トレードオフとして、エージェントレス監視では、収集されるデータの粒度や、問題発生時の自動応答の堅牢性については犠牲になることがあります。また、すべてのポーリングが集中管理されたサーバーから行われるため、監視インフラへの負荷も大きくなります。そのため、エージェント監視よりも多くのサーバーが必要になることがあります。

以上のことから、エージェント対エージェントレスの議論は目的や環境に適したツールを選択することであり、どちらが「良い」か「悪い」かの議論ではありません。

では何を導入すべきなのか?

必要なデータの種類や手法にかかわらず、このドキュメントで説明されていることを実行するにはソフトウェアツールが必要です。どのソフトウェアベンダーも、基本的には同じシナリオに基づいてツールを作っています。したがって、所謂「Apple to Apple」の比較(同一条件での比較)ができることになります。一方でツールを選ぶことが難しくなりがちです。なぜなら何を差別化要因とすべきかが分かりにくいからです。ある製品Xが他の製品Yよりも優れているとしたら、それは何故なのでしょうか?

その答えは、監視の実施方法もさることながら、あなたとあなたの組織に大きく関係しています。私の経験から言うと、優れたIT監視を導入するためのコストは、どんなソリューションを選択しても大して変わるわけではありません。ただしその「支払い方法」は変わるかもしれません。
両極端の一方の例として、カスタムメイドのbashスクリプトを駆使した完全に自作のソリューションがあります。この場合、ソフトウェアの購入コストはゼロになるかもしれませんが、作成するための社内の労力は大きく、また、維持するための社内の労力も同様に大きくなります。当然それらにもコストはかかります。

それとは対極にある例として、完成品として販売されているツールでは、それをそのままデータセンターに設置し、長期的なサービスを受けることで、本番稼動前にすべてを完璧に調整することができます。この方法では、社外に払うコストが必要ですが、社内での努力は最小限で済みます。

この2つは明らかに両極端であり、初めてデータセンターに足を踏み入れた日から誰もが理解している「内製対購入」のトレードオフを説明したに過ぎません。しかしながら、監視の世界ではこの両極端を議論することは十分に意味のあることです。なぜなら、様々なツールがあるにもかかわらず、IT監視を行うための基本技術はまだほんの一握りしかなく、いずれも上記両極端に近いところにあるからです。

選択するツールの違いは、実は見た目や使い勝手の違いなのかもしれません。

しかしユーザー・インターフェイスやグラフのスタイルといった「見た目や使い勝手」の違いは馬鹿にはできません。これは、導入、設定、管理維持に直結するのです。できることの柔軟性にも繋がります。そして何よりも重要なのは、集めた情報を(ツール内と外部システムの両方で)どこまで有効活用できるかということです。

リアルな答えは下記の3つの基本的な検討事項に行き着きます。

1. 監視によって得たい情報の種類
2. 監視に関わる人材(その人数、監視に関わる度合、スキルセット)
3. 支払える金額(外部に払う金額だけでなく人件費も含めて)

一方、技術的なこと以外で検討すべき項目は以下の通りです。

» 購入とインストールにかかる費用:これには、ハードウェア要件や環境特有のニーズが含まれます。ファイアウォール内外のデバイスを監視するために、複数のシステムが必要かどうか?社内の一通りの機器を監視するためにはどれくらいの規模の監視システムが必要か?など、様々なことが考えられます。
» 継続的なメンテナンスコスト:2年目以降に必要な保守料などです。
» サポート要件:システムのメンテナンスには何人の人が必要か?外部業者の回答を信用してはいけない質問のひとつです。そのソフトウェアを使用している他の会社に聞くのがベストです。
» どの程度のカスタマイズが必要か?

技術的な要件については、様々なツールセットの技術的なメリットを比較するべきでしょう。その際に、ダウンロードできる以下の機能マトリックス表が役に立ちます。(Excelシートで提供。英語版のみ)

Monitoring Feature-Function Matrix (XLSX)

まとめ
多くのITプロフェッショナルにとって、IT監視は自分の仕事の中心ではなく、日々のToDoリストのチェック項目のひとつでしかないかもしれません。しかし、ネットワークエンジニア、シスアド、クラウド担当者、仮想基盤担当者、情報セキュリティ担当者などが監視に興味を持つことはごく当たり前なことです。事実、監視は、ITの中でもはや「規律」とも言える必需品なってきているのです。あなたの企業のビジネスの成功を確実にするために、最新のシステム、ネットワーク、ストレージ、セキュリティを備えていることと同様に、監視は重要なものとなっているのです。

そうは言っても適切なツールがなければ、監視はすぐに混乱した状態に陥ります。それは、データの欠落、当てずっぽうの作業、長い夜、栄養ドリンクの空き瓶、そして大きな後悔です。適切なツールを導入するための最初のステップは、それを正しく理解することです。監視の要素技術がボンネットの中で何をしているのか、そしてどのようなデータを提供することが期待できるのかを、正しく正確に理解することが求められます。


以上でこの「ITシステム監視の重要性」の内容は完結です。お読みいただきありがとうございました。