改善前

適当に書いた過去のブログ記事です。勘違いや誤った情報を含んでいますし、エビデンスも不足しています。

---
title: AWSの負荷試験にFISを使わなかった話
tags: AWS AWSFIS
author: kenken38
slide: false
---
AWSには、負荷テストのためのマネージドサービスとしてAWS Fault Injection Service（AWS FIS）というものがあります。

>AWS Resilience Hub の一部である AWS Fault Injection Simulator Service (FIS) は、アプリケーションのパフォーマンス、オブザーバビリティ、回復性を向上させるために、フォールトインジェクション実験を実行するためのフルマネージドサービスです。FIS は、さまざまな AWS のサービス全体でコントロールされたフォールト挿入実験をセットアップして実行するプロセスを簡素化するため、チームはアプリケーションの動作についての確信を深めることができます。

https://aws.amazon.com/jp/fis/

先日AWS上のサーバに対して負荷試験を行う必要があったのですが、このFISを利用しなかったため、その理由について残したいと思います。
（AWSやFISのネガキャンではなく、FISをより使いやすいサービスにしてもらうための改善要望という意味で書いています。）

# 結論
FISはJMeter等のように、「Webアプリケーションに対して大量のリクエストを送信し、レスポンス時間を確認する」といった使い方ができませんでした。

例えばAmazon ECSであればCPU使用率の負荷テストなどを実施できますが、Webアプリケーションの負荷テストには向いていないようです。
https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#ecs-actions-reference

つまりFISでCPU負荷を上げたうえで、別途サードパーティのツールを利用してアクセス時間の測定などをしないといけない、ということでしょうか。
いまいち痒い所に手が届いていない気がしてなりません。

# 最後に
ここまで書いてきましたが、もしFISや他のAWSサービスで上記のようなWebアプリケーションの負荷試験を実現できるよ、という場合はコメントで教えてください。

改善後

MCPを使って文書品質を向上した後です。文書内に誤りがあれば修正し、全体を通してエビデンスを付与します。

---
title: AWSの負荷試験にFISを使わなかった話
tags: AWS AWSFIS
author: kenken38
slide: false
---
AWS Fault Injection Service（AWS FIS）は、AWS上のワークロードに対して「フォールトインジェクション（意図的に障害・劣化を起こす）」実験を実行し、アプリケーションの応答を観測することでレジリエンス改善に役立てるためのマネージドサービスです（いわゆるカオスエンジニアリングの考え方に基づきます）。（根拠: https://docs.aws.amazon.com/fis/latest/userguide/what-is.html ）

またAWS FISは、実験中に実リソースへ実際の操作を行うため、事前の計画や、まずは本番相当の事前環境で試すことが推奨されています。（根拠: https://docs.aws.amazon.com/fis/latest/userguide/what-is.html ）

なお、AWS Resilience Hub は AWS FIS 実験の「管理（manage）」を提供しますが、FISがResilience Hubの“一部”というより、Resilience HubがFISを使って実験を組み立て・実行する形の連携です。（根拠: https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html ）

（参考: サービス概要ページ: https://aws.amazon.com/jp/fis/ ）

先日AWS上のサーバに対して負荷試験を行う必要があったのですが、このFISを利用しなかったため、その理由について残したいと思います。
（AWSやFISのネガキャンではなく、FISをより使いやすいサービスにしてもらうための改善要望という意味で書いています。）

# 結論
FIS単体では、JMeter等のように「Webアプリケーションに対して大量のリクエストを送信して、レスポンス時間を測る」タイプの**負荷生成（Load generation）**には向きませんでした。（根拠: https://docs.aws.amazon.com/fis/latest/userguide/what-is.html ）

理由は、AWS FISがやることは“リクエストを大量に投げる”ではなく、**AWSリソースに対する障害・劣化（disruptive events）を作って観測する**ことだからです。（根拠: https://docs.aws.amazon.com/fis/latest/userguide/what-is.html ）

例えばAmazon ECSに対しては、タスクにCPUストレスやI/Oストレスを与えるアクションが用意されています。一方で、これらは“アプリケーションに外部から大量アクセスを発生させる”というより、**対象リソース側にストレスを与える**タイプのアクションです。（根拠: https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html ）

つまり「外形監視的にレスポンスタイムを取りたい」「同時接続数を増やしたい」場合は、FISとは別に**負荷生成ツール**（JMeter等）や、それを運用する仕組みが必要になりがちです。（根拠: https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html ）

ただし、負荷試験中にFISでフォールトインジェクションを併用できれば、「負荷がかかった状態で障害を入れたときにSLOを守れるか」「復旧時間（RTO）を満たせるか」といったレジリエンス評価には繋げやすいはずです（この観点では、Resilience Hub がFIS実験の管理を提供します）。（根拠: https://docs.aws.amazon.com/fis/latest/userguide/what-is.html , https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html ）

# 代替案（AWS上で“負荷をかけたい”場合）

## 1) まず公式ガイドで「やっていいテスト」を確認する

AWS上でロードテストを実施すると、セキュリティ機構が動く可能性があります。また、ペネトレーションテストやDDoS系テストには制約があります。事前に公式ガイドと関連ポリシーを確認したうえで計画するのが安全です。（根拠: https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html , https://aws.amazon.com/ec2/testing/ , https://aws.amazon.com/security/penetration-testing/ , https://aws.amazon.com/security/ddos-simulation-testing/ ）

## 2) マネージドな負荷生成として「Distributed Load Testing on AWS」を使う

AWS Solutions の「Distributed Load Testing on AWS」は、テストシナリオを投入すると、AWS Step Functions / AWS Lambda / Amazon ECS（AWS Fargate）などを使って分散負荷テストを実行し、平均応答時間・成功/失敗数などをAmazon CloudWatchに記録する構成です。（根拠: https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/how-distributed-load-testing-on-aws-works.html ）

「大量リクエスト送信＋メトリクス確認」を目的にするなら、FISよりこちらの方が素直に要件に合うケースが多いと思います。（根拠: https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html ）

# 最後に
ここまで書いてきましたが、もし「FISだけでWebアプリケーションに対するリクエスト負荷を生成できる」方法や、FIS + 何かの組み合わせでうまくやっている事例があればコメントで教えてください。

使い方

詳しくはREADMEをご覧ください。
ここでは、VSCode+GitHub Copilotで利用するための手順を示します。

１．リポジトリをクローンする

２．以下のコマンドでMCPを起動する

cd mcp-server
npm install
npm run build

３．GitHub CopilotでMCPを利用可能にする

ツール一覧にawsDocEnrichmentが含まれていればOK。
なおawsDocEnrichment MCPはAWS公式ドキュメントのfetchを行いますが、AWS公式MCPのAWS Documentation MCPも使えるようにしておくとなおよいでしょう。

４．`/aws-doc-enrich`カスタムコマンドを実行する

品質向上したいドキュメントをコンテキストに含めればOK。
カスタムコマンドはリポジトリ内に含まれており、自由に編集しても構いません。