シスコに置けるフルスタックオブザーバビリティの社内運用事例

IT テクノロジ進化は企業のデジタルトランスフォーメンションを加速させています。ネットワークやクラウド、ハイテクなエンドデバイス、そして斬新なアプリなどなどが企業のビジネス運営や従業員の働き方まで隅々に影響を及ぼしています。これらの IT テクノロジの健全性マネジメントも過去にないほど重要性が増しています。例えばアプリの動きが遅い、データベースが更新されない、ネットワークがダウンしているなどの問題が起きた時に、素早くトラブルの発生箇所を特定し、適切な対応を行うことは、IT 部署や各サービスオーナーに求められています。

しかし、それは言うほど簡単なことではありません。IT システムはとても複雑で、一言アプリの動きが遅いと言っても、それは本当にアプリ側の問題かもしれませんし、ユーザー自身の ISP（Wi-Fi 環境など）が停滞している可能性もあります。或いは、ネットワークのどこかがハッカーの攻撃を受け、パフォマンスが低下している可能性もあります。いろんな可能性の中から、本当の Root cause を探しているうちに、時間の経過につれ、問題がどんどん拡大する危険性があります。そのような状況を避けるには、フルスタックオブザーバビリティ（可観測性）の仕組みを構築することが必須になります。

シスコのフルスタックオブザーバビリティには、① 企業全体の Inventory ケースデータと基本サービス情報を収集する Full-Stack Visibility、② ドメインのライブモニタリングや関係性と優先度を分析する Full-Stack Insights、③ 正しいアクションや問題対応を行う Full-Stack Actions、の三つのレイヤーがあります。それぞれのレイヤー中に適切なツールや Agent を布石しています。Visibility レイヤーでシスコのセキュリティケース、IT ケースや各種サービス健全性の情報などを吸い上げします。Insights レイヤーでネットワーク、アプリケーション、データベース、クラウド、エンドデバイスなどの継続ドメインモニタリングを行なっています。そして BigData、AI/ML の技術を使って、自動修復 (Self-Healing)、或いは分析結果の通知や対応指示を Actions レイヤーの担当部署へ回し、Remediation を促す仕組みも構築しています。

そのフルスタックオブザーバビリティのお陰で、何かの事象が起きた時に、一から調査するではなく、インフラの全体像が可観測化されているので、逸早く問題点や Root cause を特定し、もっとも適切な方法で優先対応される確率がぐっと上がります。すなわち MTTD と MTTR が早くなります。また、それぞれの担当部署、例えば、ネジネスオーナー、IT オーナー (App, network, DB など)、SOC (Security operation center)、NOC  (Network operation center)、テクニックサポートセンター、エンドユーザー自身なども、対応エリアが見える化をしているので、悪く言うと責任転換ではなく、お互いに明確な連携方法を取れやすくなります。

シスコはフルスタックオブザーバビリティを実現するため、色んなツールや Agent を利用しています。それぞれのツールは特長を発揮して、データ収取や、AI 分析、システムモニタリング、自動問題対応、ケース管理などに活用されています。本ブログは、これらのツールの中のモニタリングツール AppDynamics と ThousandEyes、そして Event Aggregation& Correlation ツール CHAIN の社内運用を紹介します。

社内事例1

AppDynamics はシスコ社内のエンドユーザー IT 体験、アプリ健全性、データベース健全性のモニタリングに使用されています。シスコ社内アプリの半数以上、1000 個超えのアプリが AppDynamics にモニタリングされています。モニタリングスコープは下図をご参照ください。

効果はどれくらいあるのか、シスコの重要アプリの一つ SCM (SupportCaseManagement) で見てみたいと思います。SCM はシスコ社外のお客様がシスコへケースを上げる大事なアプリであります。従来はテクニックサポートセンターがお客様から SCM アプリ関連のケースを貰ってから、SCM アプリの健全状況や問題の発生箇所をチェックし始まります。このプロセス下のケース対応スピードは平均 30 分も掛かります。しかも事前にアプリの健全状況を把握できないせいで、お客様がケースを上げるまでに既に時間を掛けて自分で四苦八苦調べたかもしれませんので、IT 体験は非常に悪いものであります。シスコ社内のフルスタックオブザーバビリティに AppDynamics を利用された後は、殆どの場合はテクニックサポートセンターがエンドユーザーよりも先に問題を気づき、それの対応に取り掛かります。仮にユーザーからケースが上がったとしても、一から調査するというよりも、既に把握している状況をユーザーに伝え、最善な対応方法を行うのみであります。AppDynamics をフルスタックオブザーバビリティ取り入れてからは、SCM アプリ関連の問題特定は 50％ 早くなりました、ケース自体も 15% 減り、アプリの稼働率も 99.79% から 99.85% へ上がりました。

社内事例2

続きまして、シスコの社内フルスタックオブザーバビリティに使用されているもう一つの重要なモニタリングツール ThousandEyes のユーズケースを紹介します。ThousandEyes はシスコのデータセンター、グローバルネットワーク、主要エンドポイントに実装されていて、シスコのグローバルInternal Backbone Network、External Network Paths、グローバル VPN、ISP 健全性、DMZ パフォマンス、主要 SaaS パフォマンス、VOIP やビデオストリーム、Webex 体験などをモニターリングしています。ThousandEyes の導入により、問題発生時に、エンドからエンドまでのどこかに支障が起きているかを素早く特定することができるようになりました。例えば Webex のような SaaS サービスはデータセンターホスト、アプリ、ネットワーク、ユーザーデバイス、自宅 Wi-Fi などエンドからエンドまで色んな要素が関与しています。ThousandEyes が実装された後は、まずアプリの問題とネットワークの問題を簡単に分離できるようになりました、そして、ネットワークの問題であれば、どこで遅延しているかなども簡単なテストを行うことができて、該当箇所を特定し易くなります。こちらの図はシスコインドのユーザーが Webex 遅延を報告した後の ThousandEyes 調査結果になります。

以前は、この手の問題は該当箇所を調べるのに各部署に要請し、それぞれのドメインを調べる必要がありました。現在は ThousandEyes がエンドからエンドまでの状況を可視化してくれますので、こちらの例では脆弱ポイントはインドの Webex ホスト ISP にあると逸早く特定し、該当 ISP ベンダーとのやり取りで問題解決に繋がりました。

社内事例3

最後に Event Aggregation & Correlation に使用されているシスコ自社開発ツール CHAIN を紹介します。フルスタックオブザーバビリティ構造概念で示している各ドメインで収集してきた情報をより効率に使わせるには、データ内容の分析や、各ドメインデータの関連付け、そしてそのアウトプットをビジュアライズする必要があります。そのためシスコはウエブアプリ CHAIN を開発しました。CHIAN のイメージはウエブ Dashboard に近います。 CHAIN のサイトには、右のサンプルにあるように、ThousandEyes や AppDynamics の継続モニタリングデータや、各サービスドメインの健全状況一覧と区分け（サブドメイン）、そしてケースの集計情報と傾向分析などが載せています。CHAIN にはカスタマライズ機能もあり、単なる汎用情報の山盛りではなく、本当にユーザーが必要なエリアだけをフォーカスして、Dashboard を細かくアレンジすることもできます。例えば、ある重要なシスコイベントを行う時に、そのイベントと関係のあるアプリ、ネットワーク、データベース、ケース状況などだけを抽出して、CHAIN の Dashboard でビュアライズさせることができます。

このような専用 Dashboard はユーザーやサービスオーナーは自分でコンフィグすることができて、色んな情報の優先度をアレンジし、可視化したいドメイン群を特化することができます。さらに、CHAIN には通知や各種アラート機能もあります。事象が起きた時に、該当チームへ電子メールや、スマホにアラートをメッセージで知らせる（Pager 機能）設定が行えます。CHAIN で網羅した色んな可視化情報の中に何かのシステムアブノーマルが探知された場合、素早くアラートを該当部署へ知らせる事で、問題解決の MTTD と MTTR の短縮が図れるようになります。

本ブログはフルスタックオブザーバビリティの構造概念とシスコ社内の運用実例などを紹介しました。ご参考になれたら嬉しく思います。今後もシスコの社内 IT 関連情報を発信いたします。よろしくお願いいたします。