# S3 Files 모범 사례
이 페이지에서는 S3 파일 시스템 작업에 권장되는 모범 사례를 설명합니다.
## 성능 및 비용 최적화
+ **워크로드 병렬화** - S3 Files는 고도로 병렬화된 워크로드를 지원하도록 설계되었습니다. 읽기를 여러 파일과 여러 컴퓨팅 인스턴스에 분산하면 집계 처리량을 극대화하는 데 도움이 됩니다. 동일한 버킷 내에서 서로 다른 특정 접두사로 범위가 지정된 여러 파일 시스템을 생성하여(전체 버킷에 대해 하나의 파일 시스템을 생성하는 대신) 수평적으로 확장하고 집계 처리량을 개선할 수도 있습니다.
+ **파일 시스템의 범위를 워크로드가 이름 변경의 영향을 최소화하는 데 필요한 가장 작은 접두사로 지정** – S3에는 디렉터리에 대한 기본 개념이 없습니다. 디렉터리의 이름을 바꾸거나 이동할 때 S3 Files는 업데이트된 키를 사용하여 새 객체에 데이터를 쓰고 해당 디렉터리의 모든 파일에 대해 원본을 삭제해야 합니다. 수천만 개의 파일로 디렉터리 이름을 바꾸면 S3 요청 비용과 동기화 시간이 크게 증가할 수 있습니다. 파일 시스템의 범위를 활성 데이터세트로 지정하거나 이름을 바꿀 디렉터리에 더 적은 파일이 포함되도록 데이터를 구조화합니다. 자세한 내용은 [이름 바꾸기 및 이동 작업의 영향 이해](s3-files-synchronization.md#s3-files-sync-rename-move) 섹션을 참조하세요.
+ **대규모 IO 크기 사용** - S3 Files는 각 읽기 및 쓰기 작업을 최소 32KB로 측정합니다. 더 큰 IO 크기(1MB 이상)를 사용하면 작업당 오버헤드가 분할 상환되고 많은 작은 읽기 또는 쓰기보다 비용 효율적입니다. 탑재 도우미를 사용하는 경우 최적의 성능을 위해 기본 NFS 읽기 및 쓰기 버퍼 크기가 1MB로 설정됩니다.
+ **가져오기 구성에서 sizeLessThan 값을 파일 크기에 맞게 조정 **- 기본적으로 S3 Files는 디렉터리에 처음 액세스할 때 128KB보다 작은 파일의 데이터를 캐싱합니다. 이 임계값보다 큰 파일은 S3에서 직접 읽습니다. 워크로드가 더 큰 파일에서 지연 시간에 민감한 작은 읽기를 수행하는 경우 지연 시간이 짧은 액세스를 위해 파일 시스템의 고성능 스토리지에 필요한 파일 크기와 일치하도록 sizeLessThan 임계값을 늘립니다. 자세한 내용은 [S3 Files에 대한 동기화 사용자 지정](s3-files-synchronization-customizing.md) 섹션을 참조하세요.
+ **워크로드 수명 주기와 일치하도록 만료 기간 설정** - 만료 기간 내에 읽지 않은 데이터는 파일 시스템에서 자동으로 제거됩니다. 배치 작업 또는 훈련 실행과 같은 수명이 짧은 워크로드의 경우 더 짧은 만료(1\~7일)를 사용하여 스토리지 비용을 최소화합니다. 몇 주 동안 동일한 데이터를 재검토하는 워크로드의 경우 더 긴 만료(30\~90일)를 사용하여 짧은 지연 시간의 이점을 계속 활용하세요. 자세한 내용은 [S3 Files에 대한 동기화 사용자 지정](s3-files-synchronization-customizing.md) 섹션을 참조하세요.
+ **혼합 워크로드에 접두사 범위 규칙 사용** - 버킷에 자주 액세스하는 데이터와 자주 액세스하지 않는 데이터가 모두 포함된 경우 각 접두사에 대해 별도의 가져오기 규칙을 생성합니다. 이렇게 하면 콜드 접두사 메타데이터만 유지하면서 핫 접두사에 대한 데이터를 적극적으로 가져올 수 있습니다. 자세한 내용은 [S3 Files에 대한 동기화 사용자 지정](s3-files-synchronization-customizing.md) 섹션을 참조하세요.
+ **모든 가용 영역에 탑재 대상 생성** - 교차 AZ 데이터 전송 비용을 줄이고 성능을 개선할 수 있도록 운영하는 각 가용 영역에 탑재 대상을 하나씩 생성하는 것이 좋습니다. 이렇게 하면 컴퓨팅 리소스가 항상 파일 시스템에 대한 로컬 네트워크 경로를 보유하여 가용성과 지연 시간을 모두 개선할 수 있습니다. AWS Management Console을 사용하여 파일 시스템을 생성하면 S3 Files는 선택한 VPC의 모든 가용 영역에 하나의 탑재 대상을 자동으로 생성합니다.
## 동기화
+ **S3 Files 일관성 모델 이해** - 파일 시스템의 파일이 S3 버킷의 해당 객체와 동시에 수정되면 S3 Files는 S3 버킷을 신뢰할 수 있는 소스로 취급하고 파일을 분실한 디렉터리로 이동합니다. 충돌을 방지하려면 경로(파일 시스템 또는 S3) 하나를 기본 라이터로 지정합니다.
+ **동기화 상태 모니터링** - CloudWatch 지표를 사용하여 파일 시스템과 S3 버킷 간의 동기화 상태를 추적합니다. `PendingExports`가 증가하면 워크로드가 동기화 속도보다 빠르게 변경 사항을 생성하고 있음을 나타냅니다. 즉, 동기화를 완료하는 데 시간이 더 오래 걸립니다. 0이 아닌 `ExportFailures` CloudWatch 지표는 내보낼 수 없고 작업이 필요한 파일을 나타냅니다. 자세한 내용은 [S3 Files 문제 해결](s3-files-troubleshooting.md) 섹션을 참조하세요.
## 액세스 관리
+ **최소 권한 원칙 준수 **- 각 IAM 역할 및 파일 시스템 정책에 필요한 최소 권한만 부여합니다. 예를 들어 컴퓨팅 리소스가 파일 시스템에서만 데이터를 읽어야 하는 경우 `AmazonS3FilesClientFullAccess` 대신 `AmazonS3FilesClientReadOnlyAccess` 관리형 정책을 연결합니다. 또한 클라이언트가 해당 접두사 내의 데이터에만 액세스할 수 있도록 전체 버킷이 아닌 특정 접두사로 범위가 지정된 파일 시스템을 생성하는 것이 좋습니다.
+ **S3 Files IAM 역할 수정 안 함** - S3 Files가 S3 버킷과 동기화하기 위해 수임하는 IAM 역할을 수정하거나 삭제하지 마세요. 이 역할을 변경하거나 제거하면 파일 시스템과 S3 버킷 간의 동기화가 중단될 수 있습니다.
+ **S3 Files EventBridge 규칙 수정 안 함** - S3 Files는 EventBridge 규칙(DO-NOT-DELETE-S3-Files 접두사)을 생성하여 S3 버킷의 변경 사항을 감지합니다. 이 규칙을 비활성화, 수정 또는 삭제하지 마세요. 이를 제거하면 S3 Files가 버킷에서 새 객체 또는 변경된 객체를 감지하지 못하여 파일 시스템이 오래된 상태가 됩니다.
+ **에서 작성한 로그에 대한 액세스 제한 고려 `efs-utils`** - `efs-utils`는 `/var/log/amazon/efs` 디렉터리에 저장하는 로그에 S3 객체 키 이름을 직접 씁니다. S3 키 이름에 민감한 정보가 포함된 경우 POSIX 권한을 통해이 디렉터리에 대한 액세스를 제한해야 합니다. 예를 들어 `sudo chmod 700 /var/log/amazon/efs` 명령을 통해 액세스를 제한할 수 있습니다.
## 모니터링
+ **동기화 실패에 대한 경보 설정** - `ImportFailures` 및 `ExportFailures`에 CloudWatch 경보를 생성하고 파일이 동기화되지 않을 때 알림을 받습니다. 내보내기가 실패하면 권한 문제, 암호화 키 문제 또는 경로 길이 제한이 나타날 수 있습니다. 자세한 내용은 [S3 Files 문제 해결](s3-files-troubleshooting.md) 섹션을 참조하세요.