おはようございます、hisayukiです。
盛大なお祭りもだいぶ収束に向かってきました。
ソシャゲ大好きな人達のTwitterでの反応すごかったですね〜(；´∀｀)
さて、それでは昨日のAWS障害のお祭りについて書いていきたいと思います。
障害発生
まとめになってるので詳しくは省きますが、日本では珍しく数時間に渡る大規模障害が発生。
日本時間で12時過ぎくらいから、数々のサイトやゲームなどで通信エラーが多発。
そこからAWSが正式にIssueとしてユーザーに通知しました。
というわけで、こちらがまとめサイトでーす
原因
どうやら冷房管理システムの障害から、機器の物理障害に発展したっぽいですね。
これはなかなか治らないのはしかたないかなと。
MultiAZなら大丈夫だったか
障害期間中に特に言われてたのがこれです。
AWSは単一AZでの障害ということだったので、MultiAZ組んでおけば大丈夫だったはず。
ただ、なんかそういうわけでもなさそうですね。
このELBの問題は原因が不明確なのとAWSも見解を公表していないのでなんとも言えないですね。
それにこのELBの件、ブログを書いてる人の感覚だと復旧作業後半から出てきた問題みたいなので、直接紐付いてる障害なのかも見えてこないですね・・・
ちなみに同じ1aや1cでも人によって指してるDCが違うみたいなので、誰かが大丈夫と行っても他の人が大丈夫とは限りません。
まぁでもMultiRegionならよっぽど大丈夫だったと思います。
追記：2019/08/26
現在、AWSからの公式な見解はでてないですが、DevelopersIOさんが自社で起きたことと対応を書いてくださいました。
責任共有モデル
Twitterの#aws障害のTweetがあまりにも酷いのでおさらい。
まぁソシャゲで文句言ってる人はどうでもいいのですが、責任の所在を発信してる人たち。
AWS使う人がこれを知らないのは、今回の障害以上の問題と思ったほうがいいです。
利用サービスの設定で回避できる問題や障害、今回のようなアーキテクチャの組み方で回避出来ることであれば、全てAWSの利用者側の責任です。
AWSは回避策をちゃんと提供していて、コストの問題でそれを選ばなかったのは誰か？
責任の所在を問うなら回避策を選ばない決定をした人です。
アーキテクチャの決定権を持つ人がそんなこと知りませんでしたというなら、このリンク先の内容を脳が擦り切れるまで読み続けましょう。
またはAWSを任せているベンダーがいるなら、自身が理解できるまでちゃんとベンダーに説明させましょう。
もちろん、自分は理解する意思を持って説明を聞きましょう。
追記：2019/08/26
責任共有モデルはセキュリティ面での話であり、今回の件とは直接は繋がりません。
ここで伝えたいのは、障害＝AWSが全積任では無いということです。
#aws障害の投稿があまりにもCloudという仕組みがわかってない人と、AWSの責任を問う投稿が多すぎだったんで、おさらいで共有モデルを出しました。
可用性や信頼性の話が出てくるなら、そもそもSLAは100％になってないです。
SLAについてはこちら
たとえばEC2は99.99%になってるので、今回0.01%を引いてしまった。
ただそれだけの話です。
追記２：2019/08/26
上の追記で間違えたので修正。
「地域（Region)使用不能」とは、Availability Zone が一つしかない地域については、サービス利用者がインスタンスまたはタスク（コンテイナー1 個以上）のうち該当するものを実行している Availability Zone 及び他地域内のある Availability Zone がサービス利用者にとって同時に「使用不能」になることをいう。それ以外の全地域については、サービス利用者がインスタンスまたはタスク（コンテイナー1 個以上）のうち該当するものを実行している同一地域内の複数の Availability Zone が、サービス利用者にとって同時に「使用不能」となることをいう。
SLA
東京Regionは複数AZなので、それ以外の全地域が該当します。
ということはEC2のSLAはMultiAZの場合に99.99%と定義されてるので、単体EC2のSLAは定義されてなかったです。
つまりSLA定義が適用されていないSingleAZにしてたなら、AWSの保証対象外ということになりますね。
やっぱり行き着く先は利用者側責任です。
フォーカスを変える
確かに影響範囲が大きいためネガティブ発信が多いのですが、ちょっと見方を変えます。
細かい復旧状況
原文の翻訳と現地時間添えてみました。
9:18 PM PDT （日本時間 13:18）
We are investigating connectivity issues affecting some instances in a single Availability Zone in the AP-NORTHEAST-1 Region.
（AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンの一部のインスタンスに影響する接続の問題を調査しています。）
とりあえずこの時点で東京リージョンのどこかのAZが繋がりにくいということはわかります。
9:47 PM PDT（日本時間 13:47）
We can confirm that some instances are impaired and some EBS volumes are experiencing degraded performance within a single Availability Zone in the AP-NORTHEAST-1 Region. Some EC2 APIs are also experiencing increased error rates and latencies. We are working to resolve the issue.
（AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、一部のインスタンスが損なわれ、一部のEBSボリュームのパフォーマンスが低下していることを確認できます。一部のEC2 APIでは、エラー率とレイテンシが増加しています。この問題の解決に取り組んでいます。）
次の報告で東京リージョンのどこかのAZで一部インスタンスが死んでるのと、EBSにも障害が起きてることがわかります。
それによりエラー発生率とレイテンシが増加してることもわかり、問題調査してることも読み取れます。
10:27 PM PDT（日本時間 14:27）
We have identified the root cause and are working toward recovery for the instance impairments and degraded EBS volume performance within a single Availability Zone in the AP-NORTHEAST-1 Region.
（根本原因を特定し、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でのインスタンスの障害と劣化したEBSボリュームのパフォーマンスの回復に取り組んでいます。）
具体的には書かれてないですが、根本的な原因がここで特定されたことがわかります。
そこからインスタンスとEBSの復旧をし始めたことが読み取れます。
ここまでで約1時間半
11:40 PM PDT（日本時間 15:40）
We are starting to see recovery for instance impairments and degraded EBS volume performance within a single Availability Zone in the AP-NORTHEAST-1 Region. We continue to work towards recovery for all affected instances and EBS volumes.
（AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、インスタンスの障害および低下したEBSボリュームパフォーマンスの回復が見られ始めています。影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。）
根本的な原因が特定されてから1時間後、徐々にEBSの回復がされてきたことがわかります。
ここから更に影響が起きてるすべてのインスタンスとEBSの復旧に努めますとのこと。
Aug 23, 1:54 AM PDT (日本時間 17:54)
Recovery is in progress for instance impairments and degraded EBS volume performance within a single Availability Zone in the AP-NORTHEAST-1 Region. We continue to work towards recovery for all affected instances and EBS volumes.
（AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でのインスタンスの障害やEBSボリュームのパフォーマンスの低下について、リカバリが進行中です。影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。）
前回の報告から約2時間後、この段階ではまだ全体の復旧を継続中との経過報告。
リカバリ作業が継続的に行われてることと、それに対して別途問題は発生してないと。
Aug 23, 2:39 AM PDT (日本時間 18:39)
The majority of impaired EC2 instances and EBS volumes experiencing degraded performance have now recovered. We continue to work on recovery for the remaining EC2 instances and EBS volumes that are affected by this issue. This issue affects EC2 instances and EBS volumes in a single Availability Zone in the AP-NORTHEAST-1 Region.
（パフォーマンスが低下したEC2インスタンスとEBSボリュームの大部分は、現在回復しています。この問題の影響を受ける残りのEC2インスタンスとEBSボリュームの復旧に引き続き取り組みます。この問題は、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのEC2インスタンスとEBSボリュームに影響します。）
そして前回から1時間後、大部分の復旧が終わったとの報告。
全快に向けて引き続き復旧作業を続けることと、今回の問題がどの範囲に影響があったかの報告。
経過レポートだけで5時間の間に6回報告してくれてます。
これに加えて日本時間19:18に復旧報告が上がってきました。
今は日本語訳版が出てるので、そのまま載せます。
Aug 23, 4:18 AM PDT (日本時間 20:18)
日本時間 2019年8月23日 12:36 より、AP-NORTHEAST-1 の単一のアベイラビリティゾーンで、一定の割合の EC2 サーバのオーバーヒートが発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンス及び EBS ボリュームのパフォーマンスの劣化が発生しました。 このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。日本時間 15:21 に冷却装置は復旧し、室温が通常状態に戻り始めました。温度が通常状態に戻ったことで、影響を受けたインスタンスの電源が回復しました。日本時間 18:30 より大部分の EC2 インスタンスと EBS ボリュームは回復しました。 我々は残りの EC2 インスタンスと EBS ボリュームの回復に取り組んでいます。少数の EC2 インスタンスと EBS ボリュームが電源が落ちたハードウェア ホスト上に残されています。我々は影響をうけた全ての EC2 インスタンスと EBS ボリュームの回復のための作業を継続しています。 早期回復の為、可能な場合残された影響を受けている EC2 インスタンスと EBS ボリュームのリプレースを推奨します。いくつかの影響をうけた EC2 インスタンスはお客様側での作業が必要になる可能性がある為、 後ほどお客様個別にお知らせすることを予定しています。 |
ここまでこまめに復旧の進捗と最終報告をしてくれるCloudベンダーより、自社オンプレに戻したほうが安心というなら止めないです。
追記：2019/08/26
AWSから正式な障害レポートがあがりました。
ここでもELBのあたりは特に書かれてないので、フェイルオーバーがうまく行かなかった件についてはまだ謎のままですね・・・
起きてるのは物理障害
よくよく考えてください。
物理障害をたった7時間でほぼ全快まで復旧してるんです。
この規模の障害起きてるってことは、それだけの台数のサーバーがダウンしてるはずなのにたった7時間で復旧してるんですよ？ｗ
2時間で冷却システム復旧して、その後3時間でストレージもほぼ全快まで持っていってるんです。
これオンプレで出来ます？ｗ
確かに障害が起きたことは問題ではありますが、物理障害に対してのこの復旧スピードは神業だと思います。
本当に中の方々の早期対応ありがとうございました。
同じような障害が起きたときに、自社オンプレに戻したほうが早く復旧出来るというなら止めないです。
障害は起こるものである
極論、障害が起きる確率0％とか無理
というくらいのスタンスでインフラ設計をしていく必要があります。
こんなのはオンプレだって同じスタンスで設計するのではないでしょうか？
うちのネットワークは絶対壊れないから大丈夫！！とか言ってる方がいたら、色々なところで問題が起きそうですね。
自社オンプレならこんな規模の障害は起きないしって思ってる方は、Cloudと自社オンプレの時点で論点ズレてます。
まとめ
今回の一件でインフラ周りのアーキテクチャを見直すきっかけになったらいいんじゃないかなと思いました。
Cloudは銀の弾丸ではないので、与えられてる範囲が広い分やれることも自由度も高いですが、その分の責任もちゃんと持って使いましょう。
そして使う側がちゃんと知っておかないといけないこと、考慮しなきゃいけないことを理解していただけたら幸いです。
意外と大手もMultiAZ、MultiRegionまでの対応はしていないんだなって思いました。
別にSingleAZやSingleRegionでもいいんですけど、そのアーキテクチャを決定したならそれが原因で落ちても文句言うなって思います。
回避できるアーキテクチャはあるのに、選ばなかったのは自分たちですし。
そして障害にあたったサービスの中に居たのが・・・
PayPayまたお前か
コメント
まとめ記事ありがとうございました。
そもそもMultiAZにしていないと、SLAは99.99%が保証されていないですしね。
LBのケースを見ると、明確にユーザ側から障害対象のAZを切り離さないと、接続にいってた可能性があるのかもしれません。
あと、文中の追記の日付がすべて2018になってますが、2019かなと思います。
読んでいただきありがとうございます！
MultiAZじゃないと99.99%でないという認識はなかったです💦
SLAを確認したのですが表記が見つからなかったのですが、どこに謳われてるものですか？💦
→見つけました
https://d1.awsstatic.com/legal/amazon-ec2-sla/Amazon_EC2_Service_Level_Agreement_-_Japanese_Translation__2018-02-12_.pdf
LBはそうですね、これは正しくアーキテクチャ組んでる人でもダメだったみたいなので回答待ちですね・・・
日付ありがとうございます！修正しました！