当延长ELB闲置超时时，要注意的事项

导言

我是井之口，从3月份开始担任SRE职位。之前一直在做后端工程师的工作，但是这次换了职位，接触到了更多与基础设施相关的工作。这次有机会修改ELB的配置，我想将学到的东西总结一下。

构成

• NginxがRailsのプロキシサーバーとして立っていて、ELBから負荷分散されている一般的な構成です

 

• ALBアイドルタイムアウトは60秒に設定されています

 

Nginxのkeepalive-timeoutは60秒に設定されています

我会简单解释一下这个术语。

ALB 偶像超时

ALBが接続先であるNginxへ向けたTCPコネクションを保持する時間

保持连接超时时间

NginxがALBへ向けたTCPコネクションを保持する時間の事

应对内容

让我们假设由于某种原因，我们不得不延长ALB的空闲超时时间。这次我们想把超时时间延长到120秒，所以我们先试着只延长空闲超时时间。

1. 延长ALB的闲置超时时间（120秒）

 

保持Nginx的超时时间为60秒。

这是一种类似的想法。

实际上，即使在AWS官方中，当将Nginx或Apache放在ELB的连接目标时，也建议延长连接目标的超时时间，因为这个设置不够完善。

请告诉我使用Apache或NGINX作为ELB的最佳后端服务器的配置。

为什么会有问题？

如果处理时间超过60秒，Nginx会在ALB之前超时，从Nginx一侧切断TCP连接。为了从ALB侧检测到TCP连接已断开，需要等待一定周期以通过keepalive检查对方的存活性并进行确认响应。结果是，在确认断开之前，如果使用了ALB侧发起的TCP连接来发起其他请求，那么由于Nginx已经断开了连接，将会导致504错误。

由于可能发生上述情况，似乎需要更改Nginx的配置。我将尝试添加额外的设置。

增加响应

1. 将ALB的空闲超时时间延长至120秒。

 

1. 将Nginx的keepalive_timeout设置为ALB的空闲超时时间的两倍，即240秒。

 

1. 延长Nginx的proxy_read_timeout时间。

 

设置Nginx的client_header_timeout和client_body_timeout。

1. 当处理时间超过120秒时，ALB会比Nginx更早超时，从而导致连接从ALB端断开。

 

在ALB断开连接之后，Nginx会断开连接，因此，新的来自ALB的请求不可能流向已断开的连接。

现在可以安全地断开连接了。

其他设置的属性的含义

代理读取超时

• Nginxがプロキシ先(Rails)に投げたリクエストをタイムアウトする時間

 

• つまりクエリ等が原因で時間がかかっている場合は、この時間を伸ばさないと結局タイムアウトすることになる

この記事はあくまで暫定対応前提のため、非同期処理やクエリチューニングなど考えた方がより良いです

客户端头超时

クライアント(今回はALB)がNginxに投げたheaderをNginxが読み込むまでの時間のタイムアウト時間

客户端体超时

上記のリクエストボディ版

请使用中文对以下内容进行释义：

有疑问的问题/ 疑点/ 疑问事项

• TCPコネクションが切断される時の挙動

TCPコネクションを切断する場合って、FIN -> ACKでやりとりをしてから切断すると思っていたので、その時点で切断された事検知できるんじゃないのかなと思った。この辺り詳しい方教えていただければ嬉しいです。

最后

我成为了SRE，意识到提高服务的可信度也需要对不太常意识到的后端层知识。虽然我还很不成熟，但以后工作时我会考虑如何进一步提高服务的可信度。

可以参考的文章

• 【TCP】コネクションの確立までの道のり

 

ELB使ってる人はすぐにKeepAlive Timeoutの値を確認しよう