Cloud-Native Storage (Phần 1): Từ Cloud Database đến Replicated Database và Configuration Database

Một ứng dụng cloud-native không thể chỉ đơn giản là chuyển cơ sở dữ liệu từ máy chủ vật lý lên đám mây. Hạ tầng đám mây luôn tồn tại nguy cơ máy chủ gặp sự cố, mạng bị gián đoạn hoặc tài nguyên thay đổi liên tục. Vì vậy, hệ thống lưu trữ cũng phải được thiết kế theo những nguyên tắc hoàn toàn khác so với các cơ sở dữ liệu truyền thống giúp ứng dụng vừa lưu trữ dữ liệu an toàn, vừa đạt khả năng mở rộng, tính khả dụng cao và khả năng tự phục hồi khi hạ tầng gặp sự cố.

Cloud Native là gì? Tư duy thiết kế hệ thống hiện đại cho thời đại đám mây

1. Cloud Database (Cơ sở dữ liệu đám mây)

Đây là một giải pháp then chốt để giải quyết nghịch lý của các ứng dụng hiện đại: làm sao để vừa "không lưu trạng thái" (stateless) vừa có thể ghi nhớ dữ liệu nghiệp vụ.

Cloud Database: "Nơi lưu giữ linh hồn" của ứng dụng

Để một ứng dụng chạy tốt trên mây, nó phải là Stateless Application. Nó được gọi là "stateless" vì nó không giữ dữ liệu trong bộ nhớ riêng của nó. Tuy nhiên, thực tế là mọi ứng dụng đều có "trạng thái" (state) — tức là dữ liệu cần ghi nhớ lâu dài.

Cloud Database chính là nơi ứng dụng ủy thác việc lưu trữ các "trạng thái nghiệp vụ" (domain state) này để bản thân ứng dụng có thể tự do co giãn hoặc khởi động lại mà không sợ mất dữ liệu.

Cấu trúc cơ bản của dữ liệu đám mây

Trong môi trường đám mây, Ứng dụng và Dữ liệu là hai thực thể tách biệt. Ứng dụng chỉ lo xử lý logic, còn "trí nhớ" (state) hoàn toàn nằm ở Cloud Database.

Điểm khác biệt so với các cơ sở dữ liệu truyền thống

Chúng ta cần hiểu rằng Cloud Database không giống như các hệ quản trị CSDL cũ (RDBMS) ở ba điểm:

• Linh hoạt về cấu trúc (Schema): Thay vì ép ứng dụng phải tuân theo cấu trúc bảng cứng nhắc, Cloud Database cho phép ứng dụng lưu dữ liệu theo cách nó muốn (thường là dạng tài liệu như JSON).

• Ưu tiên truy cập dữ liệu: Thay vì cố gắng tiết kiệm từng chút dung lượng ổ đĩa, Cloud Database tập trung vào việc làm sao để dữ liệu luôn sẵn sàng và truy xuất nhanh nhất có thể.

• Co giãn theo chiều ngang (Horizontal Scaling): Nó không chạy trên một máy chủ duy nhất mà chạy trên một cụm gồm nhiều "nút" (nodes). Nếu một máy hỏng, các máy khác vẫn phục vụ bình thường, giúp hệ thống luôn hoạt động 24/7.

Các dịch vụ Cơ sở dữ liệu đám mây

• Amazon Web Services (AWS) cung cấp một số dịch vụ DBaaS, bao gồm Amazon Aurora, Amazon DynamoDB, Amazon ElastiCache, Amazon DocumentDB và Amazon Neptune.

• Microsoft Azure cung cấp một số dịch vụ DBaaS, bao gồm Azure SQL Database, Azure Database for PostgreSQL, Azure Cosmos DB, và Azure Cache for Redis

• Google Cloud cung cấp một số dịch vụ DBaaS, bao gồm Cloud SQL, AlloyDB for PostgreSQL, Bigtable, Firestore, Memorystore, và MongoDB Atlas

• IBM Cloud cung cấp một số dịch vụ DBaaS, bao gồm IBM Db2 on Cloud, IBM Cloud Databases for EnterpriseDB, IBM Cloud Databases for PostgreSQL, IBM Cloudant, IBM Cloud Databases for MongoDB, và IBM Cloud Databases for Redis.      

Tóm lại, Cloud Database không chỉ là một công cụ lưu trữ, mà là một hệ thống quản lý trạng thái thông minh, được thiết kế để chịu đựng sự bất ổn của hạ tầng đám mây và hỗ trợ sự linh hoạt của các ứng dụng hiện đại.

2. Replicated Database (Cơ sở dữ liệu sao chép/nhân bản)

Đây là một giải pháp thiết yếu để cơ sở dữ liệu có được cùng một tiêu chuẩn dịch vụ (tính khả dụng, khả năng co giãn và hiệu suất) như chính các ứng dụng đám mây mà nó hỗ trợ.

Trong môi trường đám mây không đáng tin cậy, cách duy nhất để đạt được sự tin cậy là thông qua dự phòng (redundancy). Thay vì chạy một tiến trình duy nhất trên một máy chủ (dễ gây ra "điểm hỏng hóc duy nhất"), Replicated Database vận hành như một cụm (cluster) gồm nhiều nút (nodes). Mỗi nút là một tiến trình cơ sở dữ liệu riêng biệt có bộ lưu trữ riêng, nhưng tất cả phối hợp với nhau để ứng dụng nhìn thấy chúng như một hệ thống duy nhất.

Cách Replicated Database vận hành

• Khả năng co giãn ngang: Bạn có thể tăng công suất bằng cách thêm các nút mới vào cụm.

• Tính khả dụng cao: Nếu một nút hoặc bộ lưu trữ của nó bị hỏng, ứng dụng vẫn có thể truy cập dữ liệu thông qua các nút khác còn hoạt động.

• Mô hình đồng bộ: Có hai cách chính để các nút phối hợp: Leader-Follower (Một nút dẫn đầu điều phối các nút đi theo) hoặc Quorum-based (Các nút bình đẳng, cùng biểu quyết để đạt được sự đồng thuận).

Sự đánh đổi quan trọng: Nhất quán cuối cùng (Eventual Consistency)

Đây là một điểm then chốt: Để đạt được hiệu suất và tính khả dụng cao, Replicated Database thường chấp nhận Nhất quán cuối cùng.

• Vì việc khóa dữ liệu trên tất cả các nút cùng lúc để đảm bảo mọi nơi giống hệt nhau tức thì sẽ làm hệ thống cực kỳ chậm, các bản sao được phép cập nhật theo tốc độ riêng của chúng.

• Điều này có nghĩa là trong một khoảnh khắc cực ngắn (mili giây), một client có thể thấy dữ liệu cũ ở nút này trong khi dữ liệu mới đã ở nút kia, nhưng cuối cùng thì mọi nút sẽ đều có cùng một phiên bản dữ liệu.

Ví dụ về MongoDB

Một cụm MongoDB không phải là một thực thể đơn lẻ mà là một tập hợp các nút (nodes) phối hợp chặt chẽ với nhau. Kiến trúc Primary/Secondary (Chính/Phụ) của MongoDB, một trong những mô hình phổ biến nhất của cơ sở dữ liệu sao chép (Replicated Database) giúp hệ thống vận hành tin cậy trên đám mây:

• Nút Primary (Nút Chính): Đây là "vị chỉ huy" duy nhất trong cụm. Mọi yêu cầu ghi dữ liệu từ ứng dụng đều phải thông qua nút này.

• Nút Secondary (Nút Phụ): Đây là các nút "trợ tá". Chúng giữ các bản sao dữ liệu của nút chính để đảm bảo nếu nút chính gặp sự cố, dữ liệu vẫn không bị mất.

• Driver (Trình điều khiển): Nằm trong ứng dụng khách, đóng vai trò như một người điều phối thông minh, biết nút nào là chính để gửi lệnh ghi và nút nào có thể dùng để đọc dữ liệu.

Nút Primary sẽ sao chép các cập nhật dữ liệu sang các nút Secondary một cách không đồng bộ (asynchronously).

• Ý nghĩa: Khi nút chính có dữ liệu mới, nó sẽ báo cho các nút phụ cập nhật theo. Vì là "không đồng bộ", nút chính không cần chờ các nút phụ xác nhận xong mới tiếp tục làm việc, giúp tốc độ hệ thống rất nhanh.

Đây là phần thú vị nhất:

• Heartbeat (Nhịp đập): Các nút Secondary liên tục gửi tín hiệu "heartbeat" đến nút Primary và đến lẫn nhau để kiểm tra xem mọi người còn "sống" hay không.

• Bầu cử (Election): Nếu nút Primary ngừng giao tiếp (do máy chủ hỏng hoặc lỗi mạng), các nút Secondary sẽ ngay lập tức tổ chức một cuộc "bầu cử" để chọn ra một nút phụ xuất sắc nhất làm Primary mới.

• Nguyên tắc "Độc tôn": Hệ thống đảm bảo tại một thời điểm chỉ có duy nhất một nút chính. Nếu nút chính cũ quay trở lại sau sự cố, nó sẽ bị "giáng chức" xuống làm nút phụ để tránh xung đột.

Mô hình này có những lợi ích:

• Tin cậy trên hạ tầng không ổn định: Bằng cách đặt mỗi nút trên một máy tính khác nhau trong đám mây, nếu một máy hỏng, cụm vẫn hoạt động bình thường.

• Tính khả dụng cao: Quá trình bầu chọn nút chính mới diễn ra tự động và cực nhanh, giúp ứng dụng của bạn gần như không cảm nhận được sự gián đoạn.

Ví dụ về Redis Cluster

Đây là một mô hình tiến hóa hơn của cơ sở dữ liệu sao chép, giúp hệ thống không chỉ chịu lỗi tốt mà còn có khả năng mở rộng cực kỳ linh hoạt trên đám mây.

Cấu trúc mạng lưới: "Mọi con đường đều thông nhau"

• Cluster Bus (Bus cụm): Bạn hãy tưởng tượng đây là một đường dây liên lạc nội bộ xuyên suốt. Trong cụm Redis, mọi nút (node) đều kết nối trực tiếp với tất cả các nút còn lại thông qua tuyến bus này.

• Sự bình đẳng: Nhờ mạng lưới này, các nút liên tục trao đổi thông tin để biết trạng thái của nhau và biết dữ liệu nào đang nằm ở đâu.

Dù các nút trông có vẻ giống nhau, chúng hoạt động ở hai chế độ:

• Nút Chính (Primary): Đóng vai trò "người thực thi toàn quyền", có thể xử lý cả lệnh Đọc (Read) và Ghi (Write) dữ liệu.

• Nút Phụ/Bản sao (Secondary/Replica): Đóng vai trò "người hỗ trợ", chỉ xử lý các lệnh Đọc. Nút này giữ một bản sao theo kiểu bất đồng bộ từ nút chính để sẵn sàng thay thế nếu nút chính gặp sự cố.

Cơ chế kết nối thông minh: "Đến đâu cũng được". Đây là điểm cực kỳ tiện lợi cho ứng dụng khách (client):

• Kết nối bất kỳ đâu: Ứng dụng khách có thể kết nối tới bất kỳ nút nào trong mạng lưới này.

• Tự động điều hướng: Nếu bạn gửi một yêu cầu "Ghi" tới một nút phụ, cụm Redis sẽ không từ chối mà tự động điều hướng yêu cầu đó đến đúng nút chính tương ứng để xử lý. Điều này giúp lập trình viên không phải lo lắng về việc quản lý địa chỉ của từng nút cụ thể.

Khả năng sống sót trên đám mây được thể hiện qua cách cụm này duy trì hoạt động:

• Phân tán rủi ro: Mỗi nút có thể chạy trên một máy chủ vật lý khác nhau trong đám mây, giúp tránh việc sập toàn bộ hệ thống chỉ vì một máy hỏng.

• Quy tắc đa số (Majority): Nếu một phần của mạng lưới bị đứt kết nối (phân mảnh), cụm vẫn sẽ hoạt động nếu phần đó còn giữ được đa số các nút chính và có ít nhất một bản sao cho các nút chính đã mất liên lạc. Nếu không đủ số lượng "đa số", toàn cụm sẽ tự dừng để bảo vệ an toàn dữ liệu.

Tóm lại, Replicated Database không chỉ là một công cụ lưu trữ, mà là một kiến trúc được thiết kế để "sống sót" và "lớn mạnh" trong môi trường đầy biến động của điện toán đám mây.

3. Configuration Database (Cơ sở dữ liệu cấu hình)

Configuration Database hay còn gọi là Dịch vụ điều phối phân tán (Distributed Coordination Service) là một loại cơ sở dữ liệu đặc biệt, đóng vai trò là "bộ não điều phối" cho chính các dịch vụ chạy trên đám mây

Bản chất: "Người giữ nhịp" cho các dịch vụ đám mây

Thông thường, chúng ta xây dựng ứng dụng stateless và đẩy dữ liệu xuống cơ sở dữ liệu. Nhưng bản thân các dịch vụ hạ tầng đám mây lại là những thực thể có trạng thái. Những dịch vụ này cần biết chính xác trạng thái của toàn bộ hệ thống để ra quyết định điều phối.

Khi các dịch vụ này chạy trên nhiều nút (nodes) để đảm bảo tính khả dụng cao, chúng cần một nơi để chia sẻ trạng thái chung sao cho tất cả các nút đều nhìn thấy một sự thật duy nhất tại cùng một thời điểm. CSDL cấu hình chính là nơi lưu trữ những "trạng thái dịch vụ" này.

Sự khác biệt: Nhất quán tin cậy (Reliable Consistency)

Điểm làm nên sự khác biệt giữa CSDL cấu hình và CSDL ứng dụng thông thường là cách chúng xử lý sự đồng bộ:

• CSDL ứng dụng (Application Database): Thường chấp nhận "nhất quán cuối cùng" (eventual consistency) để đạt tốc độ nhanh và tính khả dụng cao.

• CSDL cấu hình (Configuration Database): Ưu tiên sự nhất quán tuyệt đối. Một giao dịch ghi vào đây chỉ được coi là hoàn tất khi đa số các nút trong cụm đã xác nhận việc lưu trữ. Điều này đảm bảo không bao giờ có chuyện nút A đọc được dữ liệu mới mà nút B lại thấy dữ liệu cũ.

Để đạt được sự nhất quán "thép" như vậy, có những hạn chế mà bạn phải chấp nhận:

• Dữ liệu nhỏ và đơn giản: Nó chỉ được tối ưu hóa cho lượng dữ liệu nhỏ (như các cài đặt cấu hình, trạng thái bật/tắt của hệ thống).

• Cấu trúc Key-Value: Dữ liệu thường được lưu dưới dạng cặp "Khóa - Giá trị" đơn giản, không hỗ trợ các truy vấn phức tạp như SQL.

• Hy sinh tính khả dụng: Nếu mạng bị phân vùng (partitioned) và không đủ số lượng nút đa số để biểu quyết, CSDL này có thể tạm ngừng hoạt động hoặc chỉ cho phép đọc để bảo vệ tính đúng đắn của dữ liệu.

Cơ chế thông báo (Notification)

Một tính năng cực kỳ quan trọng là khả năng thông báo thay đổi. Khi một cài đặt cấu hình được cập nhật, CSDL này sẽ chủ động "nhắc" tất cả các nút đang sử dụng dữ liệu đó rằng: "Này, cấu hình đã đổi rồi, cập nhật ngay đi!". Điều này giúp toàn bộ hệ thống phân tán phản ứng đồng bộ và tức thì.

Ví dụ thực tế

Các công nghệ phổ biến nhất hiện nay đang đóng vai trò là CSDL cấu hình:

• etcd: Trái tim của Kubernetes, dùng để lưu trữ toàn bộ trạng thái mong muốn và trạng thái hiện tại của các cụm máy chủ.

• Apache ZooKeeper: Thường được dùng trong các hệ thống dữ liệu lớn như Hadoop hoặc Kafka để điều phối các máy chủ trong cụm.

• Consul: Một công cụ của HashiCorp giúp phát hiện dịch vụ và quản lý cấu hình tập trung.

Tóm lại, CSDL cấu hình không dành cho dữ liệu người dùng của bạn. Nó là một hệ thống chuyên dụng, cực kỳ khắt khe về tính đồng nhất, được thiết kế để giữ cho hạ tầng đám mây luôn hoạt động chính xác và nhịp nhàng dù ở quy mô hàng ngàn máy chủ.

Kết luận

Cloud-Native Storage không chỉ đơn thuần là nơi lưu dữ liệu mà còn là nền tảng giúp toàn bộ hệ thống cloud-native vận hành ổn định. Cloud Database lưu giữ trạng thái của ứng dụng, Replicated Database đảm bảo dữ liệu luôn sẵn sàng ngay cả khi hạ tầng gặp sự cố, còn Configuration Database đóng vai trò điều phối toàn bộ hệ thống phân tán. Ba thành phần này chính là những viên gạch đầu tiên để xây dựng các kiến trúc dữ liệu hiện đại trên nền tảng đám mây.