AWSの責任共有モデルとマルチAZを振り返ろう
https://gyazo.com/f226ee4fd29f92badeb843c2ad8b1064
◆ 目次
はじめに
責任共有モデル
DC、AZ、リージョン
マルチAZ
今回（2019/8/23）の障害
◆ はじめに
2019/8/23 午後1時ごろ、AWS東京リージョンの1つのAZ（apne1-az4）で障害が発生しました
現在はAWSのレベルでは復旧しています
この障害を受けて、AWSの責任共有モデルとマルチAZについて振り返ります
AWS以外のパブリッククラウドにも共通する考え方です
◆ 責任共有モデル とは
https://gyazo.com/a44bd690ecdf307542c0a7ba8b753055
お客様（利用者）：コンポーネントサービスの組合せ方やOS以上のアプリケーション、データの管理
AWS：個々のコンポーネントサービスやDCの物理的な環境
⇒ 手段・ツールはAWSが用意するけど、どう使うかは利用者の責任
◆ DC、AZ、リージョン
クラウドコンピューティングは、クラウドベンダの持つサーバ群・インフラを利用します
サーバ群・インフラはデータセンター（DC）内にあります
複数のDCで構成された独立したロケーションをアヴェイラビリティゾーン（AZ）と呼びます
「東京リージョン」「オレゴンリージョン」のようなリージョンは、複数のAZで構成されます
東京リージョンは 1a、1c、1d の3AZ構成です
リージョンにAZがいくつあるかはリージョンによって異なります
◆ マルチAZによる冗長構成
1つのAZは複数のDCと言ってもロケーションとして隣接しており、大規模停電などが発生するとAZごと利用できないことが考えられます
過去に実際に豪雨による停電障害が発生しています
そのため、複数のAZをまたいだ冗長構成 マルチAZ が推奨されています
◆ 代表的なマルチAZ構成
https://gyazo.com/b73385bfa21f04d88a640606ecd453a8
◆ マルチAZでのフェイルオーバー動作
https://gyazo.com/9bd9a2d947ea036bd37feb13c15c157f
◆ Well-Architected
このような、耐障害性（フォールトトレラント）やリスクを考慮した優れた設計を Well-Architected と呼びます
Design for Failure 故障のための設計
DC、サーバ、ネットワーク、アプリケーションといったすべてのレイヤーで故障を100%防ぐことはできません
故障することを前提にサービス・アプリケーションのダウンタイムが最小となるような設計を心がけるという思想
◆ Well-Architected な構成について知りたい？
公式の無料デジタルトレーニング
AWS Well-Architected Training (Japanese)
◆ その他参考資料
AWSにおける可用性の考え方 2013/3/1 - DevelopersIO
障害から学ぶクラウドの正しい歩き方について考える 2019/8/24 - そーだいなるらくがき帳
他に何かあればください
◆ 2019/8/23 の障害について考える
午後1時ごろ 東京リージョン の1つのAZ（apne1-az4）で障害が発生しました
EC2：コンピューティングサービス
RDS：リレーショナルデータベースサービス
影響を受けたサービス・アプリケーションが多発した
AWS障害 大規模な通信障害を受けたWEBサービスやスホゲー公式垢アナウンス報告まとめ - NAVERまとめ
◆ なぜここまで被害が広がった？
推測を含みます
マルチAZ構成にしていなかった？
⇒ 影響の合ったすべてのサービスがシングルAZ構成だったとは考えにくい
フェイルオーバーがうまくいかなかった？
AZ-1aを含むマルチAZにしていた構成でうまくフェイルオーバーされなかった
ALBの動作がおかしかった？
8月23日のAWSの大規模障害でMultiAZでも突然ALB（ELB）が特定条件で500エラーを返しはじめたという話 - Make組ブログ
◆ どうしておけばよかった？どうすればよかった？
設計するときに考えることは？
障害発生時にどうすればよかったのか？
あーだこーだタイム
◆ 実施後の参考資料 2019/8/29 追記
AZ名（1aなど）とAZ-IDの関係性について
AWSアカウントに因らずアベイラビリティゾーンを識別できるAZ IDを利用しよう - DevelopersIO
AWSによる障害レポート
東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
障害時のレポートや考察
8/23東京リージョン障害中の当ブログ稼働を紹介します - DevelopersIO
SingleAZ配置のEC2インスタンスで障害発生時の影響を最小化する - DevelopersIO
スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも？？？ Amazon EC2をステートレスにする為にやるべきこと - DevelopersIO
AWS障害、“マルチAZ”なら大丈夫だったのか？ インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」 - CLOUD USER by IT MEDIA NEWS