동기화가 작동하는 방식 이해하기

동기화가 작동하는 방식 이해하기 (Understanding how synchronization works)

S3 Files는 파일 시스템과 연결된 S3 버킷을 자동으로 동기화 상태로 유지해요. 적극적으로 사용하는 데이터는 파일 시스템에 복사되어 표준 Linux 파일 작업을 사용해 낮은 지연 시간으로 파일을 읽고 쓸 수 있어요. S3 Files는 연결된 S3 버킷에 S3 버전 관리(Versioning)가 활성화되어 있어야 해요. 파일 시스템에서 파일을 편집하면 S3 Files는 변경 사항을 해당 객체의 새 버전으로 S3 버킷에 다시 복사하며, 이전 버전이 보존되도록 해요. 다른 애플리케이션이 S3 버킷에서 객체를 추가, 수정 또는 삭제하면 S3 Files는 해당 변경 사항을 파일 시스템에 자동으로 반영해요. 파일 시스템과 S3 버킷 모두에서 같은 데이터에 대한 동시 변경으로 인해 충돌이 발생하면 S3 Files는 충돌 시 S3 버킷을 진실 원천(source of truth)으로 간주해요.

저장 비용을 최적화하기 위해 S3 Files는 최근에 사용하지 않은 데이터를 파일 시스템에서 제거해요. 데이터는 연결된 S3 버킷에 안전하게 저장된 상태로 유지되며, 다음에 액세스할 때 파일 시스템으로 다시 가져와요.

출처: 문서

본문

파일 시스템을 통해 S3 버킷 액세스하기

S3 파일 시스템을 만든 후에는 컴퓨팅 리소스에 S3 버킷을 마운트하고 S3 버킷 데이터에 바로 액세스를 시작할 수 있어요. 기본적으로 디렉터리의 내용을 나열하거나 그 안의 파일을 열어 처음 액세스할 때 S3 Files는 해당 디렉터리의 모든 파일에 대한 메타데이터를 가져오고, 가져오기 크기 임계값(기본값 128 KiB)보다 작은 파일의 데이터는 S3 버킷에서 가져와요. 디렉터리에 처음 액세스할 때는 지연 시간이 더 높을 수 있지만, 이후 읽기와 쓰기는 훨씬 빨라져요. 메타데이터를 미리 가져오면 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 삭제 마커(delete marker)가 돼요.

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

파일 시스템에서 파일이 수정되면 S3 Files는 쓰기 비활성 기간(60초)을 기다린 후 해당 변경 사항을 S3 버킷으로 내보내요. 같은 파일에 대한 빠른 연속 쓰기는 각 개별 변경에 대한 여러 객체 버전을 생성하는 대신 단일 S3 PUT 요청으로 캡처돼요. 이렇게 하면 S3 요청 비용과 저장 비용이 모두 줄어들어요. 이 60초 비활성 기간을 내보내기 트리거로 사용할 수 있어요. 예를 들어 애플리케이션이 30초마다 파일에 데이터를 추가해 총 5분 동안 추가한다면 S3 Files는 6분에 내보내기 프로세스를 시작해요. 추가 변경을 하면 60초의 쓰기 활동이 없는 기간마다 프로세스가 반복돼요.

S3 버킷의 변경 사항이 파일 시스템에 자동으로 표시됨

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

이름 변경 및 이동 작업의 영향 이해하기

Amazon S3는 객체가 키 이름으로 식별되는 플랫한 저장 구조를 사용해요. S3 Files는 디렉터리에서 데이터를 구성할 수 있게 해주지만 S3에는 기본적인 디렉터리 개념이 없어요. 파일 시스템에서 디렉터리로 보이는 것은 S3 버킷 내 객체 키가 공유하는 공통 프리픽스예요. 또한 S3 객체는 불변이며 원자적 이름 변경(atomic rename)을 지원하지 않아요. 결과적으로 파일 이름을 바꾸거나 이동하면 S3 Files는 데이터를 업데이트된 키를 가진 새 객체에 쓰고 원본을 삭제해야 해요. 디렉터리 이름을 바꾸거나 이동하면 S3 Files는 해당 프리픽스를 공유하는 모든 객체에 대해 이 프로세스를 반복해야 해요. 따라서 수천만 개의 파일이 있는 디렉터리 이름을 바꾸거나 이동하면 S3 요청 비용과 동기화 시간이 크게 늘어나요.

이름 변경에 최대 4시간(약 1,200만 객체)이 걸릴 수 있을 만큼 많은 객체가 있는 프리픽스로 범위가 지정된 파일 시스템을 만들려고 하면 S3 Files는 오류를 반환해요. 이 오류는 모든 파일이 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는 충돌한 파일을 파일 시스템의 현재 위치에서 분실물 보관함(lost and found) 디렉터리로 이동하고 연결된 S3 버킷에서 최신 버전을 파일 시스템으로 가져와요.

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

분실물 보관함 디렉터리는 파일 시스템의 루트 디렉터리에 .s3files-lost+found-파일시스템ID라는 이름으로 위치해요. 루트 디렉터리를 지정하는 액세스 포인트를 통해 파일 시스템을 마운트하면 분실물 보관함 디렉터리는 액세스 포인트의 루트 디렉터리 위에 위치하므로 해당 마운트에서 보이지 않아요. 분실물 보관함 디렉터리에 액세스하려면 액세스 포인트 없이 파일 시스템을 마운트하거나 루트 디렉터리 제한이 없는 액세스 포인트를 사용해 액세스 포인트를 통해 전체 파일 시스템 범위에 액세스하세요.

S3 Files가 파일을 분실물 보관함 디렉터리로 이동할 때 시간이 지나면서 이동될 수 있는 같은 파일의 여러 버전을 구분하기 위해 파일 이름 앞에 식별자를 붙여요. 분실물 보관함 디렉터리의 파일은 S3 버킷으로 복사되지 않아요. 이 디렉터리에서 파일을 삭제하고 복사할 수는 있지만, 그 안에서 파일을 이동하거나 이름을 바꾸거나 디렉터리 자체를 삭제할 수는 없어요. S3 버킷의 최신 버전 대신 파일 시스템 변경 사항을 유지하려면 분실물 보관함 디렉터리에서 파일을 원래 경로로 다시 복사하세요. 분실물 보관함 디렉터리에 있는 파일의 확장 속성(extended attributes)에서 파일의 원래 경로를 검색할 수 있어요. 그러면 S3 Files는 객체의 새 버전으로 S3 버킷에 복사해요. 자세한 내용은 S3 Files 문제 해결을 참고하세요.

참고 S3 Files가 분실물 보관함 디렉터리로 이동한 충돌 파일은 그곳에 무기한 남아 파일 시스템 저장 비용에 포함돼요. 더 이상 필요하지 않으면 저장 공간을 확보하기 위해 분실물 보관함 디렉터리에서 파일을 삭제해야 해요.

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