Ra mắt cơ sở dữ liệu mỗi ngày: Bí quyết vận hành 100+ cụm mà không cần "chui" vào hệ thống của khách hàng

turbopuffer, một công ty chuyên về công cụ tìm kiếm và lưu trữ dữ liệu tốc độ cao, vừa công bố kiến trúc "control plane" (mặt phẳng điều khiển) đặc biệt, cho phép họ triển khai hàng chục bản cập nhật cơ sở dữ liệu mỗi ngày trên hơn 100 cụm, bao gồm cả các cụm đặt trong tài khoản cloud của khách hàng (BYOC) mà không cần bất kỳ quyền truy cập trực tiếp nào.

Thay vì sử dụng các công cụ IaC (Infrastructure as Code) truyền thống như Terraform hay Helm, turbopuffer đã xây dựng một hệ thống điều khiển trung tâm dựa trên Kubernetes CRD và một trình điều khiển (controller) chạy cục bộ trên mỗi cụm. Cách tiếp cận này giúp mỗi cụm tự vận hành đến trạng thái cuối cùng một cách độc lập, kể cả khi mất kết nối với trung tâm điều khiển, đồng thời giảm thiểu chi phí vận hành và bảo mật cho khách hàng.

Vấn đề: Vận hành hạ tầng phân tán mà không có "chìa khóa"

Khi khách hàng sử dụng mô hình BYOC (Bring Your Own Cloud), các cụm cơ sở dữ liệu của turbopuffer nằm trong tài khoản cloud của chính khách hàng. Điều này có nghĩa là đội ngũ turbopuffer không có quyền SSH hay kubectl vào các cụm này theo mặc định.

Nhiều nhà cung cấp dịch vụ khác giải quyết vấn đề này bằng cách yêu cầu khách hàng tạo một tài khoản cloud riêng biệt và cấp cho họ quyền quản trị viên thường trực. Tuy nhiên, cách làm này tạo ra gánh nặng về bảo mật, tuân thủ và thanh toán.

Chúng tôi không muốn có các control plane khác nhau cho BYOC và SaaS, vì vậy chúng tôi phải thiết kế theo mẫu số chung nhỏ nhất. Chúng tôi phải vận hành mọi cụm mà không cần "chui" vào bên trong.

Giải pháp: State machine cục bộ và Kubernetes CRD

Để giải quyết bài toán này, turbopuffer đã thiết kế một giải pháp dựa trên các công cụ Kubernetes tiêu chuẩn:

• Một CRD (Custom Resource Definition) duy nhất có tên TurbopufferOperation biểu thị mọi loại thao tác, từ nâng cấp đến dọn dẹp.
• Một controller cục bộ trên mỗi cụm thực hiện vòng lặp đối chiếu (reconciliation loop) để đưa mỗi tài nguyên tùy chỉnh (CR) từ trạng thái này sang trạng thái khác cho đến khi đạt trạng thái cuối cùng.
• Trạng thái được lưu trữ bền vững trong etcd của cụm, cho phép agent (đại diện cụm) tiếp tục hoàn thành công việc ngay cả khi gặp sự cố hoặc mất kết nối.

Các thao tác thường tự động tiến hành, nhưng khách hàng BYOC có thể thiết lập cổng phê duyệt (approval) hoặc cửa sổ bảo trì (maintenance windows) được tích hợp vào CRD như các trạng thái chờ.

Tại sao không dùng Terraform hay GitOps?

turbopuffer chỉ ra những hạn chế của các công cụ IaC truyền thống:

• Thiếu đội DevOps chuyên trách: Các kỹ sư cơ sở dữ liệu cần tự triển khai mã của họ, và họ không quen với Terraform hay Helm.
• Khó áp dụng cho BYOC: Mô hình Terraform mặc định yêu cầu chạy terraform apply từ hạ tầng của turbopuffer, điều không thể thực hiện với BYOC. GitOps cũng gặp vấn đề về quyền sở hữu repository và kiểm soát merge.
• Hình dạng công việc không khai báo (declarative): Các thao tác như reindex namespace, compact WAL, hay dọn dẹp LSM là những công việc (jobs) cần thực hiện, không phải trạng thái cần đạt. Terraform phù hợp cho khai báo hạ tầng, nhưng không phải là hàng đợi công việc tốt.

Kiến trúc control plane: Polling, idempotency và khả năng chịu lỗi

Thay vì IaC, turbopuffer xây dựng một control plane trung tâm gồm:

• API server được hỗ trợ bởi cơ sở dữ liệu PlanetScale MySQL.
• Cụm agent thường xuyên poll API server bằng GET request có xác thực để lấy các thao tác đang chờ.
• Mỗi thao tác là một CR được đặt tên theo ID của thao tác đó, đảm bảo tính idempotent (không tạo trùng lặp).
• Agent gửi lại các thay đổi trạng thái (status transitions) qua POST, được lưu vào bảng status_transitions như một log chỉ ghi (append-only log).
• Khả năng chịu lỗi: Nếu POST không nhận được phản hồi, agent sẽ đưa các transition vào buffer và thử lại. Các transition trùng lặp không thành vấn đề vì trạng thái hiện tại của một thao tác chính là transition mới nhất.

Kiến trúc này đảm bảo control plane luôn đồng bộ với các cụm, ngay cả khi xảy ra mất kết nối tạm thời.

Giao diện điều khiển: Trải nghiệm như một code editor

Để dễ sử dụng, turbopuffer đã xây dựng một dashboard tùy chỉnh bằng Remix/React, lấy cảm hứng từ ứng dụng Linear:

• Mọi thứ có phím tắt, điều khiển hoàn toàn bằng bàn phím.
• Xem nhanh trạng thái cluster: Mỗi cụm hiển thị commit SHA đang triển khai và độ lệch so với SHA mới nhất, kèm metadata từ GitHub (commit message, PR number).
• Nâng cấp hàng loạt: Chọn nhiều cụm trên mọi mô hình triển khai và nâng cấp chúng cùng lúc.

Ngoài ra, hệ thống còn tích hợp:

• Slack: Mỗi thao tác đều có một luồng Slack riêng cho các thay đổi trạng thái. Nếu thất bại, nó sẽ "hét to" vào kênh để mọi người xử lý. Khách hàng BYOC cũng được thông báo qua kênh Slack riêng khi cần phê duyệt.
• Tích hợp công cụ giám sát: Nhảy trực tiếp từ control plane đến Datadog logs, traces, metrics hoặc Polar Signals để debug profile bộ nhớ/CPU khi cần.

Dashboard này không chỉ là một công cụ phụ. Chúng tôi coi nó như một phần mềm hạng nhất và đầu tư công sức kỹ thuật vào nó, để sự phức tạp của việc vận hành các cụm được ẩn sau một giao diện đơn giản, nhanh chóng, điều khiển bằng bàn phím.

Fleet Operations: Tự động hóa triển khai quy mô lớn

Khi số lượng cụm tăng lên, việc nâng cấp thủ công trở nên tẻ nhạt. Vì vậy, turbopuffer bổ sung thêm fleet controller:

• Mọi thao tác có thể được gửi dưới dạng fleet operation, được triển khai theo từng đợt (waves).
• Giữa các đợt, một cổng kiểm tra (gate) đảm bảo mọi cụm trong đợt đều nâng cấp thành công và các monitor không có cảnh báo.
• Nếu có sự cố, fleet controller sẽ tạm dừng triển khai và thông báo qua Slack, giới hạn phạm vi ảnh hưởng.
• Kiến trúc này không thay đổi gì ở cluster agent; nó vẫn poll API server và xử lý các CRD như cũ.

Bài học cho các kỹ sư DevOps Việt Nam

Câu chuyện của turbopuffer cho thấy một triết lý thiết kế quan trọng: sự đơn giản trong vận hành là chìa khóa để mở rộng quy mô. Việc xây dựng một control plane duy nhất cho mọi mô hình triển khai, một CRD cho mọi thao tác, và một giao diện duy nhất để quản lý toàn bộ hệ thống đã giúp họ giảm thiểu độ phức tạp và duy trì tốc độ ra mắt sản phẩm.

Đối với các đội ngũ kỹ thuật đang phát triển hạ tầng cloud-native tại Việt Nam, bài học lớn nhất có thể là: hãy thiết kế cho tình huống mất kết nối và không có quyền truy cập trực tiếp, đồng thời ưu tiên xây dựng các công cụ nội bộ giúp ẩn đi sự phức tạp của hạ tầng. Điều này không chỉ tăng tốc độ triển khai mà còn cải thiện đáng kể trải nghiệm on-call của kỹ sư.

Giao diện triển khai cập nhật lên Slack

Quy trình phê duyệt tự động qua Slack

Bảng điều khiển quản lý Fleet Operations