Post

2024-09-09-TIL

2024-09-09-TIL

Today I Learned

Idle Timeout

Backend 서버에서 타임아웃은 없고, 톰캣 서버의 설정도 별도로 하지 않았다. Backend서버 앞단의 ALB 타임아웃을 900초로 설정했다. Frontend 서버인 Nginx에서는 내부 도메인에 한해서만 커넥션 타임아웃을 900초로 설정했다. 그런데 브라우저에서 특정 요청을 해서 150초 정도가 되면 커넥션이 끊어지는 현상이 있었다. 확인해보니 NLB의 타임아웃이 350초로 고정값이라서 그 이상 idle time이 지속되면 커넥션이 끊어진다고 한다.

가장 좋은 방법은 타임아웃은 타이트하게 설정하고 오래걸리는 작업이라면 중간에 Nginx에서 keep alive 패킷을 NLB쪽으로 주기적으로 전송하는 방법이 있다. 물론 이 방법도 임계치를 두어서 백엔드 자원을 보호해야한다.

근본적인 해결방안은 모든 요청에 대해서 기획에서부터 변경을 해서 비동기로 처리하는 방식이나 예약해두고 처리경과를 푸시 알람이나 메일로 받아볼 수 있도록 구현하는게 가장 깔끔한 방법인 것 같다.

idle timeout은 말 그대로 idle(동작 중이 아닐때, 통신이 없을때) 시간이 길어지면 커넥션을 끊어버리기 위한 기준이 되는 시간이다.

상세한 내용은 따로 정리한 문서를 참고 -> Idle Timeout

Stack Overflow Alternatives

사내에 질의응답 게시판을 베이스로 한 웹 사이트를 구축해보고 싶어서 스택오버플로우와 비슷한 프로젝트를 조사해보았다.

Instagram Desktop UI

ATProtocol

개발자 이력서 Best Practices

Today I Read

AWS NLB에서 기본 idle timeout은 350으로 제한이 걸려있었는데, 이번에 60 ~ 6000초로 완화되었다고 한다.

Prior to this launch, TCP idle timeout was a fixed value of 350 seconds, which could cause TCP connection handshake retries for the long-lived traffic flows of some applications and add latency. With this launch, you now have the flexibility to configure NLB’s TCP idle timeout to be a value between 60 seconds and 6000 seconds, with the default remaining at 350 seconds for backward compatibility. This configuration can help reduce latency for long-lived traffic flows by maintaining target stickiness for the optimal duration based on the needs of your application. You can configure the TCP idle timeout value using the ‘tcp.idle_timeout.seconds’ listener attribute on your existing and newly created NLBs.

This post is licensed under CC BY 4.0 by the author.