Nginx 재시도로 인해 HTTP 요청이 반복적으로 실행됩니다.

1. 문제 배경

웹사이트는 Nginx를 역방향 프록시로 사용하고, 두 개의 Tomcat이 로드 밸런싱을 수행합니다.

웹사이트에는 단체 문자 메시지 모듈이 있으며, 발송 내용과 휴대폰 번호 목록을 관리자가 작성할 수 있습니다. 보내기를 클릭하면 그룹 문자 메시지 작업이 백그라운드에서 실행되고 전송이 완료된 후 전송 결과가 반환됩니다.

오래전 반복해서 보내는 문제에 직면했습니다. 처음에는 관리자가 이상한 행동을 하는 줄 알고 계속해서 보내기 버튼을 눌렀습니다. 따라서 프런트엔드 제출에는 제한이 적용됩니다. 보내기 클릭 시 버튼을 비활성화로 설정하고, 실행 후 반환된 데이터를 가져온 다음 사용 가능으로 설정하여 프런트 엔드에서 반복 제출을 제한합니다.

오늘 동료가 갑자기 이 모듈을 다시 사용하여 각각 두 개의 문자 메시지(8000 및 1600)를 보냈는데 프런트엔드에서 작업이 실패했다는 메시지가 표시되었지만 그의 휴대폰에는 중복된 문자 메시지가 수신되었습니다.

2. 문제 분석

먼저 휴대폰 번호 목록에 중복된 번호가 없음을 확인하였고, 프론트엔드에서 반복적으로 요청을 하지 않았음을 브라우저 디버깅을 통해 확인하였습니다.

두 서버의 로그를 확인해 본 결과, 반복적인 전송이 발생했으며, 전송 시점이 동시에 발생하지 않은 것이 사실입니다.

로그를 통해 문자 메시지를 보내는 데 걸리는 시간은 10밀리초로 추정할 수 있습니다.

로그를 통해 처리 시간 초과 로그도 확인했는데, 반복된 요청이 서로 다른 머신에서 처리되고 처리 간격이 일정한 패턴을 발견했습니다

A 로그

10:03:05,878  INFO TIMEOUT.info:252 - time: 75701ms, concurrent: 1, url: 
/push/sendmessage.10:07:24,705  INFO TIMEOUT.info:252 - time: 15148ms, concurrent: 0, url: /push/sendmessage.

B 로그

10:03:21,599  INFO TIMEOUT.info:252 - time: 76471ms, concurrent: 1, url: 
/push/sendmessage.10:07:39,718  INFO TIMEOUT.info:252 - time: 15113ms, concurrent: 0, url: /push/sendmessage.

위 정보를 바탕으로 요청 실행 시간이 제한을 초과하여 프런트 엔드 프롬프트가 실패하는 것으로 추측했습니다. 재시도 메커니즘으로 인해 중복 제출이 발생해야 합니다.

그래서 확인을 위해 운영 및 유지관리 부서에 연락을 드렸습니다. 관련 답변을 받았습니다:

Nginx는 시간 제한이 15초로 구성되어 있고 요청을 처리하고 반환하는 데 16초가 걸린다고 가정하여 시간 제한을 구성할 수 있습니다. Nginx는 처리를 위해 서버 A로 라우팅합니다. A가 15초까지 실행되면 정상적으로 반환되지 않습니다. Nginx는 처리를 위해 B 서비스로 다시 보냅니다. 프런트 엔드는 30초를 기다린 후 최종적으로 실패를 반환합니다. A와 B는 각각 해당 요청을 받아 내부적으로 처리했습니다.

운영관리반 친구들과 이유를 확인한 후 관련 정보를 바탕으로 직접 검색할 수 있습니다.

nginx의 재시도 메커니즘

기사에서는 IP를 통해 서비스에 접속하고 nginx를 우회할 수 있는 솔루션도 지적했습니다.

또한 저희 웹사이트에는 다운로드 기능이 있습니다. 최적화 전에는 각 다운로드의 실행 시간도 매우 길었지만 타임아웃 문제는 없었습니다. GET과 POST 간의 가능한 차이점을 분석했습니다. 일반적인 아이디어를 결정하기 위해 다음 링크도 위에 제공됩니다.

http://serverfault.com/questions/528653/how-can-i-stop-nginx-from-retrying-put-or-post-requests-on-upstream-server-timeo

3. 문제 요약

Nginx는 온라인 정보 참조를 통해 파일 업로드, 다운로드, GET 및 POST 요청에 대해 다양한 시간 초과 전략을 설정할 수 있습니다.

또한 SMS 대량 발송 사업의 경우 실제로 규칙을 통해 구성을 관리하고 오프라인 작업 실행을 수행하는 별도의 모듈이 있습니다. 기존 대량발송 모듈은 소규모 기업에만 해당됩니다.