AWS EFS 비용 폭탄 맞고 각성한 SRE가 스토리지 비용 70% 깎아낸 ZFS 튜닝 비법 (3.7GB/s 성능 검증)

AWS EFS 비용 폭탄 맞고 각성한 SRE가 스토리지 비용 70% 깎아낸 ZFS 튜닝 비법 (3.7GB/s 성능 검증)

James·2026년 1월 20일·3

AWS EFS 등 관리형 스토리지의 높은 비용 문제를 해결하기 위해 S3와 OpenZFS를 결합, 70% 이상의 비용 절감과 3.7GB/s 성능을 달성한 기술적 비법을 공유합니다.

솔직히 말해봅시다. 클라우드 비용 청구서를 받을 때마다 등골이 서늘하지 않은 엔지니어가 있습니까? 특히 스토리지 비용, 그중에서도 고성능 NAS(Network Attached Storage) 비용은 정말 사악합니다.

제 15년 엔지니어 인생을 걸고 말하건대, 시스템의 가용성 99.999%를 지키는 것만큼이나 중요한 건 여러분의 '통장 잔고 가용성'과 '경영진의 인내심'을 지키는 겁니다. 오늘은 최근 OpenZFS Developer Summit 2025에서 발표된 내용을 바탕으로, AWS EFS 같은 관리형 서비스에 영혼까지 털리지 않고 객체 스토리지(S3)를 고성능 파일서버처럼 쓰는 현실적인 방법을 이야기하려 합니다.

핵심은 FUSE를 갖다 버리고 ZFS를 직접 객체 스토리지에 붙이는 것입니다.

1. 현실 자각: 클라우드 NAS는 왜 이렇게 비싼가

우리가 AWS EFS나 EBS를 쓰는 이유는 단순합니다. POSIX 호환성이 필요하고, 관리가 귀찮으니까요. 하지만 그 편리함의 대가는 가혹합니다. 100TB 데이터를 운영한다고 가정해 봅시다.

  • AWS EFS: 연간 약 $360,000 (약 4억 8천만 원)
  • AWS EBS (gp3): 연간 약 $96,000 (약 1억 3천만 원)

이 돈이면 엔지니어 두 명은 더 채용할 수 있습니다. 그래서 다들 S3(객체 스토리지)를 마운트해서 쓰고 싶어 하죠. 하지만 s3fsgoofys 같은 FUSE 기반 툴을 써본 분들은 아실 겁니다. 그 끔찍한 성능과 툭하면 끊기는 연결 상태 때문에 새벽 3시에 PagerDuty 알람을 받게 된다는 사실을요.

2. 문제의 핵심: FUSE라는 병목

왜 S3를 파일시스템으로 쓰면 느릴까요? 범인은 대부분 FUSE(Filesystem in Userspace) 구조에 있습니다.

데이터가 이동하는 경로를 보세요.

ZFS → VFS → FUSE 커널 모듈 → 유저스페이스 → FUSE → VFS → s3fs → S3

I/O 하나 처리하는데 커널과 유저스페이스를 두 번이나 넘나듭니다(Context Switch). 이건 마치 옆자리 동료에게 말 걸면 될 것을, 결재 서류 만들어서 본부장 승인받고 다시 내려보내는 꼴입니다. 오버헤드가 작렬할 수밖에 없죠.

3. 해결책: objbacker.io와 네이티브 ZFS VDEV

이번 서밋에서 MayaNAS 팀이 들고 나온 솔루션, objbacker.io의 접근법은 아주 직관적입니다. "FUSE를 치워버리자"는 겁니다. ZFS가 운영체제의 블록 디바이스처럼 인식할 수 있는 특수한 캐릭터 디바이스(/dev/zfs_objbacker)를 만들고, 이를 통해 S3 SDK와 직접 통신합니다.

개선된 I/O 경로:

ZFS → /dev/zfs_objbacker → objbacker.io 데몬 → S3 SDK

중간 단계가 싹 사라졌습니다. 이제 ZFS는 S3를 마치 로컬 하드디스크처럼 다룹니다.

4. 핵심 전략: ZFS Special Device 아키텍처

하지만 S3는 본질적으로 느립니다(Latency). 아무리 경로를 최적화해도 NVMe SSD를 이길 순 없습니다. 여기서 ZFS의 계층화(Tiering) 전략이 빛을 발합니다.

모든 데이터가 NVMe 급 속도를 필요로 하진 않습니다.

  • 메타데이터 & 작은 파일(<128KB): 로컬 NVMe SSD에 저장 (빠른 응답 속도 필요)
  • 큰 데이터 블록(1MB+): S3 객체 스토리지에 저장 (높은 처리량 필요)

ZFS의 Special Device 기능을 활용해 메타데이터는 로컬에, 덩어리 큰 데이터는 S3로 보내는 겁니다. 이렇게 하면 사용자는 로컬 디스크의 빠릿빠릿함을 느끼면서, 실제 데이터는 값싼 S3에 저장하는 효과를 누립니다.

5. 검증된 결과: 숫자는 거짓말을 하지 않는다

이 구조로 AWS c5n.9xlarge 인스턴스(36 vCPU, 50Gbps Network)에서 벤치마크를 돌린 결과입니다.

  • 읽기 처리량(Throughput): 3.7 GB/s
  • 쓰기 처리량(Throughput): 2.5 GB/s
  • 비용 절감: 전통적인 블록 스토리지 대비 70% 이상 절감

단순히 s3fs를 썼다면 꿈도 못 꿀 수치입니다. 비결은 병렬 처리데이터 정렬(Alignment)에 있습니다.

  • 1MB Recordsize: ZFS의 블록 크기를 1MB로 설정하여 S3 객체 크기와 1:1로 매핑했습니다. 불필요한 조각 모음이나 캐싱 없이 PUT 요청 한 방으로 끝냅니다.
  • Parallel Buckets: 6개의 S3 버킷을 스트라이핑(Striping)으로 묶어서 네트워크 대역폭을 끝까지 짜냈습니다.

6. 결론: 기술은 돈을 아껴줄 때 가장 빛난다

우리가 새로운 기술을 배우는 이유는 단순히 "멋져서"가 아닙니다. 레거시 시스템의 비효율을 걷어내고, 그로 인해 아낀 비용과 리소스로 우리의 삶을 지키기 위해서입니다.

objbacker.io를 활용한 이 아키텍처는 오픈소스 기술(ZFS)과 클라우드 인프라(S3)를 영리하게 결합한 모범 사례입니다. 무턱대고 비싼 관리형 서비스(EFS)를 쓰거나, 무지성으로 s3fs를 쓰다가 장애를 내지 마십시오.

여러분의 시스템이 S3 위에서 3.7GB/s로 데이터를 뿜어내고, 비용은 1/3로 줄어들 때, 비로소 여러분은 연봉 협상 테이블에서 '개발자'가 아니라 '비즈니스 파트너'로서 대우받게 될 겁니다.

Action Item: 당장 회사의 스토리지 비용 명세서를 확인하세요. 그리고 ZFS on Object Storage 아키텍처 도입을 검토해 보십시오. 단, 테스트 환경에서 충분한 fio 벤치마크를 돌려본 뒤에 말입니다. 운영 서버에서 바로 테스트하다가 날아가면, 그건 제가 책임 못 집니다.

James
James실리콘밸리 15년차 Staff SRE

연봉 3억과 캘리포니아의 햇살, 그리고 공황장애. 화려한 빅테크 간판 뒤에 가려진 '생존의 청구서'를 정산해드립니다. 기술적 탁월함만큼 중요한 건 엔지니어로서의 지속 가능성임을 병상에서 깨달았습니다.

James님의 다른 글

댓글 0

첫 번째 댓글을 남겨보세요!