Sử dụng biện pháp giảm tải để tránh tải David Yanacek Sử dụng biện pháp giảm tải để tránh tải Bản quyền © 2019 Amazon Web Services, Inc và/hoặc đơn vị liên kết Amazon Web Services, Inc Bảo lưu quyền Sử dụng biện pháp giảm tải để tránh tải Tôi làm vài năm nhóm Framework dịch vụ Amazon Nhóm viết công cụ giúp chủ sở hữu dịch vụ AWS Amazon Route 53 Elastic Load Balancing xây dựng dịch vụ nhanh giúp máy khách dịch vụ gọi dịch vụ dễ dàng Các nhóm Amazon khác cung cấp cho chủ sở hữu dịch vụ chức đo lường, xác thực, giám sát, tạo thư viện máy khách tạo tài liệu Thay để nhóm dịch vụ tích hợp thủ cơng tính vào dịch vụ mình, nhóm Framework dịch vụ tích hợp lần cung cấp chức cho dịch vụ cách đặt cấu hình Một thách thức chúng tơi gặp phải xác định cách cung cấp giá trị mặc định phù hợp, đặc biệt tính liên quan đến hiệu tính khả dụng Ví dụ: chúng tơi khơng thể dễ dàng thiết lập thời gian chờ mặc định phía máy khách framework đặc điểm độ trễ lệnh gọi API Chủ sở hữu dịch vụ máy khách chẳng thể tự giải vấn đề cách dễ dàng hơn, chúng tơi tiếp tục cố gắng có số thơng tin chun sâu hữu ích trình Một câu hỏi phổ biến mà gặp phải việc xác định số lượng kết nối mặc định mà máy chủ để mở cho máy khách thời điểm Thiết lập thiết kế để ngăn chặn máy chủ thực nhiều công việc trở nên tải Cụ thể hơn, chúng tơi muốn đặt cấu hình cài đặt kết nối tối đa cho máy chủ tỷ lệ với số kết nối tối đa cho cân tải Đó thời kỳ trước Elastic Load Balancing xuất nên thiết bị cân tải sử dụng rộng rãi Chúng bắt đầu giúp chủ sở hữu dịch vụ Amazon máy khách dịch vụ tìm giá trị lý tưởng cho số kết nối tối đa để thiết lập cân tải, giá trị tương ứng để thiết lập framework mà cung cấp Chúng định tìm cách sử dụng phán đốn người để đưa lựa chọn, chúng tơi viết phần mềm để mơ phán đoán Việc xác định giá trị lý tưởng hóa lại đầy thử thách Nếu đặt số kết nối tối đa q thấp, cân tải ngừng tăng số lượng yêu cầu, dịch vụ nhiều khả tiếp nhận Nếu đặt số kết nối tối đa cao, máy chủ trở nên chậm chạp không phản hồi Nếu đặt số kết nối tối đa xác cho khối lượng công việc, khối lượng công việc thay đổi hiệu phụ thuộc thay đổi Từ đó, giá trị lại sai, dẫn đến cố ngừng hoạt động tải không cần thiết Cuối cùng, thấy khái niệm số kết nối tối đa vô mơ hồ để cung cấp câu trả lời hoàn chỉnh cho vấn đề Trong viết này, mô tả cách tiếp cận khác biện pháp giảm tải mà thấy hoạt động hiệu Bản chất tượng tải Tại Amazon, hạn chế tải cách thiết kế cho hệ thống chủ động thay đổi quy mơ trước chúng gặp phải tình tải Tuy nhiên, việc bảo vệ hệ thống bao gồm bảo vệ theo lớp Quá trình bắt đầu với việc tự động thay đổi quy mô bảo gồm chế giúp giảm tải mức có kiểm sốt, khả giám sát chế này, quan trọng kiểm thử liên tục Khi kiểm thử độ chịu tải dịch vụ, thấy độ trễ máy chủ mức sử dụng thấp thấp độ trễ mức sử dụng cao Khi máy chủ tải nặng, tượng tranh chấp luồng (thread contention), chuyển ngữ cảnh (context switching), thu gom rác (garbage collection) tranh chấp I/O (I/O contention) trở nên rõ ràng Cuối cùng, dịch vụ đạt đến điểm uốn mà hiệu bắt đầu suy giảm nhanh Lý thuyết tảng quan sát biết đến Định luật khả mở rộng phổ quát (Universal Scalability Law), rút từ Định luật Amdahl Lý thuyết xác định thông Sử dụng biện pháp giảm tải để tránh tải lượng hệ thống tăng lên q trình song song hóa (parallelization), cuối bị giới hạn thơng lượng điểm q trình chuyển đổi cấu trúc liệu đối tượng thành định dạng lưu trữ (serialization) (nghĩa là, tác vụ khơng thể song song hóa) Thật khơng may, thông lượng không bị giới hạn tài nguyên hệ thống mà thường suy giảm hệ thống bị tải Khi hệ thống giao nhiều cơng việc khả tài ngun hỗ trợ, hệ thống trở nên chậm chạp Máy tính tiếp nhận cơng việc chúng bị tải, chúng tiêu tốn ngày nhiều thời gian để chuyển ngữ cảnh khơng cịn hữu ích chậm chạp Trong hệ thống phân tán nơi máy khách làm việc với máy chủ, máy khách thường trở nên thiếu kiến nhẫn dừng chờ đợi máy chủ phản hồi sau khoảng thời gian Chúng ta biết đến khoảng thời gian với tên gọi thời gian chờ Khi máy chủ tải đến mức độ trễ vượt thời gian chờ máy khách, yêu cầu bắt đầu thất bại Đồ thị cho thấy thời gian phản hồi máy chủ tăng lên thông lượng cung cấp (trong giao dịch giây) tăng lên, cuối thời gian phản hồi đạt đến điểm uốn mà thứ giảm nhanh chóng Thời gian phản hồi (mili giây) Độ trễ máy chủ so với Thông lượng (thời gian chờ máy khách) Thông lượng cung cấp (TPS) Trong biểu đồ trước đó, thời gian phản hồi vượt thời gian chờ máy khách, rõ ràng thứ tồi tệ, biểu đồ không mức độ tồi tệ Để minh họa điều này, vẽ biểu đồ tính khả dụng máy khách với độ trễ Thay sử dụng cách tính thời gian phản hồi chung, chúng tơi chuyển sang dùng thời gian phản hồi trung vị Thời gian phản hồi trung vị có nghĩa 50% số yêu cầu nhanh giá trị trung vị Nếu độ trễ trung vị dịch vụ với thời gian chờ máy khách, nửa số yêu cầu hết thời gian, tính khả dụng 50% Đó tăng độ trễ biến vấn đề độ trễ thành vấn đề tính khả dụng Đây đồ thị xảy ra: Sử dụng biện pháp giảm tải để tránh tải Độ sẵn sàng đạt 50% độ trễ trung bình thời gian chờ Độ sẵn sàng đạt 0% độ trễ tối thiểu vượt thời gian chờ Thông lượng (TPS) Độ trễ Thời gian chờ máy khách Độ sẵn sàng phía máy khách độ trễ trung bình (mili giây) Độ sẵn sàng giảm nhanh đạt 0% không giảm tải Độ sẵn sàng Tiếc đồ thị khó đọc Một cách đơn giản để mô tả vấn đề độ sẵn sàng phân biệt goodput với thông lượng Thông lượng tổng số yêu cầu giây gửi tới máy chủ Goodput thành phần thông lượng xử lý khơng có lỗi có độ trễ đủ thấp để máy khách sử dụng phản hồi GOODPUT SO VỚI THƠNG LƯỢNG Hệ thống nhận nhiều cơng việc, khả hồn thành GOODPUT (TPS) Đạt thơng lượng hiệu tối đa THƠNG LƯỢNG CUNG CẤP (TPS) Vịng lặp phản hồi tích cực Khả lan truyền âm thầm trường hợp tải nằm cách tự khuếch đại vịng lặp phản hồi Khi máy khách hết thời gian chờ, tình đủ tệ máy khách gặp lỗi Tình tệ toàn tiến độ mà máy chủ thực cho yêu cầu tính đến thời điểm bị lãng phí Và điều cuối hệ thống nên làm trường hợp tải, với khả tiếp nhận hạn chế, loại bỏ công việc Điều làm thứ tệ hại máy khách thường thử yêu cầu lại Điều khiến lượng tải cung cấp hệ thống tăng lên nhiều lần Và có đồ thị gọi đủ sâu kiến trúc hướng dịch vụ (khi máy khách gọi dịch vụ, dịch vụ lại gọi dịch vụ khác tiếp diễn), Sử dụng biện pháp giảm tải để tránh tải lớp thực nhiều lần thử lại, tải lớp gây thử lại phân tầng khuếch đại khối lượng tải cung cấp theo cấp số nhân Khi yếu tố kết hợp, tình trạng tải tạo vịng lặp phản hồi riêng mình, dẫn đến tải trạng thái ổn định Ngăn chặn lãng phí cơng việc Thoạt nhìn, biện pháp giảm tải đơn giản Khi tải, máy chủ nên chối yêu cầu vượt mức để tập trung vào yêu cầu tiếp nhận Mục đích giảm tải nhằm giữ độ trễ thấp yêu cầu mà máy chủ chấp nhận để dịch vụ trả lời trước máy khách hết thời gian chờ Với cách tiếp cận này, máy chủ trì tính khả dụng cao cho yêu cầu tiếp nhận có tính khả dụng lưu lượng vượt mức bị ảnh hưởng Độ sẵn sàng giảm theo tuyến tính giảm số yêu cầu vượt mức Độ sẵn sàng yêu cầu chấp nhận cao Độ sẵn sàng phía máy khách độ trễ trung bình (mili giây) Giảm độ sẵn sàng hợp lý, độ trễ quán tải Thông lượng (TPS) Độ trễ Thời gian chờ máy khách Độ sẵn sàng tổng thể Độ sẵn sàng yêu cầu chấp nhận Kiểm soát độ trễ cách giảm tải vượt mức tăng tính khả dụng hệ thống Nhưng khó để trực quan hóa lợi ích phương pháp đồ thị trước Đường biểu thị tính khả dụng tổng thể xuống, khơng phải tín hiệu tốt Điều quan trọng yêu cầu mà máy chủ định tiếp nhận khả dụng chúng phản hồi nhanh chóng Giảm tải cho phép máy chủ trì phần thơng lượng khơng bị lỗi (goodput) hồn tất nhiều u cầu có thể, tăng thông lượng cung cấp Tuy nhiên, việc giảm tải khơng hồn hảo, cuối máy chủ phải tuân theo định luật Amdahl goodput giảm Sử dụng biện pháp giảm tải để tránh q tải GOODPUT SO VỚI THƠNG LƯỢNG, CĨ VÀ KHƠNG GIẢM TẢI GOODPUT (TPS) Khi không giảm tải, yêu cầu chậm lại máy khách bắt đầu hết thời gian chờ Khi giảm tải, cuối cùng, chi phí từ chối yếu tố kiểm sốt THƠNG LƯỢNG (TPS) Khơng giảm tải Có giảm tải Kiểm thử Khi trao đổi với kỹ sư phương pháp giảm tải, muốn họ chưa kiểm thử độ chịu tải dịch vụ đến thời điểm dịch vụ gặp cố xa thời điểm đó, họ nên giả định dịch vụ gặp trục trặc theo cách họ không mong muốn Tại Amazon, chúng tơi dành nhiều thời gian để kiểm tra độ chịu tải dịch vụ Việc tạo biểu đồ phần trước viết giúp vạch đường sở cho hiệu tải theo dõi hiệu thay đổi dịch vụ theo thời gian Có nhiều loại kiểm thử độ chịu tải Một số kiểm thử độ chịu tải đảm bảo nhóm tự động tăng quy mơ lượng tải tăng, kiểm thử khác sử dụng kích thước nhóm cố định Nếu kiểm thử độ chịu tải, tính khả dụng dịch vụ giảm nhanh thơng lượng tăng, dấu hiệu tốt cho thấy dịch vụ cần chế giảm tải bổ sung Kết kiểm thử độ chịu tải lý tưởng goodput trạng thái bình ổn sau tăng dịch vụ gần đạt đến công suất cao giữ nguyên có thêm thơng lượng Các cơng cụ Chaos Monkey giúp thực kiểm thử kỹ thuật mô trạng thái rối loạn (chaos engineering) dịch vụ Ví dụ: cơng cụ làm CPU q tải làm gói liệu để mơ tình trạng xảy tải Một kỹ thuật kiểm thử khác sử dụng thực kiểm thử tạo tải có sẵn (cịn gọi canary), dẫn hướng tải trì liên tục (thay tăng khối lượng tải) đến mơi trường kiểm thử, bắt đầu loại bỏ máy chủ khỏi môi trường kiểm thử Điều tăng thơng lượng cung cấp phiên bản, từ giúp chúng tơi kiểm thử thông lượng phiên Kỹ thuật tăng lượng tải phi tự nhiên cách giảm kích thước nhóm hữu ích để kiểm thử riêng biệt dịch vụ, khơng phải giải pháp thay hồn hảo cho kiểm thử độ chịu tải toàn diện Một kiểm thử độ chịu tải toàn diện, bao quát tăng lượng tải lên phần phụ thuộc dịch vụ, từ phơi bày khả gây cản trở khác Trong q trình kiểm thử, chúng tơi khơng qn đo đạc tính khả dụng độ trễ máy khách bên cạnh liệu tương tự máy chủ Khi tính khả dụng máy khách bắt đầu giảm, tăng lượng tải vượt xa giá trị tải tương ứng thời điểm Nếu biện pháp giảm tải có hiệu quả, goodput Sử dụng biện pháp giảm tải để tránh tải giữ nguyên trạng thái ổn định thông lượng cung cấp vượt khả tương ứng theo tỷ lệ dịch vụ Kiểm thử tải vô quan trọng trước khám phá chế để tránh tải Mỗi chế có phức tạp riêng Ví dụ: xem xét tất lựa chọn cấu hình framework dịch vụ mà tơi nhắc đến phần đầu viết khó khăn việc có giá trị mặc định xác Mỗi chế tránh tải thêm biện pháp bảo vệ khác có hiệu hạn chế Bằng cách kiểm thử, nhóm phát điểm gây cản trở hệ thống định kết hợp biện pháp bảo vệ cần thiết để xử lý tình trạng tải Khả hiển thị thông tin chi tiết Tại Amazon, với kỹ thuật sử dụng để bảo vệ dịch vụ khỏi tình trạng q tải, chúng tơi suy nghĩ cẩn thận số thông tin chi tiết mà cần biện pháp đối phó tải có hiệu lực Khi biện pháp bảo vệ giảm hiệu (brownout) từ chối u cầu, điều làm giảm tính khả dụng dịch vụ Khi dịch vụ hiểu nhầm từ chối yêu cầu cho dù khả tiếp nhận (ví dụ số lượng kết nối tối đa bị đặt thấp), tạo báo động giả Chúng cố gắng giữ tỷ lệ báo động giả dịch vụ mức Nếu nhóm thấy tỷ lệ báo động giả dịch vụ thường xuyên lớn 0, dịch vụ bị điều chỉnh nhạy cảm, máy chủ riêng lẻ thường xuyên tải có vấn đề tăng giảm quy mơ cân tải Trong trường hợp vậy, chúng tơi thực vài điều chỉnh hiệu ứng dụng chuyển sang loại phiên lớn để dịch vụ xử lý tình trạng cân tải tầm kiểm sốt Về thơng tin chi tiết, biện pháp giảm tải từ chối u cầu, chúng tơi đảm bảo có cơng cụ phù hợp để biết máy khách ai, họ gọi hoạt động thông tin khác giúp điều chỉnh biện pháp bảo vệ Chúng sử dụng cảnh báo để phát xem biện pháp phịng chống có từ chối lượng lớn lưu lượng hay không Trong trường hợp giảm hiệu năng, ưu tiên tăng khả tiếp nhận xác định điểm gây cản trở Có điều đáng cân nhắc nhỏ quan trọng xung quanh khả hiển thị thông tin chi tiết biện pháp giảm tải Chúng phát việc không làm nhiễu sổ độ trễ dịch vụ độ trễ dịch vụ không thành công quan trọng Dù độ trễ yêu cầu giảm tải phải cực thấp so với yêu cầu khác Ví dụ: dịch vụ giảm tải 60% lưu lượng, độ trễ trung vị dịch vụ trơng tuyệt độ trễ yêu cầu thành công tệ độ trễ bị báo cáo mức ảnh hưởng yêu cầu nhanh chóng thất bại Ảnh hưởng biện pháp giảm tải đến khả tự động thay đổi quy mô cố Vùng sẵn sàng Nếu bị đặt cấu hình sai, biện pháp giảm tải vơ hiệu hóa khả tự động thay đổi quy mô hoạt động Hãy xem xét ví dụ sau: dịch vụ đặt cấu hình để thay đổi quy mơ theo CPU đặt cấu hình giảm tải để từ chối yêu cầu mức CPU mục tiêu tương tự Trong trường hợp này, hệ thống giảm tải giảm số lượng yêu cầu để giữ lượng tải CPU mức thấp, khả thay đổi quy mô hoạt động không nhận nhận tín hiệu bị trễ để khởi chạy phiên Chúng cẩn thận xem xét logic giảm tải đặt giới hạn cho khả tự động điều chỉnh quy mô để xử lý cố Vùng sẵn sàng Các dịch vụ điều chỉnh quy mô đến mức độ mà khả tiếp nhận Vùng sẵn sàng trở nên khơng khả dụng trì mục tiêu độ trễ Các nhóm Amazon thường xem xét số hệ thống CPU để ước tính dịch vụ gần mức giới hạn khả tiếp nhận đến đâu Tuy nhiên với biện pháp giảm tải, nhóm chạy gần đến mức mà yêu cầu bị từ chối mức mà số hệ thống ra, khơng có khả tiếp nhận vượt mức cung cấp để xử lý cố Vùng sẵn sàng Với biện pháp giảm tải, chúng Sử dụng biện pháp giảm tải để tránh tải cần phải đặc biệt chắn để kiểm thử dịch vụ cách chia nhỏ nhằm hiểu khả tiếp nhận khả tối đa nhóm thời điểm Thực tế, chúng tơi sử dụng biện pháp giảm tải để tiết kiệm chi phí cách định hình lưu lượng khơng quan trọng ngồi thời điểm cao điểm Ví dụ: nhóm xử lý lưu lượng trang web cho amazon.com, nhóm định lưu lượng trình thu thập liệu tìm kiếm khơng đáng để tăng quy mơ nhằm đạt khả dự phịng đầy đủ cho Vùng sẵn sàng Tuy nhiên vô cẩn trọng với cách tiếp cận Không phải tất u cầu có chi phí việc chứng minh dịch vụ cần phải cung cấp khả dự phòng cho Vùng sẵn sàng để vừa dành cho lưu lượng truy cập người vừa để loại bỏ lưu lượng thu thập liệu vượt mức yêu cầu thiết kế cẩn thận, kiểm thử liên tục cân nhắc thận trọng từ doanh nghiệp Và máy khách dịch vụ dịch vụ đặt cấu hình theo cách này, hành vi dịch vụ trình xảy cố Vùng sẵn sàng giống sụt giảm nghiêm trọng tính khả dụng thay tính giảm tải khơng quan trọng Vì lý này, kiến trúc hướng dịch vụ, cố gắng thúc đẩy kiểu định hình sớm tốt (chẳng hạn dịch vụ nhận yêu cầu ban đầu từ máy khách) thay cố gắng đưa định ưu tiên toàn hệ thống Cơ chế giảm tải Khi thảo luận biện pháp giảm tải kịch lường trước, việc tập trung vào nhiều điều kiện dự đốn dẫn đến suy giảm hiệu quan trọng Tại Amazon, dịch vụ trì khả tiếp nhận vượt mức đủ để xử lý cố Vùng sẵn sàng mà không cần thêm khả tiếp nhận Các dịch vụ dùng biện pháp điều chỉnh lưu lượng (throttling) để đảm bảo khơng có khác biệt tất máy khách Tuy nhiên, bất chấp biện pháp bảo vệ vận hành này, dịch vụ có khả tiếp nhận định thời điểm bất kỳ, trở nên tải nhiều lý Những lý bao gồm lưu lượng truy cập tăng đột ngột, khả tiếp nhận nhóm bị đột ngột (do triển khai lý khác), máy khách chuyển từ thực yêu cầu giá rẻ (như đọc nhớ đệm) sang yêu cầu đắt tiền (như yêu cầu xử lý thành phần khơng có nhớ đệm (cache miss) ghi nhớ đệm) Khi trở nên tải, dịch vụ phải hồn thành u cầu tiếp nhận Đó điều mà dịch vụ phải làm để tự bảo vệ khỏi việc suy giảm hiệu Trong phần lại phần này, thảo luận số cân nhắc kỹ thuật mà sử dụng nhiều năm để quản lý vấn đề tải Hiểu rõ chi phí việc ngừng xử lý yêu cầu Chúng đảm bảo kiểm thử độ chịu tải vượt xa thời điểm goodput ổn định sau tăng Một lý cho phương pháp để đảm bảo ngừng xử lý yêu cầu giảm tải, chi phí hành động cần phải nhỏ Chúng tơi thấy thật dễ dàng bỏ lỡ câu lệnh ghi nhật ký tình cờ cài đặt socket Điều khiến việc ngừng xử lý u cầu có chi phí đắt đỏ nhiều sơ với yêu cầu Trong trường hợp hoi, việc nhanh chóng ngừng xử lý yêu cầu đắt đỏ việc giữ lại yêu cầu Trong trường hợp này, làm chậm yêu cầu bị từ chối để khớp với độ trễ (ở mức nhỏ nhất) phản hồi thành công Tuy nhiên, điều quan trọng phải làm điều chi phí việc giữ lại yêu cầu thấp có thể, ví dụ u cầu không liên kết với luồng ứng dụng Ưu tiên yêu cầu Khi bị tải, máy chủ có hội để phân loại yêu cầu đến để định xem nên chấp nhận từ chối yêu cầu Yêu cầu quan trọng mà máy chủ nhận yêu cầu ping từ cân tải Nếu máy chủ không đáp ứng kịp thời yêu cầu ping, cân tải ngừng gửi yêu cầu đến máy chủ khoảng thời gian máy chủ không hoạt động Và kịch giảm Sử dụng biện pháp giảm tải để tránh tải công suất, điều cuối mong đợi giảm kích thước nhóm Ngồi u cầu ping, lựa chọn ưu tiên yêu cầu khác tùy theo dịch vụ Hãy xem xét dịch vụ web cung cấp liệu để kết xuất amazon.com Một gọi dịch vụ hỗ trợ kết xuất trang web cho trình thu thập mục tìm kiếm quan trọng so với yêu cầu từ người u cầu trình thu thập thơng tin quan trọng hồn tồn chuyển sang khoảng thời gian thấp điểm Tuy nhiên, mơi trường phức tạp amazon.com nơi có số lượng lớn dịch vụ hợp tác với nhau, dịch vụ sử dụng phương pháp đoán ưu tiên bị xung đột, tính khả dụng tồn hệ thống bị ảnh hưởng cơng việc bị lãng phí Chúng ta sử dụng đồng thời biện pháp ưu tiên điều chỉnh để tránh giới hạn điều chỉnh nghiêm ngặt bảo vệ dịch vụ khỏi tải Tại Amazon, trường hợp cho phép máy khách vượt giới hạn điều chỉnh đặt cấu hình, yêu cầu vượt mức từ máy khách mức ưu tiên thấp so với yêu cầu hạn mức từ máy khách khác Chúng dành nhiều thời gian tập trung vào thuật toán phân bổ để giảm thiểu khả tiếp nhận vượt mức trở nên không khả dụng, sau cân nhắc thiệt hơn, ưu tiên khối lượng cơng việc cung cấp dự đốn thay khối lượng cơng việc khơng thể đốn trước Chú ý tới đồng hồ Nếu dịch vụ trình phân phối yêu cầu nhận thấy máy khách hết thời gian chờ, dịch vụ bỏ qua phần cịn lại cơng việc không thực yêu cầu thời điểm Nếu khơng, máy chủ tiếp tục làm việc theo yêu cầu phản hồi muộn từ máy chủ vơ nghĩa Từ phía máy chủ, phản hồi thành cơng Nhưng từ phía máy khách hết thời gian chờ, lỗi Một cách để tránh việc làm vô nghĩa để máy khách đưa dấu hiệu thời gian chờ vào yêu cầu cho máy chủ biết chờ Máy chủ đánh giá dấu hiệu ngừng xử lý yêu cầu không thành công với chi phí thấp Gợi ý thời gian chờ biểu thị dạng thời gian tuyệt đối khoảng thời gian Thật không may, máy chủ hệ thống phân tán có tiếng tệ việc thống thời gian xác Bù lại, Amazon Time Sync Service đồng hóa thời gian phiên Amazon Elastic Compute Cloud (Amazon EC2) bạn với nhóm đồng hồ nguyên tử điều khiển vệ tinh Khu vực AWS Các đồng hồ đồng hóa quan trọng Amazon cho mục đích ghi nhật ký So sánh hai tệp nhật ký máy chủ có đồng hồ không đồng khiến việc khắc phục cố chí cịn khó so với bắt đầu Cách lại để “xem đồng hồ” đo khoảng thời gian máy Máy chủ đo xác khoảng thời gian trơi qua cục không cần nhận chấp thuận từ máy chủ khác Thật không may, việc biểu thị thời gian chờ theo khoảng thời gian có vấn đề riêng Đầu tiên, tính bạn sử dụng phải giám sát không chạy lùi máy chủ đồng với Giao thức đồng thời gian mạng (NTP) Một vấn đề khó khăn nhiều để đo khoảng thời gian, máy chủ phải biết cần khởi động đồng hồ bấm Trong số trường hợp tải, khối lượng yêu cầu khổng lồ xếp hàng đệm Giao thức kiểm sốt truyền tải (TCP), đó, máy chủ đọc yêu cầu từ đệm, máy khách hết thời gian Bất hệ thống Amazon có dấu hiệu thời gian chờ, cố gắng áp dụng dấu hiệu với đối tượng trực tiếp Ở nơi mà kiến trúc hướng dịch vụ bao gồm nhiều bước nhảy, chúng tơi truyền “thời gian cịn lại” thời hạn bước nhảy để dịch vụ từ máy chủ đến máy khách cuối chuỗi gọi nhận cần thời gian để phản hồi thành công Khi máy chủ biết thời hạn máy khách, có câu hỏi vị trí thực thi thời hạn việc triển khai dịch vụ Nếu dịch vụ có hàng đợi u cầu, chúng tơi sử dụng hội để đánh giá thời gian chờ sau giải yêu cầu Nhưng điều phức tập chúng tơi khơng biết cần để giải yêu cầu Một số hệ thống ước tính thời gian cần để xử lý yêu cầu Sử dụng biện pháp giảm tải để tránh tải API hệ thống sớm ngừng xử lý yêu cầu thời hạn mà máy khách báo cáo vượt độ trễ ước tính Tuy nhiên, thứ đơn giản Ví dụ: thao tác xử lý thành phần có nhớ đệm (cache hit) diễn nhanh so với thành phần khơng có nhớ đệm (cache miss) ước tính khơng biết trước cache hit hay cache miss Hoặc tài nguyên backend dịch vụ phân vùng có vài phân vùng bị chậm Có nhiều hội để thực biện pháp tài tình, tài tình gây tác dụng ngược tình khơng lường trước Theo kinh nghiệm chúng tôi, việc thực thi thời gian chờ máy khách máy chủ tốt so với giải pháp thay thế, bất chấp phức tạp đánh đổi Thay yêu cầu chồng chất máy chủ xử lý u cầu khơng cịn quan trọng ai, thấy việc thực thi “thời gian tồn (time-to-live) theo yêu cầu” bỏ yêu cầu không thành công có ích Kết thúc chúng tơi bắt đầu Chúng tơi khơng muốn cơng việc có ích bị lãng phí, đặc biệt trường hợp tải Việc bỏ cơng việc tạo vịng lặp phản hồi tích cực làm tăng tình trạng q tải máy khách thường thử yêu cầu lại dịch vụ không phản hồi kịp thời Khi điều xảy ra, yêu cầu tốn tài nguyên trở thành nhiều yêu cầu tốn tài nguyên, làm tăng khối lượng tải dịch vụ lên nhiều lần Khi máy khách hết thời gian thử lại, chúng thường chờ đợi phản hồi kết nối lại tạo yêu cầu kết nối khác Nếu máy chủ hoàn thành yêu cầu phản hồi, máy khách khơng tiếp nhận máy khách chờ phản hồi từ yêu cầu thử lại Vấn đề cơng việc bị lãng phí lý cố gắng thiết kế dịch vụ để thực công việc bị giới hạn Ở nơi chúng tơi đưa API trả liệu lớn (hoặc thực danh sách nào), API có dạng API hỗ trợ phân trang Các API trả phần kết mã thơng báo mà khách hàng sử dụng để yêu cầu thêm liệu Chúng thấy việc ước tính tải bổ sung dịch vụ dễ dàng máy chủ xử lý yêu cầu có giới hạn với dung lượng nhớ, CPU băng thơng mạng Rất khó để thực hiên việc kiểm sốt đầu vào máy chủ phải tiếp nhận để xử lý yêu cầu Một hội tinh vi để ưu tiên yêu cầu nằm cách máy khách sử dụng API dịch vụ Ví dụ: cho dịch vụ có API: start() end() Để hồn tất cơng việc, máy khách cần phải gọi API Trong trường hợp đó, dịch vụ nên ưu tiên yêu cầu end() thay yêu cầu start() Nếu ưu tiên start(), máy khách hồn thành cơng việc bắt đầu, dẫn đến tình trạng giảm hiệu Phân trang nơi cần ý để khơng lãng phí cơng việc Nếu máy khách phải tạo vài yêu cầu theo trình tự để phân trang thơng qua kết từ dịch vụ, thấy cố sau trang N-1 bỏ kết quả, gọi dịch vụ N-2 tất lần thử lại mà máy khách thực suốt trình bị lãng phí Điều gợi ý yêu cầu end(), yêu cầu trang nên ưu tiên sau yêu cầu phân trang trang sau Điều nhấn mạnh lý thiết kế dịch vụ để thực công việc bị giới hạn không phân trang vô tận thông qua dịch vụ mà máy khách gọi hoạt động đồng Chú ý tới hàng đợi Việc xem xét thời lượng yêu cầu quản lý hàng đợi nội có ích Rất nhiều kiến trúc dịch vụ đại sử dụng hàng đợi nhớ để kết nối tập hợp luồng để xử lý yêu cầu giai đoạn khác công việc Framework dịch vụ web có thực thi thường có hàng đợi đặt cấu hình phía trước Với dịch vụ dựa TCP nào, hệ điều hành trì đệm cho socket đệm chứa khối lượng lớn u cầu bị tích tụ Khi kéo cơng việc khỏi hàng đợi, chúng tơi sử dụng hội để kiểm tra xem công việc hàng đợi Ít nhất, chúng tơi cố gắng ghi lại khoảng thời gian số dịch vụ Ngồi việc giới hạn kích thước hàng đợi, chúng tơi cịn thấy việc đặt giới hạn vào khoảng thời gian mà yêu cầu đến nằm hàng đợi vô quan trọng, yêu cầu khỏi 10 Sử dụng biện pháp giảm tải để tránh tải hàng đợi yêu cầu cũ Việc giải phóng máy chủ để làm việc yêu cầu có hội thành cơng cao Chúng tơi tìm cách sử dụng hàng đợi Vào sau, Ra trước (Last in, First out – LIFO), giao thức hỗ trợ (Quy trình HTTP/1.1 yêu cầu kết nối TCP cho không hỗ trợ hàng đợi LIFO, HTTP/2 thường lại có) Cân tải xếp hàng đợi yêu cầu kết nối đến dịch vụ bị tải tính gọi hàng đợi phát sinh Các hàng đợi dẫn đến tình trạng giảm hiệu máy chủ, cuối nhận yêu cầu, lại khơng biết u cầu hàng đợi Biện pháp mặc định an toàn thường sử dụng cấu hình tràn, nhanh chóng ngừng xử lý thay cho vào hàng đợi yêu cầu vượt mức Tại Amazon, trình học đưa vào hệ dịch vụ Elastic Load Balancing (ELB) Cân tải cổ điển sử dụng hàng đợi phát sinh Cân tải ứng dụng từ chối lưu lượng vượt mức Bất kể cấu hình gì, nhóm Amazon giám sát số cân tải có liên quan độ sâu hàng đợi phát sinh số lượng tràn cho dịch vụ họ Theo kinh nghiệm chúng tôi, tầm quan trọng ý tới hàng đợi khơng thể bị cường điệu hóa Tơi thường ngạc nhiên thấy hàng đợi nhớ nơi thường khơng nghĩ tìm chúng, hệ thống thư viện mà dựa vào Khi đào sâu vào hệ thống, tơi thấy việc cho có hàng đợi mà khơng biết hữu ích Tất nhiên, việc kiểm thử tình trạng q tải cung cấp nhiều thơng tin hữu ích đào sâu vào mã, miễn tơi đưa trường hợp kiểm thử thực tế xác Bảo vệ khỏi tình trạng tải lớp thấp Dịch vụ tạo nên nhiều lớp ─ từ cân tải đến hệ điều hành với khả netfilter iptables, framework dịch vụ mã ─ lớp cung cấp số khả để bảo vệ dịch vụ Các proxy HTTP NGINX thường hỗ trợ tính kết nối tối đa (max_conns) để giới hạn số lượng yêu cầu kết nối hoạt động mà proxy chuyển đến máy chủ backend Đây chế hữu ích chúng tơi học cách sử dụng khả phương sách cuối thay lựa chọn bảo vệ mặc định Với proxy, thật khó để ưu tiên lưu lượng quan trọng, việc theo dõi số lượng yêu cầu thô diễn cung cấp thông tin không xác việc dịch vụ có thật q tải hay không Trong phần đầu viết này, mô tả thách thức thời gian làm việc tơi nhóm Framework dịch vụ Vào thời điểm đó, chúng tơi cố gắng cung cấp cho nhóm Amazon giá trị mặc định khuyến nghị cho số kết nối tối đa để đặt cấu hình cân tải họ Cuối cùng, chúng tơi gợi ý nhóm đặt số kết nối tối đa cao cho cân tải proxy để máy chủ triển khai thuật toán giảm tải xác thơng tin cục Tuy nhiên, giá trị kết nối tối đa không vượt số luồng trình nghe, quy trình trình nghe đặc tả tệp để máy chủ có tài nguyên nhằm xử lý yêu cầu kiểm tra trạng thái quan trọng từ cân tải Các tính hệ điều hành để hạn chế sử dụng tài nguyên máy chủ mạnh mẽ hữu ích để sử dụng trường hợp khẩn cấp Và chúng tơi biết tình trạng q tải xảy ra, đảm bảo chuẩn bị cho trường hợp cách sử dụng tài liệu vận hành với lệnh cụ thể sẵn sàng Tiện ích iptables đặt giới hạn cho số lượng kết nối mà máy chủ chấp nhận từ chối kết nối vượt mức với chi phí thấp nhiều so với quy trình máy chủ Tiện ích cấu hình với điều khiển tinh vi hơn, cho phép kết nối tốc độ giới hạn chí cho phép tốc độ kết nối giới hạn số lượng giới hạn địa IP nguồn Bộ lọc IP nguồn mạnh mẽ lại không áp dụng cho cân tải truyền thống Tuy nhiên, Network Load Balancer ELB bảo toàn IP nguồn người gọi lớp hệ điều hành thơng qua ảo hóa mạng, làm cho quy tắc iptables lọc IP nguồn hoạt động mong đợi 11 Sử dụng biện pháp giảm tải để tránh tải Bảo vệ theo lớp Trong số trường hợp, máy chủ hết tài nguyên để chí từ chối yêu cầu mà không bị chậm lại Với thực tế này, xem xét tất bước nhảy máy chủ máy khách để xem cách chúng hợp tác giúp giảm tải mức Ví dụ: số dịch vụ AWS bao gồm tùy chọn giảm tải theo mặc định Khi đặt Amazon API Gateway trước dịch vụ, chúng tơi đặt cấu hình tốc độ yêu cầu tối đa mà API chấp nhận Khi dịch vụ đứng sau API Gateway, Cân tải ứng dụng Amazon CloudFront, chúng tơi đặt cấu hình AWS WAF để giảm lưu lượng vượt mức số số Khả hiển thị thông tin chi tiết gây chút căng thẳng Việc từ chối sớm quan trọng nơi có chi phí thấp để giảm lưu lượng vượt mức, lúc phải đánh đổi khả hiển thị thơng tin chi tiết Đó lý chúng tơi bảo vệ theo lớp: nhằm cho phép máy chủ tiếp nhận nhiều khả làm việc ngừng xử lý yêu cầu vượt mức, ghi lại đủ thông tin để biết lưu lượng bị ngừng xử lý Do có nhiều lưu lượng mà máy chủ ngừng xử lý, chúng tơi dựa vào lớp phía trước để bảo vệ máy chủ khỏi lưu lượng vượt mức Nghĩ khác tải Trong viết này, thảo luận cách nhu cầu giảm tải phát sinh từ thực tế hệ thống trở nên chậm chúng giao nhiều công việc đồng thời hơn, yếu tố giới hạn tranh chấp tài ngun xuất Vịng phản hồi tình trạng tải điều khiển độ trễ, thứ cuối gây lãng phí cơng việc, khuếch đại tốc độ yêu cầu chí tải Yếu tố này, thúc đẩy Định luật khả mở rộng phổ quát Định luật Amdahl, quan trọng để đường vòng cách giảm tải vượt mức trì hiệu ổn định, dự đốn trước tình trạng q tải Việc tập trung vào hiệu suất ổn định, dự đoán nguyên tắc thiết kế quan trọng làm tảng cho dịch vụ Amazon Ví dụ: Amazon DynamoDB dịch vụ sở liệu cung cấp hiệu suất tính khả dụng dự đốn quy mơ lớn Ngay khối lượng công việc tăng đột biến vượt tài nguyên cung cấp, DynamoDB trì độ trễ goodput dự đốn cho khối lượng cơng việc Các yếu tố khả tự động thay đổi quy mô DynamoDB, khả tiếp nhận thích ứng theo nhu cầu phản ứng nhanh để tăng tốc độ goodput nhằm thích nghi với khối lượng cơng việc tăng Trong thời gian đó, goodput ổn định giữ cho dịch vụ lớp DynamoDB hoạt động với hiệu dự đốn được, cải thiện tính ổn định toàn hệ thống AWS Lambda cung cấp ví dụ chí cịn rộng tập trung vào hiệu suất dự đốn Khi sử dụng Lambda để triển khai dịch vụ, lệnh gọi API chạy môi trường thực thi riêng với lượng tài ngun điện tốn ổn định phân bổ cho lệnh, vào thời điểm, mơi trường thực thi hoạt động yêu cầu cụ thể Điều khác với mơ hình dựa máy chủ, nơi máy chủ định hoạt động nhiều API Việc cách ly lệnh gọi API với tài nguyên độc lập riêng lệnh gọi (tài ngun điện tốn, nhớ, ổ đĩa, mạng) phá vỡ định luật Amdahl mức độ đó, tài ngun lệnh gọi API không cạnh tranh với tài nguyên lệnh gọi API khác Do đó, thông lượng vượt goodput, goodput ổn định thay giảm xuống mơi trường dựa máy chủ truyền thống Đây thuốc chữa bách bệnh, phần phụ thuộc chậm lại khiến tính tương tranh tăng lên Tuy nhiên, kịch này, kiểu tranh chấp tài nguyên máy chủ mà thảo luận viết không áp dụng Sự cô lập tài nguyên lợi ích nhỏ quan trọng mơi trường điện toán serverless đại AWS Fargate, Amazon Elastic Container Service (Amazon ECS) AWS Lambda Tại Amazon, thấy cần làm nhiều việc để triển khai giảm tải, từ việc điều chỉnh tập hợp 12 Sử dụng biện pháp giảm tải để tránh tải luồng, đến chọn cấu hình hồn hảo cho kết nối cân tải tối đa Rất khó khơng thể tìm thấy giá trị mặc định hợp lý cho loại cấu hình chúng phụ thuộc vào đặc điểm vận hành hệ thống Các mơi trường điện tốn serverless cung cấp cách ly tài nguyên mức thấp hiển thị nút mức cao hơn, điều khiển điều chỉnh lưu lượng tính tương tranh, để bảo vệ chống tải Ở mức độ đó, thay theo đuổi giá trị cấu hình mặc định hồn hảo, chúng tơi hồn tồn bỏ qua cấu hình bảo vệ khỏi loại tải mà không cần cấu hình Đọc thêm Định luật khả mở rộng phổ quát Định luật Amdahl Kiến trúc làm việc với kiện theo giai đoạn (SEDA) Định luật Little (mô tả tính tương tranh hệ thống cách xác định khả tiếp nhận hệ thống phân tán) Kể chuyện Định luật Little, Blog Marc Elastic Load Balancing Deep Dive and Best Practices, thuyết trình re:Invent 2016 (mơ tả q trình phát triển Elastic Load Balancing để dừng đưa yêu cầu vượt mức vào hàng đợi) Burgess, Thinking in Promises: Designing Systems for Cooperation (Suy nghĩ với tư Promise: Thiết kế hệ thống để hợp tác), O’Reilly Media, 2015 13