Hydration 테스트

실제문제점 오류 로그:발견

/dev/nvme0n1p1 /mnt/lustre xfs ro,noatime,attr2,inode64,noquota 0 0
Host /mnt/lustre contents:
total 0
drwxr-xr-x 2 root root  6 Jan  6 02:43 .
drwxr-xr-x 1 root root 20 Jan  6 02:44 ..

NVMe 인스턴스 스토어가 FSx Lustre 마운트를 덮어씌워 디렉토리가 비어있음

FSx Lustre 예상 성능 (이론적)

AWS: FSx for LustreLustre의 S3 Data Repository는 "Lazy Loading" 방식으로 동작

• 파일이 S3에만 있고, FSx에서 처음 접근 시 hydration 발생
• 첫 접근 시 S3→FSx 데이터 전송으로 인해 심각한 성능 저하

Hydration 방법 테스트:

1. dd 명령어 기반: 모든 파일을 순차적으로 읽어 hydration (1,075초, 18분 소요)
2. lfs hsm_restore 기반: AWS 권장 병렬 hydration 방식 (검증 완료, 0초 - 이미 hydration됨)

FSx BLAST 성능 측정

v11 테스트 (S3 Lazy Loading 영향 받음)

v13 테스트 (Full Hydration 후, 4개 작업 동시 실행)

FSx 성능 분석

예상과 다른 결과의 원인

1. 처리량 공유 문제:

   • FSx Scratch 2 (1.2 TB) 기준:기본 처리량: 240 MB/s (200 MB/s/TiB × 1.2 TiB)
   • 4개 작업 동시 실행 시: 작업당 ~60 MB/s
   • 254 GB 데이터베이스 읽기: 60 MB/s로 70분+ 소요

2. 버스트 크레딧 소진:

   • 버스트 처리량: 최대 ~1.44 GB/s
   • 크레딧 기반으로 장시간 워크로드에서 소진됨

3. v11 50,000 테스트가 빨랐던 이유:

   • 단일 작업 실행으로 전체 처리량 독점
   • 이전 hydration으로 데이터가 FSx 캐시에 존재

FSx Lustre 처리량 상세 사양

FSx Lustre 비용 (ap-northeast-2)

5. 비용 비교 분석

월간 비용 시나리오

시나리오 1: 간헐적 사용 (주 1-2회, 일일 1시간)

시나리오 2: 집중 사용 (일일 수십 회)

손익분기점 분석

• 일일 4회 이상 BLAST 실행 시: FSx Lustre가 더 경제적
• 주 1회 미만: EFS가 더 경제적 (스토리지 비용만 발생)

6. 최종 권장사항 (실제 테스트 계획결과 (벤치마크 스크립트)기반)

주요 발견사항

1. FSx Scratch 2는 BLAST 워크로드에 부적합:

   • 1.2 TB Scratch 2의 기본 I/O처리량(240 벤치마크MB/s)이

     #!/bin/bash다중 #작업 io_benchmark.sh시 MOUNT_POINTS=("/mnt/fsx"병목

   "/mnt/efs")
   • 4개 for동시 MOUNT작업 in시 "${MOUNT_POINTS[@]}";작업당 do60 echoMB/s로 "===EFS Testing대비 $MOUNT8-29배 ==="느림
   #
   • S3 순차Data 읽기Repository의 Lazy Loading으로 첫 접근 시 심각한 지연

2. EFS Elastic이 BLAST 워크로드에 적합:

   • 워크로드에 따른 자동 처리량 확장
   • 다중 작업 시에도 안정적인 성능
   • 설정 및 관리가 간편

EFS 추천 ✅ (BLAST 주요 패턴) fio --name=seq-read \ --directory=$MOUNT \ --rw=read \ --bs=1M \ --size=50G \ --numjobs=16 \ --ioengine=libaio \ --iodepth=32 \ --runtime=300 \ --time_based \ --group_reporting \ --output=$MOUNT-seq-read.json \ --output-format=json # 랜덤 읽기 (인덱스 접근) fio --name=rand-read \ --directory=$MOUNT \ --rw=randread \ --bs=4K \ --size=10G \ --numjobs=16 \ --runtime=300 \ --time_based \ --group_reporting \ --output=$MOUNT-rand-read.json \ --output-format=json done

BLAST 벤치마크워크로드)

#!/bin/bash
# blast_benchmark.sh

STORAGE=$1  # /mnt/fsx or /mnt/efs
THREADS=${2:-32}
RESULTS_DIR="results_$(basename $STORAGE)_$(date +%Y%m%d_%H%M%S)"

mkdir -p $RESULTS_DIR

# DB 복사 (캐시 영향 제거)
echo "Copying database to $STORAGE..."
time rsync -av --progress /data/blast_db/ $STORAGE/blast_db/

# 캐시 클리어
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

# 
테스트 1: 소형 쿼리 (빠른 반복)
echo "Test 1: Small queries"
for i in {1..10}; do
    /usr/bin/time -v blastn \
        -db $STORAGE/blast_db/nt \
        -query small_query.fasta \
        -num_threads $THREADS \
        -out $RESULTS_DIR/small_$i.txt \
        2>> $RESULTS_DIR/small_timing.log
done

# 테스트 2: 중형 쿼리
echo "Test 2: Medium queries"
/usr/bin/time -v blastn \
    -db $STORAGE/blast_db/nt \
    -query sample_queries.fasta \
    -num_threads $THREADS \
    -out $RESULTS_DIR/medium.txt \
    -outfmt "6 qseqid sseqid pident length mismatch gapopen qstart qend sstart send evalue bitscore" \
    2> $RESULTS_DIR/medium_timing.log