Phân biệt các thuật ngữ trong Distributed System (Tập 2)

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

SCALABILITY – KHẢ NĂNG MỞ RỘNG

Scalability hay gọi tắt là scale là yếu tố đầu tiên mà architect sẽ consider khi thiết kế hệ thống. Làm sao để hệ thống sẽ scale được với kiến trúc và công nghệ đã chọn. Một hệ thống được gọi là có khả năng scale nếu có thiết kế để làm sao có thể add/remove thêm tính năng, module vào một cách dễ dàng, hay làm sao để có thể tiếp nhận một lượng lớn các request tăng đột biến do nhu cầu sử dụng của user tăng lên.

  Giải mã bí ẩn "system load" trên Linux
  Phân biệt các thuật ngữ trong Distributed System (Tập 1)

Về vấn đề thêm thắt module vào hệ thống, chúng ta có thể quay về với nguyên lý thiết kế Open-Closed trong SOLID, một hệ thống cần phải được thiết kế để có thể dễ dàng, open cho sự thay đổi mà vẫn close, không được đập đi làm lại. Ở mức độ coding thì có thể hiểu là sử dụng interface, abstract class để isolate, tách bạch detail implementation và các quy tắc, contract. Hoặc sử dụng các message queue để loose coupling giữa các components.

Còn về việc đáp ứng lưu lượng request lớn thì đòi hỏi system phải có các tính chất eslasticity, giúp co giãn kích thước hợp lý. Khi có nhiều request thì cần scale out hoặc scale up các component để tăng tải, còn khi nhàn rỗi thì lại scale in hoặc down để tiết kiệm chi phí. Hoặc áp dụng các kỹ thuật caching, CQRS, non-blocking để tăng performance

RESILIENCY – KHẢ NĂNG PHỤC HỒI

Resiliency cũng là một yếu tố để bảo đảm tính Reliability của hệ thống. Resiliency đề cập đến các kỹ thuật để giúp khắc phục các lỗi trong quá trình vận hành. Một số kỹ thuật được nhắc đến như health check, monitoring và self healing (tự chữa bệnh, một component tự nhiên lăn ra chết thì phải tự mà sống dậy), circuit breaker and retry (bộ ngắt mạch, để tránh xảy ra sự cố dây chuyền), fail-over (chuyển sang node khác để tiếp tục vận hành)

Dự phòng và khả năng phục hồi thường bị nhầm lẫn với nhau. Tuy cả hai đều có liên quan với nhau nhưng chúng không thể hoán đổi cho nhau. Dự phòng có thể hiểu là việc thực hiện để ngăn chặn thất bại, ngụ ý rằng nó sẽ xảy ra trước khi một vấn đề xảy ra. Khả năng phục hồi liên quan đến việc tìm giải pháp sau khi một vấn đề đã xảy ra. Tóm lại, dự phòng là trước khi vấn đề xảy ra, ngược lại phục hồi là sau khi vấn đề xảy ra.

Ví dụ, cơ sở dữ liệu dự phòng với khả năng replication có thể được tận dụng. Nhiều thành phần và bản sao của dữ liệu tạo ra một redundant design. Nếu primary side của cặp cơ sở dữ liệu không thành công, primary side sẽ đẩy mạnh đến primary và bắt đầu nhận tải trong lúc bên failed side tự sửa lỗi. Chức năng failover và self-healing chính là khả năng phục hồi. Cả hai đều có liên quan, nhưng không thể hoán đổi cho nhau.

DISASTER RECOVERY – KHÔI PHỤC SAU THẢM HỌA

Disaster recovery cũng giống như Resiliency đều là những phương pháp để khắc phục lỗi, nhưng khác ở chỗ Resiliency chỉ giải quyết các vấn đề về vận hành và lỗi ứng dụng, hoặc sự cố cục bộ. Còn disaster recovery nó ở đẳng cấp khác, đẳng cấp của thảm họa như động đất, sóng thần, bom đạn. Rõ ràng không ai muốn có thảm họa xảy ra. Tuy nhiên trong thực tế, đã có case như vậy, đơn cử là vụ sập điện tại bang Virginia của Mỹ khiến do bão gây ra khiến cho các data center của AWS ở đó sập hoàn toàn, trên phạm vi toàn region, khiến rất nhiều website sử dụng dịch vụ này bao gồm Pinterest, Netfilx, Heroku… “tắt điện” nhiều giờ liền.

Thật ra thì mình cũng chưa đạt đến tầm phải consider đến các thảm họa khi thiết kế hệ thống, vì chi phí cho việc dự phòng rủi ro thảm họa là không nhỏ. Bạn phải deploy, backup các server ở nhiều region địa lý khác nhau để khi 1 region sập thì có thể fail-over sang region khác. Thôi thì đợi có deal to như của Netflix rồi tính cũng không muộn, chứ Multi-AZ cũng đủ xài đối với đa số hệ thống.

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev