社内で共有した文書です。クラウド初心者向けに書いているので、割り引いて読んでください。
2019/08/23の障害についてAWSがサマリーを公表しました。
AZ（データセンターのこと）の空調設備の障害によるオーバーヒートが原因とのことでした。
一部のインスタンスについては、ハードウェアの障害によりリタイヤが必要だったと書かれています。
顧客のインスタンスが一部復旧せず、休日のサーバー再構築が必要だったと聞きました。
EC2は仮想サーバーなので、基盤の物理サーバーが壊れたらインスタンスも壊れます。それに対処するのは、AWSユーザーの責任です。このあたりは、責任共有モデルとして説明されています。
この記事がわかりやすいです。
AWSの設計指針として「クラウドコンピューティングのアーキテクチャ: ベストプラクティス」というホワイトペーパーがある。
そこにいくつか記されている指針の中で、最も有名なのがDesign for failureだ。「システムは故障する可能性があるものだという前提を受け入れ、あらかじめ故障に備えた設計をする」という考え方である。
では、具体的にどう対処したらいいのか？という話ですが、障害によるシステムダウンを回避する設計をする必要があります。
クラウドらしい（クラウドの価値を十分に享受できる）順に以下となります。
- マネージドサービスを組み合わせる
- EC2のMultiAZ構成
- 単一のEC2インスタンス
1.が最も望ましい選択肢です。非機能要件の実現をクラウドベンダーに任せることができ、運用フェーズが楽になります。
公式の資料では、こちらがわかりやすいです。
www.slideshare.net
1.が困難な場合は2.を選択すると、可用性を高めることができます。
ただし、
- インフラとアプリケーションを冗長化できるよう設計する必要があります。シングルインスタンスで稼働しているシステムを単純にMultiAZに移行できるわけではありません。
- 冗長化するので使用料金は上がる
- まじめに運用設計しないと、インスタンスが増える分だけ運用コストが上がる
3.は止むを得ないケース以外は避けてください。オンプレでサーバーを運用するのとほとんど変わりません。 他に選択肢がなく採用する場合は、インスタンスのバックアップ（AMI Or スナップショット）を定期的に取得するようにしてください。
