2019年9月5日 クラスメソッド主催 AWS Well-Architected 活用術セミナー 8/23 東京リージョンで発生したサービスイベントまとめと対策

1. 東京リージョンで発生したサービスイベントまとめと対策

2. はじめに
2019年8月23日に東京リージョンの特定 AZ でサービスイベントが
発生し、複数のサービスが影響を受ける事態となりました。
将来のサービスイベント発生に備えて
Well-Architected フレームワーク 信頼性の柱 を基に
対策を考えてみます。

3. 公式発表 スーパーサマリー
8月23日 12:36 より EC2 停止が発生、オーバーヒートが原因
8月23日 13:21 特定の RunInstances API でエラー率上昇
8月23日 15:21 冷却装置が復旧
8月23日 16:05 APIエラー率はこの時間まで継続
8月23日 18:30 大部分は回復
8月28日 追加
EC2、EBS以外にもRDS、Redshift、ElastiCache、WorkSpaces等、
にも影響があった
https://aws.amazon.com/jp/message/56489/

4. 何が起きていたか？

5. お問い合わせ分布
EC2 58%
RDS 15%
EBS 8%
実際の障害ではなく
お問い合わせ時に
お客様が選択した分類。
Direct Connect、VPN など
もありますが、その先の
EC2 が原因だったようです。

6. Personal Health Dashboard
自身のアカウント内のリソースに影響があるイベントは
Personal Health Dashboard に表示されます。
大規模な障害発生時には管理しているアカウントの Dashboard を
確認するか、通知設定をしておくと影響を把握しやすいと思いま
す。

7. クラスメソッド ブログサイト
https://dev.classmethod.jp/cloud/aws/apne1-az4-down-0823-devio/
弊社のブログサイトも影響を受けました。
(詳細は上記 URL 参照)
その際の対応とどのような調査をしたのかを紹介します。
障害調査の対応としてはお手本のようでした。

8. 異常の検知
14:20 Slack の通知、 HTTP 5XX 発生を検知

9. 事象の確認
14:30
・ElasticBeanstalk のダッシュボード確認
・CloudWatch ALB ダッシュボード確認
・CloudWatch ALB 個別メトリクス確認
・EC2 正常性確認
・RDS 正常性確認
→ ALB の重点調査を開始
通知があったリソースを中心に関連するリソースを確認している

10. 調査
15:00
ALB のアクセスログから原因を調査
「actions_executed: waf-faild」が多発していることを突き止める
15:20
WAF のメトリクスからアクセス集中の疑いを排除
原因の特定、複合的要因の可能性を排除した

11. 対策
15:30
ALB の WAF 保護を一時的に無効化
15:40
収束を確認
復旧目的の一時的対策を行い、回復したことまで確認した

12. Well-Architected フレームワーク
信頼性の柱 を
障害対策の参考にする

13. 信頼性の柱
Well-Architected フレームワーク 5本の柱に信頼性の柱があります。
そのなかに記載されている設計原則は以下です。
● 復旧手順をテストする
● 障害から自動的に復旧する
● 水平方向にスケールして総合的なシステム可能性を向上する
● キャパシティーを勘に頼らない
● 変更は自動的に管理する

14. Application Design for Availability
システムの可用性を高めるための方法
- 障害分離ゾーン
- 冗長コンポーネント
- マイクロサービスアーキテクチャ
- リカバリ指向コンピューティング
- 分散システムのベストプラクティス

15. 障害分離ゾーン
AZ は分離します。(コストが許せば)
Multi-AZ でも影響受けたという一部報道がありますが、
原因を特定して切り離しをすれば復旧する可能性は高いと考えま
す。 (前述の弊社ブログのように)
Multi-Region はビジネスインパクトとコストを天秤にかけて
考えます。

16. 冗長コンポーネント
AWS 内の物理機器は冗長されている前提で考えます。
自社側の機器、例えば VPN/DX ルーターや回線、
AWS 保守専用端末についてもコストが許せば
冗長構成を考えます。

17. マイクロサービスアーキテクチャ
最小の機能セットをもったサービスを作成し
それを組み合わせてシステムを構築します。
マイクロサービスごとに可用性を定義できるようになり、
障害発生時の影響を限定することと、
切り離しによる復旧の容易さを実現します。

18. リカバリ志向コンピューティング
障害は起こるものとして、回復を重視しダウン時間を最小化
● 正常性の監視、通知
● ログファイルの出力、検索手順の確立
● 自動回復 (プロセス監視よる自動再起動など)
● 再デプロイ、ロールバックの容易さ
● Runbook による自動復旧
● エンドポイント FQDN接続の徹底 (IPアドレスで通信しない)
● ステートレスにする

19. 弊社SA ブログから

20. EC2をステートレス
スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれ
たかも？？？ Amazon EC2をステートレスにする為にやるべきこと
https://dev.classmethod.jp/cloud/aws/stateless_ec2/
SingleAZ配置のEC2インスタンスで障害発生時の影響を最小化する
https://dev.classmethod.jp/cloud/aws/minimize-failure-impact-on-singleaz/
複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定
Availability Zone上のリソースをパージする
https://dev.classmethod.jp/cloud/aws/purge-resources-specific-az/

21. 20EOF
ご静聴ありがとうございました