Trinity 中間ファイルの保存先ストレージの違いで処理時間に影響あるのか確認してみた

大村保貴

2024.05.18

Trinity は RNA-Seq データの de novo アセンブリで広く使われるアプリケーションです。本記事では、中間ファイルの保存先ストレージが実行パフォーマンスに与える影響を検証します。具体的には、インスタンスストア、EBS、EFS の実行速度を比較し、その結果を分析します。

検証結果サマリ

Trinity の中間ファイルの生成場所が実行パフォーマンスに与える影響を検証
- インスタンスストア vs EBS（gp3） vs EFS（Elastic スループットモード）
インスタンスストアと EBS（gp3）の実行速度がほぼ同じ
- ディスクアクセス以外のところにボトルネックがある可能性あり
EFS（Elastic スループットモード）は他のストレージと比べて実行速度が約 3 倍遅い

検証内容・方法

Trinity の実行中には多くの中間ファイルが生成されます。これらのファイルは高い I/O 性能を必要とします。そのため、保存先のストレージ性能が実行パフォーマンスに大きく影響します。本検証では、インスタンスストア、EBS、EFS を使用して実行パフォーマンスに与える影響を確認します。

中間ファイルの保存場所

中間ファイルの生成先は以下のストレージを利用して実行時間を確認します。

インスタンスストア: 一部の EC2 インスタンスに付属する高い I/O 性能のブロックストレージ。インスタンス停止でデータが失われるため、解析終了後に永続ストレージへ退避します。
EBS（Elastic Block Store）: 標準的なブロックストレージサービスで、よく利用される gp3 タイプを使用します。性能は 3000 IOPS、スループットは 125MiB/s です。プロビジョンド IOPS（io2）は使用しません。
EFS（Elastic File System）: 複数の EC2 インスタンスから同時にアクセス可能なファイルストレージサービス。Elastic スループットモードを利用します。

テスト用のインプットファイル

Trinity のインプットファイルにはシロイヌナズナのシーケンスデータを使用します。

# ファイルサイズ 77 MB
$ ./seqstats /mnt/s3-readonly/reads/D1_R1.fastq
Total n:    382799
Total seq:  29047372 bp
Avg. seq:   75.88 bp
Median seq: 76.00 bp
N 50:       76 bp
Min seq:    51 bp
Max seq:    76 bp

# ファイルサイズ 97 MB
$ ./seqstats /mnt/s3-readonly/reads/L1_R1.fastq
Total n:    485913
Total seq:  36864248 bp
Avg. seq:   75.87 bp
Median seq: 76.00 bp
N 50:       76 bp
Min seq:    51 bp
Max seq:    76 bp

Trinityの実行環境と設定

検証に使用した AWS ParallelCluster のバージョンとコンピュートノードのスペックは以下の通りです。

項目	値
AWS ParallelCluster	3.9.1
OS	Ubuntu 22.04
Compute Node	m6id.8xlarge
CPU	16 core
Memory	128 GB
Simultaneous Multi-Threading	無効

Trinity のバージョンは以下の通りです。Apptainer コンテナで実行します。

項目	値
Trinity	v2.15.1

実行時間の測定方法

中間ファイルの保存先のストレージごとに、Trinity の実行を 5 回ずつ行いました。実行終了後に保存される Trinity.timing ファイルから解析処理にかかった時間を確認します。

Trinity.timing には以下の様に開始時刻と、終了時刻、各フェーズでかかった時間が記録されます。

Statistics:
===========
Trinity Version:      Trinity-v2.15.1
Compiler:             GCC
Trinity Parameters:   --seqType fq --single /mnt/s3-readonly/reads/L1_R1.fastq,/mnt/s3-readonly/reads/D1_R1.fastq --CPU 16 --max_memory 128G --output /scratch/test-mountpoint-s3-m6id8x-29/trinity_out_dir
Unpaired read mode
 Input data
  Single.fasta  78 MByte
  Number of unique KMERs: 12092362
  Number of reads:        659537 Output data
  Trinity.fasta 0 MByte

Runtime
=======
Start:       Mon May  6 08:14:09 UTC 2024
End:         Mon May  6 08:25:01 UTC 2024
Trinity   652 seconds
  Inchworm (phase 1 - read clustering)  19 seconds
  Chrysalis (phase 1 - read clustering) 603 seconds
  Rest (phase 2 - parallel assembly)       30 seconds

実行結果

Trinity実行速度の比較

インスタンスストアと EBS（gp3）の実行速度がほぼ同じでした。EFS は高い I/O 性能が必要になると遅く、不向きでした。

ストレージタイプ	1回目	2回目	3回目	4回目	5回目	平均
インスタンスストア	660	660	665	673	654	662.40
EBS（gp3）	652	673	669	662	658	662.80
EFS（Elastic スループット）	1830	1754	1689	1674	1549	1699.20

ディスクアクセスのメトリクス

解析実行中のディスク読み書きのメトリクスです。とちらも大差ない結果でした。

インスタンスストア

EBS（gp3）

EFS Elastic スループットモードの課金

Elastic スループットモードの読み書き課金は $0 の状態から検証を始めました。中間ファイルの生成先が EFS になると、読み書きが発生するため課金されます。今回の検証では、EFS が最もパフォーマンスが悪く、読み書きで従量課金も発生するため、最もコストパフォーマンスが悪い結果となりました。

検証前

検証後

考察・展望

インスタンスストアと EBS（gp3）の実行速度がほぼ同じであることから、ディスク I/O 以外にボトルネックがあると考えています。一方、EFS は高い I/O 性能を要求する用途には適していないことが明らかになりました。今後はボトルネックを特定し、さらなる最適化を図る予定です。

おわりに

インスタンスストアの実行速度が一番早いと予想していましたが、EBS（gp3）と実行速度という結果でした。Trinity 実行のために Apptainer を利用していることもあり、Apptainer の設定不備の可能性もあり、切り分けができていません。CloudWatch のメトリクスを細かく確認していこうかと思ったのですが、Trinity の実行オプションに --monitor がありました。概ね必要そうなデータが取れそうなので Apptainer 環境でも実行可能か試すところからはじめてみます。

Trinity Runtime Profiling · trinityrnaseq/trinityrnaseq Wiki