「AWS東京リージョンで大規模障害、原因は冷却システムの故障」記事へのコメント

クラウドの冗長構成の考え方の良まとめ

[Anonymous Coward]

Impressの記事が凄い良くまとまってたので、じゃあどういう構成にすべきかとか考えてる人に読んでもらいたい。

AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか [impress.co.jp]

重要なのは、「どのサービスがどのレベルの稼働率を維持しないといけないのか」という点だ。

世の中には、絶対に落ちては困るサービスがある。消えては困るデータもある。

一方で、費用対効果を考えると、数年に一度あるかないかの大規模障害に備える必然性はない、というサービスもあるはずだ。

決済サービスとゲームで同じレベルを維持するのは、一般論でいって過剰だ。また同じサービスの中でも

Re:

[nemui4 (20313)]

サービス維持にお金をどれだけ出せるかですね。
マルチリージョン化すると、リージョン数分のお金が必要になるし。

>むしろ今回の件で注目すべきは、「落ちるべきではないサービスも障害で落ちている」点である。決済系や認証系サービスは、そうしたものの中に含まれるのではないか。

金勘定関わると対策は必須ですよね、動画配信やゲームだと割り切りそう。

Re:

[Anonymous Coward]

金融・決裁系はそもそも単一サービス/機器「だけで」組まないっていうの基本のはずなんだけどね。
関連省庁に怒られるのが目に見えているし、監査でも絶対指摘されるし。
まあ、実のところは「うまく切り替わらなかった」んだと思う。

Re:

[nemui4 (20313)]

>まあ、実のところは「うまく切り替わらなかった」んだと思う。

稼働中サービスだと、実環境でその手のテストも難しそうだし。
テスト用の環境を構築するのもどこまでやるかは予算次第だろうし。
運営管理者さん達大変そう。

Re:

[Anonymous Coward]

マルチAZでも影響を受けた話 [hirokiky.org]をみると、今回みたいにAZ(az4)内の一部のみの障害だと正常に動作している部分によりかえって影響を受けて、1つのAZを切り離してみるテストが成功していたとしても今回の障害には耐えられなかった可能性もありそう。

Re:クラウドの冗長構成の考え方の良まとめ

[Anonymous Coward]

あげていただいたリンクを見る限り、ロードバランサーとしては普通に想定できる障害で、
インフラ設計にハードウェアロードバランサーを組み込んだ経験がある設計者なら「さもありなん」な感想をもつ内容かと。

ただ、問題としてはAWSだとロードバランサー自体の障害対応まで頭が回りづらい構成になっていることかねぇ。
物理機器いじくるインフラエンジニアがクラウドまで見てるとは思えないし。