起きた事象
AWSの
- 「Amazon Elastic Compute Cloud」（EC2）
- 「Amazon Relational Database Service」（RDS）
がAZ ID:apne1-az4のアベイラビリティゾーンで使えない状況になった。
時間
12:36頃に当事象が発生。
18:30頃に、大半のインスタンスの復旧が完了(AWS公式より)
私が受けた障害としては、22時頃にようやく全てのRDSが復旧した。
実質9時間ほどの大障害だった。
アベイラビリティゾーンとは
東京リージョンには3つのアベイラビリティゾーン（ざっくり言うと、データセンター）がある。
それぞれのアベイラビリティゾーンは、リージョンコードとそれに続く文字識別子を用いて下記のように表される。
- ap-northeast-1a
- ap-northeast-1c
- ap-northeast-1d
ただ、AWSアカウントによってap-northeast-1aがどのアベイラビリティゾーンを指すかは決められていなく、同じap-northeast-1aでも、AWSアカウントによって物理的に違うアベイラビリティゾーンを指している可能性もある。
AWSアカウントに寄らないアベイラビリティゾーン固有の識別子としてAZ IDが存在し、
- apne1-az1
- apne1-az2
- apne1-az4
で表される。
アベイラビリティーゾーンは、リージョンコードとそれに続く文字識別子によって表されます (us-east-1a など)。リソースがリージョンの複数のアベイラビリティーゾーンに分散するように、アベイラビリティーゾーンは各 AWS アカウントの名前に個別にマップされます。たとえば、ご使用の AWS アカウントのアベイラビリティーゾーン us-east-1a は別の AWS アカウントのアベイラビリティーゾーン us-east-1a と同じ場所にはない可能性があります。
アカウント間でアベイラビリティーゾーンを調整するには、アベイラビリティーゾーンの一意で一貫性のある識別子である AZ ID を使用する必要があります。たとえば、use1-az1 は、us-east-1 リージョンの AZ ID で、すべての AWS アカウントで同じ場所になります。
影響範囲
今回はAZ ID:apne1-az4内のアベイラビリティゾーンで障害が起き、apne1-az4内のEC2やRDSがほぼ使用不能になった。
世の中での影響範囲
国内の多くのWebサービスやゲームで障害になり、アクセス不能状態になった。
一例）
https://piyolog.hatenadiary.jp/entry/2019/08/23/174801
https://gamebiz.jp/?p=246869
障害中は該当インスタンスがアクセス不能なだけでなく、
- AWSコンソールが度々エラー画面になる
- エンタープライズプランでもサポートデスクに繋がらない
- フェイルオーバーや再起動等のインスタンス更新処理をかけても表示が、更新されない
などのケースが起きた。
3つ目に関しては、2時間後にようやく更新が反映されるなど大きな遅延があった。
AWS障害はなぜ起きたか
データセンターにおいて
冷却システムが故障によりサーバーがオーバーヒートし、
インスタンス不良が起きたり、サーバーへの電源供給が滞った
ためである。
時系列で起きたこと(AWS公式より)
12:36(日本時間)
制御システムの不調により冷却システムが故障し、EC2の一部のインスタンスがオーバーヒートしてシャットダウンした。
これにより、該当アベイラビリティゾーン内のEC2およびEBSのインスタンス不良が引き起こされた。
15:21
冷却システムが復旧し、該当エリアの温度が正常温度に戻り始めた。
温度が戻ったことにより、影響を受けたインスタンスへの電源供給が復帰した。
18:30
大半のインスタンスが復旧した。
復旧していない一部の少数のインスタンスは、引き続き電源供給がされていないデバイス上で稼働してたため、可能であれば他のインスタンスで置き換える必要があった。
AWSユーザー側でこの作業をする必要があるため、AWSから各顧客にこれから連絡していく。
Beginning at 8:36 PM PDT a small percentage of EC2 servers in a single Availability Zone in the AP-NORTHEAST-1 Region shutdown due to overheating. This resulted in impaired EC2 instances and degraded EBS volume performance for resources in the affected area of the Availability Zone. The overheating was caused by a control system failure that caused multiple, redundant cooling systems to fail in parts of the affected Availability Zone. The chillers were restored at 11:21 PM PDT and temperatures in the affected areas began to return to normal. As temperatures returned to normal, power was restored to the affected instances. By 2:30 AM PDT, the vast majority of instances and volumes had recovered. We have been working to recover the remaining instances and volumes. A small number of remaining instances and volumes are hosted on hardware which was adversely affected by the loss of power. We continue to work to recover all affected instances and volumes. For immediate recovery, we recommend replacing any remaining affected instances or volumes if possible. Some of the affected instances may require action from customers and we will be reaching out to those customers with next steps.
AWS公式より
https://status.aws.amazon.com/#AP_block
復旧したサービスはどのように復旧したのか
今回の障害において、影響を受けたインスタンスの分類によって対応が別れる。
AZ ID:apne1-az4内に本番サービスで使っているインスタンスがあった場合、大きく2つに分けられる
- 状態を持たず、新規作成して置き換えて問題ないもの
- 状態を持ち、正しく復元する必要があるもの
さらに細分化すると5つに分けられ、
- 1-3しか存在しない場合は比較的すぐに復旧出来る
- 4の場合、作業はあるが、AWSユーザー側で復旧作業が可能
- 5の場合、基本的にAWS側の復旧を待つしかない
となる。
状態を持たず、新規作成して置き換えて問題ないもの
1.状態をほぼ持たないもの(影響:小)
APIサーバーや一時キャッシュのみを持つElastiCacheなど。
別のアベイラビリティゾーンに新たに生成して置き換えれば良い。
すぐ置き換えが可能。
2.状態を持つが復元可能なもの(影響度:小)
マスタデータを保持するRDSなど。
サービス運営上必要な情報を保持しているが、gitレポジトリでcsvなどで保存されており、容易に復元が可能なもの。
別のアベイラビリティゾーンに新たに生成してデータを投入して置き換えれば良い。
すぐ置き換えが可能。
状態を持ち、正しく復元する必要があるもの
ユーザーデータを格納するRDSがこれに当たる。
容量が膨大であり、手動での復元が困難である。
すでに作成してあったslaveから復元するか、障害が発生しているインスタンスからslaveを新たに生成するしかない。
3. RDSがMulti-AZ DB インスタンスだった場合(影響度:小)
Multi-AZ配置でRDSを生成すると、異なるアベイラビリティーゾーンにあるスタンバイインスタンスが生成され、インフラの障害時には自動でフェイルオーバーが行われ、異なるアベイラビリティーゾーンにあるスタンバイインスタンスがWriterに昇格する。
フェイルオーバー後のエンドポイントも変わらないため、ほぼダウンタイムなしで復旧する。
サービス上必要なRDSが全てマルチAZ配置されていたサービスにおいては、apne1-az4にメインのRDSがあった場合でもほぼ障害なしで今回のAWS障害を乗り切れている。
インフラストラクチャ障害の場合、Amazon RDS はスタンバイ (Amazon Aurora の場合はリードレプリカ) に自動的にフェイルオーバーするので、フェイルオーバーが完了するとすぐにデータベースの動作を再開できます。フェイルオーバー後も DB インスタンスのエンドポイントは変わらないため、お客様のアプリケーションは、手動で管理の介入を行うことなくデータベースオペレーションを再開できます。
参考:AWS公式Amazon RDS マルチ AZ 配置
4.RDSに異なるアベイラビリティゾーンのリードレプリカがあった場合(影響度:中)
メインのRDSに対して、リードレプリカ（読み取り専用のメインのRDSのコピー）を異なるアベイラビリティゾーンに作成済みであった場合、リードレプリカをメインのRDSから切り離し、書き込み権限を与えてメインのRDSに昇格させることが可能である。
Multi-AZ DB インスタンスの場合と違い、メインのRDSとリードレプリカそれぞれにエンドポイントが割り振られているため、レプリカのエンドポイントを変えるか、アプリケーションからの書き込み参照先をリードレプリカのエンドポイントに変更する必要がある。
レプリカの昇格作業とエンドポイントの変更対応が発生するため、障害対応時間は少々かかる。
リードレプリカは更新より参照の多いサービスにおいて負荷分散のために導入されることが多いが、異なるアベイラビリティゾーンに生成しておけば、いざという時のバックアップにもなる。
ただし、RDSがMulti-AZ DB インスタンスの方がダウンタイムも作業もほぼないので、特に理由がなければRDSがMulti-AZ DB インスタンスの方がおすすめ。
ソース DB インスタンスのレプリカを複数作成し、アプリケーションの大容量読み取りトラフィックをデータの複数のコピーから提供することにより、全体の読み込みスループットを向上させることができます。必要な場合、リードレプリカをスタンドアロンの DB インスタンスに昇格させることも可能です。
参考:AWS公式Amazon RDS リードレプリカ
5. RDSのスタンバイインスタンスがない、または同じアベイラビリティゾーンに存在する(影響度:極大)
RDSにスタンバイインスタンスが存在しない場合、基本的にAWS側の障害復旧を待つしか出来ない。
RDSのバックアップを取得して異なるアベイラビリティゾーンにRDSインスタンスを生成しようにも、データセンターレベルの障害なので取得に膨大な時間がかかるか、失敗する可能性が高い。
スタンバイインスタンスが存在したとしても、同じアベイラビリティゾーンに存在する場合はメインのRDS同様に障害の影響を受けており、昇格作業等はほぼ出来ない。
復旧が早かった方を4の要領で使うことも出来るが、対して時間は変わらない。
リードレプリカのレイテンシを気にして、メインのRDSと同じアベイラビリティゾーンに配置する場合もあるかもしれないが、基本的に異なるアベイラビリティゾーンに置いておくことが望ましい。
AWSを使っているwebサービスにおいて、どうすれば障害を防げたか
全てのRDSインスタンスをマルチAZ配置で冗長化しておくこと。
具体的にはAPIサーバーやDBをap-northeast-1aに置く場合、待機系をap-northeast-1cにおき、ap-northeast-1aに障害があった時はap-northeast-1cにフェイルオーバーするようにしておく。
ap-northeast-1aにしかないインスタンスが存在した場合、ap-northeast-1aが障害になった場合サービスが止まる。
データセンターレベルの障害はおきうるので、原則マルチAZ配置にしておくのが望ましい。
もちろん待機系の分のサーバー費用がかかる。同スペックで待機系を用意するのでれば、サーバー費用が2倍になる。
それでも、事業への影響が大きいサービス運営の障害点であれば、きちんと冗長化しておいたほうが良い。