Cloudflare ra mắt tính năng Cache Response Rules: Kiểm soát bộ nhớ đệm linh hoạt hơn

Hôm nay, chúng tôi rất vui mừng được công bố Cache Response Rules. Đây là một loại quy tắc mới được thực thi sau khi máy chủ gốc (origin server) phản hồi nhưng trước khi Cloudflare lưu nội dung vào bộ nhớ đệm (cache).

Nếu bạn từng cảm thấy khó chịu khi thấy một nội dung lẽ ra phải được lưu cache dễ dàng lại bị kéo ngược về máy chủ gốc chỉ vì một tiêu đề Set-Cookie thừa thãi hoặc Cache-Control sai lệch – những tiêu đề đôi khi rất khó hoặc không thể xóa bỏ hay thay đổi ngay tại máy chủ gốc – thì Cache Response Rules chính là giải pháp khắc phục, được áp dụng đúng vào thời điểm cần thiết.

Khi nào và làm thế nào để đưa ra các quyết định lưu cache

Bộ nhớ đệm CDN và máy chủ gốc hoạt động như một cặp đôi. Mục tiêu của chúng là phản hồi từ cache bất cứ khi nào có thể và chỉ quay lại máy chủ gốc khi phía biên (edge) không thể phản hồi. Mỗi điểm tăng trong tỷ lệ cache hit (cache hit ratio) đều đến từ việc phân chia công việc này một cách chính xác. Nếu kiểm tra cache khi không nên, chúng ta lãng phí một lượt tra cứu vốn dĩ sẽ không có kết quả. Nếu kiểm tra quá ít, máy chủ gốc sẽ phải phục vụ lưu lượng mà lẽ ra phía biên đã xử lý, khiến lợi ích về hiệu năng bị mất đi.

Quan trọng là, máy chủ gốc đóng vai trò dẫn dắt bộ nhớ đệm. Khi nó trả về một tài nguyên có thể lưu cache, các tiêu đề phản hồi (response headers) của nó sẽ cho Cloudflare biết thời gian lưu trữ hợp lệ, thời điểm và cách thức xác thực lại (revalidate), thậm chí là có nên lưu cache hay không. Bộ nhớ đệm chỉ đạt hiệu quả tối đa khi máy chủ gốc cho phép. Nếu máy chủ gốc cấu hình sai, bộ nhớ đệm chỉ mang tính hình thức trong khi chi phí hạ tầng máy chủ gốc lại tăng vọt.

Hầu hết các vấn đề về khả năng lưu cache không được quyết định tại thời điểm yêu cầu (request time). Chúng chỉ bộc lộ sau khi máy chủ gốc phản hồi.

Một khách truy cập yêu cầu tệp /static/app.js. Cloudflare kiểm tra cache, không thấy (miss), và chuyển tiếp yêu cầu đến máy chủ gốc. Máy chủ gốc trả về tệp tin. Đâu đó trong các tiêu đề phản hồi, một cách âm thầm, xuất hiện tiêu đề Set-Cookie. Tài nguyên lẽ ra phải được lưu cache tại mọi trung tâm dữ liệu của Cloudflare giờ đây lại không thể lưu cache được nữa. Hãy nhân con số đó với mỗi khách truy cập, trên mỗi trang web, với cùng một tiêu đề vô tình xuất hiện, và bạn sẽ có một tỷ lệ cache hit bị rò rỉ băng thông máy chủ gốc, làm hỏng hiệu năng và đẩy chi phí hạ tầng lên cao.

Có một danh sách dài các biến thể của cùng vấn đề này. Máy chủ gốc gửi Cache-Control: no-cache cho các tài nguyên hoàn toàn an toàn để lưu trên CDN. Máy chủ gốc gửi các chỉ thị đúng, nhưng chúng lại dành cho trình duyệt chứ không phải cho Cloudflare. Hoặc máy chủ gốc đính kèm một ETag (định danh cho một phiên bản cụ thể của tài nguyên) quá khắt khe, gây ra tình trạng xác thực lại liên tục (revalidation thrash) trên mỗi yêu cầu có điều kiện. Thông thường, đặc biệt là ở các đội ngũ lớn, những người quản lý phản hồi của máy chủ gốc và nhóm quản lý CDN là những người khác nhau. Điều này khiến việc thay đổi một dòng tiêu đề trở thành một cuộc đàm phán kéo dài hàng tuần.

Không vấn đề nào trong số này có thể được giải quyết tại thời điểm yêu cầu. Vào thời điểm Cloudflare nhìn thấy Set-Cookie trên /app.js, giai đoạn yêu cầu đã kết thúc. Phản hồi đã được gửi đi.

Vì vậy, chúng tôi đặt giải pháp vào đúng vị trí.

Cache Response Rules chạy sau khi phản hồi của máy chủ gốc đến Cloudflare, nhưng trước khi nó được ghi vào cache. Với các quy tắc này, bạn có thể viết lại các chỉ thị Cache-Control, quản lý cache-tags và xóa bỏ các tiêu đề như Set-Cookie, ETag và Last-Modified khỏi phản hồi của máy chủ gốc trước khi bộ nhớ đệm của Cloudflare nhìn thấy chúng. Giải pháp này nằm hoàn toàn trên Cloudflare. Không cần thay đổi mã nguồn máy chủ gốc.

Mảnh ghép còn thiếu

Nếu bạn đã sử dụng Cloudflare một thời gian, bạn đã chứng kiến sự phát triển của bề mặt điều khiển cache. Vài năm trước, hầu hết các cấu hình này nằm trong Page Rules, hoạt động như một nguyên mẫu đơn lẻ nhưng quá tải, kết hợp giữa lưu cache với chuyển hướng, bảo mật và hàng tá hành vi khác, tất cả đều được đánh giá tại thời điểm yêu cầu. Sau đó, chúng tôi tách các quy tắc này ra để chỉ những thay đổi hành vi liên quan mới được đánh giá đối với các yêu cầu, giúp giảm độ trễ không cần thiết và cho phép xếp chồng các quy tắc phức tạp giữa các hành vi. Cache Rules trở thành một loại quy tắc chuyên biệt, giàu tính biểu đạt cho các quyết định lưu cache, cùng với CDN-Cache-Control, Origin Cache Control, khóa cache tùy chỉnh (custom cache keys) và các quyền kiểm soát khác giúp bạn có những cách chính xác để thông báo cho Cloudflare nội dung nào an toàn để lưu cache, trong bao lâu và dưới điều kiện nào.

Nhiều quyền kiểm soát trong số này có chung một đặc điểm: chúng hoạt động trên yêu cầu (request).

Mặc dù có vẻ không trực quan, nhưng điều này lại hợp lý. Các quyết định lưu cache quan trọng nhất mà Cloudflare phải thực hiện là: chúng ta có nên tra cứu nội dung này trong cache không, và dưới khóa (key) nào? Câu hỏi này phải được trả lời trước khi Cloudflare giao tiếp với máy chủ gốc. Nếu câu trả lời là "không" trong khi lẽ ra phải là "có", thì yêu cầu đã phải trả giá cho một vòng lặp đến máy chủ gốc và không có gì ở giai đoạn phản hồi có thể lấy lại độ trễ đó. Các quy tắc tại thời điểm yêu cầu trả lời câu hỏi đó bằng cách sử dụng thông tin duy nhất có sẵn tại thời điểm đó: URL, phần mở rộng tệp yêu cầu, tiêu đề yêu cầu, địa lý, loại thiết bị, v.v. Sử dụng các tham số yêu cầu này và các quy tắc được thiết lập để thay đổi chúng, chúng tôi xác định liệu một nội dung có khả năng nằm trong cache hay không và tìm kiếm ở đó trước khi liên lạc với máy chủ gốc.

Nhưng một số quyết định lưu cache không thể thực hiện tại thời điểm yêu cầu. Các chỉ thị Cache-Control của máy chủ gốc (cache-control: max-age=3600) là một phần của phản hồi mà Cloudflare nhận được từ máy chủ gốc. Mã trạng thái, ETag, dấu thời gian Last-Modified, Set-Cookie và định dạng cache-tag mà máy chủ gốc chọn đều là những thứ nằm trong phản hồi mà máy chủ gốc chuyển cho bộ nhớ đệm. Không có thông tin nào trong số đó khả dụng khi các quy tắc tại thời điểm yêu cầu được thực thi.

Phản hồi từ máy chủ gốc là nguồn sự thật duy nhất, vì vậy nếu có thứ gì đó cần thay đổi trên Cloudflare mà không khả dụng tại thời điểm yêu cầu, trước đây bạn chỉ có ba giải pháp thay thế:

Mỗi giải pháp đó đều tiêu tốn thời gian kỹ thuật, làm tăng độ trễ hoặc lãng phí tiền bạc. Cache Response Rules mang đến cho bạn lựa chọn thứ tư: một bộ quy tắc nơi bạn có thể sửa đổi phản hồi của máy chủ gốc trước khi nó chạm tới bộ nhớ đệm của Cloudflare.

Hai giai đoạn, hai câu hỏi

Cách rõ ràng nhất để hiểu sự khác biệt giữa Cache Rules và Cache Response Rules mới là coi chúng như hai giai đoạn, mỗi giai đoạn trả lời câu hỏi riêng của mình.

Giai đoạn phản hồi không thể làm mọi thứ mà giai đoạn yêu cầu có thể làm. Nó không thể thay đổi "cái gì" (what), vì khóa (key) đã được cố định. Mặc dù nó có thể thay đổi việc Cloudflare có lưu cache hay không và lưu như thế nào, ví dụ: một quy tắc phản hồi có thể đặt no-store để làm cho một đối tượng có thể lưu cache trở thành không thể lưu, hoặc xóa Set-Cookie để làm cho nội dung không thể lưu cache trở nên đủ điều kiện lưu. Tuy nhiên, Cache Response Rules không thể làm cho một yêu cầu vốn không đủ điều kiện trở nên có thể lưu cache ở giai đoạn phản hồi, vì đã quá muộn.

Vì vậy, Cache Response Rules không thay thế Cache Rules. Cache Rules quyết định liệu chúng ta có lưu cache hay không, lưu cái gì và lưu như thế nào tại thời điểm yêu cầu. Cache Response Rules đưa ra quyết định cuối cùng về cách thức và việc có lưu hay không, một khi phản hồi của máy chủ gốc được Cloudflare nhìn thấy trong một giai đoạn chưa từng tồn tại trước đây.

Những gì bạn có thể làm

Cache Response Rules hiện hỗ trợ ba hành động.

Hành động set_cache_settings loại bỏ các thành phần như Set-Cookie, ETag hoặc Last-Modified khỏi phản hồi của máy chủ gốc trước khi Cloudflare đánh giá nó để lưu cache:

Đây là giải pháp cho vấn đề Set-Cookie trên một tài nguyên tĩnh. Các framework máy chủ gốc thường đính kèm cookie phiên vào mọi phản hồi (để cân bằng tải hoặc các mục đích khác), bao gồm cả phản hồi cho các tài nguyên mà người dùng không muốn liên kết với một phiên làm việc. Việc xóa bỏ Set-Cookie trong giai đoạn phản hồi giúp các tài nguyên đó có thể lưu cache trở lại mà không cần yêu cầu máy chủ gốc, bộ cân bằng tải hay bất kỳ thành phần thượng nguồn nào phải thay đổi bất cứ điều gì.

Cache Response Rules cũng chạy trên các phản hồi vốn không đủ điều kiện lưu cache. Vì vậy, khi bạn xóa Set-Cookie khỏi một phản hồi động, chẳng hạn, quy tắc vẫn kích hoạt bất kể đối tượng đó có được lưu trữ hay không. Điều này cho phép bạn kiểm soát những gì khách hàng nhìn thấy ngay cả khi phản hồi không được lưu trong cache. Bạn cũng có thể xóa ETag và Last-Modified, điều này hữu ích khi các tiêu đề đó bị cấu hình sai tại máy chủ gốc và gây ra tình trạng xác thực lại liên tục. Việc này đi kèm với một sự đánh đổi: xóa cả ETag và Last-Modified sẽ kích hoạt Smart Edge Revalidation cho phản hồi đó. Nếu Cache Response Rules sau đó thêm các trình xác thực mới, Cloudflare sẽ không kích hoạt Smart Edge Revalidation cho các yêu cầu có điều kiện của trình duyệt.

Vì vậy, việc xóa và sửa đổi tiêu đề, ngay cả trên các yêu cầu động, là một mô hình mới mạnh mẽ chưa từng tồn tại trước đây trên Cloudflare, nhưng có thể có các cấu hình bổ sung cần lưu ý nếu bạn thực hiện những thay đổi này.

set_cache_tags cho phép bạn thêm, xóa hoặc thiết lập các thẻ cache (cache tags) được sử dụng để xóa theo thẻ (purge by tag) trên phản hồi. Các thẻ có thể là tĩnh:

Hoặc được tính toán từ một biểu thức tiêu đề phản hồi:

Dạng thứ hai là dạng phát huy tác dụng trong quá trình chuyển đổi CDN. Nếu CDN trước đây của bạn đính kèm các khóa thay thế (surrogate keys) vào phản hồi bằng cách sử dụng tiêu đề như Surrogate-Keys với dấu phẩy phân cách, bạn có thể chuyển đổi chúng sang định dạng Cache-Tag của Cloudflare trực tiếp trong giai đoạn phản hồi.

Đối số thứ ba của split là giới hạn: số lượng phần tử tối đa trong mảng kết quả có thể từ 1 đến 128. Hãy sử dụng một giá trị lớn hơn một cách thoải mái so với số lượng thẻ thực tế trên mỗi phản hồi. Giá trị 1 sẽ trả về toàn bộ tiêu đề như một thẻ duy nhất. Một khi các thẻ tồn tại trên phản hồi, tính năng purge-by-tag sẽ hoạt động ngay lập tức (và khi nói "hoạt động", chúng tôi thường có nghĩa là trong dưới 150 ms trên toàn cầu).

set_cache_control là hành động thực hiện phần việc nặng nhọc nhất. Bạn có thể thiết lập hoặc xóa các chỉ thị riêng lẻ:

Đối với mỗi chỉ thị, bạn cũng có thể đặt cloudflare_only: true, đây là phần thường gây ngạc nhiên cho người dùng:

Khi cloudflare_only là true, chỉ thị sẽ ảnh hưởng đến cách Cloudflare lưu cache phản hồi, nhưng giá trị Cache-Control hạ nguồn gửi đến trình duyệt vẫn được giữ nguyên. Đây là phiên bản giai đoạn phản hồi của những gì CDN-Cache-Control mang lại cho bạn tại máy chủ gốc: lưu cache tài nguyên trong 24 giờ tại Cloudflare, nhưng thông báo cho trình duyệt một giá trị khác. Sự khác biệt là giờ đây bạn thực hiện việc đó từ giao diện Rules trong bảng điều khiển Cloudflare, thay vì yêu cầu máy chủ gốc thiết lập một tiêu đề riêng biệt.

Những ví dụ đáng tham khảo

Dưới đây là một số ví dụ mà chúng tôi nghĩ có thể giúp bạn thấy được sức mạnh của Cache Response Rules. Hãy thử nghiệm, tùy biến chúng và chia sẻ với cộng đồng để thấy cách đạt được các tùy chỉnh cache mạnh mẽ bằng cách kết hợp Cache Rules với Cache Response Rules. Nhiều ví dụ hơn có thể được tìm thấy trong tài liệu.

Xóa Set-Cookie khỏi các phần mở rộng tài nguyên tĩnh

Tại sao nó hiệu quả: Nguyên nhân phổ biến nhất khiến "nội dung này lẽ ra phải lưu cache được nhưng lại không" là do một middleware phiên làm việc trên máy chủ gốc đính kèm Set-Cookie vào mọi phản hồi. Việc xóa nó đối với các phần mở rộng tĩnh đã biết sẽ chuyển đổi các phản hồi đó thành có thể lưu cache mà không cần bất kỳ thay đổi nào từ máy chủ gốc.