目次
1. 2023-03-08 インシデント: 複数の地域に影響を与えるインフラストラクチャ接続の問題
影響、時系列、対応
事件と影響
2023 年 3 月 8 日の 06:03 UTC から、すべてのサービスの US1、EU1、US3、US4、および US5 Datadog リージョンに影響を与える障害が発生しました。
インシデントが始まったとき、ユーザーはブラウザや API を介してプラットフォームやさまざまな Datadog サービスにアクセスできず、モニターも利用できず、アラートも出ませんでした。障害の開始時には、さまざまなサービスのデータ取り込みも影響を受けました。
年表
すぐに調査を開始し、最初のステータス ページの更新は協定世界時 06 時 31 分に問題を示し、最初の更新はデータ取り込みとモニターへの潜在的な影響を協定世界時 07 時 23 分に示しました。
UTC 09:13 (Web アクセスが復旧) に最初の回復の兆候が見られ始め、UTC 16:44 までに最初の主要なサービスの稼働を宣言しました。私たちは復旧努力を継続し、2023 年 3 月 9 日 08:58 UTC にすべてのリージョンですべてのサービスが稼働することを宣言しました。このインシデントは、履歴データをバックフィルした後、2023 年 3 月 10 日 06:25 UTC に完全に解決されました。
応答
最初に問題のあるアップグレードが発生してから 3 分後(2023 年 3 月 8 日、協定世界時 06:00)、内部監視によってこの問題について初めて警告を受けました。私たちは調査の 18 分後に内部で重大度の高いインシデントを宣言し、その直後、協定世界時 06 時 31 分にそれを公表インシデントにしました。
当社のインシデント対応チームには、10 人の上級エンジニアリング リーダー、約 70 人の現地インシデント指揮官、およびインシデント全体を通じて活動する 450 ～ 750 人のインシデント対応者からなる緊急オペレーション センターがあり、インシデントを完全に解決するには 4 交代が必要でした。
当社のコミュニケーション リーダーは、4 つの地域にわたる約 200 件のステータス更新を調整し、数百人のサポート エンジニアが 24 時間体制でお客様と継続的にコミュニケーションを図りました。
緩和と修復は次のように進められました。
- 私たちは、顧客が履歴データへのアクセスが制限されている場合でもプラットフォームを使用できるように、リアルタイム テレメトリ データの通常の取り込みと処理を復元することに最初の取り組みを集中しました。
- リアルタイム データが使用可能になると、障害の開始時に取り込まれたものの未処理のまま残されていた履歴データに復旧作業を切り替えました。
- 同時に、お客様に状況を常に知らせるために、ステータス ページで進捗状況に関する更新情報を頻繁に提供し始めました。
根本的な原因
停止の最初のトリガーを特定しました (その後無効にしました)。2023年 3 月 8 日の 06:00 UTC に、systemd へのセキュリティ アップデートが多数の VM に自動的に適用され、ネットワーク内で潜在的な有害な相互作用が引き起こされました。 systemd-networkd の再起動時にマニフェストするスタック (systemd v249 経由の Ubuntu 22.04)。つまり、コンテナ間の通信に使用するsystemd-networkdContainer Network Interface (CNI) プラグイン ( Cilium ) によって管理されているルートを強制的に削除します。これにより、影響を受けたノードがオフラインになりました。
systemd-networkd問題をさらに悪化させる要因は、通常のブート シーケンスでは常に CNI プラグインによってルーティング ルールがインストールされる前に開始されるため、新しいノードでも再起動したノードでもこの動作が見られないことです。言い換えれば、systemd-networkd実行中のノードでの更新シナリオ以外では、正確なシーケンスを再現する明白なテストはありません。
それはすぐにどのような影響を及ぼしましたか？これにより、06:00 から 07:00 の間にフリート内の数万のノードが影響を受けました。UTC 06:31 までに、当社のフリートの十分な数がオフラインになり、お客様にも障害が確認できました。
数十のアベイラビリティーゾーンにまたがり、3 つの異なるクラウドプロバイダーで実行される 5 つの異なるリージョンに更新プログラムが自動的に適用されるのはなぜですか? 新しいコード、セキュリティ パッチ、または構成の変更をプラットフォームにプッシュするときは、リージョンごと、クラスターごと、ノードごとにプッシュします。プロセス上、変更をそのまま適用することはありません。むしろ、ノードとコンテナをブルー/グリーン方式で置き換えます。変更が失敗すると、自動ロールバックがトリガーされます。この変更管理ツールは 1 日に何十回も大規模に実行されるため、私たちはこのツールに自信を持っています。
ただし、Kubernetes の実行に使用するベース OS イメージではレガシー セキュリティ アップデート チャネルが有効になっていたため、アップデートが自動的に適用されました。設計上、私たちはかなり最小限のベース OS イメージを使用するため、これらの更新は頻繁ではなく、その日までは混乱を招くことはありませんでした。
問題をさらに悪化させるのは、自動更新が行われる時刻が OS でデフォルトで UTC 06:00 から 07:00 の間に設定されていることです。したがって、リージョン間に直接のネットワーク接続や結合がないにもかかわらず、複数のリージョンに同時に影響を及ぼしました。これにより、影響の規模が著しく大きくなり、他の地域と同様に、地域間の行動が非常に間接的に結びついていることを知らなかった初期対応者を混乱させました。
またそうなるのでしょうか？いいえ。このレガシー セキュリティ アップデート チャネルは、影響を受けるすべてのリージョンで無効にされているため、この問題が再び発生することはありません。systemd-networkdまた、再起動時にルーティング テーブルが変更されないように、 の設定も変更しました。最後に、当社のインフラストラクチャを監査して、同様のレガシー アップデート チャネルが存在する可能性がないか確認しました。
このレガシー セキュリティ アップデート チャネルを無効にしても、当社のセキュリティ体制に悪影響はありません。これは、前述の変更管理ツールを介して処理される現在のセキュリティ アップデートの適用方法と重複するためです。
回復
コンピューティング能力の低下が大きかったため、回復の大まかな手順を順番に実行する必要がありました。
まず、各リージョンで十分なコンピューティング容量を回復し、通常の速度で受信データを処理するために必要な容量にスケールバックできるようにします。実際、各クラウド プロバイダーと協力して、リアルタイム データと履歴データの同時処理に対応するために、コンピューティング能力を通常よりも高いレベルに拡張しました。
コンピューティング容量の準備ができたら、すべてのサービスをできるだけ早く復元できるように、各サービスを並行して回復します。
コンピューティング能力
ネットワーク スタックの喪失による影響はクラウド プロバイダーによって感じ方が異なり、それが私たちの復旧作業を複雑にしました。
一部のクラウド プロバイダーの自動スケーリング ロジックは、影響を受けるノードが異常であることを正しく識別しますが、ノードの即時リタイアは開始しません。これは、影響を受けたインスタンスを単純に再起動することが正しい回復手順であり、データがそのまま残っているステートフル ワークロードの場合ははるかに高速であり、全体的な回復の高速化につながりました。
他のクラウド プロバイダーの自動スケーリング ロジックは、異常なノードをすぐに新しいノードに置き換えます。異常なノード上のデータは失われるため、回復する必要があり、当面のタスクがさらに複雑になります。一度に数万のノードが置き換えられるという規模で、さまざまな方法でクラウドプロバイダーの地域レート制限をテストする激しい群れも作成されましたが、どれも事前には明らかではありませんでした。
生のコンピューティング能力を自由に使えるようになったら、リカバリの順序に注意を払う必要がありました。すべての Kubernetes クラスタを健全に保つ役割を持つ各リージョンの内部コントロール プレーンは、システムに電力を供給する数百の Kubernetes クラスタよりも前にリカバリする必要がありました。プラットフォームは修理できるかもしれない。リージョン コントロール プレーンが完全に復元されると、さまざまなコンピューティング チームがファンアウトして、各クラスターがその上で実行されているサービスを他のチームが修復できるほど健全であることを確認できます。
サービスの回復
各サービスには異なる回復手順がありましたが、ここで紹介するのに十分な類似点がすべてありました。いずれの場合も、私たちの最優先事項はライブデータの処理を復元することでした。当社のサービスのほとんどは、ライブ データ (製品に応じて過去 15 分間または過去 24 時間を意味します) を取り込んで提供するために 1 つのシステムを使用し、履歴データを提供するために別のシステムを使用します。すべてのシステムが程度の差はありましたが、分離することで、復旧プロセスの早い段階で製品を機能状態に戻すことができました。
サービス復旧中にすべてのチームが直面したもう 1 つの共通のテーマは、分散型シェアナッシング データ ストアが、クォーラム ベースのコントロール プレーンを必要とするほとんどの分散型データ ストアよりも大規模な障害にはるかにうまく対処できるという事実でした。たとえば、静的シャードが割り当てられた独立したデータ ノードのフリートは、ノード数が減少するにつれてほぼ直線的に劣化します。クォーラムによって結合された同じデータ ノードのフリートは、クォーラムが満たされている限り機能を低下させることなく動作し、クォーラムを満たさない場合は動作を拒否します。もちろん、クォーラムベースのフリートは日常の管理がはるかに簡単であるため、どちらの方向に進むかは明白な決定ではありませんが、この障害は過去の選択を再検討する必要性を浮き彫りにしました。
一般的に、主要なテレメトリ データストア (ポイント値や生のログ データを保存するデータストアなど) は静的にシャーディングされますが、さまざまなメタデータ (タグのインデックス付けや解決を行うデータストアなど) は、動作するためにクォーラムを必要とするシステムに保存されます。したがって、復旧の多くは、これらのメタデータ ストアをライブ データへの新しい書き込みを受け入れることができる状態まで復元することに重点を置き、小規模なチームが、ライブ データのインデックスを作成して保存する独立した静的シャードを同時に修復することができました。
学んだ教訓
以下は、インシデント中に学んだすべての総計ではなく、プラットフォーム全体に関係する重要なテーマです。
これは私たちにとって初めての世界規模の事件でした。私たちは、自律性とローカル障害に対する回復力を備えた明確な設計目標を持って Datadog リージョンを構築しました。このため、相互に直接接続することなく、完全に独立したクラウド プロバイダー上の複数のゾーンにまたがって構築されます。これが、グローバルな共有コントロール プレーンがない理由でもあります。さらに、各サービスには、各リージョンでのフェイルオーバー、アベイラビリティ ゾーン間のアクティブ/アクティブ セットアップ、および復旧中のスパイクに対処するための追加容量が備わっています。それでも、私たちはそれらがどのようにして間接的な関係を維持できるのかを想像できませんでした。その失敗は、私たちがどのように基礎インフラストラクチャを強化し続けるかを知らせるでしょう。
お客様に代わって当社が処理するデータには明確な階層があるという話を何度も聞きました。最も重要な、使用可能なライブ データとアラートは、履歴データへのアクセスよりもはるかに価値があります。また、すべてのライブ データの中でも、アクティブに監視されているデータやダッシュボードに表示されているデータは、残りのライブ データよりも価値があります。縮退モードでの処理とアクセスの処理方法では、この明確な階層を考慮します。
私たちはカオス テストを実行しています (そしてクラウド プロバイダーからある程度のカオスに継続的にさらされています) が、テストで考慮する必要がある劣化の規模を考慮するのが不十分でした。今後は、私たちが確認したインフラストラクチャの中断のレベルを使用して、プラットフォームが完全にダウンすることなく、劣化した状態でも動作できることを証明していきます。前の点と組み合わせると、緊急データのみがアクセス可能になり、縮退モードで処理されるという形になる可能性があります。
履歴データにアクセスできない場合にライブ データを提供する別のシステム (APM の Live Search や Log Management の Live Tail など) を使用した場合でも、利用可能になったらすぐにシステムにアクセスする方法についての明確なガイダンスを顧客に提供していませんでした。より広範な事件がまだ解決中であるにもかかわらず。今後は、利用可能なサービスとデータ、およびそれらへのアクセス方法に関するガイダンスをお客様と共有することを優先していきます。
停止中のコミュニケーションは時間の経過とともに精度と深みが向上しましたが、微妙な製品ステータスを伝えるにはステータス ページが不十分であることを認識しました。プラットフォームを縮退モードで実行している場合でも、各製品の詳細なステータスをリアルタイムで通信する方法を考案します。
最後に
この機能停止は、Datadog の関係者全員にとって屈辱的な経験でした。私たちは、お客様にとって中断のないサービスがいかに重要であるかを理解しており、今回の停止中および停止後に学んだすべてのことに基づいて、サービスの回復力を検証的に向上させることに取り組んでいます。