使用 Elastic Load Balancer 進行水平擴展的小型與中型 EC2 實例
我正在就擴展 Amazon EC2 實例進行一些辯論。我使用 ASP.NET 開發了我的應用程序，因此我必須選擇使用 Windows EC2 實例。MySQL 和圖像由其他實例提供，因此（目前）僅針對 Web 應用程序實例進行縮放。
我的選擇（目前）：
- 小型 64 位實例- 從 32 位小型實例開始，創建彈性負載均衡器，在流量增加時按需添加更多小型實例（取決於我設置的 CloudWatch 規範）。
- 中高 CPU 實例- 從中高 CPU 實例開始（成本更高，但功能更強大），創建彈性負載均衡器，並在需要時添加更多中高 CPI 實例。
第一個選項更便宜，並且允許應用程序逐漸擴展，與 Medium 實例相比，Medium 實例僅適用於 32 位，所以我有點鎖定到 32 位。我不想擴大規模，因為我更喜歡水平擴大規模。這意味著當流量低時，我不會支付Medium實例的高價。因此，對於第二個選項，我可以選擇使用 64 位小型實例，並通過在彈性負載均衡器下自動添加更多伺服器來水平擴展，這取決於從 Amazon CloudWatch 獲得的規格（即 CPU、RAM 等）。
我的問題是我很難決定選擇哪一個。我讀到中高 CPU 實例比小型實例強大 5 倍。但是價格開始有點激進。一般來說，我更喜歡在需要時通過添加更多小型實例來支付更少的費用並進行擴展。
我需要你的幫助來選擇走哪條路。每種方法的優點是什麼？如果有優勢的話，為什麼在水平擴展方面獲得中等高 CPU 比小 CPU 更好。畢竟，圍繞雲架構的所有想法是能夠在給定的時間範圍內節省您不需要其計算能力的伺服器上的成本。
我通過對 MySQL 的頁面和 SQL 查詢（存在於 Xeround 上，它解決了 DB 的擴展問題）使用記憶體來優化實例。我的數據庫相對較小（1000 行數據不多），所以小實例上的 1.7GB 記憶體可以滿足我的記憶體需求。我認為當流量增加時，主要問題將出在 CPU 上。此外，儲存空間也非常小，僅託管我的網站 ASPX 頁面。
我假設該應用程序每天可以吸引一萬甚至更多的訪問者。所以擴展是必須的——但是小實例水平擴展是明智之舉嗎？- 對於高流量的 Web 應用程序，它會是更明智的選擇嗎？
現在我更傾向於小實例 + Elastic Load Balancer 解決方案。隨著應用程序的增長，少付多付似乎是合乎邏輯的。
等待您的知識解答。謝謝。
一定要從小處著手。您可以隨時移動到更大的實例大小。如果您在設計時考慮到水平擴展，那麼後端可以是系統的任何混合。
如果 CPU 真的是瓶頸，那麼中型是更好的選擇，因為它是 CPU 的 5 倍，成本是 2 倍。但是我懷疑您的瓶頸將與文件 io 相關，在這種情況下，中型可能僅略勝於小型。