Moving to DynamoDB to Increase Application Resiliency

CapitalOne · 2021 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bối cảnh

Một team ở Capital One chạy stack active-active ở hai region AWS (East, West), service tự failover gần như tức thì, trừ PostgreSQL: primary ở một region, read replica ở region kia, promote mất 10–15 phút.
Ràng buộc: chỉ dùng database managed trên AWS (không tự vận hành MongoDB, Cassandra).

Lựa chọn	Ưu	Nhược (lúc đánh giá, 2019)
Aurora Global Database	Failover chéo region khoảng 1 phút (AWS công bố RPO 1 giây, RTO < 1 phút)	Khi đó chỉ tương thích MySQL (sau có Postgres)
Aurora Multi-Master	Nhiều primary	Chỉ trong một region
DynamoDB	Active-active đa region (Global Tables), không cần failover	Mô hình dữ liệu mới, phải viết lại tầng persistence

Aurora Global được team thích sớm và đã PoC tốt, nhưng DynamoDB là lựa chọn duy nhất active-active đa region nên được chọn.

Global Tables đồng bộ giữa region bằng stream, nhất quán cuối, replication latency khoảng 1 giây (đúng khi tải bình thường, tăng khi tải nặng).
Mô hình NoSQL: thiết kế bảng theo access pattern, thường một bảng nhiều loại entity với prefix key (tri#id...). Không hợp cho reporting/ad-hoc query; cần stream sang kho khác nếu cần báo cáo.
Vướng mắc: DynamoDB không có null/rỗng (dùng cấu trúc đánh dấu null), không có kiểu ngày (lưu chuỗi ISO UTC để sort được). Sửa thiết kế bảng vài lần: dùng composite key + timestamp làm sort key; bỏ filter (gây scan) để dùng query. ReturnConsumedCapacity giúp tối ưu.
Chế độ hai database: ứng dụng đọc/ghi cả DynamoDB và PostgreSQL nhưng chỉ trả dữ liệu PostgreSQL. Chạy production vài tuần không lỗi rồi tắt PostgreSQL.

Thời gian failover của ứng dụng giảm 99%; bỏ hẳn quy trình và script failover cho tầng dữ liệu, vì mỗi region ghi vào bảng của mình.
Hiệu năng query bằng hoặc tốt hơn (một phần do thiết kế cũ chưa tối ưu).

Ở stack active-active, database single-primary thường là phần failover chậm nhất. Muốn bỏ hẳn failover thì phải đổi mô hình dữ liệu (Failover, replica và dự phòng dữ liệu).
Đổi sang active-active nhất quán cuối nghĩa là chấp nhận xung đột ghi và mất khả năng query linh hoạt (Chọn database theo workload).
Dual write với bên cũ làm nguồn sự thật là cách chạy thử kho mới trên traffic thật (Migration không downtime).