Tìm hiểu cách thức các đại gia công nghệ quản lý dữ liệu - Phần 2: Amazon

Tuy vậy, do dịch vụ chủ đạo của 2 hãng có khác biệt rất lớn (tìm kiếm vs bán lẻ), cách mà Dynamo và GFS “đối đãi” với dữ liệu cũng rất khác nhau. Hệ thống bán lẻ của Amazon cần cung cấp mọi thông tin sẵn có về một sản phẩm mà khách hàng yêu cầu, cũng như hiển thị mọi thông tin liên quan đến giao dịch như địa chỉ giao hàng, thông tin thanh toán.v.v. ngay trên môi trường web mà khách hàng đang thao tác. 

Với những yêu cầu này, việc chỉ chú trọng đọc dữ liệu theo từng khối như GFS chắc chắn là không phù hợp, thay vào đó Dynamo cần đảm cho phép các ứng dụng web truy cập ngẫu nhiên đến từng file nhỏ nhất trên hệ thống trong mọi thời điểm. Tại hội nghị về nguyên lý hệ điều hành hồi tháng 10/2007, Vogel và nhóm kỹ sư của mình cho biết “Dynamo hướng đến việc quản lý các đối tượng dữ liệu rất nhỏ - thường có dung lượng chỉ dưới 1MB”.

Hơn thế nữa, thay vì được tối ưu phục vụ việc đọc dữ liệu, Dynamo luôn luôn ở trạng thái sẵn sàng để nhận các dữ liệu mới – nói cách khác là hướng tới việc cho phép các ứng dụng bên ngoài ghi dữ liệu bất cứ khi nào cần. Trái ngược hoàn toàn với GFS của Google trên đó các ứng dụng bên ngoài thường xuyên cần đọc dữ liệu để phân tích kết quả tìm kiếm cho người dùng. Như nhóm nhóm kỹ sư của Vogel đã viết trong buổi hội thảo “Trên đa số các dịch vụ của Amazon, việc chậm cập nhật thông tin mà người dùng nhập vào sẽ khiến chất lượng dịch vụ giảm đi rất nhiều trong mắt khách hàng. Ví dụ, tình trạng giỏ hàng của khách hàng cần được cập nhật chính xác mỗi khi học thực hiện bổ sung hoặc loại bỏ một sản phẩm trong đó, thậm chí ngay cả khi hệ thống server đang gặp trục trặc.”

Cách xử lý tính nhất quán của dữ liệu trên đây cũng có nét đặc biệt: quá trình kiểm tra tính nhất quán và đồng bộ dữ liệu sẽ chỉ được thực hiện khi phần dữ liệu đó được đọc ra, chứ không phải ngay khi ghi vào. Với cách tiếp cận này, mọi thao tác ghi của các ứng dụng sẽ không bao giờ bị từ chối (ít nhất là không bị từ chối vì các lý do về mặt đồng bộ), bất kể đó là thao tác ghi để bổ sung dữ liệu mới, hay ghi đè/thay đổi dữ liệu cũ.


Về giải pháp phân phối dữ liệu trên các thiết bị lưu trữ, do trước đó đã không ít lần phải dỡ khóc dở cười với phương pháp quản trị tập trung mỗi khi server quản trị (master) gặp sự cố, các kỹ sư của Amazon đã quyết định chuyển sang các phương pháp phân tán. Cũng đồng thời để tăng sự thuận tiện mỗi khi cần mở rộng hệ thống (số lượng dịch vụ mà Amazon bổ sung hàng năm vẫn đang tăng một cách chóng mặt). Hoàn toàn trái ngược với GFS, có thể nói hệ thống Dynamo mang nhiều nét của mô hình mạng ngang hàng peer-to-peer, thay vì dạng master-slave.

Dữ liệu của từng cụm lưu trữ của Dynamo được quản lý trên một vòng không gian địa chỉ, và mỗi đơn vị lưu trữ (bài viết gốc không nói rõ mỗi đơn vị này là ổ cứng, HDD stage rack hay server như Google) sẽ chịu trách nhiệm cho một phần của vòng không gian đó. Để dễ hình dung, hãy tưởng tượng không gian địa chỉ này là một chiếc hộp tròn được chia ngăn theo dạng các lát cắt bánh để cất đồ, và mỗi đơn vị lưu trữ kể trên là một ngăn trong đó. 

Nếu bạn đã từng đọc qua hay xem hình ảnh về cấu trúc phiến đĩa HDD, cũng có thể nói nôm na đây là một đĩa cứng khổng lỗ trong đó dữ liệu được ghi theo từng sector hình học (Geometrical sector). Đồng thời, để đảm bảo gánh nặng công việc được phân chia một cách hợp lý giữa các đơn vị lưu trữ (từ đây sẽ gọi là node) cũ và mới; Amazon đã thiết kế để một node vật lý có thể được chia làm nhiều node ảo, cùng lúc đảm nhiệm vị trí trên nhiều cụm. Đến đây dường như ta đã có thể phần nào kết luận các node này là các server, tương tự GFS. Cũng tương tự như việc một nhân viên giỏi, năng động có thể cùng lúc nhận việc trong nhiều nhóm để tận dụng được hết năng lực.

Mỗi khi một node  mới được bổ sung vào “bàn tròn” này, nó sẽ được cấp một giá trị đại diện cho vị trí, thứ tự của nó trong đó và sẽ bắt đầu chịu trách nhiệm cho một phần không gian nhớ. Các node có vị trí “bên cạnh” node mới đó sẽ phải co giãn đôi chút để điều chỉnh cho phù hợp. Cần nhớ rằng: mỗi node chịu trách nhiệm quản lý cho một lát cắt của không gian địa chỉ, còn dữ liệu trên các lát cắt riêng biệt vẫn có thể được sao lưu cho nhau – nếu không thì khả năng sao lưu, chịu lỗi của hệ thông Dynamo này sẽ chỉ là con số không to tướng. Nếu bạn chưa hiểu ý nghĩa của điều này, hãy nhìn vào hình minh họa của Amazon và xem tiếp giải thích về cơ chế ghi dữ liệu của Dynamo phía dưới:

Khi có yêu cầu “ghi” một đối tượng dữ liệu (một đoạn lời bình, hay một file hình ảnh.v.v.) vào hệ thống Dynamo, hệ thống sẽ gán cho nó một (khóa) key riêng biệt. Khóa này lại tiếp tục được sử dụng để sinh một chuỗi MD5 128-bit độc nhất, giá trị của chuỗi MD5 sẽ được dùng để xác định vị trí (hay đúng hơn là địa chỉ) mà dữ liệu đó sẽ được ghi trên vòng không gian nói trên. Đến đây, node chịu trách nhiệm cho vị trí đó sẽ làm mọi phần việc còn lại: cho phép thao tác “ghi” đó được tiến hành trên bản thân nó, đồng thời nhắc nhở các node xung quanh nó trong cụm chấp nhận thao tác ghi này (việc các node khác có lập tức chấp nhận hay không còn phụ thuộc vào tình trạng của chúng trong thời điểm đó). Như vậy dữ liệu sẽ được trải đều trên miếng bánh. Môĩ khi có sự cố xảy ra với một node, 2 người hàng xóm bên cạnh nó sẽ ngay lập tức nhận trách nhiệm cho phần địa chỉ mà node đó đang quản lý.

Lại nói tiếp về quá trình kiểm tra đọc dữ liệu từ Dynamo. Khi có yêu cầu “đọc” dữ liệu từ các ứng dụng bên ngoài, các thiết bị quản lý request (tương tự GFS client) trong hệ thống Dynamo sẽ gọi để kiểm tra xem node nào có chứa dữ liệu đó. Tất cả các node có chứa một bản sao của dữ liệu đó sẽ phản hồi, dĩ nhiên là kèm theo cả thông tin về “phiên bản” của dữ liệu mà chúng lưu. 

Tùy theo tính chất từng loại request, thiết bị quản lý request (request handler) sẽ có cách xử lý khác nhau với các phản hồi này. Nếu dữ liệu đang được yêu cầu thuộc vào loại “có là được”, không cần quá chính xác (ví dụ như các file icon hình ảnh phục vụ giao diện), node đầu tiên trả lời sẽ lập tức được đưa vào sử dụng. Ngược lại mếu ứng dụng đang yêu cầu đọc thuộc vào nhóm cần dữ liệu mới nhất, chính xác nhất (ví dụ như ứng dụng quản lý giỏ hàng), request handler sẽ chờ tất cả các node phản hồi để đảm bảo tìm được ứng cử viên phù hợp nhất. 

Ngoài ra, để đảm bảo đồng bộ dữ liệu, mỗi khi nhận được phản hồi từ nhiều node cho cùng một đối tượng dữ liệu, request handler sẽ ghép các thay đổi không xung khắc trên đó (ví dụ như thay đổi trên dòng 13 từ node A, thay đổi trên dòng 15 từ node B của cùng một file text sẽ được ghép vào với nhau); hoặc sẽ thông báo cho các node chứa dữ liệu với “phiên bản” quá cũ biết rằng nó cần cập nhật file đó từ đâu . Mỗi khi một node được thay thế bởi một thiết bị mới hơn, nó sẽ được ưu tiên cập nhật dữ liệu mới nhất từ các hàng xóm xung quanh.

Mô hình này đã được thực tế chứng minh là có khả năng hoạt động ổn định trong phần lớn các trường hợp, kể cả khi xảy ra trục trặc nho nhỏ trong hệ thống. Lần trục trặc duy nhất là vào tháng 8/2011 khi mà một số kỹ sư mạng của Amazon khi nâng cấp router đã sai sót khi chuyển hướng lưu lượng mạng để nâng cấp router. Lưu lượng cho việc sao chép dữ liệu của các node trong mô hình này là cực lớn, và sai sót khi chuyển hướng dòng chảy khổng lồ này vào một số thiết bị mạng yếu vốn chỉ dùng để phục vụ việc “bắt tay” giữa các node đã khiến toàn bộ các website của Amazon gặp trục trặc trong một thời gian ngắn. Nói chung, tuy Dynamo là một mô hình hiệu quả và đã tạo cảm hứng cho rất nhiều mô hình dữ liệu khác như Cassandra của facebook, đây không phải là một kiến trúc mà các datacenter hạng vừa, với nguồn lực tài chính, thiết bị cũng như nhân sự yếu kém có thể mơ đến.