Tweet
Tweet

Slide 1

Slide 1 text

AWS Fault Injection Serviceを使った 障害試験のシナリオと実施方法について TECH AND DESIGN STUDY #47 2024年10月30日 NRIネットコム株式会社 クラウド事業推進部 西本 悠馬

Slide 2

Slide 2 text

1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介 01 AWS Fault Injection Serviceについて 02 基盤における障害試験のシナリオの作成フロー 03 AWS Fault Injection Serviceを使った試験シナリオ例 04 まとめ 05

Slide 3

Slide 3 text

2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 1. 自己紹介

Slide 4

Slide 4 text

3 Copyright（C） NRI Netcom, Ltd. All rights reserved. ◼ 自己紹介 ⚫ 名前：西本悠馬 ⚫ 出身：奈良県 ⚫ 趣味：洋服、球技全般(最近は草野球が多い) ⚫ 経歴： • 2017年4月-2021年3月 • 統計学・データサイエンス分野を専攻(主に広告配信における効果測定など) • 2021年4月 • NRIネットコム株式会社 新卒入社 • 2021年7月 – 現在 • クラウド事業推進部に配属 • 顧客システムの要件定義・設計・開発・構築がメイン • WEBシステムが多い • 2023年4月 • 「2023 Japan AWS Jr. Champions」「2023 Japan AWS All Certifications Engineers」に選出 • 2024年4月 • 「2024 Japan AWS All Certifications Engineers」に選出 自己紹介

Slide 5

Slide 5 text

4 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2. AWS Fault Injection Serviceについて

Slide 6

Slide 6 text

5 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS Fault Injection Serviceのサービス概要 ◼ サービス概要 ⚫ フォールトインジェクション実験を実行するためのフルマネージドサービス • フォールトインジェクション実験とは・・・ • 意図的に障害を発生させることで、障害時におけるシステムの動作や回復性を確認する試験を指す ⚫ 料金 • 1アクション1分あたりで$0.1 ⚫ どうして意図的に障害を起こす必要があるのか？(※人によって解釈は違う) • 意図的に障害を引き起こし、システムの耐久性や回復性を確認する • 障害によってシステムにおける予想していない動作の発見につなげる • システム理解の促進 • 監視システムが正常に働き、開発者に連絡がいくプロセスが正常か • etc… ⚫ AWS Fault Injection Service(以降、AWS FIS)が対応しているサービス(2024/10/23時点) • Amazon CloudWatch • Amazon DynamoDB • Amazon EBS • Amazon EC2 • Amazon ECS • Amazon EKS • Amazon ElastiCache • Amazon RDS • Amazon S3 • AWS Systems Manager • Amazon VPC AWS Fault Injection Serviceについて AWS Fault Injection Simulator

Slide 7

Slide 7 text

6 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISでできるフォールトインジェクション実験の例 ◼ 実験例 ⚫ Amazon EC2 • サーバ停止、再起動 • 対象サーバに付与されているIAMロールによって行われたAPIリクエストにエラーレスポンスを返す • 負荷上昇(CPU/メモリ/IO) ⚫ Amazon ECS • インスタンス(EC2)の割合に応じたドレイン • プロセス停止 • ECSタスクの停止 ⚫ Amazon RDS • フェイルオーバーの実行 • インスタンス再起動 ⚫ Amazon DynamoDB • グローバルレプリケーションの停止 ⚫ Amazon VPC(Network) • 特定サブネットへのトラフィックの拒否 • availability-zoneの指定といったことも可能 AWS Fault Injection Serviceについて

Slide 8

Slide 8 text

7 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISで用意されているシナリオライブラリ ◼ 複数のアクションを組み合わせたシナリオが用意されている ⚫ 例）AZの可用性に関するシナリオ • 特定AZにおける様々なリソースに障害を注入するシナリオになっている AWS Fault Injection Serviceについて

Slide 9

Slide 9 text

8 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使うメリットとは ◼ AWS FISでしかできないことってほとんどない？ ⚫ AWS FISでできることは、人の手でもできることも多い • 例えば • RDSのフェイルオーバーや再起動はコンソールからも可能 • EC2に対するCPUへの負荷はサーバに接続してstressコマンドを実行する • 特定サブネットへのトラフィックの許可は、コンソールからNetwork ACLの設定を変更する • etc… ◼ AWS FISを使うメリットとは • あらかじめ用意された実験アクションが多数あり、試験準備時間の短縮につながる • テンプレートを使用することによるテストの一貫性の担保 • 試験実施後、変更された設定は元の状態に戻るため、戻し忘れがない AWS Fault Injection Serviceについて

Slide 10

Slide 10 text

9 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISでできるフォールトインジェクション実験フロー ◼ 実験フロー AWS Fault Injection Serviceについて 通常時におけるシステムの動作定義 システムが正常に動作している場合の目安 となるメトリクスの定義など 例）CPUの状況、サーバ数、レスポンスタイムなど 障害時におけるシステムの動作の仮説 障害発生時におけるシステム動作の仮説を立てる 例） 単一AZ障害が発生した場合にもシステム停止 にはならない フォールトインジェクション実験の実行 仮説を立てたうえで、各仮説を立証するための実験 方法を定め、実験を行う 実験結果の確認 仮説と実験結果を比較し、想定通りの結果となった のか、想定外の動作があったのかを整理する

Slide 11

Slide 11 text

10 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.基盤における試験シナリオの作成フロー

Slide 12

Slide 12 text

11 Copyright（C） NRI Netcom, Ltd. All rights reserved. 試験シナリオの作成 ◼ 試験シナリオ ⚫ 要件定義や方式設計に則ったシステムとなっているか改めて確認する • 例： • マルチAZ構成とし、単一AZ障害時にもシステム稼働をさせる • WEBサーバのCPUが90%を超えると、Slackに通知が飛ぶ • Auroraのプライマリインスタンス障害時には自動で、リードレプリカを昇格させ継続してシステムを稼働させる ⚫ システムにおいて、ありうる障害について考える • ECS、EC2を冗長化して稼働させているが、サーバ負荷が原因でダウンする • Auroraのプライマリインスタンスに高負荷がかかり、ダウンする • AZ障害により単一AZの利用ができなくなった • リージョン障害により、DRとして連携しているサービス間での遅延が発生する ⚫ 試験実施後の想定動作の仮説を立てる • 単一サーバ障害 • 試験：ECSタスクを1台停止させる • 想定動作：マルチAZ構成のため、システムは継続稼働する。また停止したタスクについては自動で復旧する • AZ障害 • 試験：特定AZのサブネットへの通信を妨げ、AZ障害を再現させる • 想定動作：システムは継続稼働する • サーバ高負荷 • 試験：WEBサーバに対して、負荷をかけSlack通知が飛ぶことを確認する • 想定動作：WEBサーバのCPUが90%を超えると、Slackに通知が飛ぶ。処理が一部重たくなる • DB障害に伴うフェイルオーバー • 試験：Auroraをフェイルオーバーさせる • 想定動作：フェイルオーバー中の数秒間は書き込み処理ができないが、その後継続してシステムが稼働する 基盤における試験シナリオの作成フロー

Slide 13

Slide 13 text

12 Copyright（C） NRI Netcom, Ltd. All rights reserved. 試験シナリオ例 基盤における試験シナリオの作成フロー 試験 関連リソース テスト確認項目 確認方法 確認結果 AWS WAFによる不正アクセ スのブロック WAF SQLiやXSSがAWS WAFでブロックされる こと 一般的な攻撃リクエストを投 げる WAFブロックされ、S3にログ が出力されたことを確認 ECS Execの禁止 ECS 通常時ECS Execができないことを確認す る ECS Execを実際に試す アクセスDenyになったことを 確認 ALB UnHealthyHostCount の監視 ALB, ECS ヘルスチェックの失敗に伴い、Unhealthy となったサーバを監視できているか確認す る ヘルスチェックパスを一時的に 変更する サーバがUnhealthyとなり、 通知がSlackに飛ぶことを確 認 EC2 CPU監視 EC2 WEBサーバに高負荷がかかった際に通知 ができるか・処理にどれくらい遅延がある かを確認する AWS FISを使用し、EC2に対 して高負荷をかける 監視通知がSlackに飛び、 通常位より1-2秒ほど遅延 が起きていることを確認 NAT Gateway障害 NAT Gateway NAT Gatewayの障害に伴う、WEBサー バ→Internetとの疎通不可 AWS FISを使用し、NAT GatewayのあるSubnetとの 疎通をできなくする Internetとの疎通ができなく なり、各種処理ができないこ と。agentとの疎通ができな いことでのSlack通知を確認 ECSタスクの停止 ECS アプリケーション障害により、ECSタスクが 全停止し、サービス閉塞されることを確認 する AWS FISを使用し、ECSタス クを全て停止する ECSタスクがダウンし、ヘルス チェックに失敗したことで Sorryページに画面が遷移す るようになったことを確認する ◼ 基盤試験も様々 ⚫ 障害試験の他、機能試験や監視・通知試験など

Slide 14

Slide 14 text

13 Copyright（C） NRI Netcom, Ltd. All rights reserved. 試験シナリオ作成フロー 基盤における試験シナリオの作成フロー ◼ シナリオ作成フロー 要件定義・方式設計の確認 要件定義や方式設計を確認し、構成を再度確認 する 例）AZ障害時の動作など システムにおける障害ポイントを確認 構築したシステムにおいて障害点となるポイントを確認 する 例）ECSのタスク停止 シナリオを作成する 各設計や障害となりうるポイントを元に、試験シナリオ を作成する シナリオには想定している動作も仮説として立てておく 試験の実施・改善 シナリオを元に試験を実施し、仮説が正しかったかを 確認する 仮説とは異なる動作をした場合は改善案を検討する

Slide 15

Slide 15 text

14 Copyright（C） NRI Netcom, Ltd. All rights reserved. 4. AWS Fault Injection Serviceを使った試験シナリオ例

Slide 16

Slide 16 text

15 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISで必要なセットアップ AWS Fault Injection Serviceを使った試験シナリオ例 ◼ AWS FIS実行手順 ⚫ 実験テンプレートの作成 • どういったアクションを使うのか、ターゲットは何か、どれくらいの期間実行するかといった設定を行う • また、実験時にはAWSの各API操作が利用されるため、IAMロールも用意する必要がある • IAMロールについては検証対象となるリソースへの権限のみ付与することが望ましい • 実験テンプレートで誤ったリソースを指定した場合の事故を防ぐため ⚫ 実験の開始 ⚫ 実行状況の確認 • 実験のステータスを確認し、失敗になっていないかなどを確認する • また進行中に、各種シナリオで定めた確認項目について確認する • 例1）DBのフェイルオーバー時に一時的なアクセス断があったか • 例2）ECSタスクが全て停止し、自動復旧するまでの期間のアクセスはSorryページにリダイレクトされていたか ⚫ 実験結果の確認 • 正常に終了したことを確認し、定常状態にシステムが戻ったことを確認する

Slide 17

Slide 17 text

16 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験シナリオ① AWS Fault Injection Serviceを使った試験シナリオ例 ◼ シナリオ① ECSコンテナの自動復旧 ⚫ 確認項目： • ECSタスクを停止し、自動で復旧(新規タスクが立ち上がる)すること • 冗長化しているため、システム自体は稼働していること ⚫ 実験の詳細 • 実行アクション：aws:ecs:stop-task • 実行期間：設定なし • 対象リソース：ECS Task(az-c)

Slide 18

Slide 18 text

17 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験シナリオ① 試験結果 AWS Fault Injection Serviceを使った試験シナリオ例 ◼ シナリオ① ECSコンテナの自動復旧 結果 ⚫ 仮説：新規タスクが立ち上がること、冗長化しているため接続断がないことが期待値 ⚫ 確認ポイント： • アクセス断があったか • 継続稼働が可能か • 停止後新規タスクがリクエストを受けられるようになるまでどれくらいかかったのか ⚫ 確認結果： • 停止後、1分後にコンテナが立ち上がり3分後に正常起動(通常時) • 画面操作をしている限り停止期間も無し

Slide 19

Slide 19 text

18 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験シナリオ② AWS Fault Injection Serviceを使った試験シナリオ例 ◼ シナリオ② 疑似的なAZ障害(特定Subnetへの通信不可) ⚫ 確認項目： • マルチAZ構成としているため、システム自体は稼働していること ⚫ 実験の詳細 • 実行アクション：aws:network:disrupt-connectivity • 実行期間：5分 • 対象リソース：ECS用Subnet(az-c)

Slide 20

Slide 20 text

19 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験シナリオ② 試験結果 AWS Fault Injection Serviceを使った試験シナリオ例 ◼ シナリオ② 疑似的なAZ障害(特定Subnetへの通信不可) 結果 ⚫ 仮説：2AZで稼働させ、冗長化しているため接続断がないことが期待値 ⚫ 確認ポイント： • アクセス断があったか • 継続稼働が可能か ⚫ 確認結果： • 実験開始後、対象SubnetのACL設定が書き換えられていることを確認 • 実行後、4分程度画面アクセスができないリクエストがあったことを確認(504が返却され想定外動作) • 正常にリクエストが通る場合もあった

Slide 21

Slide 21 text

20 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験シナリオ② 試験結果 AWS Fault Injection Serviceを使った試験シナリオ例 ◼ シナリオ② 疑似的なAZ障害(特定Subnetへの通信不可) 結果 ⚫ 仮説通りに行かなかった原因 • ALB(TargetGroup)が対象AZでの障害を検知できていなかった(Healthyとして認識しているため、リクエストを渡してしまっ ていた) • 根本原因：ヘルスチェック間隔の設定値がよくなかった • ヘルスチェック間隔が120秒となっており、計2回失敗するまで異常として認識できずリクエストを送り続けてしまった • 改善策：ヘルスチェック間隔や閾値の見直し(チェック間隔を狭めればいいというわけではない) ⚫ ヘルスチェック間隔を変更してリトライ • 間隔を5秒に変更し、再度テストを実施 • 異常とみなすまでの数秒リクエストが通らない場面があったが数十秒で異常と認識し、以降は正常に稼働

Slide 22

Slide 22 text

21 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験シナリオ③ AWS Fault Injection Serviceを使った試験シナリオ例 ◼ シナリオ③ アクセス過多によるサーバ高負荷 ⚫ 確認項目： • ECSタスクのCPU上昇に伴うアラート通知の確認 • AutoScalingの動作 ⚫ 実験の詳細 • 実行アクション：aws:ecs:task-cpu-stress • 実行期間：10分 • 対象リソース：ECS Task(all)

Slide 23

Slide 23 text

22 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験シナリオ③ 試験結果 AWS Fault Injection Serviceを使った試験シナリオ例 ◼ シナリオ③ アクセス過多によるサーバ高負荷 ⚫ 仮説：AutoScalingが機能し、スケールアウトすることで処理が分散されることが期待値 ⚫ 確認ポイント： • アクセス断があったのか • 処理遅延が見られたか • スケーリングにどれくらいかかったか • 設定している最大台数までスケーリングが可能か ⚫ 確認結果： • 負荷がかかり始めてからおよそ5分後にスケーリングし、新規タスクにもリクエストが行われていることを確認 • また、アクション終了後スケールダウンしたことを確認 • アクセス断や処理遅延は見られなかった(今回は単純にnginxでHTMLを返しているだけ)

Slide 24

Slide 24 text

23 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験シナリオ③ 補足 AWS Fault Injection Serviceを使った試験シナリオ例 ◼ ECS TaskにCPU負荷をかけるためにはひと手間かける必要がある ⚫ サイドカーコンテナとして、SSM Agentを動作させる必要がある • それに加えて、SSMに対する権限付与などが追加で必要になる • イメージ自体はAWSが用意しているため、それを使用すればよい(設定もそこまで大変ではない) ⚫ AutoScalingが機能するかという観点での試験としてはいいが、実際には性能試験を通じてここの動作確認を行うのがいいよう に個人的には思う

Slide 25

Slide 25 text

24 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWS FISを使った試験 失敗することも AWS Fault Injection Serviceを使った試験シナリオ例 ◼ 権限不足などを理由に処理に失敗することも ⚫ 権限不足といった原因を確認してリトライする • AWS FISで使用できるマネージドポリシーも多く用意されている(AWSFaultInjectionSimulatorXXXXX)

Slide 26

Slide 26 text

25 Copyright（C） NRI Netcom, Ltd. All rights reserved. 5. まとめ

Slide 27

Slide 27 text

26 Copyright（C） NRI Netcom, Ltd. All rights reserved. ◼ まとめ ⚫ AWS FISでは様々サービスの障害試験を行うことが可能 ⚫ 障害試験はあくまで、仮説を立てたうえでその仮説を立証するための試験であり、実験が可能だからという理由で行うものでは ない ⚫ システム理解・仮説・試験・改善のサイクルを繰り返すことで、システムをより強化できる まとめ

Slide 28

Slide 28 text

No content