我對雲端架構很陌生，但有不錯的應用程式開發經驗。目前，我正在透過 Web 應用程式讓 5-10 個使用者更容易存取大型運算管道，並在 AWS 中進行這一切設定。
我目前的實作是一個輕量級的React Web 應用程序，它使用兩個API 和一個MySQL 後端，允許用戶使用參數對作業進行排隊，並透過Web 應用程式或運行完成後發送給用戶的電子郵件訪問最終結果。
該管道的中間依賴於一個專有軟體，該軟體需要一台非常龐大的機器來計算這些步驟（64GB 記憶體、16 個核心、1TB 硬碟），並且僅此一個步驟就可以運行長達 1.5 天。這是我整個流程中最大的瓶頸。
為了盡可能節省成本，我試圖透過開啟多個 EC2 執行個體「代理」、執行步驟、傳送電子郵件、寫入網路來使瓶頸/服務部分可擴展/經濟高效應用程式資料庫，然後透過AWS lambda 函數停止實例，該函數將由Web 應用程式的操作觸發。
我計劃為 Web 應用程式託管一個 EC2 執行個體、2 個 API 和 MySQL 伺服器，因為這一部分的並發性/可擴展性非常小。我還將為瓶頸服務提供另外 1-3 個實例，以共享 5-10 個用戶的並發運行，這可以允許同時運行最多 3 個繁重步驟。
由於瓶頸服務需要類似的文件來運行程序，並且這些步驟的輸入有時可能是 150GB 的文件大小，因此我正在考慮使用 EFS 或 S3 存儲來保存輸入，這樣我只需擔心傳輸輸入文件傳輸到一個可以在EC2 執行個體之間共用的位置，我不需要確保它們開始執行傳輸步驟。這是一個手動部分，由於文件太大，我還沒有找到一種更加自動化的好方法。
我的問題是我的設定聽起來合理嗎？目前，我正在為服務實例使用 EBS 存儲，但我希望最大限度地減少 150GB 傳輸/維護的輸入位置。我也不確定 S3 和 EFS 之間的區別，因為它們似乎都是可多實例安裝的，但我應該使用哪一個？如果我需要服務在完成後能夠寫入資料庫，那麼將 Web 應用程式、API 和資料庫保留在一個 EC2 執行個體上是否有意義？該實例將一直處於開啟狀態。
感謝您的幫助，如果我說了什麼天真的話，請原諒我。
答案1
你的設定聽起來確實合理。我可能建議您考慮使用 API 閘道來「託管」您的 API，並考慮它是否適合您。您也可以考慮將重負載 EC2 執行個體放在 Autoscaling 群組中，並讓您的控制 Lambda 與其交互，而不是直接與執行個體交互。
S3和EFS是不同的資料儲存解決方案。 S3是物件存儲，EFS是文件存儲。 S3 並不完全可安裝，儘管它可能看起來像是透過不同的實用程式來安裝的。無論是正確的使用 S3 還是 EFS 取決於您如何使用其中的檔案。
對於您的資料庫，您可能會考慮使用 RDS，也許使用可突發實例類別或無伺服器選項之一。但這取決於您的預算和用例。
答案2
一般來說，在雲端中，最好嘗試使用服務而不是伺服器。您必須專注於成本，但它可以使解決方案更強大、更快、更合規。
對於你的工作量，我有一些想法：
- 您可以使用像 AWS Step 函數這樣的編排器來呼叫許多 AWS lambda 函數來進行運算嗎？我確實注意到 lambda 可能是 AWS 上最昂貴的運算時間，所以可能並不理想。透過正確設定限制和合適的工作負載，也許您可以啟動 10,000 個 lambda 並在 15 分鐘內並行完成工作。
- 除了 EFS/S3，如何建立一個黃金 EC2 映像/AMI，然後為每個作業啟動一個足夠大的現貨/動態 EC2 執行個體來處理該作業，並在完成後關閉？ Lambda 可以根據某種類型的事件來協調工作嗎？這將避免資料傳輸費用 - 儘管不確定它們是否向 EBS / S3 收費。現貨計算非常便宜，如果您正確選擇區域/可用區/實例大小，中斷應該很少見。中斷的執行個體將關閉並保留 EBS 卷，因此如果您的作業定期寫入磁碟並可以重新啟動，效果會更好。
我可能還會花一些時間來優化這項艱鉅的工作。