對於Amazon Web Services上極短的流量峯值，正確的Cloudwatch/Autoscale設置是什麼？

Question

我有以下的交通模式在Amazon Elastic魔豆運行一個網站：

• 〜50個併發用戶正常。
• 〜2000個併發用戶在發佈到Facebook頁面後半分鐘。

亞馬遜網絡服務聲稱能夠快速擴展到類似這樣的挑戰，但Cloudwatch的「大於x超過1分鐘」設置對於此流量模式似乎不夠快？

一般秒內所有的EC2實例崩潰，殺害所有的CloudWatch指標和整個網站關閉4/6分鐘。到目前爲止，我還沒有找到適用於此senario的配置。

這裏是一個小事件也被打死網站的圖表：

Answer 1

從AWS的建議如下：

我們一直在努力使我們的系統更靈敏，但它是 用幾秒鐘的響應 時間自動有挑戰性的配置虛擬服務器的用例似乎需要。也許 有一種解決方法，可以更快速地響應，或者當請求開始增加時，更具彈性 。

你有沒有觀察到，如果你使用一個更大的 實例類型，或在穩定狀態下的較大數量的實例網站是否執行得更好？ 這可能是一種快速增加入站請求的方法。雖然我認識到它可能不是最具成本效益的，但您可能會發現這是一個快速解決方案。

另一種方法可能是將警報調整爲使用閾值或 度量標準，以便更快地反映（或預測）您的需求增長。 例如，如果在超過75個或100個用戶後將鬧鐘設置爲 添加實例，則可能會看到更好的性能。你可能已經是 這樣做。除此之外，您的使用案例可能有另一個指標 ，預測需求增加，例如您的Facebook頁面上發佈的帖子可能比重要的請求增加幾個 秒或甚至一分鐘。使用CloudWatch自定義指標來監視 該值，然後將警報設置爲自動縮放也可能是 潛在解決方案。

所以我認爲最好的答案是在較低的流量下運行更多的實例並使用自定義指標來預測來自外部源的流量。例如，我將嘗試監控Facebook和Twitter的帖子，鏈接到該站點並立即擴展。

Answer 2

張貼這些鏈接可以預見？如果是這樣，你可以使用Scaling by Schedule或作爲替代，你可能會改變自動縮放集團所需容量值，甚至引發as-execute-policy向外擴展你的鏈接張貼直前。

你知道你可以在一個組有多個縮放策略？因此，您可能會針對您的情況制定特殊的Auto Scaling策略，例如SCALE_OUT_HIGH，它可以一次添加10個以上的實例。看看as-put-scaling-policy命令。

此外，您還需要檢查你的代碼，並找到瓶頸。

你用什麼HTTPD？考慮切換到Nginx，因爲它比Apache更快更省資源的軟件。嘗試使用Memcache ...像Redis一樣的NoSQL讀取和寫入也是不錯的選擇。