LỜI NÓI ĐẦU

Chào mọi người, chúng ta lại gặp nhau vào những ngày dịp cận Tết cuối năm 2022 và bài viết hôm nay mình sẽ quay lại nội dung chia sẻ kiến thức – kinh nghiệm trong quá trình làm việc. Với những ai chưa biết thì các bài viết của mình sẽ xoay quanh chủ đề liên quan đến các lĩnh vực Backend, Blockchain cũng như DevOps, hi vọng thông qua việc chia sẻ kiến thức đến cộng đồng mình cũng sẽ nhận về các ý kiến đóng góp để cải thiện kỹ năng và nâng cao trình độ trong lĩnh vực chuyên môn, cũng như sẽ có các bài viết đan xen tâm sự chuyện nghề chuyện đời dưới góc nhìn cá nhân.

CHỦ ĐỀ

Bài viết hôm nay mình mang đến cho mọi người một góc nhìn tổng quát của bản thân trong vấn đề thiết kế hệ thống. Dường như cũng là một bài viết để tổng hợp và nhìn lại trong năm vừa rồi những kiến thức về hệ thống mà mình đã thu nạp và tích luỹ. Hi vọng thông qua bài viết mọi người sẽ có được một tư duy mở để tự có câu trả lời phù hợp cho câu hỏi:

Làm sao để thiết kế hệ thống đáp ứng High Availability? (sẵn sàng cao)

KIẾN THỨC NỀN TẢNG

Trước khi bắt đầu nội dung bài viết, để có chất lượng truyền tải thông tin hiệu quả nhất mình khuyến nghị mọi người nên có trước một số kiến thức cơ bản về:

• Cách website hoạt động [https://viblo.asia/p/lam-gi-khi-website-truy-cap-cham-cau-tra-loi-tuong-de-nhung-that-ra-khong-he-de-ByEZkeLY5Q0] (tác giả Cao Phuc)

• Cache đa tầng [https://blog.bytebytego.com/p/ep-38-where-do-we-cache-data] (tác giả Alex Xu)

Và bây giờ nếu đã tự tin với một số kiến thức cơ bản, chúng ta đã có thể bắt tay vào việc tìm hiểu cách để thiết kế một hệ thống High Availability (HA) sao cho HA nhất có thể.

Hệ thống High Available

What?

Hệ thống High Aviability là gì?

• Là hệ thống có tính sẵn sàng cao, hoạt động liên tục 24/7 trong mọi điều kiện: sập server, động đất, sóng thần, chiến tranh hạt nhân, người ngoài hành tinh đổ bộ… đảm bảo thời gian downtime (bất hoạt) trong năm rơi vào con số vài trăm thậm chí chỉ vài chục miliseconds.

Why?

Tại sao phải tốn nhiều công sức làm việc này?

• Nếu tầm ảnh hưởng website của bạn rơi vào con số hàng trăm hàng triệu users thì đôi khi chỉ vài giây mất ngắt kết nối mức độ thiệt hại cho users cũng như chính nhà cung cấp dịch vụ đó là không thể tưởng tượng.
• Nếu mọi người chưa biết thì hình như vừa qua có sự cố từ nhà mạng Em Mờ nào đó cách đây mấy tuần đột ngột mất kết nối suốt buổi chiều đã có thể ảnh hưởng đến túi tiền và nồi cơm của không ít khách hàng khi bao nhiêu hợp đồng và vấn đề quan trọng không thể kịp xử lý (?!) (Lưu ý thông tin chưa được người viết kiểm chứng)

How?

Triển khai như thế nào giờ nhỉ?

• Sau khi đã xác định được mục tiêu thì bắt tay vào triển ngay và luôn. Và sẽ triển từ đâu và triển như thế nào chúng ta cùng quan sát và phân tích sơ đồ thiết kế dưới đây:

Trong mô hình trên, ngoại trừ Clients (có thể áp dụng local cache) mình sẽ phân tách thành 5 tầng của hệ thống bao gồm:

• DNS Layer
• Load Balancer Layer
• Services Layer
• Database Layer

Và bạn đã nhận ra nguyên tắc cốt lõi và mấu chốt trong mô hình thiết kế này chưa nào? Key word để giải quyết tính HA đơn giản chỉ cần hạn chế điểm chịu lỗi duy nhất trong toàn bộ hệ thống. Ở các hệ thống tập trung, mỗi tầng chúng ta thường có một điểm chịu lỗi duy nhất, và việc áp dụng Load Balancer hoàn toàn có thể triển khai trên nhiều tầng chứ không riêng gì chỉ ở tầng Services như chúng ta thường thấy.

Where?

Load Balancer có thể đặt ở đâu?

Sau khi đã có câu trả lời, bây giờ chúng ta cùng đi sâu và phân tách từng lớp cụ thể.

DNS Layer

Ở lớp Domain Name System, chúng ta có thể đặt một Load Balancer trỏ domain, sub-domain đến các nhà cung cấp dịch vụ Server khác nhau như: Digital Ocean, AWS, Azure, GCP,…

DNS mà mình thường hay sử dụng là Cloudfare, tất nhiên đây cũng là một điểm chịu lỗi mọi người có thể tìm hiểu và sử dụng kết hợp các dich vụ DNS khác nhau.

Việc lựa chọn các nhà cung cấp dịch vụ Virtual Machines cũng là một bài toán cần cân nhắc khi mà các máy chủ vật lý thực sự sẽ được phân bố khắp nơi trên thế giới. Tuỳ vào khu vực thị trường sẽ cần phải lựa chọn vị trí phù hợp để giảm thiểu độ trễ cũng như rủi ro cho hệ thống.
Ở khu vựa Đông Nam Á, đa số các máy chủ sẽ thường được đặt ở Singapore và số ít ở Taiwan.

Load Balancer Layer

Sau khi đã trỏ vào 1 máy server, chúng ta có thể tiếp tục sử dụng lớp balancer để phân bổ request đến các cụm server khác nhau. Dịch vụ load balancer phổ biến hiện nay mọi người có thể tham khảo và tìm hiểu Nginx, tương tự đây cũng có thể là một điểm chịu lỗi do đó ta có thể set up mô hình Master-Salve cho Load Balancer thông qua dịch vụ Nginx Plus.

Services Layer

Tiếp theo đến lớp Services, đây thường là nơi phổ biến và chủ yếu chúng ta sẽ tiến hành clone nhiều services cùng chạy và xử lý request. Hiện nay có nhiều công cụ và cách tiếp cận khác nhau ở tầng này mà mọi người có thể cân nhắc và lựa chọn phù hợp từ cơ bản đến nâng cao như:
pm2, docker-swarm, kubernetes,…

Trong mô hình, bên dưới mình đang sử dụng swarm mode của docker để triển khai nhiều services cùng xử lý.

Database Layer

Tầng dưới cùng là Database, nơi mà chúng ta có thể tránh tình trạng “một điểm lỗi” bằng cách clone nhiều DB bằng cách triển khai mô hình Load Balancer tương tự. Đối với MongoDB mình sẽ tiếp cận bằng 2 phương pháp đó là Replication và Sharding. Về chi tiết thiết kế, cấu hình và triển khai mô hình MongoDB đáp ứng tính HA cũng như CQRS pattern mình sẽ gửi đến các bạn trong một bài viết khác đầy đủ hơn trong tương lai.

Lời kết

Hi vọng thông qua bài viết, mọi người sẽ có cái nhìn tổng quan trong việc thiết kế hệ thống High availability và cách tiếp cận hoàn toàn có thể can thiệp ở mọi layer khác nhau. Đối với các hệ thống truyền thống tập trung việc hạn chế downtime dường như chỉ có thể cải thiện và bất khả thi để giải quyết triệt để (downtime~0). Từ đó, đối với các hệ thống phân tán phi tập trung hiện đại như Blockchain cũng sẽ là chìa khoá để mở ra một hướng đi tiềm năng trong lĩnh vực Web 3.0

Tất nhiên, để tránh tình trạng Overtech mà dân gian hay gọi dùng dao mổ trâu chặt thịt gà chúng ta cần phải cân nhắc và lựa chọn phù hợp với nhu cầu của từng hệ thống. Việc áp dụng một hạ tầng HA khổng lồ sẽ mang đến nhiều khó khăn và chi phí trong việc quản lý và vận hành nếu như nhu cầu sử dụng chưa thực sự cần tới. Tuy nhiên, việc cần có một tư duy mở là vấn đề quan trọng để từ đó có đủ cơ sở và kiến thức để cân nhắc, lựa chọn phương án tối ưu nhằm tiết kiệm khá nhiều thời gian và công sức chỉ để dành làm việc nên làm.

Mình cũng xin nhắc lại, tất cả các nội dung truyền tải trong bài viết đều xuất phát từ kiến thức và kinh nghiệm cá nhân vì vậy không thể tránh khỏi thiếu sót, mọi người chỉ nên tham khảo và có thể để lại các góp ý cho thiếu sót còn tồn đọng của mình. Nếu cảm thấy bài viết hữu ích xin để lại một upvote và comment góc nhìn cũng như các góp ý bên dưới. Chúc mọi người năm mới 2023 vui vẻ và đón đọc các bài viết khác của mình trong tương lai nhé!

░░░░░░░░░▄░░░░░░░░░░░░░░▄░░░░
░░░░░░░░▌▒█░░░░░░░░░░░▄▀▒▌░░░
░░░░░░░░▌▒▒█░░░░░░░░▄▀▒▒▒▐░░░
░░░░░░░▐▄▀▒▒▀▀▀▀▄▄▄▀▒▒▒▒▒▐░░░
░░░░░▄▄▀▒░▒▒▒▒▒▒▒▒▒█▒▒▄█▒▐░░░
░░░▄▀▒▒▒░░░▒▒▒░░░▒▒▒▀██▀▒▌░░░
░░▐▒▒▒▄▄▒▒▒▒░░░▒▒▒▒▒▒▒▀▄▒▒▌░░
░░▌░░▌█▀▒▒▒▒▒▄▀█▄▒▒▒▒▒▒▒█▒▐░░
░▐░░░▒▒▒▒▒▒▒▒▌██▀▒▒░░░▒▒▒▀▄▌░
░▌░▒▄██▄▒▒▒▒▒▒▒▒▒░░░░░░▒▒▒▒▌░
▀▒▀▐▄█▄█▌▄░▀▒▒░░░░░░░░░░▒▒▒▐░
▐▒▒▐▀▐▀▒░▄▄▒▄▒▒▒▒▒▒░▒░▒░▒▒▒▒▌
▐▒▒▒▀▀▄▄▒▒▒▄▒▒▒▒▒▒▒▒░▒░▒░▒▒▐░
░▌▒▒▒▒▒▒▀▀▀▒▒▒▒▒▒░▒░▒░▒░▒▒▒▌░
░▐▒▒▒▒▒▒▒▒▒▒▒▒▒▒░▒░▒░▒▒▄▒▒▐░░
░░▀▄▒▒▒▒▒▒▒▒▒▒▒░▒░▒░▒▄▒▒▒▒▌░░
░░░░▀▄▒▒▒▒▒▒▒▒▒▒▄▄▄▀▒▒▒▒▄▀░░░
░░░░░░▀▄▄▄▄▄▄▀▀▀▒▒▒▒▒▄▄▀░░░░░
░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▀▀░░░░░░░░