View a markdown version of this page

HealthOmics ワークフロー実行のデバッグ - AWS HealthOmics
失敗した実行を診断する実行メトリクスでリソースの使用を検査する同じワークフローの実行を比較する検出結果をコストとサイジングの変更に変換する

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

HealthOmics ワークフロー実行のデバッグ

HealthOmics は、複数のソースを通じて実行の動作を報告し、それぞれが異なる質問に答えます。失敗した実行の場合は、ログで始まるのではなく、次の順序で読み取ります。

  1. 実行に失敗したかどうか、および失敗した理由については、実行レコードを読み取ります。

  2. タスクが失敗した場合、どのタスクが失敗し、どのインスタンスタイプでタスクレコードを読み取ります。実行は、タスクの作成前、またはすべてのタスクの完了後に失敗する可能性があります。

  3. ログを読みます。タスクが報告したタスクログ、タスク外で実行が報告した実行ログ、エンジンが報告したエンジンログです。

  4. 実行メトリクスを読み、タスクが消費したマニフェストログを実行します。

完了したが、予想よりも遅い、またはコストがかかった実行については、 から開始します同じワークフローの実行を比較する。

このトピックのリソースとコストのガイダンスは、 に記載されている理由により、プライベートワークフローに適用されますプライベート HealthOmics ワークフローの最適化を実行する。次の手順で使用する API オペレーションとレスポンスフィールドについては、「」を参照してください実行情報を取得する。

このトピックのコマンドで、次の値を独自の値に置き換えます。

run_id

デバッグする実行の ID。

duration

aws logs tail 読み取りウィンドウ: 最近終了した実行2hの などの相対時間、または2026-03-26T22:00:00古い実行の などのタイムスタンプ。

run_uuid

その実行のレコードの uuidフィールド。

task_id

その実行で失敗したタスクの ID。

workflow_id

実行を一覧表示するワークフローの ID。

失敗した実行を診断する

失敗した実行を診断するには

  1. 実行レコードを取得し、status、、failureReasonstatusMessage、および を読み取りますlogLocation。レスポンスを保持します。後のステップで使用します。 logLocation は実行ログの ARNs (runLogStream) とエンジンログ () を提供しますengineLogStream。

    aws omics get-run --id run_id

    failureReason で の値を検索します実行失敗の理由。status が でない場合はFAILED、実行ステータス値代わりに「」を参照してください。

    一部の障害は、HealthOmics がタスクを作成する前、またはタスクが終了するたびに発生するため、次の 3 つのステップを読み取るタスクレコードを残しません。ロール、入力、インポート、またはエクスポートの失敗は 1 つであるため、 はタスクを作成する前に HealthOmics が拒否するイメージです (ECR_IMAGE_NOT_FOUND、ECR_PERMISSION_ERROR、ECR_REPOSITORY_NOT_FOUND、または INVALID_ECR_IMAGE_URI)。いずれの場合も、この手順の後半で実行ログにスキップします。イメージに障害が発生した場合、 はイメージ URI にstatusMessage名前を付けるため、 プライベートワークフローのコンテナイメージと から続行しますAmazon ECR のアクセス許可。次のステップで失敗したタスクが返された場合は、代わりにそのタスクを読み取ります。

  2. 失敗したタスクを一覧表示します。各項目にはtaskId、タスクの が含まれます。これは次のステップで使用されます。さらに、その名前、その creationTime、およびそれらに到達したら、そのインスタンスタイプ、startTime、および が含まれますstopTime。

    aws omics list-run-tasks --id run_id --status FAILED

    これがタスクを返さない場合、実行はステップ 1: 次の 2 つのステップをスキップして実行ログを読み取るケースの 1 つです。

  3. 失敗したタスクごとに、そのレコードを取得します。前のステップで返された内容logStreamに failureReason、imageDetails、、 が追加されます。 statusMessagelogStreamは、次のステップが読み取るログストリームの ARN であり、ストリームの名前はその中で続きlog-stream:ます。

    aws omics get-run-task --id run_id --task-id task_id

  4. タスクログを読み取ります。失敗を説明するイベントは、ストリームの最後にあります。

    aws logs tail /aws/omics/WorkflowLog \
  --log-stream-names run/run_id/task/task_id \
  --since duration

    タスクの実行前に開始する期間を設定します。コマンドはそれまで読み取られ、デフォルトのウィンドウは過去 10 分であるため、以前に終了した実行はイベントを返しません。ロググループと各ストリームの形式については、「」を参照してくださいCloudWatch のログ。

    注記

    タスクにログがまったくない理由と、タスクをよりデバッグ可能にする方法については、「」を参照してくださいワークフロータスクのトラブルシューティング。

  5. 実行の他の 2 つのログのいずれかを読み取ると、ここにある質問に回答します。どちらも異なるストリームでステップ 4 コマンドを実行します。

    aws logs tail /aws/omics/WorkflowLog \
  --log-stream-names run/run_id \
  --since duration
    実行に失敗したタスクがない

    前述のコマンドのようにrun/run_id、実行ログ を読み取ります。タスクなしで失敗するインポートおよびエクスポートステップなど、実行自体の進行状況をレポートします。レポートについては、「」を参照してくださいHealthOmics ワークフローのログタイプ。

    タスクが失敗し、ログにその理由が説明されない

    ワークフロー定義内の位置など、エンジンが失敗した原因run/run_id/engineを報告するエンジンログ を読み取ります。その ARN はステップ 1 logLocation.engineLogStreamの にあります。そのフィールドがレスポンスに含まれていない場合、実行にはエンジンログがありません。

    エンジン名の位置の定義を読み取るには、それをエクスポートします。次のコマンドは、実行が使用した定義のダウンロード URL を返します。

    aws omics get-workflow --id workflow_id --export DEFINITION

続行する場所は、失敗の理由によって異なります。次のリストでは、最も一般的なリソースとコンテナの障害について説明します。タスクが消費した内容、つまり障害がサイジングの問題であったかどうかについては、「」を参照してください検出結果をコストとサイジングの変更に変換する。

CANNOT_START_CONTAINER_ERROR、CANNOT_START_CONTAINER_SIZE_ERROR、または IMAGE_VERIFICATION_FAILURE

HealthOmics はタスクを作成し、コンテナを起動できなかったため、タスクはログを生成しませんでした。タスクレコードの からイメージを取得しimageDetails、「」を参照してくださいプライベートワークフローのコンテナイメージ。

OUT_OF_MEMORY_ERROR

「」で説明されているように、タスクの実行メトリクスまたは が検出結果をコストとサイジングの変更に変換する検索する実行マニフェストログの統計ワークフローのコンピューティングとストレージを適切なサイズにするにはどうすればよいですか?を使用して、タスクのメモリ使用量を割り当てと比較します。次に、ワークフロー定義のメモリを増やし、新しい値が で選択するインスタンスタイプを確認しますHealthOmics タスクのコンピューティングとメモリの要件。

TASK_TIMED_OUT または RUN_TIMED_OUT

タイムアウトの期限が切れたときにタスクがまだ作業を行っていたかどうかを確認します。そうでない場合は、低速ではなく応答しないものとして扱い、「」を参照してください応答しない実行のガイダンス。実行を終了した制限が実行グループからのものである場合は、「」を参照してくださいHealthOmics 実行グループの使用。

実行メトリクスでリソースの使用を検査する

実行メトリクスは、まだ進行中の実行を対象とするため、実行が終了する前に使用できます。実行にどのシリーズが存在するかは、その実行ストレージタイプ、スクラッチストレージモード、タスクがアクセラレーターをリクエストしたかどうかによって異なるため、メトリクスが欠落していると判断使用可能なメトリクスする前に、 の条件を確認してください。実行にシリーズがまったくない場合は、「」で説明されているように、そのロールがシリーズを発行できることを確認します実行のメトリクスの有効化。クエリ構文とコンソールの手順については、「」を参照してくださいHealthOmics 実行メトリクスのクエリ。

実行リソースラベルを使用して、すべてのクエリを 1 回の実行にスコープします。タスクごとのメトリクスには、一連の をタスクレコードとそのログに結合するタスクリソースラベルも含まれます。両方のラベルについては、「」を参照してください共通の 属性。

注記

CloudWatch は、PromQL クエリが返す時系列の数とそれにかかる時間範囲の両方を制限します。実行では、タスクごとのメトリクスごとにタスクごとに少なくとも 1 つのシリーズが生成されます。さらに、メトリクスが方向または GPU で分割される複数のシリーズが生成されます。タスクが多い実行の場合、クエリ自体にシリーズを集約するか、1 つのタスク、1 つの方向、または 1 つの GPU にフィルタリングします。ロングランを連続したウィンドウに分割します。現在の制限については、PromQL の制限と制限」を参照してください。

同じワークフローの実行を比較する

同じワークフローの以前の実行よりも実行が遅いか、コストがかかる場合は、2 つの実行タスクをタスクごとに比較します。タスク ID ではなく名前でタスクを調整します。両方の実行のタスクを取得し、 でグループ化してname、各名前の期間とピーク値を比較します。各実行のマニフェストログを 1 回読み取ると、すべてのタスクのタイミングと、エントリによってレポートされるピークが表示されます。 は、前の手順で使用した--status FAILEDフィルターなしで、まだ実行中の実行のタイミングListRunTasksを提供します。

タスクごとに 2 つのスパンを比較します。 startTime stopTimeはタスクの所要時間、 creationTimestartTimeは開始を待機した時間で、 の保留中フェーズと開始フェーズが含まれますタスクステータス値。タスクメトリクスが待機をカバーしないため、すべてのタスクの時間が一致する間、実行は別のタスクよりもはるかに遅くなる可能性があります。

注記

1 回の実行で複数のタスクが名前を共有でき、名前の散布インデックスが両方の実行で同じ入力データをカバーしているとは限りません。インデックスでインデックスをペアリングするのではなく、最も長い期間や最も高いピークなど、名前を共有するタスク間で集計を比較します。

2 つの実行を比較するのではなく、ワークフローの正常性を確立するには、完了した実行のセットを集計します。Run Analyzer は、「」で説明されているように、これを --batch モードで実行します実行間のファイルサイズの差異の影響。実行を自分で収集するには、 ListRuns で のレスポンスをフィルタリングしますworkflowId。オペレーションには独自のワークフローフィルターがないため、フィルターが絞り込む前に、完了したすべての実行をListRunsページスルーします。

aws omics list-runs --status COMPLETED \
  --query "items[?workflowId=='workflow_id'].id"

1 回の実行ではなく、一連の実行にわたる分布は、タスクの割り当てがデータの分散に適しているかどうか、およびスロールックの実行が正常範囲外であるかどうかを示します。

検出結果をコストとサイジングの変更に変換する

消費されるタスクは実行マニフェストログにあり、ストリームは ですmanifest/run/run_id/run_uuid。HealthOmics は実行の完了後にこれを書き込むため、タスクの停止時間ではなく実行の停止時間に達するように期間を設定します。他のストリームと同じaws logs tailコマンドで読み取ります。レポートされる統計については、「」を参照してくださいHealthOmics ワークフローのログタイプ。

マニフェストタスクエントリは、タスクの予約内容、インスタンスタイプ、期間を報告します。タスクがそれらと一緒に使用した内容をレポートしますが、すべてのタスクに使用されたわけではありません。エントリが使用状況を報告しない場合、またはタスクの作業が考慮できる範囲を下回った場合、代わりに で指定された理由で、タスクの実行メトリクスに対してサイズを設定しますコールアウト。

HealthOmics の 3 つの動作は、変更によって保存される内容を制限します。

  • タスクのコストは、タスクが使用するリソースではなく、リクエストするリソースに対して HealthOmics が選択するインスタンスタイプに従います。「HealthOmics タスクのコンピューティングとメモリの要件」を参照してください。

  • タスク料金には最小請求期間があるため、すでに短いタスクを短縮しても何も節約されません。「実行ステータスの料金への影響」を参照してください。

  • 静的実行ストレージは固定サイズであるため、削減により、サポートされるサイズが小さくなった場合にのみ料金が変更されます。「静的実行ストレージ」を参照してください。

これらの検出結果がフィードされる最適化方法については、「」を参照してください実行を最適化する方法。