diffeasy Advent Calendar 2019 의 3일째의 기사입니다.

타임아웃 대책

웹에서의 대량 데이터의 PDF, CSV 다운로드 등, API 실행하면 처리가 압도적으로 길어지면 타임 아웃이 됩니다. 근본적인 논리를 검토하는 비동기 처리 또는 배치 처리를 고려하는 것이 필수적입니다.

다만, 근본 대책에 시간을 필요로 해 버릴 가능성이 있었기 때문에, 잠정 대책으로서의 인프라측의 타임 아웃치 설정을 늘리는 것을 해 보았으므로 정리합니다.

4분(240초) 정도 걸리는 처리였기 때문에, 여유를 가지고 5분(300초) 정도 처리할 수 있도록 한 것입니다.

(WebAPI로서 있을 수 없다고는 돌진하지 않기를 바란다. 일단..)

전제가 되는 환경

GoogleComputeEngine (Linux CentOS)

GCP 로드 밸런서

nginx

Rails(API 모드)

Puma

Vue.js (axios에서 API 실행)

처리 순서는?

기본적으로 처리가 진행됨에 따라 시간 초과 값은 짧아야합니다.
①API URL 실행
②GCP 로드 밸런서
③GoogleComputeEngine(Linux CentOS)
④nginx
⑤puma(Rails)

타임 아웃 값을 가지고 있는 것은?

이번 구성에서는 이하 2개만이 디폴트 보유하고 있는 것이었습니다.
이 두 가지를 변경하여 타임 아웃 값을 변경할 수 있습니다.
②로드 밸런서
④nginx

변경 방법

②로드 밸런서

부하 분산 메뉴 하단의 파란색 문자 "고급 설정 메뉴"를 누르십시오

백엔드 서비스 탭 선택

편집 버튼을 누르십시오

백엔드 서비스 세부사항의 상단에 있는 연필 마크

이것으로 30초→300초로

④nginx

nginx의 타임 아웃 초기치는 60초. 290초로 변경한다.fastcgi_read_timeout proxy_read_timeout 를 세트한다.

    server {
        listen 10443;
        server_name xxxx.hogehoge.com;

        # タイムアウトまでの秒数を変更
        fastcgi_read_timeout 290;
        proxy_read_timeout   290;
    }

요약

4분 정도 걸리는 처리를 만들어 버리는 것이 원래 안티 패턴이군요.
다만, 그 처리를 리팩토링하는데 시간을 들여 유저를 기다리게 할 가능성이 있다면, 긴 시간을 기다리게 해 달라고 하는 것도 대책의 하나가 될 수 있다고 생각합니다.