Trinity インプットデータの保存先ストレージの違いで処理時間に影響あるのか確認してみた （S3 vs インスタンスストア）
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Trinity は、RNA-Seq データからの de novo アセンブリで広く使用されているアプリケーションです。大規模なシーケンスデータを扱うため、インプットファイルの保存ストレージによる実行パフォーマンスの影響を確認します。本記事では Trinity の実行において Mountpoint for Amazon S3 を利用した場合と、インスタンスストア（EC2 のローカルディスク）を利用した場合の Trinity の実行速度を比較検証します。
検証結果サマリ
- Trinity のインプットファイルの保存場所（S3 vs インスタンスストア）が実行パフォーマンスに与える影響を検証した
- Trinity の実行においては Mountpoint for Amazon S3 でマウントしたディレクトリからシーケンスデータを読み込んで解析処理を実行しても処理時間に違いはみられなかった
検証内容・方法
Trinity のインプットファイルの保管場所（S3 vs インスタンスストア）が実行パフォーマンスに与える影響を確認します。S3 については Mountpoint for Amazon S3 でマウントした状態で評価します。
インプットファイルの保存場所
Moutpoint for Amazon S3 経由で S3 バケットを直接指定と、インスタンスストアに保存したファイル指定で速度に変化があるのかを確認します。
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 の実行環境と設定
検証に使用した 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 のインプットファイルはインスタンスストアに保存したファイルを指定します。Mountpoint for Amazon S3 経由で S3 から対象のシーケンスデータを解析実行前にインスタンスストアへコピーしてきます。
折りたたみ
#! /bin/bash
#SBATCH -p p2
#SBATCH -N 1
#SBATCH --cpus-per-task=16
#SBATCH -J "test-instance-store-m6id8x"
INSTANCE_CPU=16
INSTANCE_MEM=128
MOUNT_PATH="/mnt"
IMAGE_PATH="/mnt/s3-readonly/images"
USE_IMAGE="trinityrnaseq.v2.15.1.simg"
READ_FILE_PATH="/mnt/s3-readonly/reads"
LEFT_FILE="L1_R1.fastq"
RIGHT_FILE="D1_R1.fastq"
OUTPUT_PATH="/scratch"
SAVE_PATH="/home/ubuntu/results/"
# SLURM変数のデフォルト値設定
SLURM_JOB_NAME=${SLURM_JOB_NAME:-"default-job-name"}
SLURM_JOB_ID=${SLURM_JOB_ID:-"default-id"}
# /scratchディレクトリが存在しない場合は作成する
if [ ! -d "${OUTPUT_PATH}" ]; then
sudo mkdir -p "${OUTPUT_PATH}"
sudo chown ubuntu. "${OUTPUT_PATH}"
shdo chmod 777 "${OUTPUT_PATH}"
fi
# 出力結果保存先ディレクトリが存在しない場合は作成する
if [ ! -d "${SAVE_PATH}" ]; then
sudo mkdir -p "${SAVE_PATH}"
fi
# リードファイルをローカルにコピー
cp ${READ_FILE_PATH}/${LEFT_FILE} ${OUTPUT_PATH}
cp ${READ_FILE_PATH}/${RIGHT_FILE} ${OUTPUT_PATH}
# Trynity実行
apptainer exec --bind ${MOUNT_PATH}:/mnt --bind /scratch:/scratch \
-e ${IMAGE_PATH}/${USE_IMAGE} \
Trinity \
--seqType fq \
--single ${OUTPUT_PATH}/${LEFT_FILE},${OUTPUT_PATH}/${RIGHT_FILE} \
--CPU ${SLURM_CPUS_PER_TASK} \
--max_memory ${INSTANCE_MEM}G \
--output ${OUTPUT_PATH}/${SLURM_JOB_NAME}-${SLURM_JOB_ID}/trinity_out_dir
# 出力結果のディレクトリをtarで固める
tar -zcf ${SLURM_JOB_NAME}-${SLURM_JOB_ID}.tar.gz -C ${OUTPUT_PATH} ${SLURM_JOB_NAME}-${SLURM_JOB_ID}
# 出力結果のディレクトリを永続ストレージへ退避
mkdir -p ${SAVE_PATH}
mv ${SLURM_JOB_NAME}-${SLURM_JOB_ID}.tar.gz ${SAVE_PATH}
Trinity インプットファイルの指定先は Moutpoint for Amazon S3 経由で S3 を直接指定しています。
折りたたみ
#! /bin/bash
#SBATCH -p p2
#SBATCH -N 1
#SBATCH --cpus-per-task=16
#SBATCH -J "test-mountpoint-s3-m6id8x"
INSTANCE_CPU=16
INSTANCE_MEM=128
MOUNT_PATH="/mnt"
IMAGE_PATH="/mnt/s3-readonly/images"
USE_IMAGE="trinityrnaseq.v2.15.1.simg"
READ_FILE_PATH="/mnt/s3-readonly/reads"
LEFT_FILE="L1_R1.fastq"
RIGHT_FILE="D1_R1.fastq"
OUTPUT_PATH="/scratch"
SAVE_PATH="/home/ubuntu/results/"
# SLURM変数のデフォルト値設定
SLURM_JOB_NAME=${SLURM_JOB_NAME:-"default-job-name"}
SLURM_JOB_ID=${SLURM_JOB_ID:-"default-id"}
# /scratchディレクトリが存在しない場合は作成する
if [ ! -d "${OUTPUT_PATH}" ]; then
sudo mkdir -p "${OUTPUT_PATH}"
sudo chown ubuntu. "${OUTPUT_PATH}"
shdo chmod 777 "${OUTPUT_PATH}"
fi
# 出力結果保存先ディレクトリが存在しない場合は作成する
if [ ! -d "${SAVE_PATH}" ]; then
sudo mkdir -p "${SAVE_PATH}"
fi
# Trynity実行
apptainer exec --bind ${MOUNT_PATH}:/mnt --bind /scratch:/scratch \
-e ${IMAGE_PATH}/${USE_IMAGE} \
Trinity \
--seqType fq \
--single ${READ_FILE_PATH}/${LEFT_FILE},${READ_FILE_PATH}/${RIGHT_FILE} \
--CPU ${SLURM_CPUS_PER_TASK} \
--max_memory ${INSTANCE_MEM}G \
--output ${OUTPUT_PATH}/${SLURM_JOB_NAME}-${SLURM_JOB_ID}/trinity_out_dir
# 出力結果のディレクトリをtarで固める
tar -zcf ${SLURM_JOB_NAME}-${SLURM_JOB_ID}.tar.gz -C ${OUTPUT_PATH} ${SLURM_JOB_NAME}-${SLURM_JOB_ID}
# 出力結果のディレクトリを永続ストレージへ退避
mkdir -p ${SAVE_PATH}
mv ${SLURM_JOB_NAME}-${SLURM_JOB_ID}.tar.gz ${SAVE_PATH}
実行時間の測定方法
インプットファイルの指定先ごとに、Trinity の実行を 3 回ずつ行いました。実行終了後に保存される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 実行においては Mountpoint for Amazon S3 でマウントしたディレクトリからシーケンスデータを読み込んで解析処理を実行可能であり、実行速度に違いはみられませんでした。
Trinity 実行速度の比較
インプットファイルは S3 から直接読み込みと、一度ローカルに保存して読み込みにはほぼ変化はありませんでした。
| 1回目 | 2回目 | 3回目 | 平均（秒） | |
|---|---|---|---|---|
| インスタンスストア指定 | 654 | 652 | 650 | 652.00 |
| S3 指定 | 662 | 650 | 652 | 654.67 |
実行時の CPU 使用率比較
同じインスタンスタイプで実行していることもあり、インプットファイルの指定先違いのでは変化ありませんでした。
S3 指定のネットワーク IN/OUT 確認
Mountpoint for Amazon S3 経由で S3 に保存しているファイルを直接読み込んでいるため、ある程度のネットワークトラフィックはありました。後半の赤色の山はインスタンスストアに書き出した実行結果をヘッドノードの EBS へ退避にしたときのネットワークアウトのトラフィックです。
インスタンスストア指定のネットワーク IN/OUT 確認
最初に S3 からインスタンスストアへシーケンスデータをコピーしているため、実行開始時にネットワークインのトラフィック（ファイルのダウンロード）が S3 指定と比べると 4 倍高い値になっています。後半のオレンジの山は同じ理由でインスタンスストアに書き出した実行結果をヘッドノードの EBS へ退避したためです。
考察・展望
今回の検証結果から、以下の知見が得られました。
- Trinity の実行において、インプットファイルの指定先が S3 であっても、Mountpoint for Amazon S3 を利用することで、インスタンスストアに保存した場合と同等の実行速度が得られる。
-
Mountpoint for Amazon S3 を活用すれば、シーケンスデータを S3 に保存することで低コストかつ耐久性の高いデータ保存が可能になる。さらに、複数のクラスター（EC2）からも同じデータにアクセスできるため、データの共有が容易になる。
-
Apptainer を使用することで Trinity の実行環境を再現性の高い形で構築できる。これにより、異なる環境間での解析結果の一貫性を確保しやすくなる。
以上より、Mountpoint for Amazon S3 と Apptainer を組み合わせることで、シーケンスデータの保存コストとデータ取り回しの観点から最適化された Trinity 実行環境を実現できると考えられます。
おわりに
Trinity を例にして Apptaienr の利用時の構成最適化に向けて引き続き検証した結果を共有していきます。
