Architect's Log

I'm a Cloud Architect. I'm highly motivated to reduce toils with driving DevOps.

AWS障害の振り返り

社内で共有した文書です。クラウド初心者向けに書いているので、割り引いて読んでください。

2019/08/23の障害についてAWSがサマリーを公表しました。

aws.amazon.com

AZ(データセンターのこと)の空調設備の障害によるオーバーヒートが原因とのことでした。

一部のインスタンスについては、ハードウェアの障害によりリタイヤが必要だったと書かれています。

顧客のインスタンスが一部復旧せず、休日のサーバー再構築が必要だったと聞きました。

EC2は仮想サーバーなので、基盤の物理サーバーが壊れたらインスタンスも壊れます。それに対処するのは、AWSユーザーの責任です。このあたりは、責任共有モデルとして説明されています。

aws.amazon.com

この記事がわかりやすいです。

tech.nikkeibp.co.jp

AWSの設計指針として「クラウドコンピューティングのアーキテクチャ: ベストプラクティス」というホワイトペーパーがある。

そこにいくつか記されている指針の中で、最も有名なのがDesign for failureだ。「システムは故障する可能性があるものだという前提を受け入れ、あらかじめ故障に備えた設計をする」という考え方である。

では、具体的にどう対処したらいいのか?という話ですが、障害によるシステムダウンを回避する設計をする必要があります。

クラウドらしい(クラウドの価値を十分に享受できる)順に以下となります。

  1. マネージドサービスを組み合わせる
  2. EC2のMultiAZ構成
  3. 単一のEC2インスタンス

1.が最も望ましい選択肢です。非機能要件の実現をクラウドベンダーに任せることができ、運用フェーズが楽になります。

公式の資料では、こちらがわかりやすいです。

www.slideshare.net

1.が困難な場合は2.を選択すると、可用性を高めることができます。

ただし、

  • インフラとアプリケーションを冗長化できるよう設計する必要があります。シングルインスタンスで稼働しているシステムを単純にMultiAZに移行できるわけではありません。
  • 冗長化するので使用料金は上がる
  • まじめに運用設計しないと、インスタンスが増える分だけ運用コストが上がる

3.は止むを得ないケース以外は避けてください。オンプレでサーバーを運用するのとほとんど変わりません。 他に選択肢がなく採用する場合は、インスタンスのバックアップ(AMI Or スナップショット)を定期的に取得するようにしてください。