インターネットレポート

構成変更のトラブルと 2024 年のその他の障害の傾向

投稿者 Mike Hicks
| | 4 分
Internet Report on Apple Podcasts Internet Report on Spotify Internet Report on SoundCloud

こちらの投稿は次の言語でもご覧いただけます: United States (English).

概要

SEO - 153 char max: 2024 年に発生した多くの障害は、構成変更に起因するものでした。このような最近の障害の傾向と、ITOps チームが 2025 年にどう対策すべきかについて詳しく説明します。


このインターネットレポートは、当社が ThousandEyes のインターネット&クラウドインテリジェンスを活用してインターネット全体の障害とその傾向を分析した結果をまとめたものです。ここでは隔週で最新の障害発生件数といくつかの興味深い障害に関する情報を公開しています。いつものように、以下の完全な分析結果をお読みいただくことも、ポッドキャストで直接解説をお聞きいただくことも可能です。


インターネットの障害と傾向

2024 年に、ThousandEyes が毎日収集する 6,500 億を超えるデータポイントから得られたインサイトを分析した結果、2 つの主要な傾向が明らかになりました。1 つは、クラウド インフラストラクチャに起因する障害の数と割合が年間を通して増加したこと。そしてもう 1 つは、年間を通じて設定ミスに起因する障害がかなり多く発生したことです。今週のエピソードの前半では、この 2 つの傾向についてもう少し詳しく分析していきます。

後半では、OpenAI と Google Cloud Pub/Sub で発生した最近のインシデントや、昨年末に Netflix に影響を及ぼしたインシデントについても詳しく検証します。

詳細については以下のレポートをお読みください。または以下のリンクを使用して、関心のあるセクションにジャンプしてください。


増加を続けるクラウド サービス プロバイダーの障害

昨年 12 月のエピソードでは、2024 年初頭にクラウド サービス プロバイダー(CSP)とインターネット サービス プロバイダー(ISP)に起因する障害の比率に変化が見え始め、年間を通してその傾向が進行したことをお伝えしました。2024 年の最終的な数字では、2024 年の ISP の障害と CSP の障害の比率は 73:27 でした。2023 年のこの比率は 83:17、2022 年は 89:11 でした。

この比率の変化は、障害の状況の変化を示唆しているかもしれません。CSP の障害の総数の割合は大幅に増加し、この 1 年で 17% から 27% に上昇しました。対照的に、ISP の障害の割合は減少しています。ISP の障害と CSP の障害全体を見ると、ISP の障害は障害全体の 73% と、昨年同期の 83% から減少しました。

障害の大半は依然として ISP が占めていますが、CSP の障害件数の増加は、インターネットの安定性と信頼性に関する傾向の重大な変化を表しているため、看過することはできません。

2024 年の ISP 障害に対する CSP 障害の比率の増加を示す棒グラフ
図 1. 2024 年の ISP 障害対 CSP 障害の比率

クラウドとアプリの偶発的な設定ミスが増加傾向に

ルーティングポリシーの偶発的な設定ミスは、長期にわたってネットワークインシデントの原因の 1 つになっています。

この 1 年は、クラウドでも構成関連のエラーが問題になりました。特に注目を集めたのは、1 月7 月の Azure の 2 つのインシデントと 10 月の Salesforce のインシデントです。設定ミスはアプリケーション内でも問題にもなりました。CrowdStrike センサーの更新インシデントは、単一の構成ファイル内の問題が原因でした。さらに、一連の ChatGPT の問題はユーザー体験の改善に関連していると考えられており、Square のケースでは、展開された構成が Android デバイスに解釈されませんでした。

クラウドサービスやアプリケーションに影響を及ぼす多くの構成の問題の根本原因は、現代のソフトウェア エンジニアリング プラクティスかもしれません。

こうしたプラクティスの 1 つ目は、普及を広げている継続的改善と継続的デリバリ(CI/CD)です。CI/CD は現代のソフトウェア エンジニアリングで不可欠な要素になりました。CI/CD は、アプリケーションへのより頻繁で段階的な変更を促進するため、製品チームとエンジニアリングチームはより迅速なペースで更新と機能強化を展開できるようになります。

このアプローチのおかげで、組織はユーザーのフィードバックや市場のニーズに速やかに対応できます。しかし私は、こうした更新を迅速に行うと、包括的なエンドツーエンドのテストが制限されやすいというデメリットがあると考えています。チームが新しい機能を迅速に展開しようとする場合は、アプリケーション全体の変更を検証する時間が十分に確保できないことが多いため、予期しない問題が発生することがあります。さらに、絶えず変化するというコードベースの性質によって予測が難しくなり、アプリケーションの動作が展開のたびに予期せず変化することも起こりえます。この安定性の欠如により、チームは新しい機能を実装しながら機能の維持にも努める必要があるため、毎日難しいタスクに直面するかもしれません。

構成関連のプラクティスの 2 つ目は、サービスの迅速な運用開始とアプリケーションの分散アーキテクチャです。デジタルアプリケーションは多数のコンポーネントで構成されており、各コンポーネントが連携して動作し一貫性のあるユーザー体験を実現する必要があります。通常は、さまざまなアジャイルチームがこれらのコンポーネントを開発し、社内開発とサードパーティの混在インフラストラクチャ上でコンポーネントが実行されます。このような共同作業型の環境では、各チームは特定のモジュールの強化に力を注いでおり、実施した変更がより広範なシステムに及ぼす影響を十分に理解していないことも珍しくありません。このように可視性が限られた環境では、他には影響がないと思って実施した変更が、相互接続されたコンポーネントの機能を思いがけず停止させ、ひいては障害に発展する可能性があります。このような障害は、チーム間の意思疎通と監視を改善していれば防止できたものです。

AI(および特に AIOps)は、設定ミスによるエラーを検出する上で重要な役割を果たします。特にネットワークではその役割は重要です。ネットワークは、少なくともクラウドサービスやアプリケーションに影響を与える領域と比較すると、設定ミスによるエラーはそれほど多くはありません。また AI は、特定のクラウドサービス、開発のサイロ、またはアプリケーション コンポーネント内の個々のエラーを検出して修正するのにも役立ちます。

ただし一般的には、標準的なデジタル体験を提供するためのサービスデリバリチェーンでも、かなり複雑化して多くの変動要素が含まれています。さまざまな機能やコンポーネントに対する変更により、規模の拡大、分散化の進行、依存関係の増大と相まって、チェーンの一部に加えた変更の影響がますます大きくなります。こうした変更は、サービスデリバリシステム全体に予測できない影響を及ぼす可能性があることから、設定ミスに起因する障害は今後も発生し続けると考えられます。

構成の変更や修正は実装の自動化が進んでおり、個々の変更が幾多の結果につながる可能性があります。テストを実施することは可能ですが、考えうるすべてのシナリオを完全にテストするのは現実的ではありません。その代わりにサービス全体を監視すれば、中断やユーザーへの影響を緩和する最善の機会を得ることができます。このアプローチなら、障害や機能が低下したコンポーネントに関する貴重なインサイトも得られるため、変更のロールバック、代替リソースへのリダイレクト、緊急時対応計画の実装といった適切な手段を講じられます。


2024 年に大きな注目を浴びた障害から得られた障害の傾向と教訓の詳細については、「2024 年の主要な障害」ウェビナーにご参加ください。

OpenAI の障害

12 月 26 日、OpenAI の ChatGPT、Sora、API サービスは、活用しているクラウドプロバイダーの 1 つが運営するデータセンターの停電が原因で問題が発生しました。その影響は、これらのサービスへのアクセスを試みるユーザーに「内部サーバーエラー」として現れました。ただしユーザーへの影響はホリデーシーズンだったことで幾分緩和されたようです。それでも、インシデントの継続時間(太平洋標準時間のユーザーの場合は日中、ChatGPT は 8 時間弱)は、運用チームと OpenAI にとって大きな不安材料になったはずです。OpenAI はこのインシデントを受けて「大規模なインフラストラクチャ イニシアチブ」の実施を約束しています。

OpenAI にとっての重要な焦点は、単一のインフラストラクチャ クラスタやホスティングプロバイダーの問題が、そのリージョン外の重要なバックエンドサービス(データベースアクセスなど)に「長時間」、広範囲に問題を引き起こさないようにすることです。インシデント後のレポートで、OpenAI は、データベースは「グローバルに複製されているが、現時点ではリージョン全体のフェールオーバーにはホスティング クラウド プロバイダーの手動による介入が必要」と発表しました。手動フェールオーバープロセスは開始されたものの、OpenAI は「規模が大きかったため緩和に時間を要した」として、このプロセスが実際にはうまく機能しなかったことを示唆しました。

OpenAI は、数週間のうちにフェールオーバーのプロセスと機能の改善に着手すると発表しました。

Google Cloud Pub/Sub の中断

1 月 8 日、Google Cloud で設定ミスに関連するインシデントが発生し、Pub/Sub、Cloud Logging、BigQuery Data Transfer Service の複数のリージョンが約 75 分にわたって影響を受けました。Pub/Sub はメッセージングミドルウェアで、ストリーミング分析、データ統合パイプライン、(マイクロ)サービス統合などのタスクに使用されています。

Google のエンジニアは、このインシデントの根本原因がリージョンのデータベースへの「不適切なサービス構成の変更」であることを突き止めました。このデータベースには「発行されたメッセージに関する情報と、各メッセージが公開された順序(順序通りの配信を保証するため)」が保存されています。この構成変更によって「このデータベースへのアクセス許可が意図せずに過剰に制限」されました。またこの構成変更は「複数のリージョンに展開された」ため、内部の運用開始プロセスとの競合が発生しました。Google は「2 つの環境間の構成の不一致が原因」で、本番前環境ではこの問題が検出できなかったと補足しました。

この構成変更はロールバックされましたが、Pub/Sub 自体の「潜在的なバグ」によって障害の期間は長びき、エンジニアによる追加の修復が必要になりました。

Netflix のインシデントから得られた教訓

観察眼に優れた読者やボクシングファンなら、昨年 11 月に開催された Jake Paul 対 Mike Tyson および Katie Taylor 対 Amanda Serrano のボクシングマッチの記録的なストリーミングで発生した問題を思い起こしていると思います。ライブストリーミングの多くのユーザーから、バッファリング、フリーズ、パフォーマンスの遅延が報告されました。

このインシデントを初めてブログに書いてから、さらに調査を進めてきましたので、ITOps チームにとって重要な補足情報をいくつか共有します(完全な分析はこちらからご覧ください)。主な結果は次の通りです。

  • 地域によって中断の時間帯にばらつきがありました。米国の ISP では、メインイベントの開始時にエラー率の増加が確認されましたが、オーストラリアの ISP では、エラーは広域には及ばなかったものの、放送時間全体を通じて問題が発生しました。

  • 単一のプロバイダーまたはネットワークパスに重大な問題は見られませんでした。

  • この問題は、Netflix のコンテンツ デリバリ ネットワークである Open Connect のアプライアンスに輻輳があったことを示唆しています。

このインシデントは、大規模イベント(注目されているスポーツイベント、ブラックフライデーのような大型セールなど)中の完璧なデジタル体験の保証を目指している ITOps チームにとって、貴重な教訓となります。まず重要なのは、アプリケーションのサービスデリバリチェーン全体を理解することです。そうすれば監視すべき最も関連性の高いシグナルとポイントを見極めることができ、問題と最適化できる可能性のある領域を素早く特定できます。また、通常の日常サービスの要件に加えて、準備している特別なイベントやシーズンの要件について綿密な計画を立てることも大切です。このことを理解していれば、チームは情報に基づいて実装すべきプロセスを決定し、こうした重要な瞬間にユーザーに質の高い体験を提供できるようになります。


数字で見る傾向

これまで 2024 年の障害の傾向について説明してきましたが、最後はいつものように ThousandEyes がこの数週間(2024 年 12 月 16 日~ 2025 年 1 月 12 日)で ISP、クラウド サービス プロバイダー ネットワーク、コラボレーション アプリケーション ネットワーク、およびエッジネットワーク全体で観察した世界的な傾向の詳しい分析で締めくくります。

  • この 4 週間の世界的な障害総数は、当初は減少傾向にありましたが、その後再び増加に転じました。1 週目、ThousandEyes は 205 件から 197 件への障害件数の 4% 減を観測しました。この減少傾向は翌週(12 月 23 日~ 29 日)まで続き、障害件数は 197 件から 76 件に大幅に減少し、対前週比で 61% 減となりました。

  • しかし、この下降傾向は 3 週目で終了し、障害件数は 76 件から 148 件と再び増加を見せ、対前週比で 95% 増となりました。翌週(1 月 6 日~ 12 日)には障害件数は 148 件から 296 件に再び倍増しました。

  • このパターンは、米国で観測された障害件数に完全には反映されませんでした。1 週目(12 月 16 日~ 22 日)の障害件数は 2% 増という微増にとどまりました。しかし翌週には大幅な逆転が見られ、障害件数は 111 件から 28 件に劇的に減少、対前週比で 74% 減となりました。次の 2 週間は増加傾向に戻り、まず 12 月 30 日~ 1 月 5 日の週には 28 件から 78 件まで 179% の急増を記録しました。翌週障害件数は再び 78 件から 117 件に増加し、50% 増となりました。

  • 12 月 16 日~ 29 日までの期間に米国で発生した障害は、平均ですべてのネットワーク障害の 51% でした。この値は前週の 12 月 2 日~ 15 日までの期間に報告された 58% から減少しました。年をまたいだ 12 月 30 日~ 1 月 12 日の期間に発生した全障害のうち、米国での障害は 44% を占めました。平均すると、2024 年を通して米国の障害は全世界の障害全体の 42% を占め、2023 年に観測された 38% から増加しました。

  • 12 月に全世界で確認された障害は合計 724 件で、11 月に記録された 840 件から 14% 減でした。米国の 12 月の障害件数も、11 月の 501 件から 408 件に減少しました。この傾向は前年と同じです。世界でも米国でも、11 月から 12 月はホリデーシーズンにあたるため、障害総数は減少するのが一般的です。

直近 8 週間の世界と米国のネットワーク障害の傾向を示す棒グラフ
図 2. 直近 8 週間の世界と米国のネットワーク障害の傾向

Upgrade your browser to view our website properly.

Please download the latest version of Chrome, Firefox or Microsoft Edge.

More detail