我需要能夠在多個 EC2 應用程式伺服器之間共用使用者上傳的內容。我將 rsync、掛載 NFS 和 S3 視為能夠幾乎即時共享此資料的潛在選項。上傳和下載的使用者檔案幾乎都在1-10MB之間。有些被多次訪問，有些只訪問一次，然後就被刪除。
我的最新方法涉及嚴格將 EC2 執行個體作為檔案伺服器啟動，與應用程式伺服器分開。使用此選項，用戶要下載文件，他們將連接到其中一個應用程式伺服器，該伺服器查詢資料庫以獲取有關他們希望下載的文件的資料。然後提示使用者下載，將他們連接到檔案伺服器進行下載。
我覺得這個選項會比我的其他選項更快。我看到的唯一缺點是我無法自動擴展/縮小文件伺服器。不過，我可以擴展並在資料庫中建立一個列，說明該文件位於哪個文件伺服器上。
這是一個好方法還是我錯過了什麼？另外，根據伺服器規格和檔案大小在 1-10MB 之間確定檔案伺服器上可以發生多少並發上傳/下載的好方法是什麼，或者最好透過負載測試來確定？
另外，就擴充功能而言，如果僅位於 1 個檔案伺服器上的 1 個特定檔案變得非常流行，是否會出現問題？使用 CDN 可以解決這個問題嗎？
答案1
CDN 將是您更好的選擇，將 S3 與 CloudFront 結合使用會是更好的選擇。我的建議是從應用程式伺服器分散用戶生成的內容，在架構內擴展或縮小時保持伺服器的易失性是一種很好的設計實踐。
答案2
S3 和 CloudFront 將是第一個選擇，但如果您發現延遲不可接受，那麼還有其他選擇。
如果單一檔案伺服器適合您，您可以過渡到可擴展的分散式檔案伺服器平台，例如GlusterFS。這允許您跨多個 EC2 執行個體儲存檔案並使它們顯示為單一安裝。您可以使用「replica 2」選項為每個檔案建立 2 個副本以實現冗餘。然後使用不同可用區中的兩個執行個體來提高可用性。檔案本身儲存在任何支援EC2 的磁碟上，其中包括具有預先配置IOPS 的EBS 甚至SSD 臨時磁碟（我之前已經這樣做過- Gluster 的冗餘使得臨時磁碟的波動性不再那麼令人擔憂，因此您可以從SSD 中受益）為您的關鍵數據提供快速 IO）。
答案3
您希望對 EC2 進行架構設計，使其上沒有任何獨特的數據，只需將它們視為計算機器即可。
你有幾個選擇。
S3
用於儲存和檢索文件的可擴展且可靠的服務。它作為檔案系統不能很好地工作，因此如果您進行大量讀取和寫入，那麼它不是一個很好的解決方案。
雲前（CDN）
靜態檔案（css、js、映像）可以在 CloudFront 之外提供（可以從 S3 或 EC2 取得資料）。這極大地提高了效能，因此您可以使用 S3 獲取檔案並從 CloudFront 提供它們。
GlusterFS
您可以使用 EC2 叢集作為網路附加儲存。當然，這會增加您的設定的複雜性，並且不是最快的解決方案。
彈性快取/Memecached
您可以託管自己的 memecached 或使用 Elasticache 服務。該解決方案不是文件存儲，但作為高效能、分散式記憶體物件快取系統很有用。