AWS のディザスタリカバリ (DR) アーキテクチャ、パート III: パイロットライトとウォームスタンバイ

このブログはSeth Eliot (Principal Reliability Solutions Architect with AWS Well-Architected)によって執筆された内容を⽇本語化したものです。原⽂はこちらを参照して下さい。

このブログ記事では、自然災害、技術的な障害、人的な行為などの災害イベントからワークロードを回復できるようにする、さらに2つのアクティブ/パッシブ戦略について学びます。以前、AWS でのディザスタリカバリ (DR) の 4 つの戦略を紹介しました。次に、バックアップと復元の戦略を検討しました。今回は、パイロットライトとウォームスタンバイ戦略について学びましょう。

DR戦略：パイロットライトまたはウォームスタンバイ

DR戦略を選択する際には、RTO（目標復旧時間）やRPO（目標復旧時点）の短縮によるメリットと、戦略の実装と運用にかかるコストを比較する必要があります。パイロットライトとウォームスタンバイ戦略は、図1に示すように、メリットとコストのバランスが取れています。

図 1.DR戦略

パイロットライトまたはウォームスタンバイの実装

図 2 と図 3 は、パイロットライトおよびウォームスタンバイ戦略をそれぞれ実装する方法を示しています。これらは両方ともアクティブ/パッシブ戦略です（以前の投稿の「アクティブ/パッシブおよびアクティブ/アクティブ DR 戦略」セクションを参照）。左側の AWS リージョンはアクティブなプライマリリージョンで、右側のリージョンはフェイルオーバー前にパッシブなリカバリリージョンです。

図 2.パイロットライトDR戦略

図 3.ウォームスタンバイ DR 戦略

これらの 2 つの DR 戦略の類似点

どちらの戦略も、Amazon Relational Database Service (Amazon RDS) DB インスタンスや Amazon DynamoDB テーブルなどのデータをプライマリリージョンからリカバリリージョンのデータリソースにレプリケートします。これらのデータリソースは、リクエストを処理する準備が整っています。いずれの戦略においても、レプリケーションに加えてリカバリリージョンで継続的なバックアップを作成する必要があります。これは、人的な行為に起因する災害が発生すると、データが削除または破損し、レプリケーションによって不良データがレプリケートされるためです。最新の正常な状態に戻すには、バックアップが必要です。

どちらの戦略も、ワークロードインフラストラクチャに使用されるリソースは、リカバリリージョンにデプロイされます。これには、サブネットとルーティングが設定された Amazon Virtual Private Cloud (Amazon VPC)、Elastic Load Balancing、Amazon EC2 Auto Scaling グループなどのサポートインフラストラクチャが含まれます。いずれの戦略も、デプロイされたインフラストラクチャは、本番稼働に対応するために追加のアクションを必要とします。ただし、次のセクションで説明するように、ワークロードインフラストラクチャの準備の程度は 2 つの戦略で異なります。

すべてのアクティブ/パッシブ戦略と同様に、いずれの戦略もトラフィックをあらかじめプライマリリージョンにルーティングしておき、災害復旧時にリカバリリージョンにフェイルオーバーする手段が必要です。

これら 2 つの戦略はデータ戦略が同じであるため、RPO（目標復旧時点）も同等です。

これらの 2 つの DR 戦略の相違点

この 2 つの戦略の主な違いは、インフラストラクチャのデプロイと準備の状況です。ウォームスタンバイ戦略は、少ないキャパシティの機能スタックをデプロイしておきます。リカバリリージョン側のワークロードはリクエストをある程度は処理できますが、本番レベルのトラフィックを処理することはできません。図 3 では Tier ごとに 1 台の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとして示されています。実際には 1 台より多い場合もありますが、コスト削減のため完全な実稼働環境に比べて常に少なくなります。待機スタックがフルキャパシティでリカバリリージョンに展開されている場合、この戦略は「ホットスタンバイ」と呼ばれます。ウォームスタンバイはリカバリリージョンに機能スタックをデプロイするため、合成トランザクションを使用してリージョンの準備状況をテストしやすくなります。

家庭用の炉のパイロットライトは、それ自体は家の中に熱を供給しません。パイロットライトは炉を素早く点火する手段を提供し、炉が熱を供給します。同様に、（ウォームスタンバイとは異なり）パイロットライト戦略の DR リージョンは、追加の手順が実行されるまでリクエストを処理できません。図 2 は、設定されている EC2 Auto Scaling グループを示していますが、デプロイ済みの EC2 インスタンスはありません。

これらの戦略のRTO は異なります。ウォームスタンバイは、少量のトラフィックをすぐに処理できます。次に、デプロイ済みのインフラストラクチャをスケールアウトする必要があります。これにより、パイロットライトよりもRTO 時間が短くなります。パイロットライトでは、ワークロードがリクエストを処理する前にインフラストラクチャをデプロイしてからリソースをスケールアウトする必要があるためです。

パイロットライトまたはウォームスタンバイによるリカバリ

災害が発生した場合、リカバリが成功するかどうかは、災害イベントの検出、リカバリリージョン内のワークロードの復元、およびリカバリリージョンにトラフィックを送信するためのフェイルオーバーに依存します。

1. 検出

前回のブログ記事で、RTOの短縮には迅速な検出がどれほど重要であるかを示し、これを実現するためのサーバーレスアーキテクチャを共有しました。これは、次のようなメトリクスに基づいてワークロードの健全性を判断できる Amazon CloudWatch アラームの一部に依存しています。

サーバーの生死に関するメトリクス（ping など）は、それだけでは DR の判断材料としては不十分です。
エラー率や応答遅延などのサービスAPIメトリクスは、ワークロードの健全性を把握するための適した方法です。
サービス検証テストは、API 操作の機能と正しさに関するメトリクスを提供します。Amazon CloudWatch Synthetics を使用すると、サービスを呼び出してレスポンスを検証するスクリプトを作成できます。これにより、ワークロードの健全性に関する優れた洞察が得られます。
ワークロードの主要パフォーマンス指標（KPI）は、ワークロードの健全性を理解するために使用できる最高のメトリクスの1つです。KPI は、ワークロードが意図したとおりに実行され、顧客のニーズを満たしているかどうかを示します。たとえば、e コマースのワークロードでは、注文レートが調べられます。注文レートは時間とともに常に変化するため、CloudWatch Anomaly Detectionを使用して、注文の落ち込みが正常でないかどうかを検出できます。

2. 復元

AWS コマンドラインインターフェイス（AWS CLI）または AWS SDK を使用して、AWS Lambda 関数の同時実行数、Amazon Elastic Container Service（Amazon ECS）タスクの数、EC2 Auto Scaling グループ内の必要な EC2 容量など、リソースの希望数をスケールアップできます。クラウドでは、リソースを簡単に作成または削除できます。

また、AWS CloudFormation はこれらの更新を行うための強力なツールです。CloudFormation のパラメータと条件関数を使用して、アクティブスタック（プライマリリージョン）または待機スタック（リカバリリージョン）の両方を作成できる 1 つのテンプレートを作成できます。以下は、CloudFormation テンプレートからの抜粋です。パラメータ ActiveOrPassive に “active” または “passive” を指定することで、EC2 インスタンスがデプロイされるかデプロイされないかを決定できます。テンプレート全体はこちらからダウンロードできます。この例では、2 つのオプションから選択するには、!if 関数で DesiredCapacity の値を設定します。2 つ以上のオプションについては、!findInMap 関数も良い選択です。

Parameters:
  Web1AutoScaleDesired:
    Default: '3'
    Description: The desired number of web instances in auto scaling group
    # other properties omitted
  Web1AutoScaleMax:
    Default: '6'
    Description: The maximum number of web instances in auto scaling group
    # other properties omitted
  ActiveOrPassive:
    Default: 'active'
    Description: Is this the active (primary) deployment or the passive (recovery) deployment
    Type: String
    AllowedValues:
      - active
      - passive
    ConstraintDescription: enter active or passive, all lowercase

# Determine whether this is an active stack or passive stack
Conditions:
  IsActive: !Equals [!Ref "ActiveOrPassive", "active"]

Resources:
  #https://docs.thinkwithwp.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html
  WebAppAutoScalingGroup:
    Type: 'AWS::AutoScaling::AutoScalingGroup'
    Properties:
      MinSize: !If [IsActive, !Ref Web1AutoScaleDesired, 0]
      MaxSize: !Ref Web1AutoScaleMax
      DesiredCapacity: !If [IsActive, !Ref Web1AutoScaleDesired, 0]
      # other properties omitted

パラメータ値は、図 4 に示すように AWS マネジメントコンソールで設定できます。ここでは “passive” に設定され、EC2 インスタンスはデプロイされません。

図 4.パラメータを使用して CloudFormation スタックの ActiveOrPassive を “passive“ に設定する

プロセスを自動化するには、AWS CLI を使用してスタックを更新し、ActiveOrPassive の値を変更することもできます。次のコマンドは、EC2 Auto Scaling グループを更新します。現在 EC2 インスタンスがないため、3 つ（Web1AutoScaleDesired の値）EC2 インスタンスを追加します。新しいテンプレートは必要ありません。すなわち、このコマンドはパラメータ値をactiveに更新するだけです。

aws cloudformation update-stack \
    --stack-name SampleWebApp --use-previous-template \
    --capabilities CAPABILITY_NAMED_IAM \
    --parameters ParameterKey=ActiveOrPassive,ParameterValue=active

3. フェイルオーバー

フェイルオーバーは、プライマリリージョン（ワークロードが実行できなくなったと判断した場所）からリカバリ・リージョンに本番トラフィックをリダイレクトします。DNS に Amazon Route 53 を使用している場合は、プライマリリージョンとリカバリリージョンの両方のエンドポイントを 1 つのドメイン名で設定できます。次に、そのドメイン名のトラフィックを受信するエンドポイントを決定するルーティングポリシーを選択します。

ヘルスチェックの設定に基づいて、プライマリが正常でない場合、フェールオーバールーティングによって自動的にトラフィックがリカバリリージョンに送信されます。このような完全自動フェールオーバーは慎重に使用する必要があります。ここで説明するベスト・プラクティスを使用しても、リカバリ時間とリカバリ・ポイントはゼロより長くなり、可用性とデータが失われます。必要ないときにフェールオーバーすると（誤報）、それらの損失が発生します。必要に応じて、元の場所にフォールバックすると、同様の損失が発生します。

加重ルーティングを使用すると、人の操作によって開始される完全自動フェールオーバーを設定できます。このポリシーでは、プライマリリージョンの重みを 100 に設定し、リカバリリージョンを 0 に設定します。AWS CLI または AWS SDK を使用して、フェイルオーバーをスクリプト化できます。障害が発生したプライマリを 100 から 0 に変更し、リカバリリージョンを 100 に設定します。

Route 53 および DNS レコードを使用する代わりに、AWS Global Acceleratorを使用してフェイルオーバーを実装することもできます。カスタマートラフィックは 200 を超えるエッジロケーションの最も近い場所にオンボーディングされ、AWS ネットワークを介して設定したエンドポイントに移動します。これにより、レイテンシーが低下します。ここでも、自動ルーティングにエンドポイントヘルスチェックを使用したり、トラフィックダイヤルを使用して各エンドポイントへのトラフィックの割合を設定したりできます。

まとめ

災害時には、パイロットライト、ウォームスタンバイともに、データ損失（RPO）を抑制する機能を提供します。どちらもダウンタイムを抑えることができる十分なRTO性能を備えています。この2つの戦略では、RTOを重視するかコストを重視するかを選択することができます。

Amazon Web Services ブログ