AWS는 데이터를 이동하지 않고도 컴퓨팅 노드에서 S3 버킷을 고성능 공유 파일 시스템 (shared file system)으로 마운트할 수 있는 Amazon S3 Files를 발표했습니다.

S3를 파일 시스템처럼 사용할 수 있게 하려는 시도가 업계에서 처음은 아닙니다. s3fs의 초기 시절부터 AWS가 나중에 출시한 Mountpoint for Amazon S3, 그리고 이제의 S3 Files에 이르기까지, "S3를 파일 시스템처럼 사용하는" 과정은 수년에 걸쳐 진행되어 왔습니다. 핵심적인 차이점은 이전 솔루션들이 주로 액세스 계층 (access layer)에서 작동했던 반면, S3 Files는 마침내 공유 액세스 (shared access), 완전한 파일 시스템 시맨틱 (file system semantics), 그리고 관리형 고성능 계층 (managed high-performance layer)을 네이티브 서비스로 통합했다는 점입니다.

이로 인해 S3 Files는 그 자체로 분석할 가치가 있는 새로운 옵션이 되었습니다. 기존 S3 데이터에 대해 파일 스타일의 액세스가 필요한 워크로드(workloads)의 경우, 네이티브하고 가벼운 솔루션을 제공합니다. 하지만 AI 모델 학습 (AI model training)이나 빅데이터 분석 (big data analytics)과 같은 더 복잡한 시나리오에서는, 그 기반 구현과 런타임 동작 (runtime behavior)에 근거하여 실제 성능을 여전히 평가할 필요가 있습니다.

이 글에서는 S3 Files의 구현, 성능 경계, 그리고 JuiceFS와 어떻게 다른지 분석하겠습니다.

S3 Files: EFS를 고성능 계층으로 사용하는 S3 네이티브 파일 시스템

S3 Files는 저지연 (low-latency) 데이터와 메타데이터를 처리하기 위해 Amazon Elastic File System (EFS)를 관리형 고성능 스토리지 계층으로 사용합니다. 그 위에 일관성 (consistency), 파일 잠금 (file locking), POSIX 권한 (permissions)을 포함하여 S3를 위한 완전한 파일 시스템 시맨틱 (file system semantics)을 제공합니다.

이렇게 생각하면 쉽습니다: AWS는 객체 스토리지 (object storage) 위에 EFS 기반의 파일 시스템 액세스 계층을 추가합니다. 이를 통해 이전에는 객체 API를 통해서만 접근할 수 있었던 데이터를 컴퓨팅 노드 (compute nodes)에서 디렉토리, 파일, 마운트 포인트 (mount points)로 직접 사용할 수 있게 합니다. 파일 시스템과 S3 사이의 변경 사항은 서비스에 의해 백그라운드에서 자동으로 동기화됩니다.

이러한 아키텍처를 통해 S3 Files는 전체 데이터셋을 마이그레이션하지 않습니다. 대신, 데이터의 "신뢰할 수 있는 원본 (source of truth)"은 S3에 그대로 둔 채, 현재 작업 세트 (working set)의 일부만을 필요에 따라 고성능 계층에 배치합니다.

S3 Files의 작동 방식: 마운트, 임포트 및 동기화

S3 Files에서 마운트 (mounting)는 시작일 뿐입니다. 정말 중요한 것은 마운트 이후의 데이터 경로입니다. 즉, 범위 (scope)가 어떻게 결정되는지, 첫 액세스 시 무엇이 임포트 (import)되는지, 어떤 요청이 고성능 계층으로 가는지, 그리고 쓰기 작업이 어떻게 S3로 다시 동기화되는지가 중요합니다. 이러한 메커니즘은 나중에 논의할 성능 경계와 비용 구조를 직접적으로 결정합니다.

아래 그림은 S3 Files 마운트 아키텍처 (S3 Files mount architecture)를 보여줍니다:

기존 S3 버킷을 마운트하는 EC2 인스턴스를 예로 들면, 진짜 질문은 마운트 명령 자체에 대한 것이 아니라 마운트 후에 어떤 일이 일어나는가에 대한 것입니다. 즉, 데이터가 어떻게 임포트되고, 액세스되며, 동기화되는지에 대한 것입니다. 다음은 주요 기술적 세부 사항입니다.

범위 (Scope): 버킷 전체를 임포트할 것인가, 특정 프리픽스 (prefix)를 임포트할 것인가

S3에서는 프리픽스 (prefixes)를 사용하여 파일을 구성합니다. 이를 버킷 내의 "하위 디렉토리" 또는 "하위 버킷"과 유사한 것으로 생각할 수 있지만, 실제 디렉토리는 아닙니다. S3 Files는 전체 S3 버킷(예: s3://my-bucket/)을 마운트하거나, 범위를 특정 프리픽스(예: s3://my-bucket/data/ml/만)로 제한할 수 있습니다. 이는 수백만 개 또는 수억 개의 객체를 포함하는 거대한 S3 버킷의 경우 특히 중요한데, 범위가 넓을수록 더 많은 메타데이터 동기화 오버헤드(metadata sync overhead)와 잠재적인 운영 복잡성이 추가되기 때문입니다.

컴퓨팅 노드에서 S3 Files를 사용할 때, AWS는 커스텀 마운트 클라이언트인 amazon-efs-utils를 제공합니다. 마운트할 때는 버킷 이름이 아니라 AWS가 S3 Files 인스턴스에 할당한 파일 시스템 ID를 사용합니다.

아래와 같이 로컬 마운트 디렉토리를 생성하고 전용 s3files 파일 시스템 유형을 사용하여 마운트할 수 있습니다:

sudo yum -y install amazon-efs-utils
sudo mkdir /mnt/s3files
sudo mount -t s3files file-system-id:/ /mnt/s3files

마운트할 때 마운트 경로에 하위 디렉토리(또는 실제로는 프리픽스)를 지정할 수 있습니다(예: file-system-id:/data/ml/). 그러나 이는 로컬 마운트 지점에만 영향을 미칩니다. 근본적인 메타데이터 동기화는 여전히 버킷 전체에 적용되며, 다른 마운트 지점이 의도치 않게 다른 하위 디렉토리에 접근할 수 있기 때문입니다. 실제 환경에서는 전체 버킷을 사용한 뒤 나중에 액세스를 제한하려고 시도하기보다, S3 Files 인스턴스를 생성할 때 범위를 특정 프리픽스로 제한하는 것이 더 나은 접근 방식인 경우가 매우 많습니다.

첫 번째 액세스: 임포트 트리거 및 크기 임계값

S3 Files는 마운트 직후에 전체 데이터셋을 고성능 레이어 (high-performance layer)로 즉시 이동시키지 않습니다. 데이터 임포트 (Data import)는 액세스 이벤트 (access events)에 의해 트리거됩니다. 기본 모드는 trigger=ON_DIRECTORY_FIRST_ACCESS입니다. 즉, 디렉토리에 처음 액세스할 때 시스템은 해당 디렉토리 하위 파일들의 메타데이터 (metadata)를 임포트하고, 기준을 충족하는 작은 파일들의 데이터를 비동기적으로 EFS 고성능 레이어로 이동시킵니다.

만약 trigger=ON_FILE_ACCESS로 설정하면, 첫 번째 디렉토리 순회 (directory traversal) 시에는 메타데이터만 임포트됩니다. 데이터는 파일이 실제로 처음 읽힐 때에만 고성능 레이어로 들어옵니다. 이는 공간과 임포트 비용을 절약할 수 있지만, 첫 번째 읽기 시의 지연 시간 (latency)은 더 높아집니다.

여기서 가장 중요한 제어 파라미터 (control parameter)는 바이트 (bytes) 단위 값을 받는 sizeLessThan입니다. 기본적으로 임포트 과정에서 128 KiB보다 작은 파일(sizeLessThan=131072)만 고성능 레이어로 이동됩니다. 더 큰 파일들은 메타데이터만 임포트되며, 실제 콘텐츠는 여전히 주로 S3에서 가져옵니다. 다시 말해, S3 Files는 모든 데이터를 고성능 레이어로 워밍업 (warming up) 하는 것이 아니라, 주로 작은 파일과 낮은 지연 시간 액세스에 최적화되어 있습니다. 주로 10 MB 수준의 이미지나 비디오 파일로 구성된 AI 학습 데이터셋의 경우, 이는 매우 중요합니다. 디렉토리 순회를 수행하더라도 기본 설정 하에서는 이러한 큰 파일들이 실제로 고성능 레이어에 들어가지 않을 수 있기 때문입니다.

동기화 간격 및 충돌 해결 (Sync intervals and conflict resolution)

S3 Files는 백그라운드에서 파일 시스템과 S3 사이의 양방향 동기화 (bidirectional sync)를 자동으로 유지합니다. S3의 데이터가 변경되면 파일 시스템 뷰 (view)도 그에 따라 업데이트됩니다. 컴퓨팅 노드 (compute nodes)에서의 쓰기 작업은 먼저 EFS 고성능 레이어에 기록된 후, 비동기적으로 S3에 배치 동기화 (batch-synced) 됩니다. 기본적으로 시스템은 다시 쓰기 전 일정 기간 동안 수정 사항을 집계합니다.

충돌 해결 원칙은 명확합니다: S3가 항상 신뢰할 수 있는 원천 (source of truth)입니다. 만약 파일 시스템의 수정 사항이 아직 S3로 동기화되지 않은 상태에서, S3에 있는 해당 객체가 다른 애플리케이션에 의해 업데이트되었다면, 시스템은 S3의 최신 버전을 사용하고 충돌이 발생한 파일은 .s3files-lost+found-* 디렉토리로 이동시킵니다.

S3 Files의 성능 경계 및 비용 구조

이전 섹션에서는 S3 Files가 어떻게 작동하는지 설명했습니다. 이번 섹션에서는 그로 인해 발생하는 성능 경계와 비용 구조에 대해 논의합니다. 고성능 레이어 점유율 (high-performance layer occupancy), 대용량 파일 읽기 경로 (large-file read path), 쓰기 흐름 (write flow), 그리고 부분 업데이트 및 디렉토리 작업의 증폭 효과 (amplification effects)가 평가해야 할 가장 중요한 네 가지 측면입니다.

EFS 고성능 레이어의 점유, 제거 및 비용

S3 Files는 용량 기반의 LRU (Least Recently Used) 제거 방식을 사용하지 않습니다. 대신 액세스 시간 기반의 수명 주기 관리 (lifecycle management)를 사용합니다. 기본적으로 S3로 동기화된 후 30일 동안 읽히지 않은 데이터는 EFS 고성능 레이어에서 제거됩니다. 이 기간은 daysAfterLastAccess (1일에서 365일 사이로 설정 가능)에 의해 제어됩니다.

이는 비용이 얼마나 많은 데이터가 EFS에 머물러야 하는지, 그리고 얼마나 오래 머무는지에 따라 달라짐을 의미합니다. 작업 세트 (working set)가 크고 오랫동안 활성 상태를 유지한다면, 비용은 그에 따라 상승할 것입니다.

대용량 파일 직접 읽기 및 임의 읽기 (random reads): 본질적으로 클라이언트 패스스루 (client passthrough)

S3 Files는 모든 대용량 파일 읽기를 EFS 고성능 레이어를 통해 라우팅하지 않습니다. 기본값인 sizeLessThan 128 KiB를 기준으로, 임포트(import) 중에 해당 임계값 미만의 파일 데이터만 고성능 레이어로 이동됩니다. 이미 S3로 동기화된 파일의 경우, 128 KiB 이상의 읽기 작업은 S3에서 직접 스트리밍됩니다.

다시 말해, S3 Files는 대용량 파일 읽기를 고성능 레이어에 유지하는 것이 아니라, 소형 파일 액세스와 낮은 지연 시간 (low latency)을 최적화하는 데 집중합니다.

이 직접 읽기 (direct-read) 경로를 사용하려면 컴퓨팅 리소스 자체가 소스 버킷을 읽을 수 있는 권한을 가지고 있어야 합니다. AWS 문서는 역할 (roles)에 s3:GetObject 및 s3:GetObjectVersion 권한이 반드시 필요하다고 명시하고 있습니다. 그렇지 않으면 클라이언트가 S3에서 직접 읽을 수 없습니다.

순차적 쓰기 (sequential writes) 비용: 대규모 쓰기는 추가적인 흐름 비용을 발생시킵니다

S3 Files의 쓰기 경로는 S3로 직접 전달되지 않습니다. 모든 쓰기 작업은 먼저 EFS 고성능 레이어 (high-performance layer)로 이동한 다음, 비동기적으로 S3에 다시 동기화 (sync)됩니다.

이는 워크로드가 지속적으로 대량의 결과 데이터를 생성하는 경우 — 예를 들어, 수백 테라바이트의 학습 출력물이나 분석 결과를 순차적으로 쓰는 경우 — 해당 데이터가 S3 Files를 통해 흐를 때 두 가지 추가 비용이 발생함을 의미합니다:

• 데이터 흐름 비용 (Data flow cost): 쓰기 작업이 고성능 레이어로 들어간 다음 나중에 S3로 동기화됩니다. S3에 직접 쓰는 것과 비교했을 때, 이 경로는 추가적인 중간 흐름 오버헤드 (intermediate flow overhead)가 발생합니다.
• 단기 체류 비용 (Short-term residency cost): 데이터가 동기화된 후에도 고성능 레이어에서 즉시 제거 (evict)되지 않습니다. 제거 조건이 충족될 때까지 머무르게 됩니다. 따라서 대규모 쓰기로 인한 임시 데이터가 한동안 EFS 용량을 차지할 수 있습니다.

현재 AWS US East (N. Virginia) 지역 가격을 예로 들면: EFS에 쓰는 비용은 GB당 약 $0.06이며, 이를 S3로 동기화하기 위해 다시 읽는 비용은 GB당 약 $0.03입니다. 데이터 흐름 비용만 따져도, 1TB를 쓸 때마다 약 $90의 추가 비용이 발생합니다. 만약 해당 데이터가 동기화 후에도 EFS에 계속 머무른다면, 고성능 레이어 스토리지 비용이 추가로 적용됩니다.

이것이 바로 S3 Files가 대규모의 지속적인 결과 쓰기를 유지하는 용도보다는, 기존 데이터를 읽는 용도에 더 적합한 이유입니다.

부분 업데이트 및 디렉토리 작업: 객체 모델로 인한 증폭 (amplification)

S3 Files는 파일 시스템 수준에서 데이터를 청크(chunk)로 나누지 않습니다. 대신 파일과 S3 객체(object) 간의 직접적인 매핑을 유지하려고 시도합니다. 이로 인한 단점은, 애플리케이션 관점에서는 아주 작은 업데이트임에도 불구하고 대용량 파일에 대해 작은 무작위 쓰기(random write)나 추가(append) 작업을 수행할 경우, 백엔드에서 S3로 다시 동기화(sync)하는 과정이 전체 객체 쓰기 및 버전 관리 오버헤드(versioning overhead)로 쉽게 증폭(amplify)될 수 있다는 점입니다.

예를 들어, 사용자가 S3 Files를 통해 100GB 크기의 LMDB 파일에 100KB 크기의 이미지 키를 추가한다고 가정해 보겠습니다. 애플리케이션은 이를 작은 쓰기 작업으로 인식합니다. 하지만 이 수정 사항은 즉시 S3로 다시 쓰여지지 않습니다. 최대 60초 동안 집계(aggregate)된 후 버킷(bucket)으로 동기화됩니다. 단일 블록만 업데이트하는 블록 스토리지(block storage)와 달리, 이러한 유형의 업데이트는 객체 쓰기, 동기화 지연 시간(sync latency) 및 버전 저장 비용으로 증폭될 가능성이 더 높습니다. 파일이 커지고 수정이 빈번해질수록 이 문제는 더욱 심각해집니다.

디렉토리 이름 변경(rename) 또한 S3의 평면 네임스페이스(flat namespace)로 인해 유사한 제약을 받습니다. S3에는 네이티브 디렉토리 메타데이터(directory metadata)가 없습니다. 따라서 rename 또는 mv 명령을 수행할 때, S3 Files는 단순히 단일 메타데이터 항목만 업데이트할 수 없습니다. 대신 디렉토리 아래의 모든 파일에 대해 새로운 객체를 작성하고 기존 객체를 삭제해야 합니다. 수천만 개의 객체가 포함된 디렉토리의 경우, 이는 동기화 시간을 크게 늘리고 S3 요청 비용을 증가시킵니다. 동기화가 완료될 때까지 파일 시스템 뷰(view)와 S3 뷰는 일시적으로 불일치할 수 있습니다.

종합적으로, S3 Files의 강점은 네이티브 액세스(native access), 데이터 마이그레이션 제로(zero data migration), 그리고 기존 S3 자산과의 우수한 호환성입니다. 그러나 단점은 워크로드(workload)가 대용량 파일 읽기, 연속 쓰기, 빈번한 부분 업데이트 또는 대규모 디렉토리 작업으로 전환되면 성능과 비용 모두가 더 빠르게 증폭된다는 것입니다. 이러한 이유로 S3 Files는 가벼운 공유 액세스 시나리오에 더 적합하며, 학습(training), 데이터 생성(data production), 대규모 분석(large-scale analytics)과 같은 헤비 워크로드에서는 단점이 더 빨리 나타나는 경향이 있습니다.

JuiceFS vs. S3 Files: 두 가지 서로 다른 아키텍처 철학