詳細
みなさん、こんにちは。IBC株式会社の橋本と申します。
本日は「大量アラートに対応するためのメソッド」についてお話させて頂きます。
運用現場の今ある状況は新しいこと何かやりたいと思っても、今あるものを踏襲してしまい、なかなかうまくいかず状況に合わせてしまうような傾向があると思います。
この課題を解決できる方法を少しでもお伝えできればと思います。
改めまして、橋本と申します。 IBC株式会社のプロダクト事業部の責任者です。ネットワークエンジニアとしてキャリアをスタートさせ、2013年にIBCに入社しました。
所掌範囲は自社監視製品の「System Answer G3」という監視製品の開発、サポート、それ以外のネットワークの監視運用関連のプロダクトの事業責任者をしています。
IBCは今期から21期目の会社です。 茅場町にある会社で、「IT障害を0にする」ということをミッションに製品開発、コンサル、お客様対応等々をさせていただいております。
本日のセッションでお伝えしたいことは大きく三つです。
まず1つ目は、アラート制御の部分はオペレーションから設計する必要があるということ、またアラート制御は何か一つ入れれば良い訳ではなく、いくつかの複合で対応していく必要があるということ。
2つ目は、監視＋制御＋人で対応しましょうということ。
3つ目は、予防保守に対する取り組みの重要性についてお話させていただきます。
日本の状況と運用環境
運用現場では日々いろんなことが起こりますが、外部環境もかなり変わってきています。
取り巻く環境の中でインパクトが大きいものとして、まず円安です。 運用現場ではAWS、Azure費用が高騰してると思います。
さらに、ソフトウェア開発やシステム開発をしているみなさんであれば、オフショアの費用、海外のエンジニアの費用、このようなところも円安の影響を受けています。
まだまだこの状況は続くということで、運用現場にも相当のコスト削減圧力がかかってくると考えています。
しかし現場は人が少なく、なかなかコスト上げられないうえに、何かにつけてDXで解決しろというような話がでる等、運用現場の皆様は様々なプレッシャーを受けていると思います。
また、人が不足したおかげで無理が生じ、そこには無駄やムラが出てきます。
さらにシステム構成の変化、環境の変化という意味では、お客様の環境がマルチクラウドやハイブリッドクラウドが当たり前になり、WANもSSD-WANやゼロトラストの環境などで複雑性を増しています。
運用現場の人たちは日々のアラート対応だけでも大変ですが、このようなところにも知識をつけなければいけなくなっています。
運用技術者のこれから
経済産業省のデータによると、2022年から新しい IT市場が拡大してきました。これはAI等の分野になります。
かたや既存のIT技術は縮退するとされています。
旧来の技術体系を持った人が新しい市場に適応できるかというパーセンテージも出ておりますが、ほとんど対応できないという調査結果となり、数パーセントの人が新しい技術を身につけ、新しい市場に対応していくだろうと言われています。
「SAMS」の課題
弊社IBCも運用サービスをやっています。
「SAMS」と言ったサービスで、形態は一般的なMSPサービスだと思ってください。 我々は監視ツールを作ってきたメーカーですので、その運用ノウハウをMSPサービスに載せて提供しております。
提供イメージはお客様とVPNを繋ぎ、リモートでオペレーションするような形を取っています。
環境としてはAWS、Azure、OCI等クラウド環境が増えており、SAMSでも運用課題が出ていました。
先ほど言ったコストの増加の部分は事業として非常に大きなインパクトになっており、監視運用対象も増えています。
また副次的な影響として、多くの種類のアラートへの対応が必要になってきました。
オンプレのネットワークやサーバーは、二つ程度の監視ツールを見ておけば良かったですが、マルチクラウド/ハイブリッドクラウドになり、Cloud Watch、Azure Monitorも見なければいけなくなり、様々なところから通知が飛ぶようになりました。
しかし、対応すると言っても人がいません。SAMSの方もこういった課題を抱えてきました。
大量アラートへの対処と導入結果
多くのアラートに対して、どう対応したかをご説明します。
大量且つ様々なアラートが出るので、まずは不要なアラートを抑制していき、さらにアラートを集約する部分でKompira AlertHubを使用しました。
監視してるSystem Answer G3とKompira AlertHubを連携させ、クラウドネイティブから発行されるアラートもKompira AlertHubの方で集約をしました。
Kompira AlertHubを使用するメリットは、柔軟なルールが設定できる点、SaaS提供により導入は非常に早くて楽な点、拡張性がある点、このような部分が肝になっています。
導入した結果、（アラート数が）5200から200という数字になりました。
Kompira AlertHubを導入しているお客様1ユーザーあたりで月間発生してるアラートが、実測ベースで5200件アラートが上がっていたところ、導入後、実際に我々がNOCでアクションする必要があったアラートは200件になったということです。
ここまでドラスティックに数字が変わるかどうかは、環境に依存する部分があると思います。
導入は苦労しましたが、すごく成果が出たプロジェクトになったので、皆さんにお伝えできればと思います。
「Kompira AlertHub」導入成果
Kompira AlertHubでの課題解決についてお話させていただきます。
まず、Kompira AlertHubの概要を簡単に説明します。
左側の監視システムからアラートが飛び、これを受信スロットで受けます。そこから振り分けのルールを通過し、深刻度の上げ下げを行います。最後にその深刻度見て、トリガーがアクションに命令を出します
Kompira AlertHubの内部処理ですが、受信スロットからルールを通過し、深刻度の変化させることで、トリガー、静観対応、アクションに繋げます。
通知ではWebhookも使えるので、かなり柔軟な運用設計ができると思います。
設定件数は、実際に我々が使っている受信スロット、ルール、トリガー、静観ルールの数です。
結構な数があるので最初の設計は大変で導入も苦労しましたが、一度決まれば5200件のアラートが200件になる効果が出ています。
「Kompira AlertHub」導入時のポイント
Kompira AlertHub設定として、我々の場合はメール送信だけのアクションにしていますので、どういった場合にメールを送るのかやメールの内容は何かという部分で、ルール、アクション等の数が決まってきます。
ここでは導入時のポイントを二点挙げます。
ポイント１
1つ目として受信スロットやルール、トリガーの設計です。
我々は受信スロットを16個に分けています。これは監視ツールや監視ツールの中でもアラートの種類によって受信スロットを分けているためです。
最終的には、どの程度の柔軟性を持たせて初期設定をするかも含め設計を考えていただいた方が良いと思います。
スコープという深刻度を管理する単位がありますが、こちらはシステム単位にするか、機能別にするかで受信スロットからアクションまでの流れがかなり変わります。
設定のところで悩んだ際には、是非フィックスポイントさんにご相談いただければと思います。
ポイント２
2つ目は受信件数。Kompira AlertHubはSaaSで提供しているので従量課金になっており、どのぐらいアラートが発生しているかにより費用が変わってきます。この部分はしっかり設計してください。
「System Answer G3」の設計
System Answer G3にもアラート制御を入れています。
System Answer G3は、エージェントレスで監視する製品ということで、エージェントのラインナップは基本的にはありません。
SNMPやレスポンス等もともとネットワークの監視から入っている製品になりますが、今では当然AWSやAzure、WindowsもWMIで監視できるので、サーバーを含めた監視が可能になっています。
監視手法毎にアラート制御することができるので、このアラートをどうKompira AlertHubに渡すのかを設計しました。
また我々の製品の制御単位として、グループという単位を使っています。
このグループは「閾値が○○％以上のグループ」や、「閾値がICMPのタイムアウトがあった場合のグループ」といった形で作っています。
本来グループというと大阪支店、福岡支店等ロケーション別にグループ分けすることが多いと思いますが、こちらとは別にKompira AlertHub専用のグループをアラート制御するためだけに設定しています。
さらにアラートの種類による制御も非常に重要になってきます。
System Answer G3で発生するアラートには様々な種類があり、それぞれに継続回数が何回だったらアラート発報するかを制御しています。それぞれに継続回数が何回だったらアラート発報します、といった制御が可能になっています。
通常であれば監視ツールは何を監視するかを重視して設計すると思いますが、アラートで何を通知するか、どう通知するかというところまで含め設計することで、System AnswerとKompira AlertHubで最大の効果を発揮できます。
現場の声
次に現場の声をお伝えできればと思います。
先ほどKompira AlertHubにはルール数が数千あると言いましたが、これはメンテナンスに非常に気を使います。
何故かというと、間違えるとアラートがあがらず、完全に漏れてしまいます。ここは非常に怖い部分です。
我々はCSVで数千行を入れるようなオペレーションを行っているので、作業は決まった手順でできるようになっておりますが、それでもちゃんとあってるのか等の確認は少し手間がかかります。
気を使うと言いながらも現場ではオペミスが減っています。
以前は5000件受けてる時から考えると、時間短縮やオペミス減少はできて当然ですが、アラートが限定されるので、その後のアクションも定義しやすくなったメリットがあります。
5000件のうち1000件はこう動いてねと言われても、その1000件を探してくるだけでも大変ですので、非常にアクションがシンプルになって良くなったという話が出ています。
これまでのまとめ
大量アラートに対応する方法として、オペレーション側から逆算でしっかり設計していくところが必要だと思います。
アクションをシンプルにするにはどうするべきなのか、何を通知すべきなのかを設計します。
Kompira AlertHubの設計ができたところで、今度はそれに必要な情報をどう渡すかという監視設定側の設定を行っていきます。
System Answerが監視、Kompira AlertHubがアラートの制御、NOCが執行と、トータルで設計することでアラートが激減すると思います。
「System Answer G3」を構成に入れるメリット
アラート処理はKompira AlertHubでやっていますが、System Answer はアラートのグループ化しかやっていないと思われると思います。
ですが我々が「IT障害ゼロ」というミッションを掲げていますので、いかにアラートのない世界を作るかという観点で製品開発をしており、その機能を利用できる点がSystem Answer G3です。
予防保守という観点で機能を実装しており、例の一つ目としては「変動検知」が挙げられます。
タイムアウトは起きていないがいつもと違う動きをした際にアラートを送るという事ができます。ここにKopira AlertHubと組み合わせることで、他のアラート情報との組み合わせでアクションを定義する事ができます。
さらにキャパシティ予知という将来予測オプション機能があり、このままいくとリソースいっぱいになりますよ、といったアラートを出すことができます。
当然毎回アラート化していると誤検知がどんどん多くなり、現場が疲弊してしまいます。
そのため、ある一定期間連続した場合の制御などをKompira AlertHubで処理することで正確な情報としてアラート化する事ができるメリットがあります。
最後に
繰り返しになりますが、アラート制御はオペレーションから設定してください。
また監視＋アラート処理＋人で対応してください。今回はSystem Answer G3とKompira AlertHub、SAMSのお話をさせていただきました。
最後に、予防保守に対する取り組みも運用の現場としては必要ではないかということをお話させていただきました。
当社もこのような取り組みを通じて、「ITの障害ゼロ」へ一歩ずつ近づいていきたいと思います。
本日は以上です。ありがとうございました。
