More Related Content
What's hot (20)
Similar to 障害に备えたアーキテクチャを考える (20)
![[CTO Night & Day 2019] よくある課題を一気に解説！御社の技術レベルがアップする 2019 秋期講習 #ctonight](https://cdn.slidesharecdn.com/ss_thumbnails/ctond2019morningsessionstartupzemifall2019-191028200214-thumbnail.jpg?width=560&fit=bounds)
![[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight](https://cdn.slidesharecdn.com/ss_thumbnails/ctond2019morningsessionsecurity-191027185908-thumbnail.jpg?width=560&fit=bounds)
More from Yoshii Ryo (10)
障害に备えたアーキテクチャを考える
- 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