Amazon Web Services ブログ

サポートオートメーションワークフロー(SAW)を使用したAWS環境の一般的な問題の診断

本ブログは 2024年8月9日に公開された「Using SAW to diagnose common issues in your AWS environment」を翻訳・一部改変したものとなります。

はじめに

AWS環境でシステム問題を手動でトラブルシューティングし解決することは、繰り返し作業が多く、間違いが起こりやすいです。 AWSサポートでは、AWSのお客様がセルフサービスによる診断と修復を可能にする機能であるサポートオートメーションワークフロー(SAW)を提供しています。 SAWは、AWS System Manager を活用して、トラブルシューティングプロセスを簡素化し、解決手順を示す、使いやすい厳選されたオートメーションランブックを提供しています。 ランブックを使用すると、接続問題のトラブルシューティング、権限エラーの診断、Amazon Elastic Compute Cloud(Amazon EC2)アクセスのリセットなどをすばやく行うことができます。 オートメーションランブック(プレフィックスは AWSSupport または AWSPremiumSupport です)は、Amazon EC2、Amazon Simple Storage Service(Amazon S3)Amazon Elastic Kubernetes Service(EKS)Amazon Elastic Container Service(ECS)などのさまざまなAWSサービスで利用できます。

この記事では、SAW がどのようにトラブルシューティングを自動化して、AWS環境の一般的な問題を診断するかを説明します。 オートメーションランブックによって合理化されたトラブルシューティングにより、システム問題の根本原因の分析と修復をより迅速に行うことができます。

サポートオートメーションワークフロー(SAW)とは

AWS Systems Manager

SAW について学ぶ前に、SAW の基盤である AWS System Managerとは何かを理解する必要があります。AWS Systems Managerは、AWSのアプリケーションとリソースの運用ハブであり、安全なエンドツーエンドの管理ソリューションです。 SAWは、Amazon Systems Manager Automation の上に構築されたオートメーションランブックです。これらのランブックは、AWSリソースの一般的な問題のトラブルシューティングや、ネットワークの問題の特定、ログの収集と分析などに役立ちます。

AWS環境でのトラブルシューティングと診断の強化

SAW は、Amazonの哲学の核心である、Customer Obsession を表しています。 SAWの起源は顧客体験に根ざしています。 お客様が AWS サポートにお問い合わせすると、当社のエンジニアが問題を解決し、解決策とともに問題を文書化します。 その中で、繰り返し発生する問題の傾向と、顧客体験を向上させる可能性を確認しました。 これらの洞察から、お客様をより良くサポートするため、セルフサービスを可能にするカスタムツールを構築しました。

SAWは、当社の経験、ベストプラクティス、長年にわたって学んだ教訓を活用して、反復的で時間のかかる手動の顧客タスクを排除し、発生する可能性のあるさまざまなトラブルシューティングの問題に対処するための強力なツールとなっています。 SAWが役立つユースケースには、SSH接続の問題のトラブルシューティング、EC2のディスク使用状況の分析、Amazon S3の問題の診断、Amazon EKSまたはAmazon ECS環境での重要なログの収集などがあります。 これらのランブックは、EC2インスタンスへのSSHアクセスがない場合や、インスタンスがAWS System Manager VPCエンドポイントの有効になっているプライベートサブネットにある場合に特に役立ちます。 次のような他のユースケースも見つかるかもしれません。

  • 診断、トラブルシューティング、修復:AWSPremiumSupport-Troubleshootec2DiskUsage を使用して、Amazon EC2インスタンスのディスク使用に関する問題を調査し、場合によっては修正します。さらに、ボリューム、パーティション、ファイルシステムの拡張をオペレーティングシステム(OS)レベルで自動化することもできます。
  • 管理分析と設定更新の自動化:AWSSupport-EnableVPCFlowLogs を使用して、AWS アカウントの複数のサブネット、ネットワークインターフェイス、VPC の Amazon VPC フローログを設定します。
  • コスト最適化と運用レビュー:AWSPremiumSupport-PostgreSQLWorkloadReview 使用して、Amazon Relational Database Service(Amazon RDS)のPostgreSQLデータベース使用統計のスナップショットをキャプチャします。
  • 診断目的のログ収集:たとえば、AWSSupport-CollecteKSInstanceLogs を利用して、クラスターの問題をトラブルシューティングするために、Amazon Elastic Kubernetes Service(Amazon EKS)からオペレーティングシステムレベルのログファイルを収集できます。

さまざまなユースケースに役立つ他のランブックを見るには、SAW のランディングページにアクセスしてください。役立つリストがあります。

SAWを使用して手動プロセスを合理化し、時間と労力を節約する方法を見ていきましょう。

SAWの使用を開始する

前提条件

SAWを続行するには、以下が必要です。

  • 使用する AWS Identity and Access Management(IAM)ユーザまたは IAM ロールに、Systems Manager コンソールにアクセスするための最低限必要な IAM 権限があることを確認してください。
  • ランブックを開始するために、次の権限があることを確認してください。
    • ssm:StartAutomationExecution
    • ssm:GetAutomationExecution
    • ssm:SendCommand
  • プレフィックス AWSPremiumSupport が付いたランブックを使用する場合は、AWSビジネスまたはエンタープライズサポートプランを利用していることを確認してください。
  • ランブックがEC2インスタンスでアクションを実行するためには、AWS Systems Manager Agent(SSM Agent)がインストールされ必要な権限が付与されていることを確認してください。そのためには、AWS 管理ポリシー AmazonSsmManagedInstanceCore を EC2インスタンスプロファイルに対応するIAMロールにアタッチする必要があります。

SAW ランブックを使用するには、AWS Systems Managerコンソールに移動し、使用するAWSリージョンを選択します。 Systems Managerコンソールで、左側のナビゲーションメニューの [共有リソース] セクションの下にある [ドキュメント] を探してください。 ここでは、Amazonが提供しているすべてのAWS Systems Managerドキュメントを見ることができます。
AWS サポートが管理する SAW ランブックを見つけるためには、検索ボックスに AWSSupport と入力してください。

まず、AWSSupport-ListEC2Resources ランブックを例に見てみましょう。 このドキュメントは、AWSアカウントの EC2 インスタンス、Elastic IP、EBSボリューム、Auto Scaling グループなどのEC2関連リソースを一覧表示するのに役立ちます。 ランブックを実行するには、「オートメーションを実行する」を選択します。

実行が完了すると詳細が表示され、実行結果の出力が表示されます。

AWS CLIを使用してランブックを実行する場合は、aws ssm start-automation-execution コマンドを使用することで実行できます。 以下は、すべてのAWSリージョンのEC2リソースを一覧表示するコマンド例です。

aws ssm start-automation-execution --document-name "AWSSupport-ListEC2Resources" --parameters '{"RegionsToQuery":["All"]}'

出力:

{
"AutomationExecutionId": "6053b7c6-7ec7-4b9b-b52c-04ddd912ede1"
}

オートメーションのステータスを取得するには、次のコマンドを実行します。

aws ssm describe-automation-executions \
--filter "Key=ExecutionId,Values=6053b7c6-7ec7-4b9b-b52c-04ddd912ede1"

上記コマンドの values の値を、手元の Automation ExecutionId に置き換えてください。
出力:

{
"AutomationExecutionMetadataList": [
{
"AutomationExecutionId": "6053b7c6-7ec7-4b9b-b52c-04ddd912ede1",
"DocumentName": "AWSSupport-ListEC2Resources",
"DocumentVersion": "7",
"AutomationExecutionStatus": "InProgress",
"ExecutionStartTime": "2024-03-13T09:53:45.685000+00:00",
"ExecutedBy": "arn:aws:sts::123456789012:assumed-role/Administrator/Admin",
"LogFile": "",
"Outputs": {},
"Mode": "Auto",
"CurrentStepName": "listVolumes",
"CurrentAction": "aws:executeScript",
"Targets": [],
"ResolvedTargets": {
"ParameterValues": [],
"Truncated": false
},
"AutomationType": "Local"
}
]
}

ユースケース

SSH接続の問題のトラブルシューティング

AWSSupport-TroubleshootSSH ランブックは、Linux SSHの一般的な問題を解決します。 このランブックは、Amazon EC2Rescue tool for Linux (ec2rl) の実行を効率化し、SSH経由でLinuxマシンにリモート接続できない一般的な問題を修正 します。 このランブックでは、AWS Systems Managerによって管理されていないEC2インスタンスもサポートします。 オフライン修復を指定すると、修正プロセス中に EC2 インスタンスが自動的に停止・起動します。

AWS Systems Manager エージェントが EC2 インスタンスにインストールされているかに関わらず、このランブックは、EC2インスタンスに接続できないときにSSHエラーを診断して問題を解決するのに役立ちます。 たとえば、SSHの設定ミスのためにEC2インスタンスに接続できない場合は、このランブックを起動して、数回クリックするだけでこのエラーから回復できます。

$ ssh ec2-user@1.2.3.4
ssh: connect to host 1.2.3.4 port 22: Connection refused

分析したいEC2インスタンスを選択し、ランブックを実行します。 EC2インスタンスにSSMエージェントがインストールされている場合は、インスタンスプロファイルに十分なIAM権限があり、AWS System Managerで管理できることを確認してください。

そうでない場合は、ランブックのオフライン修復を使用することで、問題のあるインスタンスの設定を見直します。設定の見直しでは、問題のあるインスタンスの EBSボリュームをデタッチし、レスキューインスタンスアタッチした上で設定を確認します。不適切な設定が修正されたのち、 EBS ボリュームは元のインスタンスに再度アタッチされます。このオートメーションはインスタンスを停止し、操作を試みる前にAMIを作成することに注意してください。 インスタンスストアボリュームに保存されているデータは失われます。 Elastic IPアドレスを使用していない場合、パブリックIPアドレスは変更される可能性があります。

オフライン修復を使用するには、問題のあるEC2インスタンスを選択し、次のパラメータを使用してこのランブックを実行します。

  • Action: FixAll (CheckAllはオフラインモードではサポートされていません)
  • AllowOffline: True
  • Subnet: {EC2 インスタンスと同じサブネットを選択}

オフライン修復でオートメーションを実行すると、レスキュー EC2インスタンスが作成されます。レスキュー EC2 インスタンスに問題のあるインスタンスのEBSボリュームがアタッチされ、エラーの修正が行われます。

オートメーションが完了したら、実行結果とリソースを確認できます。 私の場合は、誤って構成されたSSHファイルが修正され、EC2インスタンスに正常に接続できました。このエラーの修正には1〜2分しかかかりません。

EC2アクセスとパスワードの回復

AWSSupport-ResetAccess ランブックは、WindowsとLinuxの両方でEC2管理権限が失われたアクセス問題を解決することを目的としたランブックです。 このランブックは、指定した EC2 インスタンスで EC2Rescue ツールを使用して、EC2 コンソール経由で EC2 インスタンスのパスワード復号化を再度有効化するか(Windows)、新しい SSH キーペアを生成して追加します(Linux)。

EC2 Windowsインスタンスのキーペアを紛失した場合、このオートメーションによりパスワード対応のAMIが作成され、新しいキーペアを使用して新しいEC2インスタンスを起動できます。 SSHのトラブルシューティングランブックと同様に、このオートメーションによりインスタンスが停止するため、ステップを実行する前に、アタッチされたインスタンスストアボリューム(存在する場合)にデータが残っていないことを確認してください。 さらに、Elastic IPアドレスを使用していない場合、インスタンスを停止するとパブリックIPアドレスが変更される可能性もあります。

EC2インスタンスへのアクセスを回復するには、EC2インスタンスを選択してランブックを実行するだけです。 SubnetId には問題のあるEC2インスタンスと同じサブネットIDを選択するか、デフォルト値のCreateNewVPC のままにします。ドキュメント「EC2 インスタンスでのパスワードと SSH キーのリセット」を参照してください。

ステップが実行されると、次のステップの手順が出力セクションに表示されます。 このランブックは、オートメーションの一環として、バックアップAMIとパスワード対応の AMIを作成します。 キーペアを紛失したときのアクセスを回復するには、パスワード対応の AMIを使用して、新しいキーペアで新しいEC2 Windowsインスタンスを起動できます。

同様に、同じランブックを使用して、EC2 LinuxインスタンスのSSHアクセスを回復できます。 この方法では、新しい SSH プライベートキーが作成され、暗号化された状態で AWS System Manger Parameter Store に保存されます。パラメータ名は /ec2rl/openssh/{インスタンス ID}/key です。

私の場合、オートメーションにより、-----BEGIN OPENSSH PRIVATE KEY----- で始まる新しい OpenSSH プライベートキーが生成されました。ファイルを保存してRSA形式に変換します。RSA形式 —–BEGIN RSA PRIVATE KEY—– のプライベートキーを入手した場合はこの手順を省略できます。

$ chmod 600 saw.pem
$ ssh-keygen -p -N "" -m pem -f saw.pem
Key has comment 'Added by EC2 Rescue for Linux'
Your identification has been saved with the new passphrase.

取得したプライベートキーを使用して、EC2 Linuxインスタンスに正常に接続できます。

$ ssh -i saw.pem ec2-user@1.2.3.4

EC2のディスク使用量を分析し、空きディスク容量を増やす

AWS ビジネス、Enterprise On-Ramp、またはエンタープライズサポートプランのお客様は、AWSPremiumSupport-Troubleshootic2DiskUsage ランブックを利用して、EBSボリュームの使用状況を分析したり、オペレーティングシステム(OS)レベルでパーティションやファイルシステムの拡張を自動化したりすることもできます。 AWSリージョン、AWS中国リージョン、AWS GovCloud(米国)リージョンで利用でき、WindowsインスタンスとLinuxインスタンスの両方をサポートしています。 ディスク容量を増やすプロセスの効率化の詳細については、AWS re:Post の記事を参照してください。

たとえば、Linuxファイルシステムの空きディスク容量が不足していて、それらを拡張したい場合は、まずEBSボリュームのサイズを増やし、複数の AWS CLI コマンドを実行してファイルシステムを拡張する必要があります。 EC2インスタンスが多い大規模な環境では、多大な時間と労力がかかり、運用の負担になる可能性があります。

aws ssm start-automation-execution コマンドまたは StartAutomationExecution APIでオートメーションランブックを活用して、オートメーションをバッチで実行できます。 ディスク使用量の診断に役立つだけでなく、問題を修復して、ボリュームとそのファイルシステムを一度に拡張することもできます。

EKSまたはECSノードから重要なログを収集します

Amazon Elastic Kubernetes Service(EKS)とAmazon Elastic Container Service(ECS)は、AWS上のフルマネージドなコンテナオーケストレーションサービスです。 どちらも、コンテナ化されたアプリケーションを実行するための異なるコンピューティングオプションを提供します。 コンピュートリソースの典型的なタイプの1つは、EC2インスタンスの使用です。インスタンスをクラスターに追加して、Amazon EKS または Amazon ECS で管理できるようにする必要があります。

しかし、インスタンスにトラブルシューティングが必要な問題がある場合は、EKS Log Collector または ECS Log Collector を使用して、エラーを特定するための重要なシステムレベルの情報(kubelet、ECSエージェント、システム構成など)を収集することが不可欠です。 ただし、EC2インスタンスがSSHアクセスを提供しないか、プライベートネットワークの設定によって制限されているため、スクリプトの実行とログの収集が難しい場合があります。

AWSSupport-CollectEKSInstanceLogsAWSSupport-CollectECSInstanceLogs はこれらの問題の解決に役立つランブックです。 どちらもEKSまたはECSからのログ収集プロセスを自動化し、収集手順を簡素化します。これらのランブックでは SSMが管理するEC2インスタンスを選択できます。ログ収集スクリプトを実行した結果は EC2 インスタンスに保存されます。 さらに、バンドルログをAmazon S3バケットにアップロードするオプションも提供しています。これは、複数のインスタンスを一元的に確認する必要がある場合に役立ちます。

EKSクラスターのトラブルシューティング

AWSSupport-TroubleshooteKSWorkerNode は、Kubernetes ワーカーノードが Amazon EKSクラスターに参加できない原因を迅速に特定するのに役立つ典型的なランブックです。

Amazon EKS クラスターには、ノードと呼ばれるワーカーマシンのセットがあります。 ほとんどのユースケースでは、EKS に最適化された AMI で EC2インスタンスを起動し、それをクラスターのコンピュートリソースとして登録する必要があります。 ただし、クラスターにノードを追加するときに失敗する可能性のある要因がいくつかあります。たとえば、VPC設定の誤り、ユーザーデータの誤り、必要なタグの欠落、接続の問題などです。

以前は、各構成を確認してこれらの問題のトラブルシューティングを行っていましたが、明らかではないエラーを見逃すこともありました。ランブックを使用して、これらすべての時間を節約できます。 可能性のあるエラーと原因が Outputs セクションに表示されます。

さらに、AWSビジネス、Enterprise On-Ramp、またはエンタープライズサポートプランに加入しているお客様は、AWSPremiumSupport-TroubleshooteKSCluster ランブックにもアクセスできます。 Kubernetes Cluster Autoscaler、内部ロードバランサーの作成に関する問題、ワーカーノードの使用する AMI のレビュー、Amazon ECR からのイメージの取得失敗、マネージドノードが安定しないなど、Amazon EKS 環境でよくあるエラーをトラブルシューティングする別のオプションを提供します。 どのようなチェックが実行されるかについては、AWS re:Post の記事を参照してください。

ECSのトラブルシューティング

Amazon ECSは、コンテナ化されたアプリケーションのライフサイクルを管理するためにECSタスクを使用します。 ただし、ECSタスクはさまざまな理由で開始できず、根本原因を特定するのが難しい場合があります。

AWS Support-TroubleshootsTaskFailedToStart は、このような状況に役立つランブックです。 構成を自動的に見直して接続をテストすることで、タスクの開始を妨げる可能性のある一般的な問題の分析プロセスを合理化し、問題を解決するために実行可能なガイダンスを提供します。

たとえば、パブリックサブネットで次の接続エラーでECSタスクを開始できない場合を考えます。 ルートテーブルとネットワークの設定、さらに、VPCとサブネットのネットワーク設定タスクをが正しいことを確認しましたが、タスクを開始できない根本原因が不明です。

この場合、入力パラメータ ClusterNameTaskId を使用してランブックを実行することで、失敗したタスクを診断できます。今回は、ECSタスクを起動するときにパブリックIPの自動割り当てオプションを有効していなかったことが原因として出力されました。また、Output セクションでは問題の対処法も確認できます。

SAW についてもっと知る

この投稿では、サポートオートメーションワークフローのいくつかのユースケースを説明し、トラブルシューティングプロセスをどのように強化できるかを学びました。 AWSサポートは継続的にトラブルシューティング技術を革新し、より良いサポート体験を提供することに専念しています。 AWS SAWの可能性をまだ探っていない人は、今日試してみることを勧めます。

  • What’s New with AWS から、新機能に関する発表を購読してください。
  • AWS サポートチームが作成した AWS Support self-service runbooks の使用方法をご覧ください。
  • AWS YouTubeチャンネルでデモ AWS Supports You: Using Support Automation Workflows を見てください。
  • Systems Manager オートメーションランブックリファレンスを確認してください。これは、AWS Systems Manager で利用できるさまざまなオートメーションランブックに関する詳細情報を提供する包括的なリソースです。 定義済みの各ランブックには、詳細な説明、ステップバイステップの説明、入力と出力の例が記載されています。 特定のAWSサービスに基づいて分類された幅広いランブックを見つけることができます。

著者略歴

Eason Cao
Eason は、AWSコンテナソリューションを専門とし、5年以上の業界経験を持つシニアクラウドサポートエンジニアです。 AWSのコンテナサービスの専門家として、顧客がクラウド環境の課題を克服し、分散システムを最適化できるよう支援することに専念しています。

翻訳はクラウドサポートアソシエイトの Ayu Sonoda が担当しました。