DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

あらゆるAWSサービスの問題トラブルシューティングのための体系的ガイド

再現可能なAWSトラブルシューティングワークフローを使用して、サービス問題を切り分け、ログを確認し、権限を検証し、復旧までの時間を短縮します。

あらゆるAWSサービス問題をトラブルシューティングするための体系的なガイド

AWSサービス問題が発生したとき、推測で対応すると時間を無駄にし、しばしばインシデントを悪化させます。体系的なAWSトラブルシューティングワークフローは、症状を定義し、適切な証拠を確認し、原因を特定し、一度に複数の変更を加えずに問題を修正するのに役立ちます。

このガイドは、到達不能なEC2インスタンス、AccessDeniedエラー、スロットリングされたAPIコール、失敗するLambda関数、または根本原因が明らかでないその他のAWSサービス問題に対処する際に使用してください。

体系的なトラブルシューティング方法論

効果的なトラブルシューティングは推測ではなく、論理的で再現可能なプロセスに従うことです。構造化された方法論を採用することで、必要な情報をすべて収集し、もっともらしい仮説を立て、効率的にテストできます。以下に、中核となるステップの内訳を示します。

1. 問題を明確に定義する

ログに飛び込む前に、問題を徹底的に理解する時間を取りましょう。自問してみてください。

  • 何が問題なのか？（例：EC2インスタンスに到達できない、S3アップロードが失敗する、Lambda関数がタイムアウトする）。
  • いつ始まったのか？一定しているのか、断続的なのか？特定の時間に発生するのか？
  • どこで発生しているのか？どのリージョン、アベイラビリティーゾーン、サービス、または特定のリソースか？
  • 誰が影響を受けているのか？全ユーザー、特定のグループ、または内部システムか？
  • どのくらいの頻度で発生するのか？一度きりのイベントか、繰り返し発生するパターンか？
  • 影響は何か？ 重要度はクリティカル、高、中、低のどれか？

ヒント：詳細を調査する前に、最近のデプロイ、TerraformやCloudFormationの変更、IAMの編集、ルートテーブルの更新、セキュリティグループの変更を確認してください。

2. 情報を収集し観察する

ここで、AWSの強力な監視およびログツールが活躍します。変更を加えずに、可能な限り多くの関連データを収集します。

  • AWS Health Dashboardを確認する： アカウント固有のイベント、リージョナルサービスイベント、または計画メンテナンスを探します。
  • CloudWatchメトリクスを確認する： サービスの関連メトリクス（例：CPU使用率、ネットワークI/O、エラー率、スロットルされたリクエスト）を調べます。
  • CloudWatchログを分析する： アプリケーションログ、VPCフローログ、Lambdaログなどに潜り込み、エラーや異常なパターンを探します。
  • CloudTrailログを参照する： 最近のAPIコールを特定します。特に、不正アクセスや設定ミスが疑われる場合に有効です。
  • 設定を確認する： AWS Configを使用して、リソース設定が最近変更されていないか確認します。
  • リソースステータスを確認する： それぞれのコンソールで、インスタンス、データベース、ロードバランサーのステータスを確認します。

3. 仮説を立てる

収集した情報に基づいて、問題の可能性がある原因を1つ以上提案します。仮説は具体的でテスト可能である必要があります。例：

  • "EC2インスタンスに到達できないのは、セキュリティグループがインバウンドSSHトラフィックを許可していないためです。"
  • "S3アップロードが失敗しているのは、Access Deniedエラーが原因で、IAMポリシーが正しくないことを示しています。"
  • "Lambda関数がタイムアウトしているのは、サービスの同時実行制限に達しているためです。"

4. 仮説をテストし変数を分離する

仮説を証明または反証するための簡単なテストを設計します。最初のテストで問題が解決しない場合は、仮説を洗練させて再度テストします。テストするときは、原因と結果を簡単に特定できるように、一度に1つの変更のみを行います。

  • 例（接続性）： セキュリティグループの問題が疑われる場合、既知の送信元IPと1つのポートからテストします。それがルールの問題であると証明されたら、一時的なテストを実際に必要な狭いルールに置き換えます。
  • 例（権限）： IAM Policy Simulatorを使用して、失敗しているアクションに対してさまざまなIAMポリシーをテストします。

5. 解決して確認する

根本原因を特定したら、適切な修正を実装します。解決策を適用した後、問題が解決され、新しい問題が発生していないことを徹底的に確認します。

6. 文書化して学ぶ

解決後、問題、診断手順、根本原因、解決策を文書化します。これにより、将来のインシデントのための貴重な知識ベースが作成され、システムの回復力の向上に役立ちます。重大な問題については、予防策を特定するために事後分析を検討してください。

主要なAWSトラブルシューティングツールとリソース

AWSは、問題の診断に不可欠な豊富なツールスイートを提供しています。

Amazon CloudWatch

リソースとアプリケーションを監視するための主要なツール。CloudWatchが提供するもの：

  • メトリクス： 実質的にすべてのAWSサービスに関するリアルタイムデータポイント（CPU使用率、ネットワークI/O、S3リクエスト数、DynamoDBスロットルイベント、Lambda呼び出し/エラー）。アプリケーション固有のデータ用にカスタムメトリクスを作成します。
  • ログ： ほぼすべてのソース（EC2、Lambda、VPCフローログ、CloudTrail、アプリケーションログ）の集中ログ。CloudWatch Logs Insightsを使用して、強力なクエリと分析を実行します。
  • アラーム： メトリクスにしきい値を設定して、通知（SNS経由）や自動アクション（例：自動スケーリング）をトリガーします。
  • ダッシュボード： 主要なメトリクスとログを視覚化するカスタムダッシュボードを作成し、運用状態を一元的に把握できます。

AWS CloudTrail

CloudTrailは、AWSアカウント全体のAPIアクティビティを記録し、誰が、いつ、どこから、どのような結果で何をしたかを示します。セキュリティ調査、コンプライアンス監査、そして特に権限や意図しないリソース変更に関連する問題のトラブルシューティングに不可欠です。

  • 使用方法： Access Deniedイベント、問題の発生と同時期のUPDATE、DELETE、CREATE操作を探します。
  • S3のCloudTrailログに対するAthenaクエリの例：
    SELECT eventtime, eventsource, eventname, useridentity.arn, errorcode, errormessage
FROM cloudtrail_logs
WHERE eventtime > current_timestamp - interval '1' hour
  AND (errorcode LIKE '%AccessDenied%' OR errormessage LIKE '%denied%')
ORDER BY eventtime DESC
LIMIT 100

AWS Management Console

各サービスのコンソールは、特定のダッシュボード、ステータスページ、設定詳細を提供します。多くの場合、リソースの状態と設定を最初に確認する場所です。たとえば、EC2コンソールには、インスタンスのステータス、セキュリティグループ、ネットワークインターフェイスが表示されます。

AWS CLI/SDK

プログラムによるチェック、自動化、迅速なアドホッククエリには、AWS Command Line Interface（CLI）とSoftware Development Kit（SDK）が非常に役立ちます。これらを使用すると、ターミナルやアプリケーションから直接情報を取得したり、設定を変更したり、サービスと対話したりできます。

  • 例（セキュリティグループルールの確認）：
    aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0

AWS Health Dashboard

AWSサービスとアカウントの状態に関するパーソナライズされた情報を提供します。問題がアカウント固有なのか、より広範なAWSサービスイベントなのかを理解するために重要です。運用上の問題、計画メンテナンス、パーソナライズされたアラートが表示されます。

AWS Config

AWSリソースの設定変更を記録します。リソースが突然予期しない動作をした場合、Configはその設定履歴を表示し、変更がいつどのように行われたかを特定できます。

一般的なAWS問題のカテゴリと解決策

ほとんどのAWS問題は、いくつかの繰り返し発生するカテゴリに分類されます。これらのパターンを理解することは、正確な仮説を立てるのに役立ちます。

1. 接続性の問題

リソースが通信できない場合、ネットワークパスを確認します。

  • セキュリティグループとネットワークACL（NACL）： これらは最も一般的な原因です。セキュリティグループはステートフルでインスタンス/ENIに適用されます。NACLはステートレスでサブネットに適用されます。必要なトラフィックを許可するようにインバウンド/アウトバウンドルールを確認します。
    • ヒント： セキュリティグループは許可リストであることを覚えておいてください。NACLには許可ルールと拒否ルールの両方があります。NACLでは順序が重要です。
  • ルートテーブル： サブネットがインターネット（インターネットゲートウェイ経由）、他のVPC（ピアリング）、またはオンプレミスネットワーク（VPN/Direct Connect）への正しいルートを持っていることを確認します。
  • DNS解決： リソースがホスト名を解決できない場合、VPC DNS設定、Route 53設定、またはアプリケーションレベルのDNS設定を確認します。
  • VPCフローログ： 詳細なネットワークトラブルシューティングのために、フローログはVPC内のネットワークインターフェイスとの間のすべてのIPトラフィックを記録します。CloudWatch Logs Insightsで分析して、受け入れられた/拒否された接続を確認します。
    fields @timestamp, @message
| filter logStatus = 'OK'
| filter action = 'REJECT'
| filter srcAddr = '192.0.2.1' or dstAddr = '192.0.2.1' -- IP of interest
| sort @timestamp desc

2. 権限エラー（Access Denied）

これらは頻繁に発生し、Access Denied、UnauthorizedOperation、またはForbiddenメッセージで示されます。

  • IAMポリシー： アクションを実行しているユーザー、ロール、またはグループにアタッチされたIAMポリシーを確認します。特定のActionに対して、正しいResourceにAllowステートメントがあることを確認します。
    • ヒント： IAMポリシーはデフォルトで拒否されます。明示的なallowが必要です。
  • リソースベースのポリシー： S3、SQS、KMS、SNS、Lambdaなどの一部のサービスは、リソースへのアクセスを直接許可または拒否するリソースベースのポリシーをサポートしています。これらはIAMアイデンティティポリシーと整合している必要があります。
    • パブリックアクセスではなく、1つのAWSアカウントに対するS3バケットポリシーの例：
      {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadFromAppRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/app-readonly-role"
      },
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::example-private-bucket/*"
      ]
    }
  ]
}
  • サービスコントロールポリシー（SCP）： AWS Organizationsを使用している場合、SCPはアカウントで使用可能な最大権限を設定できます。IAMの許可はSCPの制限を上書きできません。
  • CloudTrail： CloudTrailログでAccess Deniedエラーを検索して、関連する正確なAPIコール、プリンシパル、リソースを特定します。
  • IAM Policy Simulator： IAMコンソールの強力なツールで、特定のアクションに対するさまざまなポリシーの効果をテストできます。

3. サービス制限とスロットリング

AWSサービスにはソフト制限とハード制限があります。これらの制限に達すると、エラーやパフォーマンスの低下が発生する可能性があります（ThrottlingException、TooManyRequestsException）。

  • CloudWatchメトリクス： DynamoDBのReadThrottleEventsやLambdaのThrottlesなど、スロットリングの兆候がないか、サービス固有のメトリクスを監視します。
  • Service Quotasコンソール： このコンソールには、すべてのAWSサービス割り当て、現在の使用状況が一覧表示され、調整可能な割り当ての増加をリクエストできます。
  • 指数バックオフとリトライ： AWS APIと対話する際にアプリケーションでこれらのパターンを実装して、一時的なスロットリングを適切に処理します。

4. リソース設定ミス

誤って設定されたリソースは、問題の頻繁な原因です。

  • ストレージ： 不適切なS3バケット権限（パブリックアクセス）、暗号化されていないEBSボリューム、EBSのIOPS不足。
  • コンピューティング： 間違ったEC2インスタンスタイプ、不適切なAMI、誤って設定されたユーザーデータ、Auto Scalingグループの問題。
  • データベース： 接続文字列の問題、セキュリティグループの設定ミス、パラメータグループの設定。
  • ロードバランサー： 不適切なリスナールール、異常なターゲットグループ、セキュリティグループの問題。
  • AWS Config： Configを使用して、時間の経過に伴うリソース設定の変更を追跡し、不適切な設定がいつ導入されたかを特定します。

5. アプリケーション固有の問題

AWSサービスが完全に実行されていても、アプリケーションコードに問題がある可能性があります。

  • アプリケーションログ： アプリケーションログがCloudWatch Logsに送信されていることを確認します。エラー、例外、または予期しない動作がないか分析します。
  • アプリケーションメトリクス： より深い洞察を得るために、アプリケーションからカスタムCloudWatchメトリクス（例：エラー数、リクエストレイテンシ、キュー深度）を出力します。
  • AWS X-Ray： 分散アプリケーションの場合、X-Rayはエンドツーエンドの可視性を提供し、リクエストがさまざまなサービスを通過する際にトレースし、パフォーマンスのボトルネックやエラーを特定します。

MTTRを短縮するためのベストプラクティス

適切な準備により、インシデント中に必要な調査作業を減らすことができます。

  • プロアクティブな監視とアラート： 重要なメトリクス（CPU使用率、エラー率、レイテンシ、ディスク容量、APIエラー）に対して包括的なCloudWatchアラームを実装します。SNSと統合して、PagerDuty、Slack、またはメールに通知を送信します。
  • 集中ログ： すべてのサービス（EC2、Lambda、コンテナなど）からのログをCloudWatch LogsまたはS3ベースのデータレイクに集約して、簡単に検索および分析できるようにします。
  • Infrastructure as Code（IaC）： CloudFormation、AWS CDK、またはTerraformを使用してインフラストラクチャを定義します。これにより、一貫性が確保され、手動エラーが減少し、変更のロールバックが容易になります。
  • RunbookとPlaybook： 一般的な問題、その症状、診断手順、解決手順を文書化します。これにより、チームは問題を迅速かつ一貫して解決できます。
  • AWS Well-Architected Frameworkの採用： 運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化を考慮してシステムを設計します。プロアクティブな設計により、多くの問題を防ぐことができます。
  • 定期的な監査とレビュー： セキュリティグループルール、IAMポリシー、リソース設定を定期的に見直して、ベストプラクティスと現在の要件に沿っていることを確認します。
  • AWSサポートの活用： 解決できない複雑な問題、またはAWS側のサービス問題が疑われる場合は、サポートプランで許可されていればサポートケースを開きます。リソースID、リージョン、タイムゾーン付きのタイムスタンプ、エラーメッセージ、リクエストID、およびすでに試した手順を含めてください。

まとめ

すべてのAWSサービス問題は、同じリズムで開始します。症状を定義し、最近の変更を確認し、ログとメトリクスを収集し、一度に1つの仮説をテストし、修正を文書化します。この習慣により、インシデントが発生していないときでも、トラブルシューティングを冷静に保つことができます。