AWS障害、5時間でほぼ復旧 気象庁Webサイトなどに影響【各サービス復旧状況を追記】
コメント
選択しているユーザー
マルチAZにしとけば問題なかったレベルでしょう。
日本人は完璧を求めすぎる傾向にあるので、システムは絶対に壊れないようにとか言いますが、そんなの絶対無理ですから。
突き詰めればただの機械。当然経年劣化もするし、予期せぬ誤作動でいきなり壊れたりもします。乱暴な言い方すると火事と同じです。できるだけ予防はしますが、100%防げというのは無理な話。
だから、壊れる前提でマルチAZにすることをAWSは推奨しているわけです。
クラウドだけではありません。
クラウドの先にあるコンテナやkubernetesも、「使ったら捨てる」のが製品思想です。壊れるのが大前提なのです。
落ちないシステムなんかありません。落ちても大丈夫なように設計をしとく。それだけです。
注目のコメント
気象庁のHPは大量同時アクセスが発生しうるので（地震や台風などのとき）、それにも耐えられるように堅牢なサーバーを使っているとは聞いていましたが、awsだったとは。
ちなみに仮復旧させている現在の防災情報ページは、本当は24日からリニューアルオープンするはずであったものを使っており、市町村ごとに区切られて各種情報へのアクセスがしやすくなっているものです。今までは一部の情報はアクセスがしにくく、奥底にある秘密のサイトのようになっていたところもありましたが、これについて大きく改善が図られた設計となっています。このままリニューアルでも良い気がします。“Design for Failure” AWSをはじめ、クラウド全般に言える基本中の基本とも言える思想（壊れることを前提とする）。システムに重要度を設定し、信頼性（障害の発生しにくさ）、可用性（システムが利用できる割合:稼働率）等のレベルに応じて、システムを構成する。初期のセールスの仕方により、どうしても安さが売り文句になりがちですが、クラウド導入によって得られるのはコストの弾力性（需給に合わせたコストコントロール）とアジリティ（やりたい時にすぐやれる、やりやすい）です。その辺をしっかり理解した上で、導入しないといけないですよね。
※障害が発生しているサイトやサービスを意識していないというわけではなく、優先度のもとで想定した範囲の障害になっているかが重要ですよね。もしそうでなければ、サービス/システム構成を改善する必要があると思います（そういった事を投資できるマネージメントの理解も大事）今回はasgで自動復旧したので以前のALBごと機能不全に陥った熱暴走よりはマシだった。ユーザーでは対策不能でしたから。
今回の障害は仕様通り動いたので問題なしと思っています。
ゲームはplacement groupsを使ってるでしょうから今回の様な障害でもある程度落ちてしまうのは仕方ないですよね。ゲーム会社の人はお疲れ様です。
それよりこの障害の1時間ほど前に一部インスタンスに通信出来なかったネットワーク障害の方が問題。仕様通りではない動きで対策不能、かつ問い合わせしないと障害について教えてくれない。
