지난 포스팅에서 AWS EC2 인스턴스에 Docker를 설정하고 인스턴스 스토어를 활용하는 방법을 다뤘습니다. 오늘은 한 단계 더 나아가 Docker 컨테이너가 실제로 어떤 스토리지를 사용하는지, 그리고 각 디스크별 역할과 데이터 저장 경로를 실험을 통해 상세히 분석해보겠습니다.
EC2 인스턴스의 스토리지 구성 이해하기
각 디스크와 파티션 정리
EC2 인스턴스에서 사용되는 스토리지를 정확히 이해하는 것이 중요합니다. 흔히 헷갈리는 /dev/root와 실제 EBS 디스크의 관계부터 살펴보겠습니다.
# 루트 파티션이 실제로 어떤 장치에 마운트되었는지 확인
findmnt -T /
# 모든 블록 디바이스 확인
lsblk
# 모든 마운트된 파일시스템 확인 (EFS 포함)
df -hT핵심 포인트
- /dev/root는 부팅 시점에 커널이 임시로 붙이는 이름입니다
- 실제 장치는 /dev/nvme1n1p1 (EBS 루트 파티션)입니다
- EFS는 물리적 블록 디바이스가 아니므로 lsblk에서는 보이지 않습니다
스토리지 종류별 특성
| 스토리지 |
종류디바이스 이름 | 파일 시스템 | 마운트 경로 | 주요 용도 |
| EBS 루트 디스크 | /dev/nvme1n1p1 | ext4 | / | OS, 설정, 루트 데이터 저장 |
| EBS 부트 파티션 | /dev/nvme1n1p15 | vfat | /boot/efi | EFI 부팅용 |
| 인스턴스 스토어 | /dev/nvme0n1 | ext4 | /mnt/ephemeral0 | Docker data-root, 캐시 저장 |
| EFS | 없음 | nfs4 | /mnt/efs | 네트워크 스토리지 |
EBS 용량에 포함되는 경로
- /, /var, /etc, /home 등 루트 파티션 하위 경로
EBS 용량에 포함되지 않는 경로
- /boot/efi (EFI 파티션)
- /mnt/ephemeral0 (인스턴스 스토어)
- /mnt/efs (EFS 네트워크 스토리지)
- /proc, /sys, /dev, /run (가상 파일시스템)
Docker Root Directory 설정과 데이터 흐름
Docker 데이터 저장 위치 변경
현재 Docker root directory를 인스턴스 스토어로 변경한 상태입니다.
기본 설정
기본 경로: /var/lib/docker현재 설정
// /etc/docker/daemon.json
{
"data-root": "/mnt/ephemeral0/docker"
}Docker Root Directory의 하위 구조
/mnt/ephemeral0/docker/
├── image/ # 이미지 레이어 메타데이터
├── overlay2/ # 컨테이너 파일시스템 계층 (쓰기 영역)
├── containers/ # 컨테이너 로그 및 설정 파일
├── volumes/ # 볼륨 데이터
├── buildkit/ # 이미지 빌드 캐시
├── network/ # 네트워크 설정
└── tmp/ # 임시 파일각 디렉터리의 역할을 정리하면 다음과 같습니다.
| 디렉터리 | 역할 | 저장되는 데이터 |
| image/ | 이미지 계층 데이터 관리 | 이미지 레이어, 메타데이터 |
| overlay2/ | 컨테이너 파일시스템 계층 | 컨테이너 실행 중 변경되는 파일, 레이어 diff |
| containers/ | 각 컨테이너 메타데이터 | 실행 로그, 설정 파일 |
| volumes/ | 컨테이너 볼륨 데이터 | docker run -v로 마운트한 데이터 |
| buildkit/ | 이미지 빌드 캐시 | 빌드 레이어 |
| network/ | 네트워크 설정 | 브리지 네트워크 정보 |
| tmp/ | 임시 파일 | 컨테이너 생성 시 임시 데이터 |
Docker 데이터 흐름도
┌───────────────────────────────────────┐
루트 EBS (/dev/nvme1n1p1)
/usr/bin/dockerd (도커 실행 파일)
/etc/docker/daemon.json (도커 설정)
/var/log/* (시스템 로그)
└───────────────────────────────────────┘
│
│ data-root 설정
▼
┌───────────────────────────────────────────────┐
인스턴스 스토어 (ephemeral0, /dev/nvme0n1)
/mnt/ephemeral0/docker
├── image/ (이미지 레이어)
├── overlay2/ (컨테이너 실행 데이터)
├── containers/ (컨테이너 메타데이터)
└── volumes/ (볼륨 데이터)
└───────────────────────────────────────────────┘
💡 정확한 정보를 수집하기 위해 몇 가지 실험을 진행하기로 했다.
실험 1: 컨테이너 실행 시 스토리지 사용량 변화 분석
실험 설계
1. 가설
컨테이너 실행 후 EBS 볼륨의 /var/log만 변화하고, 주요 데이터는 /mnt/ephemeral0/docker에 저장될 것입니다.
2. 측정 시점
- 도커 설치 후 컨테이너 실행 전
- 도커 컨테이너 실행 직후
- API 실행 직후
3. 측정 방법
각 시점에서 주요 경로의 디스크 사용량을 측정하여 어떤 경로에서 용량 변화가 발생하는지 확인합니다.
실험 결과
컨테이너 실행 전
417M /usr/bin # 도커 실행 파일 포함, 시스템 실행 바이너리
18M /var/log # 도커·시스템 로그 저장소
256K /var/lib/docker # 도커 기본 경로 (사용하지 않음)
324K /mnt/ephemeral0/docker # 인스턴스 스토어 기반 도커 데이터 루트
8.0K /etc/docker # 도커 설정 파일컨테이너 실행 직후
417M /usr/bin # 변화 없음
18M /var/log # 변화 없음
256K /var/lib/docker # 변화 없음
24G /mnt/ephemeral0/docker # 324K → 24G 급격한 증가
8.0K /etc/docker # 변화 없음API 실행 후
417M /usr/bin # 변화 없음
18M /var/log # 변화 없음
256K /var/lib/docker # 변화 없음
24G /mnt/ephemeral0/docker # 용량 유지
8.0K /etc/docker # 변화 없음실험 결과 분석
가설 검증 완료
- EBS 루트 디스크의 사용량은 거의 변화가 없었습니다
- 모든 Docker 컨테이너 데이터는 인스턴스 스토어에 저장되었습니다
- 컨테이너 실행으로 324K에서 24G로 급격한 용량 증가를 확인했습니다
주요 발견사항
- Docker의 data-root 설정이 정확히 동작함을 확인
- EBS는 시스템 파일과 설정 파일만 저장
- 컨테이너 이미지와 실행 데이터는 모두 인스턴스 스토어 사용
실험 2: Docker Volume vs Bind Mount 동작 차이
Volume 경로 분석 실험
컨테이너가 Docker Volume을 실제로 사용하는지 확인해보았습니다.
각 시점별 volumes 디렉터리 용량
# 컨테이너 실행 전
36K /mnt/ephemeral0/docker/volumes
# 컨테이너 실행 후
36K /mnt/ephemeral0/docker/volumes
# API 실행 후
36K /mnt/ephemeral0/docker/volumes실험 결과
Volume 디렉터리에는 변화가 없었습니다.
원인 분석
컨테이너 실행 시 -v /mnt/efs/saved_sd15:/mnt/efs/saved_sd15 바인드 마운트를 사용하기 때문에, 실제 애플리케이션 데이터는 EFS에 저장됩니다.
Bind Mount vs Volume 정리
Bind Mount
- 호스트의 특정 경로를 컨테이너에 직접 마운트
- 호스트 파일시스템에 직접 접근
- 현재 설정에서 EFS 마운트에 사용
Docker Volume
- Docker가 관리하는 볼륨 영역 사용
- /mnt/ephemeral0/docker/volumes 하위에 저장
- 현재 설정에서는 사용하지 않음
인스턴스 스토어의 중요한 한계점
중지/시작 시 데이터 손실 문제
AWS 공식 문서
"Data on an instance store volume persists even if the instance is rebooted. However, the data does not persist if the instance is stopped, hibernated, or terminated."
실제 테스트 결과
- 재부팅: 데이터 보존됨
- 중지 후 시작: 인스턴스 스토어 데이터 완전 손실
이는 Docker 환경에서 매우 중요한 문제입니다. 24GB의 컨테이너 이미지와 캐시 데이터가 인스턴스 중지 시 모두 사라지게 됩니다.
데이터 손실 대응 방안
방안 1: 백업/복원 자동화
- 인스턴스 중지 전 /mnt/ephemeral0 데이터를 S3에 백업
- 시작 시 인스턴스 스토어를 /mnt/ephemeral0 경로에 재마운트
- S3에서 백업 데이터를 자동으로 복원
# 백업 스크립트 예시
tar -czf docker-backup.tar.gz /mnt/ephemeral0/docker
aws s3 cp docker-backup.tar.gz s3://my-backup-bucket/
# 복원 스크립트 예시
aws s3 cp s3://my-backup-bucket/docker-backup.tar.gz .
tar -xzf docker-backup.tar.gz -C /방안 2: 하이브리드 스토리지 전략
- EBS: Docker 설정 및 자주 사용하는 기본 이미지
- 인스턴스 스토어: 임시 캐시 및 빌드 데이터
- EFS: 영구 보관이 필요한 데이터 (모델, 설정)
방안 3: 컨테이너 이미지 최적화
- 자주 사용하는 이미지를 사전 빌드하여 다운로드 시간 단축
- 레이어 캐시 전략으로 재빌드 시간 최소화
- ECR 등의 이미지 레지스트리 적극 활용
결론 및 권장사항
1. 핵심 발견 사항
- Docker 데이터 흐름 검증
Docker의 data-root 설정이 정확히 동작함을 확인
EBS는 시스템 파일과 설정만 저장하고, 모든 컨테이너 데이터는 인스턴스 스토어에 저장
- 바인드 마운트 활용
Docker Volume 대신 EFS 바인드 마운트 사용
모델 파일과 중요 데이터의 영속성을 EFS로 보장
- 인스턴스 스토어의 특성
뛰어난 I/O 성능과 비용 효율성
중지/시작 시 데이터 완전 손실이라는 치명적 한계
2. 환경별 권장 전략
- 개발 및 테스트 환경
인스턴스 스토어 활용으로 빠른 I/O 성능 확보
비용 효율적인 임시 환경 구성
데이터 손실에 대한 부담이 적음
- 운영 환경
EBS로 Docker root 설정하여 데이터 안정성 확보
또는 자동 백업/복원 시스템을 구축하여 인스턴스 스토어 활용
EFS와의 하이브리드 구성으로 최적의 성능과 안정성 달성
- 성능 최적화가 중요한 환경
인스턴스 스토어 + 자동 백업 시스템
컨테이너 이미지 최적화로 복원 시간 단축
모니터링 시스템으로 데이터 손실 위험 관리
다음 포스팅에서는 이러한 분석 결과를 바탕으로 운영 환경에 최적화된 Docker 스토리지 아키텍처 설계 방법을 구체적으로 다뤄보겠습니다.
관련 포스팅
'development > 머신러닝 운영' 카테고리의 다른 글
| AWS 인스턴스 스토어(ephemeral0)로 EBS 용량 한계 극복하기 (6) | 2025.08.10 |
|---|---|
| EBS 최소 볼륨 실험기 & gp3로 전환한 이유 (4) | 2025.08.10 |
| 🐳 Stable Diffusion API Docker 패키징: 로컬 모델 조립 → 컨테이너화까지 (5) | 2025.08.09 |
| EFS에 모델 구성요소 저장하고, 컨테이너에서 불러오는 구조로 전환하기 (3) | 2025.08.08 |
| PyTorch 모델 저장 시 ModuleNotFoundError 오류 해결기: pickle과 버전 호환의 함정 (2) | 2025.08.08 |
