ネットワークは多くを語っているが、誰も聞いていない

想像してみてください。時刻は夜11時。突然、重要なアプリケーションが停止しました。当直のエンジニアが緊急のリモート会議を立ち上げると、20分も経たないうちにネットワーク、データセンター、セキュリティ、仮想化SRE、クラウド、アプリケーションの6つのチームが参加します。それぞれが自分のツールを開き、それぞれの担当領域だけを確認します。そして、すべてのチームが口を揃えてこう言います。

「うちではありません」

重要なのは、その回答が間違いではないことです。ファイアウォールチームが担当のプラットフォームを確認すると、トラフィックに異常はありません。データセンターチームがACIをチェックすると、ファブリックの状態は正常です。WANチームが見たところ、BGPセッションは確立されています。誰も嘘はついていません。問題は、各チームがパズルの1ピースについて説明しているにすぎないことです。すべてのピースをつなぎ合わせて初めて、何が起きているのかが分かります。しかし、全体像を把握できる人が誰もいません。

その結果、緊急会議は1時間も続くことになります。根本原因は、たった1つのCisco ACIのブリッジドメインが削除されたことでした。その影響で、あるサブネットがBGPから消えたため、Webサーバーに接続できなくなったというわけです。手掛かりは始めからずっとテレメトリの中にありました。しかし、誰にも見えていなかったのです。データがなかったのではなく、それを可視化するための適切な仕組みが構築されていませんでした。

これはテクノロジーの問題ではなく、運用モデルの問題です。そして、この問題は毎週のように、企業に金銭的な損失をもたらし、担当者の睡眠を奪い、信頼の低下を招いています。

どんな障害でも、その全容を明らかにするためのデータはすでに存在しています。問題は、それらが6つの異なるプラットフォームに分散し、共通のタイムラインで結び付けられていないことです

増え続けるデータと可視性の不足—現代のネットワークが抱える課題

この状況で本当に驚くべき点は、今日のネットワークがテレメトリをかつてないほど大量に生成していることです。Cisco NCS 5500ルーターは、あらゆるプロトコルや転送レイヤーにわたって、1秒未満の粒度でメトリクスを出力しています。Catalyst Centerは、キャンパスインフラに対してAIドリブンの問題検出を行っています。SD-WANは、人間がまばたきするよりも速く経路選択を行います。ThousandEyesはネットワークを外部から監視し、ユーザーが実際にサービスにアクセスできるかどうかを常に検証しています。

これほどのインテリジェンスとデータがありながら、運用チームはいまだにウォールーム(作戦司令室)対応を続けているのです。

実は、ボトルネックはもはやテクノロジーではなく、相関付けです。どの監視プラットフォームも、それぞれのドメインでは十分に機能していますが、互いに連携していません。障害が複数のドメインをまたいで起きると(重大な障害の多くはそうですが)、ネットワークだけでなく、チーム間のコミュニケーション不全もトラブルシューティングすることになります。その解決策は、ツールを増やすことではなく、すべてのツールを俯瞰でき、緊急会議が必要になる前に答えを示してくれるプラットフォームです。

「解決」の真の姿とは

私は当初から壮大な戦略を持っていたわけではありません。ただ、現場で何度も同じ問題に直面してきました。優れたツールは揃っているのに、チーム間で共通の視点がないという問題です。そこで私は、トラブルシューティングの順序を逆にしたらどうなるかを考え、デバイスではなくサービスから始めるという発想を形にしていきました。それを顧客に見せたときの反応から、現場にはやはり大きなギャップがあることが分かりました。

Splunk IT Service Intelligence (ITSI)は、サービスごとに総合的な健全性スコアを提供します。このスコアには、インフラのあらゆる層の状態が1つの数値で反映されています。スコアが低下した場合、関連するKPIを見れば、原因となっているドメインが分かります。このように、サービスからドメイン、デバイス、そして根本原因へと、手当たり次第ではなく、順序立てて掘り下げていきます。ACIのイベントとThousandEyesの障害は、同じタイムスタンプを共有しています。そのため、統合プラットフォームがあれば、その相関関係は1回のクエリーで確認できます。しかし、6つのチームが集まるウォールームでは、同じ確認をするためのやり取りに45分はかかるでしょう。

考えてみると、これは障害対応に限った話ではありません。このモデルで運用しているチームは、問題をもっと早い段階で検出することもできます。Splunkの動的しきい値機能は、特定のインフラの「正常な状態」を学習します。そして、固定のしきい値を超えたときではなく、その傾向に変化が生じたときにアラートを発します。これが、後手の対応から先手の対応への転換です。これは、あらゆる運用部門の責任者が望んでいるにもかかわらず、ほとんどの監視システムでは実現できていません。

^{ACME社のサービスヘルスコマンドセンターでは、ThousandEyes、BGP、Core、APIC、ESX、ファイアウォールの情報がすべて1つの画面で表示されます。ネットワークのあらゆる要素が可視化された状態です。}

6つのドメインと、ネットワークで生じる6つの意外な障害パターン

ネットワークが複雑なのは、それが複数の層によって構築され、各層に固有の障害モード、テレメトリ、そして上位層に密かに影響を及ぼす独自の仕組みがあるからです。私はLanternで、各ドメインを詳しく解説する6本の記事を公開しています。これをガイドマップとお考えください。

01 · 6つのチームすべてが「自分たちのせいではない」と言うとき — エンドツーエンドのサービス可視化

先ほどACIブリッジドメインのシナリオをご紹介しました。それがこの記事の内容です。この記事では、SplunkがACI、ThousandEyes、Cisco Firepower、VMware ESX、IOS-XR BGPから得られるテレメトリをどのように相関付け、単一のサービス健全性ビューにまとめるのかを詳しく解説しています。さらに、ITSIが6,000件もの生アラートを、1件の対処可能なインシデントに集約するプロセスも詳しく説明しています。どのチームも無関係を主張するような緊急会議に参加した経験がある方には、この記事は必読です。

Lanternで続きを読む → クロスドメインのネットワーク問題を数分でトラブルシューティングする

02 · スイッチポートから始まったWi-Fiの問題 — Merakiブランチネットワーク

トロント拠点のあるスイッチポートで、CRCエラーが発生しました。気付きにくいフレーム破損です。リンクをダウンさせるほど深刻ではありませんが、TCPの再送を引き起こし、全体的なパフォーマンス低下につながっています。APは無線チームが確認し、異常はありませんでした。ただ、スイッチは誰も確認していません。この記事では、Splunkが数百ものMeraki拠点を横断して環境全体の健全性スコアを同時に算出する仕組みを解説しています。これにより、最初のヘルプデスクチケットが発行される前に、物理層のスイッチ障害と無線サービスの劣化を関連付けることができるようになります。

Lanternで続きを読む → 大規模なMerakiブランチネットワークを運用する

03 · 監視を超えるWANのインテリジェンス — Cisco SD-WAN

SD-WANのトラブルシューティングは、想像以上に難しいものです。ある拠点が突然通信不能になった場合、その原因はBFDのタイムアウト、OMPルートの撤回、物理インターフェイスの障害などさまざまで、対処方法もそれぞれ異なります。vManageで見えるのは、デバイスのアラートです。一方、Splunkでは、健全性スコアからインターフェイスまで体系的にドリルダウンしながら、サービスへの影響と根本原因を可視化できます。この記事では、UTDセキュリティイベントやNetFlow分析についても取り上げ、実際にWANを流れているトラフィックと、ポリシー上、本来流れるべきトラフィックを比較しています。

Lanternで続きを読む → Splunkで企業のWANサービスの信頼性を確保する

04 · 無線に関する苦情の背後にある有線の問題 — キャンパスネットワーク

アクセス層のインターフェイスエラーは、APのアップリンクを不安定にします。APが不安定になると、ワイヤレスのオンボーディングに失敗します。オンボーディングの失敗が続くと、ヘルプデスクに「Wi-Fiの調子が悪い」という苦情が寄せられます。対応するチームも、使うツールも異なり、両者の間には連携がありません。しかし、Splunkが有線側の障害を無線側への影響に自動で関連付けることで、状況は一変します。この記事では、Catalyst Centerとの統合について解説するとともに、ITSIが予測エピソード機能によって、苦情が寄せられる30分前にサービスの劣化を検出する仕組みを紹介しています。

Lanternで続きを読む → キャンパスインフラをクロスドメインで可視化する

05 · 5分間隔のポーリングでは捉えきれないもの — SR-MPLSバックボーン

BGPセッションがフラップしても30秒で復旧し、SNMPポーリングの合間に事象は消えてしまいます。あるいは、IS-ISでSPF計算が異常に繰り返され、一時的に転送障害が起きますが、記録されることはありません。このようなリンクダウンイベントを伴わないパケットロスという「グレーな障害」は、アラームを発することなく、いつの間にかサービス品質を劣化させます。Cisco MDTによって、Cisco NCS 5500からデータを1秒未満の間隔でSplunkへストリーミングすることで、8つのプロトコル層にわたるすべての異常を検出できます。この記事は、事後レビューを「再現できなかった」という言葉で終えたことがあるすべての人向けです。

Lanternで続きを読む → MPLSバックボーンインフラをリアルタイムで監視する

06 ·誰も警告してくれなかった移行時の障害 — SRv6

ゾンビSID。静かに進行するASICリソースの枯渇。そしてアラームを伴わないロケータープロセスの再起動。これらはSRv6とMPLSの相互接続環境において実際に起きる障害モードであり、従来の監視では完全に検出できません。NCS 5500でSIDエントリ数が上限の16,000に達したとき、アラートは発生せず、トラフィックが静かに途切れ始めます。Splunkは、Cisco-IOS-XR-segment-routing-srv6-operを使って、テレメトリをクロスレイヤーで相関付けることで、これらの異常を検出します。MPLSからSRv6への移行を計画している方は、ネットワークで障害が発生して初めて気付く前に、この記事を読んでください。

Lanternで続きを読む → MPLSからSRv6への移行でリアルタイムの保証を提供する

📖 さらに詳しく知るには、Lanternでこの技術シリーズの全編をご覧ください

6本の記事で6つのドメインに対応し、実際のKPI、SPLクエリー、データ取り込みアーキテクチャ、YANGテレメトリのパスなどを解説しています。

→ クロスドメインのネットワーク問題を数分でトラブルシューティングする

→ 大規模なMerakiブランチネットワークを運用する

→ Splunkで企業のWANサービスの信頼性を確保する

→ キャンパスインフラをクロスドメインで可視化する

→ MPLSバックボーンインフラをリアルタイムで監視する

→ MPLSからSRv6への移行でリアルタイムの保証を提供する

最後に一言

ここまでご紹介した機能は、各チームがすでに使っているツールを置き換えるものではありません。Catalyst Center、vManage、Merakiダッシュボードは、それぞれ優れた役割を持っており、今後も使われ続けます。Splunkは、それらの上位に位置する運用レイヤーを追加します。これにより、一元化されたタイムラインや包括的なサービス健全性ビューが実現し、SPLによってすべてのデータを横断してクエリーを実行することが可能になります。

運用部門の責任者から、効果をどのように測定するのかとよく聞かれます。率直な答えはこうです。効果を最初に実感できるのは、マルチドメインの障害を1時間15分ではなく12分で解決できたときです。そして単一のダッシュボードで、原因となったドメイン、発生時刻、そして他の6つのドメインが正常だったことまで正確に確認できたときに、初めてその価値は明らかになります。それは指標ではなく、「瞬間」です。

ネットワークは長年にわたり、何が問題なのかを伝えようとしていました。問題は、あなたの監視プラットフォームが本当にその声に耳を傾けているかどうかです。

このブログはこちらの英語ブログの翻訳、森本 寛之によるレビューです。