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.