NGINX 및 NGINX Plus를 사용한 고성능 캐싱

이 게시물은 Andrew Alexeev가 소개하고 Owen Garrett이 진행한 웨비나 에서 발췌한 것입니다.

목차

소개

콘텐츠 캐싱 및 NGINX

캐싱 제어

질문과답변

0:00 소개

앤드류 알렉세예프 : 최신 웨비나에 오신 것을 환영합니다. 저는 앤드류입니다. NGINX 는 이고르 시소예프가 전 세계 웹사이트를 더 빠르게 실행하고, 반응성을 높이고, 쉽게 확장할 수 있도록 돕는다는 아이디어를 가지고 개발했습니다. 오늘날 NGINX는 인터넷의 상위 사이트의 30% 이상과 모든 웹사이트의 20% 이상을 구동합니다. [ 편집자 - 이 통계는 2014년 5월에 웨비나가 제공되었을 때 적용되었습니다. 현재 값은 여기에서 확인하세요. ] 이 웨비나의 내용이 기존 또는 계획된 NGINX 환경에 유용하고 적용 가능하기를 바랍니다.

이제 오웬 개럿을 소개하겠습니다. 오웬은 NGINX에서 제품 개발을 담당합니다. 오늘 오웬은 NGINX에서 강력한 캐싱 메커니즘을 적용하여 애플리케이션에서 반복적인 콘텐츠를 계속해서 생성하는 부담을 어떻게 해소할 수 있는지에 대해 이야기할 것입니다.

1:22 이 웨비나에 대하여

오웬 개렛 : 앤드류, 그리고 여러분, 앞으로 45~50분 동안 함께 해주셔서 정말 감사합니다. NGINX가 콘텐츠 캐싱 과 관련해 어떻게 기능하는지 설명하고, 성능을 개선할 수 있는 몇 가지 방법을 살펴보고, NGINX 내부에서 무슨 일이 일어나는지 디버깅하고 진단할 수 있도록 콘텐츠 캐싱이 실제로 어떻게 작동하는지 자세히 살펴보고, NGINX가 캐싱할 수 있는 콘텐츠에 대해 정말 세밀하게 제어할 수 있는 몇 가지 똑똑한 힌트와 팁을 제공합니다.

Andrew가 설명한 것처럼, 모두 동일한 핵심 이유를 목표로 합니다. 즉, 반복적인 콘텐츠를 생성하는 업스트림 서버의 부담을 없애 비즈니스에 정말 필요한 애플리케이션을 실행하는 데 집중할 수 있도록 하는 것입니다. 해당 서버를 넘어 확장하여 최종 사용자에게 더 나은 수준의 서비스를 제공하고 인터넷 트래픽이 급증하거나 업스트림 서버에 장애가 발생할 가능성이 있을 때에도 서비스의 안정성을 높여줍니다.

2:17 콘텐츠 캐싱의 기본 원칙

NGINX 구현 구성을 살펴보기 전에 콘텐츠 캐싱이 어떻게 기능하는지 간단히 살펴보겠습니다. 이를 통해 모두가 동일한 페이지, 동일한 핵심 정보 기준에서 시작할 수 있습니다.

2:35 기본 원칙

콘텐츠 캐싱의 기본 원리는 업스트림 서버에서 반복되는 작업을 오프로드하는 것입니다. 첫 번째 사용자가 웹사이트에서 콘텐츠 항목을 요청하면(파란색 아이콘과 파란색 선으로 표시), 해당 HTTP 요청은 NGINX로 전달되고, 거기에서 오른쪽에 회색으로 표시된 업스트림 서버로 전달됩니다.

응답은 원격 사용자에게 다시 전달되지만 캐시 가능한 경우(곧 이것이 무슨 뜻인지 설명하겠습니다) NGINX는 해당 응답의 사본을 저장합니다. 다른 사용자, 즉 오렌지색 사람이 같은 콘텐츠를 요청하면 NGINX는 업스트림 서버에서 요청을 위조하지 않고도 로컬 캐시에서 직접 해당 콘텐츠를 제공할 수 있습니다.

캐시 가능하고 변경되지 않는 콘텐츠를 저장한다는 이 기본 원칙은 웹 브라우저, CDN, 액세스하는 사이트, CDN 활용 및 다른 장치의 NGINX에서 사용됩니다. 역방향 프록시 캐시로 작동하며, 일반적으로 웹 콘텐츠와 웹 애플리케이션을 호스팅하는 원본 서버 옆의 데이터 센터나 클라우드에 배포됩니다.

3:59 HTTP 캐싱의 메커니즘

원본 서버는 여러 가지 잘 이해되고 잘 알려진 HTTP 응답 헤더 중 하나 이상을 사용하여 콘텐츠의 캐시 가능성을 선언합니다. 물론, 캐싱 서버는 이 동작을 무시하거나 재정의하거나 변경할 수 있습니다. 하지만 구성된 콘텐츠 캐싱을 이해하려면 원본 서버에서 콘텐츠가 캐시 가능하고 변경되지 않으며 [캐시된] 복사본에 특정 수명이 있음을 나타내는 방식을 잘 이해해야 합니다.

콘텐츠 캐싱은 Expires 라는 간단한 HTTP 응답 헤더로 시작되었습니다. 원본 서버는 일부 콘텐츠를 제공하고 해당 콘텐츠가 Expires 헤더에 있는 날짜까지 유효하다고 선언합니다. 이 방법은 더 효과적이고 유연한 방법인 Cache-Control 헤더에 의해 빠르게 대체되었습니다.

만료는 사용하기 다소 불편하고 비효율적입니다. 날짜는 올바르게 형식이 지정되고 구문 분석되어야 하는 반면, Cache-Control은 훨씬 더 간소화되어 콘텐츠 캐시의 요구 사항과 속도에 맞춰 조정됩니다. Cache-Control은 콘텐츠를 공개 또는 비공개로 선언하고 공개인 경우 최대 수명 (캐싱 개체가 해당 콘텐츠를 다시 요청해야 하기 전에 캐시할 수 있는 시간(초))을 선언합니다.

캐싱을 직접 제어하는 세 번째 헤더는 X-Accel-Expires 입니다. 이 헤더는 NGINX에만 있는 특별한 헤더입니다. NGINX만 이 헤더를 이해하고 위 헤더의 동작을 재정의하고 NGINX에 콘텐츠 항목을 얼마 동안 캐시해야 하는지 직접 정확하게 알리려는 경우 사용됩니다.

웹 브라우저가 장시간 콘텐츠를 캐시하길 원하지만 프록시 캐시(원본 서버 앞에 있는 NGINX)가 더 짧은 기간 동안만 콘텐츠를 캐시하도록 하면 변경 사항이 더 빨리 반영되고 새 클라이언트에 푸시되고, 이전 클라이언트가 필요하지 않을 때 콘텐츠를 계속 다시 요청하지 않아도 되는 상황이 있습니다.

하지만 이 방법은 마지막 두 헤더를 사용하여 구현될 수도 있습니다. 원본 서버는 콘텐츠 항목이 마지막으로 수정된 시점을 선언할 수 있으며 ETag (엔터티 태그)라는 것을 선언할 수 있습니다. ETag는 해시 값인 불투명한 문자열로, 해당 콘텐츠를 식별합니다.

그러면 클라이언트는 조건부 GET 을 사용하여 요청을 할 수 있습니다. 요청에 If-Modified-Since 또는 If-None-Match 헤더를 포함할 수 있습니다. 이를 통해 클라이언트는 특정 날짜에 마지막으로 수정되었거나 특정 ETag 가 있는 콘텐츠의 캐시된 버전이 있다고 선언합니다. 서버가 보유한 최신 버전이 클라이언트가 보유한 버전과 일치하는 경우 서버는 간단히 다음과 같이 응답합니다. 304수정 되지 않음 . 이는 네트워크 대역폭을 절약하는 빠른 응답이며, 클라이언트가 캐시된 콘텐츠 사본이 여전히 유효한지 여유롭게 확인할 수 있게 해줍니다.

이러한 5개의 헤더는 원본 서버의 관점에서 콘텐츠의 캐시 가능 여부, 즉 유효성, 신선도, ETag 측면에서 콘텐츠 자체의 세부 정보를 정의합니다.

7:46 NGINX는 무엇을 캐시하나요?

NGINX와 같은 프록시 캐시는 해당 헤더를 얼마나 엄격하게 준수할지 해석하는 데 비교적 자유롭습니다. 분명히 캐시할 수 없는 것을 캐시해서는 안 되지만, 원본 서버에서 캐시할 수 있다고 하면 캐시할 의무는 당연히 없습니다.

NGINX의 기본 동작은 응답에 Set-Cookie 헤더가 없는 경우 원본 서버에서 캐시 가능으로 지정한 모든 GET 및 HEAD 요청을 캐시하는 것입니다. Set-Cookie 헤더에는 일반적으로 각 요청에 맞는 고유한 데이터가 포함되고 기본적으로 해당 값을 캐시하는 것이 적합하지 않기 때문입니다.

NGINX는 각 리소스를 특정 키, 즉 캐시 키로 캐시합니다. 동일한 캐시 키를 생성하는 모든 요청은 동일한 리소스로 충족됩니다. 기본적으로 캐시는 원시 URL에 매핑되거나 구성에서 이 슬라이드에 표시된 문자열[ $scheme$proxy_host$uri$is_args$args ]에 매핑됩니다. NGINX가 콘텐츠를 캐싱하는 시점에 [유효 기간]은 X-Accel-Expires 헤더(있는 경우) 또는 Cache-Control 헤더나 레거시 Expires 헤더에 의해 (우선순위 순서대로) 정의됩니다.

NGINX를 조정하여 이러한 헤더 중 일부를 마스크 처리하거나 원본 서버가 말하는 내용과 전혀 상관없이 고정된 캐시 시간을 제공할 수 있습니다. 참고로 RFC 2616은 HTTP와 관련된 프록시 캐시의 원하는 동작을 정의합니다.

따라서 이를 통해 캐싱의 보편성과 NGINX가 일반적으로 캐싱하기에 안전한 콘텐츠를 캐싱하여 웹사이트를 가속화하고 원본 서버의 부하를 줄이는 기본 동작에 대한 간략한 설명을 얻을 수 있습니다.

9:55 NGINX가 작동 중입니다.

이제 NGINX의 작동 방식을 살펴보겠습니다. NGINX를 구성하여 콘텐츠 캐싱을 활성화하는 것은 정말 쉽습니다.

10:06 NGINX 구성

NGINX 설정 파일에 몇 줄을 추가하는데, 그 중 하나는 디스크에 캐시를 만드는 것으로, 파일의 배치 방식, 캐시에 있는 객체의 만료 시간, 캐시 크기를 선언하는 특정 매개변수 집합을 포함합니다. 두 번째인 proxy_cache 지시어는 NGINX 프록시와 연결되어 콘텐츠(결과, 응답)를 명명된 캐시에 캐시해야 함을 알려줍니다.

여기서 저는 하나 의 캐시를 생성했습니다. 메타데이터의 경우 메모리에서는 크기가 10MB이지만, 캐시된 콘텐츠의 경우 디스크에서는 크기가 무제한입니다. 콘텐츠는 캐시된 후 60분 동안 비활성 상태이면 다시 회수됩니다. one 이라는 캐시는 기본 서버에서 사용됩니다. 이 두 가지 [지침], proxy_cache_path 및 proxy_cache 는 NGINX의 프록시 서버에 대한 안정적이고 일관된 캐싱을 활성화하기에 충분합니다.

11:14 캐싱 프로세스

NGINX가 요청을 받고 캐시를 쿼리할 때 거치는 프로세스는 다음과 같이 정의됩니다. 먼저 요청을 읽고(이 슬라이드의 왼쪽 위 상자) 캐시 키를 원시 URI와 해당 요청에 해당하는 리소스를 식별하는 데 사용할 다른 매개변수로 조립합니다. 그런 다음 메모리의 메타데이터에 액세스하여 디스크의 캐시를 확인하여 해당 요청에 대한 응답의 유효하고 최신 사본이 있는지 확인합니다.

만약 그렇다면 그것은 명중으로 간주됩니다. 그러면 NGINX가 캐시에서 직접 응답할 수 있습니다. NGINX가 정적 콘텐츠를 제공하는 것과 똑같이 디스크에서 콘텐츠를 제공하여 캐시에서 응답합니다. 따라서 NGINX는 뛰어난 성능, 안정성, 확장성을 제공하도록 설계되었습니다. 정적 콘텐츠를 사용하면 NGINX 콘텐츠 캐시에서 콘텐츠를 제공할 때 정확히 동일한 수준의 [성능]을 얻을 수 있습니다.

반면, 캐시를 확인할 때 캐시 미스가 발생할 수 있습니다. 이는 캐시에 콘텐츠가 없거나 캐시에 있는 콘텐츠가 오래되어 새로 고쳐야 한다는 것을 의미합니다. 가장 간단한 경우, 미스는 우리가 원본 서버에 해당 콘텐츠를 요청하고 응답을 받은 후 캐시 가능한지 확인하는 것을 의미합니다.

그렇다면, 프록시 모드에서 처리되는 대용량 응답에 대해 NGINX가 하는 것과 마찬가지로 디스크에 스트리밍합니다. 그런 다음 [응답이] 디스크로 스트리밍되면 이를 캐시에 복사하고 캐시에서 직접 응답합니다. 이 접근 방식의 과제 중 하나는 NGINX가 동일한 콘텐츠에 대한 여러 요청을 동시에 수신하여 모두 실패로 이어지는 경우입니다.

NGINX는 일반적으로 이러한 모든 요청을 원본 서버로 전달하여 원본 서버에 과부하를 일으킬 가능성이 있습니다. 특히 응답을 생성하는 데 시간이 오래 걸리는 요청의 경우 더욱 그렇습니다. 이런 이유로 캐시 잠금을 사용할 수 있습니다. proxy_cache_lock 지시어는 콘텐츠가 새로 고쳐질 때 한 번에 하나의 요청만 업스트림 서버로 전송되도록 합니다.

그래서 제가 설명한 시나리오에서 첫 번째 요청은 업스트림 서버로 이동하지만 동일한 콘텐츠에 대한 나머지 요청은 응답이 제공되어 캐시에 삽입될 때까지(이 시점에서 모든 요청을 충족할 수 있음) 보류되거나 시간 초과( proxy_cache_lock_timeout 지시문으로 설정)에 도달할 때까지 보류됩니다. 시간 초과는 NGINX가 서버에서 콘텐츠가 돌아올 때까지 충분히 기다린 후, 그 시점에서 해제된 요청이 원본 서버로 전달되는 것을 의미합니다.

따라서 proxy_cache_lock 과 timeout은 많은 요청이 동일한 콘텐츠에 대해 발생하는 바쁜 사이트가 있을 때 해당 콘텐츠가 캐시에서 만료되더라도 갑자기 여러 요청으로 원본 서버에 과부하가 걸리는 것을 방지하는 강력한 제어 기능을 제공합니다.

NGINX의 캐싱 프로세스에는 이 흐름도에 깔끔하게 들어맞지 않는 요소가 하나 더 있습니다. 왜냐하면 이 요소는 차트의 거의 모든 단계를 포괄하기 때문입니다. 이는 proxy_cache_use_stale 지시문으로 구성된 기능입니다. 언제든지 이러한 단계 중 하나가 어떤 이유로든 실패하면, 예를 들어 콘텐츠를 업데이트하는 중에 시간 초과가 발생하거나 업스트림 서버로부터 잘못된 응답을 받거나 다른 유형의 오류가 발생하면 캐시된 콘텐츠가 오래되었더라도 캐시에서 직접 응답하는 옵션이 있습니다.

이 도구는 업스트림 서버가 트래픽으로 인해 과부하가 걸리거나 유지 관리 또는 치명적인 오류로 인해 장애가 발생하는 경우 매우 강력한 도구입니다. 이를 통해 NGINX는 클라이언트에 오류 메시지를 반환하지 않고도 캐시에 있는 오래된 콘텐츠를 사용하여 콘텐츠를 계속 전송할 수 있습니다.

15:32 캐싱은 HTTP만을 위한 것이 아닙니다

NGINX의 캐싱은 HTTP에만 국한되지 않습니다. NGINX는 상위 웹 서버로 요청을 전달하는 단순한 HTTP 프록시보다 훨씬 더 많은 기능을 제공합니다. 일반적으로 이러한 업스트림 웹 서버는 FastCGI나 SCGI와 같은 API와 인터페이스하기 위해 존재합니다. NGINX는 HTTP 프록시와 매우 유사한 프록시 방식으로 직접 이를 수행할 수 있습니다.

NGINX는 HTTP 프록시 , FastCGI 프록시 , uWSGI 프록시 및 SCGI 프록시 에 대해 캐싱 기술을 사용할 수 있습니다. 모든 서비스는 HTTP 프록시와 거의 같은 방식으로 작동합니다. 즉, 캐시는 디스크에 저장되고 직접 응답하므로 이러한 업스트림 서비스에 대한 프록시가 필요 없습니다.

NGINX는 memcached 서버와도 인터페이스할 수 있는데, 이는 약간 다른 캐싱 접근 방식입니다. 이 경우 NGINX는 콘텐츠를 직접 저장하지 않고 프록시로 memcached를 사용하며 외부 에이전트에 의존하여 필요한 콘텐츠로 memcached를 채웁니다. 이는 또 다른 유용한 도구가 될 수 있으며, 필요한 경우 외부 사이트에서 memcached를 채우는 방법이 많이 있습니다. 따라서 비즈니스 요구 사항이라면 이것을 NGINX에 대한 캐시를 시딩하는 방법으로 간주할 수 있습니다.

17:10 무슨 일이 일어나고 있는지 이해하는 방법

여러 계층으로 구성된 대규모 인프라가 있고 일부는 캐싱을 하고, 일부는 캐싱을 하지 않고, 일부는 콘텐츠를 생성하고 일부는 생성하지 않는 경우 캐싱은 잠재적으로 매우 복잡해질 수 있습니다. 이 경우 무슨 일이 일어나고 있는지(콘텐츠가 어디에서 오는지) 추적하고, 발생한 문제를 진단하고 디버깅하는 것이 매우 어려울 수 있습니다. NGINX에서는 여러분이 최대한 쉽게 사용할 수 있도록 만들었습니다.

17:38 캐시 계측

정교한 계측을 사용하면 계측을 동적으로 제어하여 콘텐츠의 출처, 캐시의 저장 위치 및 캐시 상태를 추적할 수 있습니다.

첫 번째 단계는 $upstream_cache_status 변수입니다. 이 변수는 캐시에서 왔는지 여부와 관계없이 NGINX가 응답한 각 요청에 대해 계산됩니다. 그리고 add_header 지시문을 사용하여 해당 변수의 값을 응답에 지속적으로 추가합니다. 관례적으로 우리는 해당 값을 응답의 X-Cache-Status 헤더에 넣습니다. 이는 7가지 값 중 하나를 사용하여 해당 콘텐츠가 어떻게 제공되었는지 선언합니다. 캐시를 우회했는지, 재검증에서 나왔는지, 히트였는지 여부입니다.

이는 여러분의 반응이 어디에서 오는지 이해하기 위한 첫 번째 단계입니다. 로컬 NGINX 캐시에서 왔는가, 아니면 업스트림 서버에서 왔는가? 그리고 다양한 방법으로 해당 응답 헤더를 검사할 수 있습니다. 예를 들어 curl 과 같은 도구를 사용하여 명령줄에서 검사할 수도 있고, 대화형 디버거를 사용하여 웹 브라우저에서 검사할 수도 있습니다.

물론 모든 최종 사용자에게 해당 값을 선언하고 싶지 않을 수도 있습니다. 헤더 응답에 해당 값을 삽입하는 시기를 선택적으로 지정하는 것이 좋습니다.

19:08 캐시 계측(계속)

NGINX의 구성 언어는 선택적 유연성을 제공합니다. 이 예제는 이를 수행할 수 있는 여러 방법 중 하나를 보여줍니다. 원격 주소를 가져와서 해당 주소가 로컬호스트인 경우 $upstream_cache_status를 임시 변수( $cache_status )에 저장합니다. 마지막으로 응답을 제공할 때 응답에 임시 변수를 넣습니다.

이렇게 하면 선택된 IP 주소의 요청만 $upstream_cache_status 변수의 값을 볼 수 있습니다. 그 외에도 많은 작업을 할 수 있습니다. 곧 콘텐츠가 디스크에 어떻게 저장되는지 살펴보겠습니다. 디스크에서 위치를 계산하는 데 사용되는 키를 응답에 넣을 수 있습니다. 캐시가 실행되는 동안 이를 진단하는 데 도움이 되는 모든 종류의 매개변수를 응답에 넣을 수 있습니다.

20:09 캐시 상태

NGINX Plus는 NGINX의 상용 버전으로, 캐싱과 같은 사용 사례에 도움이 되는 여러 추가 기능을 제공합니다. NGINX Plus는 모스크바에 있는 엔지니어링 팀에서 구축한 상업적으로 지원되는 NGINX 빌드이며, 올바른 작동을 보장하기 위해 광범위한 회귀 테스트를 거쳤습니다.

NGINX Plus에는 NGINX를 역방향 프록시 및 부하 분산 장치로 사용하려는 기업을 대상으로 하는 다양한 기능도 포함되어 있습니다. 부하 분산, 상태 점검, 고급 비디오 스트리밍과 같은 기능이 있습니다. 이와 관련하여 확장된 상태, 더 나은 진단 및 NGINX에서 발생하는 일에 대한 시각화와 관련된 기능이 있습니다.

[편집자 - 위 슬라이드와 다음 문단은 원래 여기에서 논의된 별도의 상태 모듈을 대체하고 더 이상 사용되지 않는 NGINX Plus API를 참조하도록 업데이트되었습니다.]

데모를 보려면 demo.nginx.com/dashboard.html 로 이동하면 NGINX Plus API를 사용하여 NGINX Plus에서 게시된 상태 데이터를 표시하는 웹 페이지가 표시됩니다. 표시된 curl 명령을 실행하면 NGINX Plus 바이너리에서 직접 가져온 원시 JSON 데이터가 표시됩니다(여기서는 각 요소를 개별 줄에 배치하고 계층적으로 들여쓰기하기 위해 jq 유틸리티로 파이프됩니다).

해당 JSON 데이터에서 NGINX Plus 배포의 각 캐시 상태에 대한 실시간 데이터를 확인할 수 있습니다. 이 방법과 $upstream_cache_status 변수 및 캐시를 계측할 수 있는 다른 방법을 사용하면 NGINX가 콘텐츠를 캐시하는 방법에 대한 매우 좋은 개요를 제공하고 개별 요청을 자세히 분석하여 해당 요청이 캐시에서 왔는지 여부와 캐시 내의 현재 상태를 파악할 수 있습니다.

21:57 NGINX에서 콘텐츠 캐싱이 기능하는 방식

이제 외부에서 연락처 캐싱을 조사하는 방법을 살펴보았으니, 이제 내부에서 살펴보겠습니다. NGINX 내에서 어떻게 작동하나요? 앞서 언급했듯이 NGINX의 콘텐츠 캐시는 디스크에 있는 파일을 처리하는 것과 거의 같은 방식으로 작동합니다. 콘텐츠 캐시에서 콘텐츠를 제공할 때와 정적 콘텐츠를 제공할 때 모두 동일한 성능, 동일한 안정성, 동일한 운영 체제 최적화를 얻을 수 있습니다. 바로 NGINX가 유명한 성능입니다.

22:40 작동 원리

콘텐츠 캐시는 영구 캐시로 디스크에 저장됩니다. 우리는 운영 체제와 협력하여 디스크 캐시를 메모리로 바꿔서 운영 체제 페이지 캐시에 메모리에 어떤 내용을 저장해야 할지에 대한 힌트를 제공합니다. 즉, 캐시에서 콘텐츠를 제공해야 할 때 매우 빠르게 처리할 수 있습니다.

캐시 주변의 메타데이터, 즉 캐시에 무엇이 있는지와 만료 시간에 대한 정보는 모든 NGINX 프로세스의 공유 메모리 섹션에 별도로 저장되며 항상 메모리에 존재합니다. 따라서 NGINX는 캐시를 쿼리하고, 매우 빠르게 캐시를 검색할 수 있으며, 응답을 가져와 최종 사용자에게 다시 제공해야 할 때만 페이지 캐시로 이동하면 됩니다.

캐시에 콘텐츠가 어떻게 저장되는지 살펴보고, 시작 시 해당 영구 캐시가 빈 NGINX 작업자 프로세스에 어떻게 로드되는지 살펴보고, NGINX가 캐시에서 자동으로 수행하는 일부 유지 관리를 살펴보고, 특정 상황에서 캐시에서 콘텐츠를 수동으로 정리하는 방법을 살펴보겠습니다.

23:53 캐시된 콘텐츠는 어떻게 저장되나요?

콘텐츠 캐시는 proxy_cache_path 라는 지시문을 사용하여 선언된다는 것을 기억하시나요? 이 지시어는 매개변수의 개수를 지정합니다. 여기에는 캐시가 파일 시스템에 저장되는 위치, 캐시 이름, 메타데이터에 대한 메모리의 캐시 크기, 디스크의 캐시 크기가 포함됩니다. 이 경우 디스크에 40MB의 캐시가 있습니다.

콘텐츠가 저장된 위치를 이해하는 데 중요한 것은 캐시 키, 즉 NGINX가 캐시 가능한 각 리소스에 할당하는 고유 식별자를 이해하는 것입니다. 기본적으로 해당 식별자는 요청의 기본 매개변수, 즉 스키마, 호스트 헤더, URI 및 문자열 인수로 구성됩니다.

하지만 쿠키 값이나 인증 헤더, 심지어 런타임에 계산한 값 등을 사용하여 원하는 대로 확장할 수 있습니다. 영국 사용자와 미국 사용자를 위해 서로 다른 버전을 저장하고 싶을 수도 있습니다. 이 모든 것은 proxy_cache_key 지시문을 구성하여 가능합니다.

NGINX가 요청을 처리할 때 proxy_cache_key를 계산하고, 이 값에서 MD5 합계를 계산합니다. 슬라이드 아래쪽에 보여드린 명령줄 예제를 사용하여 직접 복제할 수 있습니다. 캐시 키 httplocalhost:8002/time.php 를 가져와 md5sum 을 통해 펌핑합니다. 껍질에서 이 작업을 할 때는 새로운 줄을 함께 펌핑하지 않도록 주의하세요.

그러면 캐시 가능한 콘텐츠에 해당하는 MD5 해시 값이 계산됩니다. NGINX는 해당 해시 값을 사용하여 디스크에서 콘텐츠를 저장해야 하는 위치를 계산합니다. proxy_cache_path 에서 1문자로 구성된 디렉토리와 2문자로 구성된 디렉토리로 2단계 캐시를 지정했다는 것을 알 수 있습니다. 우리는 문자열의 끝에서 해당 문자를 추출하여 디렉토리를 생성합니다.4 그리고 9b 라는 하위 디렉토리를 만들고, 캐시의 내용(헤더와 소량의 메타데이터 포함)을 디스크에 있는 파일에 저장합니다.

콘텐츠 캐싱을 테스트할 수 있습니다. 캐시 키를 응답 헤더 중 하나로 인쇄할 수 있으며, md5sum 을 통해 해당 값의 해시 대응 관계를 계산할 수 있습니다. 그런 다음 디스크에 있는 값을 검사하여 값이 실제로 존재하는지 확인하고 NGINX가 캐시한 헤더를 확인하여 이 모든 것이 어떻게 연결되어 있는지 이해할 수 있습니다.

26:36 디스크에서 캐시 로딩 중

이제 콘텐츠가 디스크에 저장되고 영구적으로 유지되므로 NGINX가 시작될 때 해당 콘텐츠를 메모리에 로드해야 합니다. 즉, 디스크 캐시에서 작업하고 메타데이터를 추출한 다음 각 작업자 프로세스에서 사용하는 공유 메모리 세그먼트의 메모리에 메타데이터를 로드해야 합니다. 이 작업은 캐시 로더 라는 프로세스를 사용하여 수행됩니다.

캐시 로더는 시작 시 시작되고 한 번 실행되어 메타데이터를 작은 청크로 디스크에 로드합니다. 한 번에 100개의 파일을 샌드박싱하여 200ms로 처리한 다음 그 사이에 50ms 동안 일시 중지한 다음 전체 캐시를 처리하고 공유 메모리 세그먼트를 채울 때까지 반복합니다.

그러면 캐시 로더가 종료되고 NGINX를 다시 시작하거나 재구성하고 공유 메모리 세그먼트를 다시 초기화해야 하는 경우가 아니면 다시 실행할 필요가 없습니다. 매우 빠른 디스크와 가벼운 부하가 있는 경우 캐시 로더의 작동을 조정할 수 있습니다. 캐시를 대량의 파일과 느린 디스크로 저장하고 NGINX가 시작될 때 캐시 로더가 과도한 CPU를 사용하지 않도록 하려면 실행 속도를 더 빠르게 할 수도 있고, 약간 늦추는 것이 좋습니다.

28:07 디스크 캐시 관리

캐시가 메모리에 저장되고 파일이 디스크에 저장되면 액세스되지 않은 캐시된 파일이 영원히 남아 있을 위험이 있습니다. NGINX는 처음으로 파일을 볼 때 이를 저장하지만, 파일에 대한 요청이 더 이상 없으면 [파일]은 무언가가 나타나 정리할 때까지 디스크에 그대로 보관됩니다.

이것은 캐시 관리자 입니다. 주기적으로 실행되어 특정 기간 동안 액세스되지 않은 파일을 디스크에서 제거하고, 캐시가 너무 크고 선언된 크기를 넘치면 파일을 삭제합니다. 가장 최근에 사용되지 않은 항목 순으로 삭제합니다. 캐시 로더를 구성하는 것처럼 proxy_cache_path [지침]에 대한 매개변수를 사용하여 이 작업을 구성할 수 있습니다.

• 비활성 시간은 기본적으로 10분입니다.
• 최대 크기 매개변수에는 기본 제한이 없습니다. 캐시에 최대 크기 제한을 적용하면 때때로 그 제한을 초과할 수 있지만 캐시 관리자가 실행되면 가장 최근에 사용되지 않은 파일을 제거하여 그 제한 아래로 되돌립니다.

29:22 디스크에서 콘텐츠 제거

마지막으로 디스크에서 콘텐츠를 제거해야 할 때가 있습니다. 파일을 찾아 삭제하고 싶다면, 앞서 언급한 기술( md5sum을 통해 캐시 키를 실행하거나 파일 시스템 전체에서 재귀적 grep을 실행하여 삭제해야 할 파일을 식별하는 방법)을 알고 있다면 비교적 쉽게 할 수 있습니다.

또는 NGINX Plus를 사용하는 경우, 해당 제품에 내장된 캐시 제거 기능을 사용할 수 있습니다. 캐시 제거 기능을 사용하면 요청에서 특정 매개변수를 가져올 수 있습니다. 일반적으로 PURGE 라는 메서드를 사용하여 해당 요청이 캐시 제거 요청인지 식별합니다.

제거 작업은 URI를 검사하고 해당 URI와 일치하는 모든 파일을 캐시에서 삭제하는 특수 NGINX Plus 핸들러에 의해 처리됩니다. URI에 별표를 접미사로 붙이면 스템이 됩니다. 이 경우, 로컬호스트 포트 8001에서 제공되는 모든 파일을 삭제하기 위해 퍼지 기능을 사용할 것입니다. 물론 하위 디렉토리도 넣을 수 있습니다.

어떤 방법을 사용하든 언제든지 디스크의 캐시에서 파일을 삭제하거나 rm -rf 명령을 사용하여 전체 캐시 디렉터리를 삭제해도 전혀 안전합니다. NGINX는 잠시도 멈추지 않고 디스크에 있는 파일의 존재 여부를 계속 확인합니다. 해당 항목이 누락되면 캐시 미스가 발생합니다. 그러면 NGINX가 원본 서버에서 캐시를 검색하여 디스크의 캐시에 다시 저장합니다. 따라서 캐시에서 개별 파일을 지워야 하는 경우 항상 안전하고 안정적입니다.

31:27 캐싱 제어

그래서 우리는 캐싱이 어떻게 작동하는지 살펴보고, NGINX 내부에서 구현된 부분을 살펴보았으며, 정적 콘텐츠에서 얻는 것과 동일한 성능을 얻기 위해 디스크에 파일을 저장하는 방법에 대해 심층적으로 알아보았습니다. 이제 캐싱에 대해 조금 더 자세히 알아보겠습니다.

간단한 사이트의 경우 캐싱 기능을 켜면 일반적으로 원하는 수준의 성능과 캐시 동작을 유지하는 데 필요한 작업을 정확하게 수행합니다. 하지만 항상 최적화해야 할 부분이 있고 기본 동작이 원하는 동작과 일치하지 않는 상황이 종종 발생합니다.

아마도 원본 서버가 올바른 응답 헤더를 설정하지 않았거나 NGINX 자체 내부에서 지정한 내용을 재정의하려고 할 수도 있습니다. 캐싱 작동 방식을 미세 조정하기 위해 NGINX를 구성할 수 있는 방법은 매우 다양합니다.

32:30 지연 캐싱

캐싱을 지연할 수 있습니다. 이는 콘텐츠의 양이 방대하고 그 중 대부분이 1시간 또는 하루에 한두 번만 접근되는 경우 매우 흔한 상황입니다. 그런 경우, 읽는 사람이 거의 없는 회사 브로셔가 있다면, 그 내용을 캐시하려고 시도하는 것은 시간 낭비일 뿐입니다. 지연 캐싱을 사용하면 워터마크를 삽입할 수 있습니다. 특정 횟수만큼 요청된 경우에만 캐시된 버전의 콘텐츠가 저장됩니다. proxy_cache_min_uses 워터마크에 도달하기 전까지는 캐시에 버전이 저장되지 않습니다.

이를 통해 캐시에 들어갈 콘텐츠에 대한 차별성을 더욱 강화할 수 있습니다. 캐시 자체는 제한된 리소스이며 일반적으로 서버에 있는 메모리 양에 따라 제한됩니다. 가능한 한 캐시가 메모리에 페이지되도록 해야 하기 때문입니다. 그래서 특정 유형의 콘텐츠를 제한하고 인기 있는 요청만 캐시에 넣고 싶어하는 경우가 많습니다.

캐시 재검증은 최근 NGINX Open Source와 NGINX Plus에 추가된 기능입니다. NGINX가 캐시된 값을 새로 고쳐야 할 때, 간단한 GET 요청을 하지 않고 "이 특정 시간과 날짜에 수정된 캐시된 버전이 있습니다"라는 조건부 GET 요청을 하도록 If-Modified-Since 기능을 수정합니다.

원본 서버는 다음으로 응답할 수 있는 옵션이 있습니다. 304수정되지 않음 은 사실상 현재 버전이 여전히 가장 최신 버전이라는 것을 의미합니다. 그렇게 하면 상류 대역폭이 절약되고, 원본 서버는 변경되지 않은 콘텐츠를 다시 보낼 필요가 없으며 디스크 쓰기도 절약될 수 있습니다. NGINX는 해당 연락처를 디스크로 스트리밍한 다음 이를 적절한 자리에 바꿔서 이전 버전을 덮어쓸 필요가 없습니다.

34:45 캐시 시간 제어

콘텐츠를 캐시하는 기간을 세부적으로 제어할 수 있습니다. 원본 서버는 브라우저에 적합한 캐시 헤더와 함께 콘텐츠를 제공하는 경우가 많습니다. 이는 콘텐츠를 새로 고치라는 비교적 빈번한 요청과 함께 장기 캐싱을 수행합니다. 하지만 NGINX 프록시를 원본 서버 바로 앞에 배치하여 파일을 조금 더 자주 새로 고치고 변경 사항을 더 빨리 적용하는 것이 좋을 수 있습니다.

브라우저의 캐시 시간 초과를 60초에서 10초로 줄이면 부하가 엄청나게 늘어나지만, NGINX의 캐시 시간 초과를 60초에서 10초로 늘리면 부하가 아주 약간만 늘어납니다. 요청 하나당 원본 서버에 분당 5개의 요청이 추가되는 반면 원격 클라이언트의 경우 사이트에서 유사한 작업이 활성화된 클라이언트 수에 따라 달라집니다.

따라서 원본 서버가 말하는 논리와 의도를 무시할 수 있습니다. NGINX에서 특정 헤더를 마스크 처리하거나 무시하도록 지정할 수 있습니다. X-Accel-Expires , Cache-Control 또는 Expires . NGINX 구성에서 proxy_cache_valid 지침을 사용하여 기본 캐시 시간을 제공할 수 있습니다.

36:18 캐시 / 캐시 안 함

때로는 원본 서버에서 캐시 가능하다고 하는 콘텐츠를 캐시하지 않을 수도 있고, NGINX에 저장된 콘텐츠 버전을 우회해야 할 수도 있습니다. proxy_cache_bypass 및 proxy_no_cache 지시문은 그 정도의 제어를 제공합니다.

이를 사용하면 HTTP 인증이나 요청 매개변수와 같이 특정 요청 헤더 집합이 설정되어 있거나 요청 매개변수가 있는 경우 캐시를 우회하여 NGINX에서 캐시를 자동으로 업데이트하거나 캐시를 완전히 건너뛰고 항상 원본 서버에서 검색하도록 할 수 있습니다.

일반적으로 이러한 작업은 상당히 복잡한 캐싱 결정을 위해 수행되며, 쿠키와 인증 헤더의 값에 대한 세부적인 결정을 내려 캐시해야 할 내용, 원본 서버에서 항상 수신해야 할 내용, NGINX 캐시에 저장해서는 안 될 내용을 제어합니다.

37:25 다중 캐시

마지막으로, 매우 대규모 배포의 경우 몇 가지 이유로 개별 NGINX 인스턴스 내에서 여러 캐시를 살펴보고 싶을 수 있습니다. 사이트의 특성과 해당 사이트 성능의 중요도에 따라 NGINX 프록시의 각 테넌트에 대해 다른 캐시 정책을 가질 수 있습니다. 심지어 공유 호스팅 상황에서 각 테넌트가 가입한 특정 플랜에 따라서도 달라질 수 있습니다.

또는 NGINX 호스트에 여러 개의 디스크가 있는 경우 각 디스크에 개별 캐시를 배포하는 것이 가장 효율적입니다. 가장 중요한 규칙은 한 디스크에서 다른 디스크로 복사하는 횟수를 최소화하는 것이며, 이를 위해서는 각 디스크에 캐시를 고정하고 해당 캐시를 사용하는 각 프록시의 임시 파일을 올바른 디스크에 고정하면 됩니다.

표준 작업은 NGINX가 업스트림 프록시에서 콘텐츠를 수신하면 콘텐츠가 충분히 작고 메모리에 맞지 않는 한 해당 콘텐츠를 디스크로 스트리밍한다는 것입니다. 그런 다음 해당 콘텐츠가 디스크로 스트리밍되면 캐시로 이동됩니다. 캐시의 임시 파일 위치(임시 파일이 저장된 디스크)가 캐시가 저장된 디스크와 동일한 경우 해당 작업은 엄청나게 더 효율적입니다.

39:07 간단한 리뷰 – 캐시를 사용하는 이유는 무엇입니까?

캐싱에 대해 이야기했고, NGINX에서 사용하는 방법, NGINX 내부에서 구현된 부분, 그리고 이를 조정하는 방법에 대해서도 이야기했습니다. 마무리가 다가오면서, 처음에 콘텐츠를 캐시하려는 이유를 다시 한번 상기시켜주는 간단한 검토를 진행해 보겠습니다. NGINX는 전 세계적으로 1억 1,400만 개의 웹사이트에 배포되었으며, 이러한 사용자 중 다수는 웹 가속 및 콘텐츠 캐싱 기능 때문에 NGINX를 배포합니다. [ 편집자 - 이 통계는 2014년 5월에 웨비나가 제공되었을 때 적용되었습니다 .]

39:44 페이지 속도가 왜 중요한가요?

이러한 기능은 웹사이트 속도를 개선하고 최종 사용자에게 더 높은 수준의 경험을 제공합니다. 웹 페이지 속도는 정말 중요합니다. 수년간 분석가들은 사용자 행동을 모니터링하고 "N초 규칙"이라고 알려진 것을 만들어냈습니다. 이는 평균적인 사용자가 페이지가 로드되고 렌더링되는 것을 기다리는 데 걸리는 시간으로, 이 시간이 지나면 지루해지고 참을성이 없어져 다른 웹사이트나 경쟁업체 웹사이트로 이동하게 됩니다.

표준이 향상되고 사용자의 기대치가 점점 더 높아지면서, 사용자가 기다릴 준비가 되어 있는 기간은 점점 줄어들고 있습니다. 약간 모호한 수학적 계산을 통해 이를 추론해 보면 2016년경에는 사용자의 인내심이 부정적인 수준으로 떨어질 것이라는 결론이 나올 수 있습니다.

40:46 구글이 규칙을 바꾸었다

하지만 실제로는 기술이 우리를 따라잡았습니다. Google은 몇 년 전 Google Instant Search를 출시하면서 이를 시각적으로 보여주었습니다. 이제 Google에서는 검색창에 검색어를 입력하면 입력을 끝내기도 전에 후보 검색 결과가 제시됩니다. 이는 현대 인터넷에 대한 기대치가 엄청나게 바뀌었다는 것을 보여줍니다. Google에서 말했듯이 "사용자는 이제 웹 페이지가 책의 페이지를 넘기는 것과 같은 방식으로 반응하기를 기대합니다." 즉, 빠르고 원활하고 유연하게 반응하기를 기대합니다.

41:28 성과가 좋지 않을 때의 비용

해당 수준의 성과를 달성하지 못하면 웹사이트나 웹 서비스에 지정하는 KPI에 상당한 영향이 미칠 수 있습니다. 광고 클릭률이든: Google 자체에서도 검색 페이지가 로딩되는 데 0.5초 더 걸리자 광고 클릭률이 20% 떨어지는 것을 발견했습니다. 수익에 관한 것일 수도 있습니다. 느린 웹 페이지의 영향을 조사하고자 Amazon은 의도적으로 100ms의 배수로 페이지 로드를 늘렸고, 영향을 받은 고객의 수익은 일반적으로 100ms가 증가할 때마다 1%씩 감소하는 것을 발견했습니다.

다른 많은 분석가, 웹사이트 및 조사자는 페이지 방문 시간, 이탈률 등 웹사이트 지표에 비슷한 영향을 미친다고 보고했습니다. 최근 들어 Google에서는 검색 결과에서 페이지 순위를 계산할 때 페이지 속도를 적용하기 시작했습니다. 중요한 것은 첫 번째 바이트를 얻는 데 걸리는 시간인 듯합니다. 페이지 로드의 첫 번째 바이트를 가져오는 데 걸리는 시간이 길어질수록 페이지 순위가 더 크게 떨어집니다. 어떤 웹사이트는 Google 검색 결과의 3, 4, 5페이지에 나타나서 아무도 접근하지 못하는 상황에 처할 수 있습니다.

43:00 NGINX 캐싱을 사용하면

NGINX의 캐싱 기능을 사용하면 첫 번째 바이트까지 걸리는 시간을 줄이고 웹 콘텐츠를 더욱 빠르고 반응성 있게 만들어 최종 사용자 경험을 개선할 수 있습니다.

NGINX를 사용하면 웹 인프라를 통합하고 단순화할 수 있습니다. NGINX는 단순한 독립형 웹 캐시가 아닙니다. NGINX에는 웹 원본 서버가 포함되어 있으며 FastCGI와 같은 API에 대한 직접 게이트웨이가 포함되어 있으며 NGINX Plus에는 정교하고 기업에 적합한 부하 분산 장치와 애플리케이션 전송 컨트롤러를 구성하는 기능이 포함되어 있습니다. 이를 통해 웹 인프라의 여러 네트워크 구성 요소를 단일 구성 요소(NGINX 또는 NGINX Plus)로 통합하여 보다 안정적이고 디버깅이 쉽고 빠른 솔루션을 얻을 수 있습니다.

NGINX를 사용하면 업스트림 서버에서 반복적인 작업을 수행하여 서버 용량을 늘릴 수 있습니다. 실제로 캐시할 수 없는 것처럼 보이는 콘텐츠(예: 블로깅 사이트의 첫 페이지)의 경우에도 NGINX 프록시에서 잠깐만 캐시하는 데는 장점이 있습니다.

1초 안에 100명의 사용자가 동일한 콘텐츠를 요청하면 NGINX는 이를 원본 서버에 대한 단일 요청으로 줄이고 캐시에서 해당 사용자에게 콘텐츠를 다시 제공하며, 콘텐츠가 1초 이상 최신이 아니라는 것을 보장합니다. 이는 블로그 사이트나 이와 유사한 웹사이트에는 충분한 경우가 많지만 성능에 엄청난 차이를 가져옵니다. 이는 업스트림 서버의 부하와 충분한 용량을 관리하고 배포하는 데 드는 비용 측면에서 모두 그렇습니다.

마지막으로 NGINX의 전략적 용도 중 하나를 잊지 마세요. 프록시 캐시의 "사용 안 함" 기능을 통해 업스트림 서버 오류로부터 보호합니다. 속도가 느리거나 오류가 발생하거나 어떤 종류의 오류가 있는 경우 NGINX는 콘텐츠의 로컬 캐시 버전으로 폴백하여 업스트림 서버가 복구될 때까지 계속 사용할 수 있습니다.

45:21 마무리 생각

세계에서 가장 바쁜 웹사이트의 38%는 주로 웹 가속 및 콘텐츠 캐싱 기능을 위해 NGINX를 사용합니다. [ 편집자 - 이 통계는 2014년 5월에 웨비나가 제공되었을 때 적용되었습니다. 현재 값은 여기에서 확인하세요. ] 더 많은 솔루션과 자세한 내용은 nginx.com 의 블로그와 기능 간략 설명서를 확인하세요. 여기에서는 NGINX 및 NGINX Plus의 기능에 대해 설명합니다. 그리고 우리의 웨비나 목록을 확인해보세요. 앞으로 진행될 웨비나뿐만 아니라 이 시리즈의 지난 이벤트에서 곧 추가될 웨비나도 있습니다.

이러한 기능에 대해 더 자세히 알아보고 싶다면 물론 nginx.org 와 nginx.com 에서 설명서와 솔루션을 찾을 수 있지만, 직접 다운로드하여 사용해 보는 것보다 더 좋은 방법은 없습니다. 오픈소스 제품은 nginx.org 에서 찾을 수 있으며, 추가적인 부하 분산, 애플리케이션 전송, 관리 및 사용 편의성 기능이 포함된 상용 지원 제품은 nginx.com 에서 찾을 수 있습니다.

여러분, 여러분의 시간과 관심에 감사드립니다. NGINX의 콘텐츠 캐싱에 대한 이 프레젠테이션과 런스루밍이 여러분 중 많은 분께 유용하고 유익한 정보가 되었기를 바랍니다.

질문과답변

질문을 살펴보고 어떤지 살펴보겠습니다.

47:20 바이트 범위 요청

바이트 범위 요청에 대한 질문이 있습니다. 바이트 범위 요청은 클라이언트가 콘텐츠를 요청하지만 해당 콘텐츠의 하위 집합만 필요한 경우에 사용됩니다. 비디오 파일이고 클라이언트가 비디오의 일부만 필요로 한다고 가정해 보겠습니다. 또는 매우 일반적으로 PDF 파일입니다. 사용자는 PDF 파일의 인덱스가 있는 헤더를 읽었고, 클라이언트는 단지 특정 페이지 세트만 다운로드하려고 합니다. NGINX의 콘텐츠 캐시에서 그게 어떻게 작동하나요?

과정은 다음과 같습니다. NGINX가 리소스에 대한 바이트 범위 요청을 받고 전체 리소스가 이미 캐시에 있는 경우, NGINX는 클라이언트가 요청한 바이트 범위로 캐시에서 응답합니다. 해당 리소스가 캐시에 없으면 NGINX는 전체 리소스에 대한 요청을 업스트림 서버에 보내고 해당 리소스를 캐시에 저장합니다. 현재 시점에서 NGINX는 바이트 범위 요청을 따르지 않고 전체 리소스를 클라이언트로 반환합니다. 대부분의 상황에서는 그게 허용되는 행동이에요.

예를 들어, 클라이언트가 PDF 문서를 다운로드하는 경우 첫 번째 요청은 어차피 전체 문서에 대한 것이고 해당 문서가 스트리밍되는 경우에만 클라이언트가 연결을 중단하고 바이트 범위 요청을 시작합니다. 따라서 캐시된 콘텐츠의 경우 NGINX는 바이트 범위 요청을 존중합니다. 캐시되지 않은 콘텐츠의 경우 NGINX는 업스트림 서버에서 전체 콘텐츠를 검색하여 해당 인스턴스에서 전체 콘텐츠를 클라이언트로 다시 반환합니다.

49:13 프록시 캐시 재검증

이것은 프록시 캐시 재검증 기능에 대한 질문입니다. 이 기능을 통해 NGINX는 업스트림 서버에 조건부 GET 요청을 보내 콘텐츠가 변경되었는지 확인할 수 있습니다. 질문은 다음과 같습니다.

프록시 캐시 재검증에는 ETag 가 고려되나요, 아니면 콘텐츠의 If-Modified-Since 날짜만 고려되나요?

답은 콘텐츠의 If-Modified-Since 날짜만 확인하고, 실무적으로는 응답에 항상 If-Modified-Since를 포함하고 ETag 를 선택 사항으로 처리하는 것이 좋습니다. 왜냐하면 응답에서 처리할 "마지막 수정" 날짜만큼 일관되거나 널리 처리되지 않기 때문입니다.

50:07 동일한 디스크에 캐시 분산

NGINX가 최상의 성능을 위해 단일 사이트의 캐싱 부하를 여러 개의 동일한 디스크로 분산하는 것이 가능할까요?

네, 그렇습니다. 약간의 노력이 필요합니다. 일반적인 시나리오는 RAID 없이 여러 디스크를 배포한 다음, 각 디스크에 고정된 개별 캐시를 배포하는 것입니다. 트래픽의 추가 구성 및 분할이 필요합니다. 이를 구성하는 데 도움이 필요하면 커뮤니티에 문의하면 해당 커뮤니티에서 귀하의 특정 요청을 처리해 드리고, NGINX Plus를 사용하는 경우 지원 팀에 문의하면 기꺼이 도와드리겠습니다.

50:50 다양한 헤더

NGINX는 캐시 적중 및 미스에 Vary 헤더를 고려합니까?

아니요, NGINX는 Vary 헤더를 자동으로 처리하지 않습니다. 이것이 문제라면 Vary 헤더를 프록시 캐시 키에 추가하면 간단히 응답을 저장하는 데 사용되는 고유 키에 Vary 헤더의 값이 포함됩니다. 그러면 여러 개의 다른 버전을 저장할 수 있습니다.

51:25 캐싱 프리미티브

모든 캐싱 기본 요소와 지침이 준수되고 있습니까?

전반적으로는 그렇습니다. Vary 헤더와 같이 존중되지 않는 몇 가지 예외 사례가 있습니다. 많은 경우, 다양한 캐시가 RFC의 요구 사항을 해석하는 방식에는 어느 정도 여유가 있습니다. 가능한 한, 우리는 안정적이고, 일관되며, 구성하기 쉬운 구현을 선택했습니다.

51:52 업스트림 헤더 및 데이터

업스트림 헤더와 데이터가 모두 캐시되고 있나요?

네, 그렇습니다. 캐시에서 응답을 받으면 헤더와 응답 본문도 캐시됩니다.

52:13 *‑헤더 인코딩

헤더 값은 응답 본문과 마찬가지로 캐시되므로... NGINX가 Transfer-Encoding 의 다양한 조합으로 올바르게 작동하지 않는다면 꽤 놀라울 것입니다. Accept-Encoding은 종종 Vary 헤더를 통해 구현되므로 캐시 키에 Vary 헤더를 넣어야 한다는 앞서 설명한 내용이 여기에도 적용됩니다(이를 지원하지 않는 클라이언트의 경우).

52:56 SPDY

SPDY에서 캐싱이 작동하나요?

전적으로. NGINX의 프런트엔드 프록시라고 생각할 수도 있지만 실제로는 NGINX 커널과 매우 깊이 얽혀 있습니다. 네, SPDY는 캐싱에 적합합니다.

53:15 Vary 헤더, 라운드 2

Vary 헤더에 대한 또 다른 질문은 다음과 같습니다. 확인을 위해 Vary 헤더 응답과 gzip을 사용하고 있다면 Trac 이나 커뮤니티 사이트 에서 해당 솔루션에 대한 토론 내용을 살펴보세요. 가장 일반적인 방법은 캐시 키에 Vary 헤더를 포함하는 것입니다.

53:45 페이지 속도

질문: PageSpeed는 NGINX 캐싱을 사용하나요, 아니면 자체 캐싱 메커니즘을 사용하나요?

이는 PageSpeed 개발자 와 공유해야 할 질문입니다.

54:00 기타 캐시

질문: 다른 콘텐츠 캐시는 NGINX와 어떻게 비교되나요?

CDN은 매우 효과적인 콘텐츠 캐싱 솔루션입니다. CDN은 서비스 형태로 배포되므로 콘텐츠가 캐시되는 방식과 해당 콘텐츠가 만료되는 방식에 대한 제어는 제한적이지만, 콘텐츠를 최종 사용자에게 더 가깝게 제공하는 매우 효과적인 도구입니다. NGINX는 웹 애플리케이션을 가속화하는 데 매우 효과적인 도구이며, 둘은 함께 배포되는 경우가 매우 많습니다. Varnish와 같은 독립형 캐시의 경우 다시 한번 말씀드리자면, 이 캐시는 여러 면에서 NGINX와 비슷한 방식으로 작동하는 매우 유능한 기술입니다. NGINX의 이점 중 하나는 원본 서비스 제공 애플리케이션 게이트웨이, 캐싱, 부하 분산을 하나의 솔루션으로 통합한다는 것입니다. 따라서 배포, 관리, 디버깅이 더 쉽고 문제가 있을 경우 진단하기 쉬운 더 간단하고 통합된 인프라를 얻을 수 있습니다.

이 게시물의 기반이 되는 웨비나를 시청하려면 여기 를 클릭하세요.

NGINX Plus를 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 사용 사례에 대해 논의해 보세요.