▲

S3 Files와 변화하는 S3의 모습

 (allthingsdistributed.com)
5P by GN⁺ 9시간전 | ★ favorite | 댓글 2개
  • 대규모 데이터 이동의 비효율을 줄이기 위해, 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는 개발자가 데이터로 더 빠르게 실험하고 구축할 수 있는 기반으로 자리함

함께 보면 좋은 글 β

▲
xguru 8시간전  [-]

아 이제는 함께 보면 좋은 글이 관련 공식 글을 잘 연결해주니 편하네요.
이렇게 소개 글과 공식글이 따로 있는 경우 어떻게 해줘야 하나 항상 고민했는데,
함께 보면 좋은 글이 잘 동작해서 기분이 좋습니다.. ㅎㅎ

이제 S3는 파일·테이블·벡터를 모두 포함한 데이터 플랫폼으로 확장하네요.

현대적 클라우드 인프라의 출발점이었던 S3가 20년 만에 다시 정의되는 느낌

답변달기
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • 이건 사실상 S3FS를 쓰되, EFS(AWS의 관리형 NFS 서비스)를 활성 데이터와 작은 랜덤 접근을 위한 캐시 계층으로 사용하는 구조임
    문제는 EFS의 비싼 요금 체계가 그대로 따라온다는 점임
    — 모든 쓰기 작업은 GB당 $0.06로, 쓰기 중심 워크로드에는 치명적일 수 있음
    — 캐시에서 읽는 경우 GB당 $0.03이 부과되며, 128KB 초과의 큰 읽기는 S3 버킷에서 직접 스트리밍되어 무료임
    — 캐시는 GB당 월 $0.30이지만, 주로 128KB 이하의 작은 파일만 지속 저장하므로 비용은 크지 않을 듯함

    • 큰 파일 읽기(>128KB)가 항상 캐시를 거치지 않는다는 게 맞는지 궁금함
      S3의 지연 시간(latency) 이 꽤 나쁜 편이라 걱정됨

  • “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다운 행보임

  • AWS가 예전엔 S3를 파일시스템으로 쓰지 말라고 했던 걸로 아는데, 왜 이제 와서 바뀐 건지 궁금함

    • 이번엔 S3 앞단에 실제 파일시스템(EFS)을 두고 투명 동기화를 수행하는 구조로 보임
      블로그에서도 일관성 문제나 객체 이름 처리 같은 주의점을 언급함
      S3 팬으로서 이런 설계는 꽤 괜찮은 절충안이라 생각함
    • 대형 고객사 아키텍트들이 오래전부터 S3를 파일시스템처럼 써왔음
      AWS가 받은 지원 티켓 압박과 “왜 안 되냐”는 요구가 누적되어 결국 이런 방향으로 간 듯함
      개인적으로는 “본질적으로 다른 걸 포장만 새로 한” 접근이라 마음에 들진 않지만, $$$의 사회적 압력이 작용한 사례 같음
    • 이건 기술력이 낮은 사용자층까지 끌어들이려는 전략으로 보임
      “S3asYourFS.exe” 같은 툴을 쓰는 사람들도 AWS 고객으로 만들 수 있으니까
      다만 AWS의 고객 지원 역량을 생각하면 이게 현명한 결정인지는 의문임
      그래도 매달 요금 내는 사용자가 늘어난다는 유혹은 컸을 것임
    • 어차피 사람들은 S3를 파일시스템처럼 쓸 거라면, 차라리 공식적으로 지원하는 게 낫다고 봄
    • 결국 AWS는 캐시를 앞단에 두고 수익 모델을 만든 것임
      사용자 입장에선 성능이 좋아지고, AWS는 부하가 줄어듦
      돈을 아낄 수도, 아닐 수도 있음

  • 이걸로 SQLite 데이터베이스를 저장하면 어떻게 될지 궁금함
    아마 읽기 전용 복제본 정도만 가능하고, Litestream처럼 백업은 안 될 듯함

    • SQLite의 락(lock) 메커니즘은 NFS에서 안전하지 않아서 작동하지 않음

  • NFS의 락킹 동작도 이미 복잡한데, 여기에 원격 S3 백엔드를 섞으면 더 혼란스러워질 것 같음

  • Werner Vogels는 정말 대단한 사람임
    예전에 DynamoDB를 공부하면서 그의 글을 처음 접했는데, 그때부터 팬이었음

답변달기