웹사이트 검색

Nginx HTTP 프록싱, 로드 밸런싱, 버퍼링 및 캐싱 이해

소개

이 가이드에서는 Nginx가 추가 처리를 위해 요청을 백엔드 http 서버로 전달할 수 있는 Nginx의 http 프록시 기능에 대해 설명합니다. Nginx는 인프라를 확장하거나 대규모 클라이언트 로드를 처리하도록 설계되지 않은 다른 서버로 요청을 전달하는 데 도움이 되는 리버스 프록시 솔루션으로 설정되는 경우가 많습니다.

그 과정에서 Nginx의 내장 로드 밸런싱 기능을 사용하여 확장하는 방법에 대해 논의할 것입니다. 또한 버퍼링 및 캐싱을 탐색하여 클라이언트의 프록시 작업 성능을 개선할 것입니다.

일반 프록시 정보

과거에 단순한 단일 서버 구성을 위해 웹 서버만 사용했다면 요청을 프록시해야 하는 이유가 궁금할 수 있습니다.

Nginx에서 다른 서버로 프록시하는 한 가지 이유는 인프라를 확장할 수 있기 때문입니다. Nginx는 동시에 많은 동시 연결을 처리하도록 제작되었습니다. 따라서 클라이언트의 접점 역할에 이상적입니다. 서버는 많은 백엔드 서버에 요청을 전달하여 인프라 전체에 부하를 분산시키는 대량 작업을 처리할 수 있습니다. 이 디자인은 또한 백엔드 서버를 쉽게 추가하거나 유지 관리를 위해 필요에 따라 제거할 수 있는 유연성을 제공합니다.

http 프록시가 유용할 수 있는 또 다른 인스턴스는 프로덕션 환경에서 클라이언트의 요청을 직접 처리하도록 구축되지 않은 애플리케이션 서버를 사용하는 경우입니다. 많은 프레임워크에는 웹 서버가 포함되어 있지만 대부분은 Nginx와 같은 고성능을 위해 설계된 서버만큼 강력하지 않습니다. 이러한 서버 앞에 Nginx를 배치하면 사용자에게 더 나은 경험을 제공하고 보안을 강화할 수 있습니다.

Nginx의 프록시는 Nginx 서버를 대상으로 하는 요청을 조작하고 실제 처리를 위해 다른 서버로 전달하여 수행됩니다. 요청 결과는 Nginx로 다시 전달되고 Nginx는 정보를 클라이언트로 전달합니다. 이 인스턴스의 다른 서버는 원격 머신, 로컬 서버 또는 Nginx 내에 정의된 다른 가상 서버일 수 있습니다. Nginx 프록시가 요청하는 서버를 업스트림 서버라고 합니다.

Nginx는 http(s), FastCGI, SCGI, uwsgi 또는 memcached 프로토콜을 사용하여 통신하는 서버에 대한 요청을 각 프록시 유형에 대한 별도의 지시문 세트를 통해 프록시할 수 있습니다. 이 가이드에서는 http 프로토콜에 중점을 둘 것입니다. Nginx 인스턴스는 요청을 전달하고 모든 메시지 구성 요소를 업스트림 서버가 이해할 수 있는 형식으로 마사지하는 역할을 합니다.

기본 HTTP 프록시 패스 분해

가장 간단한 유형의 프록시는 http를 사용하여 통신할 수 있는 단일 서버에 요청을 전달하는 것입니다. 이러한 유형의 프록시는 일반 "프록시 패스\로 알려져 있으며 적절한 이름의 proxy_pass 지시문에 의해 처리됩니다.

proxy_pass 지시문은 주로 위치 컨텍스트에서 찾을 수 있습니다. 위치 컨텍스트 내의 if 블록과 limit_except 컨텍스트에서도 유효합니다. 요청이 내부에 proxy_pass 지시문이 있는 위치와 일치하면 요청은 지시문이 제공하는 URL로 전달됩니다.

예를 살펴보겠습니다.

# server context

location /match/here {
    proxy_pass http://example.com;
}

. . .

위의 구성 스니펫에서 proxy_pass 정의의 서버 끝에는 URI가 제공되지 않습니다. 이 패턴에 맞는 정의의 경우 클라이언트가 요청한 URI가 있는 그대로 업스트림 서버에 전달됩니다.

예를 들어 /match/here/Please에 대한 요청이 이 블록에 의해 처리되면 요청 URI는 example.com 서버에 http로 전송됩니다. ://example.com/match/here/Please.

대체 시나리오를 살펴보겠습니다.

# server context

location /match/here {
    proxy_pass http://example.com/new/prefix;
}

. . .

위의 예에서 프록시 서버는 끝에 URI 세그먼트가 정의되어 있습니다(/new/prefix). proxy_pass 정의에 URI가 제공되면 location 정의와 일치하는 요청 부분이 전달 중에 이 URI로 대체됩니다.

예를 들어 Nginx 서버에서 /match/here/Please에 대한 요청은 업스트림 서버에 http://example.com/new/prefix/Please 로 전달됩니다. . /match/here는 /new/prefix로 대체됩니다. 이것은 명심해야 할 중요한 사항입니다.

때로는 이런 종류의 교체가 불가능합니다. 이 경우 proxy_pass 정의 끝에 있는 URI는 무시되고 클라이언트의 원래 URI 또는 다른 지시문에 의해 수정된 URI가 업스트림 서버로 전달됩니다.

예를 들어 정규 표현식을 사용하여 위치가 일치하면 Nginx는 URI의 어느 부분이 표현식과 일치하는지 확인할 수 없으므로 원래 클라이언트 요청 URI를 보냅니다. 또 다른 예로 재작성 지시문이 동일한 위치 내에서 사용되어 클라이언트 URI가 재작성되지만 여전히 동일한 블록에서 처리되는 경우입니다. 이 경우 재작성된 URI가 전달됩니다.

Nginx가 헤더를 처리하는 방법 이해

즉시 명확하지 않을 수 있는 한 가지는 업스트림 서버가 요청을 적절하게 처리할 것으로 예상되는 경우 URI 이상의 것을 전달하는 것이 중요하다는 것입니다. 클라이언트를 대신하여 Nginx에서 오는 요청은 클라이언트에서 직접 오는 요청과 다르게 보입니다. 이것의 큰 부분은 요청과 함께 가는 헤더입니다.

Nginx가 요청을 프록시할 때 클라이언트로부터 받는 요청 헤더를 자동으로 일부 조정합니다.

  • Nginx는 빈 헤더를 제거합니다. 빈 값을 다른 서버로 전달할 필요가 없습니다. 요청을 부풀리기만 할 뿐입니다.
  • Nginx는 기본적으로 밑줄이 포함된 모든 헤더를 유효하지 않은 것으로 간주합니다. 프록시 요청에서 이를 제거합니다. Nginx가 이를 유효한 것으로 해석하도록 하려면 underscores_in_headers 지시문을 "on\으로 설정하면 됩니다. 그렇지 않으면 헤더가 백엔드 서버로 전달되지 않습니다.
  • "Host\ 헤더는 $proxy_host 변수에 의해 정의된 값으로 다시 작성됩니다. 이것은 업스트림의 IP 주소 또는 이름 및 포트 번호가 되며, proxy_pass 지시어.
  • "연결\ 헤더가 "닫기\로 변경되었습니다. 이 헤더는 두 당사자 간에 설정된 특정 연결에 대한 정보를 알리는 데 사용됩니다. 이 경우 Nginx는 원래 요청에 응답하면 이 연결이 닫힐 것임을 업스트림 서버에 나타내기 위해 이것을 "닫기\로 설정합니다. 업스트림은 이 연결이 영구적일 것으로 기대해서는 안 됩니다.

위에서 추정할 수 있는 첫 번째 요점은 전달하지 않을 헤더는 빈 문자열로 설정해야 한다는 것입니다. 값이 비어 있는 헤더는 전달된 요청에서 완전히 제거됩니다.

위의 정보에서 수집할 다음 요점은 백엔드 애플리케이션이 비표준 헤더를 처리할 경우 밑줄이 없도록 확인해야 한다는 것입니다. 밑줄을 사용하는 헤더가 필요한 경우 구성에서 underscores_in_headers 지시어를 "on\으로 설정할 수 있습니다(http 컨텍스트 또는 기본 서버 선언 컨텍스트에서 유효). IP 주소/포트 조합) 이렇게 하지 않으면 Nginx는 이러한 헤더를 유효하지 않은 것으로 표시하고 업스트림으로 전달하기 전에 자동으로 삭제합니다.

"Host\ 헤더는 대부분의 프록시 시나리오에서 특히 중요합니다. 위에서 설명한 것처럼 기본적으로 이것은 도메인 이름 또는 IP를 포함하는 변수인 $proxy_host 값으로 설정됩니다. proxy_pass 정의에서 직접 가져온 주소 및 포트 Nginx가 업스트림 서버가 응답할 수 있는 유일한 주소이므로 기본적으로 선택됩니다(연결 정보에서 직접 가져오기 때문에).

"Host\ 헤더의 가장 일반적인 값은 다음과 같습니다.

  • $proxy_host: "Host\ 헤더를 proxy_pass 정의에서 가져온 도메인 이름 또는 IP 주소 및 포트 콤보로 설정합니다. 이것은 기본값이며 \\ Nginx의 관점에서 \안전\하지만 일반적으로 프록시 서버가 요청을 올바르게 처리하는 데 필요한 것은 아닙니다.
  • $http_host: "Host\ 헤더를 클라이언트 요청의 "Host\ 헤더로 설정합니다. 클라이언트가 보낸 헤더는 Nginx에서 항상 변수로 사용할 수 있습니다. 변수는 $http_ 접두사로 시작하고 그 뒤에 소문자로 된 헤더 이름이 오고 모든 대시는 밑줄로 대체됩니다. $http_host 변수가 대부분의 경우 작동하지만 클라이언트 요청에 유효한 "Host\ 헤더가 없으면 패스가 실패할 수 있습니다.
  • $host: 이 변수는 우선 순위에 따라 설정됩니다. 요청 라인 자체의 호스트 이름, 클라이언트 요청의 "Host\ 헤더 또는 일치하는 서버 이름 요청합니다.

대부분의 경우 "Host\ 헤더를 $host 변수로 설정하는 것이 좋습니다. 이는 가장 유연하며 일반적으로 다음과 같이 채워진 "Host\ 헤더를 프록시 서버에 제공합니다. 가능한 한 정확하게.

헤더 설정 또는 재설정

프록시 연결에 대한 헤더를 조정하거나 설정하려면 proxy_set_header 지시문을 사용할 수 있습니다. 예를 들어, 우리가 논의한 대로 "Host\ 헤더를 변경하고 프록시된 요청에 공통적인 몇 가지 추가 헤더를 추가하려면 다음과 같이 사용할 수 있습니다.

# server context

location /match/here {
    proxy_set_header HOST $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_pass http://example.com/new/prefix;
}

. . .

위의 요청은 "Host\ 헤더를 $host 변수로 설정하며, 여기에는 요청 중인 원래 호스트에 대한 정보가 포함되어야 합니다. X-Forwarded-Proto 헤더는 다음을 제공합니다. 원래 클라이언트 요청의 스키마에 대한 프록시 서버 정보(http 또는 https 요청인지 여부).

X-Real-IP는 클라이언트의 IP 주소로 설정되어 프록시가 이 정보를 기반으로 올바르게 결정을 내리거나 기록할 수 있습니다. X-Forwarded-For 헤더는 클라이언트가 지금까지 프록시된 모든 서버의 IP 주소를 포함하는 목록입니다. 위의 예에서는 이것을 $proxy_add_x_forwarded_for 변수로 설정했습니다. 이 변수는 클라이언트에서 검색된 원래 X-Forwarded-For 헤더의 값을 가져오고 Nginx 서버의 IP 주소를 끝에 추가합니다.

물론 proxy_set_header 지시문을 서버 또는 http 컨텍스트로 이동하여 둘 이상의 위치에서 참조할 수 있습니다.

# server context

proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

location /match/here {
    proxy_pass http://example.com/new/prefix;
}

location /different/match {
    proxy_pass http://example.com;
}

로드 밸런싱 프록시 연결을 위한 업스트림 컨텍스트 정의

이전 예제에서는 단일 백엔드 서버에 간단한 http 프록시를 수행하는 방법을 보여주었습니다. Nginx를 사용하면 요청을 전달할 수 있는 백엔드 서버의 전체 풀을 지정하여 이 구성을 쉽게 확장할 수 있습니다.

upstream 지시문을 사용하여 서버 풀을 정의하면 됩니다. 이 구성은 나열된 서버 중 하나가 클라이언트의 요청을 처리할 수 있다고 가정합니다. 이를 통해 거의 노력 없이 인프라를 확장할 수 있습니다. upstream 지시문은 Nginx 구성의 http 컨텍스트에서 설정해야 합니다.

간단한 예를 살펴보겠습니다.

# http context

upstream backend_hosts {
    server host1.example.com;
    server host2.example.com;
    server host3.example.com;
}

server {
    listen 80;
    server_name example.com;

    location /proxy-me {
        proxy_pass http://backend_hosts;
    }
}

위의 예에서 backend_hosts라는 업스트림 컨텍스트를 설정했습니다. 일단 정의되면 이 이름은 일반 도메인 이름인 것처럼 프록시 패스 내에서 사용할 수 있습니다. 보시다시피 서버 블록 내에서 example.com/proxy-me/...에 대한 모든 요청을 위에서 정의한 풀로 전달합니다. 해당 풀 내에서 구성 가능한 알고리즘을 적용하여 호스트를 선택합니다. 기본적으로 이것은 단순한 라운드 로빈 선택 프로세스입니다(각 요청은 차례로 다른 호스트로 라우팅됨).

업스트림 밸런싱 알고리즘 변경

업스트림 컨텍스트 내에 지시문 또는 플래그를 포함하여 업스트림 풀에서 사용하는 균형 조정 알고리즘을 수정할 수 있습니다.

  • (라운드 로빈): 다른 균형 지시문이 없는 경우 사용되는 기본 로드 균형 조정 알고리즘입니다. 업스트림 컨텍스트에 정의된 각 서버는 순차적으로 요청을 전달합니다.
  • least_conn: 활성 연결 수가 가장 적은 백엔드에 항상 새 연결을 제공하도록 지정합니다. 이는 백엔드에 대한 연결이 한동안 지속될 수 있는 상황에서 특히 유용할 수 있습니다.
  • ip_hash: 이 밸런싱 알고리즘은 클라이언트의 IP 주소를 기반으로 여러 서버에 요청을 분배합니다. 처음 세 옥텟은 요청을 처리할 서버를 결정하는 키로 사용됩니다. 그 결과 클라이언트는 매번 동일한 서버에서 서비스를 받는 경향이 있어 세션 일관성을 지원할 수 있습니다.
  • hash: 이 밸런싱 알고리즘은 주로 memcached 프록시와 함께 사용됩니다. 임의로 제공되는 해시키의 값을 기준으로 서버가 구분됩니다. 이는 텍스트, 변수 또는 조합일 수 있습니다. 이것은 사용자가 해시에 사용해야 하는 키인 데이터를 제공해야 하는 유일한 균형 방법입니다.

밸런싱 알고리즘을 변경할 때 블록은 다음과 같이 보일 수 있습니다.

# http context

upstream backend_hosts {

    least_conn;

    server host1.example.com;
    server host2.example.com;
    server host3.example.com;
}

. . .

위의 예에서 서버는 연결이 가장 적은 서버를 기준으로 선택됩니다. ip_hash 지시문은 동일한 방식으로 설정되어 일정량의 세션 "stickiness\를 얻을 수 있습니다.

hash 메소드의 경우 해시할 키를 제공해야 합니다. 이것은 당신이 원하는 무엇이든 될 수 있습니다:

# http context

upstream backend_hosts {

    hash $remote_addr$remote_port consistent;

    server host1.example.com;
    server host2.example.com;
    server host3.example.com;
}

. . .

위의 예는 클라이언트 IP 주소 및 포트 값을 기반으로 요청을 배포합니다. 또한 ketama 일관된 해싱 알고리즘을 구현하는 선택적 매개변수 consistent를 추가했습니다. 기본적으로 이는 업스트림 서버가 변경되더라도 캐시에 미치는 영향이 최소화됨을 의미합니다.

밸런싱을 위한 서버 가중치 설정

백엔드 서버 선언에서 기본적으로 각 서버는 \가중치\가 동일합니다. 이는 각 서버가 동일한 양의 로드를 처리할 수 있고 처리해야 한다고 가정합니다(밸런싱 알고리즘의 영향 고려). 선언 중에 서버에 대체 가중치를 설정합니다.

# http context

upstream backend_hosts {
    server host1.example.com weight=3;
    server host2.example.com;
    server host3.example.com;
}

. . .

위의 예에서 host1.example.com은 다른 두 서버보다 3배 더 많은 트래픽을 수신합니다. 기본적으로 각 서버에는 1의 가중치가 할당됩니다.

버퍼를 사용하여 백엔드 서버 확보

많은 사용자가 우려하는 프록싱의 한 가지 문제는 프로세스에 추가 서버를 추가할 때 성능에 미치는 영향입니다. 대부분의 경우 이는 Nginx의 버퍼링 및 캐싱 기능을 활용하여 크게 완화할 수 있습니다.

다른 서버에 프록시할 때 서로 다른 두 연결의 속도가 클라이언트의 경험에 영향을 미칩니다.

  • 클라이언트에서 Nginx 프록시로의 연결.
  • Nginx 프록시에서 백엔드 서버로의 연결.

Nginx는 이러한 연결 중 최적화하려는 연결에 따라 동작을 조정할 수 있습니다.

버퍼가 없으면 프록시 서버에서 데이터가 전송되고 즉시 클라이언트로 전송되기 시작합니다. 클라이언트가 빠르다고 가정하면 가능한 한 빨리 클라이언트에 데이터를 가져오기 위해 버퍼링을 끌 수 있습니다. 버퍼를 사용하면 Nginx 프록시가 백엔드의 응답을 임시로 저장한 다음 이 데이터를 클라이언트에 제공합니다. 클라이언트가 느리면 Nginx 서버가 백엔드에 대한 연결을 더 빨리 닫을 수 있습니다. 그런 다음 가능한 모든 속도로 클라이언트에 데이터 배포를 처리할 수 있습니다.

클라이언트마다 연결 속도가 크게 다른 경향이 있으므로 Nginx는 기본적으로 버퍼링 설계를 사용합니다. 다음 지시문을 사용하여 버퍼링 동작을 조정할 수 있습니다. http, 서버 또는 위치 컨텍스트에서 설정할 수 있습니다. 크기 조정 지시문은 요청별로 구성되므로 필요 이상으로 크기를 늘리면 클라이언트 요청이 많을 때 성능에 영향을 줄 수 있습니다.

  • proxy_buffering: 이 지시문은 이 컨텍스트 및 자식 컨텍스트에 대한 버퍼링을 활성화할지 여부를 제어합니다. 기본적으로 이것은 \켜짐입니다.
  • proxy_buffers: 이 지시문은 프록시 응답에 대한 버퍼의 수(첫 번째 인수)와 크기(두 번째 인수)를 제어합니다. 기본값은 하나의 메모리 페이지와 동일한 크기의 8개 버퍼를 구성하는 것입니다(4k 또는 8k). 버퍼 수를 늘리면 더 많은 정보를 버퍼링할 수 있습니다.
  • proxy_buffer_size: 헤더가 포함된 백엔드 서버 응답의 초기 부분은 나머지 응답과 별도로 버퍼링됩니다. 이 지시문은 응답의 이 부분에 대한 버퍼 크기를 설정합니다. 기본적으로 proxy_buffers와 같은 크기이지만 헤더 정보에 사용되므로 일반적으로 더 낮은 값으로 설정할 수 있습니다.
  • proxy_busy_buffers_size: 이 지시문은 "클라이언트 준비\로 표시되어 사용 중인 버퍼의 최대 크기를 설정합니다. 클라이언트는 한 번에 하나의 버퍼에서만 데이터를 읽을 수 있지만 버퍼는 묶음으로 클라이언트에 보내기 위해 대기열에 배치됩니다. 이 지시문은 이 상태에 있을 수 있는 버퍼 공간의 크기를 제어합니다.
  • proxy_max_temp_file_size: 디스크의 임시 파일에 대한 요청당 최대 크기입니다. 업스트림 응답이 너무 커서 버퍼에 맞지 않을 때 생성됩니다.
  • proxy_temp_file_write_size: 이것은 프록시 서버의 응답이 구성된 버퍼에 비해 너무 클 때 Nginx가 한 번에 임시 파일에 쓸 데이터의 양입니다.
  • proxy_temp_path: 업스트림 서버의 응답이 구성된 버퍼에 맞지 않을 때 Nginx가 임시 파일을 저장해야 하는 디스크 영역의 경로입니다.

보시다시피 Nginx는 버퍼링 동작을 조정할 수 있는 몇 가지 다른 지시문을 제공합니다. 대부분의 경우 이들 대부분에 대해 걱정할 필요가 없지만 이러한 값 중 일부를 조정하는 것이 유용할 수 있습니다. 아마도 조정에 가장 유용한 것은 proxy_buffers 및 proxy_buffer_size 지시문입니다.

각 업스트림 요청에 대해 사용 가능한 프록시 버퍼 수를 늘리는 동시에 헤더를 저장할 가능성이 있는 버퍼를 줄이는 예는 다음과 같습니다.

# server context

proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;

location / {
    proxy_pass http://example.com;
}

반대로 데이터를 즉시 제공하려는 빠른 클라이언트가 있는 경우 버퍼링을 완전히 끌 수 있습니다. Nginx는 업스트림이 클라이언트보다 빠르면 실제로 여전히 버퍼를 사용하지만 버퍼가 풀링되기를 기다리는 대신 즉시 클라이언트로 데이터를 플러시하려고 시도합니다. 클라이언트가 느린 경우 클라이언트가 따라잡을 수 있을 때까지 업스트림 연결이 열린 상태로 유지될 수 있습니다. 버퍼링이 "off\이면 proxy_buffer_size 지시문에 의해 정의된 버퍼만 사용됩니다.

# server context

proxy_buffering off;
proxy_buffer_size 4k;

location / {
    proxy_pass http://example.com;
}

고가용성(선택 사항)

중복 로드 밸런서 세트를 추가하여 고가용성 인프라를 생성함으로써 Nginx 프록싱을 더욱 강력하게 만들 수 있습니다.

고가용성(HA) 설정은 단일 장애 지점이 없는 인프라이며 로드 밸런서는 이 구성의 일부입니다. 로드 밸런서를 두 개 이상 보유하면 로드 밸런서를 사용할 수 없거나 유지 관리를 위해 중단해야 하는 경우 잠재적인 다운타임을 방지할 수 있습니다.

다음은 기본 고가용성 설정의 다이어그램입니다.

이 예에서는 한 서버에서 다른 서버로 다시 매핑할 수 있는 정적 IP 주소 뒤에 여러 로드 밸런서(활성 하나와 수동 하나 이상)가 있습니다. 클라이언트 요청은 고정 IP에서 활성 로드 밸런서로 라우팅된 다음 백엔드 서버로 라우팅됩니다. 자세한 내용은 예약된 IP 사용 방법 섹션을 참조하십시오.

응답 시간을 줄이기 위한 프록시 캐싱 구성

버퍼링은 더 많은 요청을 처리하기 위해 백엔드 서버를 확보하는 데 도움이 될 수 있지만 Nginx는 백엔드 서버의 콘텐츠를 캐시하는 방법도 제공하므로 많은 요청에 대해 업스트림에 연결할 필요가 전혀 없습니다.

프록시 캐시 구성

프록시 콘텐츠에 사용할 캐시를 설정하려면 proxy_cache_path 지시문을 사용할 수 있습니다. 이렇게 하면 프록시 서버에서 반환된 데이터를 보관할 수 있는 영역이 생성됩니다. proxy_cache_path 지시문은 http 컨텍스트에서 설정되어야 합니다.

아래 예에서는 캐싱 시스템을 설정하기 위해 이것과 일부 관련 지시문을 구성합니다.

# http context

proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backcache:8m max_size=50m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;

proxy_cache_path 지시문을 사용하여 캐시를 저장하려는 파일 시스템의 디렉토리를 정의했습니다. 이 예에서는 /var/lib/nginx/cache 디렉토리를 선택했습니다. 이 디렉토리가 존재하지 않는 경우 다음을 입력하여 올바른 권한 및 소유권으로 만들 수 있습니다.

sudo mkdir -p /var/lib/nginx/cache
sudo chown www-data /var/lib/nginx/cache
sudo chmod 700 /var/lib/nginx/cache

levels= 매개변수는 캐시 구성 방법을 지정합니다. Nginx는 키 값을 해싱하여 캐시 키를 생성합니다(아래 구성됨). 위에서 선택한 수준은 두 문자 하위 디렉터리(해시된 값의 끝에서 다음 두 문자에서 가져옴)가 있는 단일 문자 디렉터리(해시된 값의 마지막 문자가 됨)가 생성되도록 지시합니다. 일반적으로 이것의 세부 사항에 대해 걱정할 필요는 없지만 Nginx가 관련 값을 빠르게 찾는 데 도움이 됩니다.

keys_zone= 매개변수는 backcache라고 하는 이 캐시 영역의 이름을 정의합니다. 저장할 메타데이터의 양을 정의하는 곳이기도 합니다. 이 경우 8MB의 키를 저장하고 있습니다. 각 메가바이트당 Nginx는 약 8000개의 항목을 저장할 수 있습니다. max_size 매개변수는 실제 캐시된 데이터의 최대 크기를 설정합니다.

위에서 사용하는 또 다른 지시어는 proxy_cache_key입니다. 캐시된 값을 저장하는 데 사용할 키를 설정하는 데 사용됩니다. 이 키는 캐시에서 요청을 처리할 수 있는지 여부를 확인하는 데 사용됩니다. 이를 체계(http 또는 https), HTTP 요청 방법, 요청된 호스트 및 URI의 조합으로 설정하고 있습니다.

proxy_cache_valid 지시문은 여러 번 지정할 수 있습니다. 상태 코드에 따라 값을 저장할 기간을 구성할 수 있습니다. 이 예제에서는 10분 동안 성공 및 리디렉션을 저장하고 매분 404 응답에 대한 캐시를 만료합니다.

이제 캐시 영역을 구성했지만 캐시를 사용할 시기를 Nginx에 알려야 합니다.

백엔드로 프록시하는 위치에서 이 캐시의 사용을 구성할 수 있습니다.

# server context

location /proxy-me {
    proxy_cache backcache;
    proxy_cache_bypass $http_cache_control;
    add_header X-Proxy-Cache $upstream_cache_status;

    proxy_pass http://backend;
}

. . .

proxy_cache 지시문을 사용하여 backcache 캐시 영역이 이 컨텍스트에 사용되어야 함을 지정할 수 있습니다. Nginx는 백엔드로 전달하기 전에 여기에서 유효한 항목을 확인합니다.

proxy_cache_bypass 지시문은 $http_cache_control 변수로 설정됩니다. 여기에는 클라이언트가 캐시되지 않은 새로운 리소스 버전을 명시적으로 요청하는지 여부에 대한 표시기가 포함됩니다. 이 지시문을 설정하면 Nginx가 이러한 유형의 클라이언트 요청을 올바르게 처리할 수 있습니다. 추가 구성이 필요하지 않습니다.

X-Proxy-Cache라는 추가 헤더도 추가했습니다. 이 헤더를 $upstream_cache_status 변수의 값으로 설정합니다. 기본적으로 이것은 요청이 캐시 히트인지, 캐시 미스인지 또는 캐시가 명시적으로 우회되었는지 확인할 수 있는 헤더를 설정합니다. 이는 디버깅에 특히 유용하지만 클라이언트에도 유용한 정보입니다.

캐싱 결과에 대한 참고 사항

캐싱은 프록시의 성능을 엄청나게 향상시킬 수 있습니다. 그러나 캐시를 구성할 때 염두에 두어야 할 고려 사항이 있습니다.

첫째, 모든 사용자 관련 데이터를 캐시해서는 안 됩니다. 이로 인해 한 사용자의 데이터가 다른 사용자에게 제공될 수 있습니다. 사이트가 완전히 정적인 경우 문제가 되지 않을 수 있습니다.

사이트에 동적 요소가 있는 경우 백엔드 서버에서 이를 고려해야 합니다. 이를 처리하는 방법은 백엔드 처리를 처리하는 애플리케이션 또는 서버에 따라 다릅니다. 비공개 콘텐츠의 경우 데이터의 특성에 따라 Cache-Control 헤더를 "no-cache\, "no-store\ 또는 "private\로 설정해야 합니다.

  • no-cache: 백엔드에서 데이터가 변경되지 않았는지 먼저 확인하지 않고 응답을 다시 제공해서는 안 됨을 나타냅니다. 데이터가 동적이고 중요한 경우에 사용할 수 있습니다. ETag 해시 메타데이터 헤더는 각 요청에서 확인되며 백엔드가 동일한 해시 값을 반환하는 경우 이전 값을 제공할 수 있습니다.
  • no-store: 어떤 시점에서도 수신된 데이터를 캐시하지 않아야 함을 나타냅니다. 이것은 개인 데이터에 가장 안전한 옵션입니다. 이는 데이터가 매번 서버에서 검색되어야 함을 의미하기 때문입니다.
  • 개인: 공유 캐시 공간이 이 데이터를 캐시해서는 안 됨을 나타냅니다. 이것은 사용자의 브라우저가 데이터를 캐시할 수 있음을 나타내는 데 유용할 수 있지만 프록시 서버는 후속 요청에 대해 이 데이터가 유효한 것으로 간주해서는 안 됩니다.
  • public: 응답이 연결의 모든 지점에서 캐시될 수 있는 공개 데이터임을 나타냅니다.

이 동작을 제어할 수 있는 관련 헤더는 리소스를 캐시해야 하는 시간(초)을 나타내는 max-age 헤더입니다.

콘텐츠의 민감도에 따라 이러한 헤더를 올바르게 설정하면 개인 데이터를 안전하게 유지하고 동적 데이터를 최신 상태로 유지하면서 캐시를 활용하는 데 도움이 됩니다.

백엔드도 Nginx를 사용하는 경우 expires 지시문을 사용하여 이 중 일부를 설정할 수 있습니다. 그러면 Cache-Control에 대한 max-age가 설정됩니다. :

location / {
    expires 60m;
}

location /check-me {
    expires -1;
}

위의 예에서 첫 번째 블록은 콘텐츠를 1시간 동안 캐시할 수 있도록 허용합니다. 두 번째 블록은 Cache-Control 헤더를 "no-cache”로 설정합니다. 다른 값을 설정하려면 다음과 같이 add_header 지시문을 사용할 수 있습니다.

location /private {
    expires -1;
    add_header Cache-Control "no-store";
}

결론

Nginx는 무엇보다도 웹 서버로 작동할 수 있는 역방향 프록시입니다. 이러한 설계 결정으로 인해 다른 서버에 대한 프록시 요청은 매우 간단합니다. 하지만 Nginx는 매우 유연하므로 원하는 경우 프록시 구성을 보다 복잡하게 제어할 수 있습니다.