プライベート HealthOmics ワークフローの最適化を実行する

合計コスト、合計実行時間、またはその両方の組み合わせで実行を最適化できます。HealthOmics は、実行の最適化の決定に役立つデータとツールを提供します。実行の最適化は Ready2Run ワークフローには適用されません。これは、サービスがこれらのワークフローのリソースプロビジョニングを管理する方法を制御できないためです。

最初のステップでは、実行中のタスクの現在のタスクリソースの使用状況とコストを理解し、実行コストとパフォーマンスを最適化する方法を適用します。

アナライザーの実行

HealthOmics には、Run Analyzer という名前のオープンソースツールが用意されています。このツールは、実行のタスクレベルのリソース使用状況情報を抽出し、コストと実行パフォーマンスの最適化の機会を提案します。

注記

Run Analyzer は、ツールの実行時の AWS 定価に基づいてタスクコストと潜在的なコスト削減を見積もります。最適化の推奨事項を評価し、ユースケースに適した推奨事項を実装します。採用した最適化をテストして、実行で機能することを確認します。

Run Analyzer は次のタスクを実行します。

• メモリとコンピューティングのボトルネックを評価します。

• メモリまたは CPU 用に過剰にプロビジョニングされているタスクを特定し、コストを削減できる新しいインスタンスサイズを推奨します。

• 個々のタスクのコスト見積もりを計算し、レコメンデーションを適用すると潜在的なコスト削減を計算します。

• タスクのタイムラインビューが表示され、タスクの依存関係と処理シーケンスを確認できます。タイムラインは、長時間実行されるタスクを特定するのにも役立ちます。

• 実行ストレージのファイルシステムサイズに関する推奨事項を提供します。

• タスクのプロビジョニング時間を表示して、大きなコンテナ負荷によってプロビジョニング時間が遅くなる可能性のある領域を特定できるようにします。

• ツールには、最適化レコメンデーションの積極性を制御するために使用できる入力パラメータ (ヘッドルーム) が含まれています。

以下のセクションでは、Run Analyzer を使用して実行を最適化するための具体的な提案を示します。

実行コストを決定する

以下の方法とガイドラインを使用して、実行コストを決定できます。

• 請求期間の合計実行コストを表示するには、次の手順に従います。

  1. Billing and Cost Management コンソールを開き、Bills を選択します。

  2. サービス別の料金で、Omics を展開します。

  3. リージョンを展開し、オミクスインスタンスタイプ、実行ストレージタイプ、および Ready2Run ワークフロー別に項目化されたすべての実行のコストを表示します。

• 各実行の情報を含むコストレポートを生成するには、次の手順に従います。

  1. Billing and Cost Management コンソールを開き、データエクスポートを選択します。

  2. Create を選択して、新しいデータエクスポートを作成します。

  3. データエクスポートのエクスポート名を入力します。他のフィールドをデフォルト値のままにして、CUR (コストと使用状況) レポートを作成します。

  4. 時間の詳細度には、時間単位または日単位を選択します。

  5. データエクスポートストレージ設定で、以下の設定ステップを実行します。

     1. データエクスポート用に Amazon S3 バケットを設定します。

     2. ファイルバージョニングでは、既存のエクスポートファイルを上書きするか、毎回新しいファイルを作成するかを選択します。

     システムは 24 時間以内に最初のレポートを生成し、それ以降のレポートは 1 日に 1 回生成します。

  6. データエクスポートの作成方法の詳細については、「データエクスポートAWS ユーザーガイド」の「データエクスポートの作成」を参照してください。

• 実行にタグを付けて、チームやプロジェクトなどのカテゴリ別にコストをモニタリングおよび最適化できます。タグを使用する場合は、以下の手順に従ってタグカテゴリ別に実行コストを表示します。

  1. Billing and Cost Management コンソールを開き、Cost Explorer を選択します。

  2. レポートパラメータ > グループ化基準で、ディメンションとしてタグ を選択し、目的のタグ名を選択します。

• タスクのリソース使用状況を確認するには、CloudWatch で実行マニフェストログを表示します。詳細については、「CloudWatch Logs による HealthOmics のモニタリング」を参照してください。

• ツールアナライザーの実行を使用して、実行のタスクリソース使用状況情報を抽出します。

実行時間の使用状況を確認する

実行時間の使用状況を調査するには、次の方法を使用できます。

• コンソールの Runs ページから、実行の合計実行時間を表示できます。

• 実行の詳細ページから、次の項目を表示できます。

  • 実行の合計実行時間を表示します。

  • 実行内の各タスクの実行時間を表示します。

  • リンクのいずれかを選択して Amazon S3 のログを表示するか、CloudWatch で実行ログまたはマニフェストログを実行します。

• タスクの実行 リストから、タスクのログを表示 リンクを選択して、CloudWatch でタスクログを表示します。

• listRuns API オペレーションへのレスポンスには実行開始時刻と停止時刻が含まれているため、合計実行時間を計算できます。

• このアナライザーの実行ツールは、タイムラインビューにタスク期間を表示します。このツールは、タスク処理シーケンスを視覚的に表現し、予想される順序と一致させることができます。

実行を最適化する方法

HealthOmics は、データステージング (データのインポートやデータエクスポートなど) を実行するリソースを自動的にプロビジョニング、管理、最適化します。また、HealthOmics はワークフローのワークフローエンジンを起動して実行します。ただし、さまざまな実行設定を設定することで、実行開始時間、タスク開始時間、全体的なタスク実行時間に影響を与えることができます。ワークフロー定義と設計に対する全体的なアプローチは、タスクの実行時間にも影響します。次のリストは、実行とタスクのパフォーマンスに影響を与える可能性のある要因を示しています。

ストレージタイプを実行する

実行ストレージタイプは、実行パフォーマンスと実行プロビジョニング時間に影響します。動的実行ストレージは、実行ストレージのニーズに応じて動的にスケールするため、プロビジョニングが速くなり、メモリが不足することはありません。動的実行ストレージは、開発中のワークフローにも適しており、問題のトラブルシューティングのためにワークフローを開始および停止することがよくあります。

静的実行ストレージでは、ファイルシステムのプロビジョニング時間が長くなりますが、一部の実行はより速く完了できます。通常、実行のタスク同時実行数が高い場合や、9.6 TiB を超えるファイルシステム容量が必要な場合です。静的実行ストレージは、I/O 要件が高い長時間実行されるワークフローに適しています。

特定の実行の各実行ストレージタイプのコストとパフォーマンスを評価するのに役立つように、A/B テストを試して、どの実行ストレージタイプがパフォーマンスを向上させるかを確認できます。また、開発サイクルに動的実行ストレージを使用することを検討し、本番環境の大規模な実行には静的実行ストレージを使用することを検討してください。

実行ストレージタイプの詳細については、「」を参照してください。 HealthOmics ワークフローでストレージタイプを実行する

オーバープロビジョニング実行の静的ストレージ

ワークフロータスクの計算が I/O によって制約されている場合は、静的実行ストレージの過剰プロビジョニングを検討してください。ストレージコストはサイズとともに増加しますが、ファイルシステムの最大スループットも増加します。高価なコンピューティングタスクで I/O ボトルネックが発生している場合は、ファイルシステムサイズを大きくしてタスクの実行時間を短縮することで、全体的なコストを削減できます。

コンテナイメージサイズの縮小

各タスクが開始されると、HealthOmics はタスクに指定したコンテナをロードします。コンテナが大きいほど、ロードに時間がかかります。コンテナをできるだけ小さくして、新しいタスクの起動効率を向上させます。コンテナに大規模なデータセットを追加する場合は、データセットを S3 に保存し、ワークフローで S3 からデータをインポートすることを検討してください。HealthOmics がサポートするコンテナの最大サイズについては、「」を参照してくださいHealthOmics ワークフローの固定サイズクォータ。

タスクサイズ

小さなシーケンシャルタスクを 1 つのタスクに結合して、タスクのプロビジョニング時間を節約できます。また、HealthOmics には 1 分間の最小タスク期間料金がかかるため、タスクを組み合わせるとコストを削減できます。結合タスク内では、Unix パイプを使用してファイルのシリアル化と逆シリアル化の I/O コストを回避できる場合があります。

ファイル圧縮

ワークフロー中間ファイルを過度に圧縮しないでください。ほとんどのゲノミクス形式は、「gzip」または「block gzip」圧縮を使用します。タスク入力ファイルを解凍し、タスク出力ファイルを再圧縮すると、タスク全体の CPU 使用率の大部分を消費する可能性があります。一部のゲノミクスアプリケーションでは、出力をシリアル化するときに圧縮レベルを設定できます。圧縮レベルを減らすことで、CPU 時間を短縮できますが、ファイルが大きいほどディスクへの書き込みに費やす時間が長くなります。タスクとアプリケーションに応じて、実行時間が最短になる中間ファイルに最適な圧縮レベルを見つけることができます。まず、出力ファイルが最も大きいタスクをターゲットにすることをお勧めします。圧縮レベル 2 は、いくつかのシナリオに適しています。ユースケースではこのレベルから始めて、他の圧縮レベルを試して結果を比較できます。

スレッド数

タスク定義でスレッドを指定する場合は、スレッドの数をリクエストvCPUs の数と同じ値に設定します。

コンピューティングとメモリを指定する

タスクでメモリまたはコンピューティングリソースを指定しない場合、HealthOmics は最小のインスタンスタイプ (omics.c.large) をデフォルトの として割り当てます。HealthOmics でより大きなインスタンスタイプを割り当てる場合は、メモリとコンピューティングの要件を明示的に宣言します。

HealthOmics は、リクエストした vCPUsメモリ、GPU リソースの数を割り当てます。たとえば、15vCPUs と 33GiB をリクエストすると、HealthOmics はタスクに omics.m.4xl インスタンス (16 vCPUs、64GB) を割り当てますが、タスクで使用できる vCPUsと 33GiB は 15 個のみです。したがって、オミクスインスタンスに一致する vCPUs とメモリリソースをリクエストすることをお勧めします。

複数のサンプルを 1 回の実行にバッチ処理する

ファイルシステムのプロビジョニングには実行開始時に時間がかかるため、複数のサンプルを同じ実行にバッチ処理することで、プロビジョニング時間を短縮できます。このアプローチを決定する前に、次の要因を考慮してください。

• 1 つのサンプルが正しくないとワークフローが失敗する可能性があるため、サンプルをバッチ処理すると失敗したワークフローの数が増える可能性があります。ワークフローがほとんどの場合成功すると確信できない場合は、サンプルごとに 1 回実行することをお勧めします。

• HealthOmics は、ワークフロー全体に 1 つの実行ストレージファイルシステムを割り当てます。サンプルのバッチの場合は、すべてのサンプルを処理するのに十分な量の実行ストレージを指定してください。

• ワークフローあたりの実行ストレージの最大量があるため、 はバッチに追加できるサンプルの数を制限する可能性があります。

• 最小実行ストレージサイズは 1.2 TiB であるため、ワークフローが各サンプルで最小よりもはるかに少ないストレージを使用すると、バッチ処理によってコストを削減できます。

• 実行ストレージは複数の同時接続を処理できるため、同じ実行ストレージを使用する複数のタスクがあっても I/O ボトルネックは発生しません。

• 各実行には独自のタグセットがあります。ワークフローに予算編成や追跡の情報でタグ付けする場合は、個別の実行を使用することをお勧めします。

• IAM ロールは実行全体に適用されます。各ユーザーは、サンプルのバッチのすべてのデータにアクセスできます。ワークフローを分離することで、よりきめ細かなアクセス許可を使用できるようになります。

• HealthOmics は、同時ワークフローの最大数とワークフロー内の同時タスクの最大数のアカウントレベルのクォータを設定します。これらのクォータの引き上げをリクエストする方法については、「」を参照してくださいHealthOmics サービスクォータ。

コンテナイメージのパラメータを使用する

ワークフローに URIs、コンテナイメージをパラメータ化します。これらは実行パラメータであり、HealthOmics は、実行を開始する前に実行がコンテナにアクセスできることを検証します。そうしないと、完了したタスクに対して料金が発生したときに、実行中にタスクが失敗します。また、これらはパラメータ化された入力であるため、HealthOmics は実行マニフェストでチェックサムを生成し、実行の出所を改善します。

linter を使用する

新しいワークフローを実行する前に、linter を使用して一般的なワークフローエラーを見つけます。詳細については、「HealthOmics のワークフローlinters」を参照してください。

EventBridge を使用して問題にフラグを付ける

EventBridge カスタマイズされたアラートを使用して、ビジネスロジックに固有の異常を検出します。

シーケンスストアを使用する

ストレージコストを節約するために、ソースデータにシーケンスストアを使用することを検討してください。詳細については、HealthOmics ブログ記事の「Store omics data cost-effectively at any scale with HealthOmics」を参照してください。

実行間のファイルサイズの差異の影響

多くの場合、ユーザーは少数のテストデータを使用して実行を設計およびテストし、その後、本番環境の実行でファイルサイズに大きなばらつきがあるさまざまなデータに遭遇します。実行を最適化するときは、必ずこの差異を考慮してください。

次のリストは、ファイルサイズに大きな差異がある場合の最適化に関する推奨事項を示しています。

テストデータ内のさまざまなファイルサイズ

開発中は、代表的な分散量を持つテストデータを使用してください。

Run Analyzer を使用する

Run Analyzer ツールは、さまざまなサンプルで使用して、データサイズの差異を考慮します。

実行アナライザーを使用して、本番稼働用データサンプルの実行間の差異を把握できます。Run Analyzer の --batch モードを使用して、実行のバッチの統計を生成し、データセットの外れ値を処理するために必要な最大コンピューティングリソースを分析します。

たとえば、実行アナライザーにデータのフルフローセルをバッチモードで提供して、フルフローセルのピーク vCPU とメモリ使用率を把握できます。

入力データセットのサイズ分散を減らす

サンプルサイズに大きなばらつきがある場合は、HealthOmics のアップストリームでサンプルを分岐させ、バッチごとに異なるファイルシステムサイズを選択して、実行ストレージコストを節約できます。

WDL では、 size関数を使用して、大きなサンプルと小さなサンプルの個々のタスクのリソース割り当てを分割します。この戦略を最もコストの高いタスクに適用して、最も大きな影響を与えます。

Nextflow では、ファイルサイズまたはファイル名に基づいてリソース割り当てを階層化するための条件付きリソースを使用します。詳細については、Nextflow GitHub サイトの「条件付きプロセスリソース」を参照してください。

最適化が早すぎない

大幅なパフォーマンス調整作業に投資する前に、ワークフローコードとロジックを確定します。コードを変更すると、必要なリソースに大きな影響を与える可能性があります。開発プロセスで実行の最適化が早すぎると、最適化が過剰になるか、後でワークフロー定義が変更された場合に再度最適化が必要になる場合があります。

Run Analyzer ツールを定期的に再実行する

ワークフロー定義を経時的に変更した場合、またはサンプル分散が変更された場合は、Run Analyzer ツールを定期的に実行して、追加の最適化を行うことができます。

リソースの同時実行を最適化する方法

HealthOmics には、実行を大規模に処理する際のコストの制御と管理に役立つ以下の機能があります。

• 実行グループを使用して、コストとリソース使用量を制御します。タスクあたりの同時実行数、vCPUs、GPUs、合計実行時間に対して、実行グループの最大値を設定できます。別々のチームまたはグループが同じアカウントを使用している場合は、チームごとに個別の実行グループを作成できます。チームごと、および実行グループの最大値を設定することで、リソースの使用状況とコストを制御できます。詳細については、「HealthOmics 実行グループの作成」を参照してください。

• 開発中に、最大値が低い個別の実行グループを設定して、ランナウェイタスクをキャッチできます。

• Service Quotas は、過剰なリソースリクエストからアカウントを保護するのに役立ちます。クォータ値の増加をリクエストする方法など、Service Quotas の詳細については、「」を参照してください。 HealthOmics サービスクォータ