Hiện nay, Amazon Route 53 lưu trữ nhiều trang web nổi tiếng nhất và nhiều doanh nghiệp lớn nhất thế giới, nhưng sự khởi đầu của dịch vụ này lại khiêm tốn hơn rất nhiều.

Bắt đầu lưu trữ DNS

Không lâu sau khi AWS bắt đầu cung cấp dịch vụ, khách hàng AWS đã nói rõ rằng họ muốn có thể sử dụng các dịch vụ Amazon Simple Storage Service (S3), Amazon CloudFront và Elastic Load Balancing của chúng tôi tại tên miền “gốc” của họ, tức là cho những cái tên như “amazon.com” mà không chỉ cho “www.amazon.com”.
 
Điều đó trông có vẻ rất đơn giản. Tuy nhiên, do một quyết định về cách thiết kế giao thức DNS từ những năm 1980, điều này lại khó khăn hơn sự tưởng tượng của chúng tôi. DNS có một tính năng được gọi là CNAME cho phép chủ sở hữu của tên miền giảm tải một phần tên miền của họ cho nhà cung cấp khác để lưu trữ, nhưng DNS không hoạt động ở cấp gốc hoặc cấp cao nhất của tên miền. Để phục vụ nhu cầu từ khách hàng của mình, chúng tôi phải thực sự lưu trữ tên miền của họ. Khi lưu trữ tên miền của khách hàng, chúng tôi có thể trả lại mọi tập hợp địa chỉ IP hiện tại cho Amazon S3, Amazon CloudFront hoặc Elastic Load Balancing. Các dịch vụ này liên tục mở rộng và thêm địa chỉ IP, do đó, điều này cũng không phải là thứ mà khách hàng có thể dễ dàng nhúng trực tiếp vào mã nguồn (hardcode) trong cấu hình tên miền của họ.
 
Lưu trữ DNS không phải là công việc dễ dàng. Nếu DNS gặp vấn đề, toàn bộ doanh nghiệp có thể mất kết nối. Tuy nhiên, sau khi đã xác định được nhu cầu, chúng tôi bắt đầu giải quyết vấn đề theo cách thường thấy tại Amazon — một cách khẩn trương. Chúng tôi đã tập hợp một nhóm nhỏ các kỹ sư và bắt tay vào làm việc.

Xử lý tấn công DDoS

Các nhà cung cấp DNS đều nói thách thức lớn nhất của họ là xử lý các cuộc tấn công từ chối dịch vụ phân tán (DDoS). DNS được xây dựng dựa trên giao thức UDP, điều đó có nghĩa là các yêu cầu DNS có thể bị giả mạo trên Internet lộn xộn như miền Viễn Tây này. Vì DNS cũng là cơ sở hạ tầng vô cùng quan trọng, nên sự kết hợp này làm cho DNS trở thành mục tiêu hấp dẫn đối với những kẻ giả mạo thiếu đạo đức cố gắng tống tiền các doanh nghiệp, những “kẻ châm ngòi” cố gắng gây ra sự cố ngừng hoạt động vì nhiều lý do, và những người thỉnh thoảng gây phiền toái không nhận ra là họ đang phạm tội nghiêm trọng với hậu quả thực sự đối với cá nhân. Bất kể lý do là gì, thì mỗi ngày, các miền vẫn phải hứng chịu hàng ngàn cuộc tấn công DDoS.

Có một phương pháp giảm thiểu các cuộc tấn công này là sử dụng máy chủ công suất lớn. Mặc dù việc có một khả năng tiếp nhận cơ sở tốt là rất quan trọng, cách tiếp cận này không thực sự tốt trên quy mô lớn. Mỗi máy chủ mà nhà cung cấp thêm vào có chi phí hàng ngàn đô la, nhưng những kẻ tấn công có thể thêm nhiều máy khách giả để đạt được mục đích nếu các nhà cung cấp đang sử dụng các botnet (tập hợp các bot) bị xâm nhập. Đối với các nhà cung cấp, việc thêm khối lượng lớn khả năng tiếp nhận của máy chủ là một chiến lược thua lỗ.

Vào thời điểm chúng tôi xây dựng Amazon Route 53, công nghệ phòng thủ DNS là các thiết bị mạng chuyên dụng có thể sử dụng nhiều thủ thuật khác nhau để “xóa” lưu lượng truy cập với tốc độ rất cao. Chúng tôi đã có nhiều thiết bị này tại Amazon cho các dịch vụ DNS nội bộ hiện có của mình và đã nói chuyện với các nhà cung cấp phần cứng về những thiết bị khác có sẵn. Chúng tôi phát hiện ra rằng việc mua đủ các thiết bị để trang trải đầy đủ cho mỗi tên miền của Route 53 sẽ tốn hàng chục triệu đô la và cần thêm vài tháng để cung cấp cho khách hàng, cài đặt và vận hành. Điều đó không phù hợp với sự cấp bách trong các kế hoạch hoặc với những nỗ lực tiết kiệm của chúng tôi, vì vậy chúng tôi không bao giờ nghiêm túc xem xét giải pháp này. Chúng tôi cần tìm ra cách chỉ tiêu tốn tài nguyên để bảo vệ các tên miền thực sự bị tấn công. Chúng tôi đã chuyển sang nguyên tắc cũ rằng nhu cầu sẽ tạo ra sáng chế. Nhu cầu của chúng tôi là nhanh chóng xây dựng một dịch vụ DNS đẳng cấp thế giới, luôn hoạt động bằng tài nguyên khiêm tốn nhất. Sáng chế của chúng tôi là phân mảnh xáo trộn.

Phân mảnh xáo trộn là gì?

Phân mảnh xáo trộn rất đơn giản nhưng vô cùng mạnh mẽ. Phương pháp này thậm chí còn mạnh mẽ hơn những gì chúng tôi nhận ra ngay từ đầu. Chúng tôi đã sử dụng phương pháp này nhiều lần và nó đã trở thành một mô hình cốt lõi giúp AWS có thể cung cấp các dịch vụ cho nhiều đối tượng thuê với chi phí hợp lý, mang lại cho mỗi khách hàng trải nghiệm rằng dịch vụ dường như chỉ dành cho mình họ.

Để xem cách phân mảnh xáo trộn hoạt động, trước tiên hãy xem xét cách một hệ thống có thể được mở rộng hơn và có khả năng phục hồi tốt hơn thông qua phân mảnh thông thường. Tưởng tượng rằng một hệ thống hoặc dịch vụ có thể thay đổi quy mô theo chiều ngang được tạo thành từ 8 công nhân. Hình ảnh sau đây minh họa cho các công nhân và yêu cầu của họ. Các công nhân có thể là các máy chủ, hàng đợi hoặc cơ sở dữ liệu, bất cứ “thứ” gì tạo nên hệ thống của bạn.

Nếu không có phân mảnh thì nhóm công nhân sẽ xử lý tất cả công việc. Mỗi công nhân phải có khả năng xử lý mọi yêu cầu. Điều này là vô cùng tuyệt vời cho hiệu quả làm việc và khả năng dự phòng. Nếu một máy thợ gặp lỗi, thì bảy máy còn lại có thể tiếp nhận công việc đó nên hệ thống chỉ bị suy giảm công suất ở mức độ tương đối thấp. Tuy nhiên, một vấn đề lớn sẽ xuất hiện nếu một loại yêu cầu cụ thể hoặc hàng loạt các yêu cầu, chẳng hạn như một cuộc tấn công DDoS, có thể kích hoạt sự cố. Hai hình ảnh sau đây cho thấy tiến trình của một cuộc tấn công như vậy.

Vấn đề sẽ loại bỏ công nhân đầu tiên bị ảnh hưởng, nhưng sau đó tiến hành xếp tầng qua các công nhân còn lại khi họ tiếp quản yêu cầu. Vấn đề có thể loại bỏ rất nhanh tất cả công nhân cũng như toàn bộ dịch vụ.

Phạm vi tác động của loại sự cố này là “tất cả mọi thứ và tất cả mọi người”. Toàn bộ dịch vụ sụp đổ. Tất cả khách hàng đều bị ảnh hưởng. Như cách chúng tôi nói trong kỹ thuật nghiên cứu tính khả dụng: tình trạng này không được tối ưu.

Với việc phân mảnh thông thường, chúng tôi có thể làm tốt hơn. Nếu chia nhóm thiết bị của mình thành 4 phân mảnh máy thợ, thì chúng ta có thể đổi sự hiệu quả lấy phạm vi tác động. Hai hình ảnh sau đây cho thấy cách phân mảnh có thể giới hạn tác động của một cuộc tấn công DDoS.

Trong ví dụ này, mỗi phân mảnh có hai máy thợ. Chúng tôi chia nhỏ tài nguyên, chẳng hạn như tên miền của khách hàng, cho các phân mảnh. Chúng tôi vẫn có khả năng dự phòng, nhưng do chỉ có 2 công nhân mỗi phân mảnh, chúng tôi phải giữ lại nhiều khả năng tiếp nhận chưa được sử dụng hết trong hệ thống để xử lý mọi sự cố có thể phát sinh. Đổi lại, phạm vi tác động sẽ được giảm thiểu đáng kể.

Trong thế giới phân mảnh này, phạm vi tác động được giảm thiểu theo số lượng phân mảnh. Ở đây, với 4 phân mảnh, nếu một khách hàng gặp sự cố, thì phân mảnh lưu trữ khách hàng đó có thể bị tác động, cũng như toàn bộ khách hàng trên phân mảnh đó. Tuy nhiên, phân mảnh này chỉ chiếm một phần tư toàn bộ dịch vụ. Tác động 25% tốt hơn nhiều so với tác động 100%. Với việc phân mảnh xáo trộn, chúng tôi thậm chí còn có thể làm tốt hơn nhiều lần.

Với việc xáo trộn phân mảnh, chúng tôi sẽ tạo ra các phân mảnh ảo của mỗi 2 công nhân và chỉ định khách hàng hoặc tài nguyên của mình, hoặc mọi thứ chúng tôi muốn cô lập, cho một trong số các phân mảnh ảo đó.

Hình ảnh sau thể hiện một bố cục ví dụ của việc phân mảnh xáo trộn với 8 công nhân và 8 khách hàng được chỉ định cho 2 công nhân. Thông thường, chúng tôi sẽ có nhiều khách hàng hơn công nhân, nhưng sẽ dễ dàng để theo dõi hơn nếu chúng ta hạn chế số lượng này. Chúng tôi sẽ tập trung vào 2 khách hàng — khách hàng cầu vồng và khách hàng hoa hồng.

Trong ví dụ của mình, chúng tôi chỉ định khách hàng cầu vồng cho công nhân #1 và công nhân #4. Sự kết hợp của hai công nhân này tạo nên phân mảnh xáo trộn của khách hàng đó. Các khách hàng khác sẽ chuyển đến phân mảnh ảo khác với tổ hợp hai công nhân của riêng họ. Ví dụ: khách hàng hoa hồng cũng được chỉ định cho công nhân #1 nhưng công nhân còn lại là công nhân #8.

Nếu khách hàng cầu vồng được chỉ định cho công nhân #1 và #4 gặp sự cố (chẳng hạn như yêu cầu độc hại hoặc rất nhiều yêu cầu), thì sự cố đó sẽ ảnh hưởng đến phân mảnh ảo đó nhưng sẽ không tác động hoàn toàn đến các phân mảnh xáo trộn khác. Thực tế là chỉ có tối đa một công nhân của phân mảnh xáo trộn khác bị ảnh hưởng. Nếu người yêu cầu có khả năng chịu lỗi và có thể giải quyết vấn đề này (ví dụ như thử lại), thì dịch vụ có thể tiếp tục mà không bị gián đoạn đối với khách hàng hoặc tài nguyên trên các phân đoạn còn lại, như được minh họa trong hình ảnh sau đây.

Nói cách khác, trong khi tất cả các công nhân phục vụ khách hàng cầu vồng có thể đang đối mặt với vấn đề hoặc một cuộc tấn công, thì các công nhân khác hoàn toàn không bị ảnh hưởng. Đối với khách hàng, điều đó có nghĩa là mặc dù khách hàng hoa hồng và khách hàng hoa hướng dương đều chia sẻ một công nhân với khách hàng cầu vồng, nhưng họ không bị ảnh hưởng. Khách hàng hoa hồng có thể nhận dịch vụ từ công nhân #8 và khách hàng hoa hướng dương có thể nhận dịch vụ từ công nhân #6, như bạn có thể thấy trong hình ảnh dưới đây.

Khi xảy ra sự cố, chúng tôi vẫn có thể mất một phần tư toàn bộ dịch vụ, nhưng cách khách hàng hoặc tài nguyên được chỉ định có nghĩa là phạm vi tác động với phân mảnh xáo trộn tốt hơn đáng kể. Với tám công nhân, có 28 cách kết hợp duy nhất của hai công nhân, đồng nghĩa với 28 phân mảnh xáo trộn. Nếu chúng tôi có hàng trăm khách hàng trở lên và chỉ định mỗi khách hàng cho một phân mảnh xáo trộn, thì phạm vi tác động của một sự cố chỉ là 1/28. Tốt hơn 7 lần so với phân mảnh thông thường.

Rất thú vị khi thấy rằng những con số tốt hơn theo cấp số nhân khi bạn càng có nhiều công nhân và khách hàng. Hầu hết các thử thách mở rộng trở nên khó khăn hơn với các chỉ số đó, nhưng phân mảnh xáo trộn cũng sẽ trở nên hiệu quả hơn. Trong thực tế, với đủ công nhân, có thể có nhiều phân đoạn xáo trộn hơn khách hàng, và mỗi khách hàng đều có thể được cô lập.

Amazon Route 53 và phân mảnh xáo trộn

Tất cả những điều này có thể giúp gì cho Amazon Route 53? Với Route 53, chúng tôi quyết định sắp xếp khả năng tiếp nhận của mình thành tổng cộng 2048 máy chủ tên miền ảo. Những máy chủ này là ảo vì chúng không phản hồi các máy chủ vật lý lưu trữ Route 53. Chúng tôi có thể di chuyển các máy chủ này để giúp quản lý khả năng tiếp nhận. Sau đó, chúng tôi chỉ định mọi tên miền của khách hàng cho một phân mảnh xáo trộn của 4 máy chủ tên miền ảo. Với các con số ở trên, chúng tôi có thể có đến 730 triệu phân mảnh xáo trộn, thật đáng kinh ngạc! Chúng tôi có nhiều phân mảnh xáo trộn đến mức có thể chỉ định một phân mảnh xáo trộn duy nhất cho từng tên miền. Trên thực tế, chúng tôi có thể làm được nhiều hơn và đảm bảo rằng không có tên miền khách hàng nào sẽ chia sẻ nhiều hơn hai máy chủ tên miền ảo với bất kỳ tên miền khách hàng nào khác.

Kết quả thật tuyệt vời. Nếu miền của một khách hàng là mục tiêu của cuộc tấn công DDoS, thì bốn máy chủ tên ảo được gán cho miền đó sẽ tăng đột biến lưu lượng truy cập, nhưng không có miền của khách hàng nào khác nhận thấy điều đó. Chúng tôi không thể để khách hàng là mục tiêu của cuộc tấn công đó có một ngày tồi tệ. Phân mảnh xáo trộn nghĩa là chúng tôi có thể xác định và cô lập khách hàng bị nhắm đến cho khả năng tấn công chuyên dụng đặc biệt. Ngoài ra, chúng tôi cũng đã phát triển lớp dọn dẹp lưu lượng truy cập AWS Shield độc quyền của riêng mình. Tuy nhiên, việc phân mảnh xáo trộn tạo ra sự khác biệt lớn trong việc đảm bảo rằng trải nghiệm chung của khách hàng với Route 53 là liền mạch, ngay cả khi những sự kiện đó đang diễn ra.

Kết luận

Chúng tôi đã tiếp tục nhúng phân mảnh xáo trộn vào rất nhiều hệ thống của mình. Ngoài ra, chúng tôi đã đưa ra các tinh chỉnh, chẳng hạn như xáo trộn đệ quy, trong đó chúng tôi phân mảnh các mục ở nhiều lớp, từ đó cô lập một khách hàng của khách hàng. Phân mảnh xáo trộn có khả năng thích nghi vô cùng lớn. Đó là một cách thông minh để sắp xếp các nguồn lực hiện có. Phương pháp này cũng không tốn thêm chi phí, nên là một sự cải thiện lớn cho khả năng tiết kiệm.

Nếu bạn có hứng thú với việc tự mình áp dụng phân mảnh xáo trộn, hãy xem thư viện mã nguồn mở Infima cho Route 53 của chúng tôi. Thư viện này bao gồm nhiều cách triển khai phân mảnh xáo trộn khác nhau có thể được sử dụng cho việc chỉ định hoặc sắp xếp các tài nguyên.

Phòng thực hành tại chỗ

Thử một vài nguyên tắc mà bạn đã học ở đây với phòng thực hành tại chỗ.


Giới thiệu về tác giả

Colm MacCárthaigh là Kỹ sư chính cấp cao tại Amazon Web Services. Trước khi làm về EC2, mật mã học và kết nối mạng, Colm đã giúp xây dựng Amazon CloudFront và Amazon Route 53. Colm cũng là một người đóng góp Mã nguồn mở và là một trong những tác giả của máy chủ web Apache http, cũng như Amazon s2n — phương pháp triển khai các giao thức SSL/TLS của AWS. Khi không làm việc với những vấn đề kỹ thuật, Colm là một nhạc sĩ và ca sĩ, thường xuyên chơi nhạc, lưu diễn và thu âm nhạc Ai-len ở nhiều nơi trên thế giới.

Thời gian chờ, thử lại và rút lại với phương sai độ trễ