캐싱 동작 방식

아티클
03/22/2024

이 문서에서는 일반적인 캐싱 개념과 Azure Content Delivery Network에서 캐싱을 사용하여 성능을 향상시키는 방법을 간략하게 설명합니다. 콘텐츠 배달 네트워크 엔드포인트에서 캐싱 동작을 사용자 지정하는 방법에 대해 알아보려면 캐싱 규칙을 사용하여 Azure Content Delivery Network 캐싱 동작 제어 및 쿼리 문자열을 사용하여 Azure Content Delivery Network 캐싱 동작 제어를 참조하세요.

캐싱에 대한 소개

캐싱은 데이터에 대한 향후 요청에 신속하게 액세스할 수 있도록 데이터를 로컬에 저장하는 프로세스입니다. 가장 일반적인 캐싱 유형인 웹 브라우저 캐싱의 경우 웹 브라우저는 로컬 하드 드라이브에 정적 데이터의 복사본을 로컬로 저장합니다. 캐싱을 사용함으로써, 웹 브라우저는 서버에 여러 번 왕복하는 대신 로컬에서 동일한 데이터를 액세스할 수 있기 때문에 시간과 리소스를 절약할 수 있습니다. 캐싱은 정적 이미지, CSS 파일 및 JavaScript 파일과 같은 작고 정적인 데이터를 로컬에서 관리하는 데 적합합니다.

마찬가지로, 캐싱은 원본 서버로 다시 돌아가는 요청을 피하여 최종 사용자 대기 시간을 줄이기 위해서 사용자와 가까운 에지 서버의 콘텐츠 배달 네트워크에서 사용됩니다. 단일 사용자에 대해서만 사용되는 웹 브라우저 캐시와 달리 콘텐츠 배달 네트워크에는 공유 캐시가 있습니다. 콘텐츠 배달 네트워크 공유 캐시에서 사용자의 파일 요청을 다른 사용자가 사용할 수 있으므로 원본 서버에 대한 요청 수가 크게 줄어듭니다.

자주 변경되거나 개별 사용자의 고유한 동적 리소스는 캐시할 수 없습니다. 그러나 이러한 유형의 리소스는 성능 향상을 위해 Azure 콘텐츠 배달 네트워크에서 DSA(동적 사이트 가속) 최적화를 활용할 수 있습니다.

캐싱은 원본 서버와 최종 사용자 사이에 여러 수준에서 발생할 수 있습니다.

웹 서버: 공유 캐시(여러 사용자용)를 사용합니다.
콘텐츠 배달 네트워크: 공유 캐시(여러 사용자용)를 사용합니다.
ISP(인터넷 서비스 공급자): 공유 캐시(여러 사용자용)를 사용합니다.
웹 브라우저: 프라이빗 캐시(단일 사용자용)를 사용합니다.

각 캐시는 일반적으로 자체 리소스의 최신 여부를 관리하고 파일이 오래되면 유효성 검사를 수행합니다. 이러한 동작은 RFC 7234 HTTP 캐싱 사양에 정의되어 있습니다.

리소스 최신 여부

캐시된 리소스는 원본 서버의 해당 리소스에 비해 오래되거나 유효하지 않을 가능성이 있기 때문에 콘텐츠를 새로 고칠 시기를 제어하는 것은 어느 캐싱 메커니즘에나 중요합니다. 시간 및 대역폭 소비를 절약하기 위해 액세스할 때마다 캐시된 리소스를 원본 서버의 버전과 비교하는 작업이 진행되지는 않습니다. 대신, 캐시된 리소스가 최신으로 간주되는 한, 최신 버전으로서 클라이언트로 직접 전송됩니다. 캐시된 리소스는 해당 기간이 캐시 설정에 정의된 기간보다 짧으면 최신으로 간주됩니다. 예를 들어 브라우저가 웹 페이지를 다시 로드할 때는 하드 드라이브에 있는 각각의 캐시된 리소스가 최신 상태인지 확인하고 로드합니다. 리소스가 최신이 아니면(유효하지 않으면) 최신 복사본이 서버에서 로드됩니다.

유효성 검사

리소스가 부실한 것으로 간주되는 경우 원본 서버는 캐시의 데이터가 원본 서버의 데이터와 여전히 일치하는지 확인하도록 유효성을 검사하라는 요청을 받습니다. 파일이 원본 서버에서 수정되었으면 캐시는 리소스의 버전을 업데이트합니다. 그렇지 않고 리소스가 최신이면 캐시의 데이터가 유효성 검사를 거치지 않고 바로 전송됩니다.

콘텐츠 배달 네트워크 캐싱

캐싱은 콘텐츠 배달 네트워크가 작동하여 배달 속도를 높이고 이미지, 글꼴 및 비디오와 같은 정적 자산의 원본 부하를 줄이는 데 필수적입니다. 콘텐츠 배달 네트워크 캐싱에서 정적 리소스는 사용자에게 더 로컬인 전략적으로 배치된 서버에 선택적으로 저장되며 다음과 같은 이점을 제공합니다.

대부분의 웹 트래픽은 정적(예: 이미지, 글꼴 및 비디오)이므로 콘텐츠 배달 네트워크 캐싱은 콘텐츠를 사용자에게 더 가깝게 이동하여 네트워크 대기 시간을 줄여 데이터가 이동하는 거리를 줄입니다.
콘텐츠 배달 네트워크에 작업을 오프로드하면 캐싱을 통해 네트워크 트래픽과 원본 서버의 부하를 줄일 수 있습니다. 이렇게 하면 사용자 수가 많은 경우에도 애플리케이션의 리소스 요구 사항과 비용을 줄일 수 있습니다.

웹 브라우저에서 캐싱을 구현하는 방법과 마찬가지로 캐시 지시문 헤더를 전송하여 콘텐츠 배달 네트워크에서 캐싱이 수행되는 방식을 제어할 수 있습니다. 캐시 지시문 헤더는 HTTP 헤더이며 일반적으로 원본 서버에서 추가됩니다. 이러한 헤더의 대부분은 원래 클라이언트 브라우저에서 캐싱을 처리하도록 설계되었지만 이제는 콘텐츠 배달 네트워크와 같은 모든 중간 캐시에서도 사용됩니다.

Cache-Control 및 Expires라는 두 가지 헤더를 사용하여 캐시의 최신 여부를 정의할 수 있습니다. Cache-Control이 더 최신이고, 둘 다 있는 경우 Expires보다 우선합니다. 유효성 검사에 사용되는 두 가지 유형의 헤더(유효성 검사기라고 함)는 ETag 및 Last-Modified입니다. ETag가 더 최신이고, 둘 다 정의된 경우 Last-Modified보다 우선합니다.

캐시 지시문 헤더

Important

기본적으로 DSA에 최적화된 Azure Content Delivery Network 엔드포인트는 캐시 지시문 헤더를 무시하고 캐싱을 무시합니다. Edgio 프로필의 Azure CDN Standard의 경우 콘텐츠 배달 네트워크 캐싱 규칙을 사용하여 Azure Content Delivery Network 엔드포인트에서 이러한 헤더를 처리하는 방법을 조정할 수 있습니다. Edgio의 Azure CDN 프리미엄 프로필에 대해서만 규칙 엔진을 사용하여 캐싱을 사용하도록 설정합니다.

Azure Content Delivery Network는 캐시 기간 및 캐시 공유를 정의하는 다음 HTTP 캐시 지시문 헤더를 지원합니다.

Cache-Control:

웹 게시자에게 콘텐츠에 대한 제어 권한을 더 많이 부여하고 Expires 헤더의 제한 사항을 해결하기 위해 HTTP 1.1에 도입되었습니다.
Expires 헤더와 Cache-Control이 모두 정의 된 경우 전자의 헤더를 대체합니다.
클라이언트에서 콘텐츠 배달 네트워크 POP Cache-Control 로의 HTTP 요청에 사용되는 경우 기본적으로 모든 Azure Content Delivery Network 프로필에서 무시됩니다.
원본 서버에서 콘텐츠 배달 네트워크 POP로의 HTTP 응답에서 사용되는 경우:
- Edgio의 Azure CDN 표준/프리미엄 및 Microsoft의 Azure CDN 표준은 모든 Cache-Control 지시문을 지원합니다.
- Edgio의 Azure CDN 표준/프리미엄 및 Microsoft의 Azure CDN 표준은 RFC 7234 - HTTP(Hypertext Transfer Protocol/1.1): 캐싱(ietf.org)의 Cache-Control 지시문에 대한 캐싱 동작을 준수합니다.

만료:

HTTP 1.0에 도입된 레거시 헤더 이전 버전과의 호환성을 지원합니다.
초 단위 정밀도로 날짜 기반 만료 시간을 사용합니다.
Cache-Control: max-age와 비슷합니다.
Cache-Control이 없을 때 사용됩니다.

Pragma:

기본적으로 Azure Content Delivery Network에서는 적용되지 않습니다.
HTTP 1.0에 도입된 레거시 헤더 이전 버전과의 호환성을 지원합니다.
no-cache 지시문과 함께 클라이언트 요청 헤더로 사용됩니다. 이 지시문은 새로운 버전의 리소스를 제공하도록 서버에 지시합니다.
Pragma: no-cache는 Cache-Control: no-cache와 같습니다.

유효성 검사기

캐시가 유효하지 않으면 HTTP 캐시 유효성 검사기를 사용하여 캐시된 버전의 파일을 원본 서버의 버전과 비교합니다. Edgio의 Azure CDN 표준/프리미엄은 기본적으로 ETag 및 Last-Modified 검사기를 모두 지원하는 반면, Microsoft의 Azure CDN Standard는 Last-Modified만 지원합니다.

ETag:

Edgio의 Azure CDN 표준/프리미엄은 기본적으로 ETag를 지원하지만 Microsoft의 Azure CDN Standard는 지원하지 않습니다.
ETag 모든 파일 및 파일 버전에 대해 고유한 문자열을 정의합니다. 예: ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
HTTP 1.1에서 도입되었으며 Last-Modified보다 최신입니다. 마지막 수정 날짜를 확인하기 어려운 경우에 유용합니다.
강력한 유효성 검사와 약한 유효성 검사를 모두 지원합니다. 그러나 Azure Content Delivery Network는 강력한 유효성 검사만 지원합니다. 강력한 유효성 검사의 경우 두 리소스 표현이 바이트 단위로 동일해야 합니다.
캐시는 요청에 하나 이상의 ETag 유효성 검사기가 있는 If-None-Match 헤더를 전송하여 ETag를 사용하는 파일의 유효성을 검사합니다. 예들 들어 If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f"입니다. 서버 버전이 목록의 유효성 검사기와 일치하는 ETag 경우 응답에서 상태 코드 304(수정되지 않음)를 보냅니다. 버전이 다른 경우 서버는 상태 코드 200(정상)과 업데이트된 리소스로 응답합니다.

마지막 수정:

Edgio의 Azure CDN 표준/프리미엄에 대해서만 ETag가 HTTP 응답의 일부가 아닌 경우 Last-Modified가 사용됩니다.
리소스가 마지막으로 수정된 것으로 원본 서버에서 확인된 날짜와 시간을 지정합니다. 예: Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
캐시는 요청에 날짜와 시간이 있는 If-Modified-Since 헤더를 보내어 Last-Modified를 사용하여 파일의 유효성을 검사합니다. 원본 서버는 해당 날짜를 최신 리소스의 Last-Modified 헤더와 비교합니다. 리소스가 지정된 시간 이후로 수정되지 않은 경우 서버는 응답에 상태 코드 304(수정되지 않음)를 반환합니다. 리소스가 수정된 경우에는 서버가 상태 코드 200(정상)과 업데이트된 리소스를 반환합니다.

캐시할 수 있는 파일 결정

모든 리소스를 캐시할 수 있는 것은 아닙니다. 다음 테이블은 HTTP 응답 유형을 기반으로 어떤 리소스를 캐시할 수 있는지 보여줍니다. 이러한 조건을 모두 충족하지 않는 HTTP 응답과 함께 전송되는 리소스는 캐시할 수 없습니다. Edgio의 Azure CDN 프리미엄에 대해서만 규칙 엔진을 사용하여 이러한 조건 중 일부를 사용자 지정할 수 있습니다.

	Microsoft의 Azure Content Delivery Network	Edgio의 Azure Content Delivery Network
HTTP 상태 코드	200, 203, 206, 300, 301, 410, 416	200
HTTP 메서드	GET, HEAD	GET
파일 크기 제한	300GB	300GB

Microsoft의 Azure CDN 표준 캐싱이 리소스에 작동하려면 원본 서버가 모든 HEAD 및 GET HTTP 요청을 지원해야 하고, content-length 값이 자산에 대한 모든 HEAD 및 GET HTTP 응답에 대해 동일해야 합니다. HEAD 요청의 경우, 원본 서버는 HEAD 요청을 지원해야 하고, GET 요청을 수신한 경우처럼 동일한 헤더로 응답해야 합니다.

기본 캐싱 동작

다음 표에서는 Azure Content Delivery Network 제품 및 해당 최적화에 대한 기본 캐싱 동작을 설명합니다.

	Microsoft: 일반 웹 배달	Edgio: 일반 웹 배달	에지오: DSA
원본 사용	예	네	아니요
콘텐츠 배달 네트워크 캐시 기간	2일	7일	없음

원본 사용: 지원되는 캐시 지시문 헤더가 원본 서버의 HTTP 응답에 존재하는 경우 사용할지 여부를 지정합니다.

CDN 캐시 기간: 리소스가 Azure 콘텐츠 배달 네트워크에 캐시되는 시간을 지정합니다. 그러나 Honor 원본 이 예이고 원본 서버의 HTTP 응답에 캐시 지시문 헤더 Expires 가 포함되거나 Cache-Control: max-ageAzure Content Delivery Network에서 헤더에 지정된 기간 값을 대신 사용합니다.

참고 항목

Azure Content Delivery Network는 개체가 캐시에 저장되는 최소 시간을 보장하지 않습니다. 콘텐츠가 자주 요청되는 콘텐츠를 위한 공간을 확보하기 위해 자주 요청되지 않는 경우 캐시된 콘텐츠는 콘텐츠 배달 네트워크 캐시에서 만료되기 전에 제거될 수 있습니다.

다음 단계

캐싱 규칙을 통해 콘텐츠 배달 네트워크에서 기본 캐싱 동작을 사용자 지정하고 재정의하는 방법을 알아보려면 캐싱 규칙을 사용하여 Azure Content Delivery Network 캐싱 동작 제어를 참조하세요.
쿼리 문자열을 사용하여 캐싱 동작을 제어하는 방법을 알아보려면 쿼리 문자열을 사용하여 Azure Content Delivery Network 캐싱 동작 제어를 참조 하세요.