2019-08-24この記事は約13分で読めます。おはようございます、hisayukiです。盛大なお祭りもだいぶ収束に向かってきました。障害は起こるものであるまとめスポンサーリンク障害発生まとめになってるので詳しくは省きますが、日本では珍しく数時間に渡る大規模障害が発生。日本時間で12時過ぎくらいから、数々のサイトやゲームなどで通信エラーが多発。そこからAWSが正式にIssueとしてユーザーに通知しました。システム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。12時36...piyolog.hatenadiary.jp原因どうやら冷房管理システムの障害から、機器の物理障害に発展したっぽいですね。これはなかなか治らないのはしかたないかなと。MultiAZなら大丈夫だったか障害期間中に特に言われてたのがこれです。AWSは単一AZでの障害ということだったので、MultiAZ組んでおけば大丈夫だったはず。なんかそういうわけでもなさそうですね。(当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ?という人の認識も変えられると嬉しいです)。いう話をしてい...blog.hirokiky.orgこのELBの問題は原因が不明確なのとAWSも見解を公表していないのでなんとも言えないですね。それにこのELBの件、ブログを書いてる人の感覚だと復旧作業後半から出てきた問題みたいなので、直接紐付いてる障害なのかも見えてこないですね・・・ちなみに同じ1aや1cでも人によって指してるDCが違うみたいなので、誰かが大丈夫と行っても他の人が大丈夫とは限りません。Developers.IOども、ゲストの大瀧です。AWSのデータセンターはリージョンとアベイラビリティゾーン(以下AZ)という単位でグループ化され、AZは地理的、設備的に独立しており可用性設計に役立てることができます。従来、AZを区別するためdev.classmethod.jpまぁでもMultiRegionならよっぽど大丈夫だったと思います。追記:2019/08/26現在、AWSからの公式な見解はでてないですが、DevelopersIOさんが自社で起きたことと対応を書いてくださいました。Developers.IOAWSチームのすずきです。12:36、東京リージョンのアベイアビリティゾーン(ID:apne1-az4)で障害が発生し、EC2やEBSが影響を受ける障害が発生しました。東京リージョンdev.classmethod.jp責任共有モデルTwitterの#aws障害のTweetがあまりにも酷いのでおさらい。ソシャゲで文句言ってる人はどうでもいいのですが、責任の所在を発信してる人たち。AWS使う人がこれを知らないのは、今回の障害以上の問題と思ったほうがいいです。クラウドのセキュリティを管理している一方で、クラウドにおけるセキュリティはお客様の責任となります。責任共有モデルの詳細をご覧ください。aws.amazon.com利用サービスの設定で回避できる問題や障害、今回のようなアーキテクチャの組み方で回避出来ることであれば、全てAWSの利用者側の責任です。AWSは回避策をちゃんと提供していて、コストの問題でそれを選ばなかったのは誰か?責任の所在を問うなら回避策を選ばない決定をした人です。アーキテクチャの決定権を持つ人がそんなこと知りませんでしたというなら、このリンク先の内容を脳が擦り切れるまで読み続けましょう。AWSを任せているベンダーがいるなら、自身が理解できるまでちゃんとベンダーに説明させましょう。自分は理解する意思を持って説明を聞きましょう。追記:2019/08/26責任共有モデルはセキュリティ面での話であり、今回の件とは直接は繋がりません。ここで伝えたいのは、障害=AWSが全積任では無いということです。#aws障害の投稿があまりにもCloudという仕組みがわかってない人と、AWSの責任を問う投稿が多すぎだったんで、おさらいで共有モデルを出しました。可用性や信頼性の話が出てくるなら、そもそもSLAは100%になってないです。SLAについてはこちらたとえばEC2は99.99%になってるので、今回0.01%を引いてしまった。追記2:2019/08/26上の追記で間違えたので修正。サービス利用者にとって同時に「使用不能」になることをいう。サービス利用者にとって同時に「使用不能」となることをいう。SLA東京Regionは複数AZなので、それ以外の全地域が該当します。いうことはEC2のSLAはMultiAZの場合に99.99%と定義されてるので、単体EC2のSLAは定義されてなかったです。SLA定義が適用されていないSingleAZにしてたなら、AWSの保証対象外ということになりますね。行き着く先は利用者側責任です。フォーカスを変える確かに影響範囲が大きいためネガティブ発信が多いのですが、ちょっと見方を変えます。原文の翻訳と現地時間添えてみました。Region.(AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンの一部のインスタンスに影響する接続の問題を調査しています。)とりあえずこの時点で東京リージョンのどこかのAZが繋がりにくいということはわかります。issue.(AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、一部のインスタンスが損なわれ、一部のEBSボリュームのパフォーマンスが低下していることを確認できます。APIでは、エラー率とレイテンシが増加しています。この問題の解決に取り組んでいます。)次の報告で東京リージョンのどこかのAZで一部インスタンスが死んでるのと、EBSにも障害が起きてることがわかります。それによりエラー発生率とレイテンシが増加してることもわかり、問題調査してることも読み取れます。Region.(根本原因を特定し、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でのインスタンスの障害と劣化したEBSボリュームのパフォーマンスの回復に取り組んでいます。)具体的には書かれてないですが、根本的な原因がここで特定されたことがわかります。そこからインスタンスとEBSの復旧をし始めたことが読み取れます。volumes.(AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内で、インスタンスの障害および低下したEBSボリュームパフォーマンスの回復が見られ始めています。影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。)根本的な原因が特定されてから1時間後、徐々にEBSの回復がされてきたことがわかります。ここから更に影響が起きてるすべてのインスタンスとEBSの復旧に努めますとのこと。volumes.(AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーン内でのインスタンスの障害やEBSボリュームのパフォーマンスの低下について、リカバリが進行中です。影響を受けるすべてのインスタンスとEBSボリュームの復旧に向けて引き続き取り組みます。)前回の報告から約2時間後、この段階ではまだ全体の復旧を継続中との経過報告。リカバリ作業が継続的に行われてることと、それに対して別途問題は発生してないと。Region.(パフォーマンスが低下したEC2インスタンスとEBSボリュームの大部分は、現在回復しています。この問題の影響を受ける残りのEC2インスタンスとEBSボリュームの復旧に引き続き取り組みます。この問題は、AP-NORTHEAST-1リージョンの単一のアベイラビリティーゾーンのEC2インスタンスとEBSボリュームに影響します。)そして前回から1時間後、大部分の復旧が終わったとの報告。全快に向けて引き続き復旧作業を続けることと、今回の問題がどの範囲に影響があったかの報告。経過レポートだけで5時間の間に6回報告してくれてます。これに加えて日本時間19:18に復旧報告が上がってきました。今は日本語訳版が出てるので、そのまま載せます。サーバのオーバーヒートが発生しました。ボリュームのパフォーマンスの劣化が発生しました。このオーバーヒートは、影響を受けたアベイラビリティゾーン中の一部の冗長化された空調設備の管理システム障害が原因です。冷却装置は復旧し、室温が通常状態に戻り始めました。温度が通常状態に戻ったことで、影響を受けたインスタンスの電源が回復しました。ボリュームは回復しました。ボリュームの回復に取り組んでいます。ホスト上に残されています。ボリュームの回復のための作業を継続しています。ボリュームのリプレースを推奨します。後ほどお客様個別にお知らせすることを予定しています。|ここまでこまめに復旧の進捗と最終報告をしてくれるCloudベンダーより、自社オンプレに戻したほうが安心というなら止めないです。追記:2019/08/26AWSから正式な障害レポートがあがりました。(AP-NORTHEAST-1)aws.amazon.com起きてるのは物理障害よくよく考えてください。物理障害をたった7時間でほぼ全快まで復旧してるんです。この規模の障害起きてるってことは、それだけの台数のサーバーがダウンしてるはずなのにたった7時間で復旧してるんですよ?w2時間で冷却システム復旧して、その後3時間でストレージもほぼ全快まで持っていってるんです。これオンプレで出来ます?w確かに障害が起きたことは問題ではありますが、物理障害に対してのこの復旧スピードは神業だと思います。本当に中の方々の早期対応ありがとうございました。同じような障害が起きたときに、自社オンプレに戻したほうが早く復旧出来るというなら止めないです。障害は起こるものである極論、障害が起きる確率0%とか無理というくらいのスタンスでインフラ設計をしていく必要があります。こんなのはオンプレだって同じスタンスで設計するのではないでしょうか?うちのネットワークは絶対壊れないから大丈夫!!とか言ってる方がいたら、色々なところで問題が起きそうですね。自社オンプレならこんな規模の障害は起きないしって思ってる方は、Cloudと自社オンプレの時点で論点ズレてます。まとめ今回の一件でインフラ周りのアーキテクチャを見直すきっかけになったらいいんじゃないかなと思いました。Cloudは銀の弾丸ではないので、与えられてる範囲が広い分やれることも自由度も高いですが、その分の責任もちゃんと持って使いましょう。使う側がちゃんと知っておかないといけないこと、考慮しなきゃいけないことを理解していただけたら幸いです。意外と大手もMultiAZ、MultiRegionまでの対応はしていないんだなって思いました。別にSingleAZやSingleRegionでもいいんですけど、そのアーキテクチャを決定したならそれが原因で落ちても文句言うなって思います。回避できるアーキテクチャはあるのに、選ばなかったのは自分たちですし。障害にあたったサービスの中に居たのが・・・PayPayまたお前かPayPayのやらかしについてまとめてみたすこし落ち着いてきましたが、PayPayのやらかした問題についてまとめました。この問題、既にSoftBankだけではどうにもならない事態に発展してます。PayPayを使ってない方にも影響のある話なので読んでいただければと思います。細かいサービスアップグレードとかはTokyoで聞いたので、今回は軽めのフィードバック...技術ネタEC2をT2からT3aに変更しようとしたら怒られた話こんにちわ、hisayukiです。弊社の社内システムが乗ってるEC2、既に2年ほど経ってまして・・・未だにt2.microなんですよね。課題もあったので、この際T3にしようとしたらハマった話を書いていきます。Plans使ってみたよ!!こんばんわ、hisayukiです。今日はクリスマスイブで今年もあと1週間切りました。前回のFargateのSpotに引き続きコスト削減ネタです。今回もす...技術ネタcurlからもslsからでもLambda(Rust)を動かせるようにしたこんばんわ、hisayukiです。先日やってみたこちらの話の続きです。実際、製造してるときにいちいちデプロイなんかやってられないですよね。MySQLのCPUが急に上限に張り付いたこんばんわ、hisayukiです。ID:Q2NTE3Mjcまとめ記事ありがとうございました。そもそもMultiAZにしていないと、SLAは99.99%が保証されていないですしね。LBのケースを見ると、明確にユーザ側から障害対象のAZを切り離さないと、接続にいってた可能性があるのかもしれません。あと、文中の追記の日付がすべて2018になってますが、2019かなと思います。コメントをキャンセルメールアドレスが公開されることはありません。