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

# 実行失敗の理由
<a name="workflows-run-errors"></a>

実行が失敗した場合、[GetRun](https://docs.aws.amazon.com/omics/latest/api/API_GetRun.html) API オペレーションを使用して失敗の理由を取得します。

失敗の理由を確認して、実行が失敗した理由のトラブルシューティングに役立ててください。次の表に、各失敗の理由とエラーの説明を示します。


| 失敗の理由 | エラーの説明 | 
| --- | --- | 
|  ASSUME\$1ROLE\$1FAILED  |  HealthOmics には、ロールを引き受けるアクセス許可がありません。ロールの信頼関係で HealthOmics プリンシパルを指定します。  | 
|  CANNOT\$1START\$1CONTAINER\$1ERROR  |  イメージ: *イメージ名*を使用してワークフロータスク: *name*、id: *ID* コンテナを開始できません。イメージが有効であることを確認し、もう一度試してください。  | 
|  CANNOT\$1START\$1CONTAINER\$1SIZE\$1ERROR  |  イメージ: *イメージ**名*を使用してワークフロータスク: name、id: *ID* コンテナを開始できません。イメージサイズが 45 GiB (GPU インスタンスの場合は 95 GiB) 未満であることを確認し、もう一度試してください。  | 
| ECR\$1PERMISSION\$1ERROR | HealthOmics には、イメージ URI にアクセスするアクセス許可がありません。Amazon ECR プライベートリポジトリが存在し、HealthOmics サービスプリンシパルへのアクセス権が付与されていることを確認します。 | 
|  EXPORT\$1FAILED  |  エクスポートに失敗しました。出力バケットが存在し、実行ロールにバケットへの書き込みアクセス許可があることを確認します。  | 
|  FILE\$1SYSTEM\$1OUT\$1OF\$1SPACE  | ファイルシステムに十分なスペースがありません。ファイルシステムのサイズを増やし、もう一度実行します。 | 
|  IMAGE\$1VERIFICATION\$1FAILURE  |  イメージ*イメージ名*を確認できません。この問題を解決するには、イメージをプルして ECR リポジトリにもう一度プッシュしてみてください。  | 
|  インポート失敗  |  インポートに失敗しました。入力ファイルが存在し、実行ロールが入力にアクセスできることを確認します。  | 
| INACTIVE\$1OMICS\$1STORAGE\$1RESOURCE  |  HealthOmics ストレージ URI が ACTIVE 状態ではありません。読み取りセットをアクティブ化して、もう一度試してください。読み取りセットのアクティブ化の詳細については、「」を参照してください[HealthOmics での読み取りセットのアクティブ化](activating-read-sets.md)。  | 
| INPUT\$1URI\$1NOT\$1FOUND | 指定された URI は存在しません: uri。URI パスが存在することを確認し、ロールがオブジェクトにアクセスできることを確認します。 | 
|  INSTANCE\$1RESERVATION\$1FAILED  |  ワークフロー実行を完了するのに十分なインスタンス容量がありません。ワークフローの実行を再試行してください。  | 
| INVALID\$1ECR\$1IMAGE\$1URI |  Amazon ECR イメージ URI 構造が無効です。有効な URI を指定して、もう一度試してください。  | 
|  INVALID\$1TASK\$1RESOURCE\$1VALUE  | リクエストされた GPU、CPU、またはメモリが、使用可能なコンピューティング容量に対して高すぎるか、タスク ID の最小値である 1 未満です。 | 
|  INVALID\$1URI\$1INPUT  | URI 構造が有効な URI ではありません。URI 構造を確認して、もう一度試してください。 | 
|  MODIFIED\$1INPUT\$1RESOURCE  |  指定された URI *URI* は、実行の開始後に変更されました。実行を再試行します。  | 
|  OUT\$1OF\$1MEMORY\$1ERROR  |  ワークフロータスク *ID* のメモリが不足しました。ワークフロー定義のメモリ値を増やし、実行を再試行してください。  | 
|  RUN\$1TASK\$1FAILED  |  タスクが失敗したため、実行に失敗しました。タスクの失敗をデバッグするには、**GetRunTask** API オペレーションと Amazon CloudWatch Logs ストリームを使用します。  | 
|  RUN\$1TIMED\$1OUT  |  *数分*後にタイムアウトを実行します。  | 
|  SERVICE\$1ERROR  | サービスに一時的なエラーが発生しました。ワークフローの実行を再試行してください。 | 
| TASK\$1TIMED\$1OUT | タスク ID が秒数後にタイムアウトしました。 | 
|  UNSUPPORTED\$1INPUT\$1SIZE  |  合計入力サイズが大きすぎます。入力サイズを小さくして、もう一度試してください。  | 
|  WORKFLOW\$1RUN\$1FAILED  |  ワークフローの実行に失敗しました。CloudWatch Logs エンジンログストリーム *ID* を確認して、障害をデバッグします。  | 
|  WORKFLOW\$1VER\$1VALIDATION\$1FAILED  |  HealthOmics は、リクエストされた Nextflow バージョン: *バージョン* -- をサポートしていません。サポートされている最新バージョンは *バージョン*です。Nextflow バージョンをサポートされているバージョンに変更して、もう一度試してください。  | 
|  サポートされていない\$1GPU\$1INSTANCE\$1TYPE  |  リクエストされたインスタンスタイプは、 *リージョン*ではサポートされていません。このリージョンでサポートされている GPU インスタンスタイプで実行を再試行します。使用可能なインスタンスタイプは *GPU インスタンスタイプ*です。  | 

## 応答しない実行のガイダンス
<a name="workflows-guidance-unresponsive-runs"></a>

新しいワークフローを開発する場合、コードに問題があり、タスクが適切にプロセスを終了できないと、実行または特定のタスクが「停止」または「ハング」する可能性があります。これは、タスクを長期間実行するのが通常であるため、トラブルシューティングとキャッチが難しい場合があります。応答しない実行を防止して特定するには、以下のセクションで推奨されるベストプラクティスに従ってください。

**応答しない実行を防ぐためのベストプラクティス**
+ タスクコードで開いているすべてのファイルを閉じていることを確認します。開くファイルが多すぎると、ワークフローエンジン内でスレッドの問題が発生することがあります。
+ ワークフロータスクによって作成されたバックグラウンドプロセスは、タスクが終了したときに終了する必要があります。ただし、バックグラウンドプロセスが正常に終了しない場合は、タスクコードでそのプロセスを明示的にシャットダウンする必要があります。
+ プロセスが終了せずにループしないようにします。これにより、実行が応答しなくなる可能性があり、解決するにはワークフロー定義コードの変更が必要です。
+ タスクに適切なメモリと CPU 割り当てを提供します。[CloudWatch ログ](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html)を分析するか、ワークフローが正常に完了した実行[アナライザーの実行](workflows-run-optimize.md#workflows-run-analyzer)で を使用して、最適なコンピューティング割り当てがあることを確認します。Run Analyzer `headroom`パラメータを使用してヘッドルームを追加し、プロセスを完了するための十分なリソースを確保します。バックグラウンドオペレーティングシステムのプロセスを考慮して、割り当てられたメモリと CPU に少なくとも 5% のヘッドルームを含めます。
  + さらに、インスタンスのスループットを向上させる必要がある場合は、インスタンスの帯域幅サイズを増やします。vCPUs (サイズ 4xl 以下) の Amazon EC2 インスタンスでは、スループットがバーストする可能性があります。Amazon EC2 インスタンスのスループットの詳細については、[Amazon EC2 の使用可能なインスタンス帯域幅](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html#available-instance-bandwidth)」を参照してください。
+ 実行に正しいファイルシステムサイズを使用していることを確認します。静的実行ストレージを使用している応答しない実行の場合は、静的実行ストレージの割り当てを増やして、ファイルシステムの IO スループットとストレージ容量を増やすことを検討してください。実行マニフェストを分析して最大ファイルシステムストレージを確認し、Run Analyzer を使用してファイルシステムの割り当てを増やす必要があるかどうかを確認します。

**応答しない実行をキャッチするためのベストプラクティス**
+ 新しいワークフローを開発するときは、最大実行時間制限が設定されている実行グループを使用して、ランナウェイコードをキャッチします。例えば、実行が完了するまでに 1 時間かかる場合は、2 時間または 3 時間 (またはユースケースに応じて異なる期間) 後にタイムアウトする実行グループに配置して、ランアウェイジョブをキャッチします。また、処理時間の差異を考慮してバッファを適用します。
+ 最大ランタイム制限が異なる一連の実行グループを設定します。たとえば、数時間後に実行を終了する実行グループと、数日後に実行を終了する実行グループを、予想されるワークフロー期間に基づいて割り当てることができます。
+ HealthOmics の最大実行時間サービス制限は 604,800 秒、つまり 7 日で、クォータツールのリクエストで調整できます。このクォータのサービス制限の引き上げをリクエストするのは、1 週間近い実行がある場合に限ります。実行時間が短い実行と長い実行が混在していて、実行グループを使用していない場合は、実行時間が長い実行を最大実行時間サービス制限の高い別のアカウントに配置することを検討してください。
+ [CloudWatch ログ](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html)で、応答しないと思われるタスクがないか調べます。通常、タスクが通常のログステートメントを出力し、長期間出力していない場合、タスクは停止またはフリーズする可能性があります。

**応答しない実行が発生した場合の対処方法**
+ 追加コストが発生しないように実行をキャンセルします。
+ [タスクログ](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html#cloudwatch-logs)を調べて、プロセスが正しく終了しなかったかどうかを確認します。
+ [エンジンログ](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html#cloudwatch-logs)を検査して、異常なエンジン動作を特定します。
+ 応答しない実行のタスクログとエンジンログを、正常に完了した同じ実行のログと比較します。これにより、応答しない動作の原因となった可能性のある違いを特定できます。
+ 根本原因を特定できない場合は、[サポートケース](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case)を作成し、以下を含めます。
  + スタックした実行の ARN と、正常に完了した同一の実行の ARN。
  + エンジンログ (実行がキャンセルまたは失敗すると使用可能)
  + 応答しないタスクのタスクログ。トラブルシューティングのためにワークフロー内のすべてのタスクにタスクログは必要ありません。