はじめに
オンプレミスネットワークの場合は機器筐体やリンクなどのシングルポイント障害に加えて、電源系統障害、拠点障害、地域障害などもテストするのが定番かと思います。
クラウドネットワークの場合はどうでしょうか。特に、クラウド～オンプレミス間が接続されるハイブリッドクラウドでどうやってテストしてる？とよく質問いただくので整理してみました。
障害テストの必要性
AWSマネージドのためテストできない場合もありますが、ユーザが指定したパラメータが誤っていると回復しない可能性もありますので、障害テストは可能な限り実施すべきかと思います。
AWS Well-Architectedフレームワークの信頼性の柱、基盤や障害管理などのベストプラクティス領域でも以下のような障害テストの必要性が謳われています。
- REL02-BP02 クラウド環境とオンプレミス環境間の冗長接続をプロビジョニングする
許容可能な復旧時間を定義し、その要件を満たすかどうかをテストする必要があります。
- REL12-BP05 カオスエンジニアリングを使用して回復力をテストする
予期せぬ中断から影響を最小限に抑えて回復できることへの信頼を得ることができます。
障害テストのターゲット
ターゲットは、①オンプレミス機器、②キャリア回線、③クラウドリソース、④リージョン/アベイラビリティゾーン、⑤オンプレミス拠点/接続ロケーションなどの構成要素単位で検討します。
障害テストのサービスおよび方法
オンプレミス機器
機器の電源ケーブル抜線によって障害を再現させます。電源OFFでは終了処理が行われて、切替動作が変わってしまう可能性があるためです。従来の方法と変わりなし。
キャリア回線
ONU～オンプレミス機器間のLANケーブル抜線によって障害を再現させます。I/F閉塞では終了処理が行われて、切替動作が変わってしまう可能性があるためです。従来の方法と変わりなし。
クラウドリソース
ユーザが冗長化しているサービスは、障害テストが必要かつ実施可能です。一方、AWSマネージドで冗長化しているサービスは、障害テストが不要かつ実施不可能です。
| 障害テストが実施できるサービス | 障害テストが実施できないサービス |
|---|---|
など |
など |
DirectConnect
- BGPフェイルオーバーテスト機能を用い、VIF単位でBGPピア間の障害(1分間～72時間)を再現させます。障害テスト目的だけでなく、通信不安定時の強制切り替えでも有効か。
Site-to-Site VPN
- BGPフェイルオーバーテストのような機能は無く、VGWやTGWのトンネル接続オプション変更やオンプレミス機器のアクセスフィルタなどで障害を再現させます。
EC2（SD-WANアプライアンスなど）
- AWS FIS(Fault Injection Simulator)サービスを用い、インスタンス停止により障害を再現させます。その他のCPU/メモリの高騰等は、インスタンスへSSMエージェントがインストールできず、障害を再現できない場合があります。
リージョン/AZ
リージョン/AZ内のインスタンス停止やルート削除によって障害を再現させます。リソース削除および再作成は作業リスクが大きいため避けるようにします。
(2024-01-20 追記)
AWS FIS(Fault Injection Simulator)サービスを用い、「aws:network:disrupt-connectivity」アクションですべてのサブネットへのトラフィックを止めた方がスマートですね。
オンプレミス拠点/接続ロケーション
各オンプレミス機器の障害を再現させます。ただし、接続ロケーションがパートナー提供の場合にはユーザが制御できないため、各DirectConnectの障害で代替します。
まとめ
障害テストはAWSマネージドによりユーザ負担が軽減される一方、どのようなテストが必要かつ実施可能か整理することが大事です。
