每個網站 1 個 EC2 實例 - 使用 EC2 在 Amazon 雲上管理多個網站
我正在管理多個網站，大多數基於 WordPress，並且都基於 LAMP 堆棧。我正在將我所有的網站遷移到亞馬遜雲。我是 AWS 的新手，我的計劃是從我最小的網站開始逐個移動 1 個網站。
我的問題是我應該將我的所有網站放在 1 個 EC2 實例上，還是將 1 個網站放在 1 個單獨的實例上？
這可能聽起來很愚蠢，因為任何人肯定會在傳統的網路託管環境中選擇後者。我之所以想到前者是因為：
- 可重複使用的 LAMP 堆棧
我可以生成我自己的 AMI，並準備好使用 LAMP 堆棧，以便我可以將它重用於我的不同網站嗎？我不選擇社區 AMI 的原因是
- 我只是不知道用哪一個
- 作為對 Linux 或 LAMP 堆棧不太了解的人，我想擁有我需要的東西，不多也不少
- 成本：將每個站點放在一個巨大的實例上，而不是將每個站點放在一個較小的實例上。我不認為應該是這種情況，但我認為問不會有什麼害處
- 難以管理多個實例
可擴展性
我敢肯定，幾個月後，與現在相比，我需要大約 3 倍的計算能力（新網站推出，現在我有 6 個，到那時我將有 10 個；現有網站的流量快速增長）。不管怎樣，假設我決定進行水平縮放，例如使用我目前使用的 3 個相同類型的實例。
所以我的進一步問題是這種情況將如何影響我是否應該分開我的站點或將所有站點放在一起放在 1/ 1 組 EC2 實例上的決定？
我知道這可能與我仍在閱讀的亞馬遜雲上的垂直和水平擴展之間的差異有關。這也可能與有關虛擬機/伺服器的知識有關，我完全是個白痴，但如有必要，我不介意弄清楚更多。然而，我想我應該問一下，因為這可能會影響我應該在亞馬遜雲方面的發展方向。如果您認為我是個懶惰的笨蛋，應該先做功課，請隨意給我一巴掌：)
非常感謝所有幫助！
免責聲明：請告知是否應將其發佈在 superuser.com 或任何 stackexchange 網站上。謝謝
首先，一些原始數據，取自S. Ostermann, et al, 2010：
基本實例規格：
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+ | Name | ECUs | RAM | Archi | I/O | Disk | Cost | Reserve | Reserved Cost | | | (Cores) | [GB] | [bit] | Perf. | [GB] | [$/h] | [$/y], [$/3y] | [$/h] | +-----------+---------+------+-------+-------+------+-------+---------------+---------------+ | m1.small | 1 (1) | 1.7 | 32 | Med | 160 | 0.1 | 325, 500 | 0.03 | | m1.large | 4 (2) | 7.5 | 64 | High | 850 | 0.4 | 1300, 200 | 0.12 | | m1.xlarge | 8 (4) | 15 | 64 | High | 1690 | 0.8 | 2600, 4000 | 0.24 | | c1.medium | 5 (2) | 1.7 | 32 | Med | 350 | 0.2 | 650, 1000 | 0.06 | | c1.xlarge | 20 (8) | 7 | 64 | High | 1690 | 0.8 | 2600, 4000 | 0.24 | +-----------+---------+------+-------+-------+------+-------+---------------+---------------+基本性能/成本分析：
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+ | System | Peak Perf. | HPL | STREAM | RandomAc. | Latency | Bandw. | GFLOP/ECU | GFLOPS/$ | | | [GFLOPS] | [GFLOPS] | [GBps] | [MUPs] | [µs] | [GBps] | | | +---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+ | m1.small | 4.4 | 1.96 | 3.49 | 11.6 | - | - | 1.96 | 19.6 | | m1.large | 17.6 | 7.15 | 2.38 | 54.35 | 20.48 | 0.7 | 1.79 | 17.9 | | m1.xlarge | 35.2 | 11.38 | 3.47 | 168.64 | 17.87 | 0.92 | 1.42 | 14.2 | | c1.medium | 22 | 3.91 | 3.84 | 46.73 | 13.92 | 2.07 | 0.78 | 19.6 | | c1.xlarge | 88 | 51.58 | 15.65 | 249.66 | 14.19 | 1.49 | 2.58 | 64.5 | | 16x m1.small | 70.4 | 27.8 | 11.95 | 77.83 | 68.24 | 0.1 | 1.74 | 17.4 | | 16x c1.xlarge | 1408 | 425.82 | 16.38 | 207.06 | 45.2 | 0.75 | 1.33 | 33.3 | +---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+實際性能通常低於理論性能的 50%。一組可能令人懷疑的值是 c1.medium 的值，它們與預期結果（例如頻寬）不太一致。
典型工作負載的 EC2 主要成本是實例成本——其他成本（頻寬、預置儲存等）通常低於總成本的 25%。人們並不期望性能可以完美擴展——這從上面的數據中可以明顯看出。尤其是在水平擴展方面，似乎隨著計算能力的增加，效率會顯著下降。
鑑於上述情況，並記住除了原始計算性能（例如 I/O 性能、記憶體等）之外還有其他因素，因此垂直擴展是最經濟的方法。
不幸的是，除了場景的經濟性之外，還有其他考慮因素。可靠性是關鍵。對於單個實例，該實例的故障會破壞您的整個設置。一種可能的解決方案可能是自動擴展（即保持實例計數為 1），但是單個實例仍然容易出現在給定可用區等中可能出現的問題。
在某些時候，有必要橫向擴展 - 問題只是成為理想時間的問題之一。我可能會建議： - 垂直擴展至少幾個實例大小（如果您從 t1.micro 開始，則更是如此） - 將您的數據庫分離為單獨的實例（因為它們的擴展方式與您的 Web 伺服器不同） -水平擴展，直到有一點冗餘 - 垂直擴展，直到達到最大實例大小 - 之後水平擴展（最初可能使用較小的實例）
回到手頭的問題 - 每個實例（或每組實例）執行一個網站總是會更昂貴。除了更高的固定成本（例如，每個網站一個負載均衡器，而不僅僅是一個負載均衡器）之外，您將無法有效地利用您的實例（即，一個網站可能會在其他網站同時出現高負載）大部分是空閒的 - 這意味著您有一些實例超載，而其他實例則處於空閒狀態）。在後勤方面，問題可能沒有想像的那麼嚴重——主要問題歸結為獨立管理所有內容（使用一些配置管理工具（例如 Puppet/Chef）可能會避免這種情況，但這通常不是一個步驟直到你的設置變得有點大）。
另一方面，EC2 實例的一個限制是您只能為給定實例分配一個公共 IP 地址（這對某些 SSL 設置有一些影響）。
您當然可以生成自己的 AMI - 實際上這是相當標準的做法。我通常從亞馬遜的 Linux AMI開始因為我發現它是一種成本最少（資源非常簡單，速度很快）和 AWS 支持最好的（它會定期更新等）——我更喜歡 RHEL/CentOS 發行版（亞馬遜的 Linux 是在該發行版上）基於）到 Debian/Ubuntu 的其他流行選擇。自定義實例後，您可以拍攝 EBS 卷的快照並註冊 AMI - 將快照 ID 作為根卷所基於的映像傳遞。從理論上講，您可以更多地自定義您的作業系統，甚至可以建構您自己的發行版（但仍然使用 Amazon 核心）——但是，除非您有一個非常具體的案例，否則這不太可能特別有益。我個人對執行 Wordpress 的偏好，
最後，再次解決縮放問題。除了上面討論的問題的基本經濟學之外，困難歸結為使多個實例“出現”為一個。這包括確保每個實例都提供相同的數據、實例之間的負載平衡，以及可能處理 PHP 會話等細節。如果每個站點都在自己的一組實例上執行，這將更加困難 - 但可能不會有很大的優勢（因為您希望將功能配置到您的 AMI 中）。然而，多個實例確實意味著一個更複雜的系統，以及更多需要關注的事情。（ServerFault 上關於這個話題的問題挺多的，比如this , this , or this- 如果您需要有關如何擴展特定設置的詳細資訊，請將其作為另一個問題提出）。
作為結論性評論 - 除非您的設置對單個站點在其自己的實例/集群上執行有特殊需求（例如，配置/要求大不相同），否則我更傾向於在單個實例/集群上執行多個站點，因為它更簡單規模化、經濟高效，更符合“雲計算”（即共享資源）的精神。
參考：
- S. Ostermann 等人。面向科學計算的 EC2 雲計算服務性能分析，2010
- A. Iosup 等人，面向多任務科學計算的雲計算服務的性能分析，2010 - 有關水平擴展的更多詳細資訊，請參見表 9。