AWS障害で考えさせられた、 アプリケーションインフラ構成の注意ポイント

Developers Summit 2020 【14-E-1】の登壇スライドとなります。
#devsumiE #devsumi #devsumi2020
https://event.shoeisha.jp/devsumi/20200213/session/2415/

Transcript

1. AWS障害で考えさせられた、 アプリケーションインフラ構成の注意ポイント
2. 本⽇のスピーカー紹介 2 こっち
3. ビジョン
4. サーバーワークスのビジネス概要 2008年より、AWSに特化したインテグレーション事業を開始。 世界で20,000社を超えるAWSパートナーから上位0.3%のみが受ける最上 位資格 ”APN プレミアコンサルティングパートナー” に認定 4 AWS導⼊⽀援 AWS⾃動化ツール AWS運⽤サービス 導⼊コンサルティング AWS構築サービス 24時間365⽇の運⽤代⾏ 有⼈監視・障害対応 課⾦代⾏サービス Cloud Automator （運⽤業務⾃動化） ⽇本4拠点(+⼦会社1拠点) US1拠点
5. 770社を超えるAWS導⼊実績 (2020年1⽉末現在）
6. 本題に⼊ります 6
7. 2019.8.23 AWS 東京リージョンにて障害発⽣ 7
8. 障害発⽣時の状況 突如届き始めた、⼤量のEC2インスタンスのAutoRecovery通知 8
9. 障害発⽣時の状況 どうやらEC2インスタンスが⼤量に落ちたようだ・・・ 9
10. 障害発⽣時の状況 単⼀のAWSアカウントの問題ではなく、AWSの基盤障害の模様 10
11. 障害発⽣時の状況 障害対応に追われる 11
12. 障害の詳細 12
13. AWSからの障害報告（8/25初版） 単⼀アベイラビリティゾーンでの障害である 対象はEC2、及び、EBSである EC2 RunInstances APIにおけるエラー率の上昇 原因としてはAWSのデータセンターの制御に使われるシステムの複合的な障害 13
14. AWSからの障害報告（8/28続報） RDS、 Redshift、ElastiCache および WorkSpaces等、EC2を基盤として いるサービスについても影響 複数アベイラビリティゾーンで稼働している⼀部のケースで影響があったこ とにも触れられる 東京リージョン (AP-NORTHEAST-1) で発⽣した Amazon EC2 と Amazon EBS の事象概要 https://aws.amazon.com/jp/message/56489/ 14
15. 実際に体験した障害による影響 15
16. とある運⽤案件にて サーバーワークスはAWS環境、EC2インスタンスのOS、ミドルウェアの⼀ 部を担当 アプリケーションやデータベースについてはお客様、別ベンダーが管理 レガシーな3層構造（ELB-EC2-RDS 等）のシステムやサーバーレス構成 （API Gateway-Lambda-DynamoDB 等）のシステムなど様々な環境があ り、規模については、EC2で⾔えば、数百台規模の環境を運⽤ 今回は3つの実際に発⽣したケースを紹介
17. 冗⻑化してるから⼤丈夫・・・︖ 本番環境は複数アベイラビリティゾーンで冗⻑化されている為、サービスに 影響はなかった ・・・・はずだった 17
18. ケース① アプリケーションのDBの接続先設定の誤り RDS Aurora クラスターのフェールオーバーが発⽣ 18
19. ケース① アプリケーションのDBの接続先設定の誤り アプリケーションのデータベースの接続先にAurora クラスターの中の Writerであった特定のDBインスタンスが指定されていた アプリケーションのエラーが発⽣ 利⽤していたDNSレコードをクラスターエンドポイントに書き換えることで復 旧 インスタンスエンドポイントはフェールオーバーが発⽣しても対象インスタンスのIP アドレスを返し続ける クラスターエンドポイントはフェールオーバーの際にポイントするIPアドレスがプラ イマリのインスタンスに⾃動で切り替わるので、通常はこちらを利⽤する 19
20. ケース② 過去の構築時、設定変更時のミス 障害を受けたEC2インスタンスの中には、これまでにほぼ停⽌していないよ うなものが含まれていたため、過去の設定ミスが炙りだされることになった /etc/fstabの記載ミス ⇒ディスクマウントがされなかった サービス⾃動起動設定の不備 ⇒必要なサービスが起動せず 20
21. ケース③ プレイスメントグループ とあるデータウェアハウス(DWH)のシステムでEC2、3台並列構成 低レイテンシーを⽬的にクラスタープレイスメントグループを利⽤ 1台のEC2インスタンスに複数のEBSがアタッチされ、Raid 0を組んでいた 21
22. ケース③ プレイスメントグループ 全台どこかしらのEBSが障害ステータスの状況 EC2インスタンス3台のうち、2台復旧することが出来れば、システム全体を復 旧できる Raid 0を組んでいたため、1台復旧するためには、Raid構成のEBS全てを復旧す る必要があった 直近のEBSのスナップショットは2017年のものだった DWHで停⽌不可のシステムであったため、各インスタンスのバックアップボ リュームへのソフトウェアによるバックアップに頼ったリストア計画だった もちろんバックアップボリュームも障害ステータス スナップショットを取ろうとしても失敗する状況 22
23. 途⽅に暮れるSlackチャンネル 23
24. SHD(ServiceHealthDashboard)の復旧報に殺伐とするSlackチャンネル 24 ※Service Health DashboardはAWSのサービスの状態についてお知らせしてくれるダッシュボードです
25. 翌⽇へ持ち越し Service Health Dashboardの復旧報はあったものの、取り残される ⼀部はEBSの障害としてPersonal Health Dashboardに記載 On August 22 we experienced a cooling failure in a single Availability Zone in the Tokyo (AP- NORTHEAST-1) Region, which has caused one or more of your volumes listed in the 'Affected Resources' tab, to be inaccessible. The cooling failure resulted in hardware failure on one or more storage servers that store your volume(s). We are working to resolve the hardware failures; however, if you have the ability to restore your volume(s) from a recent スナップショット, we recommend that you do so. Given the nature of the hardware failures, we anticipate that recovery will be prolonged as we work to replace the failed components in the affected servers. 訳）8⽉22⽇、東京（AP-NORTHEAST-1）リージョンの単⼀のアベイラビリティーゾーンで冷却障害が発⽣ し、「影響を受けるリソース」タブにリストされている1つ以上のボリュームにアクセスできなくなりました。 冷却障害により、ボリュームを保存する1つ以上のストレージサーバーでハードウェア障害が発⽣しました。 ハードウェア障害の解決に取り組んでいます。 ただし、最新のスナップショットからボリュームを復元できる 場合は、復元することをお勧めします。 ハードウェア障害の性質を考えると、影響を受けるサーバーの障害の あるコンポーネントを交換するために作業するため、復旧が⻑くなることが予想されます。 25 ※Personal Health Dashboardは特定のリソースの状態についてお知らせしてくれるダッシュボードです
26. 結末 8/24 お昼過ぎに⼀部のEBSのスナップショットが取れるようになる EBSのサイズが⼤きかったため、取得に翌⽇までかかった 8/25 取得したスナップショットからリストアしたEBSをEC2にアタッチ 3台中2台のEC2インスタンスが復旧でき、システムとしても復旧させることができた ⾊々と対応はしたものの、結果としてAWSの復旧頼みであった 26
27. 改めて気づかされたこと 27
28. 改めて気づかされたこと AWSといえども障害は起きるので、過信は禁物 Design for Failureの重要性 障害は起こるものとして、システムを設計、運⽤しなければならない バックアップ超⼤事 今回のケース③で⾔えば、データボリュームについては難しかったかもしれない が、Rootボリューム、及び、バックアップボリュームのSnapshotを書き込みの 無いタイミングにて取得しておくべきだった 28
29. ここからは、今後どうすれば良いのか サーバーレスだったらどうなのか、話していきます
30. 本⽇のスピーカー紹介 30 こっち
31. 今後、どうすれば良いのか
32. ビジネス要件の確認 システムがビジネス要件にマッチしているか RPO（⽬標復旧時点） バックアップの取得タイミングが適切か レプリケーションは必要か RTO（⽬標復旧時間） レプリケーションやMulti-AZ構成、データの保管先の検討をしていきます 重要度の低いサービスで過剰な構成はコストの無駄となる 32
33. 既存システムの評価 AWS Well-Architected Frameworkを元にAWSアーキテクチャのレ ビューを実施 ⽅法としては以下 AWS Well-Architected Framework Toolの利⽤ 2019/9に⽇本語対応 AWS Well-Architected パートナー、AWS SAへ相談 単発での実施ではなく、継続的な改善を⾏っていくことが重要 33
34. バックアップの重要性
35. バックアップ⼤事 運の悪かった⼀部のEBSが壊れました。 これによって⼀部EC2のステータスが0/2となった 35
36. バックアップが必要なワケ EBSは同⼀AZにしかレプリケートされない https://aws.amazon.com/jp/ebs/features/ 36
37. EBS Snapshot AZ障害への対策としてはEBS Snapshotが有効。 とにかくSnapshotを取りましょう︕︕ 場合によっては別リージョンにコピーする 37
38. Snapshot取得忘れがち、そんなあなたに
39. EBS Snapshot作成（AMI作成）のお勧め 具体的な実現⽅法 AWS Backup AWS提供のバックアップサービス 2019/7/2に東京リージョンにも対応 3rd Party Tool Cloud Automator（https://cloudautomator.com/ ） サーバーワークスが提供するAWSの運⽤を⾃動化するサービス EBS Snapshot作成（AMI作成）の定期実⾏するジョブがGUIで可能です 39
40. Multi-AZの重要性
41. Multi-AZの重要性 今回のケースでMulti-AZ構成は⼤きな影響を受けないケースが⼤半 AutoRecoveryですぐに復旧 AutoRecoveryでループするも別AZのEC2でサービス継続 RDSでFailover発⽣するも別AZでサービス継続 しかし、ダメなケースも Multi-AZでもALBでWAFやスティッキーセッションつかった構成 Single-AZでは負荷に耐えきれなかったケース 設定ミス、設計時の考慮漏れ →マルチリージョン、マルチクラウドという話に 41
42. Multi-AZの重要性 今回のケースでMulti-AZ構成は⼤きな影響を受けないケースが⼤半 AutoRecoveryですぐに復旧 AutoRecoveryでループするも別AZのEC2でサービス継続 RDSでFailover発⽣するも別AZでサービス継続 しかし、ダメなケースも。 Multi-AZでもALBでWAFやスティッキーセッションつかった構成 Single-AZでは負荷に耐えきれなかったケース 設定ミス、設計時の考慮漏れ →マルチリージョン、マルチクラウドという話に 42
43. マルチリージョン、マルチクラウドの前に 考慮すべきこと
44. EC2をWebサーバとして利⽤している場合 ELB配置、 EC2はAutoScalingを有効にする セッション情報はキャッシュサーバやDBに持たせる 44
45. AZ障害を考慮したインスタンス数 インスタンス障害のみを考慮したインスタンス台数ではなく、AZも考慮し て台数設計を⾏う 45
46. そもそもMulti-AZにできないケース オンプレミスからそのまま移⾏したためELBが存在しない コールドスタンバイの⽤意 直近AMIから復旧を⾃動で実施してくれるスクリプトの適⽤ 低レイテンシーが求められる環境 Amazon RedshiftもSingle-AZサポートのため、移⾏できない。 プレースメントグループを以下から適切なものを選択する クラスター︓⼀番⾼スループット パーティション︓EC2インスタンスを論理的なパーティションに配置してパーティ ションが異なるインスタンスはハードウェアを共有しない スプレット︓EC2インスタンスを別々のハードウェアに分散配置 46
47. RDSのMulti-AZ対応 基本的にはMulti-AZ配置の有効化を実施 ライセンスコストも2倍になるのでデーターベースエンジンによっては注意 スループット向上のためにリードレプリカ作成している場合 リードレプリカもMulti-AZ化実施する必要あり 接続先は、エンドポイント指定する IPアドレス直指定は、切り替わりしません システムリリース前に切り替わりテストの実施は必須 47
48. サーバーレスアーキテクチャ
49. サーバーレス構成の有効性 2019年8⽉23⽇の障害において影響 49 https://aws.amazon.com/jp/message/56489/
50. サーバーレス構成の有効性 サーバーレス構成の環境でサービス断となったケースは少なかった マネージドサービスを組み合わせたよくあるサーバーレス構成 API Gateway + Lambda + DynamoDB CloudFront + S3 50
51. サーバーレス構成の有効性 サーバーレス構成の環境でサービス断となったケースは少なかった マネージドサービスを組み合わせたよくあるサーバーレス構成 API Gateway + Lambda + DynamoDB CloudFront + S3 51 今回のケースでは助かったケースが多かったが 正解とは⾔いがたい
52. 理由 今回はEC2、EBS周りの障害だった Lambda、DynamoDB、CloudFrontでも障害は起きている アプリケーションの作りによっては今回も影響があった可能性 マネージドサービスはコントロール不能になりがち 復旧対応をAWSさんに任せるしかない 障害が起きている最中で突発的に構成変更するのが⼤変
53. 当時のCloudWatchメトリクス 障害時間帯にLambdaでErrorが発⽣していた 53
54. サーバーレスで考慮しておくべきこと アプリケーション全体で障害が発⽣した際の対処⽅法を⽤意しておく サーバーレス = 安全ではないことを理解する
55. 最後に
56. 最後に ビジネス要件にマッチした構成 構築時点でわからない場合はAWS推奨構成とする 最後は神頼み
57. 最後に ビジネス要件にマッチした構成 構築時点でわからない場合はAWS推奨構成とする 最後は神頼み エンジニアとして 稼働率100%を追い求める強いハート
58. 最後に AWS障害に関するホワイトペーパーをダウンロードいただけます 58