Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 21 — CDN — CloudFront, Cloud CDN, Cloudflare

Đã đọc 0/15 mục · còn khoảng 12 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa xây xong một website bán mỹ phẩm, server đặt tại một trung tâm dữ liệu ở Hà Nội. Một khách hàng ở TP.HCM mở trang, ảnh sản phẩm tải khá nhanh. Nhưng rồi shop của bạn viral, một KOL ở Singapore giới thiệu, và bỗng nhiên có hàng nghìn người từ Singapore, Bangkok, Manila truy cập cùng lúc. Mỗi request ảnh, CSS, JavaScript đều phải đi một quãng đường rất dài từ máy người dùng về tận Hà Nội rồi quay lại. Trang tải chậm, người dùng bỏ đi, server của bạn thì "khóc thét" vì phải phục vụ từng file tĩnh cho hàng nghìn người.

Đây chính xác là bài toán mà CDN — Content Delivery Network ra đời để giải quyết. CDN là một trong những "vũ khí" hiệu quả nhất, dễ triển khai nhất và rẻ nhất để tăng tốc website và ứng dụng. Với một kỹ sư DevOps hay Cloud, hiểu CDN không chỉ là biết bật một cái switch, mà là hiểu cơ chế cache, kiểm soát cache header, xử lý invalidation, bảo mật origin và tối ưu chi phí. Bài này sẽ giúp bạn nắm chắc cả tư duy lẫn kỹ thuật, với ba nhà cung cấp phổ biến nhất: Amazon CloudFront, Google Cloud CDN và Cloudflare.

Khái niệm cốt lõi

CDN là gì?

CDN là một mạng lưới các server đặt phân tán trên toàn cầu, có nhiệm vụ lưu bản sao (cache) nội dung của bạn ở những vị trí gần người dùng cuối. Thay vì mọi người trên thế giới đều phải kết nối về server gốc (gọi là origin) của bạn, họ sẽ được phục vụ từ server CDN gần nhất về mặt địa lý và mạng.

Các server phân tán này nằm tại những điểm gọi là POP — Point of Presence (điểm hiện diện), hay còn gọi là edge location (vị trí biên). Một nhà cung cấp lớn như Cloudflare có hơn 300 POP trên toàn cầu, CloudFront có hơn 600 điểm. Ở Việt Nam, Cloudflare và CloudFront đều có POP đặt tại Hà Nội và TP.HCM, nghĩa là người dùng Việt Nam thường được phục vụ ngay trong nước thay vì phải "chạy" sang Singapore.

Cơ chế hoạt động: cache tại edge

Hãy hình dung luồng cơ bản khi bật CDN cho một file ảnh banner.jpg:

  • Người dùng ở TP.HCM yêu cầu banner.jpg. Request đi tới POP gần nhất (giả sử POP tại TP.HCM).
  • POP kiểm tra: "Mình có sẵn banner.jpg trong cache không?" Lần đầu tiên thì chưa có — đây gọi là cache miss.
  • POP đi lấy file từ origin (server Hà Nội của bạn), phục vụ cho người dùng, đồng thời lưu một bản sao vào cache.
  • Người dùng thứ hai, thứ ba, thứ một nghìn ở TP.HCM yêu cầu cùng file đó. Bây giờ POP đã có sẵn — đây gọi là cache hit — và phục vụ ngay lập tức mà không cần hỏi origin nữa.
Kết quả: origin của bạn chỉ phải phục vụ file đó một lần cho mỗi POP, thay vì hàng nghìn lần. Độ trễ (latency) giảm mạnh vì dữ liệu đi quãng đường ngắn hơn nhiều.

Nội dung nào nên đưa lên CDN?

CDN cực kỳ mạnh với static asset — những nội dung không thay đổi theo từng người dùng:

  • Hình ảnh, video, font chữ
  • File CSS, JavaScript đã build
  • File tải xuống (PDF, ZIP, tài liệu)
  • Nội dung tĩnh của website (landing page, blog)
Với nội dung động (dynamic) — ví dụ trang giỏ hàng cá nhân, dashboard sau khi đăng nhập — theo truyền thống thì không cache được vì mỗi người thấy một kết quả khác nhau. Tuy nhiên CDN hiện đại vẫn tăng tốc được cả nội dung động bằng cách tối ưu đường truyền từ POP về origin (route qua backbone riêng thay vì internet công cộng), và cho phép cache một phần với các kỹ thuật như cache theo cookie, header hoặc query string.

Cache-Control: linh hồn của CDN

Điều quyết định CDN cache file trong bao lâu chính là HTTP header mà origin trả về, quan trọng nhất là Cache-Control. Ví dụ:

Cache-Control: public, max-age=31536000, immutable

Header này nói với CDN: "File này công khai, cache được, giữ trong 31.536.000 giây (tức 1 năm), và không bao giờ đổi." Rất phù hợp cho các file có tên chứa hash như app.a3f9c2.js.

Ngược lại:

Cache-Control: no-store

nghĩa là tuyệt đối không cache — dùng cho API trả dữ liệu nhạy cảm.

Ngoài max-age, CDN còn có khái niệm TTL — Time To Live, tức thời gian một object được coi là còn "tươi" trong cache. Hết TTL, POP sẽ kiểm tra lại với origin xem file có thay đổi không (thường bằng header ETag hoặc Last-Modified).

So sánh nhanh ba nhà cung cấp

  • Amazon CloudFront: tích hợp sâu với hệ sinh thái AWS (S3, EC2, ALB, Lambda@Edge). Rất mạnh khi bạn đã ở trong AWS. Tính phí theo lượng dữ liệu ra (data transfer out) và số request.
  • Google Cloud CDN: gắn liền với Cloud Load Balancing của Google, tận dụng mạng backbone khổng lồ của Google. Phù hợp khi hạ tầng bạn ở GCP.
  • Cloudflare: nổi tiếng với gói miễn phí hào phóng, dễ cấu hình nhất (chỉ cần trỏ DNS), tích hợp sẵn bảo mật (WAF, chống DDoS) và edge computing (Workers). Đây thường là lựa chọn đầu tiên của startup và developer cá nhân ở Việt Nam.

Tình huống thực tế

Tình huống 1: Shop thời trang online "chết" trong ngày sale 12/12

Một shop thời trang tại TP.HCM, đặt trên một VPS đơn (2 CPU, 4GB RAM) tại nhà cung cấp trong nước. Ngày thường traffic ổn định, nhưng đến chiến dịch sale 12/12, họ chạy quảng cáo mạnh và lượng truy cập tăng gấp 20 lần trong vài giờ. Website tải cực chậm, có lúc trả lỗi 502 vì VPS quá tải — phần lớn tải trọng đến từ việc server phải phục vụ đi phục vụ lại hàng trăm ảnh sản phẩm nặng 300–800KB mỗi tấm.

Diễn giải: Sau sự cố, đội kỹ thuật đưa toàn bộ website qua Cloudflare (gói Pro, khoảng 20 USD/tháng), chỉ bằng cách đổi nameserver DNS. Họ cấu hình cache cho toàn bộ ảnh với Cache-Control: public, max-age=2592000 (30 ngày), bật tính năng Polish để tự động nén ảnh và chuyển sang định dạng WebP. Kết quả ở đợt sale sau: hơn 92% request được phục vụ từ cache Cloudflare, VPS chỉ nhận khoảng 8% traffic (chủ yếu là API động và trang thanh toán). Server không còn 502, thời gian tải trang giảm từ 6 giây xuống dưới 1,5 giây.

Bài học: CDN không chỉ tăng tốc, mà còn là lá chắn giảm tải cho origin. Với ứng dụng nhiều asset tĩnh, chỉ riêng việc cache đúng cách đã giải quyết được phần lớn vấn đề chịu tải mà không cần nâng cấp server đắt tiền.

Tình huống 2: Startup SaaS Việt phục vụ khách hàng khu vực Đông Nam Á

Một startup SaaS về quản lý bán hàng, hạ tầng đặt trên AWS ở region Singapore (ap-southeast-1), có khách hàng ở Việt Nam, Thái Lan, Indonesia và Philippines. Ứng dụng là một single-page app (React) với bundle JavaScript nặng khoảng 2MB. Khách ở Indonesia phàn nàn ứng dụng mở lần đầu rất lâu.

Diễn giải: Đội DevOps đặt file build tĩnh lên S3, rồi dựng CloudFront phía trước với S3 làm origin. Họ đặt tên file theo dạng có hash (main.7d2a1f.js) và set Cache-Control: max-age=31536000, immutable. Nhờ CloudFront có POP tại Jakarta, khách Indonesia bây giờ tải bundle từ ngay trong nước. Họ cũng dùng Origin Access Control để chặn truy cập trực tiếp vào S3 bucket, buộc mọi người phải đi qua CloudFront. Thời gian tải lần đầu ở Indonesia giảm từ khoảng 5 giây xuống 1,2 giây. Chi phí data transfer cũng giảm vì giá đi ra từ CloudFront rẻ hơn so với đi thẳng từ S3 tới internet.

Bài học: Khi phục vụ nhiều quốc gia, hãy chọn nhà cung cấp CDN có POP phủ đúng thị trường của bạn. Đặt tên file có hash cho phép cache "vĩnh viễn" mà vẫn cập nhật được khi deploy — vì file mới sẽ có tên mới, tự động cache miss.

Tình huống 3: Bài học đắt giá về cache invalidation

Một sàn thương mại điện tử vừa đưa CDN vào production. Đội marketing thay banner trang chủ trước một sự kiện lớn, nhưng suốt 2 tiếng đồng hồ khách hàng vẫn thấy banner cũ. Nguyên nhân: file banner tên home-banner.jpg (tên cố định) đã được cache khắp các POP với TTL 7 ngày, và họ quên thực hiện invalidation.

Diễn giải: Đội phải chạy lệnh invalidation trên CloudFront để xóa /home-banner.jpg khỏi toàn bộ edge. Sau sự cố, họ đổi quy trình: mọi asset đổi thường xuyên đều gắn thêm query string phiên bản (home-banner.jpg?v=20261212) hoặc dùng tên file có hash. Nhờ vậy, mỗi lần đổi ảnh chỉ cần đổi tham số phiên bản là CDN tự nhận đây là object mới.

Bài học: Cache mạnh đi kèm rủi ro "nội dung cũ dai dẳng". Hãy có chiến lược cache busting (đổi tên/phiên bản file) ngay từ đầu, và chỉ dùng invalidation thủ công như phương án chữa cháy — vì invalidation vừa chậm vừa có thể tính phí.

Hướng dẫn từng bước

Dưới đây là quy trình chuẩn để đưa một website qua CDN, minh họa bằng Cloudflare vì đây là cách dễ tiếp cận nhất, nhưng nguyên tắc áp dụng chung cho mọi nhà cung cấp.

Bước 1 — Xác định origin và phân loại nội dung. Liệt kê những gì là static (ảnh, CSS, JS, font) và những gì là dynamic (API, trang cá nhân hóa). Chỉ static mới là ứng viên cache mạnh.

Bước 2 — Thêm domain vào CDN. Với Cloudflare: tạo tài khoản, thêm domain, đổi nameserver tại nhà đăng ký tên miền sang nameserver Cloudflare. Với CloudFront: tạo một "distribution", khai báo origin (S3 bucket, ALB hoặc domain gốc), rồi gắn domain của bạn qua CNAME cùng chứng chỉ SSL từ ACM.

Bước 3 — Cấu hình cache header tại origin. Đây là bước quan trọng nhất. Đặt Cache-Control phù hợp: file có hash thì max-age=31536000, immutable; HTML có thể max-age=0, must-revalidate để luôn kiểm tra lại; API động thì no-store.

Bước 4 — Bật HTTPS và HTTP/2. CDN hiện đại cung cấp SSL miễn phí. Luôn ép buộc HTTPS và bật HTTP/2 hoặc HTTP/3 để tăng tốc thêm.

Bước 5 — Bật tối ưu asset. Kích hoạt nén Gzip/Brotli, nén ảnh, minify CSS/JS nếu nhà cung cấp hỗ trợ.

Bước 6 — Kiểm tra cache hit. Mở DevTools của trình duyệt, xem response header. Cloudflare trả cf-cache-status: HIT/MISS; CloudFront trả x-cache: Hit from cloudfront. Đây là cách xác nhận CDN thực sự đang cache.

Bước 7 — Thiết lập quy trình cache busting và invalidation. Tích hợp việc đổi tên file có hash vào pipeline build. Chuẩn bị sẵn lệnh invalidation cho tình huống khẩn cấp.

Bước 8 — Bảo vệ origin. Cấu hình để origin chỉ nhận traffic từ CDN (qua Origin Access Control của CloudFront, hoặc whitelist IP của Cloudflare), tránh việc kẻ tấn công bỏ qua CDN đánh thẳng vào server gốc.

Lỗi thường gặp & mẹo

Quên đặt Cache-Control — CDN không cache gì cả. Nhiều người bật CDN nhưng để tỷ lệ cache hit gần bằng 0 vì origin không trả header cache. Luôn kiểm tra header response thực tế, đừng tin CDN "tự biết".

Cache nhầm nội dung động/riêng tư. Nếu bạn lỡ cache một trang có thông tin cá nhân (ví dụ trang tài khoản), người dùng A có thể thấy dữ liệu của người dùng B từ cache. Đây là lỗi bảo mật nghiêm trọng. Nội dung riêng tư luôn phải Cache-Control: private hoặc no-store.

Lạm dụng invalidation. Invalidation trên CloudFront miễn phí 1.000 đường dẫn đầu mỗi tháng, sau đó tính phí; và nó cũng chậm (vài phút để lan khắp edge). Hãy ưu tiên cache busting bằng phiên bản/hash thay vì invalidation liên tục.

Không cân nhắc chi phí data transfer out. CDN tính phí theo lượng dữ liệu đi ra tới người dùng. Video và ảnh nặng có thể tạo hóa đơn lớn bất ngờ. Mẹo: nén ảnh, dùng WebP/AVIF, dùng gói cam kết dung lượng nếu traffic lớn.

Bỏ qua vary theo query string / cookie sai cách. Nếu cache theo toàn bộ query string, các tham số tracking (utm_source=...) sẽ tạo ra vô số biến thể cache khác nhau cho cùng một nội dung, làm tỷ lệ hit giảm mạnh. Hãy cấu hình bỏ qua các query param không ảnh hưởng nội dung.

Mẹo phủ POP đúng thị trường. Trước khi chọn nhà cung cấp, hãy tra bản đồ POP của họ tại thị trường mục tiêu. Với người dùng Việt Nam, cả Cloudflare và CloudFront đều có edge trong nước — điều này quyết định độ trễ thực tế.

Mẹo giám sát. Theo dõi tỷ lệ cache hit ratio định kỳ. Một website static tối ưu tốt thường đạt trên 90%. Nếu tỷ lệ thấp, gần như chắc chắn cache header đang sai.

Bài tập thực hành

  • Phân loại nội dung. Lấy một website bất kỳ bạn từng làm, liệt kê tất cả loại tài nguyên và phân thành hai nhóm: nên cache mạnh và không nên cache. Ghi rõ giá trị Cache-Control bạn sẽ đặt cho từng nhóm.
  • Đọc header thật. Mở một website lớn (ví dụ một trang báo Việt Nam), bật DevTools tab Network, tìm một file ảnh và xem các header cache-control, cf-cache-status hoặc x-cache. Xác định xem file đó được phục vụ từ cache hay từ origin, và TTL là bao nhiêu.
  • Triển khai thử. Tạo một tài khoản Cloudflare miễn phí, đưa một domain cá nhân (hoặc một trang tĩnh trên GitHub Pages) qua Cloudflare. Cấu hình một page rule để cache toàn bộ ảnh 30 ngày, rồi kiểm tra cf-cache-status chuyển từ MISS sang HIT sau lần tải thứ hai.
  • Thiết kế chiến lược cache busting. Viết mô tả ngắn cách bạn sẽ đặt tên file JS/CSS trong pipeline build để vừa cache được 1 năm vừa cập nhật ngay khi deploy. Giải thích vì sao cách này tốt hơn invalidation thủ công.

Tóm tắt

CDN là mạng lưới server phân tán toàn cầu, đặt tại các POP gần người dùng, giúp cache nội dung tĩnh ở biên (edge) để giảm độ trễ và giảm tải cho origin. Cơ chế cốt lõi xoay quanh cache hit/miss và được điều khiển bởi HTTP header, đặc biệt là Cache-Control và TTL. Ba nhà cung cấp phổ biến — CloudFront (mạnh trong hệ AWS), Cloud CDN (gắn với GCP), và Cloudflare (dễ dùng, có gói miễn phí, tích hợp bảo mật) — đều có POP tại Việt Nam, phù hợp cho cả dự án cá nhân lẫn doanh nghiệp.

Ba bài học then chốt: (1) cache header quyết định tất cả — không đặt đúng thì CDN vô nghĩa; (2) hãy dùng cache busting bằng hash/phiên bản thay vì lạm dụng invalidation; (3) đừng quên bảo vệ origin và kiểm soát chi phí data transfer. Nắm vững những nguyên tắc này, bạn đã có trong tay một công cụ tăng tốc mạnh mẽ, tiết kiệm và đáng tin cậy cho mọi ứng dụng cloud.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi