翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
テスト環境の作成
このガイドでは、サンプルアーキテクチャを使用して AWS DevOps Agent のインシデント対応機能を検証するための実践的なテストを提供します。本番稼働用システムを接続する前に DevOps エージェントをテストする場合は、この補足を使用します。
前提条件
AWS 管理アクセス権を持つ アカウント
AWS DevOps エージェントの自動作成ロールフローを使用して作成および設定された DevOps エージェントスペース
コストと安全性の概要
コスト保護
EC2 テスト: 2 時間無料 (AWS 無料利用枠) または ~0.02 USD
Lambda テスト: 無料 (1 か月あたりの無料利用枠あたり 100 万リクエスト)
CloudWatch: 無料 (10 個のアラーム、基本メトリクスを含む)
予想される総コスト: テスト完了時に 0.00~0.05 USD
これらのテストにおける安全機能
自動終了: 組み込みの自動シャットダウン
無料利用枠対象: 最小のインスタンスタイプを使用
制限された範囲: 最小の分離されたテストリソース
簡単なクリーンアップ: すべてを削除するためのシンプルなコンソールステップ
本番環境への影響なし: テスト環境を完全に分離する
テスト用に AWS アカウントをセットアップする
重要
インフラストラクチャリソースは、DevOps エージェントスペースのプライマリクラウド AWS アカウントを作成したアカウントにデプロイする必要があります。特定のリージョンは関係ありません。
AWS コンソールにログインする: https://console.aws.amazon.com
DevOps エージェントスペースがあるのと同じ AWS アカウントで作業していることを確認します。
テストリソースには任意のリージョンを使用できます
注記
DevOps エージェントのプライマリアカウントと作成するテスト環境リソース間の 1:1 マッピングにより、テストのセットアップが簡素化されます。DevOps エージェントスペースを簡単に拡張してセカンダリアカウントを含めたり、クロスアカウント調査を有効にしたりできます。
テストを選択する
テストは個別に実行することも、両方を同時に実行することもできます。
テストオプション A: EC2 CPU 容量テスト
目的: EC2 パフォーマンスの問題を検出して調査する AWS DevOps Agent の機能を検証する
推定時間: 5 分のセットアップ + 10 分の自動実行
難易度: 完全自動化 (手動ステップは不要)
テストオプション B: Lambda エラー率テスト
目的: Lambda 関数エラーを検出して調査する AWS DevOps エージェントの機能を検証する
推定時間: 10 分のセットアップ + トリガーまで 2 分
難易度: 非常に簡単
テストオプション A: EC2 CPU 容量テスト
ステップ 1: EC2 テスト用に CloudFormation スタックをデプロイする
CloudFormation を使用してテストリソースを作成します。これにより、 AWS DevOps Agent はテストリソースを適切に追跡して調査できます。
CloudFormation に移動します。
AWS コンソールでCloudFormation」を検索し、CloudFormation をクリックします。
スタックの作成 > 新しいリソースを使用する (標準) をクリックします。
テンプレートのアップロード:
という名前の新しいローカルファイルを作成する
AWS-DevOpsAgent-ec2-test.yamlこの CloudFormation テンプレートをコピーしてファイルに貼り付けます。
-
AWSTemplateFormatVersion: '2010-09-09' Description: 'AWS DevOps Agent EC2 CPU Test Stack' Parameters: MyIP: Type: String Description: Your current IP address for SSH access (find at https://whatismyipaddress.com) Default: '0.0.0.0/0' Resources: # Security Group for SSH access TestSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupName: AWS-DevOpsAgent-test-sg GroupDescription: AWS DevOps Agent beta testing security group SecurityGroupIngress: - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: !Ref MyIP Description: SSH access from your IP Tags: - Key: Name Value: AWS-DevOpsAgent-Test-SG - Key: Purpose Value: AWS-DevOpsAgent-Testing # Key Pair for SSH access TestKeyPair: Type: AWS::EC2::KeyPair Properties: KeyName: AWS-DevOpsAgent-test-key KeyType: rsa Tags: - Key: Name Value: AWS-DevOpsAgent-Test-Key - Key: Purpose Value: AWS-DevOpsAgent-Testing # EC2 Instance for CPU testing TestInstance: Type: AWS::EC2::Instance Properties: InstanceType: t3.micro ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-x86_64}}' KeyName: !Ref TestKeyPair SecurityGroupIds: - !Ref TestSecurityGroup UserData: Fn::Base64: !Sub | #!/bin/bash yum update -y yum install -y htop # Create the CPU stress test script cat > /home/ec2-user/cpu-stress-test.sh << 'EOF' #!/bin/bash echo "Starting AWS DevOpsAgent CPU Stress Test" echo "Time: $(date)" echo "Instance: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)" echo "" # Get number of CPU cores CORES=$(nproc) echo "CPU Cores: $CORES" echo "" echo "Starting stress test (5 minutes)..." echo "This will generate >70% CPU usage to trigger CloudWatch alarm" echo "" # Create CPU load using yes command echo "Starting CPU load processes..." for i in $(seq 1 $CORES); do (yes > /dev/null) & CPU_PID=$! echo "Started CPU load process $i (PID: $CPU_PID)" echo $CPU_PID >> /tmp/cpu_test_pids done # Auto-cleanup after 5 minutes (sleep 300 && echo "Stopping CPU load processes..." && kill $(cat /tmp/cpu_test_pids 2>/dev/null) 2>/dev/null && rm -f /tmp/cpu_test_pids) & echo "" echo "CPU load processes started for 5 minutes" echo "Check CloudWatch for alarm trigger in 3-5 minutes" EOF chmod +x /home/ec2-user/cpu-stress-test.sh chown ec2-user:ec2-user /home/ec2-user/cpu-stress-test.sh # Create auto-shutdown script (safety mechanism) cat > /home/ec2-user/auto-shutdown.sh << 'SHUTDOWN_EOF' #!/bin/bash echo "Auto-shutdown scheduled for 2 hours from now: $(date)" sleep 7200 echo "Auto-shutdown executing at: $(date)" sudo shutdown -h now SHUTDOWN_EOF chmod +x /home/ec2-user/auto-shutdown.sh nohup /home/ec2-user/auto-shutdown.sh > /home/ec2-user/auto-shutdown.log 2>&1 & echo "AWS DevOpsAgent test setup completed at $(date)" > /home/ec2-user/setup-complete.txt Tags: - Key: Name Value: AWS-DevOpsAgent-Test-Instance - Key: Purpose Value: AWS-DevOpsAgent-Testing # CloudWatch Alarm for CPU utilization CPUAlarm: Type: AWS::CloudWatch::Alarm Properties: AlarmName: AWS-DevOpsAgent-EC2-CPU-Test AlarmDescription: AWS-DevOpsAgent beta test - EC2 CPU utilization alarm MetricName: CPUUtilization Namespace: AWS/EC2 Statistic: Average Period: 60 EvaluationPeriods: 1 Threshold: 70 ComparisonOperator: GreaterThanThreshold Dimensions: - Name: InstanceId Value: !Ref TestInstance TreatMissingData: notBreaching Outputs: InstanceId: Description: EC2 Instance ID for testing Value: !Ref TestInstance SecurityGroupId: Description: Security Group ID Value: !Ref TestSecurityGroup AlarmName: Description: CloudWatch Alarm Name Value: !Ref CPUAlarm SSHCommand: Description: SSH command to connect to instance Value: !Sub 'ssh -i "AWS-DevOpsAgent-test-key.pem" ec2-user@${TestInstance.PublicDnsName}'
-
CloudFormation コンソールで、テンプレートファイルのアップロードを選択します。
ファイルの選択 をクリックします。
AWS-DevOpsAgent-ec2-test.yamlファイルを選択する[次へ] をクリックします。
スタックの設定:
スタック名:
AWS-DevOpsAgent-EC2-Testパラメータ :
MyIP: デフォルトのままにします
0.0.0.0/0(必要に応じて後で保護できます)
[次へ] をクリックします。
スタックオプションを設定します。
デフォルトのまま、次へ をクリックします。
確認と作成:
AWS CloudFormation が IAM リソースを作成する可能性があることを確認する
送信 をクリックします。
完了まで待ちます。
スタックの作成には 3~5 分かかります
ステータスは から
CREATE_IN_PROGRESSに変わりますCREATE_COMPLETE重要: EC2 インスタンスは、 AWS DevOpsAgent が追跡できる CloudFormation スタックの一部になりました。
オプション: 安全な SSH アクセス (インスタンスに接続する場合のみ)
自動テストを実行するだけの場合は、このステップをスキップします。
EC2 セキュリティグループに移動します。
AWS コンソールで、EC2 → セキュリティグループに移動します。
検索
AWS-DevOpsAgent-test-sg
SSH ルールを更新します。
セキュリティグループの選択 → インバウンドルールタブ → インバウンドルールの編集
SSH ルールを検索する (ポート 22)
ソース
0.0.0.0/0を から IP に変更します。[YOUR_IP]/32https://whatismyipaddress.com
から IP を取得する ルールの保存 をクリックします。
ステップ 2: 自動テスト実行を待機する
自動テスト実行:
CPU ストレステストはインスタンスの起動から 5 分後に自動的に開始されます
手動による介入は不要 - 待機するだけで、テストは完全にバックグラウンドで実行されます
テストをモニタリングします。
インスタンスはテストを自動的に起動して準備します
スクリプトは 5 分間実行され、>70% の CPU 使用率を生成します。
CloudWatch アラームは合計 8~10 分以内にトリガーされます (5 分の遅延 + アラームの場合は 3~5 分)
オプション: 手動再実行 (追加テスト用):
インスタンスに接続する: EC2 コンソール →
AWS-DevOpsAgent-Test-Instance→ Connect → Session Managerストレステストを再度実行します。
./cpu-stress-test.shAWS DevOpsAgent のレスポンスを複数回テストするのに最適です
テストオプション B: Lambda エラー率テスト
ステップ 1: Lambda テスト用に CloudFormation スタックをデプロイする
CloudFormation に移動します。
AWS コンソールで、CloudFormation に移動します。
スタックの作成 → 新しいリソースを使用する (標準) をクリックします。
テンプレートをアップロードします。
という名前の新しいローカルファイルを作成する
AWS-DevOpsAgent-lambda-test.yamlこの CloudFormation テンプレートをコピーしてファイルに貼り付けます。
-
AWSTemplateFormatVersion: '2010-09-09' Description: 'AWS DevOpsAgent Lambda Error Test Stack' Resources: # IAM Role for Lambda function LambdaExecutionRole: Type: AWS::IAM::Role Properties: RoleName: AWS-DevOpsAgentLambdaTestRole AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole Tags: - Key: Name Value: AWS-DevOpsAgent-Lambda-Test-Role - Key: Purpose Value: AWS-DevOpsAgent-Testing # Lambda function that generates errors TestLambdaFunction: Type: AWS::Lambda::Function Properties: FunctionName: AWS-DevOpsAgent-test-lambda Runtime: python3.12 Handler: index.lambda_handler Role: !GetAtt LambdaExecutionRole.Arn Code: ZipFile: | import json import random import time from datetime import datetime def lambda_handler(event, context): print(f"AWS DevOpsAgent Test Lambda - {datetime.now()}") print(f"Event: {json.dumps(event)}") # Intentionally generate errors for testing error_scenarios = [ "Simulated database connection timeout", "Test API rate limit exceeded", "Intentional validation error for AWS DevOpsAgent testing" ] # Always throw an error for testing purposes error_message = random.choice(error_scenarios) print(f"Generating test error: {error_message}") # This will create a Lambda error that CloudWatch will detect raise Exception(f"AWS DevOpsAgent Test Error: {error_message}") Description: AWS DevOpsAgent beta test function - intentionally generates errors Timeout: 30 Tags: - Key: Name Value: AWS-DevOpsAgent-Test-Lambda - Key: Purpose Value: AWS-DevOpsAgent-Testing # CloudWatch Alarm for Lambda errors LambdaErrorAlarm: Type: AWS::CloudWatch::Alarm Properties: AlarmName: AWS-DevOpsAgent-Lambda-Error-Test AlarmDescription: AWS-DevOpsAgent beta test - Lambda error rate alarm MetricName: Errors Namespace: AWS/Lambda Statistic: Sum Period: 60 EvaluationPeriods: 1 Threshold: 0 ComparisonOperator: GreaterThanThreshold Dimensions: - Name: FunctionName Value: !Ref TestLambdaFunction TreatMissingData: notBreaching Outputs: LambdaFunctionName: Description: Lambda Function Name for testing Value: !Ref TestLambdaFunction LambdaFunctionArn: Description: Lambda Function ARN Value: !GetAtt TestLambdaFunction.Arn AlarmName: Description: CloudWatch Alarm Name Value: !Ref LambdaErrorAlarm TestCommand: Description: AWS CLI command to test the function Value: !Sub 'aws lambda invoke --function-name ${TestLambdaFunction} --payload "{\"test\":\"AWS DevOpsAgent validation\"}" response.json'
-
CloudFormation コンソールで、テンプレートファイルのアップロードを選択します。
ファイルの選択 をクリックします。
AWS-DevOpsAgent-lambda-test.yamlファイルを選択する[次へ] をクリックします。
スタックの設定:
スタック名:
AWS-DevOpsAgent-Lambda-Test[次へ] をクリックします。
スタックオプションを設定します。
デフォルトのまま、次へ をクリックします。
確認と作成:
AWS CloudFormation が IAM リソースを作成する可能性があることを確認する
送信 をクリックします。
完了まで待ちます。
スタックの作成には 2~3 分かかります
ステータスは に変わります
CREATE_COMPLETE
ステップ 2: Lambda エラーをトリガーする
Lambda コンソールに移動します。
AWS Lambda コンソールに移動する
関数を検索する
AWS-DevOpsAgent-test-lambda
関数をテストします。
テストタブをクリックします。
新しいイベントの作成 をクリックします。
イベント名:
AWS-DevOpsAgent-test-eventこの JSON ペイロードを使用します。
-
{ "test": "AWS DevOpsAgent validation", "timestamp": "2024-01-01T00:00:00Z" }
-
保存 をクリックします。
エラーの生成:
テストボタンを 3 回クリックします (それぞれ 10 秒待機)
各テストは意図的なエラーを生成します
CloudWatch アラームは 2~3 分以内にトリガーされます
AWS DevOpsAgent は、次にセットアップするオペレーターアプリで調査を使用してアラームを検出できるようになりました。
AWS DevOps エージェントの検出を検証する
ステップ 1: CloudWatch アラームのサニティチェック (オプション)
このステップは、上記のテストがアラーム状態になったことを確認するためのものです。
EC2 テストの場合:
CloudWatch コンソールで、アラームに移動します。
ストレステストを開始してから 3~5 分待ちます。
アラームにアラーム状態が表示されます
それでも「OK」の場合: さらに 2~3 分待ちます (CloudWatch メトリクスは遅延する可能性があります)
Lambda テストの場合:
AWS-DevOpsAgent-Lambda-Error-Testアラームを確認するテストが実行されてから 2~3 分以内にアラーム内が表示されるはずです
ステップ 2: AWS DevOps エージェント調査を開始する
AWS DevOps Agent AgentSpace を開く
管理者アクセスをクリックします。これにより、DevOps エージェントスペースウェブアプリが新しいウィンドウで開きます。
画面の右側にある調査の開始ボタンをクリックします。
次のフォームに入力します。
調査の詳細: 実行する調査を記述します。調査目標、調査対象領域、または関連情報についての詳細を含めます。
調査の開始点: 調査を開始する情報を記述します。アラーム、メトリクス、ログスニペットなどについて言及して、DevOps エージェントに作業の開始点を与えることができます。この場合、先ほど作成したアラームの概要を入力します。
インシデント日時 (ISO 8601 推奨): YYYY-MM-DDTHH:MMZ
調査に名前を付けます。例:
Oncall_investigation_1:2025-10-27インシデントのAWS アカウント ID
インシデントが発生したリージョン
Priority - AWS DevOpsAgent では、2 つの同時調査が可能です。Priority を使用すると、調査の実行順序を定義できます。
調査をクリックして調査を開始します。
ダッシュボードにリストされている調査をクリックします。調査の詳細画面が表示され、DevOps エージェントが実行している詳細な手順を表示できます。
期待される結果
EC2 テスト結果:
EC2 CPU アラームを検出する
根本原因を特定します:「CPU ストレステストワークロード」
タイムラインを表示: ストレステスト → CPU スパイク → アラーム
モニタリングとスケーリングに関する推奨事項を提供します
Lambda テスト結果:
Lambda エラー率の急増を検出
根本原因を特定します:「意図的なテスト例外」
タイムラインを表示: 関数の呼び出し → エラー → アラーム
エラー処理とモニタリングに関する推奨事項を提供します
クリーンアップ手順
クリーンアップテスト A (EC2 テスト)
自動クリーンアップ
インスタンスは 2 時間後に自動終了します (CloudFormation テンプレートに組み込まれています)
手動クリーンアップ (即時)
CloudFormation スタックの削除:
CloudFormation コンソールに移動する
AWS-DevOpsAgent-EC2-Testスタックの選択削除をクリックします
削除の確認
これにより、EC2 インスタンス、セキュリティグループ、キーペア、CloudWatch アラームなどのすべてのリソースが自動的に削除されます。 EC2 CloudWatch
クリーンアップテスト B (Lambda テスト)
CloudFormation スタックの削除:
CloudFormation コンソールに移動する
AWS-DevOpsAgent-Lambda-Testスタックの選択削除 をクリックします。
削除の確認
これにより、Lambda 関数、IAM ロール、CloudWatch アラームなどのすべてのリソースが自動的に削除されます。 CloudWatch
トラブルシューティング
一般的な問題
EC2 インスタンスに接続できません」
セキュリティグループを確認する: SSH (ポート 22) が IP に対して開いていることを確認します。
キーアクセス許可の確認: 実行
chmod 400 AWS-DevOpsAgent-test-key.pemパブリック IP の検証: インスタンスにはパブリック IP を割り当てる必要があります
インスタンスの待機: インスタンスが「実行中」状態であることを確認します
「アラームがトリガーされない」
メトリクスの待機: CloudWatch メトリクスが表示されるまでに 2~5 分かかる場合があります
CPU 負荷の確認: インスタンスへの SSH と を実行して CPU >70%
topを検証するストレステストの検証: を実行して
ps aux | grep yes、ロードプロセスが実行されているかどうかを確認します。延長待機: 最初のアラームトリガーには最大 7~8 分かかることがあります
テスト検証
Your AWS DevOp エージェントのテストは、次の場合に成功します。
技術検証
調査精度: EC2 テストの結果は、CPU 負荷が原因でアラームがトリガーされたことを正しく示す必要があります。Lambda テストの結果は、これが意図的な失敗であることを示す必要があります。
タイムラインの精度: 表示されているイベントの正しいシーケンス
Recommendation Quality: 提示された実用的な提案