重大なシステム障害から得るべき教訓【前編】
IT史に名を残すシステム障害8選
サイバー攻撃やハードウェアの故障、自然災害、ヒューマンエラーなど、さまざまな要因でシステム障害が発生してきた。歴史に残る重大なシステム障害の例を8つ紹介する。
ITは現代社会になくてはならない存在であり、われわれの生活を支える無数のシステムやサービスを構成している。そうした状態でのシステムやサービスの停止は、日常生活だけではなく企業の経済活動にも甚大な影響を引き起こす。近年はクラウドサービスへの依存が進む中で、影響はより広範に及ぶ傾向にある。どのようなシステム障害が発生し、どのような影響を与えてきたのか。
近年の重大なシステム障害8選
ITの歴史を振り返ると、枚挙にいとまがないほどのシステム障害が発生してきた。以下に挙げるのは、2015年以降に主要なシステム障害が発生した組織と、その発生時期だ。
1.Dyn(2016年)
2016年10月21日(米国東部標準時)、DNS(ドメインネームシステム)サービスを提供するDynのサービスが停止した。これは、史上最大級のDDoS(分散型サービス拒否)攻撃によるものだった。攻撃発覚後、DynはOracleに買収されることになる。
攻撃は、マルウェア「Mirai」に感染したインターネット接続機器がbotネットを形成し、Dynのサーバに対して繰り返しアクセスしてサービスを停止させた。botネットとは、マルウェアに感染したコンピュータが形成するネットワークだ。Dynのサービス停止によって、「CNN」や「Twitter」(現「X」)、「Netflix」「Reddit」といった、DynのDNSサービスを利用していた複数の大手Webサイトが影響を受けた。
2.Amazon Web Services(2017年)
2017年2月29日(太平洋標準時)、オブジェクトストレージサービス「Amazon Simple Storage Service」(Amazon S3)に障害が発生した。原因は、Amazon Web Services(AWS)のエンジニアが一部のサーバインスタンスを停止するコマンドを実行しようとした際、入力ミスを犯したことによる。その結果、想定よりも多くのサーバインスタンスを停止させたことで、Amazon S3のサブシステムに影響が生じ、サービスがダウンした。
停止されたサーバインスタンスは、米国バージニア北部リージョンにある2つの重要なサブシステムを運用するものであり、システムの完全な再起動が必要になった。サーバ再起動中は、Amazon S3をストレージとして利用するAWSのサービスもダウンした。ダウンした例としては、「Amazon Elastic Compute Cloud」(Amazon EC2)や「Amazon Elastic Block Store」(Amazon EBS)がある。
Amazon S3のサブシステムは、障害発生時にユーザー組織への影響を最小化するように設計されていた。ところがAWSの説明によると、米国バージニア北部リージョンのサブシステムは、「長年にわたって」完全な再起動を経験していなかった。そのため再起動には「想定よりも長い時間」を要したという。この障害は約4時間に及び、AWSのサービスを利用していた企業が被った損害の合計は数百万ドルに上るとの報道がある。
3.Verizon Communications(2019年)
通信大手Verizon Communicationsは、2019年6月24日の午前6時30分ごろ(米国東部標準時間)にシステム障害を引き起こした。この障害は、ネットワークのトラフィックの経路を誘導するルーティングプロトコル「BGP」(Border Gateway Protocol)の設定および運用ミスによって発生したものだ。
障害は、米国ペンシルベニア州にある小規模ISP(インターネットサービスプロバイダー)DQE Communicationsに起因する。DQE Communicationsはネットワーク管理ツールベンダーNoctionのBGP最適化ツールを使用していた。その最適化ツールが作成したルーティング情報が、DQE Communicationsの顧客であるAllegheny Technologiesに送信され、さらにVerizon Communicationsに送信された。そしてVerizon Communicationsはこの情報を誤ってインターネットに公開してしまったのだ。
本来ならこの情報公開はフィルタリングによって防がれるべき挙動だ。だがVerizon Communicationsはフィルタリングを実施していなかった。その結果、世界各地のトラフィックが本来の経路ではなくDQE CommunicationsとAllegheny Technologiesを経由するようになり、両社のシステムは大量のトラフィックを処理し切れなくなった。これによってCloudflareやAmazon.comなどの企業でサービス障害が発生した。
4.Google(2020年)
2020年12月14日(太平洋標準時)にGoogleが引き起こしたのは、「Gmail」「Google Drive」などの「Googleアカウント」によるログインが必要なサービスでの障害だ。ダウンタイム(システムの停止期間)は約45分間だったものの、広範囲にわたって影響を及ぼした。
このシステム障害の原因は、ストレージを含むシステムリソースの割り当てを管理するクオータ(割り当て上限)システムの切り替えミスだ。 Googleは2020年10月、ユーザー認証サービスのクオータシステムを新システムに切り替えた。だが切り替えの際に古いクオータシステムの一部が残ってしまい、その結果クオータシステムが誤ったストレージ使用量を報告した
障害に備えて、Googleは複数のフェイルセーフ(故障や誤作動があった場合の安全性を確保する仕組み)を用意していた。だが、今回発生した「単一サービスのストレージ使用量が0になるという報告」の障害を想定したものはなかった。新しい認証データを書き込むことができず、システムが保持している認証情報が最新ではない状態になった結果、認証情報を検索する際にエラーが発生し、エンドユーザーのログイン時に認証エラーが生じるようになった。
5.Fastly(2021年)
Fastlyは、BBCやShopify、Amazon.com、CNN、米国政府、英国政府といった組織を支えるCDN(コンテンツ配信ネットワーク)プロバイダーだ。2021年6月8日(協定世界時)、Fastlyのサービスがダウンし、同社の顧客に影響を与えた。
2021年5月にFastlyが公開したソフトウェアアップデートにはバグが存在した。そのバグは特定の状況下で有効になるもので、存在が明らかになるまでに1カ月近くを要した。同年6月8日午前9時47分頃(協定世界時)、同社のある顧客がサービス設定を変更したことがバグのトリガーになった。影響は大きく、「自社ネットワークの85%で障害が発生した」とFastlyは報告する。
救いとなったのは、復旧が迅速だったことだ。Fastlyは事件について報告したブログエントリ(投稿)で、「障害発生から49分以内にネットワークの95%が復旧し、数時間後には修正プログラムを配布できた」と説明する。とはいえ障害発生中、ニュースメディアがニュースを掲載できなかったり、EC(電子商取引)サイトが商品を販売できなかったりといった問題が発生し、影響は広範囲に及んだ。
6.Facebook(2021年)
2021年10月4日(協定世界時)、Facebook社(現Meta Platforms)は、同社が運営する「Facebook」や「Instagram」「WhatsApp」といったWebサービスの定期メンテナンスを実施していた。メンテナンス担当者がネットワーク容量を評価するコマンドを実行したところ、同社の全データセンターの接続を全て切断してしまった。Meta Platformsによると、この問題は監査システムによって防がれるべきだったが、監査ツールにバグがあり、コマンドがそのまま実行された。その結果、同社サービスがダウンしたという。
7.Rogers Communications(2022年)
2019年のVerizon Communicationsのシステム障害と同じように、カナダの通信大手Rogers Communicationsも、ルーティングに関する問題で大規模なシステム障害を経験した。カナダの放送・通信を規制する公的機関Canadian Radio-television and Telecommunications Commissionの報告によると、このシステム障害でカナダ全土の1200万人以上が影響を受けた。
原因はヒューマンエラーだ。インターネットトラフィックを誘導するディストリビューションルーターを設定する際、フィルターとして機能するアクセス制御リストを担当者が誤って削除した。その結果、大量のルーティングデータがRogers Communicationsのコアネットワークのルーターに流入し、処理能力を超えてシステムがクラッシュした。この事態によって、同社が提供する携帯電話回線、インターネット、緊急通信サービスが約1日間利用不可能になった。
8.CrowdStrike(2024年)
セキュリティベンダーCrowdStrikeによるシステム障害は、2024年7月19日(米国東部標準時間)に発生した。CrowdStrikeは、同社のエンドポイントセキュリティツール「CrowdStrike Falcon」のセンサー(エージェントソフトウェア)の更新プログラムを公開した。この更新には不具合のある設定ファイルが含まれており、世界中の「Windows」搭載デバイスでクラッシュを引き起こした。CrowdStrikeは問題を発見してから約1時間後に更新プログラムの公開を取りやめたが、その間に更新プログラムが適用されたデバイスは手遅れだった。Windowsの提供元であるMicrosoftの推定によると、旅行や金融、医療などの業界で約850万台のWindows搭載デバイスが影響を受けた。
「CrowdStrike Falconのセンサーが99%復旧した」とCrowdStrikeが宣言したのは、障害発生から10日後の2024年7月29日(米国東部標準時間)だった。この障害の長期的な影響は、American AirlinesやUnited Airlines、Delta Air Linesなどの企業が障害発生から数日後も完全に復旧できていなかったことから読み取れる。
次回は、システム障害の主な原因と、障害に備える方法を紹介する。
TechTarget発 世界のインサイト&ベストプラクティス
米国TechTargetの豊富な記事の中から、さまざまな業種や職種に関する動向やビジネスノウハウなどを厳選してお届けします。
Copyright © ITmedia, Inc. All Rights Reserved.
TechTarget発 世界のインサイト&ベストプラクティス
米国TechTargetの豊富な記事の中から、さまざまな業種や職種に関する動向やビジネスノウハウなどを厳選してお届けします。
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー