1년 전 Cloudflare에서 캐시 설정을 사용자 지정하는 새로운 방법인 캐시 규칙을 도입했습니다. 캐시 규칙은 사용자가 콘텐츠를 캐시하는 방식에 더 큰 유연성을 제공하므로 정밀한 제어, 사용자 친화적인 API, 원활한 Terraform 통합이 가능합니다. 2022년 9월 말 출시 이후 10만 개 이상의 웹 사이트에서 캐시 규칙을 사용하여 캐시 설정을 미세 조정했습니다.
오늘, 다른 여러 Rules 제품과 함께 Cache 규칙이 일반 공개 버전(GA)으로 제공된다는 소식을 알려드리게 되어 기쁩니다. 하지만 그 뿐만 아니라, Cloudflare에서 캐시하는 방법을 사용자 정의할 수 있는 더 많은 옵션을 제공하는 새로운 캐시 규칙 구성 옵션도 도입됩니다. 여기에는 Cache Reserve에 대하여 자격이 되는 리소스, 원본 서버에서 데이터를 수신할 때 준수해야 하는 제한 시간 초과 값, 콘텐츠를 캐시할 때 사용할 사용자 지정 포트, 캐시 제어 헤더가 없는 경우 Cloudflare의 캐시를 우회할지 여부 등을 정의하는 기능이 포함됩니다.
캐시 규칙에서는 사용자가 코드를 작성할 필요 없이 거의 모든 사용 사례에 맞게 콘텐츠 전송 전략을 조정할 수 있는 완전한 제어 기능 능력과 기능이 제공합니다. 캐시 규칙이 GA로 전환됨에 따라 고객이 완벽한 캐시 전략을 얼마나 빨리 달성할 수 있을지 정말 기대됩니다.
Cloudflare에서의 캐시 사용자 지정 역사
Cloudflare에서 캐시사용자 정의의 여정은 10년 전 회사 설립 초기부터 시작되었습니다. 초기부터 고객들이 가장 자주 하는 요청 중 하나는 구성을 단순화하는 것이었습니다. 고객은 웹 사이트의 모든 페이지에 대해 정확한 캐시 정책을 쉽게 구현하고, 강력한 보안 조치를 적용하며, 헤더를 조작하고, 리디렉션을 설정하는 등의 작업을 수행하기를 원했습니다. 이러한 제어를 설정하는 데 Cloudflare를 사용하는 것은 응답에 헤더나 정책을 추가하는 복잡한 구성 옵션만 제공하는 원본 서버를 사용하는 고객에게 특히 중요했으며, 이는 나중에 CDN에서 다운스트림에 적용할 수 있었습니다.
이러한 수요에 부응하여 저희는 Page Rules 제품을 출시했으며, 이 제품은 이후 인기와 기능 모두에서 괄목할 만한 성장세를 보였습니다. Page Rules는 Cloudflare에서 콘텐츠를 캐시하는 방식을 세밀하게 제어하려는 고객들이 선호하는 선택이 되었습니다. 현재 5백만 개 이상의 캐시 관련 Page Rules가 활성화되어 있어 웹 사이트의 콘텐츠 전송 전략 수립에 도움이 되고 있습니다.
하지만 그 이면에는 Page Rules 확장성 문제가 있었습니다.
Cloudflare에서 Page Rule을 만날 때마다 고객의 모든 규칙 조건을 단일 정규식 패턴으로 변환해야 합니다. 그런 다음 이 패턴을 웹 사이트 요청에 적용하여 원하는 캐시 구성을 달성합니다. 모든 고객의 모든 정규식을 전 세계 300여 개의 데이터 센터에 걸쳐 초당 수천만 건의 요청과 비교하는 방법을 생각해 보면 Page Rules를 적용하려면 필요한 계산량이 엄청날 것임을 쉽게 짐작할 수 있습니다. 이러한 압박은 사용자에게 제공할 수 있는 규칙의 수와 직결됩니다. 예를 들어 Page Rules는 지정된 웹 사이트에 125개의 규칙만 배포할 수 있습니다.
이 문제를 해결하기 위해 저희는 새로운 Rulesets Engine에서 모든 Page Rule 기능을 재구축했습니다. 규칙 집합 엔진 기반 제품은 사용자에게 더 많은 규칙을 제공할 뿐만 아니라 이러한 규칙을 언제 실행해야 하는지에 대한 유연성을 제공합니다. 규칙 집합 엔진의 마법 중 하나는 페이지의 모든 규칙을 하나의 정규식으로 결합하는 대신 조건에 따라 규칙 로직을 평가할 수 있다는 것입니다. 예를 들어 하위 도메인 A와 B에 서로 다른 캐싱 정책이 있는 경우 하위 도메인 A의 요청은 A에만 적용되는 정규식 로직을 사용하여 평가할 수 있습니다(B에 적용되는 로직은 생략). 이렇게 하면 성능에 의미 있는 이점을 얻을 수 있으며, Cloudflare 네트워크 전체에 걸쳐 Page Rules를 적용하는 데 필요한 계산 요구 사항을 줄일 수 있습니다.
지난 1년 동안 Cache Rules는 Origin Rules, Configuration Rules, Single Redirect Rules과 함께 베타 버전으로 제공되었습니다. 얼리 어답터들의 소중한 지원 덕분에 제품을 성공적으로 미세 조정하여 베타에서 정식 버전으로 전환할 수 있는 단계에 이르렀습니다. 이제 이들 제품은 Page Rules가 할 수 있는 모든 것 이상을 수행할 수 있습니다. 이는 또한 Page Rules에 대한 EOL 프로세스의 시작을 의미합니다. 앞으로 몇 달 안에 고객이 Page Rules를 특정 Rules 제품으로 교체하는 방법에 관한 일정과 정보를 발표할 예정입니다. 이 과정을 최대한 자동화하고 모든 사용자가 Page Rules로부터 원활하게 전환할 수 있도록 간단한 단계를 제공하겠습니다.
Cache Rules 사용 방법 및 새로운 기능
Cache Rules를 사용해 보신 분들은 Cache Rules가 직관적이며 다른 규칙 집합 엔진 제품과 유사하게 작동한다는 것을 아실 것입니다. URL 또는 요청 헤더와 같은 사용자 정의 기준이 평가되고 지정된 값과 일치하는 경우 Cloudflare 캐싱 구성이 준수됩니다. 각 Cache Rule은 필드, 연산자, 값에 따라 다릅니다. 사용 가능한 모든 다른 옵션에 대해서는 Cache Rules 설명서를 참조하세요.
다음은 캐시를 사용자 지정하기 위해 다양한 전략을 배포하는 방법의 두 가지 예입니다. 이 예시는 Cache Rules로 가능한 것의 빙산의 일각에 불과하므로 직접 사용해보고 의견을 알려주세요.
예시: 캐시된 콘텐츠는 일정한 주기로 업데이트됩니다
예를 들어 Acme Corp에서 캐싱 전략을 업데이트하려고 한다고 가정해 보겠습니다. 특정 요청 헤더를 활용하도록 캐시를 사용자 정의하고 해당 요청 헤더의 존재를 다른 캐시 규칙을 적용할 시기를 결정하는 기준으로 사용하려고 합니다. 가장 먼저 결정해야 할 것은 특정 규칙을 트리거하기 위해 어떤 정보를 사용해야 하는가 하는 것입니다. 이는 표현식에 정의되어 있습니다.
트리거 기준이 정의되면 Acme Corp에서는 다음으로 캐시를 사용자 지정할 방법을 결정해야 합니다.
빠르게 변화하는 콘텐츠
가장 일반적인 캐시 전략은 에지 캐시 TTL을 업데이트하는 것입니다. Acme에서 웹 사이트의 특정 콘텐츠가 빠르게 변경될 수 있다고 생각하는 경우, Cloudflare가 캐시에서 제공할 수 있는 리소스를 고려해야 하는 시간을 더 짧게 변경할 수 있습니다. 이렇게 하면 Cloudflare가 원본으로 더 자주 돌아가 콘텐츠를 재검증하고 업데이트할 수 있습니다. 또한 에지 캐시 TTL 섹션에서는 Cloudflare가 원본 서버에서 반환하는 상태 코드에 따라 리소스의 TTL을 정의하고, Acme의 원본 서버에서 캐시 제어 명령이 전송되지 않은 경우 Cloudflare가 무엇을 캐시해야 하는지도 정의할 수 있습니다.
느리게 변화하는 콘텐츠
반면, 파비콘이나 로고처럼 자주 변경되지 않는 콘텐츠가 많고 이 콘텐츠를 원본이 아닌 Cloudflare의 캐시에서 제공하는 것을 선호하는 경우, Acme Corp에서는 새로운 Cache Rule을 사용하여 어떤 콘텐츠가 Cache Reserve 대상인지 정의할 수 있습니다. Cache Reserve는 자산을 Cloudflare의 캐시에 장기간 영구적으로 저장하여 송신 수수료를 절감합니다.
기존에는 사용자가 Cache Reserve를 활성화하면 전체 영역이 Cache Reserve에 기록될 수 있었습니다. 웹 사이트의 모든 리소스에 대한 원본 송신 수수료를 절약하려는 고객에게는 여전히 이 방법이 가장 좋은 방법입니다. 그러나 Cache Reserve에 어떤 자산을 포함해야 하는지 또는 어떤 자산의 크기가 적격해야 하는지를 정확하게 제어하려는 고객의 경우 Cache Reserve 적격성 규칙은 추가 노브를 제공하므로 고객이 맞춤형 방식으로 캐시 히트를 정확하게 늘리고 원본 송신 수수료를 줄일 수 있습니다. 이 규칙을 사용하려면 Cache Reserve 구독이 필요함을 유의하세요.
예시: 원본이 느림
가상의 예를 들어 보겠습니다. 최근 Acme Corp에서는 Cloudflare 로그에서 오류가 증가하는 것을 확인했습니다. 이러한 오류는 Acme에서 독점 데이터를 기반으로 사용자에게 제공하는 새로운 보고서와 관련이 있습니다. 이 보고서를 작성하려면 원본에서 여러 데이터베이스에 액세스하여 몇 가지 계산을 수행하고 이러한 계산을 기반으로 보고서를 생성해야 합니다. 이 보고서를 생성하는 원본은 이 모든 백그라운드 작업이 완료될 때까지 응답을 기다려야 합니다. Acme의 보고서는 성공적이었고, 이를 보고 싶어 하는 방문자들의 트래픽이 폭주했습니다. 하지만 그 원본에서는 따라잡는 데 어려움을 겪고 있습니다. 이들이 보고 있는 오류의 대부분은 524로, 이는 제한 시간 초과가 발생하기 전에 Cloudflare에서 원본 응답을 확인하지 못하는 것과 관련이 있습니다.
Acme에서는 원본 인프라를 확장하여 이를 개선하려는 계획이 있지만, 이를 배포하는 데 시간이 오래 걸리고 있습니다. 그 동안 Cache Rules로 전환하여 제한 시간 초과를 더 길게 구성할 수 있습니다. 이전에는 Cloudflare와 두 개의 연속적인 원본 읽기 사이의 제한 시간 초과 값이 100초였으므로 원본이 100초 이상 지속되는 기간 동안 응답을 성공적으로 보내지 못하면 524 오류가 발생할 수 있었습니다. Cache Rule을 사용하여 이 제한 시간 초과를 연장함으로써 Acme Corp에서 Cloudflare의 캐시에 더 많이 의존할 수 있습니다.
위의 캐시 전략은 원본에서 리소스가 변경되는 빈도와 원본의 성능에 중점을 둡니다. 그러나 다른 전략을 가능하게 하는 수많은 다른 규칙이 있습니다. 사용자 지정 캐시 키를 사용하면 고객이 강력한 ETag를 준수하여 Cloudflare에서 캐시를 정의하는 방법을 결정할 수 있으며, 이를 통해 고객이 특정 캐시된 자산의 유효성을 재확인해야 하는 시기를 결정할 수 있습니다. 또한 사용자 지정 포트를 사용하면 고객이 콘텐츠에 대한 캐싱 결정을 내릴 때 Cloudflare에서 사용해야 하는 비표준 포트를 정의할 수 있습니다.
Cache Rules의 전체 목록은 여기에서 확인할 수 있습니다.
지금 바로 Cache Rules를 사용해 보세요!
Cloudflare의 캐시를 사용하는 모든 사용자가 강력하고 쉽게 제어할 수 있는 추가 규칙을 지속해서 구축하고 출시할 예정입니다. 추가 Cache Rules에 대한 기능 요청이 있는 경우 Cloudflare 커뮤니티에 알려주세요.
대시보드로 이동하여 Cache Rules를 지금 바로 사용해 보세요!