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

一般的なAWSアーキテクチャ問題のトラブルシューティング：解決策とヒント

この実践的なトラブルシューティングガイドで、一般的なAWSアーキテクチャの課題をナビゲートします。パフォーマンスのボトルネック、接続の問題、サービスの可用性の問題を診断し解決する方法を学びます。この記事では、Amazon Web Services上で堅牢で信頼性の高いアプリケーションを構築するための実用的な解決策、監視のヒント、ベストプラクティスを提供します。

一般的なAWSアーキテクチャ問題のトラブルシューティング：解決策とヒント

ほとんどのAWSアーキテクチャの問題は、最初は漠然としています。アプリケーションが遅い、プライベートインスタンスがAWS APIに到達できない、ロードバランサーに正常なターゲットがない、データベースのフェイルオーバーが図で約束された通りに動作しないなどです。最速のトラブルシューティングは、通常、アカウント全体の設定を変更するのではなく、1つのリクエストパスを追跡し、各ホップが正常であることを証明することから始まります。

最初に3つの質問をしましょう。何が変わったのか、ユーザーに見える症状は何か、リクエストはどこで止まっているのか。障害がパフォーマンス、接続、可用性、認可のいずれであるかがわかれば、AWSコンソールははるかにノイズが少なくなります。

パフォーマンスのボトルネック

パフォーマンスの問題は、アプリケーションの応答時間の遅延、高レイテンシ、リソースの枯渇として現れることがあります。ボトルネックを特定することは、効果的な最適化のために重要です。

パフォーマンスのボトルネックの特定

  • 主要なメトリクスの監視： Amazon CloudWatch などのAWSサービスを利用して、コンピュート、ストレージ、データベースリソースのメトリクスを追跡します。以下の点に注目してください。
    • CPU使用率： EC2インスタンスのCPU使用率が一貫して高い場合、処理能力の不足や非効率なコードを示している可能性があります。
    • メモリ使用率： メモリ使用率が高いとスワッピングが発生し、パフォーマンスが低下します。EC2メモリはデフォルトでは基本的なインスタンスメトリクスに含まれていないため、ワークロードにメモリが重要な場合は、CloudWatchエージェントまたはアプリケーションモニタリングツールを使用してください。
    • ネットワークイン/アウト： ネットワークトラフィックの急増や持続的な高トラフィックは、非効率なデータ転送や負荷の増加を示している可能性があります。
    • ディスクI/O操作（IOPS）とスループット： Amazon EBSやAmazon S3などのサービスでは、プロビジョニングされた制限を超えると、ストレージ関連の速度低下を引き起こす可能性があります。
    • データベース接続とクエリレイテンシ： Amazon RDSまたはDynamoDBインスタンスのパフォーマンスを監視します。
  • AWS X-Ray： 分散アプリケーションの場合、AWS X-Rayはリクエストフローを可視化し、特定のサービスコールにおけるパフォーマンスの問題を特定するのに役立ちます。
  • VPCフローログ： ネットワークトラフィックパターンを分析して、予期しないまたは過剰なデータ転送を特定します。

パフォーマンスのボトルネックに対する解決策

  • リソースのスケーリング：
    • 垂直スケーリング（スケールアップ）： EC2インスタンスのインスタンスサイズ（CPU、RAM）を増やすか、RDSインスタンスクラスをアップグレードします。AWS Auto Scaling を使用して、需要に応じて容量を自動的に調整します。
    • 水平スケーリング（スケールアウト）： アプリケーション層にインスタンスを追加する（例：EC2 Auto Scalingグループの使用）か、複数のデータベース読み取りレプリカに負荷を分散します。
  • アプリケーションコードの最適化： 非効率なアルゴリズム、過剰なデータベースクエリ、メモリリークがないかアプリケーションコードを確認します。
  • キャッシング： Amazon ElastiCache（RedisまたはMemcached）または静的コンテンツ用のAmazon CloudFrontを使用してキャッシング戦略を実装し、バックエンドサービスへの負荷を軽減します。
  • データベースの最適化： SQLクエリをチューニングし、適切なインデックスを追加するか、Amazon Auroraなどのより高性能なデータベースソリューションへの移行を検討します。
  • ストレージの最適化： 適切なEBSボリュームタイプ（例：汎用には gp3、高IOPSには io2）を選択するか、コストとパフォーマンスのためにAmazon S3 Intelligent-Tieringを活用します。

例：高いEC2 CPU使用率の診断

  1. CloudWatchメトリクスの確認： CloudWatchに移動し、EC2を選択して、インスタンスの CPUUtilization メトリクスを表示します。一貫して80〜90％を超えている場合は、さらに調査します。
  2. インスタンスにSSH接続： top、htop、ps などのツールを使用して、最もCPUを消費しているプロセスを特定します。
  3. アプリケーションログの分析： 高いCPU使用率と相関する可能性のあるエラーやパターンをアプリケーションログで探します。
  4. スケーリングの検討： ワークロードが正当であり、それ以上最適化できない場合は、インスタンスサイズの増加またはEC2 Auto Scalingの有効化を検討します。

接続の問題

接続の問題は、ユーザーがアプリケーションにアクセスできなくなったり、AWSリソース間の通信を妨げたりする可能性があります。

一般的な接続シナリオ

  • EC2インスタンスに到達できない： VPC内のインスタンスがインターネットや他のインスタンスからアクセスできない可能性があります。
  • VPC間接続障害： 異なるVPC間でのリソース接続の問題。
  • サービスエンドポイントの利用不可： VPC内からAWSサービス（例：S3、RDS）に接続できない。

トラブルシューティング手順

  1. VPCネットワーク設定の確認：

    • セキュリティグループ： インスタンスにアタッチされたセキュリティグループが、正しい送信元IPアドレスまたはセキュリティグループから必要なポートへのインバウンドトラフィックを許可していることを確認します。セキュリティグループはステートフルであることに注意してください。
    • ネットワークACL（NACL）： サブネットに関連付けられたNACLがインバウンドおよびアウトバウンドトラフィックを許可していることを確認します。NACLはステートレスであるため、双方向のルールが必要です。
    • ルートテーブル： サブネットのルートテーブルをチェックして、インターネット（インターネットゲートウェイまたはNATゲートウェイ経由）、他のサブネット、またはピアリングされたVPCへの正しいルーティングを確認します。
    • サブネット設定： インスタンスが正しいサブネットにあり、サブネットに適切なルートテーブルの関連付けがあることを確認します。

  2. インターネットゲートウェイ（IGW）/ NATゲートウェイの確認：

    • IGW： パブリックサブネットにインターネットアクセス用のIGWへのルートがあることを確認します。
    • NATゲートウェイ： プライベートサブネット内のインスタンスがインターネットアクセスを必要とする場合、NATゲートウェイが正しく設定され、Elastic IPに関連付けられ、プライベートサブネットのルートテーブルからNATゲートウェイへのルートがあることを確認します。

  3. VPCピアリング / Transit Gatewayの確認： VPC間通信の場合、VPCピアリング接続またはTransit Gatewayアタッチメントがアクティブであり、関連するすべてのVPCのルートテーブルがピアリングされたVPCのCIDRブロックまたはTransit Gatewayへのルートを含むように更新されていることを確認します。

  4. DNS解決の確認： VPCがDNSを使用するように設定されていること（例：VPC_CIDR_PLUS_2 のAmazonProvidedDNS）と、DNS解決が正しく機能していることを確認します。インスタンスから dig または nslookup を使用してテストします。

  5. AWSネットワーク到達可能性： AWS Reachability Analyzer を使用して、VPC内またはVPC間のAWSリソース間の接続問題を診断します。

例：EC2インスタンスがインターネットからアクセスできない

  1. パブリックIPアドレス： EC2インスタンスにパブリックIPアドレスが割り当てられていますか？パブリックサブネットにありますか？
  2. セキュリティグループ： インスタンスにアタッチされたセキュリティグループを確認します。アプリケーションのポート（例：HTTPの場合はポート80、HTTPSの場合は443）に対して、0.0.0.0/0（または特定のIP範囲）からのトラフィックを許可するインバウンドルールが存在することを確認します。
  3. ネットワークACL： インスタンスのサブネットに関連付けられたNACLを確認します。アプリケーションポートへのインバウンドトラフィックと、応答用のエフェメラルポート（1024-65535）へのアウトバウンドトラフィックを許可していることを確認します。
  4. ルートテーブル： サブネットのルートテーブルにインターネットゲートウェイへのルート（0.0.0.0/0 -> igw-xxxxxx）があることを確認します。
  5. インスタンスの状態： インスタンスは実行中ですか？

サービスの可用性の問題

ミッションクリティカルなアプリケーションにとって、高可用性を確保することは重要です。ダウンタイムは重大なビジネス影響につながる可能性があります。

高可用性のための戦略

  • マルチAZデプロイメント： データベース（RDS Multi-AZ）やアプリケーションサーバーなどの重要なリソースを、リージョン内の複数のアベイラビリティーゾーン（AZ）にデプロイします。1つのAZがダウンした場合、トラフィックは自動的に別のAZにフェイルオーバーできます。
  • 負荷分散： Elastic Load Balancing（ELB） - Application Load Balancer（ALB）、Network Load Balancer（NLB）、Classic Load Balancer（CLB） - を使用して、異なるAZの複数のインスタンスにトラフィックを分散します。ELBのヘルスチェックにより、異常なインスタンスは自動的にローテーションから除外されます。
  • Auto Scaling： EC2 Auto Scaling を実装して、異常なインスタンスを自動的に置き換え、需要とヘルスチェックに基づいて容量をスケールアップまたはスケールダウンします。
  • ステートレスアプリケーション： アプリケーションをステートレスに設計することで、データ損失や中断なしに個々のインスタンスを簡単に置き換えたりスケールしたりできます。
  • グレースフルデグラデーション： 一部の依存関係が利用できない場合でも、おそらく機能を減らして、アプリケーションが機能するように設計します。

可用性の問題のトラブルシューティング

  1. ヘルスチェック：

    • ELBヘルスチェック： ELBのヘルスチェック設定が正確で、正しいエンドポイントとポートをテストしていることを確認します。
    • EC2 Auto Scalingヘルスチェック： Auto Scalingのヘルスチェックが適切に設定されていることを確認します。
    • アプリケーションヘルスエンドポイント： 監視可能な専用のヘルスチェックエンドポイントをアプリケーションに実装します。

  2. CloudWatchアラームの分析： 重要なメトリクス（例：高いエラー率、低ディスク容量、高レイテンシ）に対してCloudWatchアラームを設定し、トリガーされたアラームを迅速に調査します。

  3. AWS Healthの確認： アカウントまたはリージョンに影響を与えるサービスイベントについて、AWS Health Dashboard を確認します。広範なパブリックイベントについては、パブリックのAWS Healthステータスページも確認してください。

  4. フェイルオーバーテスト： 高可用性戦略が期待通りに機能していることを確認するために、定期的にフェイルオーバーテスト（例：1つのAZのインスタンスを終了する）を実行します。

例：インスタンス障害によるアプリケーションの応答不能

  1. ELBヘルスチェック： ALBを使用している場合、ターゲットグループのヘルスを確認します。ALBは、障害が発生したインスタンスを自動的に異常としてマークし、トラフィックの送信を停止する必要があります。
  2. Auto Scaling： インスタンスがAuto Scalingグループの一部であった場合、グループは（ELBまたはEC2のヘルスチェックを介して）異常なインスタンスを検出し、交換用のインスタンスを起動する必要があります。
  3. CloudWatchメトリクス： ALBの HealthyHostCount や UnHealthyHostCount などのメトリクスをCloudWatchで監視します。また、残りの正常なインスタンスの CPUUtilization や NetworkIn/Out をチェックして、増加した負荷を処理しているかどうかを確認します。
  4. ログ： 障害が発生したインスタンス（可能な場合）と新しいインスタンスのログを調べて、障害が発生した理由を理解します。

問題を防ぐためのセキュリティのベストプラクティス

直接的なトラブルシューティングではありませんが、セキュリティのベストプラクティスを遵守することで、多くの一般的なアーキテクチャ上の問題を事前に防ぐことができます。

  • 最小権限の原則： IAMユーザー、ロール、およびサービスに必要な権限のみを付与します。
  • ネットワークのセグメンテーション： VPC、サブネット、セキュリティグループ、NACLを使用してリソースを分離し、セキュリティ侵害の影響範囲を制限します。
  • 定期的なパッチ適用： EC2インスタンス上のオペレーティングシステムとアプリケーションをパッチ適用し、最新の状態に保ちます。
  • 暗号化： 保存データ（例：EBSボリューム、S3オブジェクト、RDSデータベース）と転送中のデータ（TLS/SSLを使用）を暗号化します。
  • ログ記録と監視： 詳細なログ記録（CloudTrail、VPCフローログ）を有効にし、不審なアクティビティに対する監視とアラートを設定します。

小さなRunbookを作成する

各本番ワークロードについて、実際のリクエストパス（DNS、CDN、ロードバランサー、コンピュート層、データベース、キャッシュ、キュー、オブジェクトストレージ、外部依存関係）を記載した短いRunbookを保持します。チームが最初に確認すべき特定のCloudWatchメトリクス、ターゲットグループ、セキュリティグループ、ルートテーブル、ダッシュボードを追加します。「AWSを確認」はRunbookではありません。「インシデントウィンドウについて、ALBターゲットのヘルス、ECSサービスのイベント、RDS Performance Insights、最近のCloudTrailの変更を確認する」は、午前2時に役立ちます。

AWSのトラブルシューティングは、ネットワーク障害とIAM障害を分離し、正常な時間枠と異常な時間枠を比較し、複数のレイヤーを一度に変更しないようにすることで、はるかに落ち着いて行えるようになります。リクエストを追跡し、最初に壊れたホップを見つけ、そのレイヤーを修正してから次に進みます。