View a markdown version of this page

トラブルシューティング - AWS HealthOmics
ワークフローのトラブルシューティング実行メトリクスのトラブルシューティングコールキャッシュの問題のトラブルシューティングデータストアのトラブルシューティングKiro CLI を使用したトラブルシューティング

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

トラブルシューティング

以下のトピックは、HealthOmics ワークフローとデータストアを使用する際に発生する問題のトラブルシューティングに役立ちます。

ワークフローのトラブルシューティング

失敗した実行のトラブルシューティング方法を教えてください。

GetRun API オペレーションを使用して、失敗の理由を取得します。詳細については、「実行失敗の理由」を参照してください。

失敗したタスクのトラブルシューティング方法を教えてください。

タスク失敗メッセージのエラーコードを確認して、失敗を理解します。CloudWatch のタスクログを確認して、タスクの詳細なログ記録メッセージを確認します。詳細なログメッセージが表示されない場合は、ワークフローを修正して追加のログステートメントを出力できます。詳細については、「CloudWatch Logs による HealthOmics のモニタリング」を参照してください。

エンジンログはどこにありますか?

HealthOmics は、すべての実行 (成功と失敗) について、ほぼリアルタイムで CloudWatch にエンジンログを発行します。エンジンログは、実行の完了後に Amazon S3 バケットにも配信されます。詳細については、「CloudWatch Logs による HealthOmics のモニタリング」および「Amazon S3 のログ」を参照してください。

ワークフローの入力パラメータサイズを減らすにはどうすればよいですか?

ワークフローには、最大 256 KB の入力パラメータを指定できます。ディレクトリのインポートまたはサンプルシートを使用して、このサイズ制約内にとどまることができます。詳細については、「実行パラメータサイズの管理」を参照してください。

実行が完了しないのはなぜですか?

コードに問題があり、プロセスが適切に終了していない場合、実行が応答しないか、「スタック」する可能性があります。応答しない実行を防止してキャッチする方法の詳細については、「」を参照してください応答しない実行のガイダンス。

実行メトリクスのトラブルシューティング

タスクの実行が予想よりも遅いのはなぜですか?

タスクが中央処理ユニット (CPU) にバインドされている場合、グラフィックス処理ユニット (GPU) にバインドされている場合、または入出力 (I/O) を待機している場合、タスクの実行が遅くなることがあります。タスクの実行中にリソース使用率を確認するには、実行のほぼリアルタイムの CloudWatch メトリクスを使用します。

  • aws.omics.task.cpu.usage と を比較しますaws.omics.task.cpu.limit。制限での持続的な使用量は、タスクが CPU バウンドであり、より多くの割り当てられた CPU の恩恵を受ける可能性があることを示します。

  • GPU ワークロードの場合は、 を確認してくださいaws.omics.task.gpu.utilization。使用率が低い場合は、タスクが GPU を効果的に使用していないことを示している可能性があります。

  • I/O のボトルネックaws.omics.task.filesystem.operationsがないか、 aws.omics.task.filesystem.ioと を確認します。

詳細については、「プライベートワークフローのメトリクスを実行する」を参照してください。

ストレージの不足が原因で実行が失敗したのはなぜですか?

共有ファイルシステムのストレージを使い果たすと、実行が失敗する可能性があります。実行の共有ファイルシステムで使用中のストレージaws.omics.run.filesystem.usageを報告する と、合計容量aws.omics.run.filesystem.limitを報告する を比較します。ダッシュボードまたはアラームを作成して、ストレージ使用率をモニタリングできます。詳細については、「プライベートワークフローのメトリクスを実行する」を参照してください。

ワークフローのコンピューティングとストレージを適切なサイズにするにはどうすればよいですか?

ワークフローを 1 回実行し、CloudWatch メトリクスを確認して、実際の使用率と割り当てられた制限を比較します。

  • CPU、GPU、またはメモリの使用量が制限を大幅に下回る場合は、割り当てを減らしてコストを削減できます。

  • 使用量が常に制限に達している場合は、パフォーマンスを向上させたり、障害を回避したりするために割り当てを増やします。

  • を使用してaws.omics.run.filesystem.usage、実行に適したファイルシステムサイズを設定します。

詳細については、「プライベートワークフローのメトリクスを実行する」を参照してください。

実行のメトリクスが表示されないのはなぜですか?

実行メトリクスとタスクメトリクスが CloudWatch のcloudwatch.aws/omicsスコープに表示されない場合は、以下を確認してください。

  • 実行に使用される IAM ロールに CloudWatch にメトリクスを発行するアクセス許可があることを確認します。

  • メトリクスは、実行中にほぼリアルタイムで公開されます。最初のデータポイントが表示されるまで少し (約 30 秒) 待ちます。

  • 30 秒未満で実行されるタスクにはメトリクスがない場合があります。

  • 正しい AWS リージョンとアカウントが表示されていることを確認します。

詳細については、「プライベートワークフローのメトリクスを実行する」を参照してください。

これは、実行マニフェストログリソース統計とどのように異なりますか?

実行マニフェストログは、CPU とメモリの最大数や平均数など、完了した実行の集計統計をレポートするため、完了した実行で最適化の機会を確認できます。CloudWatch 実行メトリクスは時系列です。HealthOmics は にリストされている頻度でデータポイントを発行するため使用可能なメトリクス、実行の進行中に使用率の変化をモニタリングし、より詳細なデータを使用して実行のトラブルシューティングを行うことができます。実行メトリクスの詳細については、「」を参照してくださいプライベートワークフローのメトリクスを実行する。

Query Studio の実行メトリクスは、Nextflow 実行レポートとどのように異なりますか?

どちらもワークフローのリソース使用率を報告します。タイミング、エンジンカバレッジ、使用方法が異なります。実行メトリクスを使用して進行中の実行をモニタリングし、Nextflow 実行レポートを使用して完了した実行を確認します。

  • 実行メトリクスは、実行の実行中にほぼリアルタイムで利用できるため、進行状況をモニタリングし、アラームを設定し、進行中の実行のトラブルシューティングを行うことができます。Nextflow 実行レポートは実行が終了したときに書き込まれるため、実行後にのみ実行を確認することができます。

  • HealthOmics は、実行が使用するワークフローエンジンに関係なく、プライベートワークフロー実行ごとに実行メトリクスを出力します。実行レポートは Nextflow に固有であり、HealthOmics は で書き込むように設定した場合にのみエクスポートします/mnt/workflow/output/。

  • 実行メトリクスは CloudWatch 時系列であるため、PromQL でクエリを実行し、アラームを実行してダッシュボードに追加できます。実行レポートは、実行の Amazon S3 出力場所にある静的ファイルです。

実行レポートの詳細については、「」を参照してくださいNextflow 実行レポートの生成。実行メトリクスの詳細については、「」を参照してくださいプライベートワークフローのメトリクスを実行する。

コールキャッシュの問題のトラブルシューティング

以下のトピックは、通話キャッシュで発生する問題のトラブルシューティングに役立ちます。

実行がキャッシュに保存されないのはなぜですか?

  1. GetRun API オペレーションレスポンスの cacheId フィールドをチェックして、キャッシュを使用するように実行が設定されていることを確認します。CLI を使用して、次のコマンドを実行します: aws omics get-run —id <run_id>。

  2. 実行が成功した場合は、GetRun レスポンスで返されるキャッシュ動作が CACHE_ALWAYS であることを確認します。キャッシュ動作が CACHE_ON_FAILURE に設定されている場合、実行は失敗したときにのみキャッシュに保存されます。

タスクがキャッシュエントリを使用していないのはなぜですか?

/aws/omics/WorkflowLog CloudWatch ロググループで、実行キャッシュのログストリームを開きます: runCache/<cache_id>/<cache_uuid>。

  1. 前の実行で、キャッシュされる予定のタスクのキャッシュエントリが作成されていることを確認します。キャッシュに保存された実行は、CACHE_ENTRY_CREATED のログメッセージで記録されます。

  2. タスクの CACHE_MISS ログを見つけ、完了した を実行します。ログエントリがない場合は、キャッシュを使用するように実行が設定されていることを確認します。

  3. キャッシュエントリが作成された場合は、CPU、メモリCPUs、GPUs、コンテナダイジェストが両方のタスクで同じであることを確認します。キャッシュエントリを作成したタスクのタスク ARN は、ログメッセージにあります。

  4. 両方のタスクのコンピューティング要件が一致する場合は、タスク間で入力が変更されていないことを確認します。これを行うには、エンジンログを開きます。エンジンログは、すべての実行で CloudWatch Log Group /aws/omics/WorkflowLog で使用できます。これらは、完了後に実行の出力ディレクトリでも使用できます。

タスクのコールキャッシュが無効になっているのはなぜですか?

ワークフローエンジン機能を使用してキャッシュをオプトアウトするようにタスクが設定されているかどうかを確認します。

  • WDL ワークフローの場合: メタセクションtrueでタスクの揮発性が に設定されているかどうかを確認します。

  • Nextflow ワークフローの場合: タスクのキャッシュディレクティブが に設定されているかどうかを確認します。 false

  • CWL ワークフローの場合: enableReuse 機能falseに対してタスクの WorkReuse が に設定されているかどうかを確認します。

データストアのトラブルシューティング

読み取りセットで S3 GetObject が失敗するのはなぜですか?

最も一般的に、障害の原因はアクセス許可がないことです。シーケンスストア S3 読み取りアクセス許可は、アクセスを許可するシーケンスストア S3 アクセスポリシーと、アクセスを許可するポリシーをアタッチする IAM プリンシパルの両方を必要とする双方向設定です。ポリシー要件の詳細については、「」を参照してくださいAmazon S3 URIs を使用したデータアクセスのアクセス許可。次の設定が設定されていることを確認します。

  • シーケンスストア S3 アクセスポリシーは、IAM プリンシパルまたはプリンシパルのアカウントのルートへのアクセスを明示的に許可しています。

  • IAM プリンシパルに、アクセスするリソースにアクセス許可を明示的に付与するポリシーがあることを確認します。アクセス許可を定義するときは、IAM プリンシパルポリシーはアクセスポイント ARN を使用する必要があり、アクセスポイントエイリアスベースのパスを使用する必要はなく、ARN は 条件にあり、リソースの指定には使用されないことに注意してください。

  • ストアでカスタマーマネージドキー (CMK-KMS) を使用している場合は、IAM プリンシパルにキーに対する kms:decrypt アクセス許可があることを確認します。アカウント間の使用状況の設定については、KMS クロスアカウントアクセスガイドを参照してください。

タグベースのアクセスコントロールを使用しているポリシーがある場合は、以下を確認してください。

  • シーケンスストアがタグの同期を完了していることを確認します。そのためには、ストアのステータスは active ではなく である必要がありますupdating。

  • 読み取りセットとポリシーのタグキーまたはキー値にタイプミスがないことを確認します。

Athena で注釈ストアまたはバリアントストアが表示されないのはなぜですか?

Lake Formation では、共有されたストアに基づいてリソースリンクを必ず作成してください。アクセス許可を持つリソースリンクを作成すると、ストアが Athena に表示されます。詳細については、「HealthOmics を使用するように Lake Formation を設定する」を参照してください。

Athena のデータストアにアクセスできないのはなぜですか?

注釈ストアまたはバリアントストアが表示されていても、アクセスが拒否されたことを示すエラーメッセージが表示されている場合は、使用しているクエリエンジンのバージョンを確認してください。エンジンバージョン 3 を使用して実行されるクエリのみがサポートされています。Athena クエリエンジンのバージョンの詳細については、Amazon Athena ドキュメントを参照してください。

Kiro CLI を使用したトラブルシューティング

Kiro CLI は、以下によってトラブルシューティングプロセスを合理化するのに役立ちます。

  • ワークフロー実行の分析とタスク失敗のデバッグ

  • 関連するログとエラーメッセージの収集

  • 必要なすべてのデバッグログがアタッチされた AWS サポートケースの作成

  • AWS サポートに送信された情報から個人を特定できる情報 (PII) を編集します

で Kiro CLI を使用してサポートケース AWS HealthOmics をトラブルシューティングおよび作成する方法の詳細については、GitHub の HealthOmics Agentic 生成 AI チュートリアルを参照してください。

警告

Kiro CLI を使用する場合は、先に進む前に、生成されたすべてのコンテンツと提案されたアクションを確認してください。応答品質を向上させ、ワークフローの要件に合わせてフィードバックを提供します。詳細については、「Kiro のセキュリティ上の考慮事項とベストプラクティス」を参照してください。