[TIL] AWS EC2에서 학습하기

1. EC2 고속 저장소의 비밀: /dev/mapper와 LVM

AI 학습 인스턴스에서 보이는 /dev/mapper 경로는 고성능을 위한 스토리지 구성의 핵심

1.1. /dev/mapper의 정의와 역할

• 정의: /dev/mapper는 Linux Device Mapper (장치 매퍼) 시스템에 의해 생성된 가상 장치 파일
• 비유: 여러 개의 작은 창고'(디스크)를 하나로 합쳐서 쓰는 '가상의 대형 창고 관리 시스템'
• 역할: 하위의 물리적 장치(/dev/nvme0n1 등)와 상위의 파일 시스템 사이에 위치하며, 물리적 디스크를 논리적으로 조합하고 관리할 수 있게 해주는 Linux 커널 프레임워크.

1.2. vg.01-lv_ephemeral의 구성 원리

/dev/mapper/vg.01-lv_ephemeral은 Device Mapper의 주요 기술인 LVM (Logical Volume Manager)을 사용하여 구성된 논리 볼륨(Logical Volume).

• LVM 역할: 여러 개의 물리적 디스크를 하나의 볼륨 그룹(vg.01)으로 묶고, 그 안에서 유연하게 크기를 조절 가능한 논리 볼륨(lv_ephemeral)을 생성.
• EC2 활용: AWS Deep Learning AMI(DLAMI) 계열 인스턴스는 여러 개의 NVMe SSD (인스턴스 스토어)를 LVM으로 묶어 단일하고 거대한 고성능 작업 공간(예: 3.5T)을 /opt/dlami/nvme 등에 제공합니다.

💡 휘발성 주의 이 볼륨은 인스턴스 스토어를 기반으로 하기에 이름에 ephemeral이 포함되어 있으며, EC2 인스턴스를 중지(Stop)하면 이 공간에 저장된 모든 데이터는 영구적으로 삭제됨

1.3. LVM의 아키텍처 이점과 오버헤드

1. 동적 용량 관리 및 유연성 (Flexibility)
   • 논리 볼륨(LV)의 크기를 시스템을 중단하지 않고 (온라인 상태로) 자유롭게 확장 또는 축소할 수 있음.
   • AI 프로젝트의 데이터셋 크기가 예상치 못하게 증가할 경우, 인스턴스에 새 디스크(PV)를 추가하고 볼륨 그룹(VG)에 편입시킨 후, /dev/mapper LV의 크기를 즉시 확장하여 다운타임을 최소화함.
2. 통합된 스토리지 풀 관리 (Consolidation)
   • 크기가 다르거나 종류가 다른 여러 물리적 볼륨(PV)을 하나의 볼륨 그룹(VG)으로 통합하여, 사용자나 애플리케이션에게 단일하고 거대한 연속적인 저장 공간으로 제공
   • 여러 개의 개별 NVMe 인스턴스 스토어 디스크를 하나로 묶어 3.5TB와 같은 대용량 고속 캐시 공간으로 만들어, 데이터 로더가 단일 경로로 대규모 데이터셋을 접근하게 함

1.4. 단일 디스크 사용 대비 잠재적 오버헤드

LVM은 관리 계층을 추가하므로, 다음과 같은 미세한 오버헤드가 발생할 수 있습니다.

1. I/O 경로의 복잡성 증가 (Mapping Lookup)
   • LVM은 논리적 주소(LV)를 물리적 주소(PV 내의 오프셋)로 변환하는 매핑 테이블(Mapping Table) 조회가 필요함.
   • 이 조회 과정에서 아주 미세한 수준의 CPU 및 메모리 오버헤드가 발생할 수 있음
2. 초기 설정 및 관리 복잡도
   • 단일 디스크와 달리, LVM은 VG 생성, LV 생성, 파일 시스템 포맷 및 마운트 등 초기 설정 단계가 복잡하며, 문제 발생 시 디버깅이 더 어려움(운영 오버헤드)

2. YOLO 학습을 위한 S3 데이터 파이프라인 최적화

S3에 있는 학습 데이터를 효율적으로 사용하려면, S3를 직접 마운트하는 것을 피하고 '복사-학습-백업' 전략을 사용해야 함

2.1. S3 직접 마운트를 피해야 하는 이유

S3는 객체 스토리지(Object Storage)로, Linux 파일 시스템(POSIX)과 호환성이 낮고, AI 학습에 필요한 무작위 접근(Random I/O) 성능이 매우 떨어짐. 특히, 딥러닝 데이터 로더는 수많은 작은 파일(이미지/어노테이션)을 랜덤하게 읽고, 메타데이터(파일 목록, 크기 등)에 빈번하게 접근함.

• 성능 저하: S3는 객체당 네트워크 지연 시간(Latency)이 높아, 수백만 개의 작은 파일을 반복적으로 GET 요청할 때 발생하는 총 지연 시간이 NVMe SSD의 로컬 접근 속도와 비교할 수 없을 정도로 길어저 심각한 병목 현상을 초래함.
• 파일 시스템 불일치: 파일 잠금 등 일부 기능 부재로 학습 프레임워크에서 예상치 못한 오류를 유발할 수 있음.
  • 원자적 이름 변경 (Atomic Rename) :  S3는 Rename 명령이 없으며, 파일을 복사하고 원본을 삭제하는 **두 단계 작업(Copy & Delete)**으로 에뮬레이션됨. 이는 학습 중 임시 파일 처리나 체크포인트 저장 시 지연 시간(Latency)을 크게 증가시킴
  • 파일 잠금 (File Locking) : S3는 기본적으로 파일 잠금 메커니즘을 제공하지 않음. s3fs 같은 도구는 임시 파일 등으로 이를 에뮬레이션하려 하지만, 불안정하거나 성능이 크게 저하됨. 딥러닝에서 동시 접근 시 데이터 충돌 위험이 존재

2.2. 권장되는 학습 데이터 워크플로우

1. 인스턴스 시작 시 (복사):
   • aws s3 sync 명령어를 사용하여 S3의 학습 데이터를 고속 볼륨(/opt/dlami/nvme 등)으로 복사합니다.
   • 명령어 예시: aws s3 sync s3://[S3_버킷]/[데이터_경로]/ /opt/dlami/nvme/
2. 학습 진행 시 (활용):
   • YOLO 모델은 /opt/dlami/nvme에 복사된 데이터를 읽으며 초고속으로 학습
3. 학습 완료/중간 (백업):
   • 휘발성 위험에 대비하여, 학습 결과물(모델 체크포인트)은 다시 S3로 업로드하거나 영구 EBS에 저장하도록 설정해야 함