【CFnテンプレ付】FISでAZ/Region障害を“安全に”擬似再現して可用性検証してみた

はじめに

GMOコネクトの永田です。

AWSのAZ障害とRegion障害を想定した障害試験を、Fault Injection Service (FIS) を使って擬似的に実施しましたので、その時のポイントをまとめます。

まとめ

• 簡易なAZ障害/Regionダウンシナリオ（妥協したシナリオ）なら aws:network:disrupt-connectivity のみでも実施は可能
• FISもCloudFormationで実装可能
• FISの利用時、注意点（制約事項）あり

FISで利用したActionの考え方

FISでは、発生させる障害のActionが色々あり、どれを使うと良いんだろう？は、悩みました。

ECSアクションなど色々見た結果（ターゲットはELB+ECSな構成）、AZ障害相当、Region障害相当の定義として以下としました。（妥協したとも言う）

• AZ障害相当
  • VPCの該当AZに対する通信IN/OUTが100%全て停止
  • 実際に100%全部落ちるというケースは少ないものの、まずは極端な例であっても簡易な考え方にしたかった
• Region障害相当
  • VPCの通信IN/OUTが全て停止
  • 実際に100%全部落ちるというケースは少ないものの(ry

なお、上記の条件であれば、FISではなくNetworkACLでも実現はできます。（disrupt-connectivityの中身がNACL）

P.15

aws:network:disrupt-connectivity,
※サブネットに対してNACLを用いたN/W接続拒否

ただ、FISは元々のNACLをクローンして実験が終わったら自動で復元してくれますので、手動でNACLを設定・削除するのに比べると安全であり、FISを利用することにしました。

aws:network:disrupt-connectivity

ターゲットサブネットに関連付けられた元のネットワークアクセスコントロールリスト (ネットワーク ACL) を一時的にクローンすることで、ターゲットサブネットへの指定されたトラフィックを拒否します。FIS は、クローンされたネットワーク ACL に拒否ルールを追加します。このネットワーク ACL には、タグ managedbyFIS=true があり、アクションの期間中、サブネットに関連付けます。アクションが完了すると、FIS はクローンされたネットワーク ACL を削除し、元のネットワーク ACL の関連付けを復元します。

FIS aws:network:disrupt-connectivity のCloudFormation作成

方針が決まったので、じゃあFISをCloudFormationで作ろう！、と思ったのですが検索しても全然情報が出てきませんでした😭（Amazon Qのコード補完でも期待したものが候補にでてこなかったです。。。）

AWS Consoleの画面上、対象のVPCを指定したり、AZを選択したりは出来るのですが、CFn Referenceを見ても説明が見当たりませんでした。

と言うことで試行錯誤し、結果的に以下で実施したい内容は実現できました。

• Region障害相当のaws:network:disrupt-connectivity CloudFormation

  FisExperimentTemplateNetworkDown:
    Type: AWS::FIS::ExperimentTemplate
    Properties:
      Description: Experiment to simulate network down
      Targets:
        FisTargetSubnet:
          ResourceType: aws:ec2:subnet
          Parameters:
            - vpc: !Ref FisTargetVpcId
          SelectionMode: ALL
      Actions:
        DisruptConnectivity:
          ActionId: aws:network:disrupt-connectivity
          Description: "Network down 10min"
          Parameters:
            duration: PT10M
            scope: all
          Targets:
            Subnets: FisTargetSubnet
      RoleArn: !GetAtt IAMRoleFisNetwork.Arn
      StopConditions:
        - Source: none

• AZ障害相当のaws:network:disrupt-connectivity CloudFormation

  FisExperimentTemplateNetworkDown:
    Type: AWS::FIS::ExperimentTemplate
    Properties:
      Description: Experiment to simulate network down
      Targets:
        FisTargetSubnet:
          ResourceType: aws:ec2:subnet
          Parameters:
            - vpc: !Ref FisTargetVpcId
              availabilityZoneIdentifier: !Ref FisTargetAz
          SelectionMode: ALL
      Actions:
        DisruptConnectivity:
          ActionId: aws:network:disrupt-connectivity
          Description: "Network down 10min"
          Parameters:
            duration: PT10M
            scope: all
          Targets:
            Subnets: FisTargetSubnet
      RoleArn: !GetAtt IAMRoleFisNetwork.Arn
      StopConditions:
        - Source: none

FIS aws:network:disrupt-connectivity の注意点（制約事項）

便利なFISですが、いくつか注意点（制約事項）があります。
今回利用したaws:network:disrupt-connectivityでは以下が注意点として挙げられます。

(制約1) 同一Subnetは通信が継続する

all - サブネットに出入りするすべてのトラフィックを拒否します。このオプションでは、サブネット内のネットワークインターフェースに出入りするトラフィックを含め、サブネット内トラフィックが許可されることに注意してください。

と言うことで、仮に同じSubnet内にELBとECSがある場合、Health checkはOKのままとなり、ELB targetがUnHealthyとなりません。

(制約2) ECSのタスクは制限されているAZでも起動してしまう

FISの内部的にはあくまでNACLで制限しているため、NACL制限されているAZにも新しいtaskが起動してしまうことがありました。ELB Health checkがUnhealthyとなった後、どのAZで起動するかはFargateのブラックボックスであり、NACLは考慮していないためのようです。

なお、NACLのあるSubnetで起動しようとするとImage pullに失敗し、タイムアウトまでかなり待たされます。そのため特定AZがダウンしても、別のAZで復旧してキャパシティが戻ることをFISで確認しようとすると、1/3のガチャ（Tokyo 3AZ）になります。

（再掲）まとめ

• 簡易なAZ障害/Regionダウンシナリオ（妥協したシナリオ）なら aws:network:disrupt-connectivity のみでも実施は可能
• FISもCloudFormationで実装可能
• FISの利用時、注意点（制約事項）あり

弊社では、AWSを使ったサービスの開発や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ: https://gmo-connect.jp/contactus/