S3 Files와 변화하는 S3의 모습

• 대규모 데이터 이동의 비효율을 줄이기 위해, 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는 개발자가 데이터로 더 빠르게 실험하고 구축할 수 있는 기반으로 자리함