一般的なエラーとトラブルシューティング - AWS Batch

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

一般的なエラーとトラブルシューティング

AWS Batchにおけるエラーは、多くの場合、アプリケーションレベルで発生したり、ユーザーの特定のジョブ要件を満たさないインスタンス構成が原因で発生したりします。その他の問題としては、ジョブがRUNNABLE のステータス内で停止したり、INVALID の状態でコンピューティング環境が停止したりすることが挙げられます。RUNNABLE のステータスのまま動かなくなるジョブのトラブルシューティングの詳細については、RUNNABLE 状態でジョブが止まる を参照してください。ある INVALIDの状態にあるコンピューティング環境のトラブルシューティングについては、INVALIDコンピューティング環境 を参照してください。

  • Amazon EC2 スポット vCPU クォータの確認 — 現在のService Quotasが、ジョブの要件を満たしていることを確認します。たとえば、現在のサービスクォータが 256 vCPUs で、ジョブに10,000 vCPUs が必要だとします。その場合、サービスクォータはジョブの要件を満たしていません。詳細とトラブルシューティングの手順の詳細については、Amazon EC2 Service QuotasAmazon EC2 リソースのService Quotaを増やすには?を参照してください。

  • アプリケーション実行前のジョブが失敗する — ジョブの一部には、DockerTimeoutErrorのエラーまたはCannotPullContainerErrorのエラーが原因で失敗するものがあります。トラブルシューティング情報については、AWS Batch の”DockerTimeoutError”エラーを解決する方法を参照してください。

  • 不十分なIP アドレス — VPC とサブネットの IP アドレスの数によって、作成できるインスタンスの数が制限されることがあります。Classless Inter-Domain Routings (CIDR) を使用して、ワークロード実行に必要なIP アドレスよりも多くの IP アドレスを指定します。必要な場合、大きなアドレス空間を持つ専用VPCを構築することもできます。たとえば、10.x.0.0/16において複数の CIDR を持つ VPC を作成し、すべてのアベイラビリティーゾーンに 10.x.y.0/17の CIDR を使い サブネットを作成できます。この例では、xは1~4で、yは0または128です。この設定では、すべてのサブネットに36,000個のIP アドレスが割り当てられます。

    VPC diagram showing 6 private subnets with different CIDR ranges across 3 Availability Zones.
  • インスタンスが Amazon EC2 に登録されていることを確認する — Amazon EC2 コンソールにおいてインスタンスが表示されるが、Amazon ECS クラスターに Amazon Elastic Container Service コンテナインスタンスが何も表示されない場合は、Amazon ECS エージェントが Amazon マシンイメージ (AMI)にインストールされていない可能性があります。AMI内のAmazon ECS エージェント、AMI Amazon EC2 データ、または起動テンプレートも、正しく設定されていない可能性があります。根本原因を探し出すには、別のAmazon EC2 インスタンスを作成するか、または SSH を使用して既存のインスタンスに接続します。詳細については、Amazon ECS コンテナエージェントの設定Amazon ECS ログファイルの場所、およびコンピューティングリソースの AMI を参照してください。

  • AWSダッシュボードを確認する — AWSダッシュボードを確認して、予想されるジョブの状態とコンピューティング環境が予想どおりにスケーリングされていることを確認します。CloudWatchでジョブログを確認することもできます。

  • インスタンスが作成されたことを確認する — インスタンスが作成されたら、コンピューティング環境が想定どおりにスケーリングされたことを意味します。インスタンスが作成されていない場合は、コンピューティング環境内の関連するサブネットを探して変更します。詳細については、Auto Scaling グループのスケーリングアクティビティを検証するを参照してください。

    また、インスタンスが関連するジョブ要件を満たしていることを確認するようお勧めします。たとえば、ジョブに 1 TiB のメモリが必要でも、コンピューティング環境では192 GB のメモリに制限されている C5 インスタンスタイプが使用されているとします。

  • AWS Batch により、インスタンスがからリクエストされていることを確認する — Auto Scaling グループの履歴をチェックして、インスタンスが AWS Batch によってリクエストされていることを確認します。これは、Amazon EC2 がどのようにインスタンスを取得しようとしているかを示しています。Amazon EC2 スポットが特定のアベイラビリティーゾー、のインスタンスを取得できない、というエラーが表示される場合は、アベイラビリティーゾーンが特定のインスタンスファミリーを提供していないことが原因である可能性があります。

  • インスタンスが Amazon ECS に登録されていることを確認する — Amazon EC2 コンソールにインスタンスが表示されるが、Amazon ECS クラスターに Amazon ECS コンテナインスタンスが表示されない場合は、Amazon ECS エージェントが Amazon マシンイメージ (AMI) にインストールされていない可能性があります。さらに、Amazon ECS エージェント、AMI の Amazon EC2 データ、または起動テンプレートが正しく設定されていない可能性があります。根本原因を探し出すには、別のAmazon EC2 インスタンスを作成するか、または SSH を使用して既存のインスタンスに接続します。詳細については、CloudWatch エージェント構成ファイル: ログセクションAmazon ECS Log File Locations、およびコンピューティングリソースの AMIを参照してください。

  • サポートチケットを開く — トラブルシューティングを行っても問題が解決せず、サポートプランがある場合は、サポートチケットを開いてください。サポートチケットには、問題、ワークロードの仕様、構成、およびテスト結果に関する情報を必ず含めてください。詳細については、AWS Support プランの比較を参照してください。

  • AWS Batch および HPC フォーラムを確認する — 詳細については、AWS BatchおよびHPCフォーラムを参照してください。

  • AWS Batch ランタイムモニタリングダッシュボードを確認する — このダッシュボードは、サーバーレスアーキテクチャを使用して Amazon ECS からのイベントをキャプチャし AWS Batch、そしてAmazon EC2 を使用してジョブとインスタンスに関する洞察を提供します。詳細については、AWS Batch ランタイム監視ダッシュボードソリューションを参照してください。