Tìm hiểu về Azure Cosmos DB – Phần 1

Thiết kế cơ sở dữ liệu (database) luôn là một trong những công việc đầy khó khăn trong một bài toán xây dựng giải pháp phần mềm. Lựa chọn mô hình cơ sở dữ liệu (database model, viết ngắn gọn là data model) phù hợp, xây dựng các thực thể & mối quan hệ giữa chúng, thiết kế mô hình kiến trúc để đảm bảo database hoạt động ổn định, có khả năng mở rộng (scale) được khi có yêu cầu và đặc biệt đảm bảo tính chính xác, nhất quán của dữ liệu khi thực hiện sao chép ở phạm vi rộng. Đó là một vài trong rất nhiều các gạch đầu dòng cần phải làm cho các kỹ sư phần mềm khi “đụng” tới database.

Trong bài viết ngày hôm nay, mình sẽ cùng các bạn tìm hiểu về một giải pháp mới & khá thú vị của nền tảng điện toán đám mây Microsoft Azure có tên Azure Cosmos DB, một dịch vụ lữu trữ & quản lý database hỗ trợ nhiều data model (multi-model) & có khả năng scale ở phạm vi toàn cầu, giúp bạn nhanh chóng xây dựng được một giải pháp database trên cloud với tính ổn định cao.

Azure Cosmos DB là gì?

Tiền thân của Azure Cosmos DB là Azure DocumentDB, cũng một dịch vụ về NoSQL database của Microsoft Azure tuy nhiên chỉ hỗ trợ data model cũng chính là tên của dịch vụ này luôn: document. Tuy nhiên vào sự kiện //Build 2017, Microsoft chính thức công bố Azure Cosmos DB, thay thế cho Azure DocumentDB tuy nhiên không chỉ dừng lại ở những gì mà dịch vụ tiền nhiệm của nó hỗ trợ mà còn cung cấp những khả năng mới & cải tiến. Cùng tìm hiểu các đặc điểm nổi bật của Cosmos DB bên dưới!

3 data model & 4 API được hỗ trợ

Hỗ trợ thêm 2 data model là Graph và Key-Value với API tương tác dữ liệu tương ứng là Germlin và Tables (bản chất là Azure Table Storage) API, nâng tổng số data model là 3 và API là 4 tính đến thời điểm viết bài viết này.

API Data Model
SQL Document
MongoDB API Document
Tables API Key-Value
Gremlin Graph

Khả năng sao chép dữ liệu quy mô toàn cầu

Azure Cosmos DB có khả năng sao chép (replicate) toàn bộ dữ liệu trong database ra phạm vị toàn cầu với hơn 30 trung tâm lưu trữ dữ liệu (datacenter) của Microsoft Azure đặt tại hầu khắp các lục địa trên Thế giới.

Azure Cosmos DB cho phép replicate dữ liệu ra “không giới hạn” các khu vực có datacenter của Microsoft Azure ngoại trừ các khu vực bị giới hạn bởi rào cản địa lý hoặc luật pháp như Trung Quốc, Đức, …

Mỗi khu vực có dữ liệu trong Cosmos DB bao gồm khu vực được chọn ở lúc khởi tạo ban đầu cũng như các khu vực được chọn để replicate dữ liệu sẽ được gọi là node trong bài viết này.

Việc cấu hình replicate dữ liệu ra các khu vực khác được Azure Cosmos DB thực hiện khá nhanh chóng với khả năng đảm bảo tính sẵn sàng của dữ liệu ở các node mới trong vòng 30 phút với dung lượng dữ liệu lên tới 100 TB.

Các khu vực được chọn để replicate dữ liệu sẽ đóng vai trò là các read node, tức các node chỉ đóng vai trò xử lý query lấy dữ liệu. Mặc định, khu vực được chọn đầu tiên trong quá trình khởi tạo Cosmos DB đóng vai trò là write node, tức node vừa xử lý query thêm & cập nhật dữ liệu và vừa hỗ trợ xử lý query lấy dữ liệu như read node. Tuy nhiên, bạn hoàn toàn có thể thay đổi khu vực của write node sau đó. Thông tin này mình sẽ chia sẻ ở nội dung bên dưới.

Lưu ý: Database lưu trên Cosmos DB chỉ có duy nhất 1 write node tuy nhiên có thể có nhiều read node.

Với khả năng replicate dữ liệu phạm vi toàn cầu như vậy, ứng dụng kết nối tới Azure Cosmos DB sẽ có độ trễ (latency) rất thấp với 99% các thao tác với dữ liệu được đảm bảo ở mức dưới 10 ms cho đọc và 15 ms cho ghi. Azure Cosmos DB sẽ điều hướng các request tới khu vực có dữ liệu sao chép gần nhất.

Ngoài ra, với việc hỗ trợ replicate dữ liệu ở phạm vi toàn cầu, Cosmos DB cung cấp giải pháp “chống sụp đổ” dựa trên cơ chế chuyển đổi dự phòng (failover) cho hệ thống database lưu trữ trên đây khi xảy ra các sự cố. Khi xảy ra sự cố ở phạm vi khu vực lớn như mất điện toàn bộ datacenter hoặc phạm vi toàn quốc gia hoặc đa quốc gia (một sự cố rất rất hiếm khi xảy ra), Cosmos DB có khả năng xử lý tự động theo thứ tự ưu tiện hoặc xử lý “bằng cơm”.

Cơ chế xử lý failover của Cosmos DB như thế nào?

Lấy một ví dụ về một hệ thống database lưu trên Cosmos DB có write node đặt tại West US và được cấu hình replicate dữ liệu ra 3 read node là North Europe, East Asia và Australia South với biểu đồ biểu diễn sau:

Cơ chế xử lý failover tự động

Đối với cơ chế xử lý failover tự động, Cosmos DB sẽ xử lý riêng cho từng loại node.

Xử lý cho read node
Xử lý failover cho read node

Trong trường hợp một read node nào đó bị gặp sự cố với ví dụ cụ thể ở đây là node đặt tại North Europe, ngay lập tức Azure sẽ ngắt kết nối nó với write node đặt tại West US và thiết lập trạng thái offline cho read node đó. Sau đó, bằng giao thức chuyên biệt có tên “regional discovery protocol” (RDP) trong bộ Cosmos DB SDK,  Azure sẽ chuyển hướng tất cả các query lấy dữ liệu sang node kếtiếp được thiết lập trong danh sách PreferredLocations (chi tiết). Danh sách này có thể được thiết lập qua Cosmos DB SDK với cú pháp ví dụ bên dưới được viết bằng C# với mục đích thiết lập thêm 2 node đặt tại West US và North Europe vào danh sách PreferredLocations:

ConnectionPolicy connectionPolicy = new ConnectionPolicy 
{ 
 ConnectionMode = ConnectionMode.Direct,
 ConnectionProtocol = Protocol.Tcp
};

connectionPolicy.PreferredLocations.Add(LocationNames.WestUS); // Thêm node ở West US vào danh sách
connectionPolicy.PreferredLocations.Add(LocationNames.NorthEurope); // Thêm node ở North Europe vào danh sách

DocumentClient client = new DocumentClient(
 new Uri("ĐƯỜNG DẪN CỦA AZURE COSMOS DB"),
 "KEY TRUY CẬP CỦA AZURE COSMOS DB",
 connectionPolicy);

Trong trường hợp không có node nào được khai báo trong danh sách PreferredLocations, write node hiện tại sẽ được sử dụng làm read node. Quá trình failover này được thực hiện tự động bởi Azure và không cần bất cứ 1 hành động nào từ phía bạn cả.

Khi read node bị ảnh hưởng được khôi phục ví dụ là datacenter có điện trở lại, read node đó sẽ sync với write node hiện tại và sau đó khi sẵn sàng, nó sẽ được thiết lập lại về trạng thái online. Cosmos DB SDK cũng thông qua giao thức RDP, sẽ biết được khi có node mới online và sẽ kiểm tra xem node đó có trong danh sách PreferredLocations không. Trong trường hợp node mới nằm trong danh sách thì SDK sẽ kiểm tra hạng ưu tiên của node mới xem nó có cao hơn so với node hiện tại để thay thế làm read node không.

Xử lý cho write node
Xử lý failover cho write node

Tương tự với read node, write node đặt tại West US khi gặp sự cố sẽ được Azure thiết lập sang trạng thái offline. Sau đó, 1 trong các read node hiện tại sẽ được tự động lựa chọn để làm write node thay thế dựa vào thứ tự ưu tiên được bạn thiết lập trên portal của Cosmos DB (trong phần Replicate data globally\Automatic Failover) hoặc qua API.

Trong ví dụ ở đây thì node đặt tại North Europe sẽ được chọn làm write node thay thế theo thứ tự ưu tiên được thiết lập như hình bên dưới:

Thiết lập thứ tự ưu tiên trên portal

Khi sự cố được khắc phục, write node bị ảnh hưởng tức node đặt tại West US sẽ tiếp tục giữ ở trạng thái offline. Bạn cần phải thực hiện query tới node đó để tính toán các thay đổi được thực hiện trong khoảng thời gian gặp sự cố so với write node hiện tại tức node đặt tại North Europe. Sau đó, tùy theo yêu cầu của bạn, bạn thực hiện merge & giải quyết các conflict và cập nhật các thay đổi ngược trở lại write node hiện tại (đặt tại North Europe). Sau khi thực hiện merge & giải quyết các conflict hoàn tất, bạn có thể chuyển trạng thái của write node bị ảnh hưởng (West US) sang trạng thái online bằng một cách mà cá nhân mình thấy hơi bất tiện đó là gỡ node đó ra khỏi danh sách các node của Cosmos DB và sau đó thêm lại và thực hiện failover “bằng cơm” để cấu hình node đó (West US) là write node của database.

Cơ chế xử lý failover “bằng cơm”

Bằng cơm ở đây thực chất là được thực hiện bằng tay một cách thủ công :). Cơ chế xử lý failover bằng cơm này được xây dựng với mục đích chính là thay đổi write node hiện tại của database sang một node khác.

Bạn có thể thực hiện failover bằng cơm thông qua trang portal của Cosmos DB hoặc qua API.

Tương tự cơ chế xử lý trong failover tự động, khi thay đổi write node mới thành công, Cosmos DB SDK sẽ tự động xử lý thay đổi này và đảm bảo query write (cập nhật, thêm mới) được trỏ tới write node mới mà không cần bạn phải cập nhật lại code hay làm bất cứ điều gì khác cả.

5 cấp độ đảm bảo tính nhất quán của dữ liệu

Một trong những bài toán cần phải giải quyết khi thực hiện replicate dữ liệu đó là đảm bảo tính nhất quán của dữ liệu.

Azure Cosmos DB được bổ sung thêm một cấp độ đảm bảo tính nhất quán dữ liệu mới là Consistent Prefix, nâng tổng số lượng cấp độ nhất quán của dữ liệu được hỗ trợ lên là 5 tính đến thời điểm viết bài viết này và hiện là dịch vụ NoSQL database trên cloud cung cấp nhiều cấp độ đảm bảo tính nhất quán của dữ liệu nhất (AWS DynamoDB hiện chỉ hỗ trợ Strong & Eventual hay Google Cloud Spanner chỉ hỗ trợ Strong).

Với 5 cấp độ đảm bảo tính nhất quản của dữ liệu, bạn sẽ có nhiều lựa chọn hơn để lựa chọn một cấp độ phù hợp với bài toán của mình, cân bằng giữa 3 yếu tố trong định lý CAP (Consistency, Availability, Performance):

  • Consistency – Mức độ nhất quán của dữ liệu
  • Performance – Hiệu suất của việc truy suất dữ liệu
  • Availability – Tính sẵn sàng của dữ liệu

Dưới đây là bảng so sánh “tradeoff” của 5 cấp độ đảm bảo tính nhất quán của dữ liệu theo định lý CAP mà Cosmos DB hỗ trợ để các bạn có thể tham khảo khi lựa chọn một cấp độ cho database của mình.

Thang đánh giá sẽ đi từ Kém > Trung Bình > Trung Bình+ > Cao.

Cấp độ Mức độ nhất quán Hiệu suất Tính sẵn sàng
Strong Cao Kém Kém
Eventual Kém Cao Cao
Consistent Prefix Trung bình Trung bình+ Cao
Bounded Staleness Trung bình+ Trung bình Kém
Session Trung bình Trung bình+ Trung bình+

Hết phần 1

Phạm Dũng

Anh Phạm Dũng là chuyên gia các giải pháp phát triển công nghệ Microsoft, hiện đang làm tại FPT Software. Anh Dũng có 5 năm kinh nghiệm phát triển phần mềm, đặc biệt là trên các platform và sản phẩm của Microsoft. Đến với AzureVN.NET, anh Dũng hi vọng sẽ chia sẻ về các kinh nghiệm, thông tin về Microsoft Azure và hướng tiếp cận để phát triển trên nền tảng Azure.

lion-pham has 9 posts and counting.See all posts by lion-pham

Leave a Reply

Your email address will not be published. Required fields are marked *