サービス停止を防ぐAWS 活用術 : コンテナワークロードにおける 高可用性設計の実践

AWS Summit 2025の登壇資料

AWS-38:
サービス停止を防ぐAWS 活用術 : コンテナワークロードにおける高可用性設計の実践
動画：https://www.youtube.com/watch?v=uGpbR388GPE

Transcript

1. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. サービス停⽌を防ぐAWS 活⽤術 : コンテナワークロードにおける ⾼可⽤性設計の実践 堀内 保⼤ A W S - 3 8 アマゾン ウェブ サービス ジャパン合同会社 ストラテジックインダストリ技術本部, デジタルソリューション部 シニアソリューションアーキテクト
2. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾃⼰紹介 2 堀内 保⼤ (Yasuhiro Horiuchi) AWS シニアソリューションアーキテクト • 主に⼤規模 E コマース、決済関連のお客様を担当 • コンテナ技術⽀援や登壇 バックグラウンド • SIer でシステムへの性能関連の技術⽀援 （性能試験、監視、チューニング、⾮機能設計 etc.） 好きなAWSサービス • Amazon Elastic Kubernetes Service (Amazon EKS) @ka_shino_ki horiuyas@amazon.co.jp
3. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 本セッションの対象者とゴール 想定聴講者 § コンテナワークロードにおいてマイクロサービスを実装している/予定 § ⾃⾝のアーキテクチャの可⽤性設計改善に取組みたい ゴール § トレードオフを理解したうえで⾼可⽤性設計のパターンを理解する § ⾃⾝のアーキテクチャの可⽤性改善に取り組むことができる 3
4. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. アジェンダ 1. 障害の定義 2. 可⽤性設計の検討ポイント 3. 障害シナリオ 4. まとめ
5. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Photo by Guido van Nispen / CC BY 2.0 Werner Vogels VP and CTO, Amazon.com “Everything fails, all the time.”
6. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾼可⽤性と災害対策 (DR) 発⽣確率 影響 Low High High Rare ⾼可⽤性設計 (HA) のスコープ 災害対策 (DR) のスコープ 運⽤エラー/ デプロイミス ⾼負荷 コンポーネント ホスト障害 ネットワーク断絶 ラック障害 データセンター 障害 インターネット 障害 ⼤規模災害 全プロバイダー 障害 6
7. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. グレー障害 • 完全な停⽌ではなく、散発的 or 部分的な劣化 • 観測箇所によって⾒え⽅が異なる特徴を有する → システムレベルでのヘルスチェックで検出が難しく、 外形監視にて SLO が劣化していないかを確認することが重要 healthy healthy ALL GOOD MASKED FAILURE GRAY FAILURE DETECTED FAILURE unhealthy unhealthy 顧客側の認識 システム側の認識 例 • インスタンスの⼀部で起動障害 • 断続的なパケットロスや接続障害 • 部分的な DNS ルックアップの障害 • ボリュームのディスクレイテンシー劣化 https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html 7
8. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 可⽤性の⽬標とトレードオフ • 復旧時間 (MTTR) を短縮化し、 障害間隔 (MTBF) を⻑期化する • 定量的にコントロールできるのは MTTR →いかに障害が発⽣した際に⾼速に復旧するか • ⾼い可⽤性実現にはトレードオフが必要 § コスト § ⼯数 § 複雑性 https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/resilience-analysis-framework/tradeoffs.html 8
9. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 可⽤性設計の検討ポイント
10. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾼可⽤性に向けた設計検討ポイント 1. 耐障害性 a. 冗⻑化 b. 通信の信頼性 • ⾼速な切り離し︓ヘルスチェック、サーキットブレーカー • 瞬断の軽減︓リトライとタイムアウト 2. 障害分離 a. AZ 独⽴性 b. AZ 退避 10
11. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾼可⽤性に向けた設計検討ポイント 1. 耐障害性 a. 冗⻑化 b. 通信の信頼性 • ⾼速な切り離し︓ヘルスチェック、サーキットブレーカー • 瞬断の軽減︓リトライとタイムアウト 2. 障害分離 a. AZ 独⽴性 b. AZ 退避 11
12. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 • 複数の独⽴したコンポーネントを⽤意すること で可⽤性の向上が可能 • (100%-99.00%)3 = 99.9999% • 障害コンポーネントの回避/切り離しても 処理継続が可能 Amazon ECS Container Container Container 12
13. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 • 複数の独⽴したコンポーネントを⽤意すること で可⽤性の向上が可能 • (100%-99.00%)3 = 99.9999% • 障害コンポーネントの回避/切り離しても 処理継続が可能 • 考慮事項 • 配置戦略を障害影響が及ばない境界を意識 することで、範囲障害の影響を軽減できる • ※障害分離境界︓ E.g. インスタンス、AZ、リージョン Amazon ECS Container Container Container 13
14. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 • 複数の独⽴したコンポーネントを⽤意すること で可⽤性の向上が可能 • (100%-99.00%)3 = 99.9999% • 障害コンポーネントの回避/切り離しても 処理継続が可能 • 考慮事項 • 配置戦略を障害影響が及ばない境界を意識 することで、範囲障害の影響を軽減できる • ※障害分離境界︓ E.g. インスタンス、AZ、リージョン Amazon ECS Container Container Container AZ-1 AZ-2 14
15. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 • 複数の独⽴したコンポーネントを⽤意すること で可⽤性の向上が可能 • (100%-99.00%)3 = 99.9999% • 障害コンポーネントの回避/切り離しても 処理継続が可能 • 考慮事項 • 配置戦略を障害影響が及ばない境界を意識 することで、範囲障害の影響を軽減できる • ※障害分離境界︓ E.g. インスタンス、AZ、リージョン Amazon ECS Container Container Container AZ-1 AZ-2 AZ 範囲障害時、 複数インスタンスで同時に 障害が発⽣する可能性 15
16. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Instance Instance Instance 1. 耐障害性 a. 冗⻑化 – マルチ AZ 冗⻑化 • マルチ AZ に分散された、複数台のインスタンス にコンテナをデプロイすることで、 範囲障害影響を軽減 Container Container Container AZ-1 AZ-3 Amazon ECS AZ-2 16
17. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 - マルチ AZ 冗⻑化 の実装 • コンテナの AZ 分散配置 • インスタンスの AZ 分散配置 17
18. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 - マルチ AZ 冗⻑化 の実装 • コンテナの AZ 分散配置 • Amazon ECS : タスク配置戦略 • 不均衡状態の再配置︓ availabilityZoneRebalancing • Amazon EKS : Pod Topology Spread Constraints • 不均衡状態の再配置︓ Deschedular, Consolidation & Node TTL • ※ Fargate であれば AZ を複数指定でデフォルト分散 • インスタンスの AZ 分散配置 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement.html https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/ https://github.com/kubernetes-sigs/descheduler 18
19. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 - マルチ AZ 冗⻑化 の実装 • コンテナの AZ 分散配置 • インスタンスの AZ 分散配置 • Amazon EC2 Auto Scaling : Auto Scaling Group にて AZ 戦略を設定 • インスタンススケーリング時に指定 AZ で均等に配置 • Amazon EKS Auto Mode, Karpenter : デフォルトで AZ 分散 • Pod の配置戦略に合わせて、インスタンスを AZ に起動 ASG Capacity Provider Managed Node Group / Cluster Autoscaler Auto Mode EC2 Fleet ASG でスケール時に AZ 分散 Pod 配置戦略に沿って AZ に インスタンスを起動 https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/ec2-auto-scaling-availability-zone-balanced.html 19
20. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 – マルチ AZ 冗⻑化 • 考慮事項 • グレー障害のような検知が難しい障害で AZ 障害が伝搬する可能性がある （サービス間通信があり、 サービス単位で切離しができなかった場合） Instance Instance Instance Container Container Container AZ-1 AZ-3 Amazon ECS AZ-2 Container Container Container 20
21. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Instance Instance Instance Container Container Container AZ-1 AZ-3 Amazon ECS AZ-2 Container Container Container 1. 耐障害性 a. 冗⻑化 – マルチ AZ 冗⻑化 • 考慮事項 • グレー障害のような検知が難しい障害で AZ 障害が伝搬する可能性がある （サービス間通信があり、 サービス単位で切離しができなかった場合） 21
22. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Instance Instance Instance Container Container Container AZ-1 AZ-3 Amazon ECS AZ-2 Container Container Container 1. 耐障害性 a. 冗⻑化 – マルチ AZ 冗⻑化 • 考慮事項 • グレー障害のような検知が難しい障害で AZ 障害が伝搬する可能性がある （サービス間通信があり、 サービス単位で切離しができなかった場合） 22
23. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Instance Instance Instance Container Container Container AZ-1 AZ-3 Amazon ECS AZ-2 Container Container Container 1. 耐障害性 a. 冗⻑化 – マルチ AZ 冗⻑化 • 考慮事項 • グレー障害のような検知が難しい障害で AZ 障害が伝搬する可能性がある （サービス間通信があり、 サービス単位で切離しができなかった場合） → 障害分離にて対応する（後述） 23
24. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. [再掲] ⾼可⽤性に向けた設計検討ポイント 1. 耐障害性 a. 冗⻑化 b. 通信の信頼性 • ⾼速な切り離し︓ヘルスチェック、サーキットブレーカー • 瞬断の軽減︓リトライとタイムアウト 2. 障害分離 a. AZ 独⽴性 b. AZ 退避 24
25. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 b.通信の信頼性 NW のエラーや、呼出先の不具合 に対する耐障害性の仕組み • 呼び出し先サービスの正常性確認 →ヘルスチェック • 継続した呼び出しの失敗 →サーキットブレーカー • ⼀時的な呼び出しの失敗 →リトライ（Exponential back-off） • 呼出先サービスのパフォーマンス悪化 →タイムアウト 呼出元サービス 呼出先サービス 25
26. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. コンテナ ヘルスチェック 2. Service Discovery ヘルスチェック 3. ロードバランサー ヘルスチェック 1. 耐障害性 b.通信の信頼性 - ヘルスチェックのレベル Query Service Discovery Target [1] https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_healthcheck [2] https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ [3] https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-discovery.html [4] https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group-health-checks.html 26
27. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. コンテナ ヘルスチェック 2. Service Discovery ヘルスチェック 3. ロードバランサー ヘルスチェック 1. 耐障害性 b.通信の信頼性 - ヘルスチェックのレベル Query Service Discovery Target [1] https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_healthcheck [2] https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ [3] https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-discovery.html [4] https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group-health-checks.html 1. コンテナレイヤヘルスチェック 失敗すると終了 →故障時のコンテナの置き換え *Amazon ECS : タスク定義で設定 *Amazon EKS : Liveness Probe 27
28. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. コンテナ ヘルスチェック 2. Service Discovery ヘルスチェック § 異常を検知するとサービス間の Service Discovery から除外 3. ロードバランサー ヘルスチェック 1. 耐障害性 b.通信の信頼性 - ヘルスチェックのレベル Query Service Discovery Target [1] https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_healthcheck [2] https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ [3] https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-discovery.html [4] https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group-health-checks.html 2. Service Discovery へルスチェック 1 が失敗するとサービス間通信からも除外 →⼀時的な不健全への対応 *Amazon ECS : タスク定義のヘルスチェックに基づいて Service Discovery にて除外[3] *Amazon EKS : Readiness Probe[2] 28
29. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. コンテナ ヘルスチェック 2. Service Discovery ヘルスチェック 3. ロードバランサー ヘルスチェック § 異常を検知するとロードバランサーのターゲットから除外 1. 耐障害性 b.通信の信頼性 - ヘルスチェックのレベル Query Service Discovery Target [1] https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_healthcheck [2] https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ [3] https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-discovery.html [4] https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group-health-checks.html 3. ロードバランサー へルスチェック 失敗すると LB のターゲットから除外 *Application Load Balancer のヘルスチェックで設定 29
30. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 b.通信の信頼性 - サーキットブレーカー 呼出元サービス 呼出先サービス App コンテナ プロキシ Envoy タスク / Pod タスク / Pod タスク / Pod サービス サービス タスク / Pod 5xx エラー ←継続的にエラー クライアントサイド ロードバランシングにおいて、 リクエストエラーが連続した場合、ルーティングから⼀定期間除外 サービスメッシュでのイメージ 30
31. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 b.通信の信頼性 - サーキットブレーカー 呼出元サービス 呼出先サービス App コンテナ プロキシ タスク / Pod タスク / Pod タスク / Pod サービス サービス タスク / Pod 5xx エラー ←継続的にエラー 連続してエラーが返る場合、 ⼀次的にルーティングから外す クライアントサイド ロードバランシングにおいて、 リクエストエラーが連続した場合、ルーティングから⼀定期間除外 サービスメッシュでのイメージ Envoy 31
32. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 b.通信の信頼性 - サーキットブレーカー 実装例 1. サービスメッシュを利⽤ 2. ライブラリ (E.g. resilience4j) を利⽤ https://github.com/resilience4j/resilience4j https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker.html 32
33. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 b.通信の信頼性 - サーキットブレーカー 実装例 1. サービスメッシュを利⽤ 2. ライブラリ (E.g. resilience4j) を利⽤ https://speakerdeck.com/kashinoki38/ecs-service-connect-de-ecs-shang-nomaikurosabisunonai-zhang-hai-xing-toke-guan-ce-xing-wogao-meyou?slide=25 https://aws.amazon.com/jp/blogs/containers/transforming-istio-into-an-enterprise-ready-service-mesh-for-amazon-ecs/ https://aws.amazon.com/jp/blogs/opensource/getting-started-with-istio-on-amazon-eks/ https://catalog.us-east-1.prod.workshops.aws/workshops/a0193a6a-70c1-45e2-91e2-879852adb0d0/ja-JP https://github.com/aws-samples/istio-on-eks https://aws.amazon.com/jp/blogs/opensource/getting-started-with-cilium-service-mesh-on-amazon-eks/ https://github.com/aws-samples/cilium-service-mesh-on-eks • ECS Service Connect • Istio • Cilium 33
34. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 b.通信の信頼性 - サーキットブレーカー 実装例 1. サービスメッシュを利⽤ 2. ライブラリ (E.g. resilience4j) を利⽤ • ECS Service Connect • Istio • Cilium 34 https://speakerdeck.com/kashinoki38/ecs-service-connect-de-ecs-shang-nomaikurosabisunonai-zhang-hai-xing-toke-guan-ce- xing-wogao-meyou
35. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 b.通信の信頼性 - リトライ / タイムアウト 呼出元サービス 呼出先サービス App コンテナ タスク / Pod タスク / Pod タスク / Pod タスク / Pod 到達不可 or しきい値超え ⾃動リトライ • NW 障害や 503 エラー時にリトライ • レイテンシがしきい値超え時にタイムアウト https://aws.amazon.com/jp/builders-library/timeouts-retries-and-backoff-with-jitter/ ←突如ダウン or レイテンシ劣化 35
36. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. [再掲] ⾼可⽤性に向けた設計検討ポイント 1. 耐障害性 a. 冗⻑化 b. 通信の信頼性 • ⾼速な切り離し︓ヘルスチェック、サーキットブレーカー • 瞬断の軽減︓リトライとタイムアウト 2. 障害分離 a. AZ 独⽴性 b. AZ 退避 36
37. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 グレー障害が発⽣すると原因の特定まで時間がかかるため、 早期に障害範囲を切り離すことで復旧速度を早める E.g. 散発的なエラー、レイテンシの劣化 障害を独⽴させ、退避する 37 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/availability-zone- evacuation-patterns.html
38. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 • 障害分離境界により範囲障害の影響を軽減する E.g. インスタンス、AZ 、リージョン →AZ 独⽴性 • 早期に障害範囲を切り離す E.g. 散発的なエラー、レイテンシの劣化 →AZ 退避 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/availability-zone- evacuation-patterns.html 障害を独⽴させ、退避する 38
39. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 a. AZ 独⽴性 Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container トラフィックを AZ 内に閉じる事で、 障害を分離する ※プライマリ DB 接続等、必要な場合を除く https://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/availability-zone-independence.html https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 39
40. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 a. AZ 独⽴性 Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container https://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/availability-zone-independence.html https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html AWS Cloud Map Primary DB Reader DB Reader DB Reader DB サービス間通信が発⽣する状況で、 AZ 障害時の回避可能性が⾼い フロント切離しで AZ 退避(後述)が可能 トラフィックを AZ 内に閉じる事で、 障害を分離する ※プライマリ DB 接続等、必要な場合を除く 40
41. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 a. AZ 独⽴性 コンテナ上でのサービス間通信 • Amazon ECS § ECS Service を AZ 単位で作成 →明⽰的な AZ 指定ルーティング ※現状 ECS Service 間の通信を AZ に閉じる機能はない • Amazon EKS § Topology Aware Routing や trafficDistribution で、トラフィックを AZ に閉じることが可能 ※ベストエフォート Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 41
42. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 a. AZ 独⽴性 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/advanced-multi-az-resilience-patterns/availability-zone-independence.html https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB AZ 毎の DB 接続点は、 AWS Cloud Map 等で管理が必要 Elastic Load Balancing では クロスゾーン負荷分散無効化が可能 42
43. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 特定のAZでの劣化を判断したら、 原因究明/解決までトラフィック を⽌め、⾼速に復旧する Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 43
44. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 特定のAZでの劣化を判断したら、 原因究明/解決までトラフィック を⽌め、⾼速に復旧する Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 退避 44
45. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 – 静的安定性を考慮した退避が重要 • 静的安定性とは § 依存先に障害が発⽣しても、 追加の変更を加える必要がなく、通常どおり動作し続ける状態 45
46. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 – 静的安定性を考慮した退避が重要 • 静的安定性とは § 依存先に障害が発⽣しても、 追加の変更を加える必要がなく、通常どおり動作し続ける状態 1. 新規のリソースは可能な限り作成しない → 事前プロビジョニング 50% 50% 50% Availability Zone A Availability Zone B Availability Zone C 46
47. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 – 静的安定性を考慮した退避が重要 • 静的安定性とは § 依存先に障害が発⽣しても、 追加の変更を加える必要がなく、通常どおり動作し続ける状態 1. 新規のリソースは可能な限り作成しない → 事前プロビジョニング 2. コントロールプレーンに依存しない → 分散されたデータプレーンにてフェイルオーバーを⾏う ※コントロールプレーンのほうが複雑で統計的に障害確率が⼤きい 47
48. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 - Application Recovery Controller • マルチリージョン/マルチ AZ アプリケーションの リカバリを簡素化するサービス • ゾーンシフト 機能 • ⼿動/⾃動で特定 AZ 退避を実⾏ • 退避に利⽤可能なサービスと連携し退避 • Amazon Route53, ELB, Amazon EKS 等 との連携が可能 48
49. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Application Load Balancer / Network Load Balancer との連携 • クロスゾーン負荷分散が有効な ALB も利⽤ 可能（2024/11/22 updated) https://aws.amazon.com/jp/blogs/news/using-cross-zone-load- balancing-with-zonal-shift/ 2. 障害分離 b. AZ 退避 - Application Recovery Controller - ゾーンシフト 49
50. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. シフト時の挙動 https://aws.amazon.com/jp/blogs/news/using-cross-zone-load- balancing-with-zonal-shift/ 2. 障害分離 b. AZ 退避 - Application Recovery Controller - ゾーンシフト 初期状態 50
51. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. https://aws.amazon.com/jp/blogs/news/using-cross-zone-load- balancing-with-zonal-shift/ 2. 障害分離 b. AZ 退避 - Application Recovery Controller - ゾーンシフト 特定 AZ の ALB への ルーティングを退避 シフト時の挙動 1. 障害が発⽣した AZ の IP アドレスを DNS から削除（データプレーン動作） 2. 障害が発⽣した AZ のターゲットへの すべてのトラフィックをブロック シフト状態 51
52. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. https://aws.amazon.com/jp/blogs/news/using-cross-zone-load- balancing-with-zonal-shift/ 特定 AZ の ALB ターゲットを削除 2. 障害分離 b. AZ 退避 - Application Recovery Controller - ゾーンシフト シフト時の挙動 1. 障害が発⽣した AZ の IP アドレスを DNS から削除（データプレーン動作） 2. 障害が発⽣した AZ のターゲットへの すべてのトラフィックをブロック 52 シフト状態
53. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon EKS との連携 • 影響を受けた AZ の • 関連する EndpointSlice から Pod エンドポイントを削除 → トラフィック • すべてのノードで Pod をスケジューリングブロック ※Karpenter, Auto Mode はカバーされていない ※Pod, ノードは終了しない(復旧時のため) https://aws.amazon.com/jp/about-aws/whats-new/2024/10/amazon-eks- application-recovery-controller-arc/ 2. 障害分離 b. AZ 退避 - Application Recovery Controller - ゾーンシフト → コンピュート Container Container Container AZ-1 AZ-3 Amazon EKS AZ-2 Container Container Container 53 退避
54. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon EKS との連携 • 影響を受けた AZ の • 関連する EndpointSlice から Pod エンドポイントを削除 → トラフィック • すべてのノードで Pod をスケジューリングブロック ※Karpenter, Auto Mode はカバーされていない ※Pod, ノードは終了しない(復旧時のため) https://aws.amazon.com/jp/about-aws/whats-new/2024/10/amazon-eks- application-recovery-controller-arc/ 2. 障害分離 b. AZ 退避 - Application Recovery Controller - ゾーンシフト → コンピュート Container Container Container AZ-1 AZ-3 Amazon EKS AZ-2 Container Container Container 影響を受けた AZ 上の Pod へのルーティングを回避 54 退避
55. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon EKS との連携 • 影響を受けた AZ の • 関連する EndpointSlice から Pod エンドポイントを削除 → トラフィック • すべてのノードで Pod をスケジューリングブロック ※Karpenter, Auto Mode はカバーされていない ※Pod, ノードは終了しない(復旧時のため) https://aws.amazon.com/jp/about-aws/whats-new/2024/10/amazon-eks- application-recovery-controller-arc/ 2. 障害分離 b. AZ 退避 - Application Recovery Controller - ゾーンシフト → コンピュート Container Container Container AZ-1 AZ-3 Amazon EKS AZ-2 Container Container Container 新規の Pod スケジューリング はブロック 55 退避
56. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 – 障害検知 56 [1] https://health.aws.amazon.com/health/status [2] https://aws.amazon.com/jp/blogs/networking-and-content-delivery/configuring-amazon-application- recovery-controller-zonal-autoshift-observer-notifications/ どのように AZ 退避をキックするのか 1. システムメトリクスから、特定 AZ での障害を検知する 2. 外形監視により、特定 AZ の顧客体験メトリクス毀損をチェックする 3. AWS が提供するイベントを利⽤する 1. Service Health Dashboard の利⽤[1] 2. オートシフトオブザーバー通知[2]
57. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. どのように AZ 退避をキックするのか 1. システムメトリクスから、特定 AZ での障害を検知する 2. 外形監視により、特定 AZ の顧客体験メトリクス毀損をチェックする 3. AWS が提供するイベントを利⽤する 1. Service Health Dashboard の利⽤[1] 2. オートシフトオブザーバー通知[2] 2. 障害分離 b. AZ 退避 – 障害検知 6/26 14:50 - 15:30 AWS におけるグレー障害の検出と対策 57
58. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 – 障害検知 58 [1] https://health.aws.amazon.com/health/status [2] https://aws.amazon.com/jp/blogs/networking-and-content-delivery/configuring-amazon-application- recovery-controller-zonal-autoshift-observer-notifications/ どのように AZ 退避をキックするのか 1. システムメトリクスから、特定 AZ での障害を検知する 2. 外形監視により、特定 AZ の顧客体験メトリクス毀損をチェックする 3. AWS が提供するイベントを利⽤する 1. Service Health Dashboard の利⽤[1] 2. オートシフトオブザーバー通知[2]
59. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. b. 障害分離 考慮事項 • コスト効率低下 • 各 AZ での冗⻑化、かつ、事前プロビジョニング • 設計が複雑化する • AZ ごとの接続エンドポイント管理 ※特にフェイルオーバー時や退避の考慮 • AZ 毎のリソース管理 • AZ 退避の仕組み検討（特に Application Recovery Controller 未対応のサービス） →重要な⾼可⽤性⽬標を持つコンポーネントやパスへの適⽤を検討する 59
60. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. b. 障害分離 考慮事項 • コスト効率低下 • 各 AZ での冗⻑化、かつ、事前プロビジョニング • 設計が複雑化する • AZ ごとの接続エンドポイント管理 ※特にフェイルオーバー時や退避の考慮 • AZ 毎のリソース管理 • AZ 退避の仕組み検討（特に Application Recovery Controller 未対応のサービス） →重要な⾼可⽤性⽬標を持つコンポーネントやパスへの適⽤を検討する 60 認証 ブラウズ 検索 ⽀払い サービス 倉庫 サービス 顧客 配送 サービス 機械学習による パーソナライズ サービス 配送業者 製品 カタログ ユーザー体験のクリティカルパス の⽬標と想定する障害をベースに設計検討する クレジット カード会社
61. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾼可⽤性設計検討ポイント振り返り 1. 耐障害性 a. 冗⻑化 b. 通信の信頼性 • ⾼速な切り離し︓ ヘルスチェック、サーキットブレーカー • 瞬断の軽減︓ リトライとタイムアウト 2. 障害分離 a. AZ 独⽴性 b. AZ 退避 Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 61
62. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオ
63. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオと対策を検討する 1. 想定障害の洗い出し § 過去の障害 § 構成上から懸念される障害 2. 障害に対する対策と復旧時間の⽬標から設計する 3. 障害の再現を⾏う E.g. AWS Fault Injection Service https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-readiness-reviews/the-orr-tool.html 63
64. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオと対策を検討する 1. 想定障害の洗い出し § 過去の障害 § 構成上から懸念される障害 2. 障害に対する対策と復旧時間の⽬標から設計する 3. 障害の再現を⾏う E.g. AWS Fault Injection Service https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-readiness-reviews/the-orr-tool.html 64
65. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオ例 構成上から懸念される障害例 1. 特定 AZ で部分的な Amazon EKS インスタンス障害 2. 特定 AZ 内でのエラー率上昇 (特定 AZ 内での NW Issue) Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 65
66. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオ例 構成上から懸念される障害例 1. 特定 AZ で部分的な Amazon EKS インスタンス障害 2. 特定 AZ 内でのエラー率上昇 (特定 AZ 内での NW Issue) Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 特定 AZ で部分的なインスタンス障害 → 同⼀インスタンスに乗る Pod に 影響 66
67. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオ例 構成上から懸念される障害例 1. 特定 AZ で部分的な Amazon EKS インスタンス障害 2. 特定 AZ 内でのエラー率上昇 (特定 AZ 内での NW Issue) Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 67 冗⻑化 複数 AZ 、複数インスタンスに冗⻑化 これによりルーティングで処理継続 可能 通信の信頼性 ALB ヘルスチェックにより ターゲットから切離し デフォルト 30 sec * 5
68. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオ例 Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 構成上から懸念される障害例 1. 特定 AZ で部分的な Amazon EKS インスタンス障害 2. 特定 AZ 内でのエラー率上昇 (特定 AZ 内での NW Issue) Container Container 68
69. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオ例 Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 構成上から懸念される障害例 1. 特定 AZ で部分的な Amazon EKS インスタンス障害 2. 特定 AZ 内でのエラー率上昇 (特定 AZ 内での NW Issue) Container Container 散発的なエラーが発⽣ 発⽣時の根本箇所の特定 が困難 69
70. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 障害シナリオ例 Region AZ-1 AZ-2 AZ-3 Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container AWS Cloud Map Primary DB Reader DB Reader DB Reader DB 構成上から懸念される障害例 1. 特定 AZ で部分的な Amazon EKS インスタンス障害 2. 特定 AZ 内でのエラー率上昇 (特定 AZ 内での NW Issue) Container Container 退避 AZ 退避 外形監視より、特定 AZ で のエラー率上昇を確認 当該 AZ を切り離す 検知時間＋切離しまで数分 冗⻑化 複数 AZ 、複数インスタンスに 冗⻑化 これによりルーティングで処理 継続可能 AZ 独⽴性 障害 AZ の封じ込め 静的安定性を持った退避 通信の信頼性 AZ 退避までの間、 リトライやタイムアウト により、エラーを低減 70
71. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ
72. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Key Takeaway • 「障害は必ず発⽣する」を前提に、⾼速に復旧させる設計を検討する • ⾼可⽤性に向けた設計検討ポイント • 障害シナリオと復旧⽬標を元に、どの設計パターンを導⼊するか検討 しましょう 1. 耐障害性 a. 冗⻑化 b. 通信の信頼性 2. 障害分離 a. AZ 独⽴性（トラフィック、デプロイ） b. AZ 退避 72
73. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! 堀内 保⼤ (Yasuhiro Horiuchi) AWS Japan G.K. Sr. Solutions Architect @ka_shino_ki horiuyas@amazon.co.jp https://www.linkedin.com/in/kashinoki38
74. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Appendix.
75. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 - コンテナのマルチ AZ 冗⻑化 Amazon ECS https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/tas k-placement.html • EC2 起動タイプ • タスク配置戦略 • タスク定義の要件や制約事項を満たし、 配置戦略を満たすインスタンスを選択する • E.g. 複数 AZ でタスクを均等に分散し、 各 AZ 内で複数のインスタンスでタスク均等分散 • Fargate 起動タイプ • AZ にタスクを分散する仕様 • タスク配置戦略は未サポート "placementStrategy": [ { "field": "attribute:ecs.availability-zone", "type": "spread" }, { "field": "instanceId", "type": "spread" } ] サービス定義 • タスクを AZ に分散配置する⽅法は起動タイプで異なる ※どちらもベストエフォート 75
76. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 - コンテナのマルチ AZ 冗⻑化 76 AZ 間で不均衡なタスクの検出・再調整が可能に (2024/11/20 updated) • 特定の AZ にタスクが偏っていることを⾃動で検出してタスクを再配置 • availabilityZoneRebalancing という設定がサービスに追加 Amazon ECS { "availabilityZoneRebalancing": "ENABLED", ... } サービス定義 1. 各 AZ で実⾏されているタスク数を継続監視 2. AZ 間でのタスク数の不均衡を検出 1. 実⾏中のタスク数が最も少ない AZ のタスクを開始 2. 実⾏中のタスク数が最も多い AZ のタスクを停⽌ ※新しく開始されたタスクが HEALTHY および RUNNING になるのを待ってから停⽌
77. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • Pod Topology Spread Constraintsの利⽤ • インスタンス毎や AZ 毎を toplogy とみなした配置が可能 ※新規スケジューリング時のみ • 何らかの理由で再配置されると Pod が分散配置されない →Deschedular • Deschedularは、ポリシーに従って Pod を Evict してくれる • RemovePodsViolatingTopologySpreadConstraint で Pod Topology Spread Constraints 違反を指定 • Pod Disruption Budget (PDB) を設定し、最低限確保したい Pod 数を守る 1. 耐障害性 a. 冗⻑化 - コンテナのマルチ AZ 冗⻑化 https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/ https://github.com/kubernetes-sigs/descheduler Amazon EKS apiVersion: v1 kind: Pod metadata: name: example-pod spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule Pod 定義 whenUnsatisfiable :条件に合致する Nodeがない場合の対処法 DoNotSchedule | ScheduleAnyway topologyKey : インスタンスや AZ maxSkew: topology 間で許容する Pod 数差異 77
78. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. 耐障害性 a. 冗⻑化 - インスタンスのマルチ AZ 冗⻑化 78 Amazon ECS Amazon EKS • Amazon EC2 Auto Scaling • ※以下でも利⽤ • Amazon ECS Capacity Provider • Amazon EKS Managed Node Group • Auto Scaling Group にて AZ 戦略を設定 • 使⽤できる AZ で均等にインスタンスを 配置しようとする • バランスの取れたベストエフォート • バランスのみ • Amazon EKS Auto Mode, Karpenter • NodePool にて利⽤ AZ を指定 • Pod の AZ 分散スケジューリングに合わせて、 必要 Node を AZ に起動 コンテナの下回りのインスタンスの配置戦略 https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/ec2-auto- scaling-availability-zone-balanced.html apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: my-node-pool spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "topology.kubernetes.io/zone" operator: In values: [“ap-northeast-1a", ”ap-northeast-2c", ”ap-northeast-2d"] NodePool 定義
79. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. • Amazon ECS の機能として、Service Discovery や Service Connect には AZ に 閉じて通信を⾏う機能は現時点では存在しない • ECS Service を AZ 単位で作成することで、明⽰的に AZ を指定したルーティング が実現可能 79 2. 障害分離 a. AZ 独⽴性 - コンテナ側のトラフィックハンドリング Amazon ECS AZ-1 AZ-2 Amazon ECS Container Container Container Container Container Container Container Container Container Container Container Container ECS Service ECS Service ECS Service ECS Service
80. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Topology Aware Routing や trafficDistribution で、トラフィックを AZ に閉じること が可能 ※ベストエフォート • 仕組み § Serviceにアノテーションを付与すると有効化︓service.kubernetes.io/topology-mode: Auto § インスタンスに付与された Topology ラベルを元にトラフィックをコントロール E.g. topology.kubernetes.io/zone § kube-proxy が、設定に基づいてルーティング先エンドポイントをフィルタリング 80 2. 障害分離 a. AZ 独⽴性 - コンテナ側のトラフィックハンドリング https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/ https://v1-31.docs.kubernetes.io/docs/concepts/services-networking/service/#traffic-distribution Amazon EKS
81. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 – コントロールプレーンとデータプレーン Control APIs • AWS では、ほとんどのサービスをコントロール プレーンとデータ プレーン の概念に分けている。 • コントロール プレーンは、リソースの作成、読み取り/記述、更新、削除、⼀覧表⽰ (CRUDL)等の 管理 API を提供。 • データ プレーンは、サービスの主要な機能を提供 • データ プレーンは、コントロール プレーンより障害イベントが統計的に発⽣しにくい 81 81
82. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. 障害分離 b. AZ 退避 – 静的安定性を考慮した動作 復旧のためのコントロールプレーン処理は避ける Amazon Route 53 でのプラクティス • アンチパターン • ベストプラクティス www.example.com → us-east-1.example.com www.example.com → us-west-2.example.com ChangeResourceRecordSet ヘルスチェック: us-west-2.example.com ヘルスチェック: us-east-1.example.com www.example.com ヘルスチェック、DNSフェイルオーバーは データプレーン操作 82
83. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. システムメトリクスから、特定 AZ での障害を検知するアラートを構築する 2. 外形監視により、特定 AZ の顧客体験メトリクスの SLO※ 違反をチェックする → Amazon CloudWatch Synthetic や AWS Lambda による独⾃ロジックを活⽤ ※サービスレベル⽬標 3. AWS が提供する障害イベントを利⽤する 1. オートシフトオブザーバー通知 2. Service Health Dashboard の利⽤ 2. 障害分離 b. AZ 退避 – 障害検知 ALB と NLB の両⽅が、標準のリージョンの DNS 名に加えて、ゾーン DNS 名を提供 これを利⽤し、各 AZ ごとの外形監視を⾏う https://aws.amazon.com/jp/blogs/networking-and-content-delivery/rapidly-recover-from-application-failures-in-a-single-az/ ELB name: zonal-shift-demo-1234567890.elb.ap-northeast-1.amazonaws.com Zone 1A: ap-northeast-1a.zonal-shift-demo-1234567890.elb. ap-northeast-1.amazonaws.com … 83
84. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. システムメトリクスから、特定 AZ での障害を検知するアラートを構築する 2. 外形監視により、特定 AZ の顧客体験メトリクスの SLO 違反をチェックする 3. AWS が提供する障害イベントを利⽤する 1. Service Health Dashboard の利⽤ 2. Application Recovery Controller オートシフトオブザーバー通知 2. 障害分離 b. AZ 退避 – 障害検知 https://aws.amazon.com/jp/blogs/news/manage-and-view-your-aws-health-notifications-in-aws-user-notifications-service/ https://aws.amazon.com/jp/blogs/networking-and-content-delivery/configuring-amazon-application-recovery-controller-zonal-autoshift-observer-notifications/ オートシフトオブザーバー通知は、 AWS が潜在的な AZ 障害を検知したこと を知らせるイベント ※オートシフト無効でも受領可能 84