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

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

Transcript

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

   View Slide

2. 本⽇のスピーカー紹介
   2
   こっち
   

   View Slide

3. ビジョン
   

   View Slide

4. サーバーワークスのビジネス概要
   2008年より、AWSに特化したインテグレーション事業を開始。
   世界で20,000社を超えるAWSパートナーから上位0.3%のみが受ける最上
   位資格 ”APN プレミアコンサルティングパートナー” に認定
   4
   AWS導⼊⽀援
   AWS⾃動化ツール
   AWS運⽤サービス
   導⼊コンサルティング
   AWS構築サービス
   24時間365⽇の運⽤代⾏
   有⼈監視・障害対応
   課⾦代⾏サービス
   Cloud Automator
   （運⽤業務⾃動化）
   ⽇本4拠点(+⼦会社1拠点)
   US1拠点
   

   View Slide

5. 770社を超えるAWS導⼊実績
   (2020年1⽉末現在）
   

   View Slide

6. 本題に⼊ります
   6
   

   View Slide

7. 2019.8.23 AWS 東京リージョンにて障害発⽣
   7
   

   View Slide

8. 障害発⽣時の状況
   突如届き始めた、⼤量のEC2インスタンスのAutoRecovery通知
   8
   

   View Slide

9. 障害発⽣時の状況
   どうやらEC2インスタンスが⼤量に落ちたようだ・・・
   9
   

   View Slide

10. 障害発⽣時の状況
    単⼀のAWSアカウントの問題ではなく、AWSの基盤障害の模様
    10
    

    View Slide

11. 障害発⽣時の状況
    障害対応に追われる
    11
    

    View Slide

12. 障害の詳細
    12
    

    View Slide

13. AWSからの障害報告（8/25初版）
    単⼀アベイラビリティゾーンでの障害である
    対象はEC2、及び、EBSである
    EC2 RunInstances APIにおけるエラー率の上昇
    原因としてはAWSのデータセンターの制御に使われるシステムの複合的な障害
    13
    

    View Slide

14. AWSからの障害報告（8/28続報）
    RDS、 Redshift、ElastiCache および WorkSpaces等、EC2を基盤として
    いるサービスについても影響
    複数アベイラビリティゾーンで稼働している⼀部のケースで影響があったこ
    とにも触れられる
    東京リージョン (AP-NORTHEAST-1) で発⽣した Amazon EC2 と Amazon EBS の事象概要
    https://aws.amazon.com/jp/message/56489/
    14
    

    View Slide

15. 実際に体験した障害による影響
    15
    

    View Slide

16. とある運⽤案件にて
    サーバーワークスはAWS環境、EC2インスタンスのOS、ミドルウェアの⼀
    部を担当
    アプリケーションやデータベースについてはお客様、別ベンダーが管理
    レガシーな3層構造（ELB-EC2-RDS 等）のシステムやサーバーレス構成
    （API Gateway-Lambda-DynamoDB 等）のシステムなど様々な環境があ
    り、規模については、EC2で⾔えば、数百台規模の環境を運⽤
    今回は3つの実際に発⽣したケースを紹介
    

    View Slide

17. 冗⻑化してるから⼤丈夫・・・︖
    本番環境は複数アベイラビリティゾーンで冗⻑化されている為、サービスに
    影響はなかった
    ・・・・はずだった
    17
    

    View Slide

18. ケース① アプリケーションのDBの接続先設定の誤り
    RDS Aurora クラスターのフェールオーバーが発⽣
    18
    

    View Slide

19. ケース① アプリケーションのDBの接続先設定の誤り
    アプリケーションのデータベースの接続先にAurora クラスターの中の
    Writerであった特定のDBインスタンスが指定されていた
    アプリケーションのエラーが発⽣
    利⽤していたDNSレコードをクラスターエンドポイントに書き換えることで復
    旧
    インスタンスエンドポイントはフェールオーバーが発⽣しても対象インスタンスのIP
    アドレスを返し続ける
    クラスターエンドポイントはフェールオーバーの際にポイントするIPアドレスがプラ
    イマリのインスタンスに⾃動で切り替わるので、通常はこちらを利⽤する
    19
    

    View Slide

20. ケース② 過去の構築時、設定変更時のミス
    障害を受けたEC2インスタンスの中には、これまでにほぼ停⽌していないよ
    うなものが含まれていたため、過去の設定ミスが炙りだされることになった
    /etc/fstabの記載ミス
    ⇒ディスクマウントがされなかった
    サービス⾃動起動設定の不備
    ⇒必要なサービスが起動せず
    20
    

    View Slide

21. ケース③ プレイスメントグループ
    とあるデータウェアハウス(DWH)のシステムでEC2、3台並列構成
    低レイテンシーを⽬的にクラスタープレイスメントグループを利⽤
    1台のEC2インスタンスに複数のEBSがアタッチされ、Raid 0を組んでいた
    21
    

    View Slide

22. ケース③ プレイスメントグループ
    全台どこかしらのEBSが障害ステータスの状況
    EC2インスタンス3台のうち、2台復旧することが出来れば、システム全体を復
    旧できる
    Raid 0を組んでいたため、1台復旧するためには、Raid構成のEBS全てを復旧す
    る必要があった
    直近のEBSのスナップショットは2017年のものだった
    DWHで停⽌不可のシステムであったため、各インスタンスのバックアップボ
    リュームへのソフトウェアによるバックアップに頼ったリストア計画だった
    もちろんバックアップボリュームも障害ステータス
    スナップショットを取ろうとしても失敗する状況
    22
    

    View Slide

23. 途⽅に暮れるSlackチャンネル
    23
    

    View Slide

24. SHD(ServiceHealthDashboard)の復旧報に殺伐とするSlackチャンネル
    24
    ※Service Health DashboardはAWSのサービスの状態についてお知らせしてくれるダッシュボードです
    

    View Slide

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は特定のリソースの状態についてお知らせしてくれるダッシュボードです
    

    View Slide

26. 結末
    8/24 お昼過ぎに⼀部のEBSのスナップショットが取れるようになる
    EBSのサイズが⼤きかったため、取得に翌⽇までかかった
    8/25 取得したスナップショットからリストアしたEBSをEC2にアタッチ
    3台中2台のEC2インスタンスが復旧でき、システムとしても復旧させることができた
    ⾊々と対応はしたものの、結果としてAWSの復旧頼みであった
    26
    

    View Slide

27. 改めて気づかされたこと
    27
    

    View Slide

28. 改めて気づかされたこと
    AWSといえども障害は起きるので、過信は禁物
    Design for Failureの重要性
    障害は起こるものとして、システムを設計、運⽤しなければならない
    バックアップ超⼤事
    今回のケース③で⾔えば、データボリュームについては難しかったかもしれない
    が、Rootボリューム、及び、バックアップボリュームのSnapshotを書き込みの
    無いタイミングにて取得しておくべきだった
    28
    

    View Slide

29. ここからは、今後どうすれば良いのか
    サーバーレスだったらどうなのか、話していきます
    

    View Slide

30. 本⽇のスピーカー紹介
    30
    こっち
    

    View Slide

31. 今後、どうすれば良いのか
    

    View Slide

32. ビジネス要件の確認
    システムがビジネス要件にマッチしているか
    RPO（⽬標復旧時点）
    バックアップの取得タイミングが適切か
    レプリケーションは必要か
    RTO（⽬標復旧時間）
    レプリケーションやMulti-AZ構成、データの保管先の検討をしていきます
    重要度の低いサービスで過剰な構成はコストの無駄となる
    32
    

    View Slide

33. 既存システムの評価
    AWS Well-Architected Frameworkを元にAWSアーキテクチャのレ
    ビューを実施
    ⽅法としては以下
    AWS Well-Architected Framework Toolの利⽤
    2019/9に⽇本語対応
    AWS Well-Architected パートナー、AWS SAへ相談
    単発での実施ではなく、継続的な改善を⾏っていくことが重要
    33
    

    View Slide

34. バックアップの重要性
    

    View Slide

35. バックアップ⼤事
    運の悪かった⼀部のEBSが壊れました。
    これによって⼀部EC2のステータスが0/2となった
    35
    

    View Slide

36. バックアップが必要なワケ
    EBSは同⼀AZにしかレプリケートされない
    https://aws.amazon.com/jp/ebs/features/
    36
    

    View Slide

37. EBS Snapshot
    AZ障害への対策としてはEBS Snapshotが有効。
    とにかくSnapshotを取りましょう︕︕
    場合によっては別リージョンにコピーする
    37
    

    View Slide

38. Snapshot取得忘れがち、そんなあなたに
    

    View Slide

39. EBS Snapshot作成（AMI作成）のお勧め
    具体的な実現⽅法
    AWS Backup
    AWS提供のバックアップサービス
    2019/7/2に東京リージョンにも対応
    3rd Party Tool
    Cloud Automator（https://cloudautomator.com/ ）
    サーバーワークスが提供するAWSの運⽤を⾃動化するサービス
    EBS Snapshot作成（AMI作成）の定期実⾏するジョブがGUIで可能です
    39
    

    View Slide

40. Multi-AZの重要性
    

    View Slide

41. Multi-AZの重要性
    今回のケースでMulti-AZ構成は⼤きな影響を受けないケースが⼤半
    AutoRecoveryですぐに復旧
    AutoRecoveryでループするも別AZのEC2でサービス継続
    RDSでFailover発⽣するも別AZでサービス継続
    しかし、ダメなケースも
    Multi-AZでもALBでWAFやスティッキーセッションつかった構成
    Single-AZでは負荷に耐えきれなかったケース
    設定ミス、設計時の考慮漏れ
    →マルチリージョン、マルチクラウドという話に
    41
    

    View Slide

42. Multi-AZの重要性
    今回のケースでMulti-AZ構成は⼤きな影響を受けないケースが⼤半
    AutoRecoveryですぐに復旧
    AutoRecoveryでループするも別AZのEC2でサービス継続
    RDSでFailover発⽣するも別AZでサービス継続
    しかし、ダメなケースも。
    Multi-AZでもALBでWAFやスティッキーセッションつかった構成
    Single-AZでは負荷に耐えきれなかったケース
    設定ミス、設計時の考慮漏れ
    →マルチリージョン、マルチクラウドという話に
    42
    

    View Slide

43. マルチリージョン、マルチクラウドの前に
    考慮すべきこと
    

    View Slide

44. EC2をWebサーバとして利⽤している場合
    ELB配置、 EC2はAutoScalingを有効にする
    セッション情報はキャッシュサーバやDBに持たせる
    44
    

    View Slide

45. AZ障害を考慮したインスタンス数
    インスタンス障害のみを考慮したインスタンス台数ではなく、AZも考慮し
    て台数設計を⾏う
    45
    

    View Slide

46. そもそもMulti-AZにできないケース
    オンプレミスからそのまま移⾏したためELBが存在しない
    コールドスタンバイの⽤意
    直近AMIから復旧を⾃動で実施してくれるスクリプトの適⽤
    低レイテンシーが求められる環境
    Amazon RedshiftもSingle-AZサポートのため、移⾏できない。
    プレースメントグループを以下から適切なものを選択する
    クラスター︓⼀番⾼スループット
    パーティション︓EC2インスタンスを論理的なパーティションに配置してパーティ
    ションが異なるインスタンスはハードウェアを共有しない
    スプレット︓EC2インスタンスを別々のハードウェアに分散配置
    46
    

    View Slide

47. RDSのMulti-AZ対応
    基本的にはMulti-AZ配置の有効化を実施
    ライセンスコストも2倍になるのでデーターベースエンジンによっては注意
    スループット向上のためにリードレプリカ作成している場合
    リードレプリカもMulti-AZ化実施する必要あり
    接続先は、エンドポイント指定する
    IPアドレス直指定は、切り替わりしません
    システムリリース前に切り替わりテストの実施は必須
    47
    

    View Slide

48. サーバーレスアーキテクチャ
    

    View Slide

49. サーバーレス構成の有効性
    2019年8⽉23⽇の障害において影響
    49
    https://aws.amazon.com/jp/message/56489/
    

    View Slide

50. サーバーレス構成の有効性
    サーバーレス構成の環境でサービス断となったケースは少なかった
    マネージドサービスを組み合わせたよくあるサーバーレス構成
    API Gateway + Lambda + DynamoDB
    CloudFront + S3
    50
    

    View Slide

51. サーバーレス構成の有効性
    サーバーレス構成の環境でサービス断となったケースは少なかった
    マネージドサービスを組み合わせたよくあるサーバーレス構成
    API Gateway + Lambda + DynamoDB
    CloudFront + S3
    51
    今回のケースでは助かったケースが多かったが
    正解とは⾔いがたい
    

    View Slide

52. 理由
    今回はEC2、EBS周りの障害だった
    Lambda、DynamoDB、CloudFrontでも障害は起きている
    アプリケーションの作りによっては今回も影響があった可能性
    マネージドサービスはコントロール不能になりがち
    復旧対応をAWSさんに任せるしかない
    障害が起きている最中で突発的に構成変更するのが⼤変
    

    View Slide

53. 当時のCloudWatchメトリクス
    障害時間帯にLambdaでErrorが発⽣していた
    53
    

    View Slide

54. サーバーレスで考慮しておくべきこと
    アプリケーション全体で障害が発⽣した際の対処⽅法を⽤意しておく
    サーバーレス = 安全ではないことを理解する
    

    View Slide

55. 最後に
    

    View Slide

56. 最後に
    ビジネス要件にマッチした構成
    構築時点でわからない場合はAWS推奨構成とする
    最後は神頼み
    

    View Slide

57. 最後に
    ビジネス要件にマッチした構成
    構築時点でわからない場合はAWS推奨構成とする
    最後は神頼み
    エンジニアとして
    稼働率100%を追い求める強いハート
    

    View Slide

58. 最後に
    AWS障害に関するホワイトペーパーをダウンロードいただけます
    58
    

    View Slide

59. View Slide