web-dev-qa-db-ja.com

504ゲートウェイタイムアウト-ロードバランサー付きの2つのEC2インスタンス

これは不可能な問題かもしれません。私はすべてを試しました。配電盤のどこかに、口ひげをひねり回している男がいるように感じます。

問題：

Amazon EC2でアプリケーションを実行しています。インスタンスが1つだけで、ロードバランサーが存在しない場合、問題なく機能します。

しかし、実稼働環境では、1つのロードバランサーの背後で2つの同一のインスタンスが実行されており、PDFを生成してメールに添付する機能など）の特定のタスクを実行すると、何も起こりません。 [ネットワーク]タブでGoogle Developerツールを使用すると、タイムアウトに達すると「504 Gateway Timeout」というエラーが表示されます（30秒に設定されています）。

私のデータベースはAmazon RDSの外部にあります。

私は....クライアントがログインした最初のサーバーに接続したままにすることを強制できたら、この問題は解決されます。なぜなら、instance-1が到達しようとすると504ゲートウェイタイムアウトが発生しているからです。インスタンス2でタスクを実行します。

これは、負荷分散を使用している場合にのみ発生しますが、2台のサーバーのいずれかに直接接続する場合には発生しません。

ロードバランサー設定：

  • ロードバランサーのレジストラーにCRECORDがあり、app.myapplication.comがmyloadbalancerDNSname.elb.amazonaws.comを指すようにします
  • ロードバランサーには2つの正常なインスタンスがあり、それぞれ同じリージョンにありますが、異なる可用性ゾーンにあります。
  • ロードバランサーは、インスタンスと同じセキュリティグループを使用しています（ポート22、80、および443ですべてのIPを許可します）
  • ロードバランサーのクロスゾーンロードバランシングがオンになっています。
  • （Amazon S3の）CORSは、*から*へのGET、POST、PUT、DELETEが有効になっています（これがどのようにインスタンスに関連付けられているかわかりませんが、とにかく指示どおりに実行しました）
  • ロードバランサーには、次のように構成されたリスナーがあります。
    • ロードバランサープロトコル：HTTPロードバランサーポート：80インスタンスプロトコル：HTTPインスタンスポート：80
    • ロードバランサープロトコル：HTTPSロードバランサーポート：443インスタンスプロトコル：HTTPインスタンスポート：80（Certプロバイダーごとに正しく選択された暗号、SSLフィールドは100％確実に正しい）

その他のアイデア：

そうは言っても、私はHTTPSではなく、通常のHTTPでテストしています。私の証明書プロバイダーがそうだと言っていても、SSLが適切にセットアップされているとは思いません。私が不審な理由は、 https://app.myapplication.com を入力しようとすると、Google Developer Toolsの「（failed）net :: ERR_CONNECTION_CLOSED」というエラーが表示されるためです。 [ネットワーク]タブ。しかし、これは通常のHTTPを使用しても問題があるため、適用されないはずです。 SSLは後でトラブルシューティングできます。

繰り返しになりますが、私の問題は、一部の機能を使用するときに「504ゲートウェイタイムアウト」問題が発生することですが、ページをロードする代わりにランダムに発生することもあります（まれに）。この504問題は、負荷分散を使用している場合にのみ発生しますが、2つのインスタンスのいずれかに直接接続する場合には発生しません。

どの質問をすればよいかわかりません。すべてのドキュメントをTにフォローしており、すべての提案をウェブ全体でチェックし、何もしていません。

amazon-ec2load-balancinghttp-status-code-504
16
user3035649

どのWebサーバーを使用していますか？私はnginxとAWSの負荷分散に関して非常によく似た問題を抱えていました。追加した keepalive_timeout 75s;私のnginx設定ファイルのhttpブロックに追加しましたが、それ以降は問題が発生していません。

その行を追加して保存した後（ubuntu Sudo service nginx restart。 Redhatでnginxを停止する/path/to/nginx/executable -s stopその後/path/to/nginx/executable nginxを起動します）

この修正は、AWSのヘルプページで推奨されました AWSロードバランサーのトラブルシューティング

11
Maximus

まず、ELBのアイドルタイムアウトは何に設定されていますか？ロードバランサーの「説明」タブの一番下にあります。アイドルタイムアウトの詳細については、こちらをご覧ください ELBのドキュメント 。デフォルトは60秒です。また、Webサーバーでキープアライブを設定または増やすことも検討する必要があります。その方法は、使用しているWebサーバーによって異なります。

次に、クライアントが1つのインスタンスから別のインスタンスに切り替えられていることが原因であると思われる場合は、ELBで session stickiness を有効にする必要があります。これにより、クライアントは常にロードバランサーによって同じバックエンドインスタンスにリダイレクトされます。これを有効にするには、もう一度「説明」タブに移動し、「ポート構成」セクションの各エントリの横にある「編集」リンクをクリックします。 「ロードバランサーによって生成されたCookieスティッキを有効にする」オプションを選択すると、ELBにスティッキのすべての側面を管理するように指示する可能性があります。

5
Bruce P

私の場合、ロードバランサーに問題はなかったことがわかりました。最終的な解決策は、謎のIPからアプリケーションのホスト名にトラフィックをルーティングする不可解なエントリがあったUbuntuのホストファイルです。そのため、PDFの作成プロセス中に、パスがPDFジェネレーターによってミステリーサーバーを指すように書き換えられていたため、ゲートウェイタイムアウトの問題が発生しました。時折機能し、失敗しない。

127.0.0.1 localhost
127.0.1.1 ubuntu-server
42.139.126.191 app.myapp.com

これはそのように見えたので、その3行目を削除し、すべてのギアが再び回転し始めました。 ：P

3
user3035649

Amazon ELBの背後でAmazon EC2インスタンスを使用すると、504 GATEWAY_TIMEOUTエラーが発生していました。 Ubuntu Webサーバーでは、ApacheとPHPを使用します。

この場合、エラーはサーバーのメモリ不足が原因でした。 Apacheエラーログに「メモリ不足」は表示されませんでした。 Apacheアクセスログに504行のエントリがありました。 syslogファイル（/ var/log/syslog）を調べて「メモリ不足」を確認し、メモリの問題を修正しました。

これにより、504エラーが解決されました。

2
Rainbard

セキュリティグループの設定を確認してください。ポート80はアクセスが制限されている場合があります。

1
Henry

おそらくアイドルタイムアウトが原因であり、デフォルト値は60秒です。 AWS ALB

0
Rahul Garg