meatsby.github.io

03. Amazon FSx

Properties1
tagsaws

9 min read

Amazon FSx

AWS 에서 제공하는 fully managed 3rd party high-performance file systems service 다. 아래와 같은 타입의 파일시스템을 완전관리형으로 제공한다.

  • FSx for Windows File Server
  • FSx for Lustre
  • FSx for NetApp ONTAP
  • FSx for OpenZFS

Amazon FSx for Lustre

Lustre 파일시스템

  • Lustre 파일시스템은 1999년 CMU 에서 개발한 오픈소스 병렬 파일시스템으로 지리 정보 처리, 금융 모델링 등 HPC 기반 워크로드에 주로 활용한다.
  • 대규모 확장으로 ms 미만의 지연 시간, 초당 최대 수백GB-수백만GB IOPS 로 데이터를 처리할 수 있다.
  • POSIX 호환으로 기존 Linux 기반 응용 프로그램을 사용한다.

EC2 에서 FSx for Lustre 마운트하기

sudo dnf install -y lustre-client # lustre-client 를 설치하고
sudo mkdir -p /mnt/fsx # 마운팅할 디렉터리를 생성하고
sudo mount -t lustre -o relatime,flock ${file_system_dns_name}@tcp:/${mountname} /mnt/fsx # FSx for Lustre 를 마운팅

Lustre 아키텍처 — MDT 와 OST

Lustre 는 메타데이터와 데이터를 물리적으로 분리하고, 데이터를 여러 서버에 쪼개 저장하는 분산 파일시스템이다.

구성 요소풀네임역할
MDTMetadata Target파일명·디렉터리 구조·권한·inode·layout(데이터가 어느 OST 에 있는지) 저장. 실제 파일 내용은 없음
OSTObject Storage Target실제 파일 데이터(바이트) 저장. 여러 개로 분산
MGTManagement Target클러스터 설정 (보통 노출 안 됨)
  • 서버 단위로는 MDS (Metadata Server) / OSS (Object Storage Server). Target 은 그 서버에 붙은 저장 장치 단위.
  • FSx for Lustre 는 보통 MDT 하나(MDT0000) + OST 여러 개로 구성된다.

접근 흐름 — client 는 데이터를 OST 와 직접 통신한다. MDT 는 “어디 있나” 만 알려주고 빠진다.

1. client: open("/mnt/fsx/bigfile")
              ↓
2. MDT: "이 파일은 OST0,1,2,3 에 stripe_size 1M 로 흩어져 있다" (layout 반환)
              ↓
3. client → OST0,1,2,3 와 동시에 직접 read/write (MDT 안 거침)

→ 데이터 path 가 단일 서버에 묶이지 않는 게 핵심.

Striping — 데이터 분산 방식

파일을 stripe_size 단위 청크로 잘라 여러 OST 에 round-robin 분산한다 (RAID-0 방식, replica 아님).

  • stripe_size = 청크 하나 크기. Lustre 기본 1 MB.
  • stripe_count = 몇 개 OST 에 분산할지.

예시 — stripe_count=4, stripe_size=1MB, 10 MB 파일:

파일:  [0-1M][1-2M][2-3M][3-4M][4-5M][5-6M][6-7M][7-8M][8-9M][9-10M]
          ↓     ↓     ↓     ↓     ↓     ↓     ↓     ↓     ↓     ↓
        OST0  OST1  OST2  OST3  OST0  OST1  OST2  OST3  OST0  OST1

분산 방식별:

  • 큰 파일 = n 분할 striping (stripe_count>1)
  • 작은 파일 = 한 OST 통째 (stripe_count=1)
  • 아주 작은 파일 = DoM (Data on MDT) 으로 MDT 에 데이터까지 직접 저장 (OST 왕복 제거)
  • replica = 기본 아님. 내구성은 하부 스토리지(RAID)·AWS 가 책임

HPC 에 유리한 이유

병렬성 두 축으로 일반 NAS(NFS) 가 못 내는 aggregate 대역폭을 낸다.

  1. 단일 파일의 병렬 대역폭 = 한 client 가 큰 파일 하나 읽어도 여러 OST 에서 동시에 → 단일 OST 대역폭 × OST 수. (1 GB 를 한 서버에서 받는 것보다 100 MB 씩 10 서버에서 동시에 받는 게 빠른 원리)
  2. 다중 client 병렬성 = 수천 compute 노드가 각자 다른 OST 두드림 → 단일 병목 없음
  3. 데이터 path 와 메타데이터 path 분리 = 데이터 전송이 MDT 안 거쳐 둘이 독립 scale
일반 NAS (NFS)Lustre
파일 하나서버 1대가 처리여러 OST 병렬
대역폭 한계단일 서버OST 수만큼 합산
메타데이터·데이터같은 서버분리 (MDT vs OST)
scalescale-upscale-out (OST 추가)
단, 병렬 효과는 client NIC 대역폭·straggler(느린 OST 하나)·stripe 오버헤드에 막힐 수 있다. 작은 파일 다수는 striping 이 오히려 손해다.

df vs lfs df

  • df = 범용 POSIX 도구. Lustre 마운트를 하나의 파일시스템으로 보고 합산 용량만 표시. statfs() 호출.
  • lfs df = Lustre 전용 client 유틸(lfs = Lustre FileSystem). 구성 target(MDT·OST) 마다 따로 조회.
$ lfs df -h
UUID               bytes  Used  Available  Use%  Mounted on
fsx-MDT0000_UUID   ...                            /mnt/fsx[MDT:0]
fsx-OST0000_UUID   ...                            /mnt/fsx[OST:0]
fsx-OST0001_UUID   ...                            /mnt/fsx[OST:1]
...
  • fsx-MDT0000_UUID = 메타데이터 target. fsx-OST0000_UUID 등 = 데이터 target 들.
  • Mounted on 의 /mnt/fsx[OST:0] = 진짜 마운트 포인트 아님. <마운트경로>[타입:인덱스] 라벨. 전부 같은 /mnt/fsx 에 마운트돼 있다.
  • bytes·Used·Available·Use% = 각 target 하나의 용량.

왜 구분이 중요한가:

  • MDT 와 OST 는 따로 찬다. MDT(메타데이터) 고갈 시 OST 공간 남아도 새 파일 생성 불가. 작은 파일 수억 개 = MDT 고갈, 큰 파일 = OST 고갈.
  • OST 불균형 = df 는 합산이라 “공간 있음” 으로 보이지만 특정 OST 가 꽉 차면 그 OST 로 가는 쓰기는 ENOSPC 실패. lfs df 로만 발견 가능.

자주 쓰는 lfs 명령:

lfs df -h                      # target별 용량
lfs df -i                      # inode 기준 (MDT 메타데이터 고갈 확인)
lfs getstripe <파일>           # 이 파일이 어느 OST 에 어떻게 쪼개졌나
lfs setstripe -c 4 <디렉터리>  # 이 디렉터리 새 파일은 OST 4개에 stripe
lfs find <경로> ...            # Lustre 최적화 find (MDT 직접 질의)
lfs quota -u <user> /mnt/fsx   # 사용자별 quota

Throughput tier — 용량에 묶인 성능

FSx for Lustre 의 throughput 은 따로 못 사고 용량에 묶여 있다.

총 throughput (MB/s) = 스토리지 용량 (TiB) × throughput tier (MB/s per TiB)
배포 타입throughput per TiB비고
Scratch (SSD)200 MB/s/TiB (+ burst)임시·복제 X·저렴
Persistent_2 (SSD)125 / 250 / 500 / 1000 중 선택영구·AZ 내 복제
예시 — Persistent_2, 500 MB/s/TiB, 4.8 TiB → 총 2400 MB/s.

용량에 묶이는 이유 = 용량을 키우면 내부 OST 가 늘어나기 때문. 용량 ↑ = OST 수 ↑ = striping 병렬도 ↑ = aggregate throughput 선형 증가. AWS 가 이걸 “MB/s per TiB” 로 추상화해 판다.

성능 튜닝 두 노브:

  1. 용량 ↑ → OST 수 ↑ → 병렬 대역폭 ↑
  2. tier ↑ (125 → 1000) → 같은 용량에서 OST 당 provisioned 대역폭 ↑

Scratch vs Persistent

ScratchPersistent_2
용도임시 (단기 처리·중간 결과)장기·중요 데이터
복제없음 — 서버 장애 시 데이터 손실AZ 내 복제
throughput200 MB/s/TiB + burst125~1000 선택 (provisioned 안정)
비용저렴비쌈
전형HPC 중간 계산·CI artifactML 학습 데이터셋·반복 접근
  • Scratch 가 괜찮은 경우 = 원본이 04. Amazon S3 에 있고 FSx 는 빠른 작업 공간일 때. 날아가도 S3 에서 다시 hydrate.
  • Scratch 의 burst = baseline 200 MB/s/TiB 위로 일시적 spike 흡수 (credit 모델).

References

Graph View