Healthchecks.io: Hành trình chuyển đổi sang hệ thống lưu trữ đối tượng tự quản lý

Healthchecks.io là một dịch vụ giám sát thời gian hoạt động (uptime monitoring) phổ biến. Khi người dùng gửi yêu cầu HTTP POST đến các điểm cuối (endpoint) ping của dịch vụ này, Healthchecks.io sẽ lưu trữ 100kB đầu tiên của nội dung yêu cầu. Nếu nội dung nhỏ, nó sẽ được lưu vào cơ sở dữ liệu PostgreSQL; nếu lớn hơn, nó sẽ được chuyển sang hệ thống lưu trữ đối tượng (object storage) tương thích S3.

Gần đây, Healthchecks.io đã thực hiện một bước chuyển đổi quan trọng: từ bỏ các dịch vụ lưu trữ đám mây được quản lý (managed cloud storage) để chuyển sang giải pháp tự lưu trữ (self-hosted) hoàn toàn.

Những khó khăn với các dịch vụ Managed Storage

Vào năm 2022, khi bắt đầu triển khai tính năng lưu trữ nội dung yêu cầu ping, người sáng lập Healthchecks.io đã đánh giá nhiều nhà cung cấp khác nhau. AWS S3 bị loại bỏ do mô hình định giá theo từng yêu cầu (per-request pricing) sẽ trở nên đắt đỏ với tần suất hoạt động cao của dịch vụ, cũng như các lo ngại về pháp lý liên quan đến Đạo luật CLOUD.

Ban đầu, OVHcloud được lựa chọn nhờ không tính phí theo yêu cầu và là công ty EU. Tuy nhiên, theo thời gian, các vấn đề về hiệu suất và độ tin cậy ngày càng gia tăng. Đến năm 2024, dịch vụ chuyển sang UpCloud với chất lượng dịch vụ tốt hơn ban đầu, nhưng sau đó hiệu suất lại suy giảm dần. Các thao tác xóa đối tượng (DeleteObjects) trở nên chậm chạp, thường xuyên vượt quá giới hạn thời gian chờ (timeout).

Yêu cầu khắt khe về hạ tầng

Tính đến tháng 4 năm 2026, Healthchecks.io đang quản lý khoảng 14 triệu đối tượng dữ liệu với tổng dung lượng 119GB. Kích thước trung bình của mỗi đối tượng là 8KB, nhưng có sự biến động lớn từ 100 byte đến 100.000 byte. Hệ thống phải xử lý trung bình 30 thao tác tải lên mỗi giây, với các đỉnh cao lên tới 150 lần/giây, cùng với tỷ lệ thay đổi (churn) dữ liệu liên tục.

Mặc dù lưu trữ đối tượng không quan trọng bằng cơ sở dữ liệu PostgreSQL chính (nếu nó bị lỗi, người dùng vẫn có thể nhận cảnh báo, chỉ không thể xem nội dung chi tiết của ping), nhưng độ trễ thấp vẫn là yếu tố sống còn. Các thao tác S3 diễn ra trong chu kỳ yêu cầu/phản hồi HTTP, nếu chậm sẽ làm nghẽn quy trình xử lý của máy chủ web.

Tìm kiếm giải pháp tối giản

Người sáng lập Healthchecks.io, người làm việc độc lập (one-person team), đã thử nghiệm các giải pháp tự lưu trữ phổ biến như Minio, SeaweedFS và Garage. Tuy nhiên, tất cả đều bị loại bỏ do độ phức tạp vận hành (operational complexity). Việc thiết lập cụm (cluster), cập nhật, thay thế node lỗi và giám sát sức khỏe cụm là quá nhiều gánh nặng cho một người đã phải tự quản lý Postgres, HAProxy và email.

Cuối cùng, giải pháp được chọn là Versity S3 Gateway.

Giải pháp: Versity S3 Gateway và Btrfs

Versity S3 Gateway là một công cụ đơn giản, biến hệ thống tập tin cục bộ thành một máy chủ S3. Nó không cần cơ sở dữ liệu riêng cho metadata; thao tác PutObject tạo một tệp tin thông thường, GetObject đọc tệp tin và DeleteObject xóa tệp tin. Quy trình nâng cấp chỉ đơn giản là thay thế tệp binary và khởi động lại dịch vụ.

Hệ thống mới được triển khai vào tháng 3 năm 2026 với cấu trúc như sau:

• S3 API chạy trên một máy chủ chuyên dụng với địa chỉ IP riêng tư.
• Các máy chủ ứng dụng kết nối qua đường hầm Wireguard.
• Dữ liệu được lưu trên hai ổ NVMe cấu hình RAID 1.
• Sử dụng hệ thống tập tin Btrfs thay vì ext4 để tránh nguy cơ hết inode khi lưu trữ hàng triệu tệp tin nhỏ.

Chiến lược sao lưu cũng được thiết kế chặt chẽ:

• Mỗi hai giờ, quá trình rsync đồng bộ các tệp đã thêm và xóa sang một máy chủ sao lưu.
• Hàng ngày, máy chủ sao lưu thực hiện bản sao lưu đầy đủ, mã hóa và lưu trữ ngoại vi (off-site), giữ dữ liệu trong 30 ngày.

Kết quả đạt được

Sau khi chuyển sang giải pháp tự lưu trữ, các chỉ số hiệu suất của Healthchecks.io đã cải thiện đáng kể:

• Độ trễ của các thao tác S3 giảm rõ rệt.
• Hàng đợi các nội dung ping chờ được tải lên giảm mạnh.

Độ trễ API S3 sau khi chuyển đổi

Hàng đợi chờ xử lý giảm sâu

Mặc dù chi phí thuê máy chủ chuyên dụng cao hơn so với việc lưu trữ 100GB trên các dịch vụ quản lý, nhưng sự cải thiện về hiệu suất và độ tin cậy là hoàn toàn xứng đáng. Danh sách các bộ xử lý dữ liệu phụ (data sub-processors) cũng được rút gọn, giúp đơn giản hóa các vấn đề về tuân thủ quy định.

Người sáng lập tỏ ra thận trọng nhưng lạc quan về hệ thống mới, coi đây là một bước tiến lớn so với giải pháp cũ, đồng thời vẫn mở lòng cho việc chuyển đổi nếu tìm thấy hệ thống nào có sự cân bằng tốt hơn trong tương lai.