- Stripe đã duy trì 99,999% thời gian hoạt động trong năm 2023, đồng thời xử lý tổng khối lượng thanh toán 1 nghìn tỷ USD
- Đội ngũ hạ tầng cơ sở dữ liệu của Stripe cung cấp DocDB, một dịch vụ cơ sở dữ liệu dưới dạng dịch vụ (DBaaS), làm lớp nền cho API
- DocDB là một phiên bản mở rộng của MongoDB Community, gồm nhiều dịch vụ do Stripe tự xây dựng nội bộ
- Hệ thống xử lý hơn 5 triệu truy vấn mỗi giây, phân tán dữ liệu tài chính quan trọng ở quy mô petabyte trên hơn 2.000 shard cơ sở dữ liệu và lưu trong hơn 5.000 collection
- Stripe chọn MongoDB Community vì tính linh hoạt của mô hình tài liệu và khả năng xử lý dữ liệu thời gian thực ở quy mô lớn
- Vào năm 2011, MongoDB Atlas chưa tồn tại, nên Stripe đã xây dựng cụm MongoDB tự quản lý chạy trên đám mây
- Trọng tâm của DocDB là Data Movement Platform
- Ban đầu nó được xây dựng như một giải pháp mở rộng ngang để vượt qua giới hạn mở rộng dọc của MongoDB, nhưng sau đó được tùy biến cho nhiều mục đích khác nhau
- Ví dụ như gộp các shard cơ sở dữ liệu ít dùng để tăng mức sử dụng và hiệu quả, nâng cấp major version của database engine để tăng độ ổn định, hoặc chuyển khách hàng lớn từ multi-tenant sang single-tenant
- Data Movement Platform cho phép chuyển đổi từ một số ít shard cơ sở dữ liệu dung lượng lớn sang nhiều shard dung lượng nhỏ
- Nó cũng cung cấp khả năng di chuyển trong suốt với client và zero downtime, giúp Stripe cung cấp DBaaS có độ đàn hồi rất cao
- DocDB có thể tách shard cơ sở dữ liệu khi lưu lượng tăng đột biến, và khi lưu lượng thấp thì có thể hợp nhất hàng nghìn cơ sở dữ liệu bằng bin packing
Cách xây dựng hạ tầng cơ sở dữ liệu
- Khi ra mắt năm 2011, Stripe đã chọn MongoDB làm cơ sở dữ liệu online vì năng suất cho lập trình viên tốt hơn so với cơ sở dữ liệu quan hệ tiêu chuẩn
- Stripe muốn vận hành một hạ tầng cơ sở dữ liệu vững chắc trên MongoDB với ưu tiên hàng đầu là độ ổn định của API, nhưng không tìm được DBaaS có sẵn nào đáp ứng yêu cầu
- Đáp ứng các tiêu chuẩn cao nhất về tính sẵn sàng, độ bền và hiệu năng
- Chỉ lộ ra số lượng tính năng cơ sở dữ liệu tối thiểu để ngăn các vấn đề do truy vấn chưa được tối ưu từ ứng dụng client gây ra
- Hỗ trợ khả năng mở rộng ngang thông qua sharding
- Cung cấp hỗ trợ hạng nhất cho multi-tenancy với quota cưỡng chế
- Cung cấp bảo mật mạnh bằng cách thực thi các chính sách phân quyền
- Giải pháp là xây dựng DocDB dùng MongoDB làm storage engine nền tảng — một DBaaS thực sự co giãn và mở rộng được, trong đó di chuyển dữ liệu online là cốt lõi
- Các ứng dụng sản phẩm của Stripe truy cập dữ liệu trong cơ sở dữ liệu thông qua một fleet máy chủ proxy cơ sở dữ liệu do Stripe tự phát triển bằng Go để thực thi các vấn đề về độ tin cậy, khả năng mở rộng, kiểm soát quota và kiểm soát truy cập
- Stripe đã đưa ra quyết định kiến trúc cốt lõi là sử dụng sharding làm cơ chế mở rộng ngang
- Hàng nghìn shard cơ sở dữ liệu, mỗi shard lưu giữ một phần nhỏ của dữ liệu tích lũy, hiện là nền tảng cho toàn bộ sản phẩm của Stripe
- Khi ứng dụng gửi truy vấn đến máy chủ proxy cơ sở dữ liệu, proxy sẽ phân tích truy vấn, định tuyến tới một hoặc nhiều shard, sau đó kết hợp kết quả từ các shard và trả về lại cho ứng dụng
- Máy chủ proxy cơ sở dữ liệu dựa vào dịch vụ metadata của chunk để ánh xạ chunk tới shard cơ sở dữ liệu, nhờ đó có thể dễ dàng tra cứu shard liên quan cho một truy vấn nhất định
- Các sự kiện thay đổi phát sinh từ thao tác ghi vào cơ sở dữ liệu được gửi tới hệ thống phần mềm streaming, rồi cuối cùng được lưu trong object storage qua pipeline change data capture (CDC)
- Ở cấp ứng dụng sản phẩm, đội ngũ Stripe dùng control plane nội bộ của cơ sở dữ liệu tài liệu để cấp phát các container logic của dữ liệu gọi là logical database, bao gồm một hoặc nhiều collection DocDB gồm các tài liệu có mục đích liên quan
- Dữ liệu của các collection DocDB này được phân tán trên nhiều cơ sở dữ liệu (physical database), mỗi nơi lưu một phần nhỏ của collection
- Các physical database của DocDB nằm trên các shard được triển khai dưới dạng replica set gồm một node primary và nhiều node secondary với khả năng replication và tự động failover
Cách thiết kế Data Movement Platform
- Để xây dựng một sản phẩm DBaaS có khả năng mở rộng ngang và độ đàn hồi cao, có thể scale up và scale down theo nhu cầu của ứng dụng sản phẩm, Stripe cần khả năng di chuyển dữ liệu giữa các shard cơ sở dữ liệu với zero downtime theo cách trong suốt với client
- Đây là một bài toán hệ thống phân tán phức tạp, còn khó hơn nữa vì các yêu cầu đặc thù của dữ liệu tài chính quan trọng
- Tính nhất quán và toàn vẹn dữ liệu: Cần bảo đảm dữ liệu được di chuyển vẫn giữ được tính nhất quán và toàn vẹn ở cả shard nguồn lẫn shard đích
- Tính sẵn sàng: Không thể chấp nhận downtime kéo dài trong quá trình di chuyển dữ liệu, vì hàng triệu doanh nghiệp phụ thuộc vào Stripe để nhận thanh toán từ khách hàng 24/7
- Mục tiêu là giữ các bước cốt lõi của quá trình di chuyển ngắn hơn thời gian failover primary cơ sở dữ liệu theo kế hoạch, thường chỉ vài giây, và nằm trong retry budget của ứng dụng sản phẩm
- Độ chi tiết và khả năng thích ứng: Ở quy mô của Stripe, hệ thống phải có thể di chuyển số lượng chunk dữ liệu bất kỳ từ số lượng shard nguồn bất kỳ sang shard đích bất kỳ
- Không được có giới hạn về số lượng di chuyển chunk cơ sở dữ liệu đang diễn ra trong toàn fleet, cũng như không giới hạn số lượng di chuyển mà một shard cụ thể có thể tham gia tại một thời điểm
- Ngoài ra, vì nhiều shard cơ sở dữ liệu chứa dữ liệu ở quy mô terabyte, hệ thống cũng phải có thể di chuyển các chunk với nhiều kích thước khác nhau ở thông lượng cao
- Không ảnh hưởng hiệu năng lên shard nguồn: Khi di chuyển chunk cơ sở dữ liệu giữa các shard, mục tiêu là giữ nguyên hiệu năng và thông lượng khả dụng của shard nguồn để không ảnh hưởng tiêu cực đến truy vấn người dùng
- Để đáp ứng các yêu cầu này, Stripe đã xây dựng một nền tảng di chuyển dữ liệu, gọi tới các dịch vụ được thiết kế riêng để quản lý di chuyển dữ liệu online giữa các shard cơ sở dữ liệu
- Thành phần Coordinator của nền tảng di chuyển dữ liệu chịu trách nhiệm điều phối nhiều bước liên quan đến di chuyển dữ liệu online và gọi các dịch vụ liên quan để thực hiện từng giai đoạn bên dưới
Bước 1: Đăng ký di chuyển chunk
- Trước tiên, hệ thống đăng ký ý định di chuyển một chunk cơ sở dữ liệu từ shard nguồn sang một shard đích bất kỳ trong dịch vụ metadata của chunk
- Sau đó, hệ thống xây dựng index trên shard đích cho chunk đang được di chuyển
Bước 2: Import dữ liệu hàng loạt
- Tiếp theo, hệ thống nạp dữ liệu vào một hoặc nhiều shard cơ sở dữ liệu bằng snapshot chunk của shard nguồn tại thời điểm T
- Dịch vụ thực hiện import dữ liệu hàng loạt chấp nhận nhiều bộ lọc dữ liệu khác nhau và chỉ import những chunk dữ liệu đáp ứng tiêu chí lọc
- Ban đầu việc này có vẻ đơn giản, nhưng Stripe đã gặp giới hạn thông lượng khi nạp dữ liệu hàng loạt vào các shard DocDB
- Stripe đã thử gom batch các thao tác ghi và tinh chỉnh tham số engine DocDB để tối ưu import dữ liệu hàng loạt, nhưng không đạt nhiều thành công
- Tuy nhiên, Stripe đã đạt được bước đột phá đáng kể khi tận dụng việc DocDB dùng cấu trúc dữ liệu B-tree để sắp xếp dữ liệu và tìm cách tối ưu thứ tự chèn
- Bằng cách sắp xếp dữ liệu theo thuộc tính index phổ biến nhất trong collection và chèn theo thứ tự đã sắp xếp, Stripe cải thiện mạnh tính cục bộ của ghi và tăng thông lượng ghi lên 10 lần
Bước 3: Replication bất đồng bộ
- Sau khi import dữ liệu vào shard đích, hệ thống bắt đầu replication thao tác ghi từ shard nguồn sang shard đích cho chunk cơ sở dữ liệu đang được di chuyển kể từ thời điểm T
- Hệ thống replication bất đồng bộ đọc các thay đổi do thao tác ghi trên shard nguồn từ hệ thống CDC và thực hiện ghi lên shard đích
- Operation log, hay oplog, là collection đặc biệt của mỗi shard DocDB, lưu lại bản ghi của mọi thao tác làm thay đổi dữ liệu trong cơ sở dữ liệu của shard đó
- Stripe gửi oplog của tất cả các shard DocDB tới Kafka, nền tảng event streaming, rồi lưu trữ trong dịch vụ object storage đám mây như Amazon S3
- Stripe đã xây dựng một dịch vụ dùng các sự kiện oplog trong Kafka và Amazon S3 để sao chép thay đổi từ một hoặc nhiều shard DocDB nguồn sang một hoặc nhiều shard DocDB đích
- Bằng cách dựa vào các sự kiện oplog của hệ thống CDC, Stripe tránh tiêu tốn thông lượng đọc vốn dành cho truy vấn người dùng trên shard nguồn, từ đó không làm chậm truy vấn người dùng và cũng không bị ràng buộc bởi kích thước oplog của shard nguồn
- Dịch vụ được thiết kế có độ đàn hồi cao, kể cả khi shard đích không khả dụng, và có thể bắt đầu đồng bộ, tạm dừng rồi tiếp tục từ checkpoint bất kỳ lúc nào
- Dịch vụ replication cũng cung cấp khả năng lấy độ trễ replication
- Các thay đổi của chunk đang được di chuyển được sao chép hai chiều, từ shard nguồn sang shard đích và ngược lại; dịch vụ replication gắn thẻ cho các thao tác ghi mà nó phát ra để ngăn replication bất đồng bộ vòng lặp
- Đây là một lựa chọn thiết kế có chủ đích để tạo sự linh hoạt, cho phép hoàn lưu lưu lượng về shard nguồn nếu có sự cố khi chuyển lưu lượng sang shard đích
Bước 4: Xác minh tính chính xác
- Sau khi replication giữa shard nguồn và shard đích được đồng bộ, Stripe thực hiện xác minh toàn diện tính toàn vẹn và chính xác của dữ liệu bằng cách so sánh snapshot tại cùng một thời điểm
- Đây là một lựa chọn thiết kế có chủ đích để tránh ảnh hưởng đến thông lượng của shard
Bước 5: Chuyển lưu lượng
- Khi dữ liệu của chunk đã được import từ shard nguồn sang shard đích và các thay đổi đang được replication tích cực, việc chuyển lưu lượng sẽ được Coordinator điều phối
- Để đổi hướng đường đọc và ghi cho chunk dữ liệu đang di chuyển, hệ thống trước tiên phải tạm dừng lưu lượng tới shard nguồn, cập nhật tuyến trong dịch vụ metadata của chunk, rồi để các máy chủ proxy chuyển hướng đọc và ghi sang shard đích
- Giao thức chuyển lưu lượng dựa trên ý tưởng version gating
- Ở trạng thái ổn định, mỗi máy chủ proxy gắn một version token number vào các request gửi tới shard DocDB
- Stripe đã thêm các bản vá tùy chỉnh vào MongoDB để shard có thể kiểm tra liệu version token number trên request nhận từ proxy có mới hơn version token number mà nó biết hay không, và chỉ xử lý các request đáp ứng tiêu chí này
- Để cập nhật tuyến của chunk, Coordinator thực hiện các bước sau:
- Trước hết, tăng version token number của shard DocDB nguồn. Version token number được lưu trong một tài liệu ở collection đặc biệt của DocDB, và tại thời điểm này mọi thao tác đọc ghi cho chunk trên shard nguồn đều bị từ chối
- Sau đó, chờ dịch vụ replication sao chép xong các thao tác ghi còn tồn đọng từ shard nguồn
- Cuối cùng, cập nhật tuyến của chunk trong dịch vụ metadata của chunk để trỏ tới shard đích cùng version token number
- Khi hoàn tất, các máy chủ proxy sẽ lấy tuyến đã cập nhật của chunk cùng version token number mới nhất từ dịch vụ metadata của chunk
- Máy chủ proxy dùng tuyến cập nhật của chunk để định tuyến các thao tác đọc và ghi cho chunk sang shard đích
- Toàn bộ giao thức chuyển lưu lượng mất chưa đến 2 giây để thực thi, và mọi thao tác đọc ghi thất bại khi gửi tới shard nguồn đều sẽ thành công sau khi retry
Bước 6: Hủy đăng ký di chuyển chunk
- Cuối cùng, hệ thống đánh dấu việc di chuyển là hoàn tất trong dịch vụ metadata của chunk và xóa dữ liệu chunk khỏi shard nguồn để kết thúc quá trình di chuyển
Ứng dụng của nền tảng di chuyển dữ liệu
- Khả năng di chuyển chunk dữ liệu online giữa các shard DocDB giúp Stripe mở rộng hạ tầng cơ sở dữ liệu theo chiều ngang để theo kịp tốc độ tăng trưởng của công ty
- Các kỹ sư trong đội hạ tầng cơ sở dữ liệu có thể tách shard DocDB chỉ với một cú nhấp chuột dựa trên kích thước và thông lượng, từ đó tạo thêm dư địa về lưu trữ và thông lượng cho các đội sản phẩm
- Trong năm 2023, Stripe đã dùng nền tảng di chuyển dữ liệu để cải thiện mức sử dụng hạ tầng cơ sở dữ liệu
- Cụ thể, Stripe đã di chuyển 1,5 petabyte dữ liệu theo cách trong suốt với ứng dụng sản phẩm để bin-pack hàng nghìn cơ sở dữ liệu có mức sử dụng thấp, qua đó giảm tổng số shard DocDB nền tảng xuống còn khoảng ba phần tư
- Stripe cũng dùng nền tảng di chuyển dữ liệu để nâng cấp fleet hạ tầng cơ sở dữ liệu bằng cách forklift dữ liệu sang phiên bản MongoDB mới hơn chỉ trong một bước, không cần đi qua các major và minor version trung gian
- Đội hạ tầng cơ sở dữ liệu của Stripe đang tập trung xây dựng một nền tảng vững chắc và đáng tin cậy có thể mở rộng cùng sự phát triển của nền kinh tế Internet
- Hiện tại, họ đang tạo mẫu một hệ thống quản lý nhiệt để chủ động cân bằng dữ liệu giữa các shard dựa trên kích thước và thông lượng, đồng thời đầu tư vào tự động mở rộng shard để phản ứng linh hoạt với thay đổi trong mô hình lưu lượng
Chưa có bình luận nào.