Đừng chỉ bê nguyên hệ thống (lift and shift) — Cẩm nang thực tế của tôi về Thiết kế, Tối ưu hóa và Di chuyển Cơ sở dữ liệu Đám mây
Việc đưa cơ sở dữ liệu của bạn lên đám mây có thể giống như mở chiếc hộp Pandora — nhưng điều đó không nhất thiết phải là cơn ác mộng. Tôi đã phân tích các mẫu thiết kế thông minh nhất, các lối tắt khi di chuyển và các mẹo tối ưu hóa giúp bạn tránh khỏi nhiều đêm gỡ lỗi và tiết kiệm cả đống tiền.
Vậy là một anh bạn của tôi từng nói: “Chúng ta chỉ cần mang MySQL on-prem lên EC2, xong.” Hai tháng sau, anh ta gần như bứt tóc vì các đợt tăng đột biến độ trễ và hóa đơn khiến CFO của anh ấy phát khóc. Sự thật là, cơ sở dữ liệu đám mây đòi hỏi một tư duy khác. Bạn không thể chỉ bê nguyên xi thói quen cũ lên đám mây và kỳ vọng mọi thứ chạy êm ru. Tôi đã đi con đường đó vài lần, và tôi đã gom nhặt được cả một bộ công cụ các phương pháp thực sự hiệu quả — dù bạn đang lên kế hoạch cho đợt di chuyển đầu tiên hay đang cố vắt thêm tốc độ từ một hệ thống hiện có.
Hãy bàn về thiết kế trước. Khi tôi phác thảo một hệ thống mới, tôi dựa nhiều vào các mẫu thiết kế cơ sở dữ liệu đám mây đã được kiểm chứng, phù hợp với tải công việc. Với một ứng dụng giao dịch, điều đó có thể nghĩa là chuyển sang phi máy chủ (serverless) với thứ gì đó như Aurora Serverless — nó tự mở rộng quy mô và giúp bạn không cần bận tâm đến kích thước phiên bản. Với một catalog thương mại điện tử nơi lượt đọc vượt trội lượt ghi theo tỷ lệ 100 đổi 1, tôi sẽ thêm vào các bản sao đọc (read replicas) và một lớp bộ nhớ đệm với Redis hoặc ElastiCache — đó chính là lúc việc thiết kế cơ sở dữ liệu đám mây cho khả năng mở rộng thực sự phát huy giá trị. Thay vì xây dựng một cơ sở dữ liệu nguyên khối bị nghẽn khi tải cao, bạn nghĩ theo hướng phân rã: tách mô hình lệnh và mô hình truy vấn (CQRS rất hữu ích ở đây), sử dụng phân mảnh (sharding) một cách khôn ngoan, hoặc chuyển các phân tích nặng sang một engine dạng cột như Redshift. Kiến trúc cơ sở dữ liệu đám mây tốt nhất không phải là một chiếc hộp ma thuật duy nhất; nó là một tập hợp các thành phần, mỗi thành phần làm tốt một việc và giao tiếp qua các API nhẹ.
Nhưng nếu bạn đã có một cơ sở dữ liệu “khổng lồ” nằm trong trung tâm dữ liệu của riêng mình và chỉ cần đưa nó lên đám mây thì sao? Đó là lúc một chiến lược di chuyển cơ sở dữ liệu đám mây vững chắc sẽ cứu cánh cho bạn. Tôi từng thấy nhiều người lao vào làm vội, và tin tôi đi, hậu quả chẳng đẹp đẽ gì — chỉ mục bị hỏng, chi phí tăng vọt, và thời gian ngừng hoạt động lẽ ra có thể tránh được. Vậy đây là cách di chuyển cơ sở dữ liệu lên đám mây mà không khiến bạn phát điên. Trước tiên, bạn cần một bộ các bước di chuyển cơ sở dữ liệu lên đám mây thực tế, không rườm rà. Tôi sẽ không đưa cho bạn một danh sách kiểu sách giáo khoa, nhưng hãy hình dung thế này: bắt đầu với giai đoạn khám phá, nơi bạn lập hồ sơ về tải công việc, kích thước bảng và các phụ thuộc. Sau đó chọn phương pháp di chuyển — đồng nhất (như SQL Server sang SQL Server trên RDS) hoặc không đồng nhất (Oracle sang PostgreSQL trên Aurora). Các công cụ như AWS Database Migration Service cực kỳ tiện lợi ở đây, nhưng bạn không thể chỉ “bắn rồi quên”. Bạn sẽ muốn tuân theo các biện pháp tốt nhất khi di chuyển cơ sở dữ liệu lên AWS, chẳng hạn như bật ghi nhật ký chi tiết, kiểm thử trước với một tập dữ liệu đại diện nhỏ, và thiết lập sao chép liên tục để giảm thiểu thời gian cắt chuyển (cutover). Một danh sách kiểm tra di chuyển cơ sở dữ liệu đám mây nên bao gồm những thứ như: xác minh rằng