ServiceNowのネットワーク障害に対するプロアクティブな対応からの学び
障害から得られる教訓
2024年11月1日
著者: Sheikh Mursaleen
翻訳: 逆井 晶子
この記事は米Catchpoint Systems社のブログ記事「Learnings from ServiceNow’s Proactive Response to a Network Breakdown」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。
ServiceNowは、ITサービス管理、IT運用管理、ITビジネス管理の分野でトップクラスの企業の1つです。
彼らに障害やサービス中断が発生すると、何千人ものユーザーに影響を及ぼします。
間接的および誘発的な影響は、ITエコシステム全体に多大な影響を与えることになります。
考えてみてください。
障害のためにワークフローが中断されると、大規模で広範な波及効果が生じます。
例えば：
- ITチームは、従業員に対するサービスの堅牢性やユーザーエクスペリエンス品質を維持できなくなります。
これは、SLA（Service Level Agreement）の違反のリスクがあります。
また、ITに依存していた従業員の業務が継続して中断される恐れがあります。 - セキュリティチームは、脅威や脆弱性に対応できなくなります。
これにより、リスクが増大し、厳格なガバナンスとコンプライアンスの義務を遵守できなくなる可能性があります。 - アプリケーションオーナーと開発者の自動化タスクが停止します。
これは、重要なリリースの遅れのリスクがあり、その結果、追加の会議や、製品の更新を期待していたお客様との信頼の低下につながる可能性があります。 - 財務および調達部門が製品やサービスの供給業者を確保または支払うことができなくなります。
これは、製造プラントにおいて高価な組み立てラインの稼働が停止するリスクを伴います。
このリストはまだまだ続きます。
残念ながら、ServiceNowは最近、このようなタイプの障害を経験しました。
CatchpointのInternet Performance Monitoring（IPM）データを使用して分析を行いました。
ServiceNowは、より大きな影響を及ぼしかねない障害の影響を最小限に抑えるために積極的な対策を講じたことがわかりました。
詳しく見てみましょう。
何が起こったのか？
2024年8月15日14:15 ET、ServiceNowの主要サービスがダウンし、上流プロバイダーとの接続状況に応じて断続的な成功が報告されました。
障害は16:18 ETまで報告され、2時間3分の期間にわたりました。
この障害は、ServiceNowのポータルリソースだけでなく、クライアントの統合にも影響を及ぼしました。
CatchpointのInternet Sonarは、既存テストに設定した閾値を用いて分析し、アラートを発報しました。
Internet Sonarダッシュボードには、主要な地域からのレスポンスや接続タイムアウトエラーがリアルタイムで動的に表示されました。
障害のトレンドを観察すると、リソースは断続的に到達可能である一方、ほとんどのリクエストが長い接続時間に直面していることが分かりました。
この障害は、特にAS 6461 | Zayoとの接続が不安定になったことが原因でした。
Tracerouteモニタを使用して、Catchpointポータルでこの動作を確認しました。
ServiceNow は、データセンターのロケーションごとに複数の ISP を利用しています (https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0547560)。
このうち、ServiceNow と直接接続している主要な ISP は Lumen (3356)、Cogent (174)、Zayo (6461)、Level3 (3356)、AT&T (7018)、Verizon (6167) です。
障害発生前は、AS 6461 | Zayo がServiceNowにとって有力なトラフィックルートでした。
しかし、Zayoに重大な問題が発生すると、ルートの変動が生じ、ServiceNowのチームはBGPイベント（アナウンス、再アナウンス、撤回）を複数回行わざるを得なくなりました。
RIPEstatのBGPアクティビティ：アナウンスと撤回の増加
上記のRIPEstatでのBGPアクティビティを、以下の3つのシナリオで分解してみましょう。
- 障害前
- 障害中
- 障害後
障害前（8月14日 00:00～23:59 UTC）、AS 16839で合計178件のイベントが観測されました。
これらのイベントは、隣接関係の変化を含むSNC ASN内のBGPアクティビティの様子を示しています。
2023年8月15日の障害時、前日と比較してイベント数が大幅に増加し、491件に達し、ルートの撤回と再アナウンスが多く見られました。
この異常は、ServiceNowチームがインターネットからのアクセスを確保するために手動または自動で行った変更を示しており、ServiceNowのポータルやパートナーとの接続は依然として問題を抱えていました。
障害が収束した後、ServiceNowのASNはZayo経由での直接トラフィックを受け取らなくなり、問題が特にZayo-ServiceNow間のリンクにあることが示唆されました。
BGPは他のプロバイダを介して信頼性のあるルートを確保しました。
Zayo-ServiceNowのリンクの問題は、障害発生から10時間後（8月15日20:25 UTC ～ 8月16日06:28 UTC）に解決され、トラフィックは再び通常のルートに戻りました。
Catchpointプラットフォームでのネットワーク障害の監視
Internet Sonarやsynthetic test alertsに加えて、Catchpointポータルで次のような観察がなされました：
- 初期の再アナウンスとプリペンディング
- ルートの変動とコミュニティタグの変化
- ルートの撤回と再アナウンス
- ルート変更（プリペンディングとルート最適化を含む）
- 最終的な安定化
15:51 ESTには低レベルながらサービスは通常に戻り、BGPイベントに基づいてServiceNowチームがルートをロールバックし、トラフィックを代替IPにリダイレクトしました。
上記のスニペットから、障害前、障害中、障害後のトラフィックルートの変遷が観察されます。
リクエストは、元のIP（149.95.45.217）から新しいIP（149.95.29.217）にリアルタイムでリダイレクトされ、Zayo経由のトラフィックがBGPの更新により優先度を下げられていました。
学びと教訓
インターネット全体の制御は難しいものの、この障害から得られる教訓もあります。
BGPイベントが発生した際に積極的かつ必要な行動を取らなければ、長期的な障害が生じる可能性があります。
ServiceNowチームは、ネットワークの変動に基づき重要なリソースやクライアント統合の接続を回復しました。
ここの障害は、多くの組織にとって、以下の点について学ぶ絶好の機会となります:
- エンドユーザーとコンテンツの間にあるすべてのものを監視する戦略を再検討する
- フォールバックメカニズムを特定する
- ベンダーを監視し、責任を追求する
- 自社およびベンダーの障害管理プロセスを再検討する
- 緩和計画をテストすることを忘れない
現代の分散型環境では、アプリケーション提供プロセスは相互依存する多数の異なる部分で構成されています。
このような障害は、ネットワーク障害がインフラストラクチャ（DNS、ロードバランサー、CDN、クラウドインフラストラクチャ、データセンターなど）に、そして最も重要なことにエンドユーザーエクスペリエンスと全体的なビジネスに与える影響を示しています。
まとめ
- 各サービスとネットワーク全体を監視する必要性
- 主要なISPは避けられないダウンタイムを経験し、そのたびにグローバル企業は収益損失、生産性低下、サービス信頼性の低下により数百万ドルのコストがかかります。
- 障害の関連性
- 障害は、マイクロサービスに関連している場合もあれば、インフラストラクチャの障害に関連している場合もあります。
- SLAの維持
-
これらのサービスプロバイダーは、SLAを維持することが不可欠です。
また、ユーザーは、ベンダーの約束だけに頼るべきではありません。
障害が発生するとSLA違反につながり、これを証明するデータがなければ、罰金を避けることが難しくなります。 - エンドツーエンドの障害管理
- エンドツーエンドの障害管理を実装することで、プロアクティブな監視によりMTTD（Mean Time To Detect）を大幅に短縮することができます。
- 障害の迅速かつシームレスな処理
- Catchpointは、重要な資産データ、指標、履歴データなどを包括的に表示することで、障害の迅速かつシームレスな処理を促進します。
- 戦略的なプロアクティブ監視
- 戦略的なプロアクティブ監視は、マルチソースの主要資産、メトリックデータ、デリバリーチェーンの移動部分のいずれかをキャプチャして統合することで、Ops、SRE、SOC/NOCチームの効率を高め、MTTR（Mean Time to Recovery）を大幅に短縮すること役立ちます。