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

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

トラブルシューティング

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

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

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

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

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

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

正常に完了した実行のエンジンログはどこにありますか？

HealthOmics は、失敗した実行に対してのみ CloudWatch にログを発行します。実行が正常に完了すると、HealthOmics はエンジンログを Amazon S3 バケットに配信します。詳細については、「Amazon S3 のログ」を参照してください。

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

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

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

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

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

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

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

  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. 両方のタスクのコンピューティング要件が一致する場合は、タスク間で入力が変更されていないことを確認します。これを行うには、エンジンログを開きます。実行のステータスが FAILED の場合、ログは Cloudwatch Log Group /aws/omics/WorkflowLog になります。それ以外の場合、エンジンログは実行の出力ディレクトリにあります。

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

読み取りセットで 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 ドキュメントを参照してください。

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

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

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

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

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

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

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

警告

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