logo

アマゾンのAWS障害--障害を長引かせた要因はインフラに潜んだバグ

Jack Clark (CNET News) 翻訳校正: 編集部2012年07月04日 13時12分
  • このエントリーをはてなブックマークに追加

 Amazonによると、米国時間6月29日の夜遅くからその週末にかけてAmazon Web Service(AWS)で発生した障害は落雷によって引き起こされたものの、同社のインフラに潜んでいたソフトウェアのバグのせいで回復までに時間がかかる結果となったという。

 Amazonの障害分析レポートで明かされたバグの内容から、クラウドプロバイダが運用するシステムの規模というものがソフトウェアシステムの障害時にどれほど重大な影響を与えるのかが分かる。そして、こういったバグはGoogleの「規模が大きくなると問題があらゆる箇所に及ぶ」という言葉の正しさを証明する実例ともなっている。

 Amazonによると、米国東部リージョンにおける同社のクラウド(4つのアベイラビリティゾーンにまたがる10カ所のデータセンターから成る)では最初、雷雨が原因と思われる外部電力の変動によって障害が引き起こされたという。


 この障害によって、Elastic Compute Cloud(EC2)といったAWSの主要なサービスが停止することになった。しかし、サービスの停止が長引いた原因は、同社のソフトウェアに潜んでいた複数のバグにあったという。例を挙げると、あるデータセンターではバックアップ電源への切り替えに失敗し、最終的に無停電電源装置(UPS)のバッテリを使い切った結果、同リージョンのハードウェアがシャットダウンすることになったという。

 Amazonによると、サービスのインスタンスが利用できなくなったことで「多くの顧客に重大な影響が及んだ」ものの、制御プレーン(顧客がリージョンの垣根を越えてリソースの生成や削除、変更を行えるようにするソフトウェア)の機能低下によってさらに事態が悪化したという。こういった柔軟性の喪失により、障害に対応しようとする顧客に足かせがはめられたというわけだ。

 そして、問題はこれだけで終わらなかった。Amazonのサーバ起動プロセスにボトルネックが発生したため、EC2やElastic Block Store(EBS)といった主要なAWSコンポーネントのオンライン復旧に想定以上の時間がかかった。これにより事態はさらに悪化した。EBSが復旧した時点でさまざまな技術的なチェックを実施し、保存されているデータに影響が及んでいないことを確認する必要があるものの、影響を受けたハードウェアの数があまりにも多かったためである。その結果、「バックログの解消に数時間を要する」ことになった。

 まとめると、こういった問題が重なり合ったため、非常用電源を稼働させるだけで終わっていた本来の場合に比べると、復旧プロセスが長引いたことになる。

この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。

-PR-企画特集