Cloudflare chuyển đổi blog sang nền tảng EmDash: Bài kiểm chứng sức mạnh hạ tầng quy mô lớn

Chắc hẳn bạn đã nhận thấy sự thay đổi gần đây trong thiết kế của Blog Cloudflare. Chúng tôi đã bổ sung chế độ tối (dark mode), hiện đại hóa giao diện và thực hiện nhiều cải tiến nhỏ khác trong quá trình này.

Điều bạn có thể chưa nhận ra – ngoại trừ những người thường xuyên túc trực trên mạng – là việc thiết kế lại này nằm trong một dự án chuyển đổi lớn hơn nhiều. Vào thứ Tư, ngày 12 tháng 8, chúng tôi đã chuyển blog sang EmDash, một hệ quản trị nội dung (CMS) được xây dựng đặc biệt để hoạt động trên Astro và với Cloudflare.

Chúng tôi sẽ đưa bạn đi sâu vào câu chuyện chuyển đổi này – những gì chúng tôi đã học được và cách EmDash trở nên tốt hơn – cũng như những lợi ích mà chúng tôi đang nhận thấy từ nền tảng mới.

Chúng tôi là "Customer Zero" (Khách hàng số 0)

Tại Cloudflare, chính Cloudflare là "Customer Zero". Điều này có nghĩa là chúng tôi sử dụng chính các sản phẩm của mình. Và trong quá trình sử dụng, chúng tôi cải thiện chúng để phục vụ bản thân và khách hàng tốt hơn.

Đây là một giá trị văn hóa rất thực tế tại Cloudflare. Gánh nặng chứng minh thuộc về bạn nếu bạn muốn sử dụng một nhà cung cấp bên ngoài. Tại sao đội ngũ đó không thể hỗ trợ bạn, những khoảng trống nào đang tồn tại, tại sao những khoảng trống đó không thể được lấp đầy, và liệu những "khoảng trống" đó có thực sự là yêu cầu cần thiết hay không?

Ưu tiên này thậm chí còn được ghi nhận trong các tiêu chuẩn kỹ thuật nội bộ của chúng tôi, được gọi là Codex.

Chúng tôi không chỉ xây dựng sản phẩm cho người khác; chúng tôi xây dựng chúng để vận hành chính Cloudflare. Chúng tôi là khách hàng đầu tiên và khắt khe nhất của chính mình.

Chúng tôi kiểm chứng khả năng mở rộng, tính bảo mật và khả năng sử dụng trên cơ sở hạ tầng khổng lồ của chính mình trước khi bất kỳ khách hàng trả phí nào chạm vào sản phẩm. Nếu một sản phẩm gặp lỗi, nó sẽ ảnh hưởng đến chúng tôi trước tiên. Điều này buộc chúng tôi phải khắc phục sự cố ngay lập tức, đảm bảo rằng khi một tính năng đến tay doanh nghiệp, nó đã vượt qua môi trường sản xuất khắc nghiệt nhất trên thế giới.

Với sự ra đời của EmDash và một số hạn chế từ nhà cung cấp CMS hiện tại, chúng tôi biết rằng mình có khả năng sẽ là "Customer Zero" cho EmDash ngay trong nội bộ Cloudflare.

"Customer Zero" trong thực tế

Khi bắt đầu các cuộc thảo luận về việc chuyển đổi, chúng tôi bắt đầu với hai câu hỏi chính:

Nền tảng này có hoạt động không?

Câu hỏi đầu tiên của chúng tôi mang tính bao quát nhất: EmDash có hoạt động hiệu quả với chúng tôi không? Đây là điều bạn muốn biết về bất kỳ nền tảng mới nào, đặc biệt là với một nền tảng chưa đạt phiên bản 1.0.

Để trả lời câu hỏi này, chúng tôi đã chạy thử một loạt các luồng người dùng phổ biến, chẳng hạn như:

Nhìn chung, EmDash đáp ứng khá tốt các bài kiểm tra khả năng sử dụng này. Những khoảng trống chúng tôi tìm thấy thường liên quan đến:

Sự thiếu sót lớn nhất mà chúng tôi phát hiện là vấn đề bài viết lên lịch (scheduled posts), vốn không hoạt động cho đến phiên bản EmDash 0.19.0. Khoảng trống này là điều dễ hiểu đối với một phiên bản EmDash còn sớm, nhưng chắc chắn đó là điều chúng tôi không muốn phát hiện ra sau thời điểm bài viết đã được lên lịch đăng.

EmDash có khả năng mở rộng không?

Mối quan tâm lớn nhất của chúng tôi là liệu cấu hình EmDash đề xuất có thể xử lý lưu lượng truy cập mà chúng tôi thấy trên Blog Cloudflare hay không.

Mô hình lưu lượng truy cập vào blog của chúng tôi cực kỳ đa dạng. Tải thông thường ở mức khoảng 75 yêu cầu mỗi giây (RPS), nhưng cũng có lúc tăng vọt lên hơn 5.000 RPS. Một số đợt tăng đột biến này trùng với thời điểm đăng bài viết mới, nghĩa là các bài viết đó đã trở nên lan truyền và thu hút rất nhiều sự chú ý. Những đợt khác xảy ra vào bất kỳ thời điểm nào trong ngày và đêm, điều này có khả năng là do mọi người đang gửi thêm lưu lượng truy cập vào hệ thống của chúng tôi chỉ để xem điều gì sẽ xảy ra.

Hiệu suất cũng rất quan trọng đối với các hệ thống của chúng tôi (và độc giả của chúng tôi). Suy cho cùng, Cloudflare là một công ty về hiệu suất web, vì vậy tốc độ tải trang trở nên vô cùng quan trọng.

Với hai mối quan tâm đó, chúng tôi đã xây dựng một số kịch bản sử dụng k6, một công cụ kiểm thử hiệu suất mã nguồn mở:

Đối với mỗi kịch bản đó, chúng tôi đã đánh giá:

Với những bài kiểm tra này – cùng nhiều cuộc thảo luận nội bộ và các điểm dữ liệu – chúng tôi đã đi đến kiến trúc sản xuất của mình:

Nhiều lớp bộ nhớ đệm (caching) mà chúng tôi thiết lập đóng vai trò then chốt trong việc giúp blog vừa nhanh vừa bền bỉ. Trong sơ đồ dưới đây, chúng được sắp xếp từ trên xuống dưới theo khoảng cách gần với người dùng:

Với thiết lập này, chúng tôi thường phục vụ 99,5% các tệp tĩnh từ bộ nhớ đệm và 70% các yêu cầu từ bộ nhớ đệm, giúp cải thiện hiệu suất giao diện người dùng (frontend) và giảm tải cho cơ sở dữ liệu.

Khi đã có kiến trúc đó, chúng tôi có thể bắt đầu nghĩ đến việc thiết kế lại giao diện người dùng.

Thiết kế lại giao diện người dùng (Frontend)

Ngoài việc cập nhật kiến trúc backend, quá trình chuyển đổi mang đến cơ hội hoàn hảo để đưa giao diện của blog phù hợp với ngôn ngữ thiết kế hình ảnh cập nhật của Cloudflare. Chúng tôi đã xây dựng lại trải nghiệm frontend bằng cách sử dụng các mẫu được thiết lập bởi hệ thống thiết kế Kumo, tạo ra sự nhất quán về hình ảnh và cấu trúc giữa trang chủ, bảng điều khiển (dashboard) và các trang tiếp thị của Cloudflare. Kết quả là một trải nghiệm đọc gắn kết, mang lại cảm giác như một phần mở rộng tự nhiên của hệ sinh thái Cloudflare rộng lớn hơn.

Một ưu tiên lớn cho việc thiết kế lại này, và cũng là yêu cầu từ lâu của độc giả, là hỗ trợ gốc cho chế độ sáng và tối. Chúng tôi đã triển khai tính năng chuyển đổi chủ đề gắn liền trực tiếp với cài đặt hệ thống, cùng với một nút chuyển đổi thủ công, đồng thời đảm bảo các nguyên tắc về khả năng truy cập được tuân thủ nghiêm ngặt trên cả hai chủ đề. Bất kể sở thích là gì, bảng màu cập nhật và tính năng làm nổi bật cú pháp mã (code syntax highlighting) đều thích ứng liền mạch mà không làm giảm khả năng đọc.

Chúng tôi cũng tận dụng cơ hội này để giải quyết một vài vấn đề nhỏ về trải nghiệm người dùng tồn tại từ lâu, bắt đầu với biểu mẫu đăng ký email. Trước đây, hộp đăng ký nằm ở góc trên bên phải của trang. Do vị trí đó, độc giả thường nhầm lẫn nó với thanh tìm kiếm và nhập truy vấn tìm kiếm trực tiếp vào trường nhập liệu.

Để khắc phục điều này, chúng tôi đã chuyển phần đăng ký email vào một khối kêu gọi hành động (call-to-action) chuyên dụng ở cuối các bài viết.

Giờ đây, khi độc giả đọc xong một bài viết và muốn cập nhật thông tin, lời nhắc đăng ký sẽ xuất hiện một cách tự nhiên ở cuối bài.

Cuối cùng, chúng tôi đã giới thiệu hai tính năng thanh bên chuyên dụng trên các trang bài viết nội bộ để cải thiện khả năng điều hướng và tương tác cộng đồng. Ở bên phải, mục lục "Trên trang này" (On this page) theo dõi tiến trình đọc và cho phép bạn nhảy trực tiếp đến các phần cụ thể của các bài viết kỹ thuật dài. Ở bên trái, phần "Thảo luận trực tuyến" (Discuss Online) mới giúp việc chia sẻ bài viết và tham gia thảo luận trên các nền tảng xã hội và cộng đồng nhà phát triển trở nên dễ dàng hơn bao giờ hết.

Chiến lược triển khai

Khi tiến gần đến thời điểm chuyển đổi, chúng tôi bắt đầu tập trung vào câu hỏi rộng hơn là "làm thế nào để thực hiện thay đổi này một cách an toàn?". Đảm bảo không có thời gian chết (zero downtime) cho độc giả là một yêu cầu không thể thương lượng, cùng với việc đảm bảo cơ chế dự phòng liền mạch nếu có sự cố xảy ra vào phút cuối.

Để đạt được điều này, chúng tôi đã triển khai một Worker proxy để định tuyến lưu lượng truy cập một cách thông minh giữa blog cũ và trang web mới chạy trên EmDash. Worker này đặt một cookie phiên bản trên các yêu cầu, sau đó cho phép chúng tôi định tuyến lưu lượng truy cập đến trải nghiệm mới hoặc cũ tương ứng. Ngoài ra, chiến lược này cho phép chúng tôi quay lại blog cũ nếu trang web mới gặp bất kỳ lỗi 500 nào. Nhờ sự linh hoạt của Cloudflare Workers, proxy này tương đối đơn giản để tạo và mở rộng mà không gặp vấn đề gì. Khả năng định cấu hình kết nối trực tiếp worker-to-worker thông qua liên kết dịch vụ NEW_BLOG đặc biệt hữu ích ở đây, vì nó làm giảm độ trễ cho bất kỳ người dùng cuối nào đi qua proxy. Liên kết dịch vụ này cho phép Worker proxy gửi các yêu cầu đến trực tiếp Worker của blog mới thay vì gửi chúng qua hostname công khai, DNS, TLS và kết nối HTTP đi ra ngoài.

Vào ngày ra mắt, chúng tôi đã bắt đầu triển khai dần dần, bắt đầu từ 1% tổng lưu lượng truy cập, sau đó tăng dần lên 5%, 15% và hơn thế nữa khi chúng tôi xác nhận tình trạng hệ thống. Cách tiếp cận theo từng giai đoạn này cho phép chúng tôi quan sát cách nền tảng xử lý tải thực tế trong môi trường sản xuất, đồng thời bắt kịp một vài trường hợp ngoại lệ vào phút cuối mà không ảnh hưởng đến đại đa số độc giả. Đến cuối ngày, chúng tôi đã chuyển đổi thành công 100% lưu lượng truy cập sang nền tảng mới.

Kết quả