本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 的最佳實務 AWS Batch
您可以使用 大規模 AWS Batch 執行各種嚴苛的運算工作負載，而無需管理複雜的架構。 AWS Batch 任務可用於流行病學、遊戲和機器學習等領域的各種使用案例。
本主題涵蓋使用 時要考慮的最佳實務， AWS Batch 以及使用 時如何執行和最佳化工作負載的指引 AWS Batch。
**Topics**
+ [使用時機 AWS Batch](bestpractice1.md)
+ [大規模執行的檢查清單](bestpractice2.md)
+ [最佳化容器和 AMIs](bestpractice3.md)
+ [選擇正確的運算環境資源](bestpractice4.md)
+ [Amazon EC2 隨需或 Amazon EC2 Spot](bestpractice5.md)
+ [使用適用於 的 Amazon EC2 Spot 最佳實務 AWS Batch](bestpractice6.md)
+ [常見錯誤和故障診斷](bestpractice7.md)
# 使用時機 AWS Batch
AWS Batch 會以低成本大規模執行任務，並提供佇列服務和成本最佳化擴展。不過，並非所有工作負載都適合使用 執行 AWS Batch。
+ **短期任務** – 如果任務只執行幾秒鐘，則排程批次任務的額外負荷可能需要比任務本身的執行時間更長的時間。作為解決方法，binpack您的任務會在您提交之前一起進行 AWS Batch。然後，設定您的 AWS Batch 任務以反覆執行任務。例如，將個別任務引數暫存到 Amazon DynamoDB 資料表或 Amazon S3 儲存貯體中的檔案。考慮將任務分組，讓任務執行 3-5 分鐘。在您binpack執行任務之後，請在 AWS Batch 任務中循環執行任務群組。
+ **必須立即執行的任務** - AWS Batch 可以快速處理任務。不過， AWS Batch 是排程器，並針對成本效能、任務優先順序和輸送量進行最佳化。 AWS Batch 可能需要時間來處理請求。如果您在幾秒鐘內需要回應，則使用 Amazon ECS 或 Amazon EKS 的服務型方法更合適。
# 大規模執行的檢查清單
在 50，000 個或更多 vCPUs 上執行大型工作負載之前，請考慮下列檢查清單。
**注意**
如果您計劃在數百萬個或更多vCPUs 上執行大型工作負載，或需要大規模執行的指引，請聯絡您的 AWS 團隊。
+ **檢查您的 Amazon EC2 配額** – 在 Service Quotas面板中檢查您的 Amazon EC2 配額 （也稱為限制） AWS 管理主控台。如有必要，請請求提高 Amazon EC2 執行個體尖峰數量的配額。請記住，Amazon EC2 Spot 和 Amazon 隨需執行個體有不同的配額。如需詳細資訊，請參閱 [ Service Quotas 入門](https://docs.aws.amazon.com/servicequotas/latest/userguide/getting-started.html)。
+ **驗證每個區域的 Amazon Elastic Block Store 配額** – 每個執行個體都會使用作業系統的 GP2 或 GP3 磁碟區。根據預設，每個 的配額 AWS 區域 為 300 TiB。不過，每個執行個體都會使用計數做為此配額的一部分。因此，當您驗證每個區域的 Amazon Elastic Block Store 配額時，請務必將其納入考量。如果達到配額，則無法建立更多執行個體。如需詳細資訊，請參閱 [Amazon Elastic Block Store 端點和配額](https://docs.aws.amazon.com/general/latest/gr/ebs-service.html)
+ **使用 Amazon S3 進行儲存** – Amazon S3 提供高輸送量，並有助於根據每個可用區域中的任務和執行個體數量，消除對要佈建多少儲存體的猜測。如需詳細資訊，請參閱[最佳實務設計模式：最佳化 Amazon S3 效能](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html)。
+ **逐步擴展以提早識別瓶頸** – 對於在數百萬個或更多 vCPUs上執行的任務，請開始降低並逐步增加，以便您可以提早識別瓶頸。例如，從在 50，000 個 vCPUs 上執行開始。然後，將計數增加到 20 萬vCPUs，然後增加到 50 萬vCPUs，以此類推。換句話說，繼續逐步增加 vCPU 計數，直到您達到所需的 vCPUs 數量。
+ **及早監控以識別潛在問題** – 為了避免大規模執行時的潛在中斷和問題，請務必同時監控您的應用程式和架構。即使從 1，000 擴展到 5，000 vCPUs，也可能發生中斷。您可以使用 Amazon CloudWatch Logs 檢閱日誌資料，或使用用戶端程式庫的 CloudWatch Embedded Metrics。如需詳細資訊，請參閱 [CloudWatch Logs 代理程式參考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html)和 [https://github.com/awslabs/aws-embedded-metrics-python](https://github.com/awslabs/aws-embedded-metrics-python)
# 最佳化容器和 AMIs
容器大小和結構對於您執行的第一組任務很重要。如果容器大於 4 GB，則尤其如此。容器映像內建於 layer 中。Docker 會使用三個並行執行緒平行擷取圖層。您可以使用 `max-concurrent-downloads` 參數增加並行執行緒的數量。如需詳細資訊，請參閱 [Dockerd 文件](https://docs.docker.com/engine/reference/commandline/dockerd/)。
雖然您可以使用較大的容器，但我們建議您最佳化容器結構和大小，以縮短啟動時間。
+ **較小型的容器擷取速度**較快 – 較小型的容器可能會導致較快的應用程式啟動時間。若要減少容器大小，請將不常更新的程式庫或檔案卸載至 Amazon Machine Image (AMI)。您也可以使用綁定掛載來提供容器的存取權。如需詳細資訊，請參閱[繫結掛](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/bind-mounts.html)載。
+ **建立大小相同的圖層並分解大型圖層** – 每個圖層都會由一個執行緒擷取。因此，大型 layer 可能會大幅影響您的任務啟動時間。我們建議最大層大小為 2 GB，以便在較大的容器大小和更快的啟動時間之間取得良好的權衡。您可以執行 `docker history your_image_id`命令來檢查您的容器映像結構和圖層大小。如需詳細資訊，請參閱 [Docker 文件](https://docs.docker.com/engine/reference/commandline/history/)。
+ **使用 Amazon Elastic Container Registry 做為容器儲存庫** – 當您平行執行數千個任務時，自我管理的儲存庫可能會失敗或調節輸送量。Amazon ECR 可大規模運作，並且可以使用超過一百萬vCPUs 處理工作負載。
![\[Diagram showing layers of machine images and containers with data types and change frequencies.\]](http://docs.aws.amazon.com/zh_tw/batch/latest/userguide/images/batch-best-practices-f1.png)
# 選擇正確的運算環境資源
AWS Fargate 需要的初始設定和組態比 Amazon EC2 更少，而且可能更容易使用，特別是第一次使用時。搭配使用 Fargate，您無需管理伺服器、處理容量規劃，或出於安全性而隔離容器工作負載。
如果您有下列需求，建議您使用 Fargate 執行個體：
+ 您的任務必須快速啟動，特別是不到 30 秒。
+ 任務的需求為 16 vCPUs或更少、沒有 GPUs，以及 120 GiB 或更少的記憶體。
如需詳細資訊，請參閱[何時使用 Fargate](when-to-use-fargate.md)。
如果您有下列需求，建議您使用 Amazon EC2 執行個體：
+ 您需要加強對執行個體選擇的控制，或使用特定的執行個體類型。
+ 您的任務需要 AWS Fargate 無法提供的資源，例如 GPUs、更多記憶體、自訂 AMI 或 Amazon Elastic Fabric Adapter。
+ 您需要高水準的輸送量或並行。
+ 您需要自訂您的 AMI、Amazon EC2 啟動範本，或存取特殊 Linux 參數。
使用 Amazon EC2，您可以根據特定需求更精細地調整工作負載，並視需要大規模執行。
# Amazon EC2 隨需或 Amazon EC2 Spot
大多數 AWS Batch 客戶使用 Amazon EC2 Spot 執行個體，因為比隨需執行個體節省成本。不過，如果您的工作負載執行數小時且無法中斷，則隨需執行個體可能更適合您。您一律可以先嘗試 Spot 執行個體，並視需要切換到隨需。
如果您有下列需求和期望，請使用 Amazon EC2 隨需執行個體：
+ 任務的執行時間超過一小時，您無法容忍工作負載中斷。
+ 您的整體工作負載具有嚴格的 SLO （服務層級目標），無法增加運算時間。
+ 您需要的執行個體更有可能看到中斷。
如果您有下列需求和期望，請使用 Amazon EC2 Spot 執行個體：
+ 任務的執行時間通常為 30 分鐘或更短。
+ 您可以在工作負載中容忍潛在的中斷和任務重新排程。如需詳細資訊，請參閱 [Spot 執行個體建議](https://aws.amazon.com/ec2/spot/instance-advisor/)程式。
+ 如果中斷，可以從檢查點重新啟動長時間執行的任務。
您可以先在 Spot 執行個體上提交，然後使用隨需執行個體做為備用選項，來混合這兩種購買模式。例如，在連線至在 Amazon EC2 Spot 執行個體上執行之運算環境的佇列上提交您的任務。如果任務中斷，請從 Amazon EventBridge 擷取事件，並將其與 Spot 執行個體回收相關聯。然後，使用 AWS Lambda 函數或 將任務重新提交至隨需佇列 AWS Step Functions。如需詳細資訊，請參閱 [教學課程：針對失敗的任務事件傳送 Amazon Simple Notification Service 提醒](batch_sns_tutorial.md)、[處理 Amazon EC2 Spot 執行個體中斷的最佳實務](https://aws.amazon.com/blogs/compute/best-practices-for-handling-ec2-spot-instance-interruptions/)，以及[AWS Batch 使用 Step Functions 管理](https://docs.aws.amazon.com/step-functions/latest/dg/connect-batch.html)。
**重要**
針對隨需運算環境使用不同的執行個體類型、大小和可用區域，以維持 Amazon EC2 Spot 執行個體集區可用性並降低中斷率。
# 使用適用於 的 Amazon EC2 Spot 最佳實務 AWS Batch
當您選擇 Amazon Elastic Compute Cloud (EC2) Spot 執行個體時，您可以最佳化工作流程以節省成本，有時可大幅節省成本。如需詳細資訊，請參閱 [Amazon EC2 Spot 的最佳實務](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html#be-instance-type-flexible)。
若要最佳化工作流程以節省成本，請考慮下列 Amazon EC2 Spot 最佳實務 AWS Batch：
+ **選擇`SPOT_CAPACITY_OPTIMIZED`配置策略** – 從最深層的 Amazon EC2 Spot 容量集區 AWS Batch 中選擇 Amazon EC2 執行個體。如果您擔心中斷，這是適當的選擇。如需詳細資訊，請參閱[的執行個體類型配置策略 AWS Batch](allocation-strategies.md)。
+ **多樣化執行個體類型** – 若要多樣化執行個體類型，請考慮相容的大小和系列，然後根據價格或可用性來 AWS Batch 選擇。例如，將 `c5.24xlarge`視為 `c5.12xlarge`或 `c5a`、`c5n`、`m5`、 `c5d`和 `m5d` 系列的替代方案。如需詳細資訊，請參閱[靈活了解執行個體類型和可用區域](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/spot-best-practices.html#be-instance-type-flexible)。
+ **減少任務執行時間或檢查點** – 我們建議不要在使用 Amazon EC2 Spot 執行個體時執行需要一小時或更長時間以避免中斷的任務。如果您將任務分割或檢查點為包含 30 分鐘或更短的較小部分，則可以大幅降低中斷的可能性。
+ **使用自動重試** – 為了避免 AWS Batch 任務中斷，請設定任務的自動重試。批次任務可能因下列任何原因中斷：傳回非零結束碼、發生服務錯誤，或發生執行個體回收。您最多可以設定 10 次自動重試。首先，我們建議您設定至少 1-3 次自動重試。如需追蹤 Amazon EC2 Spot 中斷的詳細資訊，請參閱 [Spot 中斷儀表板](https://github.com/aws-samples/ec2-spot-interruption-dashboard)。
對於 AWS Batch，如果您設定重試參數，任務會放置在任務佇列的前面。也就是說，任務會獲得優先順序。當您建立任務定義或在 中提交任務時 AWS CLI，您可以設定重試策略。如需詳細資訊，請參閱 [submit-job](https://docs.aws.amazon.com/goto/aws-cli/batch-2016-08-10/SubmitJob )。
```
$ aws batch submit-job --job-name MyJob \
--job-queue MyJQ \
--job-definition MyJD \
--retry-strategy attempts=2
```
+ **使用自訂重試** – 您可以將任務重試策略設定為特定應用程式結束程式碼或執行個體回收。在下列範例中，如果主機造成失敗，任務最多可重試五次。不過，如果任務因不同原因而失敗，則任務會結束，且狀態會設為 `FAILED`。
```
"retryStrategy": {
"attempts": 5,
"evaluateOnExit":
[{
"onStatusReason" :"Host EC2*",
"action": "RETRY"
},{
"onReason" : "*",
"action": "EXIT"
}]
}
```
+ **使用 Spot 中斷儀表板** – 您可以使用 Spot 中斷儀表板來追蹤 Spot 中斷。應用程式會在回收的 Amazon EC2 Spot 執行個體上提供指標，以及 Spot 執行個體所在的可用區域。如需詳細資訊，請參閱 [Spot 中斷儀表板](https://github.com/aws-samples/ec2-spot-interruption-dashboard)
# 常見錯誤和故障診斷
中的錯誤 AWS Batch 通常發生在應用程式層級，或是由不符合特定任務需求的執行個體組態所造成。其他問題包括任務卡在 `RUNNABLE` 狀態，或運算環境卡在 `INVALID` 狀態。如需有關故障診斷任務卡在 `RUNNABLE` 狀態的詳細資訊，請參閱 [任務停滯在 `RUNNABLE` 狀態](job_stuck_in_runnable.md)。如需 `INVALID` 狀態中運算環境故障診斷的資訊，請參閱 [`INVALID` 運算環境](invalid_compute_environment.md)。
+ **檢查 Amazon EC2 Spot vCPU 配額** – 驗證您目前的服務配額是否符合任務要求。例如，假設您目前的服務配額為 256 個 vCPUs且任務需要 10，000 vCPUs。然後，服務配額不符合任務要求。如需詳細資訊和疑難排解說明，請參閱 [Amazon EC2 服務配額](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)和[如何提高 Amazon EC2resources的服務配額？](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-limit/)。
+ **任務在應用程式執行之前失敗** – 有些任務可能因為`DockerTimeoutError`錯誤或`CannotPullContainerError`錯誤而失敗。如需疑難排解資訊，請參閱[如何解決 中的「DockerTimeoutError」錯誤 AWS Batch？](https://aws.amazon.com/premiumsupport/knowledge-center/batch-docker-timeout-error/)。
+ **IP 地址不足** – VPC 和子網路中的 IP 地址數目可以限制您可以建立的執行個體數目。使用無類別網域間路由 (CIDRs) 來提供比執行工作負載所需的更多 IP 地址。如有必要，您也可以建置具有大型地址空間的專用 VPC。例如，您可以在 中建立具有多個 CIDRs VPC，`10.x.0.0/16`並在每個可用區域中建立具有 CIDR 為 的子網路`10.x.y.0/17`。在此範例中，*x* 介於 1-4 之間，*y* 為 0 或 128。此組態在每個子網路中提供 36，000 個 IP 地址。
![\[VPC diagram showing 6 private subnets with different CIDR ranges across 3 可用區域.\]](http://docs.aws.amazon.com/zh_tw/batch/latest/userguide/images/batch-best-practices-VPC_larges_scale-1.png)
+ **確認執行個體已向 Amazon EC2 註冊** – 如果您在 Amazon EC2 主控台中看到執行個體，但 Amazon ECS 叢集中沒有 Amazon Elastic Container Service 容器執行個體，Amazon ECS 代理程式可能不會安裝在 Amazon Machine Image (AMI) 上。您的 AMI 中的 Amazon ECS 代理程式、Amazon EC2 資料或啟動範本可能也未正確設定。若要隔離根本原因，請建立個別的 Amazon EC2 執行個體，或使用 SSH 連線到現有的執行個體。如需詳細資訊，請參閱 [Amazon ECS 容器代理程式組態](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html)、[Amazon ECS 日誌檔案位置](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html)和 [運算資源 AMI](compute_resource_AMIs.md)。
+ **檢閱 AWS 儀表板** – 檢閱 AWS 儀表板，以確認預期的任務狀態和運算環境如預期擴展。您也可以在 CloudWatch 中檢閱任務日誌。
+ **確認您的執行個體已建立** – 如果執行個體已建立，這表示您的運算環境會如預期擴展。如果未建立執行個體，請在運算環境中尋找要變更的關聯子網路。如需詳細資訊，請參閱[驗證 Auto Scaling 群組的擴展活動](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)。
我們也建議您驗證執行個體是否可以滿足相關的任務需求。例如，任務可能需要 1 TiB 的記憶體，但運算環境使用的 C5 執行個體類型限制為 192 GB 的記憶體。
+ **驗證您的執行個體是否正由 請求 AWS Batch** – 檢查 Auto Scaling 群組歷史記錄，以確認您的執行個體正由 請求 AWS Batch。這是 Amazon EC2 如何嘗試取得執行個體的指示。如果您收到錯誤，指出 Amazon EC2 Spot 無法取得特定可用區域中的執行個體，這可能是因為可用區域不提供特定執行個體系列。
+ **確認執行個體已向 Amazon ECS 註冊** – 如果您在 Amazon EC2 主控台中看到執行個體，但 Amazon ECS 叢集中沒有 Amazon ECS 容器執行個體，Amazon ECS 代理程式可能不會安裝在 Amazon Machine Image (AMI) 上。此外，Amazon ECS 代理程式、AMI 中的 Amazon EC2 資料或啟動範本可能未正確設定。若要隔離根本原因，請建立個別的 Amazon EC2 執行個體，或使用 SSH 連線到現有的執行個體。如需詳細資訊，請參閱 [CloudWatch 代理程式組態檔案：日誌區段](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Logssection)、[Amazon ECS 日誌檔案位置](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html)和 [運算資源 AMI](compute_resource_AMIs.md)。
+ **開啟支援票證** – 如果您在進行故障診斷後仍遇到問題，並擁有支援計畫，請開啟支援票證。在支援票證中，請務必包含有關問題、工作負載詳細資訊、組態和測試結果的資訊。如需詳細資訊，請參閱[比較 支援 計劃](https://aws.amazon.com/premiumsupport/plans/)。
+ **檢閱 AWS Batch 和 HPC 論壇** – 如需詳細資訊，請參閱 [AWS Batch](https://repost.aws/tags/TAAQ5TlH16Tc686CgyYUNX0g/aws-batch)和 [HPC](https://repost.aws/tags/TAjBvP4otfT3eX8PswbXo9AQ/high-performance-compute) 論壇。
+ **檢閱 AWS Batch 執行期監控儀表板** – 此儀表板使用無伺服器架構從 Amazon ECS AWS Batch和 Amazon EC2 擷取事件，以提供任務和執行個體的洞見。如需詳細資訊，請參閱[AWS Batch 執行期監控儀表板解決方案](https://github.com/aws-samples/aws-batch-runtime-monitoring)。