DevOps 지식 허브
DevOps 지식 허브

Nginx 버퍼 튜닝: `client_body_buffer_size` 및 `proxy_buffer_size` 최적화

버퍼 튜닝을 마스터하여 Nginx 성능을 최적화하세요. 이 가이드는 업로드 및 응답 처리 중 느린 디스크 I/O를 최소화하기 위해 `client_body_buffer_size`, `proxy_buffer_size`, `proxy_buffers`를 구성하는 방법을 자세히 설명합니다. 고성능 애플리케이션의 지연 시간을 개선하기 위해 데이터가 빠른 메모리 버퍼에 유지되도록 하는 실제 예제를 알아보십시오.

49 조회수

Nginx 버퍼 튜닝: client_body_buffer_size 및 proxy_buffer_size 최적화

Nginx는 고성능, 효율성, 확장성으로 유명하며, 종종 강력한 리버스 프록시, 로드 밸런서 또는 웹 서버 역할을 수행합니다. 최대 성능을 달성하는 데 있어 중요한 측면은 내부 버퍼링 메커니즘을 올바르게 구성하는 것입니다. 버퍼는 Nginx가 들어오는 요청 본문(업로드 또는 POST 데이터용)과 나가는 업스트림 응답을 처리하는 방식을 결정합니다. 잘못된 구성은 과도한 메모리 소비를 초래하거나, 반대로 느린 디스크 I/O 작업을 유발하여 Nginx의 속도 이점을 상쇄할 수 있습니다.

이 가이드는 주요 버퍼 지시어인 client_body_buffer_size, proxy_buffer_size, 및 관련 설정들을 심층적으로 다루며, 기능, 영향, 그리고 특정 워크로드에 맞게 튜닝하기 위한 실행 가능한 단계를 제공합니다. 효과적인 버퍼 튜닝은 불필요한 디스크 데이터 스와핑을 방지하여 응답 지연 시간과 전반적인 처리량을 직접적으로 개선합니다.

Nginx 버퍼링 기본 이해

Nginx는 클라이언트에서 서버로, 또는 서버에서 백엔드 업스트림 애플리케이션으로 흐르는 데이터를 프로세스 내에서 임시적으로 보유하기 위해 버퍼를 사용합니다.

버퍼가 가득 차면 Nginx는 메모리에서 계속 버퍼링할지 아니면 초과 데이터를 디스크의 임시 파일로 유출(spill)할지 결정해야 합니다. 디스크 I/O는 메모리 액세스보다 훨씬 느리므로, 튜닝의 목표는 일반적인 요청/응답 크기가 메모리 버퍼 내에 편안하게 맞도록 보장하는 것입니다.

주요 버퍼 지시어 개요

버퍼링을 제어하는 몇 가지 지시어가 있으며, 이는 종종 컨텍스트(클라이언트 통신, 프록시, 또는 FastCGI)에 따라 달라집니다.

  • client_body_buffer_size: 클라이언트 요청 본문(POST 요청, 파일 업로드 등에서 사용됨)을 읽는 데 사용되는 버퍼의 크기를 제어합니다.
  • proxy_buffer_size: 리버스 프록시로 작동할 때 업스트림 서버로부터 응답을 읽는 데 사용되는 버퍼의 크기를 제어합니다.
  • proxy_buffers: 데이터가 proxy_buffer_size를 초과할 때 업스트림 서버로부터 응답을 읽는 데 사용되는 버퍼의 개수와 크기를 정의합니다.
  • fastcgi_buffer_size 및 fastcgi_buffers: FastCGI 통신(예: PHP-FPM)에 특화된 유사한 지시어입니다.

client_body_buffer_size 튜닝

이 지시어는 Nginx가 대용량 업로드 또는 광범위한 양식 제출을 직접 처리할 때 중요합니다.

기본 동작 및 영향

기본적으로 Nginx는 일반적으로 client_body_buffer_size를 비교적 작은 값(버전에 따라 8k 또는 16k)으로 설정합니다. 클라이언트 요청 본문이 이 크기를 초과하면 Nginx는 초과 데이터를 디스크의 임시 파일(client_body_temp_path)에 쓰기 시작합니다.

영향: 기본 버퍼 크기보다 크지만 사용 가능한 RAM보다는 작은 요청을 처리할 것으로 예상되는 경우, 이 값을 늘리면 느린 디스크 쓰기 작업을 방지할 수 있습니다.

구성 예시

이 지시어는 http, server, 또는 location 컨텍스트 내에 설정됩니다.

http {
    # 클라이언트 요청 본문의 버퍼 크기를 128KB로 설정합니다
    client_body_buffer_size 128k;
    ...
}

모범 사례: 이 값은 허용되는 절대 최대 업로드 크기가 아니라 예상되는 POST 데이터의 최대 일반적인 크기를 기준으로 설정해야 합니다. 이 값을 전역적으로 너무 높게 설정하고 많은 클라이언트가 적당히 큰 요청을 동시에 보낼 경우, 모든 워커 프로세스에서 과도한 메모리를 소비할 위험이 있습니다.

리버스 프록시 버퍼 최적화: proxy_buffer_size 및 proxy_buffers

Nginx가 리버스 프록시 역할을 할 때, 주요 관심사는 업스트림 서버(예: Apache, Tomcat 또는 Node.js 애플리케이션)에서 돌아오는 응답을 버퍼링하는 것으로 바뀝니다.

proxy_buffer_size

이는 업스트림 서버로부터 응답 헤더와 응답 본문의 첫 번째 청크를 읽는 데 사용되는 초기 버퍼 크기를 정의합니다.

proxy_buffers (개수 및 크기)

업스트림 응답 본문이 클 경우, Nginx는 proxy_buffers에 의해 정의된 버퍼 세트를 사용합니다. 이 지시어는 두 가지 인수를 취합니다.

  1. 버퍼의 개수.
  2. 각 버퍼의 크기.

응답 데이터가 할당된 총 버퍼 공간(개수 * 크기)을 초과하면 Nginx는 나머지 데이터를 proxy_temp_path 디렉토리에 디스크로 쓰기 시작합니다.

구성 예시 (프록시 컨텍스트)

업스트림 서버의 대용량 응답이 메모리에 유지되도록 보장하려면 프록시 버퍼를 다음과 같이 구성할 수 있습니다.

location /api/ {
    proxy_pass http://backend_servers;

    # 초기 버퍼 크기를 64k로 설정
    proxy_buffer_size 64k;

    # 응답의 나머지를 위해 각각 128k 크기의 버퍼 8개를 사용합니다.
    # 총 버퍼 용량: 8 * 128k = 1MB
    proxy_buffers 8 128k;

    # Nginx가 클라이언트에게 데이터를 전송하기 시작하기 전에 디스크에 임시로 쓸 수 있는 최대 크기를 설정합니다.
    proxy_max_temp_file_size 10m;
}

팁: 백엔드가 일반적으로 대용량 JSON 페이로드나 대용량 정적 파일을 반환하는 경우, 일반적인 응답 크기를 조사하고 해당 응답의 95%를 수용할 수 있을 만큼 proxy_buffers를 충분히 크게 설정하십시오. 업스트림 서버가 큰 응답 헤더를 보낼 경우 proxy_buffer_size를 늘려야 할 수도 있습니다.

디스크 유출 관리 (proxy_max_temp_file_size)

Nginx가 메모리 버퍼 공간( proxy_buffers 또는 client_body_buffer_size에 의해 정의됨)이 부족해지면 오버플로우를 디스크로 유출합니다. 이것이 언제 발생하는지를 제어하는 지시어는 *_temp_file_size입니다.

기본적으로 Nginx는 임시 파일이 무한정 커지는 것을 허용하며, 이는 높은 부하 하에서 디스크 공간을 빠르게 소모할 수 있습니다.

proxy_max_temp_file_size

이것은 업스트림 응답을 버퍼링할 때 Nginx가 생성할 수 있는 임시 파일의 크기를 제한합니다. 이 값을 0으로 설정하면 임시 파일 사용이 완전히 비활성화되며, Nginx는 버퍼가 초과될 경우 메모리에서 버퍼링하거나 오류를 반환하도록 강제됩니다(또는 컨텍스트에 따라 연결을 닫습니다).

# 예시: 버퍼링이 메모리를 초과하면 20MB 후 디스크 쓰기를 중단합니다
proxy_max_temp_file_size 20m;

# 예시: 디스크 유출을 완전히 비활성화합니다 (주의해서 사용하고 충분한 RAM이 필요합니다)
proxy_max_temp_file_size 0;

proxy_max_temp_file_size 0에 대한 경고: 이는 디스크 I/O를 제거하지만, 워커 프로세스가 할당된 총 버퍼 공간을 초과하는 수많은 동시 요청을 처리하는 경우, Nginx가 데이터 스트림을 처리할 수 없을 때 메모리 소진 오류 또는 예상치 못한 연결 종료에 직면할 수 있습니다.

FastCGI 버퍼 튜닝 (fastcgi_buffer_size)

FastCGI를 통해 통신하는 애플리케이션(예: PHP)의 경우, 버퍼링 로직은 유사하지만 전용 지시어를 사용합니다.

fastcgi_buffer_size는 헤더와 FastCGI 응답의 초기 부분을 읽기 위한 버퍼 크기를 설정합니다. fastcgi_buffers는 후속 본문 데이터를 읽는 데 사용되는 버퍼 배열을 정의합니다.

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;

    # FastCGI 버퍼를 각각 16k 크기의 버퍼 16개로 설정
    fastcgi_buffers 16 16k;

    # 응답이 매우 클 경우 크기를 조정합니다
    fastcgi_buffer_size 128k;
}

요약 및 튜닝 전략

효과적인 버퍼 튜닝은 시스템 메모리 가용성과 워크로드 특성 간의 균형 잡힌 행위입니다.

  1. 워크로드 분석: 클라이언트 요청 본문과 업스트림 응답의 일반적인 크기를 확인합니다.
  2. 클라이언트 본문: client_body_buffer_size를 가장 큰 일반적인 POST/업로드 크기를 포함하도록 설정합니다.
  3. 프록시 응답: 대다수의 백엔드 응답을 RAM에 수용할 수 있을 만큼 proxy_buffers (개수 및 크기)를 충분히 크게 설정합니다.
  4. 유출 제한: proxy_max_temp_file_size를 사용하여 버퍼 오버플로우로 인한 디스크 사용량을 제한하거나, 메모리 할당이 충분하다고 확신하는 경우에만 0으로 설정합니다.

구성 변경 후에는 성능을 철저히 테스트하고 시스템 메모리 사용률을 모니터링하는 것을 잊지 마십시오.

# nginx.conf 변경 후에는 항상 리로드 전에 구문을 테스트합니다
nginx -t

# 그런 다음 Nginx를 리로드하여 연결을 끊지 않고 변경 사항을 적용합니다
systemctl reload nginx