TOP > 政治・経済 > AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか【西田宗千佳のイマトミライ】-Impress Watch

AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか【西田宗千佳のイマトミライ】-Impress Watch

61コメント 登録日時:2019-08-26 09:19 | Impress Watchキャッシュ

8月23日午後、日本国内で多数のネットサービスが同時多発的にトラブルに見舞われた。...

Twitterのコメント(61)

専門外なんで「カオスエンジニアリング」という言葉を初めて知った(^_^;)・・>
落ちないサービスなどない。技術的障害やセキュリティ対策を経営課題としてとらえられるかどうか。とても考えさせられる良記事でした。
結局、露呈したのか、していないのかがわからない…
自分の担当範囲だけでもここ数年でオンプレ減ったなあって改めて思った
AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか【西田宗千佳のイマトミライ】

むしろ半日で治って、さすがAWSだなと
3つ目のAZがもっと早ければ、と思うけどDCの建築で燃えたりしたから仕方ないね。
北海道のブラックアウトと同じで「一極集中」が良くないのでは。
予算の壁を乗り越えるのも難しい。
確かにこれでクラウドの弱さというのは無茶がある
逆にクラウドでも障害は発生すると理解できた
SLAにはどの程度影響与えたんだろ?
すごくわかりやすい記事。
さすが、安定の西田氏の記事だった。

でも、EC2はストレージサービスではありません…
サービスの重要度によって対応をきちんとしないとねという話
そういえば去年はzenなんとかというサービスが4日ほど止まり続けたっけ・・・ |
カオスエンジニアリングか

結局のところ、危機的な状況下で、修羅場を経験しないと、人は成長しない

医者もそう

エンジニアでも、常に負荷をかけ続け、修羅場をくぐり抜ける力を早く身に付けたい
ほんの半日程度とか書いてあるけど、関係者にとっては果てしなく長い半日だったかと
「どのサービスがどのレベルの稼働率を維持しないといけないのか」 AWS障害に関する考え方、この記事が一番良くまとまっている。
とはいえこの理屈は「システム運営側」のことであって、システムを利用する側にその理屈は通らない。一瞬たりとも止まらないからこそのクラウドだからね
>決済サービスとゲームで同じレベルを維持するのは、一般論でいって過剰だ。

まぁゲームのほうが100倍大事ですよね
“自動復旧システムを用意し、わざとエンジニアがいる時間帯に障害を細かく「起こし続け」て、対処を継続していくことで、自動復旧システムの稼働状態を確認・維持し、エンジニアがいない時間帯にトラブルが起きた時 / “AWSの大規模障害は本当に「クラウドの弱さを露呈した…”
最後の段落、「なんとかペイ」にも通じる話… // 

AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか(Impress Watch)
まあ、「キメ」の問題ではあるよね。オンプレミスだと一蓮托生か過剰防衛にせざるを得ないけど、クラウドは捨てられるし二の矢三の矢もすぐに放てるわけで、「最適化された体制」を整えるには……という問題になる。 / “AWSの大規模障害は本当に「クラウドの弱さを露呈した…”
“むしろ今回の件で注目すべきは、「落ちるべきではないサービスも障害で落ちている」点である。決済系や認証系サービスは、そうしたものの中に含まれるのではないか” /
「カオスエンジニアリング」覚えました。
これを読んで理解できないって人はヤバイと思います。
クリティカルなミッションの設計がまだできてないのがクラウドだと思いました。

AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか【西田宗千佳のイマトミライ】
@impress_watch
記事によってMultiAzなら防げたかどうか見解が別れているけど、PayPayの障害はMultiAz構成にすらしてなかったということ?thoroughlyではない構成だった?
2019年8月26日 08:10 西田 宗千佳
クラウドの弱さじゃないって。同じコストでオンプレだったらもっと稼働率低いよ。
なるほど…カオスエンジニアリングか。覚えとこっと
クラウドの弱さと言うよりも、この規模の障害に対する準備不足と考慮漏れの方が大きい。と言うのが被害者コメントです(笑)
『特定のクラウド事業者に依存するもろさが露呈した(新聞)』
←『結局のところ(〜略〜)情報と知見が集まらないと、単純に結論を下すことはできない』
これが日本のジャーナリズムの実情。
必要なのは「どのサービスは落ちてはいけないのか」の判断だ。
「カオスエンジニアリング」という考え方は初めて知った。
そもそも何をもって「強い」「弱い」というのかをはっきりさせてないので結局ぼんやりした内容になってる
"EC2およびEBS(ともにストレージサービス)" EC2がストレージサービスだとは知らなかったですね…:
まさにこれ。“「経営課題としてテクノロジーをどう判断するのか」という話である。...だからこそ技術的妥当性の判断できる経営層、もしくは経営層に技術的妥当性を提案できるポジションが必要、ということなのだ” / “AWSの大規模障害は本当に「クラウドの弱さを露呈した」…”
オンプレサーバ管理とかしきれるわけない(したくない)
良いまとめ。「特定のクラウド事業者に依存するもろさが露呈した」とか書いてるの、どこの素人や。
Chaosねぇ〜♪
カオスエンジニアリング
知らなかった!面白い。
単純に、落ちたらアカンってのは、日本ではありがちな発想な気がする
こんな障害覚悟して使用しないと
この論点だとPayPayが落ちたの草。7Payがあまりにやらかしたので影が薄くなってしまったが、PayPayも開始当初はだいぶやらかしてたからな /
AWSの障害から学ぶカオスエンジニアリング。
『本番稼働中のシステムに擬似的に障害を起こして知見を蓄積して、実際の障害に備える。』
availability zoneって物理的な存在だから、RAID組んでるHDDの1個くらいに思った方がいいかもしれぬ。
オンプレのサーバ使っても結局ハード障害もネットワーク障害もあるし、何処かしらのクラウドに任せた方が絶対良い。
誰だよ、アマゾンの森林火災の影響でAWS障害が発生したとかデマ流してた奴!
正論ながら、モンスタークレーマーが大手を振る今の時代に「どのサービスは落ちてはいけないのか」みたいな考え方は一切通用しないというのもありそうかな…> -
カオスエンジニアリングかぁ。
なるほどね。コントロールできる障害を細かく起こし続けて自動復旧状態を可能にしておく仕組み。
どう運用に取り込めば良いかな?
「必要なのは『どのサービスは落ちてはいけないのか』の判断だ」 - Impress Watch
とても勉強になりました。
不具合を起こさないことも大事だが、サービスのどの部分を担保して、どれぐらいのコストや時間をかけるのか考えることも重要。
オンプレミスで 同様の障害が起これば、 1日で回復するのは 無理だったはず。

これで AWSの 評価は
落ちないでしょ。

むしろ、 迅速な対応に感謝する。
「特定のクラウド事業者に依存するもろさが露呈した」とか書いてる新聞社にはポンコツ記者やデスクしかいない可能性ってことですねw
「障害をわざと起こして、大きな障害を防ぐ」「カオスエンジニアリング」面白い考え方だなー。
新聞はねえ。どうしようもないよね。

これほどきちんと運用できてるデータセンター少ないほうだと思うし、
大体が空調屋さん来るの待ってない?
しっかり資料と教育整ってるから自らでできることをやれる。

とりあえず対応関係者さんお疲れ様でした。
"今回の件で注目すべきは、「落ちるべきではないサービスも障害で落ちている」点"
落ちてもいいサービスと、落ちてはいけないサービスの区別は非常に重要だと思う。 /
EC2ってストレージサービスなのか??
「クラウド」の弱さに対して、日本人は落ちない強い「クラウド」を求める。米人は弱い「クラウド」で如何にしてサービスを継続できるかを考える。米人の発想が現実解と思うけど、日本の経営者の大半は落ちない「クラウド」に向かうんだろうな。
必要なのは「どのサービスは落ちてはいけないのか」の判断だ
クラウドの弱さを露呈、とか書いた新聞があるんだ。弱いのは、あんたの(ry
「カオスエンジニアリング」そういう仕組みがあるのか
どっかからか金もらった記事?
弱さ露呈してるだろ

【西田宗千佳のイマトミライ】
以上

記事本文: AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか【西田宗千佳のイマトミライ】-Impress Watch

関連記事