Nút thắt cổ chai của Relational Database

Ban đầu, PayPay dựa vào AWS Aurora (MySQL) cho toàn bộ dữ liệu giao dịch cốt lõi (sổ cái, số dư user). Aurora là một database rất tuyệt, nhưng về bản chất nó vẫn là một RDBMS truyền thống. Bạn có thể dễ dàng scale read (bằng cách thêm Read Replicas), nhưng tất cả các thao tác Ghi (Writes) đều phải đi qua một Primary Node duy nhất.

Khi PayPay đạt tới mốc hàng chục triệu người dùng, lượng Write TPS trong các đợt chiến dịch đã bắt đầu chạm vào giới hạn vật lý của cấu hình Aurora lớn nhất (Giới hạn của Vertical Scaling).

Các giải pháp truyền thống (Và vì sao chúng thất bại)

  • Manual Sharding: Chia database dựa trên User ID (vd: Users 1-1M ở DB A, 1M-2M ở DB B). Cách này tạo ra một gánh nặng khổng lồ về mặt vận hành, logic định tuyến phức tạp trên application, và biến các giao dịch chéo shard (như User A chuyển tiền cho User B) thành thảm họa.
  • NoSQL (DynamoDB/Cassandra): Dù có thể scale horizontal thoải mái, nhưng các database NoSQL thường thiếu các chuẩn giao dịch ACID chặt chẽ và thiếu tính năng JOIN phức tạp — đây lại là các yêu cầu bắt buộc của một sổ cái tài chính.

Chuyển đổi sang TiDB (NewSQL)

Giải pháp của PayPay là áp dụng TiDB, một database phân tán mã nguồn mở (distributed SQL database) được build bởi PingCAP.

TiDB là gì?

TiDB mang lại cái tốt nhất của cả 2 thế giới:

  1. Khả năng Horizontal Scalability của NoSQL: Có thể thêm node thoải mái để scale ghi và lưu trữ ra vô tận.
  2. Chuẩn ACID của RDBMS: Hỗ trợ distributed transactions và có thể “giao tiếp” bằng giao thức của MySQL.

Cách PayPay sử dụng:

Bằng cách chuyển đổi các domain nặng về ghi (như Payment Ledger) sang TiDB, PayPay đã loại bỏ được cái nút thắt (bottleneck) ghi dữ liệu ở một node duy nhất.

  • Application vẫn viết các câu query SQL bình thường (y chang như đang nói chuyện với MySQL).
  • TiDB tự động, trơn tru phân tán dữ liệu và các câu query đó ngang qua một cluster các node lưu trữ trạng thái (TiKV).

Khi sắp có một chiến dịch khổng lồ, team Platform chỉ đơn giản là bổ sung thêm node TiDB vào để cân tải cho lượng Write, sau đó scale down lại khi chiến dịch kết thúc. Sự chuyển dịch này là một cột mốc quan trọng biến kiến trúc của PayPay trở thành thực sự có khả năng đạt chuẩn planet-scale.

Có một hệ thống tốt là chưa đủ, hệ thống đó cần phải đứng vững trước những sự cố đứt cáp, sập server không báo trước. Khám phá cách vận hành ở Phần 4 — Vận hành: SRE & Chaos Engineering.