某公司將應用程式遷移到 AWS。該應用程式在兩個 EC2 執行個體上執行，並位於 Application Load Balancer (ALB) 後方。MySQL 資料庫在單獨的 EC2 執行個體上執行，且讀取負載很高。每個 EC2 執行個體都會將頻繁更新的靜態內容儲存在其連接的 Amazon EBS 磁碟區上；靜態內容更新時必須複製到每個 EBS 磁碟區。負載全天變化，在尖峰時段，應用程式無法處理所有請求。追蹤顯示資料庫無法處理尖峰讀取流量。哪種解決方案能提高應用程式的可靠性？

此解決方案透過容器化應用程式並使用 Amazon ECS 和 Fargate 解決了應用程式擴展問題，Fargate 消除了管理 EC2 執行個體的負擔。Amazon EFS 解決了靜態內容複製的痛點，提供了一個可共享、可擴展的檔案系統。AWS Application Auto Scaling 確保應用程式能自動應對流量變化。將資料庫遷移到 Amazon Aurora MySQL Serverless v2 並搭配讀取器執行個體，能有效處理高讀取負載並自動擴展，同時提升可靠性。 其他選項的不足之處： 將應用程式遷移到 Lambda 函數可能不適合頻繁更新的靜態內容，且 Lambda 函數從 EBS 讀取靜態內容並非最佳實踐。 Step Functions 適用於協調工作流程，而非直接作為 ALB 的目標來處理應用程式請求。 在 ECS 叢集上為靜態內容建立新的 EBS 磁碟區，仍會面臨跨多個容器同步內容的挑戰，無法解決原始問題。