Get Hands-on with Amazon EKS - Workshop Event Series

Whether you're taking your first steps with Kubernetes or you're an experienced practitioner looking to sharpen your skills, our Amazon EKS workshop series delivers practical, real-world experience that moves you forward. Learn directly from AWS solutions architects and EKS specialists through hands-on sessions designed to build your confidence with Kubernetes. Register now and start building with Amazon EKS!

Application Load Balancer の使用時に発生する 504 エラーのトラブルシューティング方法を教えてください。

所要時間2分

Application Load Balancer のアクセスログまたは Amazon CloudWatch メトリクスに、ELB_504 と表示されるエラーをトラブルシューティングしたいです。使用しているサービスに Application Load Balancer 経由で接続する際に、HTTP 504 エラーが発生することもあります。

簡単な説明

ゲートウェイまたはプロキシがタイムアウトすると、HTTP 504 エラーが発生します。Application Load Balancer での HTTP 504 エラーは、次の原因で発生する可能性があります。

ロードバランサーが、接続タイムアウト (10 秒) の期限内にターゲットへの接続を確立できなかった。
ロードバランサーがターゲットに接続する際に、SSL ハンドシェイクのタイムアウトが発生した。
注: SSL ハンドシェイクのタイムアウトは、10 秒から変更できません。
ロードバランサーはターゲットへの接続を確立したが、アイドルタイムアウト期間が経過するまでにターゲットが応答しなかった。
ターゲットがエンティティ本体よりも大きい Content-Length ヘッダー値を返し、ロードバランサーがタイムアウトした。
大量のトラフィックが原因で、ターゲットの応答が遅くなった。
ターゲットは AWS Lambda 関数で、サービスが接続タイムアウトの期限内に応答しなかった。

解決策

ロードバランサーが登録済みターゲットでのトラフィックを許可していることを確認する

CloudWatch メトリクス TargetConnectionErrorCount で Sum 統計情報を確認します。データポイント数が 0 ではなく正の値である場合は、ロードバランサーとターゲットの間の接続に問題があります。

これらの問題を解決するには、ロードバランサーとバックエンドターゲットに関連付けられているネットワークセキュリティグループを確認します。ネットワークセキュリティグループが、トラフィックおよびヘルスチェック用のポートで、ロードバランサーとターゲット間の両方向のトラフィックを許可していることを確認してください。サブネットのネットワークアクセス制御リスト (ネットワーク ACL) で、ターゲットからロードバランサーノードへのトラフィックをエフェメラルポート (1024 ～ 65535) で許可していることを確認します。

注: Application Load Balancer には、特定のセキュリティグループルールを使用することがベストプラクティスです。

ロードバランサーのメトリクスを確認する

ターゲットが Unhealthy とマークされている理由を特定するには、Application Load Balancer の CloudWatch メトリクスを確認します。HTTPCode_ELB_504_Count メトリクスのデータがない場合は、ロードバランサーではなく、アプリケーションサーバーが 504 エラーを返したことを示しています。この構成では 504 エラーが発生する可能性があるため、TargetResponseTime の最大値がタイムアウトの値を頻繁に超過しているかどうかを確認します。

さらに、リソースタイプに応じて、ターゲットにおける次の CPU およびメモリ使用率メトリクスを確認します。

Amazon Elastic Compute Cloud (Amazon EC2) の場合は、CPUUtilization メトリクスを確認します。EC2 インスタンスは、デフォルトでは CloudWatch にメモリメトリクスを送信しませんが、カスタムメモリメトリクスを送信することはできます。
Amazon ECS タスクの場合は、CPUUtilization および MemoryUtilization メトリクスを確認します。いずれかの値が 1 (100%) の場合、タスクは応答しなくなります。
Lambda 関数の場合は、Duration メトリクスを確認します。Duration がロードバランサーのアイドルタイムアウト値より長く続く場合、Gateway timeout エラーが発生します。

リソースの可用性を向上させる

ターゲットの CPU 使用率が高い場合、応答しなくなる可能性があります。

この問題を解決するには、ターゲットで次のリソースを増やします。

Amazon EC2 では、インスタンスサイズを増やすことで、ターゲットがより多くのコンピューティングリソースを使用できるようにします。
Amazon ECS タスクでは、Amazon ECS タスク定義で CPU とメモリのクォータを増やします。
Lambda 関数では、メモリを増やすことでリソースのキャパシティを変更します。
注: 関数に割り当てる CPU とメモリの量は比例します。

アプリケーションが HTTP リクエストに応答するときの効率が上がるように、コードを更新します。設定したアイドルタイムアウト期間よりもアプリケーションの応答時間が長くならないようにします。デフォルトでは、Application Load Balancer アイドルタイムアウトは 60 秒です。必要に応じて、ロードバランサーのアイドルタイムアウトを増やしてください。

注: ターゲットで完了する必要があるコンピューティング操作の数が多い場合にのみ、アイドルタイムアウト値を増やすことがベストプラクティスです。それ以外の場合は、代わりにターゲットのリソース使用量を最適化することをおすすめします。

需要に基づき、ターゲットをスケーリングする

需要に基づいてターゲットをスケーリングするには、お使いの構成に応じて次のアクションを実行します。

Amazon EC2 の場合は、トラフィックの急増に対応するスケーリングポリシーが設定された EC2 Auto Scaling グループを使用します。
Amazon ECS の場合は、クラスターの自動スケーリングを使用します。

注: Lambda 関数の呼び出し時に、関数は自動的にスケーリングされます。

外部依存関係を確認する

アプリケーションがマイクロサービスアーキテクチャを使用する場合は、データベースや API などの外部依存関係がターゲットの応答時間に影響します。

次の一般的な外部依存関係において、問題の有無を確認してください。

Amazon Relational Database Service (Amazon RDS) では、CloudWatch メトリクス ReadLatency、WriteLatency、DatabaseConnections を確認します。
Amazon Simple Queue Service (Amazon SQS) キューでは、CloudWatch メトリクス ApproximateAgeOfOldestMessage および NumberOfMessagesDelayed を確認します。
Amazon Simple Storage Service (Amazon S3) バケットでは、CloudWatch メトリクス FirstByteLatency、TotalRequestLatency、4xxErrors、5xxErrors を確認します。
Amazon Cognito 認証サービスでは、CloudWatch メトリクス TokenRefreshSuccesses を確認し、ThrottlingException エラーの有無を確認します。

パフォーマンスのボトルネックの原因を特定するには、次の手順を実行します。

HTTP リクエストに Server-Timing ヘッダーを追加し、CloudWatch での遅延を測定します。
AWS X-Ray などのサービスを使用し、アプリケーションにオブザーバビリティソリューションを実装します。
リソース間の物理的な距離を短縮することで、遅延を軽減します。

Compute Optimizer を使用して今後の問題を回避する

AWS Compute Optimizer を使用すると、Amazon EC2、Amazon ECS、Lambda リソースの使用状況に関するインサイトを取得できます。Compute Optimizer は、リソースの使用率が高すぎる時期を検出するため、タイムアウトを回避するのに役立ちます。ワークロードを最適化する方法に関するベストプラクティスを取得することもできます。