Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 障害に備えたアーキテクチャを考える
Similar to 障害に備えたアーキテクチャを考える (20)
More from Yoshii Ryo
More from Yoshii Ryo (10)
Recently uploaded
障害に備えたアーキテクチャを考える
- 3. 内容について注意点 ● 資料作成にあたり、調査したうえで記載しておりますが 資料内の内容と AWS 公式アナウンスやドキュメントに 差異がある場合には、AWS 公式を正と致します。 ● 本資料は本セミナー向けに記載しております。 内容に関する質問やお問い合わせは、坂巻、吉井、または、 セミナー担当者へお願い致します。
- 4. 4 Please Share on social media #cmdevio #cmdevio5
- 5. 目次 ～ 本日の内容 ⮚ 2019年8月23日 東京リージョン障害 5分 ⮚ トラブルで右往左往しないためには 5分 ⮚ AWS Well-Architected Framework 15分 信頼性の柱 紹介 ⮚ 障害に備えるアーキテクチャとは 20分
- 6. 6自己紹介 吉井 亮 (YOSHII Ryo) クラスメソッド株式会社 AWS事業本部 コンサルティング部 好きなAWSサービス： Systems Manager 好きなフレーズ： No human labor is No human error YoshiiRyo1
- 8. 8公式発表スーパーサマリー 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/
- 9. 9弊社サポートへのお問い合わせ EC2 : 58% RDS : 15% EBS : 8% 実際の障害ではなくお問い合わせ時に お客様が選択した分類。 Direct Connect、VPN などもありますが、 その先の EC2 が原因だったようです。
- 11. 11何が起きた？ AZ-C で ElastiCache ノードを増やそうとしたが ノード増が完了したのが AZ-A 回復後になった
- 13. 13何が起きた？ ALB スティッキーセッションを有効していて クライアントが AZ-A へアクセスし続けた
- 14. 14何が起きた？ アプリケーションが RDS や ElastiCache の EndPoint IP アドレスをキャッシュしていたため フェイルオーバー後も AZ-A へ接続しようとした
- 16. 16クラスメソッド ブログサイト 管理者から学ぶ https://dev.classmethod.jp/cloud/aws/apne1-az4-down-0823-devio/ 弊社のブログサイトも影響を受けました。 (詳細は上記 URL 参照) その際の対応とどのような調査をしたのかを紹介します。 障害調査の対応としてはお手本のようでした。
- 17. 17異常の検知 14:20 Slack の通知、 HTTP 5XX 発生を検知
- 18. 18事象の確認 14:30 ・ElasticBeanstalk のダッシュボード確認 ・CloudWatch ALB ダッシュボード確認 ・CloudWatch ALB 個別メトリクス確認 ・EC2 正常性確認 ・RDS 正常性確認 → ALB の重点調査を開始 通知があったリソースを中心に関連するリソースを確認している
- 19. 19原因の特定 15:00 ALB のアクセスログから原因を調査 「actions_executed: waf-faild」が多発していることを突き止め る 15:20 WAF のメトリクスからアクセス集中の疑いを排除 原因の特定、複合的要因の可能性を排除した
- 20. 20対策 15:30 ALB の WAF 保護を一時的に無効化 15:40 収束を確認 復旧目的の一時的対策を行い、 回復したことまでを確認した
- 21. 21小まとめ 右往左往しないために準備しておくこと 1. サービス断を検知→通知する仕組み 2. 何が起きているか判るようにメトリクスを取得 3. ログを S3/CWLogs へ出力 4. ログの検索手順を確立 5. 想定障害と復旧手順があるとベスト
- 23. 2 3 AWS事業本部コンサルティング部 坂巻 一義 2019/11/1 AWS Well-Architected Framework 信頼性の柱 紹介
- 25. 自己紹介 坂 巻 一 義 ‣AWS事業本部コンサルティング部 ‣AWS設計、構築 ‣＠nochi251 ほぼ銭湯
- 26. AWS Well-Architected Framework おさらい Well-Architected Framework おさらい
- 30. AWS Well-Architected Toolで評価可能 AWS Well-Architected Tool 合計46の質問項目
- 34. AWS Well-Architected Framework おさらい Well-Architected Framework 信頼性の柱
- 36. 信頼性を向上するための5つの観点 1. 復旧手順をテストする 2. 障害から自動的に復旧する 3. 水平方向にスケールしてシステム全体の可用性を 向上させる 4. システムスペックの推計をやめる 5. 自動で変更を管理する 設計原則
- 37. 復旧手順をテストする オンプレミスでは... クラウドでは... ➢ 安価に本番同等の規模が構築可能 ➢ 本番規模で繰り返しテストすることで信頼性を向上 ➢ 本番規模の開発環境がないこともしばしば ➢ 本番規模で復旧テストすることが少ない AWS CloudFormation AMI Snapshot
- 38. 障害から自動的に復旧する Amazon CloudWatch AWS LambdaAmazon Simple Notification Service 監視項目がしきい値に達した時に あらかじめ設定済みの処理を自動的に実行
- 39. 自動復旧の例：EC2 Auto Recovery しきい値超過検出 再起動 メトリクス EC2 アクション システムステータスチェックまたは、インスタンスステータスチェ ックがエラーになった際に EC2 インスタンスの停止・起動を行う ことにより自動復旧する
- 41. スペックの推計をやめる ➢ キャパシティプランニング不要 ➢ Auto Scaling等で需要にあわせて最適なリソースを維持 自動でリソースを追加/削除 適切なスペックを維持
- 46. 基盤：信頼性の質問２ ネットワークトポロジをどのように管理していますか? ❏ パブリッククラウドとオンプレミス環境のプライベートアドレス 間で可用性の高い接続を活用する ❏ ワークロードのユーザー向けに可用性の高いネットワーク接続を 活用する ❏ 接続されている複数のプライベートアドレス空間において、重複 しないプライベート IP アドレス範囲を指定します ❏ 拡張や可用性のために割り当てる IP サブネットを確保する
- 47. 基盤：信頼性の質問２ ネットワークトポロジをどのように管理していますか? ❏ パブリッククラウドとオンプレミス環境のプライベートアドレス 間で可用性の高い接続を活用する ❏ ワークロードのユーザー向けに可用性の高いネットワーク接続を 活用する ❏ 接続されている複数のプライベートアドレス空間において、重複 しないプライベート IP アドレス範囲を指定します ❏ 拡張や可用性のために割り当てる IP サブネットを確保する ネットワーク経路は冗長化し、 将来の拡張を考慮し 可用性の高いサービスを利用しよう
- 48. 基盤：信頼性の質問２ ネットワークトポロジをどのように管理していますか? ❏ パブリッククラウドとオンプレミス環境のプライベートアドレス 間で可用性の高い接続を活用する ❏ ワークロードのユーザー向けに可用性の高いネットワーク接続を 活用する ❏ 接続されている複数のプライベートアドレス空間において、重複 しないプライベート IP アドレス範囲を指定します ❏ 拡張や可用性のために割り当てる IP サブネットを確保する
- 51. 基盤：信頼性の質問２ ネットワークトポロジをどのように管理していますか? ❏ パブリッククラウドとオンプレミス環境のプライベートアドレス 間で可用性の高い接続を活用する ❏ ワークロードのユーザー向けに可用性の高いネットワーク接続を 活用する ❏ 接続されている複数のプライベートアドレス空間において、重複 しないプライベート IP アドレス範囲を指定します ❏ 拡張や可用性のために割り当てる IP サブネットを確保する
- 53. 基盤：信頼性の質問２ ネットワークトポロジをどのように管理していますか? ❏ パブリッククラウドとオンプレミス環境のプライベートアドレス 間で可用性の高い接続を活用する ❏ ワークロードのユーザー向けに可用性の高いネットワーク接続を 活用する ❏ 接続されている複数のプライベートアドレス空間において、重複 しないプライベート IP アドレス範囲を指定します ❏ 拡張や可用性のために割り当てる IP サブネットを確保する
- 54. 基盤：信頼性の質問２ VPC、サブネット 共に将来の拡張を 考慮し十分なサイ ズにする オンプレミス、ピ アVPCとIP 範囲 が重複しないよう に考慮 AWS Direct Connect VPC Peering
- 55. ホワイトぺーパー／Foundation - Networking RFC1918ガイドライ ンに従いCIDR割当 AWS Direct Connect VPC Peering スペースを残しておく
- 56. ホワイトぺーパー／Foundation - Networking AWS Direct Connect VPC Peering CIDRは変更できないので 拡張を見越し十分なスペースを確保
- 57. 変更管理：信頼性の質問４ リソースをどのようにモニタリングしていますか？ ❏ ワークロードにおける全ての層をモニタリングする ❏ モニタリングに基づいて通知を送信する ❏ イベントに対して自動化された応答を実行する ❏ 定期的にレビューを実施する
- 58. 変更管理：信頼性の質問４ ❏ ワークロードにおける全ての層をモニタリングする ❏ モニタリングに基づいて通知を送信する ❏ イベントに対して自動化された応答を実行する ❏ 定期的にレビューを実施する モニタリングして異常通知 自動復旧、評価しよう リソースをどのようにモニタリングしていますか？
- 59. AWS Personal Health Dashboard • パーソナライズされた情報の表示 • 自アカウントで使用している AWS サービス・リソースの障害情報、 計画されたリタイアメント通知/メ ンテナンス情報を確認できる • CloudWatch Eventsと連携して通 知可能 AWS Personal Health Dashboard
- 61. 障害管理：信頼性の質問６ データをどのようにバックアップしていますか？ ❏ バックアップする必要があるデータをすべて特定し、バックアッ プやソースからのデータの複製を実行する ❏ データのバックアップまたはソースからのデータの複製を自動的 に実行する ❏ データの定期的な復旧を行ってバックアップの完全性とプロセス を確認する ❏ バックアップを保護または暗号化するか、データが安全なソース から複製できることを確認する
- 62. 障害管理：信頼性の質問６ データをどのようにバックアップしていますか？ ❏ バックアップする必要があるデータをすべて特定し、バックアッ プやソースからのデータの複製を実行する ❏ データのバックアップまたはソースからのデータの複製を自動的 に実行する ❏ データの定期的な復旧を行ってバックアップの完全性とプロセス を確認する ❏ バックアップを保護または暗号化するか、データが安全なソース から複製できることを確認する
- 63. 障害管理：信頼性の質問６ データをどのようにバックアップしていますか？ ❏ バックアップする必要があるデータをすべて特定し、バックアッ プやソースからのデータの複製を実行する ❏ データのバックアップまたはソースからのデータの複製を自動的 に実行する ❏ データの定期的な復旧を行ってバックアップの完全性とプロセス を確認する ❏ バックアップを保護または暗号化するか、データが安全なソース から複製できることを確認する バックアップデータを特定して 自動でバックアップしよう
- 64. バックアップ自動化に向けたソリューション • EBS • Amazon Data Lifecycle Managerによるスナップショッ ト取得 • AWS Backupによるスナップショット取得 • RDS • 標準機能によるスナップショットの自動取得 • AWS Backupによるスナップショット取得 • S3 • バージョニング機能
- 65. バックアップ自動化に向けたソリューション • EBS • Amazon Data Lifecycle Managerによるスナップショッ ト取得 • AWS Backupによるスナップショット取得 • opswitchによる自動取得 • RDS • 標準機能によるスナップショットの自動取得 • AWS Backupによるスナップショット取得 • opswitchによる自動取得 • S3 • バージョニング機能
- 67. 障害管理：信頼性の質問６ データをどのようにバックアップしていますか？ ❏ バックアップする必要があるデータをすべて特定し、バックアッ プやソースからのデータの複製を実行する ❏ データのバックアップまたはソースからのデータの複製を自動的 に実行する ❏ データの定期的な復旧を行ってバックアップの完全性とプロセス を確認する ❏ バックアップを保護または暗号化するか、データが安全なソース から複製できることを確認する
- 72. 72(信頼性の柱 紹介の)まとめ ✔可用性を向上させる構成を採用する ✔水平方向へのスケール ✔可用性と拡張に優れたサービスの利用 ✔需要に応じたキャパシティの確保 ✔障害が起こることを前提とした対策を行う ✔ 復旧テスト ✔ 障害から自動復旧する構成
- 76. 76稼働率
- 78. 78稼働率と停止時間 稼働率 停止時間 (年間) 99% 3d 15h 99.9% 8h 45m 99.95% 4h 22m 99.99% 52m 99.999% 5m
- 79. 7999% シナリオ VPC Availability Zone 1 EC2
- 80. 8099% シナリオ • One Region, One AZ, One EC2 • EC2 上にアプリケーションと DB が同居 • データバックアップは S3 へ • EBS スナップショットを日次で取得 • EC2 AutoRecovery を設定 • CloudWatch で死活/リソース監視 → 落ちたら手動復旧
- 81. 8199% シナリオ 想定料金 ・EC2 は Linux on m5.large , 100GB (EBS&snapshot) ・ネットワーク、その他費用は割愛 シナリオ 想定料金(月額) 99% を 100 とした割合 99% $107.77 100 99.9% 99.99% Multi Region 99.999%
- 82. 8299.9% シナリオ VPC Availability Zone 1 EC2 Availability Zone 2 EC2 ALB Aurora Master Aurora Replica Auto Scaling
- 83. 8399.9% シナリオ • One Region, Two Azs • ELB for Web • EC2 は AutoScaling • DB は Multi-AZ Aurora • RDS スナップショットを日次で取得
- 84. 8499.9% シナリオ • アプリは In-place Deployment (自動化) → Rollback を容易にしておく • URL外形監視&CloudWatchで死活/リソース監視 → アプリ障害の復旧はなるべく自動化 → プロセス暴走などはEC2シャットダウン
- 85. 8599.9% シナリオ 想定料金 ・EC2 は2台 Linux on m5.large , 100GB (EBS&snapshot) ・RDS は Aurora MySQL Comp. db.r5.2xlarge ・ALB 100GB/月 転送 ・ネットワーク、その他費用は割愛 シナリオ 想定料金(月額) 99% を 1 とした割合 99% $107.77 1 99.9% $2645.80 25.65 99.99% Multi Region 99.999%
- 86. 8699.99% シナリオ VPC Availability Zone 1 EC2 ALB Aurora Master Availability Zone 2 EC2 Aurora Replica Availability Zone 3 EC2 Aurora Replica CloudFront Auto Scaling
- 87. 8799.99% シナリオ • One Region, Three Azs • ELB for Web • EC2 は AutoScaling → ECS&Fargate も検討 • DB は Multi-AZ Aurora • RDS スナップショットを日次で取得
- 88. 8899.99% シナリオ • CloudFront でコンテンツをキャッシュ → オリジン(EC2) の負荷軽減 → スパイクアクセスに耐える • URL外形監視&CloudWatchで死活/リソース監視 → アプリ障害の復旧はなるべく自動化 → プロセス暴走などはEC2シャットダウン
- 89. 8999.99% シナリオ • アプリは Blue/Green or Canary Deployment → Rollback を半自動 • 運用フロー見直し (緊急対応は事後承認など) → 停止時間を短くするには復旧時間を短くする → 一次復旧は自動化 (Lambda, ShellScriptなど) → それで駄目ならオペレーター作業
- 90. 9099.99% シナリオ 想定料金 ・EC2 は3台 Linux on m5.large , 100GB (EBS&snapshot) ・RDS は Aurora MySQL Comp. db.r5.2xlarge ・CloudFront,ALB 100GB/月 転送 ・ネットワーク、その他費用は割愛 シナリオ 想定料金(月額) 99% を 1 とした割合 99% $107.77 1 99.9% $2645.80 25.65 99.99% $3968.08 36.81 Multi Region 99.999%
- 91. 91Multi Region シナリオ VPC AZ 1 EC2 ALB Aurora Master EC2 Aurora Replica CloudFront Auto Scaling Route 53 AZ 2 VPC AZ 1 EC2 ALB Aurora Replica EC2 Aurora Replica Auto Scaling AZ 2
- 92. 92Mutli Region シナリオ • Two Region, Four Azs • ELB for Web • EC2 は AutoScaling (ECS&Fargate) • Standby Region の EC2 は Stop しておく • DB は Multi-AZ Aurora Cross Region Replica • 日次 AMI コピー (リージョン間) • システム継続に必要なデータはDBに保存
- 93. 93Mutli Region シナリオ • Multi Region が必要ですか？ • リージョン内に複数の AZ があり、 AZ 内には複数のデータセンターがある • 復旧手順、復旧テスト、構成上の制約、 データ保管要件など考えることが多い
- 94. 94Multi Region シナリオ 想定料金 ・EC2 は2台 Linux on m5.large , 100GB (EBS&snapshot) ・RDS は Aurora MySQL Comp. db.r5.2xlarge ・CloudFront,ALB 100GB/月 転送 ・ネットワーク、その他費用は割愛 シナリオ 想定料金(月額) 99% を 1 とした割合 99% $107.77 1 99.9% $2645.80 25.65 99.99% $3968.08 36.81 Multi Region $5143.05 47.72 99.999%
- 95. 95小まとめ 可用性を高めるためには 1. AZ またぎ 2. サーバー (EC2) でなんとかしようとしない AutoScaling、RDS など AWS サービス使う 3. サービス継続に必要なデータを腹持ちしない RDS、DynamoDB、S3、ElastiCache など活用 4. 復旧アクションは自動化、半自動化する
- 96. 96 まとめ
- 98. 98 AWS マネージドサービス使う RDBMS on EC2 → EC2 Application Server on EC2 → ECS&Fargate など
- 100. 100 さいごに
- 101. 101Multi Region シナリオ 想定料金 99.999% がないけど？ シナリオ 想定料金(月額) 99% を 1 とした割合 99% $107.77 1 99.9% $2645.80 25.65 99.99% $3968.08 36.81 Multi Region $5143.05 47.72 99.999%
- 102. 10299.999% VPC AZ 1 EC2 ALB Aurora Master EC2 Aurora Replica CloudFront Auto Scaling Route 53 AZ 2 VPC AZ 1 EC2 ALB Aurora Replica EC2 Aurora Replica Auto Scaling AZ 2 どのようなアーキテクチャに なると思いますか？
- 103. 10399.999% VPC AZ 1 EC2 ALB Aurora Master EC2 Aurora Replica CloudFront Auto Scaling Route 53 AZ 2 VPC AZ 1 EC2 ALB Aurora Replica EC2 Aurora Replica Auto Scaling AZ 2 一緒に PoC しましょう!!!
- 104. 104 Thank you for you attention
- 105. 105