Herokuは全顧客を単一のAWSリージョンで運用していた——そしてEBSが80時間にわたり故障した

2011年4月21日8時15分（UTC）、Herokuの各所で監視アラートが発報した。Web、キャッシュ、ルーティングの各サービスでタイムアウトが発生していた。引き金は上流にあった。AWS自身の説明によれば、太平洋夏時間午前0時47分、米国東部の単一アベイラビリティゾーンにおけるAWSのネットワーク変更により、プライマリEBSトラフィックが容量の小さいレプリケーションネットワークへと移され、EBSノードが孤立し、再ミラーリングの嵐が発生して、同ゾーンのボリュームの13%がスタックした。

EC2自体は約12時間で復旧したが、EBSは80時間以上にわたり劣化した状態が続いた。プラットフォーム全体を米国東部で運用し、データベースをEBS上に置いていたHerokuには、フェイルオーバー先がなかった。第2のリージョンは存在しなかった。ほとんどのアプリケーションは16時間以内に復旧したが、共有データベースサーバー上の無料アプリは最大3日を要した。

Herokuのポストモーテムは、ありがちな言い訳を退けた。「Herokuは、お客様に影響を与えたダウンタイムについて100%の責任を負います」。そこから導かれた3つの教訓は次のとおりである。単一リージョン内のアベイラビリティゾーンは、チームが想定していたようにはリスクを分割しない。ブロックストレージはクラウドに適した技術ではない。そして、インフラストラクチャを抽象化すると約束するプラットフォームは、そのインフラストラクチャが故障したときの結果に責任を負う。

ほとんどのアプリは16時間以内に復旧した。共有データベース上の無料アプリは最大3日間停止した。米国東部のEBSは80時間以上にわたり劣化した

プラットフォーム全体が単一のAWSリージョンに置かれており、そのアベイラビリティゾーンは、Herokuが分離されていると想定していた障害モードを共有していることが判明した。

ステートフルなサービスはEBS上にあり、EC2の復旧後も長く壊れたままだった。これはHerokuが回避することも、インシデントの最中に置き換えることもできない依存関係だった。

標準的な対処手順、すなわち不健全なインスタンスを停止し、交換し、AWSを待つという手順は、障害が1〜2時間で収まることを前提としていた。今回の障害は数日間に及んだ。

マルチリージョン化は、可用性への効果が小さい大規模プロジェクトとして何年も後回しにされていた。4月の障害は、その優先順位を一週末で見直させることになった。

単一のクラウドリージョン内のアベイラビリティゾーンは冗長性ではない。すべての顧客が同じリージョン、同じブロックストレージ上で運用されているなら、上流のネットワーク上の一つの誤りが全員の障害になる。

Herokuはマルチリージョン化をはるかに優先度の高い課題として扱い、EBSへの依存を減らすと述べ、プラットフォームがIaaSレベルの障害を生き延びられるようにするためのアーキテクチャ変更に着手した。AWSによるこの事象の総括は、業界で最も広く読まれた障害分析の一つとなり、「すべてを一つのリージョンに置くな」はクラウドの標準的な助言となった。それでもHerokuはその後何年も強い単一リージョン体制を維持し、同社が特定した集中リスクはその後のインシデントでも繰り返し表面化した。