6

Tôi có một trang web chạy trên amazon beanstalk đàn hồi với mẫu lưu lượng truy cập sau:Cài đặt Cloudwatch/Autoscale chính xác cho các đột biến lưu lượng truy cập cực kỳ ngắn trên Amazon Web Services là gì?

  • ~ 50 người dùng đồng thời bình thường.
  • ~ 2000 người dùng đồng thời trong 1/2 phút khi bài đăng được tạo lên trang Facebook.

Dịch vụ web của Amazon tuyên bố có thể nhanh chóng mở rộng đến những thách thức như thế này nhưng thiết lập đồng hồ "Lớn hơn x trong hơn 1 phút" không xuất hiện đủ nhanh cho mẫu lưu lượng truy cập này?

Thông thường trong vòng vài giây tất cả các trường hợp ec2 gặp sự cố, giết tất cả chỉ số đồng hồ và toàn bộ trang web bị ngừng trong 4/6 phút. Cho đến nay tôi vẫn chưa tìm thấy một cấu hình hoạt động cho senario này.

Dưới đây là đồ thị của một sự kiện nhỏ hơn mà còn giết chết trang web: enter image description here

+0

Biểu đồ hiển thị thử nghiệm bao vây 200 người dùng liên tiếp trong 2 phút. Đây là độ dài điển hình nhưng ~ 20% lưu lượng truy cập khi liên kết được đăng. – Ben

+0

Bạn sẽ bị tính phí cho cả một giờ nếu bạn mở rộng quy mô, Ngay cả khi có thể mở rộng nhanh (sử dụng ami sẵn sàng phục vụ) sẽ cuộn lên một loạt các máy chủ theo yêu cầu để thả chúng sau mười phút. – theist

Trả lời

1

Các gợi ý từ AWS là như sau:

Chúng tôi luôn làm việc để làm cho hệ thống của chúng tôi phản ứng nhanh hơn, nhưng nó là thách thức để cung cấp máy chủ ảo tự động với thời gian đáp ứng của một vài giây là bạn sử dụng trường hợp xuất hiện để yêu cầu. Có lẽ có giải pháp thay thế nhanh hơn hoặc nhiều hơn khả năng phục hồi khi các yêu cầu bắt đầu tăng.

Bạn đã quan sát xem trang web có hoạt động tốt hơn không nếu bạn sử dụng loại cá thể lớn hơn hoặc số lượng cá thể lớn hơn ở trạng thái ổn định? Đó có thể là một phương pháp để có khả năng phục hồi nhanh chóng trong các yêu cầu gửi đến. Mặc dù tôi nhận ra nó có thể không phải là chi phí hiệu quả nhất, bạn có thể thấy điều này là một sửa chữa nhanh chóng.

Một cách tiếp cận khác có thể là điều chỉnh báo thức của bạn để sử dụng ngưỡng hoặc số liệu phản ánh (hoặc dự đoán) nhu cầu của bạn tăng nhanh hơn. Ví dụ: Ví dụ: bạn có thể thấy hiệu suất tốt hơn nếu bạn đặt báo thức thành thêm phiên bản sau khi bạn vượt quá 75 hoặc 100 người dùng. Bạn có thể đã là làm điều này.Bên cạnh đó, trường hợp sử dụng của bạn có thể có một chỉ báo khác là dự đoán nhu cầu tăng, ví dụ như đăng trên trang Facebook của bạn có thể tăng một yêu cầu quan trọng lên một số giây hoặc thậm chí một phút. Sử dụng chỉ số tùy chỉnh CloudWatch để theo dõi giá trị đó và sau đó đặt báo thức thành Auto Scale trên đó cũng có thể là giải pháp tiềm năng .

Vì vậy, tôi nghĩ câu trả lời tốt nhất là chạy nhiều trường hợp hơn với lưu lượng truy cập thấp hơn và sử dụng chỉ số tùy chỉnh để dự đoán lưu lượng truy cập từ nguồn bên ngoài. Tôi sẽ cố gắng, ví dụ, theo dõi Facebook và Twitter cho các bài đăng có liên kết đến trang web và mở rộng quy mô ngay lập tức.

3

có những liên kết này đăng tải dự đoán? Nếu vậy, bạn có thể sử dụng Scaling by Schedule hoặc thay thế bạn có thể thay đổi giá trị DESIRED-CAPACITY của Nhóm quy mô tự động hoặc thậm chí kích hoạt as-execute-policy để chia tỷ lệ ngay trước khi liên kết của bạn được đăng.

Bạn có biết mình có thể có nhiều chính sách chia tỷ lệ trong một nhóm không? Vì vậy, bạn có thể có chính sách Tự động chia tỷ lệ đặc biệt cho trường hợp của mình, ví dụ như SCALE_OUT_HIGH bổ sung thêm 10 trường hợp cùng một lúc. Hãy xem lệnh as-put-scaling-policy.

Ngoài ra, bạn cần phải kiểm tra mã của mình và tìm cổ chai.

Bạn sử dụng HTTPD nào? Xem xét việc chuyển sang Nginx vì phần mềm tiêu thụ tài nguyên nhanh hơn và ít tốn kém hơn Apache. Hãy thử sử dụng Memcache ... NoSQL như Redis cho hight đọc và viết là lựa chọn tốt là tốt.