View a markdown version of this page

実験計画ドキュメント - AWS 規範ガイダンス
定常状態オブザーバビリティ要件実験定義仮説実験プロセス実験タイムライン実験結果特定された欠陥

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

実験計画ドキュメント

定常状態

プロセス名 ペット導入サイト

物理アーキテクチャ

（アーキテクチャ図へのリンク）

論理アーキテクチャ

（論理図へのリンク）

定常状態を定義する

最大コンテンツフルペイント (LCP) を使用して測定される平均ページロード時間は、ペット導入サイトでは 2.5 秒以下、99 パーセンタイルレイテンシー (P99) は 4.0 秒以下、ベースラインは 5000 人の同時ユーザーです。

定常状態メトリクス

ユーザーベース全体でキャプチャされた LCP メトリクスとゴールデンメトリクス (レイテンシー、スループット、エラー率、飽和度）。

定常状態オブザーバビリティ

LCP はユーザーのブラウザによってキャプチャされ、Amazon CloudWatch に送信され、CloudWatch RUM で検査されます。60 秒間、その期間内のすべてのリクエストについて、平均と P99 LCP 時間が集計されます。最上位のゴールデンメトリクスは、CloudWatch を使用してキャプチャされます。

定常状態を実現するプロセス

Grafana K6 は、約 5K00 人の同時ユーザーの通常の本稼働トラフィックレベルをシミュレートする負荷を作成するために使用されます。

オブザーバビリティ要件

チームは以下を表示できる必要があります。

  • 定常状態: アプリケーションが通常の状態であることを確認するために何が観察されますか？

  • 失敗条件: ダッシュボードに失敗条件はどのように表示されますか？ 例:

    • トリガーする必要があるアラーム

    • 生成する必要があるログ

  • 障害の影響: 影響を受けることが予想されるコンポーネント (影響の範囲) を表示するには、何を観察する必要がありますか？

  • 復旧: MTTR をキャプチャするために復旧を表示および測定する方法

  • デバッグ: 実験失敗の詳細をトラブルシューティングします。

次の表は、オブザーバビリティ要件グラフの提案と例を示しています。特定の実験に基づいて、観察すべき内容を定義する必要があります。

監視する必要があるもの オブザーバビリティツールへのリンク 観察内容

入力のソース

Grafana K6 ダッシュボード

  • 実行中のコンテナ数

  • 1 秒あたりのリクエスト

全体的なアプリケーションの状態

  • ペット導入 CloudWatch ダッシュボード

  • ペット導入ユーザーエクスペリエンスダッシュボード (RUM)

  • Amazon EKS の正常なノード数

  • Amazon EKS ノードの CPU 使用率

ワークフローの状態

ペット導入 CloudWatch ダッシュボード

LCP 時間、ゴールデンメトリクス

トレース

ペット導入 X-Ray ダッシュボード

  • リクエストのレイテンシー

  • Request count

  • 失敗数

ログ

ペットの採用 CloudWatch Logs

ポッドで発生したエラーは CloudWatch Logs に発行されます。

実験定義

実験名 Amazon EKS PetSite ポッド CPU ストレス

実験ソースコード

（実験ソースリポジトリへのリンク）

実験の説明

この実験では、PetSite アプリケーションポッドの CPU 使用率の増加がカスタマーエクスペリエンス全体にどのような影響を与えるかを調べます。実行中の各 PetSite ポッドに CPU ストレスを挿入することで、顧客への影響とその影響の程度を理解できます。

実験要件またはパラメータ

アプリケーション負荷: 本番稼働平均

ポッドラベルセレクタ: app=petsite

実験期間

10 分

環境

Alpha テスト環境

実験ターゲットリソース

PetSite アプリケーションポッド

負荷生成ツールを通じて導入される実験ベースライン

  • リクエストの 54% の LCP は <2.5 秒です。

  • リクエストの 46% の LCP は <4 秒です。

  • エラーは観察されません。

バックオフ条件

なし

仮説

次の場合 影響 復旧

PetSite アプリケーションポッドが通常の本番稼働レベルのトラフィックで 10 分間 60% を超える CPU 使用率を経験または引き起こした場合、定常状態はどうなりますか？

 

P99 が 4.0 秒以下のユーザーの P50 では、LCP 時間は 2.5 秒未満のままになります。コンシューマーは PetSite ランディングページをロードできる必要があります。

検出：

  • CPU ストレスは、CloudWatch で設定されたアラームによって検出されます。

  • LCP メトリクスは、ユーザーエクスペリエンスの低下に関するアラームも生成します。

自己修復：

  • マイクロサービスアーキテクチャの分散性は、ポッドの多くのインスタンスが複数のアベイラビリティーゾーンで実行されていることを意味します。 

  • EKS クラスターコントロールプレーンは、影響を受けたポッドからトラフィックを遠ざけ、ワーカーノードで新しいポッドを起動します。

復旧： 

CPU 使用率が正常に戻ると、LCP は自動的に回復します。

実験プロセス

以下のサンプルstep-by-stepします。

  1. すべての Amazon CloudWatch、CloudWatch RUM、 AWS X-Ray ダッシュボードへのアクセスと機能を検証します。

  2. アプリケーション環境の状態を検証します。

    1. CloudWatch ダッシュボードを使用して、EKS クラスターが正常であることを確認します。

    2. サンプルの URL にあるテストペット導入サイトアプリケーションのデプロイにアクセスしてください。

  3. 定常状態を実現するために負荷を開始します。

    1. ロードジェネレーターが実行されていて、1 秒あたり 5000 リクエストを送信していることを確認します。

    2. アプリケーションが定常状態になるまで 5 分待ちます。

    3. CloudWatch RUM ダッシュボードを使用して、アプリケーションの定常状態を確認します。

  4. 障害を開始する (実験):

    1. AWS FIS コンソールを開きます。

    2. pet-adoption-pod-stress 実験を実行します。

    3. コンソールで実験が実行されていることを確認します。

  5. アプリケーションに対する障害の影響を確認します。

    1. CloudWatch RUM および CloudWatch ダッシュボードからスクリーンショットをキャプチャし、異常なデータポイントを書き留めます。

    2. 実験が完了したら AWS FIS、追加のスクリーンショットをキャプチャして、アプリケーションがストレスなしで定常状態に戻ったかどうかを記録し、データポイントに異常をメモします。

    3. 定常状態が再開しない場合は、アプリケーションを復旧する手順を実行し、実行した手順を記録します。

  6. 環境が正常に戻ったことを確認します。

    • すべてのビジネス、ユーザーエクスペリエンス、アプリケーション、インフラストラクチャのメトリクスを確認して、システムが既知の状態に戻ったことを確認します。役に立つ場合は、ダッシュボードのスクリーンショットをキャプチャします。

実験タイムライン

ロード生成、障害の注入、アプリケーションの影響の観察、復旧からロード生成を停止したときに終了まで、end-to-endの実験のタイムラインを必ずキャプチャしてください。これは次の例に示されています。

カオス実験のタイムラインの例。

実験結果

実験実行 ID 実験結果

PET-ADOPT-EXP-23

（実験結果へのリンク）

特定された欠陥

  • Kubernetes クラスターは PetSite ポッドの CPU 障害を検出しなかったため、追加のデプロイをスケジュールしませんでした。

  • この実験の結果、4XX または 5XX エラー率の増加はありませんでした。

  • リソースの制約がある場合、LCP への影響を考慮してポッドのヘルスチェックを調整する必要があります。