大規模障害から見るAWSのバックエンド #awswakaran_tokyo

# 大規模障害から見るAWSのバックエンド
#### 2019/09/25 #awswakaran_tokyo
### 株式会社ドリコム　インフラストラクチャー部
中村 昴 (@varu3)

---
# 自己紹介
- ばるさん
- twitter: varu_3
- github: varusan
- Blog: https://varu3.hatenablog.com/
- インフラストラクチャー部
- 弊社で運用しているソーシャルゲーム、WEBサービスの主にインフラ部分を管理している部署です
- 社内サービス（GitLabやRPMパッケージ）
- AWS, GCP, 国内パブリッククラウド, Kubernetesなど

---
# 2019年8月23日....　

---

# 止まるインスタンス...
# 鳴り止まないアラート...
# 流速が増すTwitterのTL...
# 加熱する報道...
# 祈りの声...
# 悲鳴…

---

# AWSの大規模障害
- 日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。
- いわゆるAZ障害、ゾーン障害

---
# アベイラビリティゾーンのちょっとした話
- `ap-northeast-1a`が示すゾーンはアカウントごとに異なる
- アカウントごとでは`ZoneId`が識別子となる
- 確認の仕方
```
$ aws ec2 describe-availability-zones
{
"AvailabilityZones": [
{
"State": "available",
"ZoneName": "ap-northeast-1a",
"Messages": [],
"ZoneId": "apne1-az4",
"RegionName": "ap-northeast-1"
}
]
}
```

---

# 弊社で起きた事

---
# その１
# EC2インスタンスのステータスチェックに失敗する

---
## 発生直後
- 稼働中のインスタンスのAWS上でのステータスチェックが失敗し、疎通ができなくなった。
- 止まるインスタンスは 3 AZのうちの 1 つのAZのみ
- 大半のインスタンスは`強制停止` → `起動`で復旧たが、一部立ち上がらないインスタンスもあった

- 立ち上がらなかったインスタンスを、AMIイメージを取得してそのAMIから立ち上げようとするも失敗
- EBSスナップショットも取れない状態

---

## EC2インスタンスの強制停止？

``` bash
$ aws ec2 stop-instances --instance-ids <インスタンスID> --force
```
- インスタンス停止コマンドで`--force`をつけると強制停止となる
- それでも停止できない場合は、心を強く持って連打

- もしくはAWS上でstopping 中にさらに停止すると、強制停止になる

---

# 対応策
- 止まったら困るインスタンス（絶賛開発中のサーバとか）は日次スナップショットを取っておく

- EBSのスナップショットはS3に保存される
- S3は最低3つのAZに冗長化されて保存される
- そのため、他のAZでも起動できる（はず）
- 障害時にはバックアップからインスタンスを起動する
- 本番環境
- MultiAZ構成
- オートスケールしなくても台数を固定してオートスケーリンググループで管理する
- 問題が起きたインスタンスを削除して他AZで立ち上げる

---

# その２
# Elasticache(Memcached)でのパフォーマンスが低下する

---

- NewRelicのメトリクス
- 障害が発生した時間帯からMemcachedの負荷が微増している状態
- Memcached クラスタには接続はできている

---
- CloudWatchメトリクスが正常に取得できていない
- 一見、`available`となっているため問題ないように見えるがこれは罠。

---
# なぜMemcachedでも影響が？
- EC2とEBSを基盤として動作しているため
- その他にもRDS、 Redshift、 ElastiCache および Workspace なども。

- 当初、障害が起きているとアナウンスされたのは、AWSではEC2, EBSのみだった
- 該当サービスがなくてよかった、と安心してはいけない。
- むしろEC2の障害だと大きく影響範囲が広がる可能性を考慮する。

---

# その3.
# ALBで5xxエラーが発生

---
- 障害発生時からALBで5xxエラーが増加。
- ALBログを確認したところ` "actions_executed": "waf-failed"` と出ていた

- このALBはWAFと紐づけていた

---
# どういうことか

## 本来の挙動
1. ALBのリクエストはAWS WAFへ転送される
1. AWS WAF はリクエストのブロックもしくは許可する
1. 許可されたリクエストは本来のリクエスト先へ

## 障害発生時
- 障害が発生したAZへルーティングされたWAF上で問題が発生した
- 本来の挙動でいうと2.の部分

---

※クラスメソッドさんの記事より:
https://dev.classmethod.jp/cloud/aws/apne1-az4-down-0823-devio/

---
# 対応
- WAFを無効にする
- ALBのサブネットから問題が起きたリージョンを外す
- ALBは最低 2 AZが必要なため、3 AZ目のサブネットの設定をしておく

---
# 障害時の情報源

- AWS Personal Health Dashboard
- 各アカウントごとにAWSコンソールから参照できる
- 公式の（おそらく）一番確かで早い情報
- 報告されない事象もある（EC2がバックエンドだったものなど）

- AWS Service Health Dashboard
- https://status.aws.amazon.com/
- 探しやすい、一覧性がある
- ただし情報は即座には反映されない（体感、ラグがある）

- Twitter
- 情報の精度としては玉石混合
- みんなが大変そうなのはわかる。
---

# まとめ

- 単一インスタンスは定期的にスナップショットを取ることが必要だよ
- 本番環境では、オートスケーリンググループでインスタンスを管理して、柔軟にインスタンス数やAZを変更できることが大事だよ
- EC2の障害はEC2以外にも、他のEC2がバックエンドで使われているフルマネージドサービスにも影響を及ぼすよ
- 障害を辿るとAWSのバックエンドがチョットワカルようになるよ
- 情報を逐一確認しながら、自分たちのアカウントではどのように影響が出ているかを確認することが大事だよ

---

# 最後に
- 弊社ではこのような事例があったものの幸いなことに、本番環境への影響は最低限に止めることができました。
- AWSの中の人やサービス対応におわれた方々、本当にお疲れ様でした！！

Transcript

1. 大規 模障害 から見るAWSのバックエンド 2019/09/25 #awswakaran _tokyo 株式会社ドリコム インフラストラクチャー部 中 村 昴 ( @varu3)
2. 自 己紹介 ばるさん twitter: varu _3 github: varusan Blog: https://varu3.hatenablog.com/ インフラストラクチャー部 弊 社で 運 用しているサービスのインフラを 管理している部 署 です AWS, GCP, 国内パブリッククラウド, Kubernetesなどなど
3. 2019年8月23日....
4. 止 まるインスタンス... 鳴 り 止 まないアラート... 流 速 が 増 すTwitterのTL... 加 熱 する報 道... 祈 りの 声 ... 悲鳴…
5. AWSの大規 模障害 日本時間 2019年8月23日 12:36 より、東 京 リージョン (AP-NORTHEAST-1) の 単 一のアベ イラビリティゾーンで、オーバーヒートにより一定の 割合の EC2 サーバの 停止 が発生し ました。 いわゆるAZ 障害 、ゾーン 障害
6. アベイラビリティゾーンのちょっとした話 a p - n o r t h e a s t - 1 a が示すゾーンはアカウントごとに 異 なる アカウントごとでは Z o n e I d が 識 別子となる 確認 の 仕 方 $ a w s e c 2 d e s c r i b e - a v a i l a b i l i t y - z o n e s { " A v a i l a b i l i t y Z o n e s " : [ { " S t a t e " : " a v a i l a b l e " , " Z o n e N a m e " : " a p - n o r t h e a s t - 1 a " , " M e s s a g e s " : [ ] , " Z o n e I d " : " a p n e 1 - a z 4 " , " R e g i o n N a m e " : " a p - n o r t h e a s t - 1 " } ] }
7. 弊 社で 起 きた事
8. その １ EC2インスタンスのステータスチェックに 失敗する
9. 発生 直後 稼働 中のインスタンスのAWS上でのステータスチェックが 失敗し、 疎 通ができなくなっ た。 止 まるインスタンスは 3 AZのうちの 1 つのAZのみ 大 半 のインスタンスは 強制停止 → 起動 で 復旧 たが、一部 立ち上がらないインスタ ンスもあった 立ち上がらなかったインスタンスを、AMIイメージを取 得 してそのAMIから 立ち上げ ようとするも 失敗 EBSスナップショットも取れない 状態
10. EC2インスタンスの 強制 停止 ？ $ a w s e c 2 s t o p - i n s t a n c e s - - i n s t a n c e - i d s < インスタンスI D > - - f o r c e インスタンス 停止 コマンドで - - f o r c e をつけると 強制 停止 となる それでも 停止 できない場合は、 心を 強く 持 って連 打 もしくはAWS上でstopping 中にさらに 停止 すると、 強制 停止 になる
11. 対 応 策 止 まったら 困 るインスタンス（ 絶賛 開発中のサーバとか）は日 次スナップショットを取 っておく EBSのスナップショットはS3に 保 存 される S3は最 低3つのAZに 冗 長 化されて 保 存 される そのため、他のAZでも 起 動できる（はず） 障害 時にはバックアップからインスタンスを 起 動する 本番 環境 MultiAZ 構成 オートスケールしなくても 台 数を 固 定してオートスケーリンググループで 管理する 問 題 が 起 きたインスタンスを 削除して他AZで 立ち上げる
12. その ２ Elasticache(Memcached)でのパフォーマンスが 低 下する
13. NewRelicのメトリクス 障害 が発生した時間 帯 からMemcachedの 負荷 が 微増 している 状態 Memcached クラスタには 接続 はできている
14. CloudWatchメトリクスが正 常 に取 得 できていない 一見、 a v a i l a b l e となっているため問 題 ないように見えるがこれは 罠 。
15. なぜMemcachedでも 影 響 が？ EC2とEBSを 基 盤 として動作しているため その他にもRDS、 Redshift、 ElastiCache および Workspace なども。 当初、 障害 が 起 きているとアナウンスされたのは、AWSではEC2, EBSのみだった 該 当サービスがなくてよかった、と 安心してはいけない。 むしろEC2の 障害 だと大きく 影 響範囲 が広がる可能性を 考慮 する。
16. その3. ALBで5xxエラーが発生
17. 障害 発生時からALBで5xxエラーが 増 加。 ALBログを 確認 したところ " a c t i o n s _ e x e c u t e d " : " w a f - f a i l e d " と出ていた このALBはWAFと 紐 づけていた
18. どういうことか 本 来の 挙 動 1. ALBのリクエストはAWS WAFへ 転送される 2. AWS WAF はリクエストのブロックもしくは 許 可する 3. 許 可されたリクエストは本 来のリクエスト先へ 障害 発生時 障害 が発生したAZへルーティングされたWAF上で問 題 が発生した 本 来の 挙 動でいうと2.の部分
19. ※ クラスメソッドさんの記事より: https://dev.classmethod.jp/cloud/aws/apne1-az4-down-0823-devio/
20. 対 応 WAFを無 効にする ALBのサブネットから問 題 が 起 きたリージョンを外す ALBは最 低 2 AZが 必 要なため、3 AZ目のサブネットの設定をしておく
21. 障害 時の情報 源 AWS Personal Health Dashboard 各 アカウントごとにAWSコンソールから 参照できる 公式の（おそらく）一番 確 かで 早 い情報 報 告されない事 象 もある（EC2がバックエンドだったものなど） AWS Service Health Dashboard https://status.aws.amazon.com/ 探 しやすい、一覧性がある ただし情報は 即座 には 反映 されない（体 感、ラグがある） Twitter 情報の 精 度としては 玉 石混 合 みんなが大変そうなのはわかる。
22. まとめ 単 一インスタンスは定 期的にスナップショットを取ることが 必 要だよ 本番 環境 では、オートスケーリンググループでインスタンスを 管理して、 柔軟にインス タンス数やAZを変更できることが大事だよ EC2の 障害 はEC2以外にも、他のEC2がバックエンドで使われているフルマネージドサー ビスにも 影 響 を 及 ぼすよ 障害 を 辿るとAWSのバックエンドがチョットワカルようになるよ 情報を 逐 一 確認 しながら、自分たちのアカウントではどのように 影 響 が出ているかを 確 認 することが大事だよ
23. 最後に 弊 社ではこのような事 例があったものの 幸 いなことに、本番 環境 への 影 響 は最 低限 に 止 めることができました。 AWSの中の人やサービス対 応におわれた方 々、本当にお 疲 れ様でした！！