用於處理需求峯值的EC2

Question

我正在爲執行一些cpu密集型工作的移動應用程序編寫後端。我們預計該應用在大多數情況下不會有大量使用，但會偶爾出現高需求高峯。我在想，我們應該做的是預留幾臺24/7服務器來處理低需求流量的穩定狀態，然後根據需要添加和刪除EC2實例來處理峯值。移動應用程序將首先擊中一個簡單的負載均衡服務器，在所有可用的處理服務器中執行簡單的循環用戶分配。負載平衡器將處理新的EC2實例，並根據需要將其恢復。

一些問題：

我沒寫過這樣的事情之前，這聽起來是個不錯的策略？

處理新的EC2實例的最佳方法是什麼？我想我可以提前創建X實例，根據需要設置它們（安裝軟件等），然後停止每個實例。然後，負載均衡器將根據需要啓動和停止實例（例如通過boto）。我認爲這應該比創建新實例並通過腳本或其他東西安裝所有內容更快更容易。好主意？

我在這裏關心的一件事是關閉EC2實例並重新開啓的成本。我查看了AWS使用情況報告，並且很難解釋它。我可以看到啓動停止的實例是一項潛在的昂貴操作。但是，似乎是因爲我剛開始一個停止的實例，而不是從頭開始一個新的實例，它應該不會太糟糕。這聽起來是對的嗎？

Answer 1

這是一個非常合理的策略。我以前成功地使用過它。你可能想看Elastic Load Balancing（ELB）與Auto Scaling的組合。從概念上講，兩者應該解決這個確切的問題。

回到2010年左右，ELB在某些類型的HTTP請求中遇到了一些問題，導致我們無法使用它。我明白這些問題已經解決。

由於ELB不是一個選項，我們根據需要手動從EBS快照啓動實例，並手動將它們添加到NGinX負載平衡器。這當然可以使用AWS API進行自動化，但是我們的高峯期是可預測的（月末），我們只是要求某人啓動新實例並沒有考慮自動執行任務。

當一個實例停止時，我相信您支付的唯一費用是支持實例及其數據的EBS存儲。除非您的實例有大量關聯的數據，否則EBS存儲費用應該很小。自從我上次使用AWS以來，事情可能已經發生了變化，但如果發生這種變化，我會感到驚訝。

Answer 2

首先關於成本，實例是從頭開始還是從停止狀態開始對成本沒有影響。您需要爲您使用的計算單位的數量計費。

其次，你要做的就是自動縮放。你所做的是建立一個啓動配置，指定你要使用的AMI（以及你正在使用的任何用戶數據配置，ELB和你將要使用的可用性區域，最小和最大實例數量等等）。您使用該啓動配置設置了一個擴展組，然後設置擴展策略以確定要將哪些擴展操作附加到該組，然後將雲監控警報附加到每個策略以觸發擴展操作。

您沒有儲存服務器，您連接到ELB或類似的東西。一切都基於創建一個AMI，用作所需服務器的模板。

您應該在下面的鏈接自動縮放讀了起來：

http://aws.amazon.com/autoscaling/