DocDB của Stripe: Cách di chuyển dữ liệu không thời gian chết vận hành hệ thống thanh toán nghìn tỷ USD

Hãy tưởng tượng việc mở rộng một trong những nhà ga sân bay bận rộn nhất thế giới trong khi máy bay vẫn liên tục cất và hạ cánh mỗi 60 giây. Sân bay Quốc tế Hartsfield-Jackson Atlanta đã thực hiện một kỳ tích kỹ thuật tương tự khi họ di chuyển các module bê tông nặng 700 tấn để mở rộng nhà ga D mà không làm gián đoạn các chuyến bay. Tại Stripe, chúng tôi đối mặt với một thách thức tương tự nhưng ở quy mô kỹ thuật số: làm thế nào để mở rộng cơ sở hạ tầng cơ sở dữ liệu xử lý hàng nghìn tỷ đô la thanh toán mà không gây ra thời gian chết (downtime), ngay cả khi chỉ trong tích tắc?

Jimmy Morzaria, Kỹ sư Phần mềm Staff tại Stripe, đã chia sẻ câu chuyện về hành trình xây dựng DocDB — dịch vụ cơ sở dữ liệu nội bộ giúp Stripe đạt được mục tiêu xử lý 1,4 nghìn tỷ USD thanh toán vào năm 2024 với độ tin cậy 5,5 chín (99.99995%).

Tầm quan trọng của độ tin cậy tại quy mô nghìn tỷ

Stripe không chỉ là một cổng thanh toán; đó là hạ tầng thương mại cho những gã khổng lồ như Amazon, Google và Shopify. Với hơn 5 triệu truy vấn cơ sở dữ liệu mỗi giây (QPS) và hàng petabyte dữ liệu tài chính phân tán trên hơn 2.000 shard, bất kỳ sự gián đoạn nào cũng có thể dẫn đến mất doanh thu và uy tín. Nghiên cứu cho thấy 40% khách hàng sẽ từ bỏ doanh nghiệp nếu thanh toán của họ bị từ chối.

Do đó, độ tin cậy không phải là một tính năng bổ sung, mà là yêu cầu sống còn. Trái tim của hệ thống này là DocDB, được xây dựng dựa trên mã nguồn mở MongoDB nhưng được tùy chỉnh sâu để đáp ứng các yêu cầu khắt khe về bảo mật, hiệu suất và khả năng mở rộng.

Sự tiến hóa của hạ tầng cơ sở dữ liệu tại Stripe

Khởi đầu năm 2011 với MongoDB, Stripe phát triển nhanh chóng. Đến năm 2017, hệ thống đã mở rộng lên hàng chục shard, nhưng các hoạt động bảo trì như tạo chỉ mục (index) hoặc thay thế node vẫn được thực hiện thủ công bằng các script tạm thời. Cách tiếp cận này nhanh chóng trở thành nút thắt cổ chai.

Stripe đã giải quyết vấn đề bằng cách xây dựng một lớp Database Proxy (Proxy cơ sở dữ liệu). Lớp này không chỉ quản lý kết nối mà còn đóng vai trò là điểm giao diện duy nhất để thực thi kiểm soát độ tin cậy, khả năng mở rộng và kiểm soát truy cập. Tuy nhiên, sự bùng nổ của thương mại điện tử vào năm 2020, đặc biệt là sự gia tăng của các công ty AI, đã đẩy tải lượng truy vấn và lưu trữ lên mức đỉnh mới.

Việc mở rộng dọc (vertical scaling) — tăng sức mạnh cho các máy chủ hiện có — sớm chạm đến giới hạn vật lý. Stripe buộc phải chuyển sang mở rộng ngang (horizontal scaling). Để làm được điều này, chúng tôi đã đầu tư vào các khối xây dựng nền tảng quan trọng:

• Control Plane: Để cung cấp và hủy cấp phát cơ sở dữ liệu, shard.
• Routing Metadata Service: Ánh xạ các phân vùng cơ sở dữ liệu tới các shard vật lý.
• Online Data Movement: Khả năng di chuyển dữ liệu trực tuyến để mở rộng ngang.

DocDB: Tại sao tự xây dựng thay vì mua?

Nhiều người hỏi tại sao Stripe lại tự xây dựng một Database-as-a-Service (DBaaS) thay vì sử dụng giải pháp có sẵn. Câu trả lời nằm ở ba yếu tố: Bảo mật, Độ tin cậy/Hiệu suất và Quy mô.

• Bảo mật: Với một nền tảng tài chính, bảo mật là tối thượng. DocDB cho phép thực thi các chính sách ủy quyền trực tiếp tại lớp dữ liệu.
• Độ tin cậy và Hiệu suất: MongoDB rất mạnh mẽ nhưng bề mặt truy vấn rộng lớn của nó có thể dẫn đến các vấn đề hiệu suất nếu không sử dụng đúng cách. DocDB chỉ phơi bày một tập hợp các hàm đã được kiểm chứng, giúp ngăn chặn các sự cố không mong muốn và đảm bảo đa người thuê (multi-tenancy) thực sự với hạn ngạch (quota) được thực thi nghiêm ngặt.
• Quy mô: DocDB được thiết kế tập trung vào khả năng mở rộng ngang liền mạch thông qua sharding.

Nền tảng di chuyển dữ liệu không thời gian chết

Để đạt được khả năng mở rộng ngang mà không ảnh hưởng đến dịch vụ, Stripe đã xây dựng một nền tảng Zero-Downtime Data Movement (Di chuyển dữ liệu không thời gian chết). Quy trình này tuân theo các nguyên tắc thiết kế chính: tính sẵn sàng, tính nhất quán, hiệu suất và khả năng thích ứng.

Quy trình di chuyển dữ liệu giữa các shard bao gồm các bước sau:

1. Đăng ký ý định di chuyển: Ghi nhận ý định di chuyển một khối dữ liệu (chunk) trong Routing Metadata Service.
2. Nhập hàng loạt (Bulk Import): Sử dụng snapshot tại một thời điểm để tải dữ liệu sang shard đích. Một bước đột phá quan trọng ở đây là tối ưu hóa thứ tự chèn dựa trên chỉ mục B-tree của MongoDB, giúp tăng tốc độ ghi lên 10 lần.
3. Sao chép không đồng bộ (Async Replication): Đọc oplog (nhật ký hoạt động) từ shard nguồn thông qua hệ thống CDC và ghi vào shard đích. Điều này đảm bảo mọi thay đổi dữ liệu trong quá trình di chuyển đều được đồng bộ.
4. Kiểm tra tính toàn vẹn: So sánh snapshot thời điểm thực giữa shard nguồn và shard đích để đảm bảo dữ liệu nhất quán.
5. Chuyển đổi lưu lượng (Traffic Switch): Đây là bước phức tạp nhất, sử dụng cơ chế Version Gating.

Cơ chế Version Gating: Chìa khóa chuyển đổi mượt mà

Để chuyển đổi lưu lượng truy cập từ shard cũ sang shard mới mà không làm gián đoạn ứng dụng, chúng tôi sử dụng cơ chế "Version Gating" (Cổng kiểm soát phiên bản).

• Các máy chủ proxy cơ sở dữ liệu gửi yêu cầu kèm theo số phiên bản phản ánh phiên bản siêu dữ liệu định tuyến mà chúng biết.
• Shard MongoDB có logic để từ chối các yêu cầu có số phiên bản cũ hơn số phiên bản mà shard hiện đang nắm giữ.

Khi chuyển đổi:

1. Một bộ điều phối (coordinator) sẽ tăng số phiên bản trên shard nguồn.
2. Các truy vấn gửi đến shard nguồn với phiên bản cũ sẽ bị từ chối với lỗi "phiên bản cũ".
3. Bộ điều phối cập nhật định tuyến trong Routing Metadata Service và tăng số phiên bản siêu dữ liệu.
4. Các máy chủ proxy phát hiện định tuyến mới, cập nhật phiên bản và chuyển hướng truy cập sang shard đích.

Toàn bộ quá trình này chỉ mất từ vài mili giây đến tối đa 2 giây. Các yêu cầu thất bại sẽ được thử lại (retry) tự động bởi ứng dụng và thành công ngay lập tức. Ngoài ra, chúng tôi cũng sử dụng cơ chế sao chép hai chiều (bidirectional replication) trong quá trình di chuyển để cho phép hoàn tác (rollback) nhanh chóng nếu cần thiết.

Vượt ra ngoài khả năng mở rộng

Nền tảng di chuyển dữ liệu này không chỉ dùng để thêm shard (mở rộng ngang). Nó mở ra nhiều trường hợp sử dụng khác:

• Gộp shard: Gộp nhiều shard lại thành một khi chúng không được sử dụng hết công suất, giúp tối ưu hóa tài nguyên cho các ngày cao điểm như Black Friday.
• Nâng cấp phiên bản cơ sở dữ liệu: Di chuyển dữ liệu từ shard chạy phiên bản MongoDB cũ sang phiên bản mới, cho phép bỏ qua các phiên bản chính mà không cần nâng cấp tại chỗ (in-place).
• Thay đổi mô hình thuê: Di chuyển cơ sở dữ liệu từ đơn thuê (single-tenant) sang đa thuê (multi-tenant) và ngược lại một cách dễ dàng.

Bài học kinh nghiệm

Câu chuyện của DocDB mang lại ba bài học lớn cho các kỹ sư hạ tầng:

1. Độ tin cậy là không thể thương lượng: Thiết kế hệ thống với độ tin cậy là ưu tiên hàng đầu. Quy trình di chuyển dữ liệu của chúng tôi được thiết kế để đảm bảo không có thời gian chết đối với các ứng dụng sản phẩm.
2. Đầu tư vào nền tảng vững chắc: Khả năng di chuyển dữ liệu trong suốt với ứng dụng không chỉ giúp mở rộng quy mô mà còn hỗ trợ nâng cấp và thay đổi kiến trúc hạ tầng linh hoạt.
3. Tự xây dựng hay Mua sắm: Xây dựng nội bộ có ý nghĩa khi khả năng đó tạo ra lợi thế chiến lược dài hạn, yêu cầu các kiểm soát độc đáo về độ tin cậy, bảo mật hoặc tuân thủ. Ngược lại, mua giải pháp bên ngoài phù hợp với các khả năng không tạo ra sự khác biệt, giúp tập trung nguồn lực vào các cơ hội có tác động cao hơn.

Với DocDB và nền tảng di chuyển dữ liệu không thời gian chết, Stripe đã chuyển đổi việc quản lý cơ sở dữ liệu từ việc chăm sóc vài "con thú cưng" (pets) cần sự chú ý thủ công sang việc quản lý một "đàn gia súc" (cattle) lớn có thể tự động hóa và mở rộng dễ dàng, đảm bảo nền kinh tế số luôn vận hành trơn tru.