kashinoki38 blog

something like tech blog

トップ > AWS > 分散システムの可用性設計 - 参考資料まとめ

分散システムの可用性設計 - 参考資料まとめ

AWS Resilience

今年1年いろいろ調べた際に参照した、AWSにおける分散システムの可用性設計、特に AZ を活用した耐障害性設計に関する公式資料・参考記事をまとめました。

1. Whitepaper

Well-Architected フレームワーク - 信頼性の柱

docs.aws.amazon.com

マルチAZの高度なレジリエンスパターン

docs.aws.amazon.com

  • Introduction
    • マルチAZは二元的な障害イベントの際にはうまく機能するが、Gray Failureに直面すると問題が発生することがある
    • 単一のAZに限定されたグレー障害の影響を検出するためにワークロードを計測する方法と、そのAZでの影響を軽減するための対策について指針を提供
      • ⚠️このようなタイプのワークロードは、全体のポートフォリオの中で小さな部分を占める可能性が高いため、このガイダンスはプラットフォームレベルではなく、ワークロードレベルで検討されるべきです
  • Gray Failures
    • グレー障害の定義と特徴
      • 異なる観測性：異なるエンティティが障害を異なる方法で観察する現象
        • システムの消費者の1つがシステムが不健全であることを検出しているにもかかわらず、システム自体の監視が問題を検出しない、または影響がアラームの閾値を超えない状況
      • システムがどれほど洗練され、回復力があっても、障害が検出されないか、反応閾値以下にとどまる可能性は常にある
    • グレー障害の例
      • マルチAZシステムでの影響：特定のAZとデータベース間の接続に問題が発生する場合がある
      • 各サービスのヘルスチェックやステータスでは正常と判断するが、ワークロードは可用性に影響を受ける
    • グレー障害への対応
      • 3つの選択肢：何もしない、影響を受けたAZを退避、別のリージョンにフェイルオーバー
        • 大多数のワークロードは何もしないで問題ない
    • AZ退避の利点
      • より低いRTO（Recovery Time Objective）：インフラとリソースが既に複数のAZにプロビジョニングされている
      • より低いRPO（Recovery Point Objective）：多くのAWSサービスが単一リージョン内で強力なデータ永続性を提供
      • AZ退避は静的に可能
    • リージョナルサービスはAZ退避では対応ができない
  • Multi-AZ Observability
    • インストルメンテーションの重要性
      • タスクの所要時間、成功/失敗数、リクエストのメタデータなどを記録するコードが必要 → EMF活用
      • サーバーサイドとクライアントサイドの両方でメトリクスを生成
      • 外形監視においても、AZ別のエンドポイントがある場合ディメンションとして利用可能
        • E.g NLBのゾーン別エンドポイントをそれぞれテストするCloudWatch SyntheticsまたはAWS Lambda関数で実行されるカナリア
    • CloudWatch 複合アラームによる障害検出
      • ごく一部のインスタンスが影響を与えているのではないのかを確認する
        • CloudWatch Contributor Insights を使用して、可用性とレイテンシーのメトリクスへの寄与要因の数を特定しアラームに利用する
        • InstanceIdをキーにUniqueContributorsというメトリクスで集計が可能
  • AZ Evacuation Patteerns
    • 達成すべき成果
      • 1/影響を受けているAZへの作業の送信を停止する（AZIを実装する）
        • 影響を受けていないAZのリソースが、影響を受けているAZのリソースと相互作用しないようにする
      • 2/影響を受けているAZに新しいキャパシティがプロビジョニングされないようにする
    • AZ Independence (AZI）
      • 別のAZのプライマリデータベースインスタンスへの接続など、絶対に必要な場合を除いて、AZ内のリソースを分離し、異なるAZのリソース間のやり取りを防止
      • 使用する他のゾーンサービスも AZI パターンを使用して実装する必要がある
        • E.g. インターフェースエンドポイントもAZ毎のDNS名を利用する
      • 課題はDBアクセス
        • Auroraの場合
          • 参照：カスタムエンドポイントを利用して、AZ IDに基づいて名前をつけ、Zoneに閉じた参照を行う
          • 更新：Writerエンドポイントを利用。障害時にはフェイルオーバー
    • AZI退避はデータプレーン動作をなるべく使う
      • ワークロードが一時的なエラーを克服するために、コード内でジッターを伴うエクスポネンシャルバックオフによる再試行などの戦略を既に試行したことを前提
      • データプレーン制御の退避
        • 1/ARCのZone Shift
        • 2/Route 53 ARC の機能を使用して特定の DNS レコードの状態を手動で指定する
          • 可用性の高い Route 53 ARC クラスターデータプレーンを使用できる
        • 3/セルフマネージド型 HTTP エンドポイントの使用
          • 3-1/Amazon S3 の使用
            • Route 53 ARCのキックのヘルスチェックをS3レコード存在で代替する
              • オブジェクトが存在しないときは健全、オブジェクトが存在するときは異常がある
              • use1-az3 に対してアベイラビリティーゾーンの退避を開始したい場合、use1-az3.txt という名前のファイルを CLI または API を使用してバケットにアップロード
          • 3-2/API Gateway と DynamoDB を使用する
            • 使用中の各AZステータスを保存する Amazon DynamoDB へのサービス統合で設定

分散システムにおける高可用性設計

docs.aws.amazon.com

  • ※この記事は古い
  • Understanding availability
    • uptime = MTBF/ MTTR(MTTD + Repair Time) + MTBF
    • 分散システムの可用性
      • 分散システムの障害には、再現可能な「ボーアバグ」と一時的な「ハイゼンバグ」がある。プロダクション環境では主にハイゼンバグが問題となり、再現が難しく、デバッグ時に挙動が変わることがある。多くの障害は一時的で、再試行すると成功する可能性が高い。そのため、分散システムはハイゼンバグに対する耐性が必要となる。
  • 耐障害性（Fault Trelant）と障害分離（Fault Isolation）
    • 耐障害性：サブシステムの障害に耐え、可用性を維持する能力（確立されたSLA内で正しいことを行う）
    • 障害分離：障害が発生した際の影響範囲を最小限に抑える。れは通常、モジュール化によって実装される。独立して故障し修復可能。モジュールを超えて伝搬しない。
  • コントロールプレーン、データプレーン、静的安定性のアーキテクチャパターン
    • コントロールプレーン：通常、データプレーンよりも複雑で動く部分が多いため、統計的に故障する可能性が高く、可用性が低くなる
    • データプレーン：コントロールプレーンよりも単純で、より高いボリュームで動作する傾向があり、より高い可用性につながる
    • 静的安定性：依存関係の障害にもかかわらず、ワークロードが正しい動作を継続する能力
      • 回復のための2つのアプローチ：1/障害後に対応する（Auto Scaling）、2/事前オーバープロビジョニング
      • 後者がコントロールプレーン依存が少なく、障害時の過負荷のリスクも低い
  • 可用性の計測
    • uptime, downtimeによる可用性定義は二者択一になっているが実際は異なる（MTTR, MTBFは結果的な可用性理解と改善検討には有用だが、測定値としては有用ではない）
      • ダウンタイムの定義や、あるいはシステム全体の可用性指標が必要 E,g, 単一のAPIやワークロードの可用性がしきい値を下回る状態,重要なデータプレーン操作のみ
      • パーセンタイルで見て、特定のしきい値を超えた時間をダウンタイムとしてみなす
  • 制御できるのは、障害をどれだけ早く検知し、対処するか。つまりMTTDとMTTRの削減
    • Reducing MTTD：迅速な障害検知
    • Reducing MTTR
      • 何が問題かを特定するためのメトリクス 1/影響評価メトリクス 2/運用健全性メトリクス
      • 最速のアプローチは高速なフェイル（fail-fast mechanism）
    • 依存関係のMTBF向上
      • 障害分離：複数のAZやリージョンの使用
        • リージョン検討：すべてのAWSサービスがAZレベルで動作するわけではない。リージョナルサービスの設計上の可用性がワークロードに必要な全体的な可用性をサポートしていない場合、マルチリージョンアプローチを検討する必要がある

セルベースアーキテクチャ

docs.aws.amazon.com

  • Introduction
    • バルクヘッドアーキテクチャを使用して影響の範囲を制限する」を拡張し、障害の影響を限られた数のコンポーネントに抑える
    • セルベースアーキテクチャは、ワークロードにより高い障害分離、予測可能性、テスト可能性を提供
      • 極めて高いレベルのレジリエンスを必要とするワークロードにとって基本的な特性
    • 顧客がマルチテナント環境にいることを認識していても、彼らが望むのはシングルテナント環境の体験
  • What is a cell-based architecture?
    • 全体のワークロードはパーティションキーによって分割
      • パーティションキーの例には、顧客ID、リソースID、またはほとんどのAPI呼び出しで簡単にアクセスできるその他のパラメータ
    • セルルーティング層は、パーティションキーに基づいて個々のセルにリクエストを分散し、クライアントに単一のエンドポイントを提示
    • セルベースのアーキテクチャは、ワークロードの複数の分離されたインスタンスを使用し、各インスタンスはセルと呼ばれる
    • 各セルは独立しており、他のセルと状態を共有せず、全体のワークロードリクエストの一部を処理
    • cell-based architecture
      • セルルーター — この層は可能な限り薄い層とも呼ばれ、リクエストを適切なセルにルーティングする責任のみを持ちます。
      • セル — 独立して運用するために必要なすべてを備えた完全なワークロード。
      • コントロールプレーン — セルのプロビジョニング、デプロビジョニング、セル顧客の移行などの管理タスクを担当します。
  • Why use a cell-based architecture?
    • スケールアウト特性
    • 影響範囲の縮小
    • より高いテスト可能性
    • より長い平均故障間隔（MTBF）
      • セルは一貫した制限されたサイズを持ち、定期的にテストされ運用される
    • より短い平均復旧時間（MTTR）
    • より高い可用性
  • When to use a cell-based architecture?
    • ダウンタイムが顧客に大きな悪影響を与える可能性のあるアプリケーション
    • 経済的安定性に不可欠なワークロードを持つ金融サービス業界
    • 大規模すぎる、または重要すぎて障害が許されないウルトラスケールシステム
    • 5秒未満の目標復旧地点（RPO）
    • 30秒未満の目標復旧時間（RTO）
    • 一部のテナントが完全に専用のテナンシー（つまり、専用のセル）を必要とするマルチテナントサービス
    • ⚠️欠点
      • インフラストラクチャとコンポーネントの冗長性によるアーキテクチャの複雑性の増加
      • インフラストラクチャとサービスの高コスト
      • これらの複数のレプリカ（セル）のワークロードを運用するための専門的な運用ツールと実践が必要

実装はこちらの解説がわかりやすい

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-58_Architecture_AWS_Summit_JP_2024.pdfpages.awscloud.com

  • 1/ テスト不足、2/ オペミス、3/ Poison pillに対して影響範囲を狭めるアプローチとしてセルベースアーキテクチャを提案している
    • 本来はテストや切り戻し、アプリ実装の工夫等で対応を行うべきだが、すべてを想定することは難しいため
  • セルベースアーキテクチャのメリット
    • 障害分離性
    • スケール性
    • テスト性

セルベースアーキテクチャ事例

  • AWS re:Invent 2021 - Unlocking scalability with cells: New Relic’s journey to AWS - YouTube
  • AWS re:Invent 2022 - Journey to cell-based microservices architecture on AWS for hyperscale (ARC312) - YouTube
  • An Insider Look: How Okta Builds and Runs Scalable Infrastructure | Okta
  • Slack’s Migration to a Cellular Architecture | Engineering at Slack
  • re:Invent 2024: AWSとSlackが語るCell-based Architectureの実践
    • Egressプラットフォームのセルベース化
    • 信頼性の向上、コストが目的
      • Slack全体として、重要なサービスをAZ Affinityアーキテクチャパターンに移行する大規模な取り組みが進行中
      • Egressスタックの運用コストが予算のガイドラインをはるかに上回るペースで増加し続けていたため、 このコスト問題に対処する必要
    • Affinityのアーキテクチャパターン
      • 問題のBlast Radiusを単一のAvailability Zone内に限定すること
      • 必要に応じてAZを退避できる能力を持つこと
      • 一度リクエストがAZに入ったら、そのすべてのダウンストリーム依存関係が同じAZ内に存在しなければならない
  • re:Invent 2024: Stripeが実現する99.9995%の可用性 - 技術と文化
    • Stripeは金融インフラとして99.9995%（5.5ナイン）の可用性を目指している
      • 月に13秒のダウンタイムしか許容されない厳しい基準を設定している
    • 信頼性と可用性の技術的な側面
        1. セルベースアーキテクチャ
        2. コストと技術的な複雑さがある
          • cellの場合は、各cellが独自にトラフィックスパイクに対応できる必要があるため、平均的により多くのハードウェアを使用する
        3. ランダムな障害を防ぐだけでなく、変更管理にも関わる
        4. 段階的に導入可能で、システムの一部から適用できる
          • システム全体で同じCellを使用する必要があるという誤解
          • ストレージサブシステムやAPIサービスメジャーなど、それぞれの部分で独立してCell-based architectureを使用
        1. グレー障害への対応
        2. 異常検知を利用
          • 他のノードと比較して異常な動作をしているノードを自動的に発見
        1. カオステスティングとフォールトインジェクション
        2. サービスが成熟するにつれて、より多くの障害を有効にしていき、QA環境では常にシステムを稼働させていく
        1. 負荷テスト
        1. 継続的デリバリー
        1. リトライメカニズム
        2. APIの失敗時に自動的にリトライを行い、ユーザーの成功率を向上させる
        3. Stripe内部でリトライを行うことで、ユーザーの負担を軽減
          • リトライは私たちのネットワーク内で行われるため、リトライによる全体的なレイテンシーが少なくなる
        4. アーキテクチャに関する内部知識を活用してより効率的にリトライを実行
          • 同じセルで何度もリトライするのではなく、データベースの異なるセルでリトライしたり、オレゴンで問題が発生している場合はオハイオでリトライしたり
        5. Tips
          • APIを冪等に設計する
          • ユーザーに最も近い外側の層でリトライを行う
            • リトライを各層で実装すると増幅される
          • 瞬断を回避するアプローチとしてリトライを設計する
    • 信頼性文化の構築
  • re:Invent 2024: AWSとCapital Oneが語るレジリエントなアプリ構築
    • Capital Oneの2つのミッションクリティカルなプラットフォームにおけるCell-based Architectureの実装事例
    • オーソリプラットフォーム（Zonal Independence Cell）
      • 250ミリ秒以内でのエンドツーエンド処理が必須要件
      • AZ Affinityを採用し、トランザクション全体を単一Cell内で完結させることで低レイテンシーを実現
      • Deep Health Checkによりトランザクションレベルまでの健全性を把握し、SLO違反前に予防的にトラフィックをシフト
      • Resilience EngineがCloudWatch等からアラートを集約し、Cell間のトラフィック制御とキャパシティ管理を自動化
      • 250ミリ秒以内に完了しない場合でも、複数ホップの判断により暫定的な応答を返すデグレードモードを実装
    • Core Banking Platform（Regional Cell-based）
      • 複数テナント（リテール顧客、カード顧客等）の異なる要件に対応するためテナントセグメンテーションを重視
      • Siloed方式とPooled方式の両方をサポートし、Noisy neighbor effectを最小化
      • Cell単位での独立運用により、リージョン障害時もプラットフォーム全体ではなく影響Cellのみをフェイルオーバー
      • デプロイメント失敗の影響範囲をCell内に限定し、運用の柔軟性を確保

Operational Readiness Reviews (ORR)

docs.aws.amazon.com

  • AWSが運用インシデントから得た学びを、ベストプラクティスガイダンス付きの質問として体系化したフレームワーク
  • 目的は「より短く、より少なく、より小さな」インシデントを実現すること
  • AWSの分散型運用文化において、開発者の速度と俊敏性を犠牲にせずにベストプラクティスを共有・適用するためのスケーラブルなセルフサービスメカニズムとして設計
  • Correction of Errors (COE) による事後分析から得られた知見を、他のワークロードでの予防可能なリスクの発生を防ぐために活用
  • ORRの質問はリスクを明らかにし、インシデントの共通原因を排除するためのベストプラクティス実装についてチームを教育
  • ワークロードのライフサイクル全体（設計から本番運用後まで）を通じて、適切なORRチェックリストを使用した自己評価を実施
  • Well-Architected Frameworkの運用エクセレンスと信頼性の柱を補完し、組織固有のビジネス、文化、ツール、ガバナンスルールに特化した学びを含めることが可能
  • データ駆動型アプローチにより、ワークロードにおける既知の一般的な影響原因を排除するための一貫したレビューを実現

Resilience Lifecycle Framework

docs.aws.amazon.com

  • AWSが顧客や内部チームとの長年の経験から開発した、レジリエンス向上のための継続的なアプローチを定義するフレームワーク
  • 現代の組織は「常時稼働、常時利用可能」という顧客期待の変化に伴い、レジリエンス関連の課題が増大している
  • AWSはレジリエンスを「インフラストラクチャ、依存サービス、設定ミス、一時的なネットワーク問題などの障害に対して、アプリケーションが抵抗または回復する能力」と定義
  • 5つのステージで構成される継続的なライフサイクル
    • Stage 1: Set objectives（目標設定） - レジリエンス目標の定義、依存関係の特定
    • Stage 2: Design and implement（設計・実装） - レジリエンスパターンの適用、トレードオフの評価
    • Stage 3: Evaluate and test（評価・テスト） - カオスエンジニアリング、ゲームデイによる検証
    • Stage 4: Operate（運用） - モニタリング、インシデント対応プロセスの実行
    • Stage 5: Respond and learn（対応・学習） - インシデントからの学習、継続的な改善
  • 望ましいレジリエンスレベルを達成するには、運用の複雑性、エンジニアリングの複雑性、コストのトレードオフを評価・調整する必要がある
  • ソフトウェア開発ライフサイクル（SDLC）と同様のプロセスとしてモデル化されており、アジャイル開発プロセスのように開発の各イテレーションで繰り返し実行可能
  • 各ステージの実践を時間をかけて段階的に深化させることを推奨

2 Builder's Library, Blog

静的安定性関連

  • アベイラビリティーゾーンを使用した静的安定性
    • 静的に安定するように Amazon Elastic Compute Cloud (EC2) を構築した方法について説明
    • EC2における静的安定性の実装例
      • EC2 は、コントロールプレーンとデータプレーンで構成
      • データプレーンはコントロールプレーンの障害時にも静的に安定するように設計されている
        • たとえば、ネットワーク接続の中断を回避するために、EC2 インスタンスが実行される物理マシンが VPC の内外のポイントにパケットをルーティングするのに必要なすべての情報にローカルアクセスできるように、EC2 データプレーンは設計
    • 静的で安定した 2 つのサンプルアーキテクチャを紹介
      • アクティブ - アクティブ：負荷分散サービス
        • キャパシティをオーバープロビジョニングすることで、1 つのAZ全体に障害が発生した場合でも、残りのAZのサーバーが負荷を負担
        • ヘルスチェックに失敗し始め、Application Load Balancer はそれらからトラフィックを移動
      • アクティブ - スタンバイ：RDBMS
        • RDS はフェイルオーバーを管理し、作業中のアベイラビリティーゾーンの新しいプライマリに DNS 名を再ポイントし直します
    • EC2のAZ Isolation
      • デプロイ：AZごとにデプロイタイミングをずらす（1→1/N→N）
      • トラフィック：ネットワークトラフィックをAZのローカルに留める
        • Gray Failureやソフトウェアバグの場合、LBではヘルスチェックで障害を検出できず正常に処理できない
        • たすき掛け（リージョナル可用性とも表現可能）になるとAZ障害にあるのは2/3 * 2/3 = 4/9 で障害回避は50%を下回る。AZIにすれば2/3で回避できる。
        • NAT GWをZonal Serviceにした理由はこれ
  • 分散システムでのフォールバックの回避
    • 重大な障害を処理するための戦略
      • 再試行: すぐに、または少し遅れて、失敗したアクティビティを再度実行します。
      • 積極的な再試行: アクティビティを並行して複数回実行し、最初のアクティビティを使用して終了します。
      • フェイルオーバー: エンドポイントの別のコピーに対してアクティビティを再度実行するか、できればアクティビティの複数の並行コピーを実行して、それらの少なくとも 1 つが成功する確率を上げます。
      • フォールバック: 異なるメカニズムを使用して、同じ結果を達成します。
    • フォールバック戦略の問題点
      • テストが困難
      • フォールバック自体が失敗する可能性
      • システム障害を悪化させる可能性
      • 潜在的なバグが存在
    • Amazonのフォールバック回避策
      • 非フォールバックケースの信頼性向上(メインコードをより堅牢にすることで可用性を高める)
      • 発信者にエラー処理を任せる
      • データを積極的にプッシュ(E.g. サービスに必要なデータがすでにローカルにある)
      • フォールバックをフェイルオーバーに変換
      • 再試行とタイムアウトの適切な管理

耐障害性設計

  • Understand resiliency patterns and trade-offs to architect efficiently in the cloud | AWS Architecture Blog

    • クラウドにおけるレジリエンスパターン
    • レジリエンスパターンの詳細
      • 1/マルチAZ
        • 単一リージョン内の複数AZを使用
        • 低コストだが、バイモーダル動作としてAZダウン時の回復時間が毀損
      • 2/静的安定性を持つマルチAZ
        • 複数AZに事前にリソースを配置
        • コストは高いが、障害時のダウンタイムを最小化
      • 3/アプリケーションポートフォリオ分散
        • 重要なアプリケーションを複数リージョンに分散
        • リージョン障害の影響を軽減するが、運用が複雑
      • 4マルチAZ展開（マルチリージョンDR）
        • パイロットライトやウォームスタンバイなどのDRパターンを使用
        • リージョン障害に対応するが、複雑性が増加
      • 5/マルチリージョンアクティブ-アクティブ
        • 複数リージョンで同時に稼働
        • 最高レベルの可用性を提供するが、最も複雑で高コスト

  • Improving Performance and Reducing Cost Using Availability Zone Affinity | AWS Architecture Blog

    • AZアフィニティの概要
      • AZアフィニティは、Amazon VPCネットワークでの耐障害性システム構築のベストプラクティスの一つ。
      • 複数のアベイラビリティゾーン（AZ）を使用しつつ、パフォーマンスを向上させ、コストを削減する設計パターン。
    • クロスAZの影響
      • AZ間のデータ転送は遅延とコストを増加させる。
      • 同一AZ内の通信は通常サブミリ秒の遅延だが、AZ間は数ミリ秒の遅延が発生。
    • AZアフィニティの実装方法
      • ロードバランサーのクロスゾーンロードバランシングを無効化。
      • クライアントがゾーナルDNS名を使用してリクエストを送信。
      • AWS Cloud Mapを使用したサービスディスカバリの活用。
        • AZ固有のDNS名をCloudMapから取得する案
    • ワークロードの耐障害性
      • クライアントは単一AZに「固定」されるが、問題発生時には他のAZにフェイルオーバー可能。
      • 指数バックオフを伴うリトライや、他のAZへのリクエスト送信で対応。
    • クライアントライブラリの活用
      • サービスディスカバリ、リトライ、フェイルオーバーを処理するクライアントライブラリの提供が有効。
      • ユーザーに低レベルAPIと高レベルライブラリの両方のオプションを提供。
    • 結論
      • AZアフィニティパターンは、マルチAZシステムの遅延とデータ転送コストを削減しつつ、高可用性を維持。
      • すべてのワークロードに適しているわけではないが、特定の要件下では検討に値する。

  • Amazonの高可用性デプロイメントへのアプローチ

    • 段階的デプロイメント戦略
    • 自動化による安全なデプロイ
    • ロールバック安全性の確保

  • Amazonのレジリエントサービス構築アプローチ

    • 障害分離の実装
    • 監視とアラートの設計
    • 継続的改善のプロセス

実装パターン

  • ジッターを伴うタイムアウト、再試行、およびバックオフ
    • 再試行を使用すると、クライアントは同じリクエストを再送信することで、これらのランダムな部分的障害と短期間の一時的障害に耐えることが可能（Gray Failureに対する対処
      • Amazon では、タイムアウト、再試行、バックオフを採用して回復力のあるシステムを構築
    • タイムアウト値の適切な設定
      • タイムアウト値の選択が重要で、高すぎると有用性が低下し、低すぎるとリスクが生じる
        • ダウンストリームサービスのレイテンシーメトリックから開始する
    • 再試行とバックオフ
      • 再試行は「利己的」で、適切な用量で使用する必要がある
      • バックオフを使用して再試行の間隔を調整し、システムの負荷を軽減
    • ジッター
      • バックオフにランダム性を追加して再試行を時間内に分散
      • 定期的な作業にもジッターを追加し、トラフィックの急増を防ぐ
  • ヘルスチェックの実装
    • ヘルスチェックのトレードオフ
      • 重大ではない理由でヘルスチェックが失敗し、その失敗がサーバー間で相関している場合、トラブルが発生
      • ヘルスチェックの種類と特徴
        • ライブ状態チェック：基本的な接続とプロセスの存在を確認
        • ローカルヘルスチェック：アプリケーションの機能を確認
        • 依存関係のヘルスチェック：他システムとの対話能力を検査
        • 異常検出：フリート内のサーバー間の動作を比較
      • ヘルスチェック失敗への対応
        • フェールオープン：すべてのサーバーが失敗した場合にトラフィックを許可
        • サーキットブレーカーなしのヘルスチェック：LBからはライブ＆ローカルヘルスチェック。外部から依存関係のヘルスチェック＆異常検出
      • ヘルスチェックの実装における注意点
        • 正常性を優先する設定
          • 過負荷状態ではヘルスチェックのレスポンスを優先するようにする
        • 依存関係のヘルスチェックと影響範囲のバランスデプロイ時の複数の緩和システムの実装
          • フェールオープン保護がなければ、依存関係をテストするヘルスチェックを実装すると、その依存関係が「ハードな依存関係」に変わります。 依存関係がダウンすると、サービスもダウンし、影響範囲が拡大する連鎖障害が発生します。
    • Challenges with distributed systems
      • 分散システムの8つの障害モード
        1. POST REQUEST失敗: ネットワーク配信失敗
        2. DELIVER REQUEST失敗: サーバー受信直後のクラッシュ
        3. VALIDATE REQUEST失敗: メッセージ無効判定
        4. UPDATE SERVER STATE失敗: 状態更新失敗
        5. POST REPLY失敗: 応答投稿失敗
        6. DELIVER REPLY失敗: クライアント配信失敗
        7. VALIDATE REPLY失敗: 応答無効判定
        8. UPDATE CLIENT STATE失敗: クライアント状態更新失敗

監視

3. re:Inventセッション

4. Application Recovery Controller (ARC)

  • ARCのベストプラクティス

    • Zonal Shiftの適切な使用法
    • 容量計画の重要性
    • 定期的なテストの実施

  • ゾーンシフトを用いたクロスゾーン負荷分散 | Amazon Web Services ブログ

    • 2024 年 11 月 22 日より、クロスゾーン負荷分散を有効にした Application Load Balancer (ALB) の Amazon Application Recovery Controller (ARC)ゾーンシフトサポートを発表
    • クロスゾーン負荷分散を有効にした状態でゾーンシフトを使用する場合の運用上のベストプラクティスを紹介
    • クロスゾーン負荷分散の利点
      • ロードバランサーのゾーンシフトを終了するとターゲットごとに受信されるトラフィックの全体的な割合が減少するため、キャパシティが不均衡になった場合にリバランスをより安全に行うのに役立つ
      • クロスゾーン無効の場合は、ターゲット台数がある程度回復するまでトラフィック再開を待つような仕組みを入れることを検討する
    • AZオブザーバビリティの重要性
      • Amazon CloudWatch Synthetics を使用して ALB と NLB のゾーンエンドポイントをモニタリングし、AZ ごとのメトリクスを生成

  • 単一アベイラビリティーゾーンでのアプリケーション障害からの迅速な復旧 | Amazon Web Services ブログ

    • ゾーンシフトの概要
    • 単一AZアプリケーションの障害に対応するための準備
      • パッシブモニタリングとアクティブモニタリングの併用
        • パッシブモニタリング - サーバーサイドメトリクス
          • ALB と NLB の両方が、UnhealthyHostCount や ProcessedBytes などの AZ 単位のメトリックを提供
        • アクティブモニタリング - 外形監視
          • ALB と NLB の両方が、標準のリージョンの DNS 名に加えて、ゾーン DNS 名を提供します。これにより、以下のように、各ゾーンのアプリケーションレプリカの応答性と信頼性を個別に監視するカナリアを作成することができます 
            • ELB name: zonal-shift-demo-1234567890.elb.ap-southeast-2.amazonaws.com 
Zone 2A: ap-southeast-2a.zonal-shift-demo-1234567890.elb.ap-southeast-2.amazonaws.com
Zone 2B: ap-southeast-2b.zonal-shift-demo-1234567890.elb.ap-southeast-2.amazonaws.com 
Zone 2C: ap-southeast-2c.zonal-shift-demo-1234567890.elb.ap-southeast-2.amazonaws.com
            • https://dev.classmethod.jp/articles/zoneshift-2az-try/
              • 次項のゾーンシフト開始後と比較するため、現在の ALB の DNS を確認しておきます。Tips ですが、ALB の DNS 名の先頭にアベイラビリティゾーンを付け加えることで、各 AZ にある ALB ノードの IP を個別に調べることができます。
    • ゾーンシフトのベストプラクティス
      • 十分なキャパシティヘッドルームの確保
      • 他のゾーンレプリカでターゲットが正常で、トラフィックを積極的に受け入れていることを確認する
      • 定期的な事前のテストと練習
      • 慎重な自動化
        • エッジケースについては慎重に考える
        • たとえば、トラフィックが急激に増加してアプリケーションが過負荷になった場合、通常、AZ を切り離すことは望ましくない
    • ゾーンシフトの試行
      • AWS Fault Injection Serviceを使用したグレー障害のシミュレーション
        • AWS FIS 実験テンプレート： 1 つの AZ にグレー障害 ( 2 %のパケットロス) を 30 分間注入する。

  • re:Invent 2023: AWSが語るAZ障害からの自動回復 - zonal autoshiftの紹介

    • AWSにおける障害対応
    • Central Incident Response Teamが検知ししシフトさせる
      • 検出と対応を一元化することは非常に有用
    • ただし、スケーリングについては、依然としてそれらのサービスチームが対応する（シフト/回復時のスケーリング）
    • マイクロサービスとAZ回復
      • サイロモデル：AZ内でマイクロサービスを完結させる
        • この素晴らしい点は、AZの障害から回復したい場合、フロントエンドでAZ 3を切り離すだけで、 バックエンドに全く変更を加えることなく、AZ 3のすべてのバックエンドが静かになり始める
          • このモデルには一定のポイントまでスケールアップできるものの、その後は少し難しくなるという問題がある（チーム数、サービス数がスケールした際に調整が困難になる）
            • 多くのチームが独立して運用でき、お互いの業務に干渉しないことに相反する点（要は管理が難しい）
              • 特に、その決定に20〜30のチームが関与している場合はなおさ
            • E.g.
              • フロントエンドサービスがAZ 4に容量を追加することを決めた場合、他のすべてのマイクロサービスもそれに追随してAZ 4にデプロイしなければならない
              • AZごとのデプロイを各サービスが実施した際に、それがずれていれば複数AZに障害がわたる可能性がある
            • ※NLBのAvailability Zone DNS affinityで実装しやすくはなった
              • 呼び出し元AZを意識したルーティング
    • Decoupledモデル：各サービスがお互いをリージョナルとして呼び出す
        • マイクロサービスそれぞれがAZ 3から独立して回復する必要がある
        • Amazonでは、Decoupledモデルの場合、インシデント対応チームがフロントエンドサービスだけでなく、すべてのマイクロサービスも処理できる準備ができていれば、それほど問題にはならない
    • Learning
      • 1/ AZ Resilient Design
      • 2/ グレーの障害を、それが何であるかや解決方法を心配せずにハードな障害に変える
        • 単にAZがダウンしていると仮定し、原因を突き止めるまでそこへのトラフィックを止める
      • 3/ マネージド、リージョナルサービスを利用する
        • 特にデータベース層では、AZ障害に対処できる管理されたリージョナルサービスを好んで使用
      • 4/ 事前スケール
      • 5/ 理想的には、多くのサービスが関与している場合、中央のチームが検出してシフトを行うことが本当に役立つ
      • 6/ 定期的なテストサイクルを設けることが重要
    • Zonal Shiftとauto shift
      • Zonal Shift：AZからトラフィックを迅速に移動させる機能
        • サイロ型アーキテクチャでは、zonal shiftはフロントエンドに適用
        • 非サイロ型アーキテクチャでは、実際には実行中の各マイクロサービスに適用する必要
        • ※Zonal Shiftはリソースを再構成せずにトラフィックをシフトするためのもの。リソース再構築は実施しない
      • auto shift：AWSが自動的にZonal Shiftを適用する新機能
        • AZに潜在的な影響がある場合に実行→十分な容量が必要
        • 事前にキャパシティを確保し、定期的な練習が重要
          • practice runの契約の一部として、アラームを提供していただき、そのアラームが発生した場合にpractice runを停止
      • autoshiftと共にAWS Fault Injection Serviceの新機能もリリース
        • 停電テストを導入し、実際にAZでの電源障害をシミュレートして、その対応としてzonal shiftをどのように使用できるかを確認することができます

5. その他参考