目的

  • AWS FIS (AWS Fault Injection Service) アクション aws:network:disrupt-connectivity の Scope「all」と「availability-zone」 の挙動の違いを検証

構成

方法

  • VPC と ap-northeast-1a を対象に、各 Scope で aws:network:disrupt-connectivity を5分間実施
  • ALB のヘルスチェックが Unhealthy になるかを確認
  • プライベートサブネットに配置した EC2 からインターネットへアクセス可能かを確認
  • プライベートサブネットに配置した EC2 からプライベートサブネットに配置した Aurora (RDS) へアクセス可能かを確認
  • Aurora (RDS) がフェイルオーバーするかを確認

結果

all

ALB (ヘルスチェック) EC2 (インターネットアクセス) Aurora (EC2からのアクセス) Aurora (フェイルオーバー)
Unhealthy 不可 同じサブネットからは可能 しない

availability-zone

ALB (ヘルスチェック) EC2 (インターネットアクセス) Aurora (EC2からのアクセス) Aurora (フェイルオーバー)
healthy 可能
※構成に依存		 同じサブネットからは可能 しない

背景

  • AZ障害のシミュレーションをAWS FIS (AWS Fault Injection Service) でしたい
  • AWS FIS (AWS Fault Injection Service) には aws:network:disrupt-connectivity というネットワーク障害をシミュレートするアクションがある
  • aws:network:disrupt-connectivity には Scope というネットワークを切断する範囲を設定する項目がある
  • Scope には「all」と「availability-zone」という種類があるが、どちらがAZ障害のシミュレーションとして妥当かを検討するため、実際の挙動を検証

前提

AWS FIS (AWS Fault Injection Service) とは

AWS Fault Injection Service (AWS FIS) は、AWS ワークロードでフォールトインジェクション実験を実行できるマネージドサービスです。

AWS Fault Injection Service とは :
https://docs.aws.amazon.com/ja_jp/fis/latest/userguide/what-is.html

aws:network:disrupt-connectivity とは

対象サブネットと Scope に設定された範囲のネットワークトラフィックを切断するアクションです。

ネットワークアクション「aws:network:disrupt-connectivity」 :
https://docs.aws.amazon.com/ja_jp/fis/latest/userguide/fis-actions-reference.html#network-actions-reference

Scope とは

Scope の AWS ドキュメントを見てみましょう。
マネジメントコンソールから、実験テンプレート作成画面の Scope の情報より確認できます。

スコープは、ネットワーク接続の中断実験で拒否するネットワークトラフィックのタイプを定義します。

ネットワーク接続を切断させる範囲を選択できるというわけですね。

では、Scope にはどのような種類があるのでしょうか。
確認してみましょう。

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

availability-zone – 他のアベイラビリティーゾーンのサブネットとの間で送受信される VPC 内トラフィックを拒否します。

dynamodb – 現在のリージョンの DynamoDB のリージョンエンドポイントとの間で送受信されるトラフィックを拒否します。

prefix-list – 指定したプレフィックスリストとの間で送受信されるトラフィックを拒否します。

s3 – 現在のリージョンの Amazon S3 のリージョンエンドポイントとの間で送受信されるトラフィックを拒否します。

vpc – VPC との間で送受信されるトラフィックを拒否します。

AZ障害のシミュレーションをする場合、「all」か「availability-zone」を選択すればよさそうですね。

検証

ドキュメントだけでは、ALBやEC2、 RDSなどの各コンポーネントに対しどのような影響を与えるのかドキュメントからは判断できない部分がありましたので、よくある ALB + EC2 + Aurora (RDS) の構成を対象に、AZ障害をシミュレーションするにあたって重要となりそうな下記の4つ観点から、実際に検証してみました。

  • ALB のヘルスチェックが Unhealthy になるか
  • プライベートサブネットに配置した EC2 からインターネットへアクセス可能か
  • プライベートサブネットに配置した EC2 からプライベートサブネットに配置した Aurora へアクセス可能か
  • Aurora がフェイルオーバーするか

実験テンプレート

対象はどちらの Scope も ap-northeast-1a のサブネットです。

all

availability-zone

ALB のヘルスチェックが「unhealthy」になるか

all

結果 : 「unhealthy」

EC2 側から HealthCheck のアクセスログを確認してみます。

ap-northeast-1a

実験時間中、ap-northeast-1a 側には HealthChecker アクセスがありませんでした。

Scope「all」では、同じサブネット内トラフィックは許可されますが、ALBはパブリックサブネットに配置されているため、HealthChecker のアクセスが届かず、「unhealthy」となりました。

ap-northeast-1c

ap-northeast-1c 側には通常通り、HealthChecker のアクセスがありました。

availability-zone

結果 :「healthy」

EC2 側から HealthCheck のアクセスログを確認してみます。

ap-northeast-1a

実験時間中、同じAZである ap-northeast-1a 側のALB (10.0.1.166) からのみ、HealthChecker アクセスがありました。

Scope「availability-zone」では、 異なるAZ間のトラフィックのみが拒否されるため、異なるAZに配置されているALB (10.0.2.179) からの HealthChecker アクセスが届かずとも、同じAZに配置されているALB (10.0.1.166) からの HealthChecker アクセスが届くことにより、「healthy」となりました。

ap-northeast-1c

実験時間中、同じAZである ap-northeast-1c 側のALB (10.0.2.179) からのみ、HealthChecker アクセスがありました。

ap-northeast-1a 側と同様に、Scope「availability-zone」では、 異なるAZ間のトラフィックのみが拒否されるため、異なるAZに配置されているALB (10.0.1.166) からの HealthChecker アクセスが届かずとも、同じAZに配置されているALB (10.0.2.179) からの HealthChecker アクセスが届くことにより、「healthy」となりました。

プライベートサブネットに配置した EC2からインターネットへアクセス可能か

20秒毎に「8.8.8.8」へ ping を送信するスクリプトを利用し、検証しました。

all

結果 : 不可

実験時間中、「100% packet loss」となり、インターネットへのアクセスは不可となりました。

ap-northeast-1c 側は、実験時間中も、インターネットへのアクセスが可能でした。

availability-zone

結果 : 可能

実験時間中も、「0% packet loss」のままとなり、インターネットへのアクセスが可能でした。

Scope「availability-zone」では、 異なるAZ間のトラフィックのみが拒否されるため、本記事の構成のように、各AZにNATGWを配置し、各AZ単体でインターネットへのアクセス経路を確保しているような場合は、インターネットへのアクセスは可能ですが、片方のAZのみにNATGWを配置する等、AZ単体ではアクセス経路を確保できないような構成の場合は、インターネットへのアクセスが不可能となるAZが生じると思われます。

プライベートサブネットに配置した EC2 からプライベートサブネットに配置した Aurora へアクセス可能か

30秒毎に Aurora のクラスターエンドポイント (ライターインスタンス) へアクセスし、データを書き込むスクリプト
利用し、検証しました。

all

結果 : 同じサブネットからは可能

実験時間中、同じサブネットに配置した EC2 (sh-nakamura-test-fis-ap-northeast-1a) からの書き込みのみが記録されています。

Scope「all」では、サブネット内のネットワークインターフェースとの間で送受信されるトラフィックを含む、サブネット内トラフィックは許可されるため、Aurora のライターインスタンスと同じサブネットに配置した EC2 からのアクセスのみが届き、ライターインスタンスとは別のサブネットに配置した EC2 (sh-nakamura-test-fis-ap-northeast-1c) からのアクセスが届かなくなることで、同じサブネットに配置した EC2 (sh-nakamura-test-fis-ap-northeast-1a) からの書き込みのみが記録されました。

availability-zone

結果 : 同じサブネットからは可能

Scope「all」の場合と同様に、同じサブネットに配置した EC2 (sh-nakamura-test-fis-ap-northeast-1a) からの書き込みのみが記録されています。

Scope「availability-zone」では、他のアベイラビリティーゾーンのサブネットとの間で送受信される VPC 内トラフィックを拒否するため、Aurora のライターインスタンスと同じAZに配置した EC2 からのアクセスのみが届き、ライターインスタンスとは別のAZに配置した EC2 (sh-nakamura-test-fis-ap-northeast-1c) からのアクセスが届かなくなることで、同じAZに配置した EC2 (sh-nakamura-test-fis-ap-northeast-1a) からの書き込みのみが記録されました。

本記事の構成では、Auroraと同じサブネットに配置されたEC2からのアクセスのみを検証しておりますが、Scope「availability-zone」の場合は、サブネット単位ではなく、アベイラビリティーゾーン単位で切断されるため、同じAZ間であれば、異なるサブネットでもアクセスが可能であると思われます。

Aurora がフェイルオーバーするか

all

結果 : しない

availability-zone

結果 : しない

フェイルオーバーはしませんでした。
どちらのScopeにおいてもアクセス可能であるため、フェイルオーバーはしないようです。

結論

  • AZ障害のシミュレーションには、ALB のヘルスチェックが「unhealthy」になる点や EC2 のインターネットアクセスが不可となる点から、Scope「all」の方が妥当
  • Aurora (RDS) へのアクセスは可能なままとなるので、Aurora (RDS) の障害のシミュレーションには向かない
  • Aurora (RDS) のフェイルオーバーはしないので、FIS で Aurora (RDS) のフェイルオーバーを検証する場合は、アクション「aws: rds:failover-db-cluster」を使おう