# HTTP 504 ステータスコード (Gateway Timeout)
HTTP 504 ステータスコード (Gateway Timeout) は、CloudFront がオリジンにリクエストを転送したとき (リクエストされたオブジェクトがエッジキッシュに存在しなかったため) に、以下のいずれかの状況が発生したことを示しています。
+ オリジンが HTTP 504 ステータスコードを CloudFront に返した。
+ リクエストの期限切れまでにオリジンが応答しなかった。
トラフィックがファイアウォールまたはセキュリティグループによってオリジンからブロックされているか、インターネットでオリジンにアクセスできない場合、CloudFront は HTTP 504 ステータスコードを返します。最初に、これらの問題を確認します。次に、アクセスに問題がない場合は、アプリケーションの遅延とサーバーのタイムアウトを調べると、問題の特定と修正に役立ちます。
**Topics**
+ [CloudFront トラフィックを許可するようにオリジンサーバーのファイアウォールを設定する](#http-504-gateway-timeout-configure-firewall)
+ [CloudFront トラフィックを許可するようにオリジンサーバーのセキュリティグループを設定する](#http-504-gateway-timeout-configure-security-groups)
+ [インターネットでカスタムオリジンサーバーをアクセス可能にする](#http-504-gateway-timeout-make-origin-accessible)
+ [オリジンサーバーでアプリケーションからの遅延したレスポンスを見つけて修正する](#http-504-gateway-timeout-slow-application)
## CloudFront トラフィックを許可するようにオリジンサーバーのファイアウォールを設定する
オリジンサーバーのファイアウォールが CloudFront トラフィックをブロックしている場合、CloudFront は HTTP 504 ステータスコードを返すため、これが問題でないことを確認した上で、他の問題を確認できます。
これがファイアウォールの問題であるかどうかを判断するために使用する方法は、オリジンサーバーが使用しているシステムによって異なります。
+ Linux サーバーで IPTable ファイアウォールを使用している場合は、IPTables を操作するのに役立つツールと情報を検索できます。
+ Windows サーバーで Windows ファイアウォールを使用している場合は、Microsoft ドキュメントの「[Add or Edit Firewall Rule](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx)」(ファイアウォール規則を追加または編集する) を参照してください。
オリジンサーバーでファイアウォール設定を評価するときは、公開されている IP アドレス範囲に基づいて、CloudFront エッジロケーションからのトラフィックをブロックしているファイアウォールまたはセキュリティルールを探します。詳細については、「[CloudFront エッジサーバーの場所と IP アドレス範囲](LocationsOfEdgeServers.md)」を参照してください。
CloudFront の IP アドレス範囲がオリジンサーバーへの接続を許可されている場合は、サーバーのセキュリティルールを更新して変更を反映します。Amazon SNS トピックにサブスクライブして、IP アドレス範囲ファイルが更新されたときに通知を受け取ることができます。通知を受け取ったら、コードを使用してファイルを取得し、解析して、ローカル環境を調整することができます。詳細については、AWS ニュースブログの「[Subscribe to AWS Public IP Address Changes via Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/)」を参照してください。
## CloudFront トラフィックを許可するようにオリジンサーバーのセキュリティグループを設定する
オリジンで Elastic Load Balancing を使用している場合は、[ELB セキュリティグループ](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html)を確認し、セキュリティグループで CloudFront からのインバウンドトラフィックを許可していることを確認します。
また、AWS Lambda を使用してセキュリティグループを自動的に更新することで、CloudFront からのインバウンドトラフィックを許可することもできます。
## インターネットでカスタムオリジンサーバーをアクセス可能にする
カスタムオリジンサーバーがインターネットで公開されておらず、CloudFront からアクセスできない場合は、HTTP 504 エラーが返されます。
CloudFront エッジロケーションはインターネットを介してオリジンサーバーに接続します。カスタムオリジンがプライベートネットワークにある場合、CloudFront はオリジンに到達できません。このため、[内部の Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html) などのプライベートサーバーをオリジンサーバーとして CloudFront で使用することはできません。
インターネットトラフィックがオリジンサーバーに接続できることを確認するには、次のコマンドを実行します (*OriginDomainName* はサーバーのドメイン名です)。
HTTPS トラフィックの場合:
+ nc -zv *OriginDomainName* 443
+ telnet *OriginDomainName* 443
HTTP トラフィックの場合:
+ nc -zv *OriginDomainName* 80
+ telnet *OriginDomainName* 80
## オリジンサーバーでアプリケーションからの遅延したレスポンスを見つけて修正する
サーバーのタイムアウトは、多くの場合、アプリケーションの応答に非常に長い時間がかかっているか、タイムアウト値の設定が低すぎる場合に発生します。
HTTP 504 エラーを手早く修正するには、ディストリビューションの CloudFront タイムアウト値を高く設定します。ただし、アプリケーションとオリジンサーバーのパフォーマンスとレイテンシーの問題があれば、最初にその問題に対応することをお勧めします。次に、HTTP 504 エラーを回避してユーザーに良好な応答性を提供する、適切なタイムアウト値を設定できます。
パフォーマンスの問題を見つけて修正するための手順について、以下に概要を示します。
1. ウェブアプリケーションの一般的な高負荷のレイテンシー (応答性) を測定します。
1. 必要に応じて CPU やメモリなどのリソースを追加します。データベースクエリを高負荷シナリオに対応するようにチューニングするなど、問題に対応する他のステップを実行します。
1. 必要に応じて、CloudFront ディストリビューションのタイムアウト値を調整します。
各ステップの詳細を以下に示します。
### 一般的な高負荷のレイテンシーの測定
1 台以上のバックエンドウェブアプリケーションサーバーで長いレイテンシーが発生しているかどうか調べるには、各サーバーで次の Linux curl コマンドを実行します。
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**注記**
サーバーで Windows を実行する場合は、Windows 用の curl を検索およびダウンロードして、類似したコマンドを実行できます。
サーバーで実行するアプリケーションのレイテンシーを測定および評価する場合は、次の点に留意します。
+ レイテンシーの値は、各アプリケーションに対して相対的です。ただし、先頭バイトまでの時間は、秒単位またはそれ以上ではなく、ミリ秒単位が合理的です。
+ 通常の負荷でアプリケーションのレイテンシーを測定して問題がなくても、高負荷がかかった場合に、ビューワーにタイムアウトが発生する可能性があることに注意してください。需要が高い場合、サーバーでレスポンスの遅延が発生するか、まったく応答しないことがあります。高負荷に伴うレイテンシーの問題を避けるために、CPU、メモリ、ディスクの読み取りと書き込みなど、サーバーのリソースをチェックし、サーバーが高負荷に合わせてスケールできることを確認します。
次の Linux コマンドを実行して、Apache プロセスによって使用されているメモリを確認できます。
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ サーバーでの高い CPU 使用率により、アプリケーションのパフォーマンスが大幅に低下する場合があります。Amazon EC2 インスタンスをバックエンドサーバーとして使用している場合は、サーバーの CloudWatch メトリクスで CPU 使用率を確認します。詳細については、[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)を参照してください。または、独自のサーバーを使用している場合、CPU 使用率を確認する方法について、サーバーのヘルプドキュメントを参照してください。
+ リクエストの量が多くてデータベースクエリが遅くなるなど、高負荷に伴って発生する可能性がある他の問題を確認します。
### リソースの追加およびサーバーとデータベースのチューニング
アプリケーションとサーバーの応答性を評価したら、一般的なトラフィックと高負荷の状況に対する十分なリソースがあることを確認します。
+ 独自のサーバーがある場合は、評価に基づいて、ビューワーリクエストを処理する十分な CPU、メモリ、およびディスクスペースがあることを確認します。
+ Amazon EC2 インスタンスをバックエンドサーバーとして使用している場合は、受信されるリクエストを満たす適切なリソースがインスタンスタイプにあることを確認します。詳細については、*Amazon EC2 ユーザーガイド*の「[インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
さらに、タイムアウトを避けるために次のチューニングステップを検討します。
+ curl コマンドによって返される先頭バイトまでの時間の値が高いと思われる場合は、アプリケーションのパフォーマンスを向上させるステップを実行します。アプリケーションの応答性の向上は、タイムアウトエラーを減らすうえで有効です。
+ データベースクエリをチューニングし、パフォーマンスを低下させることなく高いリクエストボリュームを処理できるようにします。
+ バックエンドサーバーで[キープアライブ (持続的)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) 接続を設定します。このオプションは、それ以降のリクエストまたはユーザーに対して接続を再確立する必要があるときに発生するレイテンシーを回避するために有効です。
+ **Elastic Load Balancing をオリジンとして使用している場合**の 504 エラーの原因には、以下が考えられます。
+ ロードバランサーが、 (10 秒の) 接続タイムアウトが期限切れになる前にターゲットへの接続を確立できない。
+ ロードバランサーがターゲットへの接続を確立しても、アイドルタイムアウト期間が経過する前にターゲットが応答しない。
+ サブネットのネットワークアクセスコントロールリスト (ACL) で、ターゲットから一時ポート (1024～65535) のロードバランサーノードへのトラフィックが許可されていない。
+ ターゲットがエンティティ本文より大きな Content-Length ヘッダーを返した。ロードバランサーが欠落しているバイトを待機している間にタイムアウトとなった。
+ ターゲットが Lambda 関数であり、接続タイムアウトが期限切れになる前に Lambda サービスが応答しない。
レイテンシー低減の詳細については、「[ELB Classic Load Balancer での高レイテンシーをトラブルシューティングする方法を教えてください。](https://repost.aws/knowledge-center/elb-latency-troubleshooting)」を参照してください。
+ **MediaTailor をオリジンとして使用している場合**の 504 エラーの原因には、以下が考えられます。
+ 相対 URL が適切に処理されなかった場合、MediaTailor はプレイヤーから不正な形式の URL を受け取る可能性があります。
+ MediaPackage が MediaTailor のマニフェストオリジンである場合、MediaPackage 404 マニフェストエラーが原因で MediaTailor が 504 エラーを返す場合があります。
+ MediaTailor オリジンサーバーへのリクエストは、完了するまでに 2 秒以上かかります。
+ **Amazon API Gateway をオリジンとして使用している場合**の 504 エラーの原因には、以下が考えられます。
+ 統合リクエストは、API Gateway REST API の最大統合タイムアウトパラメータよりも時間がかかります。詳細については、「[API Gateway で API HTTP 504 タイムアウトエラーをトラブルシューティングする方法を教えてください。](https://repost.aws/knowledge-center/api-gateway-504-errors)」を参照してください。
### 必要に応じて、CloudFront タイムアウト値を調整する
アプリケーションの低いパフォーマンス、オリジンサーバーの容量、およびその他の問題について評価、対応したが、それでもビューワーに HTTP 504 エラーが発生する場合は、オリジン応答タイムアウトに対してディストリビューションで指定されている時間の変更を検討します。詳細については、「[応答タイムアウト](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout)」を参照してください。