EBS Snapshot 프로비저닝 성능 분석
EBS Snapshot 기반 프로비저닝 성능 분석
작성일: 2026-01-07 리전: ap-northeast-2 (Seoul)
개요
EBS Snapshot 기반으로 EC2 인스턴스를 프로비저닝할 때 발생하는 Lazy Loading 메커니즘과 BLAST 워크로드에 미치는 영향을 분석합니다.
1. EBS Snapshot 복원 동작 방식
Lazy Loading (기본 동작)
┌─────────────────────────────────────────────────────────────────┐
│ EBS Snapshot 복원 과정 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ S3 (Snapshot 저장소) │
│ ┌──────────────────┐ │
│ │ ████████████████ │ 300GB Snapshot │
│ └────────┬─────────┘ │
│ │ │
│ │ ① 볼륨 생성 요청 (즉시 완료 - 수 초) │
│ ▼ │
│ ┌──────────────────┐ │
│ │ EBS Volume │ 볼륨은 즉시 "Available" 상태 │
│ │ (논리적 생성) │ │
│ └────────┬─────────┘ │
│ │ │
│ │ ② 실제 데이터 접근 시 (Lazy Loading) │
│ ▼ │
│ ┌──────────────────┐ │
│ │ 블록 A 읽기 요청 │──▶ S3에서 해당 블록만 다운로드 │
│ │ 블록 B 읽기 요청 │──▶ S3에서 해당 블록만 다운로드 │
│ │ ... │ (첫 접근 시 지연 발생) │
│ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
성능 영향
| 상황 | 성능 | 설명 |
|---|---|---|
| 첫 번째 블록 접근 | 느림 (3-5 MB/s per TiB) | S3에서 다운로드 |
| 이미 로드된 블록 | 빠름 (gp3 최대 성능) | 로컬 EBS에서 읽기 |
| 전체 DB 첫 스캔 | 병목 발생 가능 | BLAST DB 전체 읽기 시 |
2. BLAST 워크로드 영향 분석
254GB BLAST DB의 첫 로딩 시간 (이론값)
Lazy Loading 속도: ~150-300 MB/s (실측 기반)
254GB 전체 로딩: 254,000 MB ÷ 200 MB/s ≈ 21분
vs
EBS gp3 네이티브 속도: 1,000 MB/s
254GB 전체 로딩: 254,000 MB ÷ 1,000 MB/s ≈ 4.2분
실제 테스트에서 2~3분이 나온 이유
- 부분 접근: BLAST가 전체 DB를 순차적으로 읽지 않음
- 인덱스 중심: 인덱스 파일 위주로 접근 (전체의 10-20%)
- 병렬 I/O: 멀티스레드로 효율적 병렬 로딩
- 접근 패턴: BLAST의 검색 알고리즘이 모든 블록을 읽지 않음
볼륨 크기별 예상 초기화 시간
| 볼륨 크기 | Lazy Loading (전체 읽기) | gp3 네이티브 | BLAST 실제 |
|---|---|---|---|
| 100 GB | ~8분 | ~1.7분 | ~2분 |
| 254 GB | ~21분 | ~4.2분 | ~3분 |
| 500 GB | ~42분 | ~8.3분 | ~5분 |
| 1 TB | ~85분 | ~17분 | ~10분 |
3. 해결 방안
방안 1: Fast Snapshot Restore (FSR)
┌─────────────────────────────────────────────────────────────────┐
│ Fast Snapshot Restore 활성화 시 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ S3 Snapshot │ ───▶ │ Pre-initialized │ │
│ │ │ │ Volume Pool │ │
│ └──────────────────┘ └────────┬─────────┘ │
│ │ │
│ │ 즉시 사용 가능 │
│ ▼ │
│ ┌──────────────────┐ │
│ │ EBS Volume │ │
│ │ (Full Performance)│ │
│ │ from Block 1 │ │
│ └──────────────────┘ │
│ │
│ ✅ 첫 접근부터 최대 성능 (16,000 IOPS, 1,000 MB/s) │
│ │
└─────────────────────────────────────────────────────────────────┘
FSR 활성화:
aws ec2 enable-fast-snapshot-restores \
--availability-zones ap-northeast-2a ap-northeast-2c \
--source-snapshot-ids snap-0da0e59a29928ee10
FSR 비용 (ap-northeast-2):
| 구성 | 시간당 | 일간 | 월간 |
|---|---|---|---|
| 1 AZ | $0.75 | $18 | $540 |
| 2 AZ | $1.50 | $36 | $1,080 |
방안 2: EBS 초기화 스크립트 (비용 효율적)
#!/bin/bash
# User Data에서 볼륨 초기화 강제 실행
# 방법 1: dd를 사용한 전체 읽기
dd if=/dev/nvme1n1 of=/dev/null bs=1M status=progress
# 방법 2: fio 사용 (더 빠름, 병렬 처리)
fio --name=init --filename=/dev/nvme1n1 --rw=read --bs=1M \
--direct=1 --numjobs=4 --iodepth=32 --runtime=0
예상 초기화 시간:
| 방법 | 300GB 초기화 시간 |
|---|---|
| dd (단일 스레드) | ~25분 |
| fio (병렬) | ~17분 |
| 인덱스만 로딩 | ~5분 |
방안 3: Instance Store + S3 복사 (r6id)
#!/bin/bash
# NVMe Instance Store로 S3에서 직접 복사
aws s3 sync s3://blast-db/core_nt/ /mnt/nvme/blast_db/ \
--only-show-errors
# 예상 시간: 300GB ÷ 500MB/s ≈ 10분
방안 4: 상시 인스턴스 유지
# AWS Batch Compute Environment 설정
aws batch update-compute-environment \
--compute-environment blast-ebs-r6i-ce \
--compute-resources minvCpus=96
4. 방안별 비교
| 방안 | 초기화 시간 | 추가 비용/월 | BLAST 성능 | 권장 상황 |
|---|---|---|---|---|
| Lazy Loading (기본) | 0분 (지연 분산) | $0 | 첫 실행 느림 | 간헐적 사용 |
| FSR 활성화 | 0분 | $540+ | 최고 | 빈번한 실행 |
| dd/fio 초기화 | ~17분 | $0 | 최고 | 비용 절감 |
| Instance Store + S3 | ~10분 | r6id 비용 | 최고 | 대규모 배치 |
| 상시 인스턴스 | 0분 | $1,680+ (Spot) | 최고 | 연속 작업 |
5. 비용 최적화 시나리오
시나리오 A: 일 4회 이하 실행
설정: 기본 Lazy Loading 사용
월 추가 비용: $0
첫 Job: 느림 (DB 로딩 ~5분 포함)
이후 Job: 빠름 (인스턴스 재사용 시)
시나리오 B: 일 10회+ 실행
FSR 비용: $540/월 (1 AZ)
Job당 시간 절감: ~3-5분
월 120 jobs × 4분 절감 = 8시간 EC2 절감 = $62
순 비용 증가: $478/월
→ 시간이 중요한 경우에만 권장
시나리오 C: 비용 최적화 (병렬 초기화)
#!/bin/bash
# Launch Template User Data - 병렬 초기화
# 백그라운드에서 볼륨 초기화 시작
nohup dd if=/dev/nvme1n1 of=/dev/null bs=1M 2>/dev/null &
# ECS 에이전트 즉시 시작 (초기화와 병렬)
systemctl start ecs
6. 권장사항 요약
| 사용 패턴 | 권장 방안 | 예상 총 비용/월 |
|---|---|---|
| 테스트/개발 | Lazy Loading | $50-100 |
| 일 1-5회 운영 | 초기화 스크립트 | $100-200 |
| 일 10회+ 운영 | FSR 또는 상시 인스턴스 | $500-700 |
| 대규모 배치 | r6id + S3 복사 | 상황별 |
7. 결론
현재 EBS Snapshot 기반 테스트에서 ~3분 DB 로딩 시간이 측정된 것은 BLAST의 접근 패턴 특성 덕분입니다:
- 전체 DB를 순차 읽기하지 않음
- 인덱스 파일 집중 접근
- Lazy Loading이 효율적으로 동작
대부분의 BLAST 워크로드에서 Lazy Loading 기본 동작으로도 충분한 성능을 얻을 수 있습니다. 추가 최적화는 실행 빈도와 시간 요구사항에 따라 선택적으로 적용하면 됩니다.
작성일: 2026-01-07
No comments to display
No comments to display