Azure Front Door를 사용한 캐싱

Important

Azure Front Door(클래식)는 2027년 3월 31일에 사용이 중지됩니다. 서비스가 중단되지 않도록 하려면 2027년 3월까지 Azure Front Door(클래식) 프로필을 Azure Front Door 표준 또는 프리미엄 계층으로 마이그레이션하는 것이 중요합니다. 자세한 내용은 Azure Front Door(클래식) 사용 중지를 참조하세요.

Azure Front Door는 동적 사이트 가속 및 부하 분산 기능이 있는 최신 CDN(콘텐츠 배달 네트워크)입니다. 경로에 캐싱이 구성된 경우 각 요청을 수신하는 에지 사이트는 캐시에서 유효한 응답을 확인합니다. 캐싱을 사용하면 원본 서버로 전송되는 트래픽의 양을 줄이는 데 도움이 됩니다. 캐싱된 응답이 없으면 요청이 원본으로 전달됩니다.

각 Front Door 에지 사이트는 자체 캐시를 관리하며 요청은 다른 에지 사이트에서 제공될 수 있습니다. 따라서 캐시된 응답을 제공한 경우에도 일부 트래픽이 원본에 도달하는 것을 볼 수 있습니다.

캐싱은 대기 시간을 크게 줄이고 원본 서버의 부하를 줄일 수 있습니다. 그러나 모든 유형의 트래픽이 캐싱의 이점을 얻을 수 있는 것은 아닙니다. 이미지, CSS 및 JavaScript 파일과 같은 정적 자산은 캐싱에 적합합니다. 인증된 API 엔드포인트와 같은 동적 자산은 개인 정보 유출을 방지하기 위해 캐시해서는 안 됩니다. 정적 및 동적 자산에 대해 별도의 경로를 사용하는 것이 좋습니다. 동적 자산에 대해서는 캐싱이 사용하지 않도록 설정됩니다.

Warning

캐싱을 사용하도록 설정하기 전에 공개 설명서를 철저히 검토하고 캐싱을 사용하도록 설정하기 전에 가능한 모든 시나리오를 테스트합니다. 앞에서 설명한 것처럼 잘못된 구성을 사용하면 여러 사용자가 공유할 수 있는 사용자별 데이터를 실수로 캐시하여 개인 정보 인시던트가 발생할 수 있습니다.

요청 메서드

GET 요청 메서드를 사용하는 요청만 캐시할 수 있습니다. 다른 모든 요청 메서드는 항상 네트워크를 통해 프록시됩니다.

대용량 파일 전달

Azure Front Door는 파일 크기의 제한 없이 대용량 파일을 전달합니다. 캐싱을 사용하도록 설정한 경우 Front Door는 개체 청크라는 기술을 사용합니다. 대용량 파일이 요청되면 Front Door가 원본에서 파일의 더 작은 파일 조각을 검색합니다. Front Door가 전체 파일 요청 또는 바이트 범위 파일 요청을 받으면 Front Door 환경은 원본에서 8MB 청크의 파일을 요청합니다.

청크가 Azure Front Door 환경에 도착하면 캐시되고 사용자에게 즉시 제공됩니다. 그런 다음, Front Door가 다음 청크를 동시에 프리페치합니다. 이 프리페치를 사용하면 콘텐츠가 사용자보다 먼저 하나의 청크로 유지되도록 하여 대기 시간을 줄일 수 있습니다. 이 프로세스는 전체 파일을 다운로드(요청된 경우)하거나, 클라이언트에서 연결을 닫을 때까지 계속됩니다. 바이트 범위 요청에 대한 자세한 내용은 RFC 7233을 읽어보세요.

Front Door는 수신되는 모든 청크를 캐시하므로 전체 파일을 Front Door 캐시에 캐시할 필요가 없습니다. 파일 또는 바이트 범위에 대한 후속 요청은 캐시에서 처리됩니다. 청크가 모두 캐시되지 않은 경우 프리페치를 사용하여 원본에서 청크를 요청합니다.

이 최적화는 바이트 범위 요청을 지원하는 원본의 기능을 사용합니다. 원본이 바이트 범위 요청을 지원하지 않거나 범위 요청을 올바르게 처리하지 않는 경우 이 최적화가 효과적이지 않습니다.

원본이 Range 헤더를 사용하여 요청에 응답하는 경우 다음 방법 중 하나로 응답해야 합니다.

• 범위가 지정한 응답을 반환합니다. 응답은 HTTP 상태 코드 206을 사용해야 합니다. 또한 Content-Range 응답 헤더가 있어야 하며 원본이 반환하는 콘텐츠의 실제 길이와 일치해야 합니다. 원본에서 유효한 값의 올바른 응답 헤더를 보내지 않는 경우 Azure Front Door는 응답을 캐시하지 않으며 일관되지 않은 동작이 표시될 수 있습니다.

  팁

  원본이 응답을 압축하는 경우 Content-Range 헤더 값이 압축된 응답의 실제 길이와 일치하는지 확인합니다.

• 범위가 지정되지 않은 응답을 반환합니다. 원본이 범위 요청을 처리할 수 없는 경우 Range 헤더를 무시하고 범위가 지정되지 않은 응답을 반환할 수 있습니다. 원본이 206 이외의 응답 상태 코드를 반환하는지 확인합니다. 예를 들어 원본은 200 OK 응답을 반환할 수 있습니다.

원본에서 CTE(청크 분할 전송 인코딩)를 사용하여 데이터를 Azure Front Door POP로 보내는 경우 8MB보다 큰 응답 크기는 지원되지 않습니다.

파일 압축

Azure Front Door에서 파일을 압축하여 성능 향상을 참조하세요.

Azure Front Door(클래식)는 에지에서 콘텐츠를 동적으로 압축할 수 있으므로 클라이언트에 대한 응답 시간이 더 작고 빨라집니다. 파일을 압축할 수 있으려면 캐싱을 사용해야 하며 파일이 압축에 적합한 MIME 형식이어야 합니다. 현재 Front Door(클래식)에서는 이 목록을 변경할 수 없습니다. 현재 목록:

• "application/eot"
• "application/font"
• "application/font-sfnt"
• "application/javascript"
• "application/json"
• "application/opentype"
• "application/otf"
• "application/pkcs7-mime"
• "application/truetype"
• "application/ttf",
• "application/vnd.ms-fontobject"
• "application/xhtml+xml"
• "application/xml"
• "application/xml+rss"
• "application/x-font-opentype"
• "application/x-font-truetype"
• "application/x-font-ttf"
• "application/x-httpd-cgi"
• "application/x-mpegurl"
• "application/x-opentype"
• "application/x-otf"
• "application/x-perl"
• "application/x-ttf"
• "application/x-javascript"
• "font/eot"
• "font/ttf"
• "font/otf"
• "font/opentype"
• "image/svg+xml"
• "text/css"
• "text/csv"
• "text/html"
• "text/javascript"
• "text/js", "text/plain"
• "text/richtext"
• "text/tab-separated-values"
• "text/xml"
• "text/x-script"
• "text/x-component"
• "text/x-java-source"

또한 파일의 크기는 1KB 이상 8MB 이하여야 합니다.

이러한 프로필은 다음과 같은 압축 인코딩을 지원합니다.

• Gzip(GNU zip)
• Brotli

요청이 gzip 및 Brotli 압축을 지원하는 경우 Brotli 압축이 우선적으로 적용됩니다.

자산 요청이 압축을 지정하고 요청 결과 캐시 누락이 발생하면 Azure Front Door(클래식)는 POP 서버에서 직접 자산을 압축합니다. 이후 압축된 파일은 캐시에서 제공됩니다. 결과 항목은 Transfer-Encoding: chunked 응답 헤더와 함께 반환됩니다.

원본에서 CTE(청크 분할 전송 인코딩)를 사용하여 데이터를 Azure Front Door POP로 보내는 경우 압축이 지원되지 않습니다.

참고 항목

범위 요청은 다른 크기로 압축될 수 있습니다. Azure Front Door에서는 모든 GET HTTP 요청에 대해 콘텐츠 길이 값이 동일해야 합니다. 클라이언트가 다른 콘텐츠 길이로 응답하도록 하는 Accept-Encoding 헤더가 있는 바이트 범위 요청을 보내는 경우 Azure Front Door는 503 오류를 반환합니다. 원본에서 압축을 사용하지 않도록 설정하거나 규칙 엔진 규칙을 만들어 바이트 범위 요청의 요청에서 Accept-Encoding 헤더를 제거할 수 있습니다.

쿼리 문자열 동작

Azure Front Door를 사용하면 쿼리 문자열이 포함된 웹 요청에 대해 파일이 캐시되는 방식을 제어할 수 있습니다.

쿼리 문자열이 있는 웹 요청에서 쿼리 문자열은 물음표(?) 다음에 나오는 요청 부분입니다(?). 쿼리 문자열은 필드 이름 및 해당 값이 등호(=)로 구분된 하나 이상의 키-값 쌍을 포함할 수 있습니다(=). 각 키-값 쌍은 앰퍼샌드(&)로 구분됩니다.

예를 들어 URL http://www.contoso.com/content.mov?field1=value1&field2=value2에는 두 개의 쿼리 문자열이 포함됩니다.

• value1 값을 가진 field1입니다.
• value2 값을 가진 field2입니다.

요청의 쿼리 문자열에 키-값 쌍이 둘 이상인 경우 해당 순서는 중요하지 않습니다.

캐싱을 구성할 때 캐시에서 쿼리 문자열을 처리하는 방법을 지정합니다. 지원되는 동작은 다음과 같습니다.

• 쿼리 문자열 무시: 이 모드에서는 Azure Front Door가 첫 번째 요청에서 클라이언트의 쿼리 문자열을 원본으로 전달하고 자산을 캐시합니다. Front Door 환경에서 제공되는 자산의 모든 후속 요청은 캐시된 자산이 만료될 때까지 쿼리 문자열을 무시합니다.

• 쿼리 문자열 사용: 이 모드에서는 쿼리 문자열을 포함하여 고유한 URL이 있는 각 요청이 고유 캐시가 있는 고유 자산으로 처리됩니다. 예를 들어 www.example.ashx?q=test1 요청에 대한 원본에서의 응답이 Front Door 환경에서 캐시되고, 쿼리 문자열이 이와 동일한 후속 캐시에 대해 반환됩니다. www.example.ashx?q=test2에 대한 요청은 자체 TTL(Time To Live) 설정과 함께 별도의 자산으로 캐시됩니다.

  쿼리 문자열 매개 변수의 순서는 중요하지 않습니다. 예를 들어 Azure Front Door 환경에 URL www.example.ashx?q=test1&r=test2의 캐시된 응답이 포함된 경우 www.example.ashx?r=test2&q=test1에 대한 요청도 캐시에서 제공됩니다.

• 지정된 쿼리 문자열 무시 및 지정된 쿼리 문자열 포함: 이 모드에서는 캐시 키가 생성될 때 지정된 매개 변수를 포함하거나 제외하도록 Azure Front Door를 구성할 수 있습니다.

  예를 들어 기본 캐시 키가 /foo/image/asset.html이고 URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200에 대한 요청이 이루어진다고 가정합니다. userid 쿼리 문자열 매개 변수를 제외하는 규칙 엔진 규칙이 있는 경우 쿼리 문자열 캐시 키는 /foo/image/asset.html?language=EN&sessionid=200입니다.

Front Door 경로에서 쿼리 문자열 동작을 구성합니다.

캐시 제거

캐시 제거를 구성하는 방법은 Azure Front Door의 캐시 제거를 참조하세요.

Azure Front Door는 자산의 TTL(Time-to-Live)이 만료될 때까지 자산을 캐시합니다. 클라이언트가 만료된 TTL을 사용하여 자산을 요청할 때마다 Front Door 환경에서는 요청을 처리하기 위해 자산의 업데이트된 새 복사본이 있는지 검색한 후 새로 고친 캐시를 저장합니다.

사용자가 항상 자산의 최신 복사본을 받도록 보장하는 가장 좋은 방법은 각 업데이트에 대해 자산 버전 관리를 수행하여 자산을 새 URL로 게시하는 것입니다. Front Door는 다음 클라이언트 요청에 대한 새 자산을 즉시 검색합니다. 경우에 따라 모든 가장자리 노드에서 캐시된 콘텐츠를 제거하고 이러한 콘텐츠가 모두 새로 업데이트된 자산을 검색하도록 강제하려 할 수 있습니다. 웹 애플리케이션에 대한 업데이트 또는 잘못된 정보가 포함된 신속한 업데이트 자산 때문일 수 있습니다.

에지 노드에서 제거하고자 하는 자산을 선택합니다. 모든 자산을 삭제하려면 모두 제거를 선택합니다. 아니면 제거하고 싶은 각 자산의 경로를 경로에 입력합니다.

삭제할 경로 목록에서 지원되는 형식은 다음과 같습니다.

• 단일 경로 제거: /pictures/strasbourg.png와 같은 파일 확장명을 사용하여 자산의 전체 경로(프로토콜 및 도메인 제외)를 지정하여 개별 자산을 제거합니다.
• 와일드 카드 제거: 별표(*)를 와일드 카드로 사용할 수 있습니다. 경로에 /*가 포함된 엔드포인트의 모든 폴더, 하위 폴더, 파일을 제거하거나 폴더를 지정하고 맨 뒤에 /*를 붙여(예: /pictures/*) 특정 폴더의 모든 하위 폴더와 파일을 제거합니다.
• 루트 도메인 제거: 경로에 "/"가 포함된 엔드포인트의 루트를 제거합니다.

참고 항목

와일드카드 도메인 제거: 이 섹션에서 설명한 대로 제거를 위해 캐시된 경로를 지정해도 Front Door에 연결된 와일드카드 도메인에는 적용되지 않습니다. 현재로서 와일드카드 도메인을 직접 제거하는 것은 지원되지 않습니다. 특정 하위 도메인과 제거 경로를 지정함으로써 특정 하위 도메인에서 경로를 제거할 수 있습니다. 예를 들어 내 Front Door에 *.contoso.com가 있는 경우, foo.contoso.com/path/*을 입력하여 내 하위 도메인 foo.contoso.com의 자산을 제거할 수 있습니다. 현재 제거 콘텐츠 경로에서 호스트 이름 지정은 해당하는 경우 와일드카드 도메인의 하위 도메인으로 제한됩니다.

Front Door의 캐시 제거에서는 대/소문자를 구분하지 않습니다. 또한 쿼리 문자열에 구애받지 않으므로 URL을 제거하면 URL의 모든 쿼리 문자열 변형이 제거됩니다.

캐시 만료

다음 순서의 헤더를 사용하여 항목이 캐시에 저장될 기간을 결정합니다.

1. Cache-Control: s-maxage=<seconds>
2. Cache-Control: max-age=<seconds>
3. Expires: <http-date>

일부 Cache-Control 응답 헤더 값은 응답을 캐시할 수 없음을 나타냅니다. 여기에는 private, no-cache, no-store와 같은 값이 포함됩니다. Front Door는 규칙 엔진을 사용하여 캐싱 동작을 재정의하는 경우에도 이러한 헤더 값을 적용하고 응답을 캐시하지 않습니다.

원본의 응답에 Cache-Control 헤더가 없는 경우 기본적으로 Front Door는 1일에서 3일 사이의 캐시 기간을 임의로 결정합니다.

참고 항목

캐시 만료는 366일을 초과할 수 없습니다.

Cache-Control 응답 헤더에 REVALIDATED_HIT가 표시될 수 있습니다. 이는 Azure Front Door의 캐시된 콘텐츠가 클라이언트에 제공되기 전에 원본 서버로 유효성을 다시 검사했음을 나타냅니다. 캐시된 콘텐츠가 만료되었지만 원본 서버는 콘텐츠가 변경되지 않았음을 나타내는 경우에 발생할 수 있습니다. 이 경우 캐시된 콘텐츠가 클라이언트에 제공되고 캐시 만료가 다시 설정됩니다.

요청 헤더

캐싱을 사용할 경우 다음 요청 헤더는 원본으로 전달되지 않습니다.

• Content-Length
• Transfer-Encoding
• Accept
• Accept-Charset
• Accept-Language

참고 항목

응답에 캐싱을 허용하는 Cache-Control 지시문이 포함되어 있지 않으면 권한 부여 헤더를 포함하는 요청은 캐시되지 않습니다. 다음 Cache-Control 지시문에는 유효성 재검사, public 및 s-maxage와 같은 효과가 있습니다.

응답 헤더

원본 응답을 캐시할 수 있는 경우 클라이언트에 응답을 보내기 전에 Set-Cookie 헤더가 제거됩니다. 원본 응답을 캐시할 수 없는 경우 Front Door는 헤더를 제거하지 않습니다. 예를 들어 원본 응답에 max-age 값이 있는 Cache-Control 헤더가 포함된 경우 이는 응답이 캐시 가능하고 Set-Cookie 헤더가 제거되었음을 Front Door에 나타냅니다.

또한 Front Door는 X-Cache 헤더를 모든 응답에 연결합니다. X-Cache 응답 헤더에는 다음 값 중 하나가 포함됩니다.

• TCP_HIT 또는 TCP_REMOTE_HIT: 응답의 처음 8MB 청크는 캐시 적중이며 콘텐츠는 Front Door 캐시에서 제공됩니다.
• TCP_MISS: 응답의 처음 8MB 청크는 캐시 누락이며 콘텐츠는 원본에서 가져옵니다.
• PRIVATE_NOSTORE: Cache-Control 응답 헤더가 private 또는 no-store로 설정되어 있으므로 요청을 캐시할 수 없습니다.
• CONFIG_NOCACHE: 요청이 Front Door 프로필에 캐시되지 않도록 구성되어 있습니다.

로그 및 보고서

액세스 로그에는 각 요청의 캐시 상태 포함됩니다. 또한 보고서는 애플리케이션에서 Azure Front Door의 캐시를 사용하는 방법에 대한 정보가 포함됩니다.

액세스 로그에는 각 요청의 캐시 상태 포함됩니다.

캐시 동작 및 기간

캐시 동작 및 기간은 규칙 엔진에서 구성할 수 있습니다. 규칙 엔진 캐싱 구성은 항상 경로 구성을 재정의합니다.

• 캐싱을 사용하지 않도록 설정하면 Azure Front Door는 원본 응답 지시문에 관계없이 응답 콘텐츠를 캐시하지 않습니다.

• 캐싱을 사용하도록 설정하면 캐시 동작은 규칙 엔진에서 적용되는 캐시 동작 값에 따라 달라집니다.

  • 원본 지킴: Azure Front Door는 항상 원본 응답 헤더 지시문을 따릅니다. 원본 지시문이 누락된 경우 Azure Front Door는 1~3일 동안 콘텐츠를 캐시합니다.
  • 항상 재정의: Azure Front Door는 항상 캐시 기간으로 재정의합니다. 즉, 원본 응답 지시문의 값을 무시하고 캐시 기간 동안 콘텐츠를 캐시합니다. 이 동작은 응답을 캐시할 수 있는 경우에만 적용됩니다.
  • 원본이 없는 경우 재정의: 원본이 캐싱 TTL 값을 반환하지 않는 경우 Azure Front Door는 지정된 캐시 기간을 사용합니다. 이 동작은 응답을 캐시할 수 있는 경우에만 적용됩니다.

참고 항목

• Azure Front Door는 콘텐츠가 캐시에 저장되는 시간을 보장하지 않습니다. 콘텐츠를 자주 사용하지 않는 경우 캐시된 콘텐츠는 콘텐츠 만료 전에 Edge 캐시에서 제거될 수 있습니다. Front Door는 캐시된 데이터가 만료된 경우에도 캐시에서 데이터를 제공할 수 있습니다. 이 동작은 원본이 오프라인일 때 사이트를 부분적으로 사용 가능한 상태로 유지하는 데 도움이 될 수 있습니다.
• 원본은 no-cache, private 또는 no-store 값과 함께 Cache-Control 헤더를 사용하여 특정 응답을 캐시하지 않도록 지정할 수 있습니다. 원본 서버에서 Azure Front Door POP로의 HTTP 응답에서 사용되는 경우 Azure Front Door는 캐시 제어 지시문을 지원하고 RFC 7234 - 하이퍼텍스트 전송 프로토콜(HTTP/1.1): 캐싱(ietf.org)의 Cache-Control 지시문에 대한 캐싱 동작을 적용합니다.

캐시 동작 및 기간은 Front Door 디자이너 라우팅 규칙과 규칙 엔진 모두에서 구성할 수 있습니다. 규칙 엔진 캐싱 구성은 항상 Front Door 디자이너 라우팅 규칙 구성을 재정의합니다.

• 캐싱을 사용하지 않도록 설정하면 Azure Front Door(클래식)는 원본 응답 지시문에 관계없이 응답 콘텐츠를 캐시하지 않습니다.

• 캐싱을 사용하도록 설정하면 캐시 기본 기간 사용 값에 따라 캐시 동작이 달라집니다.

  • 캐시 클래식 기간 사용이 예로 설정된 경우 Azure Front Door(클래식)는 항상 원본 응답 헤더 지시문을 따릅니다. 원본 지시문이 누락된 경우 Front Door는 1~3일 동안 콘텐츠를 캐시합니다.
  • 캐시 클래식 기간 사용이 아니요로 설정되면 Azure Front Door(클래식)는 항상 캐시 기간(필수 필드)으로 재정의됩니다. 즉, 원본 응답 지시문의 값을 무시하고 캐시 기간 동안 내용을 캐시합니다.

참고 항목

• Azure Front Door(클래식)는 콘텐츠가 캐시에 저장되는 시간을 보장하지 않습니다. 콘텐츠를 자주 사용하지 않는 경우 캐시된 콘텐츠는 콘텐츠 만료 전에 Edge 캐시에서 제거될 수 있습니다. Azure Front Door(클래식)는 캐시된 데이터가 만료된 경우에도 캐시에서 데이터를 제공할 수 있습니다. 이 동작은 원본이 오프라인일 때 사이트를 부분적으로 사용 가능한 상태로 유지하는 데 도움이 될 수 있습니다.
• Front Door 디자이너 라우팅 규칙에 설정된 캐시 기간은 최소 캐시 기간입니다. 원본의 캐시 제어 헤더가 재정의 값보다 큰 TTL을 사용하는 경우 이 재정의가 작동하지 않습니다.

다음 단계

• Azure Front Door(클래식)를 만드는 방법을 알아봅니다.
• Azure Front Door(클래식) 작동 방식에 대해 알아봅니다.

• 규칙 집합 일치 조건에 대해 자세히 알아보기
• 규칙 집합 작업에 대해 알아봅니다.