S3 Files와 변화하는 S3의 모습
(allthingsdistributed.com)- 대규모 데이터 이동의 비효율을 줄이기 위해, S3 데이터를 파일 시스템처럼 직접 접근할 수 있게 하는 S3 Files가 도입됨
- 이 기능은 Amazon EFS와 S3를 통합하여 EC2, 컨테이너, Lambda 등에서 S3 버킷을 NFS로 마운트해 읽기·쓰기 가능하게 함
- 내부적으로 stage와 commit 구조를 사용해 변경을 주기적으로 S3에 반영하며, 파일과 객체 간 양방향 동기화를 지원
- S3 Files는 S3 Tables, S3 Vectors와 함께 S3를 통합 데이터 플랫폼으로 확장시키는 핵심 구성요소로 작동
- S3는 이제 단순 저장소를 넘어, 데이터 중심의 통합 작업 공간으로 진화하며 개발자가 데이터를 직접 활용할 수 있는 기반을 제공함
S3의 변화와 S3 Files의 설계
-
데이터 이동의 어려움과 S3 Files의 출발점
- 대규모 데이터를 옮기는 과정은 과학 연구부터 머신러닝까지 다양한 산업에서 지속적인 비효율의 원인으로 존재
- UBC의 유전체 연구 사례에서는 연구자들이 S3와 로컬 파일 시스템 간 복사 작업에 많은 시간을 소비
- 이러한 데이터 마찰(data friction) 은 도구들이 서로 다른 방식으로 데이터를 접근하기 때문에 발생
- S3 Files는 이러한 마찰을 줄이기 위해 S3 데이터를 직접 파일 시스템처럼 접근할 수 있도록 설계됨
-
에이전트 기반 개발과 데이터의 중요성
- 에이전트형 도구(agentic tooling) 의 발전으로 애플리케이션 개발 속도와 다양성이 급격히 증가
- 코드 작성의 장벽이 낮아지면서, 도메인 전문가들이 직접 애플리케이션을 구축할 수 있는 환경이 형성
- 애플리케이션의 수명은 짧아지고, 데이터가 장기적으로 남는 핵심 자산으로 부상
- 스토리지는 단순 저장소가 아니라, 데이터를 애플리케이션과 분리해 지속적으로 활용할 수 있게 하는 추상화 계층이 되어야 함
S3의 새로운 데이터 프리미티브
-
S3 Tables
- S3는 구조화된 데이터를 다루기 위해 Apache Iceberg 기반의 S3 Tables를 도입
- Iceberg의 기능을 유지하면서 데이터 무결성 보호, 자동 압축(compaction), 교차 리전 복제 등을 제공
- 현재 200만 개 이상의 테이블이 S3 Tables에 저장되어 있으며, 다양한 애플리케이션이 이를 기반으로 구축됨
-
S3 Vectors
- AI 발전으로 벡터 인덱스에 대한 수요가 증가
- 기존 벡터 데이터베이스는 메모리나 SSD에 인덱스를 저장하지만, 이는 비용과 확장성의 한계를 가짐
- S3 Vectors는 S3 객체와 유사한 비용·성능·내구성 프로파일을 가진 완전 탄력적 벡터 인덱스 제공
- 수백 개에서 수십억 개의 레코드까지 확장 가능하며, 유사도 검색(scalar similarity search) 을 위한 API 엔드포인트 제공
S3 Files의 등장
-
개요
- S3 Files는 Amazon EFS를 S3에 통합하여, S3 데이터를 네트워크 파일 시스템(NFS)처럼 직접 접근 가능하게 함
- EC2, 컨테이너, Lambda 등에서 S3 버킷 또는 프리픽스를 마운트하여 파일처럼 읽고 쓸 수 있음
- 변경 사항은 자동으로 S3에 반영되어, 파일과 객체 간의 양방향 동기화 지원
-
설계의 난제
- 파일 시스템과 객체 스토리지는 근본적으로 다른 데이터 모델을 가짐
- 초기에는 EFS와 S3를 단순히 결합하려 했으나, “불쾌한 절충(unpalatable compromises)” 만 남음
- 파일은 세밀한 변경과 동시 접근을 지원하지만, 객체는 불변성과 전체 단위 업데이트를 전제로 함
- S3의 이벤트 알림 시스템은 하루 3천억 건 이상의 알림을 처리하며, 객체 단위의 변경을 기반으로 작동
Stage and Commit 설계 원리
-
경계를 기능으로 전환
- 파일과 객체의 차이를 숨기지 않고, 명시적 경계로 설계
- 변경은 EFS에서 stage(임시 저장) 되고, 일정 주기마다 commit(커밋) 되어 S3에 반영
- 이 접근은 Git의 버전 관리 개념에서 영감을 받아, 시간·정책 기반의 데이터 전송 제어를 가능하게 함
-
일관성과 원자성
- 파일 시스템의 원자적(rename, move) 연산과 S3의 전체 객체 단위 업데이트를 병행 지원
- 두 계층을 분리함으로써 각 시스템의 일관성 모델을 유지하면서 단일 데이터 뷰 제공
-
권한 관리
- S3의 IAM 정책과 파일 시스템의 inode 기반 권한은 구조적으로 다름
- S3 Files는 마운트 단위 권한 부여를 통해 두 체계를 분리
- S3 IAM 정책은 최종 백스톱(backstop) 으로 유지되어, 데이터 경계 변경 시 접근 제어 가능
-
네임스페이스 불일치
- S3는 디렉터리 개념이 없고, 경로 구분자(delimiter) 도 임의 지정 가능
- 파일 시스템과의 불일치를 해결하기 위해 양쪽의 네이밍 규칙을 그대로 유지
- 호환 불가능한 객체는 이동하지 않고, 이벤트를 발생시켜 개발자가 처리할 수 있도록 설계
-
성능과 지연(latency)
- 파일 시스템은 메타데이터 중심 접근, S3는 대규모 병렬 접근에 최적화
- 대부분의 워크로드는 파일과 객체를 동시에 접근하지 않기 때문에, 두 모델의 통합보다는 동기화 계층 유지가 현실적
- 파일 뷰는 NFS 일관성, 객체 뷰는 S3 강한 일관성을 유지하며, 동기화 계층이 연결 역할 수행
S3 Files의 동작 방식
-
기본 구조
- S3 Files는 EFS를 백엔드로 사용하여 파일 시스템 경험 제공
- 디렉터리 접근 시 S3 메타데이터를 가져와 동기화된 뷰 생성, 128KB 이하 파일은 즉시 데이터도 로드
- 대용량 파일은 지연 로딩(lazy hydration) 으로 필요 시 데이터 가져오기
- 변경 사항은 약 60초마다 S3에 단일 PUT으로 커밋, 양방향 동기화 수행
-
충돌 및 관리
- 양쪽에서 동시에 수정 시 S3가 진실의 원천(source of truth) 으로 간주
- 충돌된 파일은 lost+found 디렉터리로 이동하고, CloudWatch 메트릭으로 기록
- 30일간 접근되지 않은 파일은 파일 시스템 뷰에서 제거되어 비용 최적화
-
성능 최적화
-
read bypass기능을 통해 대용량 순차 읽기 시병렬 GET 요청으로 직접 S3에서 읽기
- 클라이언트당 3GB/s 처리량 달성, 다중 클라이언트에서는 테라비트급 확장성 확보
-
-
한계와 개선 예정
- S3는 네이티브 rename 연산이 없어, 디렉터리 이름 변경 시 전체 복사·삭제 필요
- 5천만 개 이상의 객체를 포함한 마운트는 경고 표시
- 명시적 커밋 제어는 초기 버전에 포함되지 않음
- 일부 객체 키는 POSIX 파일명으로 표현 불가, 파일 뷰에서 제외됨
데이터 다양성과 S3의 진화
-
데이터 접근 방식의 공존
- UBC 연구 사례처럼, 개발자들은 데이터 이동·캐싱·이름 관리에 많은 시간을 소비
- S3 팀은 Tables, Vectors, Files를 통해 다양한 데이터 접근 방식을 통합 지원
- 파일과 객체의 차이를 없애려 하기보다, 각자의 특성을 인정하고 경계를 기능화
-
S3의 확장된 역할
- S3는 단순 객체 저장소에서 다양한 데이터 형태를 지원하는 통합 스토리지 플랫폼으로 진화
- Tables, Vectors, Files를 통해 데이터를 작업 방식에 맞게 직접 활용 가능
- 목표는 스토리지가 작업의 방해물이 아닌, 투명한 기반 인프라가 되는 것
- 향후 stage/commit 제어, 파이프라인 통합 등 기능 확장을 지속 예정
-
결론
- S3 Files는 파일과 객체의 명시적 경계를 유지하면서도 양쪽의 장점을 결합
- 20년 전 객체 저장소로 시작한 S3는 이제 데이터 중심의 통합 작업 공간으로 발전
- “이제, 만들어 보라(Go build!)”는 메시지처럼, S3는 개발자가 데이터로 더 빠르게 실험하고 구축할 수 있는 기반으로 자리함
댓글과 토론
아 이제는 함께 보면 좋은 글이 관련 공식 글을 잘 연결해주니 편하네요.
이렇게 소개 글과 공식글이 따로 있는 경우 어떻게 해줘야 하나 항상 고민했는데,
함께 보면 좋은 글이 잘 동작해서 기분이 좋습니다.. ㅎㅎ
이제 S3는 파일·테이블·벡터를 모두 포함한 데이터 플랫폼으로 확장하네요.
현대적 클라우드 인프라의 출발점이었던 S3가 20년 만에 다시 정의되는 느낌
S3와 transparent하게 파일 구조가 공유되지는 않지만, ZeroFS라고 하는 S3를 데이터베이스 삼아 POSIX-compliant한 파일시스템을 굴리는 오픈 소스도 존재합니다. S3 위에서 PostgreSQL을 굴리는 데모로 꽤 인기있었죠.
이전 S3 엔지니어가 창업한 Archil에서 자사 제품과 비교한 글도 있어서 같이 보면 재미있습니다 ㅎㅎ
Hacker News 의견들
-
이건 사실상 S3FS를 쓰되, EFS(AWS의 관리형 NFS 서비스)를 활성 데이터와 작은 랜덤 접근을 위한 캐시 계층으로 사용하는 구조임
문제는 EFS의 비싼 요금 체계가 그대로 따라온다는 점임
— 모든 쓰기 작업은 GB당 $0.06로, 쓰기 중심 워크로드에는 치명적일 수 있음
— 캐시에서 읽는 경우 GB당 $0.03이 부과되며, 128KB 초과의 큰 읽기는 S3 버킷에서 직접 스트리밍되어 무료임
— 캐시는 GB당 월 $0.30이지만, 주로 128KB 이하의 작은 파일만 지속 저장하므로 비용은 크지 않을 듯함- 큰 파일 읽기(>128KB)가 항상 캐시를 거치지 않는다는 게 맞는지 궁금함
S3의 지연 시간(latency) 이 꽤 나쁜 편이라 걱정됨
- 큰 파일 읽기(>128KB)가 항상 캐시를 거치지 않는다는 게 맞는지 궁금함
-
“NFS provides the semantics your applications expect”라는 문구는 지금까지 본 것 중 가장 웃겼음
- 애플리케이션이 네트워크 끊김 하나로 시스템 콜이 무한 대기 상태에 빠지고, 파일시스템이 언마운트 불가 상태가 되는 걸 기대하지는 않음
-
Hugging Face Buckets도 최근에 버킷을 파일시스템처럼 마운트할 수 있는 기능을 추가했음
hf-mount 변경 로그 -
동기화 관련 부분이 궁금했음
AWS 문서에 따르면,
/mnt/s3files/report.csv를 수정한 뒤 S3 버킷에 다른 버전이 업로드되면, 충돌 시 내 버전은.s3files-lost+found-file-system-id디렉터리로 이동되고 버킷 버전으로 교체된다고 함
즉, 충돌 시 자동 복구 디렉터리가 존재함 -
FiberFS가 거의 첫 공식 릴리스 단계에 있음
내장 캐시, CDN 호환, JSON 메타데이터, 동시성 안전성을 갖추고 모든 S3 호환 스토리지를 대상으로 함- Amazon의 자체 FUSE 구현체와 비교하면 어떤지 궁금함. 지금 세 번째 버전까지 나왔음
-
AWS가 로컬 NVMe 스토리지와의 관리형 브리징을 제공했으면 좋겠음
NVMe는 EBS보다 훨씬 빠르고, EBS는 EFS보다 빠름
NVMe 위에 캐시 계층을 올리면 속도가 꽤 나올 듯하지만, 완전 통합형 옵션이 더 이상적임- EFS가 단순 NFS 마운트라면, NVMe 볼륨을 붙이고 cachefilesd를 설정해서 직접 구현할 수도 있을 듯함
예를 들어
이런 식으로 하면 바로 동작할지도 모름mkfs.ext4 /dev/nvme0n1 && \ mount /dev/nvme0n1 /var/cache/fscache && \ mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files
사실상 세 줄짜리 명령어인데, 이걸 관리형 서비스로 내놓는 게 AWS다운 행보임
- EFS가 단순 NFS 마운트라면, NVMe 볼륨을 붙이고 cachefilesd를 설정해서 직접 구현할 수도 있을 듯함
-
AWS가 예전엔 S3를 파일시스템으로 쓰지 말라고 했던 걸로 아는데, 왜 이제 와서 바뀐 건지 궁금함
- 이번엔 S3 앞단에 실제 파일시스템(EFS)을 두고 투명 동기화를 수행하는 구조로 보임
블로그에서도 일관성 문제나 객체 이름 처리 같은 주의점을 언급함
S3 팬으로서 이런 설계는 꽤 괜찮은 절충안이라 생각함 - 대형 고객사 아키텍트들이 오래전부터 S3를 파일시스템처럼 써왔음
AWS가 받은 지원 티켓 압박과 “왜 안 되냐”는 요구가 누적되어 결국 이런 방향으로 간 듯함
개인적으로는 “본질적으로 다른 걸 포장만 새로 한” 접근이라 마음에 들진 않지만, $$$의 사회적 압력이 작용한 사례 같음 - 이건 기술력이 낮은 사용자층까지 끌어들이려는 전략으로 보임
“S3asYourFS.exe” 같은 툴을 쓰는 사람들도 AWS 고객으로 만들 수 있으니까
다만 AWS의 고객 지원 역량을 생각하면 이게 현명한 결정인지는 의문임
그래도 매달 요금 내는 사용자가 늘어난다는 유혹은 컸을 것임 - 어차피 사람들은 S3를 파일시스템처럼 쓸 거라면, 차라리 공식적으로 지원하는 게 낫다고 봄
- 결국 AWS는 캐시를 앞단에 두고 수익 모델을 만든 것임
사용자 입장에선 성능이 좋아지고, AWS는 부하가 줄어듦
돈을 아낄 수도, 아닐 수도 있음
- 이번엔 S3 앞단에 실제 파일시스템(EFS)을 두고 투명 동기화를 수행하는 구조로 보임
-
이걸로 SQLite 데이터베이스를 저장하면 어떻게 될지 궁금함
아마 읽기 전용 복제본 정도만 가능하고, Litestream처럼 백업은 안 될 듯함- SQLite의 락(lock) 메커니즘은 NFS에서 안전하지 않아서 작동하지 않음
-
NFS의 락킹 동작도 이미 복잡한데, 여기에 원격 S3 백엔드를 섞으면 더 혼란스러워질 것 같음
-
Werner Vogels는 정말 대단한 사람임
예전에 DynamoDB를 공부하면서 그의 글을 처음 접했는데, 그때부터 팬이었음