![[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...](https://cdn.slidesharecdn.com/ss_thumbnails/awsblackbelt2018reinvent2018digest-181130052158-thumbnail.jpg?width=560&fit=bounds)
![[最新版(12/5 最新版) が別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar A...](https://cdn.slidesharecdn.com/ss_thumbnails/awsblackbelt2018reinvent2018digestupdated-181201055918-thumbnail.jpg?width=560&fit=bounds)
More Related Content
Similar to 20190905 aws well-architected_framework_seminar_service_eventattokyoregion (20)
More from Yoshii Ryo (10)
20190905 aws well-architected_framework_seminar_service_eventattokyoregion
- 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 収束を確認 復旧目的の一時的対策を行い、回復したことまで確認した
- 13. 信頼性の柱 Well-Architected フレームワーク 5本の柱に信頼性の柱があります。 そのなかに記載されている設計原則は以下です。 ● 復旧手順をテストする ● 障害から自動的に復旧する ● 水平方向にスケールして総合的なシステム可能性を向上する ● キャパシティーを勘に頼らない ● 変更は自動的に管理する
- 14. Application Design for Availability システムの可用性を高めるための方法 - 障害分離ゾーン - 冗長コンポーネント - マイクロサービスアーキテクチャ - リカバリ指向コンピューティング - 分散システムのベストプラクティス
- 15. 障害分離ゾーン AZ は分離します。(コストが許せば) Multi-AZ でも影響受けたという一部報道がありますが、 原因を特定して切り離しをすれば復旧する可能性は高いと考えま す。 (前述の弊社ブログのように) Multi-Region はビジネスインパクトとコストを天秤にかけて 考えます。
- 16. 冗長コンポーネント AWS 内の物理機器は冗長されている前提で考えます。 自社側の機器、例えば VPN/DX ルーターや回線、 AWS 保守専用端末についてもコストが許せば 冗長構成を考えます。
- 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/