グレー障害に備える〜ベストプラクティスとApplication Recovery Controller Zonal Shift〜

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2024 NTT DATA Corporation 2 自己紹介・名前：川村吏（かわむらつかさ）・所属：株式会社NTTデータ社会基盤ソリューション事業本部・業務： 2015年中ころ～2019年初頭まで：オンプレミス環境(VMware、Xen、Hyper-V等)を中心とした、基盤設計、構築、運用等 2019年初頭～2020年10月：パブリッククラウド(AWS中心、Azureも少し)へのリフト、シフト、新規開発における提案、基盤設計、構築 2020年11月～：NTTデータ社へ中途入社公共機関向けシステムのクラウド移行に関するコンサル、提案、設計、構築など・好きなAWSサービス： S3、CloudFront、Route53 ・趣味：猫、Disney、グラス収集、紅茶、料理、etc…

Slide 3

Slide 3 text

© 2024 NTT DATA Corporation 3 本日お話することもうすぐre:inventということで、一昨年、昨年と連続で発表されたApplication Recovery Controller Zonal Shiftのご紹介と、本機能に密接に関連するグレー障害の概要とグレー障害対応するためのベストプラクティスについて語ります。 ※Application Recovery Controllerの全般的な解説は行いません。 ※グレー障害に対応するための詳細な対応内容は解説しません。

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 2024 NTT DATA Corporation 6 グレー障害とは？ AWS re:Invent 2023 - Detecting and mitigating gray failures (ARC310)にて解説されていました。また、AWS Whitepapers グレー障害の検出と軽減にも説明があります。定義：グレー障害は、視点別のオブザーバビリティという特性によって定義されます。これは、異なるエンティティは異なる視点で障害を観測することを意味します。 https://youtu.be/LzIZ-dEzgEw?si=q8I5cye7A3nuBS6t https://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html

Slide 7

Slide 7 text

© 2024 NTT DATA Corporation 7 グレー障害とは？視点別のオブザーバビリティとは、システムコンシューマーの 1 つがシステムの異常を検出しても、システム自体の監視では問題が検出されないか、影響がアラームのしきい値を超えない状況つまりグレー障害とは、システム全体で見た場合に障害とは定義されず検出されないものの、単体レベルで見た場合になんらかの異常が発生しているグレーな状況 App1が仮に70msに変化しても平均レイテンシは 60msにとどまるため異常検知されないが、App1としては40%レイテンシが上昇することになる

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2024 NTT DATA Corporation 10 グレー障害の例 https://aws.amazon.com/jp/message/56489/ 2019年８月に発生したAWSの障害を覚えていますか？東京リージョンの１AZで冷却システムが停止したことにより、EC2などの複数のサービスに障害が発生した事例ポイントは、個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響が観測されていたこと。 →マルチAZ構成だったとしても、観測異常と判断されず、切り離されないこともある

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© 2024 NTT DATA Corporation 12 Application Recovery Controller Zonal Shiftとは？ • ELBの特定のAZを無効化する機能 • 手動(ゾーンシフト) :re:invent 2022でリリース • 自動(ゾーンオートシフト) :re:invent2023でリリース • アベイラビリティゾーン内のサービスを起因とした、グレー障害、障害時に有効

Slide 13

Slide 13 text

© 2024 NTT DATA Corporation 13 Application Recovery Controller Zonal Shift（手動）とは？ https://aws.amazon.com/jp/blogs/networking-and-content-delivery/rapidly-recover-from-application-failures-in-a-single-az/ Az3をZonalShiftにより切り離す特定のAZの一部のインスタンスやELBなどでエラーレートや遅延が大きい等の場合に、ユーザ側起因でZonalShift により、特定のAZを切り離すことが可能

Slide 14

Slide 14 text

© 2024 NTT DATA Corporation 14 Application Recovery Controller Zonal Shiftとは？実際の動作としては、リージョンのDNS名で名前解決を行った際に指定したAZに紐づくIPアドレスへの名前解決が行われなくなるという動作になる。 Availability Zone A Elastic Load Balancing Availability Zone B Availability Zone C Region xxx.elb.ap-southeast- 2.amazonaws.com ap-southeast-2a.xxxx.elb.ap- southeast-2.amazonaws.com ap-southeast-2b.xxxx.elb.ap- southeast-2.amazonaws.com ap-southeast-2c.xxxx.elb.ap- southeast-2.amazonaws.com ※ゾーンシフト時も名前解決可能 xxx.elb.ap-southeast- 2.amazonaws.com の名前解決を実施通常時 Availability Zone A,B,CのいずれかのIPアドレスを返却ゾーンシフト後指定したAvailabilityZoneCを除外した任意のAvailabilityZoneのいずれかのIPアドレスを返却ゾーンシフトにより除外

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 2024 NTT DATA Corporation 16 Application Recovery Controller Zonal Shift（手動）が有効なケース主にユーザ側（AWS責任外）起因のエラーに有効 • 単一AZでのグレー障害（遅延やエラーレートの上昇など） • グレー障害時の一時的な切り分け操作や調査ケース例モニタリングや複合的なメトリクスによるアラームなどにより、ゾーンシフトをLambda 等で自動的に発動するケース例一時的な切り分けや調査などにより、手動でゾーンシフトを発動する

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2024 NTT DATA Corporation 19 どちらをつかえばいいの？結論：どちらを使えばいいということではなく、ターゲットが違う手動ゾーンシフト：ユーザ側起因のエラーに有効なので、AZごとのエラーレートなどのモニタリングとセットでゾーンシフトを発動するような仕組みを用意しておくと有用ゾーン自動シフト：AWS側起因のエラーに有効なので、これを有効化しただけでは、ユーザ側起因のエラーには対応できない、とはいえ、AWS側起因のエラー時に自動的に発動するため、有効化しておくとよい

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 2024 NTT DATA Corporation 21 ゾーンシフトにおけるベストプラクティスと留意事項 • クロスゾーン負荷分散を無効化している必要がある（ALB） • ゾーンオートシフトを利用するには毎週30分間練習実行が必要 • AZを無効化するので、１AZ分のキャパシティがない状態で動作させても問題ない状態としておく (必要に応じてスケーリング) • 事前のテスト • 切り替えのシナリオを明確にする（可能な場合自動化する） • ユーザから対象リソースへの接続時間を制限する • 切り替えは一時的なものであることを意識し原則としてなるべく早く元の構成にもどす • フェイルオーバーメカニズムにおいてデータプレーンのAPIを利用する（zonal shift actions）

Slide 22

Slide 22 text

© 2024 NTT DATA Corporation 22 グレー障害に備えるためのベストプラクティス • 静的安定性の確保(W-A 信頼性の柱 REL1-BP05) • 障害が発生する前に障害に供えること→障害が発生した場合になにか対応行うのではなく、障害が発生しても継続したサービス提供が可能な状態としておくこと障害境界点の独立性に応じた設計 • 可観測性をもたせること（W−A 信頼性の柱 REL06～REL07） • 障害境界点に応じたメトリクスの取得（視点別のオブザーバビリティの確保） • サーバサイドのモニタリングと、ユーザサイドでのモニタリング • 外れ値によるモニタリング • モニタリングの組み合わせ等によるグレー障害の検出 • 可能な限り内部構造が複雑なコントロールプレーン（リソースの作成更新などサービスの管理機能）ではなく比較的単純なデータプレーン（サービス自体の主要機能）を利用した復旧方法の実装（W−A 信頼性の柱 REL11-BP04） • DNSレコードの追加、変更などDNSレコードの変更、スケーリング操作等のコントロールプレーンに依存した復旧方法ではなく、ARCによるDNSトラフィックのシフトやルーティングポリシー設定などデータプレーンによる復旧方法を設計する • 可能な限り自動化

Slide 23

Slide 23 text

© 2024 NTT DATA Corporation 23 まとめ • システムにおける可用性要件を明確に定義し、備えるべき障害に応じたアーキテクチャを設計すること • システムにおける障害を定義し、観測可能としておくこと • ベストプラクティスに応じて適切な障害復旧方法を設計しておくこと(Zonal Shiftは一例) • 障害を見据えたテストを実施しておくこと • W-Aを定期的に読んでフィードバックすること（W-ARV）

Slide 24

Slide 24 text

© 2024 NTT DATA Corporation 24 参考 • ゾーンシフトとゾーンオートシフトを使用してでアプリケーションを復旧する ARC https://docs.aws.amazon.com/ja_jp/r53recovery/latest/dg/multi-az.html • Rapidly recover from application failures in a single AZ https://aws.amazon.com/jp/blogs/networking-and-content-delivery/rapidly-recover-from- application-failures-in-a-single-az/ • アベイラビリティーゾーンを使用した静的安定性 https://aws.amazon.com/jp/builders-library/static-stability-using-availability-zones/ • AWS re:Invent 2023 - グレー障害の検出と軽減 (ARC310) https://youtu.be/LzIZ-dEzgEw?si=q8I5cye7A3nuBS6t • マルチAZの高度なレジリエンスパターングレー障害の検出と軽減 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/gray- failures.html

Slide 25

Slide 25 text

Thank you!