동기화 작동 방식 이해

S3 Files는 파일 시스템과 연결된 S3 버킷을 자동으로 동기화된 상태로 유지합니다. 능동적으로 사용하는 데이터는 파일 시스템에 복사되므로 지연 시간이 짧은 표준 Linux 파일 작업을 사용하여 파일을 읽고 쓸 수 있습니다. S3 Files를 사용하려면 연결된 S3 버킷에서 S3 버전 관리를 활성화해야 합니다. 파일 시스템에서 파일을 편집할 때 S3 Files는 변경 사항을 해당 객체의 새 버전으로 S3 버킷에 다시 복사하여 이전 버전이 보존되도록 합니다. 다른 애플리케이션이 S3 버킷에 객체를 추가, 수정 또는 삭제하면 S3 Files는 파일 시스템에 이러한 변경 사항을 자동으로 반영합니다. 파일 시스템과 S3 버킷 모두에서 동일한 데이터가 동시에 변경되어 충돌이 발생하는 경우 S3 Files는 충돌 시 S3 버킷을 사실의 출처로 취급합니다.

스토리지 비용을 최적화하기 위해 S3 Files는 파일 시스템에서 최근에 사용하지 않은 데이터를 제거합니다. 데이터는 연결된 S3 버킷에 안정적으로 저장되며 다음에 액세스할 때 파일 시스템으로 다시 가져옵니다.

S3 버킷은 파일 시스템을 통해 액세스할 수 있습니다.

S3 파일 시스템을 생성한 후 컴퓨팅 리소스에 S3 버킷을 탑재하고 S3 버킷 데이터에 즉시 액세스할 수 있습니다. 기본적으로 디렉터리의 콘텐츠를 나열하거나 그 안에 있는 파일을 열어 디렉터리에 처음 액세스할 때 S3 Files는 해당 디렉터리의 모든 파일에 대한 메타데이터를 S3 버킷에서 가져오기 크기 임계값(기본값 128KiB)보다 작은 파일에 대한 데이터와 함께 가져옵니다. 디렉터리에 대한 첫 번째 액세스는 지연 시간이 더 길 수 있지만 후속 읽기 및 쓰기는 훨씬 빠릅니다. 메타데이터를 미리 가져와서 S3 Files를 사용하면 디렉터리 콘텐츠를 찾아보고, 파일 크기를 보고, 짧은 지연 시간으로 권한을 확인할 수 있습니다.

예를 들어 S3 버킷에 객체가 1,000개인 data/images/ 접두사가 포함되어 있다고 가정해 보겠습니다. ls /mnt/s3files/data/images/를 처음 실행할 때 S3 Files는 1,000개의 모든 파일에 대한 메타데이터를 가져오고 가져오기 크기 임계값 미만의 파일에 대한 데이터를 파일 시스템에 비동기식으로 복사합니다. 이 초기 목록은 몇 초 정도 걸릴 수 있지만 해당 디렉터리의 개별 파일에 대한 ls -la, stat 또는 cat과 같은 후속 명령은 짧은 지연 시간으로 반환됩니다.

가져오기 크기 임계값보다 큰 파일의 경우 S3 Files는 메타데이터만 가져오며, 데이터는 파일 시스템에 복사되지 않고 대신 액세스할 때 S3 버킷에서 직접 읽습니다. 워크로드에 더 잘 맞게 이 임계값을 조정할 수 있습니다. 예를 들어 동일한 파일에 반복적으로 액세스하고 지연 시간이 짧은 읽기의 이점을 활용하는 워크로드에 대해 더 많은 데이터를 미리 가져오도록 늘릴 수 있습니다. 데이터를 순차적으로 스트리밍하는 워크로드의 경우 작은 임의 읽기가 아닌 큰 청크로 데이터를 순차적으로 읽을 때 데이터를 미리 가져올 때의 지연 시간 이점이 덜 의미가 있으므로 임계값이 낮을수록 비용 효율적일 수 있습니다. 자세한 내용은 S3 Files에 대한 동기화 사용자 지정 섹션을 참조하세요.

파일 시스템의 변경 사항은 S3 버킷에 자동으로 반영됩니다.

파일 시스템에서 파일을 생성, 수정 또는 삭제하면 S3 Files가 해당 변경 사항을 S3 버킷에 자동으로 복사합니다. 새 파일은 새 S3 객체가 되고, 기존 파일의 변경 사항은 새 객체 버전이 되며, 삭제된 파일은 S3 삭제 마커가 됩니다.

소유자(UID), 그룹(GID) 및 권한 비트와 같이 파일 시스템을 통해 파일 및 디렉터리에 설정한 POSIX 권한은 해당 S3 객체에 사용자 정의 S3 객체 메타데이터로 저장됩니다. chmod, chown 또는 chgrp를 사용하여 권한을 변경하면 S3 Files는 이러한 변경 사항을 데이터 변경과 함께 S3 버킷으로 내보냅니다. S3 Files가 S3 버킷에서 객체를 가져올 때이 메타데이터를 읽고 파일 시스템에 해당 POSIX 권한을 적용합니다. POSIX 권한 메타데이터가 없는 객체에는 기본 권한이 할당됩니다.

파일 시스템에서 파일을 수정하면 S3 Files는 최대 60초를 기다렸다가 S3 버킷에 복사하기 전에 해당 시간 동안 파일에 대한 모든 연속 변경 사항을 집계합니다. 즉, 모든 개별 변경 사항에 대해 새 객체 버전을 생성하는 대신 동일한 파일에 대한 빠른 연속 쓰기가 단일 S3 PUT 요청으로 캡처되므로 S3 요청 비용과 스토리지 비용이 절감됩니다. S3 Files가 변경 사항을 S3 버킷에 복사한 후에도 파일을 계속 수정하면 필요에 따라 후속 변경 사항이 복사됩니다.

예를 들어 애플리케이션이 로그 파일을 열고 30초 동안 50회 추가하면 S3 Files는 50개의 추가를 모두 단일 S3 PUT 요청에 일괄 처리합니다. 애플리케이션이 첫 번째 동기화 후에도 계속 쓰면 S3 Files는 후속 동기화에서 추가 변경 사항을 복사합니다.

S3 버킷의 변경 사항은 파일 시스템에 자동으로 표시됩니다.

S3 Files는 S3 이벤트 알림을 사용하여 S3 버킷의 변경 사항을 모니터링합니다. S3 API로 작업하는 다른 애플리케이션이 S3 버킷의 객체를 추가, 수정 또는 삭제하면 S3 Files는 현재 데이터가 파일 시스템의 고성능 스토리지에 저장된 파일에 대해 파일 시스템의 이러한 변경 사항을 자동으로 반영합니다. 파일 시스템에서 데이터가 만료된 파일은 다음에 액세스할 때까지 업데이트되지 않습니다. 그러면 S3 Files가 S3 버킷에서 최신 버전을 검색합니다.

이름 바꾸기 및 이동 작업의 영향 이해

Amazon S3는 객체가 키 이름으로 식별되는 플랫 스토리지 구조를 사용합니다. S3 Files를 사용하면 디렉터리에서 데이터를 구성할 수 있지만 S3에는 디렉터리에 대한 기본 개념이 없습니다. 파일 시스템의 디렉터리로 표시되는 것은 S3 버킷 내 객체의 키가 공유하는 공통 접두사입니다. 또한 S3 객체는 변경할 수 없으며 원자성 이름 변경을 지원하지 않습니다. 따라서 파일 이름을 바꾸거나 이동할 때 S3 Files는 업데이트된 키로 새 객체에 데이터를 쓰고 원본을 삭제해야 합니다. 디렉터리의 이름을 바꾸거나 이동할 때 S3 Files는 해당 접두사를 공유하는 모든 객체에 대해 이 프로세스를 반복해야 합니다. 따라서 수천만 개의 파일이 포함된 디렉터리의 이름을 바꾸거나 이동하면 S3 요청 비용과 동기화 시간이 크게 증가합니다.

S3 Files는 많은 수의 객체가 있는 접두사로 범위가 지정된 파일 시스템을 생성하려고 할 때 오류를 반환합니다. 이러한 경우 이름 변경에 최대 4시간(약 1,200만 개 객체)이 소요될 수 있습니다. 이 오류는 모든 파일에 S3 버킷에 대한 별도의 쓰기 및 삭제 요청이 필요하므로 대규모 재귀 이름 변경 또는 이동 작업이 파일 시스템 성능에 영향을 미칠 수 있음을 알립니다. 그래도 해당 접두사로 범위가 지정된 파일 시스템을 생성하려면 --AcceptBucketWarning 파라미터를 추가할 수 있습니다.

S3 Files는 S3 버킷에서 객체의 이름을 개별적으로 변경하므로 이름 변경이 완전히 완료될 때까지 두 디렉터리가 모두 S3 버킷에 표시됩니다. 디렉터리 이름을 변경한 후 완전히 동기화되기 전에 작성된 객체는 이동되지 않습니다. 데이터 재구성 작업을 간소화하려면 일치하는 디렉터리의 이름을 바꾸는 동안 S3 버킷을 통해 새 객체를 생성하지 않는 것이 좋습니다.

예를 들어 mv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta를 실행하면 파일 시스템에서 이름 변경이 즉시 완료됩니다. S3 버킷에서 S3 Files는 각 객체를 S3 버킷 내의 새 키에 복사 및 삭제하고(projects/alpha/ 접두사를 projects/beta/로 대체) 원본을 삭제하기 시작합니다. 이 프로세스 중에 S3 버킷에는 projects/alpha/ 및 projects/beta/ 아래의 객체가 일시적으로 포함됩니다. 모든 객체가 이동되면 projects/beta/만 유지됩니다.

스토리지를 최적화하기 위해 파일 시스템에서 미사용 데이터가 만료되었습니다.

S3 Files는 파일 시스템에서 최근에 읽지 않은 파일 데이터를 자동으로 제거하여 스토리지 비용을 최적화합니다. 데이터는 S3 버킷에 안전하게 저장됩니다. S3 Files는 파일 시스템에서 복사본만 제거합니다. 이름, 크기 및 권한과 같은 파일 메타데이터는 파일 시스템에서 제거되지 않으므로 짧은 지연 시간으로 파일 시스템을 계속 탐색할 수 있습니다.

파일 시스템의 파일을 30일 동안 읽지 않았고(구성 가능) 변경 사항이 S3 버킷에 이미 동기화된 경우 S3 Files는 파일 시스템에서 파일 데이터를 제거합니다. 다음에 해당 파일을 읽을 때 S3 Files는 S3 버킷에서 해당 객체의 최신 버전을 검색하여 파일 시스템에 다시 복사합니다.

예를 들어 1월에 /mnt/s3files/data/batch-jan.parquet에서 데이터세트를 처리하고 다시 액세스하지 않는다고 가정해 보겠습니다. 30일 후 S3 Files는 파일 시스템에서 파일 데이터를 제거합니다. 파일은 올바른 크기와 권한을 가진 디렉터리 목록에 계속 표시되지만 데이터는 더 이상 파일 시스템에 없습니다. 4월에 파일을 다시 읽으면 S3 Files가 S3 버킷에서 파일을 검색하여 파일 시스템에 다시 복사합니다. 첫 번째 읽기는 지연 시간이 길 수 있지만 후속 읽기는 빠릅니다.

S3 버킷은 충돌 시 신뢰할 수 있는 출처입니다.

충돌은 파일 시스템을 통해 동일한 파일이 수정되고 S3 Files가 파일 시스템을 S3 버킷으로 다시 동기화하기 전에 해당 S3 객체도 변경된 경우 발생합니다. 예를 들어 다른 애플리케이션이 해당 객체의 새 버전을 업로드하거나 연결된 S3 버킷에서 직접 삭제하는 동안 탑재된 파일 시스템을 통해 파일을 편집할 수 있습니다.

S3 Files는 파일 시스템을 S3 버킷으로 다시 동기화하려고 하거나 객체가 변경되었음을 나타내는 S3 이벤트 알림을 수신할 때 충돌을 감지합니다. S3 버킷은 데이터의 장기 저장소 역할을 하므로 S3 Files는 충돌이 발생할 때 S3 버킷을 사실의 출처로 간주합니다. 이렇게 하면 예측 가능한 일관성이 제공되므로 S3 버킷의 버전이 항상 우선합니다. 충돌이 발생할 경우 S3 Files는 충돌하는 파일을 파일 시스템의 현재 위치에서 분실한 디렉터리로 이동하고 연결된 S3 버킷에서 파일 시스템으로 최신 버전을 가져옵니다.

예를 들어 파일 시스템을 통해 /mnt/s3files/report.csv를 편집한다고 가정해 보겠습니다. S3 Files가 변경 사항을 S3 버킷에 다시 동기화하기 전에 다른 애플리케이션이 새 버전의 report.csv를 S3 버킷에 직접 업로드합니다. S3 Files가 충돌을 감지하면 report.csv의 버전을 분실한 디렉터리로 이동하고 S3 버킷의 버전으로 바꿉니다.

분실한 디렉터리는 파일 시스템의 루트 디렉터리 이름 .s3files-lost+found-file-system-id 아래에 있습니다. 루트 디렉터리를 지정하는 액세스 포인트를 통해 파일 시스템을 마운트하는 경우 분실 및 발견 디렉터리는 액세스 포인트의 루트 디렉터리 위에 위치하므로 해당 마운트 지점에서 보이지 않습니다. 분실 및 발견 디렉터리에 액세스하려면 액세스 포인트 없이 파일 시스템을 마운트하거나 루트 디렉터리 제한 없이 액세스 포인트를 사용하여 액세스 포인트를 통해 전체 파일 시스템의 범위에 액세스할 수 있습니다.

S3 Files가 파일을 분실한 디렉터리로 이동할 때 파일 이름 앞에 식별자를 추가하여 시간이 지남에 따라 이동할 수 있는 동일한 파일의 여러 버전을 구분합니다. 분실한 디렉터리의 파일은 S3 버킷에 복사되지 않습니다. 이 디렉터리에서 파일을 삭제하고 복사할 수 있지만 파일 내에서 파일을 이동하거나 이름을 바꾸거나 디렉터리 자체를 삭제할 수는 없습니다. S3 버킷의 최신 버전 대신 파일 시스템 변경 사항을 유지하려면 분실한 디렉터리에서 원래 경로로 파일을 복사합니다. 분실한 디렉터리에 있는 파일의 확장 속성에서 파일의 원래 경로를 검색할 수 있습니다. 그러면 S3 Files가 객체의 새 버전으로 S3 버킷에 복사합니다. 자세한 내용은 S3 Files 문제 해결 섹션을 참조하세요.

기본 동기화 설정은 S3 데이터에 대한 지연 시간이 짧은 파일 기반 액세스를 위해 대부분의 워크로드에서 작동합니다. 이러한 파라미터를 구성하는 방법에 대한 자세한 내용은 S3 Files에 대한 동기화 사용자 지정 섹션을 참조하세요.