Với một hệ thống có lượng truy cập lớn không chỉ trong phạm vi khu vực mà còn ở phạm vi toàn cầu, làm thế nào để xây dựng được một kiến trúc cho hệ thống đó với khả năng chịu tải lớn cũng như đáp ứng được tốc độ phản hồi nhanh là một bài toán không hề dễ cho các kiến trúc sư phần mềm khi thiết kế giải pháp cho hệ thống trên. Hướng tiếp cận có vẻ truyền thống nhưng lại khá hiệu quả đó là phân tán hệ thống nói trên ra các datacenter đặt ở các khu vực hoặc ở gần các khu vực có lượng truy cập lớn (gọi là các node) và xây dựng bộ điều hướng để điều hướng truy cập của người dùng vào các node gần nhất hoặc có đỗ trễ mạng thấp nhất với họ, từ đó đảm bảo được tốc độ phản hồi nhanh từ hệ thống tới người truy cập cũng như giảm tải được cho toàn bộ hệ thống nói chung (khi toàn bộ lưu lượng truy cập không đổ dồn vào một node duy nhất). Đây cũng là một trong những kỹ thuật cơ bản được sử dụng để xây dựng các hệ thống áp dụng mô hình distributed system. Tuy nhiên để làm được điều này không hẳn các công ty, tổ chức đều có thể có đủ kinh phí cũng như kỹ thuật để làm được.
Trong bài viết ngày hôm nay mình sẽ chia sẻ với các bạn về một dịch vụ trên Azure có tên Azure Traffic Manager, cho phép bạn có thể kiểm soát quá trình kết nối tới hệ thống của mình thông qua việc xây dựng ra các cấu hình điều hướng truy cập (traffic), hay còn được gọi là Traffic Manager profile.
Azure Traffic Manager là gì?
Như cái tên gọi của nó, về cơ bản Azure Traffic Manager cho phép bạn kiểm soát được việc phân phối truy cập của người dùng tới các endpoint của hệ thống đặt ở nhiều datacenter khác nhau dựa vào các phương thức điều hướng truy cập (traffic-routing method) được Azure Traffic Manager cung cấp cũng như dựa vào tình trạng “sức khỏe” của các endpoint.
Với khả năng theo dõi tình trạng sức khỏe của các endpoint, Azure Traffic Manager còn giúp giải quyết bài toán xử lý khi có sụp đổ xảy ra ở một endpoint nào đấy trong hệ thống (failover), đảm bảo truy cập của người sử dụng hệ thống không bị gián đoạn khi có sự cố xảy ra.
Mặc dù là một giải pháp của Azure, ngoài hỗ trợ các dịch vụ như Azure App Service, Azure Virtual Machine hay Azure Cloud Services, Azure Traffic Manager còn hỗ trợ cho các endpoint của hệ thống được xây dựng không sử dụng dịch vụ của Azure, cho phép bạn có thể tích hợp Azure Traffic Manager vào một hệ thống có sẵn ở on-premises hay ở các cloud provider khác như AWS hay IBM.
Azure Traffic Manager hoạt động như thế nào?
Azure Traffic Manager dựa hoàn toàn vào DNS để thực hiện điều hướng truy cập của người sử dụng tới một endpoint phù hợp nhất. Khi có một yêu cầu truy cập tới một hệ thống nào đó, phía client (có thể là web browser hay một application) sẽ cần phải thực hiện chuyển đổi DNS name của hệ thống thành một địa chỉ IP cụ thể rồi từ đó thực hiện truy cập tới IP đó để truy cập vào hệ thống. Dựa vào các các quy tắc được định nghĩa trong phương thức điều hướng được lựa chọn cũng như tình trạng sức khỏe của các endpoint của hệ thống, từ đó Azure Traffic Manager sẽ điều hướng truy cập của người sử dụng tới IP của endpoint phù hợp.
Ví dụ
Mình có một hệ thống ở đây là một trang blog cá nhân của mình có DNS name là blog.lionpham.com. Ngoài Việt Nam, hệ thống của mình còn có lượng truy cập lớn & đều đặn từ Mỹ, Anh và Ấn Độ nên mình đã tạo ra 4 endpoint sử dụng dịch vụ Azure Web App đặt tại 4 vị trí khác nhau là Southeast Asia, West US, North Europe và Central India. Mỗi endpoint này đều có 1 IP cụ thể riêng và mình đã thiết lập A record cho từng endpoint với giá trị DNS name tương ứng là:
DNS Name | Region |
blog-asia.lionpham.com | Southeast Asia |
blog-us.lionpham.com | West US |
blog-uk.lionpham.com | North Europe |
blog-india.lionpham.com | Central India |
Khi tạo Traffic Manager profile, Azure sẽ cung cấp cho mình một DNS name của dịch vụ, lấy ví dụ ở đây là lionpham.trafficmanager.net. Để các truy cập tới hệ thống được xử lý điều hướng bởi Azure Traffic Manager, mình thực hiện thiết lập CNAME record cho DNS name của hệ thống với giá trị là DNS name của Traffic Manager profile được tạo.
DNS Name | CNAME |
blog.lionpham.com | lionpham.trafficmanager.net |
Quá trình xử lý điều hướng truy cập của Azure Traffic Manager được mô tả theo sơ đồ sau:
- Khi người dùng sử dùng trình duyệt để gửi yêu cầu truy cập vào hệ thống qua với DNS name là blog.lionpham.com, DNS service sẽ thực hiện dịch giá trị DNS name thành địa chỉ IP của máy chủ của hệ thống cần kết nối.
- Để dịch giá trị DNS name thành địa chỉ IP, DNS service sẽ tìm và thực hiện kết nối tới DNS name server của lionpham.com để truy vấn DNS record cho blog.lionpham.com, ở đây một bản ghi CNAME với giá trị miêu tả blog.lionpham.com là alias của lionpham.trafficmanager.net.
- DNS Service tiếp tục thực hiện kết nối tới DNS name server của trafficmanager.net để truy vấn DNS record cho lionpham.trafficmanager.net. Ở đây, DNS name server của trafficmanager.net chính là Azure Traffic Manager.
- Khi Azure Traffic Manager nhận được yêu cầu truy vấn DNS từ DNS service, dịch vụ này sẽ dựa vào phương thức điều hướng truy cập được cấu hình trong Traffic Manager profile có DNS name là lionpham.trafficmanager.net kết hợp với thông tin về trạng thái, tình trạng sức khỏe của các endpoint từ đó đưa ra được một DNS record của endpoint phù hợp.
- Do truy cập được thực hiện từ Việt Nam, và giả định cả 4 endpoint của hệ thống đều hoạt động ổn định và phương thức điều hướng được sử dụng là Performance, Azure Traffic Manager lúc này dựa vào dữ liệu độ trễ mạng và chọn endpoint đặt ở Southeast Asia là endpoint phù hợp nhất và trả về một CNAME record với giá trị là blog-asia.lionpham.com.
- Khi DNS service nhận được kết quả trả về từ DNS name server của trafficmanager.net với một CNAME record miêu tả lionpham.trafficmanager.net là alias của blog-asia.lionpham.com, DNS service tiếp tục thực hiện kết nối tới DNS name server của lionpham.com để truy vấn DNS record cho blog-asia.lionpham.com và ở đây một A record với giá trị địa chỉ IP của endpoint blog-asia.lionpham.com. Sau khi lấy được A record, DNS service phản hồi lại về cho trình duyệt với địa chỉ IP được dịch từ DNS name blog.lionpham.com.
- Trình duyệt của người truy cập thực hiện kết nối trực tiếp tới endpoint blog-asia.lionpham.com với IP nhận được.
Như vậy với quá trình xử lý điều hướng ở trên, bạn có thể thấy Azure Traffic Manager chỉ đơn giản là nhận truy vấn DNS và trả về DNS record của endpoint phù hợp. Việc kết nối tới endpoint về sau được thực hiện trực tiếp giữa client (ở ví dụ trên là trình duyệt web) với endpoint được chọn. Azure Traffic Manager sẽ không nắm được thông tin dữ liệu được trao đổi giữa client và endpoint.
Các phương thức điều hướng truy cập (traffic-routing method)
Để điều hướng truy cập, Azure Traffic Manager cung cấp các phương thức điều hướng linh hoạt cho từng nhu cầu sử dụng. Có 4 phương thức điều hướng hiện được Azure Traffic Manager hỗ trợ:
- Priority – Điều hướng truy cập theo trọng số ưu tiên
- Weighted – Điều hướng truy cập ngẫu nhiên dựa vào trọng số
- Performance:- Điều hướng truy cập vào endpoint ở vị trí có độ trễ thấp nhất
- Geographic – Điều hướng truy cập vào endpoint ở vị trí địa lý gần nhất
Phương thức điều hướng Priority
Đây là phương thức điều hướng mà Azure Traffic Manager sẽ điều hướng toàn bộ truy cập vào 1 endpoint chính và sử dụng các endpoint còn lại làm endpoint dự phòng.
Để phân biệt endpoint nào là endpoint chính và các endpoint nào là endpoint dự phòng, khi thiết lập endpoint, bạn đánh trọng số ưu tiên cho endpoint trong trường Priority với giá trị từ 1 tới 1000 (giá trị mặc định là thứ tự của endpoint được thêm vào). Azure Traffic Manager sẽ dựa vào endpoint nào có trọng số thấp nhất đặt làm endpoint chính và các endpoint có trọng số cao hơn sẽ là endpoint dự phòng.
Phương thức Priority được sử dụng trong các bài toán yêu cầu có giải pháp để xử lý đảm bảo hệ thống hoạt động ổn định trong trường hợp xảy ra sụp đổ ở một node nào đấy của hệ thống.
Phương thức điều hướng Weighted
Phương thức Weighted cho phép phân tải truy cập tới các endpoint của hệ thống một cách ngẫu nhiên dựa vào trọng số được đánh cho mỗi endpoint.
Tương tự với Priority, khi thiết lập endpoint, bạn đánh trọng số cho endpoint với giá trị từ 1 đến 1000 vào trường Weight (giá trị mặc định là 1). Azure Traffic Manager sẽ tính toán dựa vào trọng số được đánh để chọn ra endpoint phù hợp. Với endpoint có trong số cao hơn, xác suất để Azure Traffic Manager điều hướng truy cập tới endpoint đấy sẽ cao hơn và ngược lại với các endpoint có trọng số thấp. Trong trường hợp trọng số của các endpoint giống nhau, Azure Traffic Manager sẽ đánh bằng tỷ lệ nhận được điều hướng truy cập cho các endpoint.
Phương thức Weighted thường được sử dụng trong các bài toán như:
- Production test tính năng mới của ứng dụng như trang web với giao diện mới hoặc phiên bản nâng cấp hiệu năng của web API: Trong trường hợp này, bài toán đặt ra là làm sao có thể thực hiện production test cho tính năng mới mà vẫn đảm bảo ứng dụng hoạt động ổn định. Nếu điều hướng toàn bộ truy cập tới phiên bản mới thì quá rủi ro vì không đảm bảo được 100% phiên bản mới sẽ hoạt động ổn định. Giải pháp đưa ra là điều hướng 1 lượng nhỏ truy cập tới phiên bản mới trong khi vẫn giữ được lượng lớn truy cập tới phiên bản hiện tại của ứng dụng. Thực hiện phương pháp này với Azure Traffic Manager bằng cách tạo mới endpoint cho phiên bản mới và đánh trọng số dựa vào % tải của truy cập mà bạn muốn điều hướng tới phiên bản mới này.
Phương thức điều hướng Performance
Microsoft thu thập thông tin độ trễ mạng giữa các dải IP tới các datacenter của họ từ đó xây dựng một bảng có tên Internet Latency Table để lưu thông tin tốc độ truy cập 2 chiều giữa các địa chỉ IP tới datacenter của Azure. Dựa vào Internet Latency Table, khi có một truy vấn DNS gửi tới, Azure Traffic Manager sẽ đối chiếu IP của truy vấn với bảng Internet Latency Table để tìm ra endpoint phù hợp.
Khi thiết lập endpoint, nếu kiểu endpoint là External endpoint, bạn cần phải khai báo vị trí đặt hoặc vị trí gần vị trí đặt máy chủ của endpoint đó theo danh sách các địa điểm được cung cấp sẵn.
Trong trường hợp các endpoint đều chung một vị trí, Azure Traffic Manager sẽ phân phối đều truy cập tới các endpoint.
Phương thức điều hướng Geographic
Azure Traffic Manager hỗ trợ điều hướng truy cập tới endpoint có vị trí địa lý giống hoặc gần với vị trí của nơi gửi yêu cầu truy vấn DNS. Khi thiết lập endpoint, bạn sẽ cần phải khai báo vị trí địa lý của endpoint đấy. Thông tin vị trí địa lý được Azure Traffic Manager phân cấp ở nhiều cấp khác nhau, bao gồm:
- World: cấp Thế giới
- Regional Grouping: cấp nhóm khu vực, thường là các châu lục hoặc vùng lãnh thổ lớn như Châu Á, Châu Âu, …
- Country/Region: cấp Quốc gia như Việt Nam, Hàn Quốc, …
- State/Province: cấp tiểu bang, thành phố, tỉnh như California, Washington, … (chỉ có một số cấp quốc gia nhất định mới có thể khai báo cấp tiểu bang này như Mỹ, Anh, Úc hay Canada)
Chi tiết về việc phân cấp này bạn có thể tham khảo tại đây.
Khi thực hiện tìm endpoint phù hợp, Azure Traffic Manager sẽ thực hiện đối chiếu vị trí địa lý ở cấp thấp nhất tức State/Province rồi sau đó tới Country/Region > Regional Grouping > World.
Sự khác nhau giữa Priority và Weighted
Phương thức Priority và Weighted đều dựa vào trọng số để tìm ra endpoint phù hợp nhất. Tuy nhiên trong trường hợp tất cả các endpoint đều hoạt động ổn định, với phương thức Priority, việc điều hướng truy cập vào endpoint nào là xác định và chỉ có duy nhất 1 endpoint được đánh trọng số thấp nhất (có mức độ ưu tiên cao nhất) sẽ là endpoint nhận toàn bộ truy cập, các endpoint còn lại sẽ không được nhận truy cập. Còn với phương thức Weighted, việc điều hướng vào endpoint nào là không xác định, Azure Traffic Manager sẽ ngẫu nhiên lựa chọn một endpoint phù hợp nhất dựa vào trọng số được đánh cho mỗi endpoint, do vậy tất các endpoint đều có khả năng nhận truy cập, còn việc nhận nhiều hay ít thì phụ thuộc vào trọng số được đánh ở mỗi endpoint.
Sự khác nhau giữa Performance và Geographic
Sự khác nhau thấy rõ ở 2 phương thức này là phương thức Performance dựa vào độ trễ mạng để chọn ra endpoint phù hợp nhất trong khi Geographic thì dựa vào vị trí địa lý.
Mặc dù Performance dựa vào độ trễ mạng để chọn ra endpoint phù hợp nhất, tuy nhiên có thể có một số bạn sẽ nghĩ rằng dựa vào độ trễ mạng cũng giống với dựa vào vị trí địa lý vì ở càng gần nhau thì tốc độ trễ mạng càng thấp nên phương thức Performance và Geographic là có vẻ giống nhau. Quan điểm này không hoàn toàn đúng, trong nhiều trường hợp, việc kết nối từ một node tới một node khác ở vị trí gần chưa chắc đã có độ trễ mạng thấp hơn so với việc kết nối tới một node khác ở xa hơn. Điều này hoàn toàn có thể xảy ra bởi các yếu tố như hạ tầng mạng chẳng hạn. Do vậy khi lựa chọn phương thức điều hướng truy cập có phụ thuộc vào tốc độ, độ trễ mạng, bạn nên lựa chọn Performance. Geographic là phương thức phù hợp hơn với những bài toán cần đảm bảo dữ liệu được trao đổi giữa các endpoint phải tuân thủ luật chủ quyền dữ liệu chẳng hạn.
Các kiểu endpoint được hỗ trợ
Ngoài hỗ trợ endpoint là các dịch vụ trên Azure, Azure Traffic Manager còn hỗ trợ cho các endpoint của hệ thống bên ngoài, được xây dựng không sử dụng dịch vụ của Azure. Có 3 kiểu endpoint hiện được Azure Traffic Manager hỗ trợ:
- Azure endpoint: Các dịch vụ được host trên Azure.
- External endpoint: Các dịch vụ bên ngoài không được host trên Azure hoặc được host trên Azure nhưng không được trực tiếp hỗ trợ trong Azure endpoint.
- Nested endpoint: Cho phép thêm các cấu hình điều hướng truy cập từ các Azure Traffic Manager khác.
Azure endpoint
Azure Traffic Manager trực tiếp hỗ trợ điều hướng truy cập cho một số dịch vụ của Azure bao gồm:
- Azure Cloud Service
- Azure App Service
- Azure Public IP
Với các ứng dụng host trên Azure App Service, các gói dịch vụ (plan) Free, Basic, Shared không được hỗ trợ. Bạn phải nâng cấp gói dịch vụ cho Azure App Service resource của mình lên các gói Standard trở lên để có thể sử dụng được Azure Traffic Manager.
Còn với Azure Public IP, một lưu ý khi cấu hình dịch vụ này làm endpoint của Azure Traffic Manager đó là bạn cần phải thiết lập DNS name cho Public IP đó trước khi có thể sử dụng làm endpoint.
Trong trường hợp bạn muốn điều hướng truy cập tới các ứng dụng được host trên Azure Virtual Machine (VM), bạn có thể sử dụng Azure Public IP rồi trỏ tới Public IP của VM hoặc của Load Balancer của VM.
Nested endpoint
Trong nhiều hệ thống, thiết lập các quy tắc điều hướng là một bài toán phức tạp và một profile không thể xử lý được các quy tắc này. Với nested endpoint, Azure Traffic Manager cho phép bạn có thể lồng các profile với nhau, tạo thành một bộ các quy tắc điều hướng truy cập đáp ứng yêu cầu của hệ thống.
Ví dụ
Quay trở lại ví dụ trên của mình, blog cá nhân của mình có một giao diện mới cùng với một số tối ưu về hiệu suất, mình muốn thực hiện production test cho phiên bản mới tuy nhiên chỉ hướng tới các bạn đọc ở Việt Nam. Mình đã deploy phiên bản mới này lên một Deployment Slot của Azure Web App resource với DNS name là blog-asia-new.lionpham.com. Bài toán mình cần phải giải quyết ở đây là làm sao có thể điều hướng được 20% lượng truy cập từ Việt Nam vào phiên bản mới mà vẫn giữ nguyên quy tắc điều hướng hiện tại.
Để giải quyết bài toán trên, mình sẽ tạo ra một Azure Traffic Manager profile khác có DNS name là lionpham-asia.trafficmanager.net. Trong profile này, mình thiết lập phương thức điều hướng truy cập là Weighted với 2 endpoint là:
Endpoint | Weight |
blog-asia-new.lionpham.com | 20 |
blog-asia.lionpham.com | 80 |
Và mình có một biểu đồ điều hướng truy cập như sau:
Về cơ bản, luồng điều hướng khá giống với ví dụ đầu tiên của mình tuy nhiên ở đây thay vì điều hướng toàn bộ truy cập từ Việt Nam vào endpoint có DNS name là blog-asia.lionpham.com, các truy cập từ Việt Nam sẽ được xử lý ở Azure Traffic Manager – lionpham-asia.trafficmanager.net với cấu hình 20% truy cập vào endpoint có DNS name là blog-asia-new.lionpham.com và 80% truy cập vào endpoint có DNS name là blog-asia.lionpham.com.
Ở biểu đồ trên, giả định ở đây là Azure Traffic Manager – lionpham-asia.trafficmanager.net tính toán ngẫu nhiên và trả về DNS record của endpoint có DNS name là blog-asia-new.lionpham.com (4), tức endpoint của phiên bản mới của blog cá nhân của mình. Sau đó, DNS service thực hiện truy vấn DNS record cho DNS name này và trả về IP của endpoint của phiên bản mới (6). Trình duyệt sau đó thực hiện truy cập vào IP nhận được và bạn đọc ở phiên truy cập đấy sẽ có trải nghiệm đọc blog cá nhân của mình với giao diện mới & hiệu suất được tối ưu (7).
Azure Traffic Manager xác định tình trạng của endpoint như thế nào?
Azure Traffic Manager được tích hợp sẵn tính năng Health Monitoring, cho phép dịch vụ này có khả năng liên tục theo dõi tình trạng sức khỏe của các endpoint của nó. Với khả năng này, Azure Traffic Manager có thể dễ dàng xử lý các bài toán chống sụp đổ hệ thống bằng cách luôn luôn điều hướng truy cập vào các endpoint khỏe mạnh.
Về mặt kỹ thuật, Health Monitoring của Azure Traffic Manager sẽ sử dụng 1 trong 3 giao thức HTTP, HTTPS và TCP để thực hiện kết nối tới một đường dẫn cụ thể trong endpoint theo một tần suất định sẵn để kiểm tra xem endpoint đó có khỏe mạnh hay không. Azure Traffic Manager xác định 1 endpoint không khỏe mạnh khi:
- Với phương thức HTTP hay HTTPS: Mã HTTP phản hồi về không phải là 200
- Với phương thức TCP: Message phản hồi về sau khi thực hiện handshake không phải là ACK hoặc SYN-ACK
- Timeout xảy ra khi thực hiện kết nối tới endpoint
- Azure Traffic Manager không thể thực hiện kết nối tới endpoint
Để cấu hình giao thức kết nối, tần suất kiểm tra, đường dẫn để thực hiện kết nối, cũng như các cấu hình khác cho Health Monitoring, các bạn vào phần Configuration của Azure Traffic Manager.
Kinh nghiệm khi thiết lập Health Monitoring
Khi lựa chọn giao thức kết nối HTTP hay HTTPS, bạn nên xây dựng một web application đơn giản (có thể là một Node.JS web application) có chứa những đoạn code logic tối thiểu để kiểm tra trạng thái của ứng dụng của bạn, mình gọi đây là “Health check web application“. Sau đó bạn cấu hình cho Health check web application này lắng nghe kết nối với một cổng riêng, khác với cổng kết nối của ứng dụng chính. Ví dụ như blog cá nhân của mình có cổng kết nối là 80 và 443, thì Health check web application nên đặt cổng khác 80 và 443, ví dụ như 3000 chẳng hạn. Việc làm này sẽ giúp ngăn chặn các truy cập không mong muốn vào Health check web application từ bên ngoài cũng như tránh xảy ra xung đột đường dẫn giữa ứng dụng chính với Health check web application, ví dụ như Health check web application được triển khai với đường dẫn tương đối là /healthcheck trong khi ứng dụng chính cũng có 1 đường dẫn tương đối là /healthcheck, thực tế là dẫn tới một trang với một nội dung không phải là để kiểm tra trạng thái của ứng dụng, mà chỉ là chia sẻ các kỹ thuật xây dựng Health check web application chẳng hạn.
Trên là phần 1 của bài viết về Azure Traffic Manager. Trong phần 2 của bài bài viết (dự kiến sẽ được đăng trong vài ngày tới), mình sẽ cùng các bạn đi cụ thể vào cấu hình cho một Traffic Manager profile cũng như tìm hiểu về cơ chế tính phí của Azure Traffic Manager.
Cập nhật ngày 18/03/2018: Phần 2 của bài viết đã được đăng tải và có sẵn để đọc tại đây.
Traffic Manager có vẻ như chỉ hỗ trợ cho các internet-facing services thôi đúng không bạn?
Đúng rồi bạn nhé, service phải accessible từ Internet thì mới có thể sử dụng được Azure Traffic Manager