翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 実験結果ドキュメント
## 設定
実験の特定の設定を文書化します。例:
+ 1 秒あたり合計 85 件のリクエストを発行する 5K ユーザーをシミュレートするように設定されたロード生成。
## 前提条件
+ ペット導入サイトがアルファテスト環境で実行されていることを確認しました。
+ 実験テンプレートが、EKS クラスターで実行されている PetSite アプリケーションポッドに CPU ストレスを適用するように設定されていることを確認します。 アプリケーションポッドは Kubernetes ラベル で識別されました`app=petsite`。
+ ロードが実行され、1 秒あたり 85 件のリクエストが生成されていることが確認されました。
## 定常状態
定常状態を達成するために実行されたステップと、その検証方法を文書化します。例:
ペット導入サイトのテストデプロイでは、定常状態をシミュレートするために 85 RPS の負荷が生成されています。CloudWatch RUM と CloudWatch ダッシュボードがレビューされ、すべてのビジネスメトリクスとアプリケーションメトリクスが実験の実行前に正常範囲内にあったことが確認されました。
オブザーバビリティデータ：
| 予想 | 観測値 |
| --- | --- |
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-result.html) |  |
## フォールトインジェクション
AWS FIS は、実験テンプレート (リンクを提供) を使用して障害を挿入するために使用されます。実験は 10 分間実行するように設定され、ワーカーノードで CPU ストレスが 60% を超えた場合はロールバックが設定されました。
## 障害観測
CloudWatch RUM と CloudWatch ダッシュボードは、アプリケーションの定常状態 (LCP メトリクスを使用して定義) を追跡するためにレビューされました。 スクリーンショットを次の表に示します。
オブザーバビリティデータ：
| 予想 | 観測値 |
| --- | --- |
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-result.html) |  |
## 復旧
ストレスが削除された後 ( AWS FIS 実験が完了し、ポッドから CPU ストレスが削除された後）、アプリケーションは通常の定常状態を再開する必要があります。 手動による介入は必要ありません。
オブザーバビリティデータ：
| 予想 | 観測値 (スクリーンショット） |
| --- | --- |
| LCP P99 は 4 秒未満で、平均は 2.5 秒未満である必要があります。 |  |