S3 File Gateway 처리량 극대화

다음 섹션에서는 NFS와 SMB 클라이언트, S3 File Gateway 및 Amazon S3 간의 처리량을 극대화하는 모범 사례를 설명합니다. 각 섹션에 제공된 지침은 전체 처리량을 개선하는 데 점진적으로 기여합니다. 이러한 권장 사항은 필요하지 않으며 상호 종속적이지 않지만가 S3 File Gateway 구현을 테스트하고 조정하는 데 지원 사용하는 논리적 방식으로 선택 및 정렬되었습니다. 이러한 제안을 구현하고 테스트할 때 각 S3 File Gateway 배포는 고유하므로 결과가 다를 수 있습니다.

S3 File Gateway는 파일과 객체 간의 기본 1:1 매핑과 함께 업계 표준 NFS 또는 SMB 파일 프로토콜을 사용하여 Amazon S3 객체를 저장하고 검색할 수 있는 파일 인터페이스를 제공합니다. S3 File Gateway를 VMware, Microsoft Hyper-V 또는 Linux KVM 환경의 온프레미스 또는 AWS 클라우드에 Amazon EC2 인스턴스로 가상 머신으로 배포합니다. S3 File Gateway는 전체 엔터프라이즈 NAS 교체로 작동하도록 설계되지 않았습니다. S3 File Gateway는 파일 시스템을 에뮬레이션하지만 파일 시스템은 아닙니다. Amazon S3를 내구성 있는 백엔드 스토리지로 사용하면 각 I/O 작업에 추가 오버헤드가 발생하므로 기존 NAS 또는 파일 서버와 비교하여 S3 File Gateway 성능을 평가하는 것은 동등한 비교가 아닙니다.

클라이언트와 동일한 위치에 게이트웨이 배포

S3 File Gateway 가상 어플라이언스를 물리적 위치에 배포하고 NFS 또는 SMB 클라이언트 간에 네트워크 지연 시간을 최소화하는 것이 좋습니다. 게이트웨이의 위치를 선택할 때 다음 사항을 고려하세요.

• 게이트웨이의 네트워크 지연 시간이 짧으면 NFS 또는 SMB 클라이언트의 성능을 개선하는 데 도움이 될 수 있습니다.

• S3 File Gateway는 게이트웨이와 클라이언트 간에 비해 게이트웨이와 Amazon S3 간에 더 높은 네트워크 지연 시간을 허용하도록 설계되었습니다.

• Amazon EC2에 배포된 S3 File Gateway 인스턴스의 경우 게이트웨이와 NFS 또는 SMB 클라이언트를 동일한 배치 그룹에 유지하는 것이 좋습니다. 자세한 내용은 Amazon Elastic Compute Cloud 사용 설명서의 Amazon EC2 인스턴스에 대한 배치 그룹을 참조하세요.

느린 디스크로 인한 병목 현상 감소

IoWaitPercent CloudWatch 지표를 모니터링하여 S3 File Gateway의 느린 스토리지 디스크로 인해 발생할 수 있는 성능 병목 현상을 식별하는 것이 좋습니다. 디스크 관련 성능 문제를 최적화하려고 할 때는 다음 사항을 고려하세요.

• IoWaitPercent는 CPU가 루트 또는 캐시 디스크의 응답을 기다리는 시간의 비율을 보고합니다.

• IoWaitPercent가 5~10%보다 크면 일반적으로 성능 저하 디스크로 인한 게이트웨이 성능 병목 현상을 나타냅니다. 이 지표는 가능한 0%에 가까워야 합니다. 즉, 게이트웨이가 디스크를 기다리지 않으므로 CPU 리소스를 최적화하는 데 도움이 됩니다.

• Storage Gateway 콘솔의 모니터링 탭에서 확인하거나 지표IoWaitPercent가 특정 임계값을 초과하면 자동으로 알리도록 권장 CloudWatch 경보를 구성할 수 있습니다. 자세한 내용은 게이트웨이에 대한 권장 CloudWatch 경보 생성을 참조하세요.

• 를 최소화하려면 게이트웨이의 루트 및 캐시 디스크에 NVMe 또는 SSD를 사용하는 것이 좋습니다IoWaitPercent.

CPU, RAM 및 캐시 디스크에 대한 가상 머신 리소스 할당 조정

S3 File Gateway의 처리량을 최적화하려는 경우 CPU, RAM 및 캐시 디스크를 포함하여 게이트웨이 VM에 충분한 리소스를 할당하는 것이 중요합니다. CPU 4CPUs, 16GB RAM 및 150GB 캐시 스토리지의 최소 가상 리소스 요구 사항은 일반적으로 소규모 워크로드에만 적합합니다. 대규모 워크로드에 가상 리소스를 할당할 때는 다음을 권장합니다.

• S3 File Gateway에서 생성되는 일반적인 CPUs 사용량에 따라 할당된 CPU 수를 16~48개로 늘립니다. UserCpuPercent 지표를 사용하여 CPU 사용량을 모니터링할 수 있습니다. 자세한 내용은 게이트웨이 지표 이해를 참조하세요.

• 할당된 RAM을 32~64GB로 늘립니다.

  참고

  S3 File Gateway는 64GB를 초과하는 RAM을 사용할 수 없습니다.

• 루트 디스크 및 캐시 디스크에 NVMe 또는 SSD를 사용하고 게이트웨이에 쓰려는 최대 작업 데이터 세트에 맞게 캐시 디스크의 크기를 조정합니다. 자세한 내용은 공식 Amazon Web Services YouTube 채널의 S3 File Gateway 캐시 크기 조정 모범 사례를 참조하세요.

• 하나의 대용량 디스크를 사용하는 대신 게이트웨이에 최소 4개의 가상 캐시 디스크를 추가합니다. 여러 가상 디스크는 동일한 기본 물리적 디스크를 공유하더라도 성능을 향상시킬 수 있지만, 가상 디스크가 서로 다른 기본 물리적 디스크에 있는 경우 일반적으로 성능이 향상됩니다.

  예를 들어 12TB의 캐시를 배포하려는 경우 다음 구성 중 하나를 사용할 수 있습니다.

  • 3TB 캐시 디스크 4개

  • 1.5TB 캐시 디스크 8개

  • 12 x 1TB 캐시 디스크

  이를 통해 성능 외에도 시간이 지남에 따라 가상 머신을 보다 효율적으로 관리할 수 있습니다. 워크로드가 변경되면 각 개별 가상 디스크의 원래 크기를 유지하면서 캐시 디스크 수와 전체 캐시 용량을 점진적으로 늘려 게이트웨이 무결성을 유지할 수 있습니다.

  자세한 내용은 로컬 디스크 스토리지 용량 결정을 참조하세요.

S3 File Gateway를 Amazon EC2 인스턴스로 배포할 때는 다음 사항을 고려하세요.

• 선택한 인스턴스 유형은 게이트웨이 성능에 상당한 영향을 미칠 수 있습니다. Amazon EC2는 S3 File Gateway 인스턴스에 대한 리소스 할당을 조정할 수 있는 광범위한 유연성을 제공합니다.

• S3 File Gateway에 권장되는 Amazon EC2 인스턴스 유형은 Amazon EC2 인스턴스 유형에 대한 요구 사항을 참조하세요.

• 활성 S3 File Gateway를 호스팅하는 Amazon EC2 인스턴스 유형을 변경할 수 있습니다. 이를 통해 Amazon EC2 하드웨어 생성 및 리소스 할당을 쉽게 조정하여 이상적인 price-to-performance 비율을 찾을 수 있습니다. 인스턴스 유형을 변경하려면 Amazon EC2 콘솔에서 다음 절차를 사용합니다.

  1. Amazon EC2 인스턴스를 중지합니다.

  2. Amazon EC2 인스턴스 유형을 변경합니다.

  3. Amazon EC2 인스턴스의 전원을 켭니다.

  참고

  S3 File Gateway를 호스팅하는 인스턴스를 중지하면 파일 공유 액세스가 일시적으로 중단됩니다. 필요한 경우 유지 관리 기간을 예약해야 합니다.

• Amazon EC2 인스턴스의 price-to-performance 비율은 지불한 가격으로 얻을 수 있는 컴퓨팅 성능을 나타냅니다. 일반적으로 최신 세대 Amazon EC2 인스턴스는 이전 세대에 비해 비교적 저렴한 비용으로 최신 하드웨어와 향상된 성능을 갖춘 최상의 price-to-performance 비율을 제공합니다. 인스턴스 유형, 리전 및 사용 패턴과 같은 요소는이 비율에 영향을 미치므로 비용 효율성을 최적화하려면 특정 워크로드에 적합한 인스턴스를 선택하는 것이 중요합니다.

SMB 보안 수준 조정

SMBv3 프로토콜은 성능 및 보안에 일부 장단점이 있는 SMB 서명 및 SMB 암호화를 모두 허용합니다. 처리량을 최적화하기 위해 게이트웨이의 SMB 보안 수준을 조정하여 클라이언트 연결에 적용되는 보안 기능을 지정할 수 있습니다. 자세한 내용은 게이트웨이의 보안 수준 설정을 참조하세요.

SMB 보안 수준을 조정할 때는 다음 사항을 고려하세요.

• S3 File Gateway의 기본 보안 수준은 암호화 적용입니다. 이 설정은 게이트웨이 파일 공유에 대한 SMB 클라이언트 연결에 암호화와 서명을 모두 적용합니다. 즉, 클라이언트에서 게이트웨이로의 모든 트래픽이 암호화됩니다. 이 설정은 게이트웨이에서 로 가는 트래픽에는 영향을 주지 않으며 AWS,이 트래픽은 항상 암호화됩니다.

  게이트웨이는 암호화된 각 클라이언트 연결을 단일 vCPU로 제한합니다. 예를 들어 암호화된 클라이언트가 하나뿐인 경우 게이트웨이에 4개 이상의 vCPU가 할당되더라도 해당 클라이언트는 vCPUs 1개로 제한됩니다. 따라서 단일 클라이언트에서 S3 File Gateway로의 암호화된 연결에 대한 처리량은 일반적으로 40~60MB/s 사이에서 병목 현상이 발생합니다.

• 보안 요구 사항이 보다 완화된 태세를 허용하는 경우 보안 수준을 클라이언트 협상으로 변경할 수 있습니다. 그러면 SMB 암호화가 비활성화되고 SMB 서명만 적용됩니다. 이 설정을 사용하면 게이트웨이에 대한 클라이언트 연결이 여러 vCPUs 활용할 수 있으므로 일반적으로 처리량 성능이 향상됩니다.

  참고

  S3 File Gateway의 SMB 보안 수준을 변경한 후에는 파일 공유 상태가 Storage Gateway 콘솔에서 업데이트 중에서 사용 가능으로 변경될 때까지 기다린 다음 새 설정이 적용되도록 SMB 클라이언트를 연결 해제했다가 다시 연결해야 합니다.

여러 스레드 및 클라이언트를 사용하여 쓰기 작업 병렬화

단일 클라이언트의 순차 쓰기는 단일 스레드 작업이므로 한 번에 하나의 NFS 또는 SMB 클라이언트만 사용하여 파일을 작성하는 S3 File Gateway를 사용하면 처리량 성능을 극대화하기 어렵습니다. 대신 각 NFS 또는 SMB 클라이언트의 여러 스레드를 사용하여 여러 파일을 병렬로 쓰고 여러 NFS 또는 SMB 클라이언트를 S3 File Gateway에 동시에 사용하여 게이트웨이 처리량을 극대화하는 것이 좋습니다.

여러 스레드를 사용하면 성능이 크게 향상될 수 있습니다. 그러나 더 많은 스레드를 사용하려면 더 많은 시스템 리소스가 필요하므로 게이트웨이가 증가된 부하에 맞게 크기가 조정되지 않으면 성능에 부정적인 영향을 미칠 수 있습니다. 일반적인 배포에서는 게이트웨이의 최대 하드웨어 및 대역폭 제한에 도달할 때까지 스레드와 클라이언트를 더 추가할 때 더 나은 처리량 성능을 기대할 수 있습니다. 특정 하드웨어 및 네트워크 구성에 대한 속도와 시스템 리소스 사용량 간의 최적의 균형을 찾기 위해 다양한 스레드 수를 실험하는 것이 좋습니다.

스레드 및 클라이언트 구성을 테스트하는 데 도움이 되는 일반적인 도구에 대한 다음 정보를 고려하세요.

• robocopy와 같은 도구를 사용하여 게이트웨이의 파일 공유에 파일 세트를 복사하여 멀티스레드 쓰기 성능을 테스트할 수 있습니다. 기본적으로 robocopy는 파일을 복사할 때 8개의 스레드를 사용하지만 최대 128개의 스레드를 지정할 수 있습니다.

  robocopy와 함께 여러 스레드를 사용하려면 명령에 /MT:n 스위치를 추가합니다. 여기서 n는 사용하려는 스레드 수입니다. 예:

  robocopy C:\source D:\destination /MT:64

  이 명령은 복사 작업에 64개의 스레드를 사용합니다.

  참고

  이 방법은 단일 스레드로 제한되고 파일을 순차적으로 복사하므로 최대 처리량을 테스트할 때 Windows Explorer를 사용하여 파일을 끌어서 놓지 않는 것이 좋습니다.

  자세한 내용은 Microsoft Learn 웹 사이트의 robocopy를 참조하세요.

• DISKSPD 또는 FIO와 같은 일반적인 스토리지 벤치마킹 도구를 사용하여 테스트를 수행할 수도 있습니다. 이러한 도구에는 특정 워크로드 요구 사항에 맞게 스레드 수, I/O 깊이 및 기타 파라미터를 조정할 수 있는 옵션이 있습니다.

  DiskSpd를 사용하면 -t 파라미터를 사용하여 스레드 수를 제어할 수 있습니다. 예:

  diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat

  이 예제 명령은 다음을 수행합니다.

  • 10GB 테스트 파일 생성(-c1G)

  • 300초 동안 실행(-d300)

  • 50% 읽기 50% 쓰기로 임의 I/O 테스트 수행(-r -w50)

  • 스레드 64개 사용(-t64)

  • 대기열 깊이를 스레드당 32로 설정합니다(-o32).

  • 1MB 블록 크기 사용(-b1M)

  • 하드웨어 및 소프트웨어 캐싱을 비활성화합니다(-h -L).

  자세한 내용은 Microsoft Learn 웹 사이트에서 DISKSPD를 사용하여 워크로드 스토리지 성능 테스트를 참조하세요.

• FIO는 numjobs 파라미터를 사용하여 병렬 스레드 수를 제어합니다. 예:

  fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting

  이 예제 명령은 다음을 수행합니다.

  • 임의 I/O 테스트 수행(--rw=randrw)

  • 70% 읽기 및 30% 쓰기 수행(--rwmixread=70)

  • 1MB 블록 크기 사용(--bs=1M)

  • I/O 깊이를 64(--iodepth=64)로 설정합니다.

  • 10GB 파일에서 테스트(--size=10G)

  • 5분 동안 실행(--runtime=300)

  • 64개의 병렬 작업(스레드)을 생성합니다(--numjobs=64).

  • 비동기 I/O 엔진(--ioengine=libaio) 사용

  • 더 쉬운 분석을 위해 결과를 그룹화합니다(--group_reporting).

  자세한 내용은 fio Linux man 페이지를 참조하세요.

자동 캐시 새로 고침 끄기

자동 캐시 새로 고침 기능을 사용하면 S3 File Gateway가 메타데이터를 자동으로 새로 고칠 수 있으므로 게이트웨이가 아닌 Amazon S3 버킷에 직접 기록하여 사용자 또는 애플리케이션이 파일 세트에 변경한 내용을 캡처하는 데 도움이 될 수 있습니다. 자세한 내용은 Amazon S3 버킷 객체 캐시 새로 고침을 참조하세요.

게이트웨이 처리량을 최적화하려면 Amazon S3 버킷에 대한 모든 읽기 및 쓰기가 S3 File Gateway를 통해 수행되는 배포에서이 기능을 끄는 것이 좋습니다.

자동 캐시 새로 고침을 구성할 때는 다음 사항을 고려하세요.

• 배포의 사용자 또는 애플리케이션이 가끔 Amazon S3에 직접 쓰기 때문에 자동 캐시 새로 고침을 사용해야 하는 경우 비즈니스 요구 사항에 여전히 실용적인 새로 고침 사이의 가능한 가장 긴 시간 간격을 구성하는 것이 좋습니다. 캐시 새로 고침 간격이 길수록 디렉터리를 검색하거나 파일을 수정할 때 게이트웨이가 수행해야 하는 메타데이터 작업 수를 줄일 수 있습니다.

  예를 들어 워크로드에 대해 허용 가능한 경우 자동 캐시 새로 고침을 5분이 아닌 24시간으로 설정합니다.

• 최소 시간 간격은 5분입니다. 최대 간격은 30일입니다.

• 매우 짧은 캐시 새로 고침 간격을 설정하도록 선택한 경우 NFS 및 SMB 클라이언트의 디렉터리 브라우징 환경을 테스트하는 것이 좋습니다. 게이트웨이 캐시를 새로 고치는 데 걸리는 시간은 Amazon S3 버킷의 파일 및 하위 디렉터리 수에 따라 크게 증가할 수 있습니다.

Amazon S3 업로더 스레드 수 증가

기본적으로 S3 File Gateway는 Amazon S3 데이터 업로드를 위해 8개의 스레드를 열어 대부분의 일반적인 배포에 충분한 업로드 용량을 제공합니다. 그러나 게이트웨이가 표준 8 스레드 용량으로 Amazon S3에 업로드할 수 있는 것보다 높은 속도로 NFS 및 SMB 클라이언트로부터 데이터를 수신할 수 있으며, 이로 인해 로컬 캐시가 스토리지 한도에 도달할 수 있습니다.

특정 상황에서는 게이트웨이의 Amazon S3 업로드 스레드 풀 수를 8개에서 40개로 지원 늘릴 수 있으므로 더 많은 데이터를 병렬로 업로드할 수 있습니다. 대역폭 및 배포와 관련된 기타 요인에 따라 업로드 성능이 크게 향상되고 워크로드를 지원하는 데 필요한 캐시 스토리지 양을 줄이는 데 도움이 될 수 있습니다.

CachePercentDirty CloudWatch 지표를 사용하여 Amazon S3에 아직 업로드되지 않은 로컬 게이트웨이 캐시 디스크에 저장된 데이터의 양을 모니터링하고 지원 에 문의하여 업로드 스레드 풀 수를 늘리면 S3 File Gateway의 처리량이 향상될 수 있는지 확인하는 것이 좋습니다. 자세한 내용은 게이트웨이 지표 이해를 참조하세요.

참고

이 설정은 추가 게이트웨이 CPU 리소스를 사용합니다. 게이트웨이 CPU 사용량을 모니터링하고 필요한 경우 할당된 CPU 리소스를 늘리는 것이 좋습니다.

SMB 제한 시간 설정 증가

S3 File Gateway가 대용량 파일을 SMB 파일 공유에 복사하는 경우 SMB 클라이언트 연결은 장기간 후에 시간 초과될 수 있습니다.

파일 크기와 게이트웨이의 쓰기 속도에 따라 SMB 클라이언트의 SMB 세션 제한 시간 설정을 20분 이상으로 확장하는 것이 좋습니다. 기본값은 300초 또는 5분입니다. 자세한 내용은 게이트웨이 백업 작업이 실패하거나 게이트웨이에 쓸 때 오류가 있음을 참조하세요.

호환되는 애플리케이션에 대한 기회 잠금 켜기

기회 잠금 또는 "oplocks"는 새 S3 File Gateway마다 기본적으로 활성화됩니다. 호환되는 애플리케이션과 함께 oplock을 사용하는 경우 클라이언트는 여러 개의 더 작은 작업을 더 큰 작업으로 배치하므로 클라이언트, 게이트웨이 및 네트워크에 더 효율적입니다. Microsoft Office, Adobe Suite 등 클라이언트 측 로컬 캐싱을 활용하는 애플리케이션을 사용하는 경우 성능을 크게 개선할 수 있으므로 기회 잠금을 켜두는 것이 좋습니다.

기회 잠금을 끄면 일반적으로 oplock을 지원하는 애플리케이션이 대용량 파일(50MB 이상)을 훨씬 더 느리게 엽니다. 이 지연은 게이트웨이가 4KB 파트로 데이터를 전송하여 I/O가 높고 처리량이 낮기 때문에 발생합니다.

작업 파일 세트의 크기에 따라 게이트웨이 용량 조정

게이트웨이 용량 파라미터는 게이트웨이가 로컬 캐시에 메타데이터를 저장할 최대 파일 수를 지정합니다. 기본적으로 게이트웨이 용량은 스몰로 설정되어 있습니다. 즉, 게이트웨이는 최대 5백만 개의 파일에 대한 메타데이터를 저장합니다. 기본 설정은 Amazon S3에 수억 개 또는 수십억 개의 객체가 있더라도 대부분의 워크로드에서 잘 작동합니다. 일반적인 배포에서는 특정 시간에 작은 하위 집합의 파일만 적극적으로 액세스하기 때문입니다. 이 파일 그룹을 "작업 세트"라고 합니다.

워크로드가 5백만 개 이상의 작업 파일 세트에 정기적으로 액세스하는 경우 게이트웨이는 RAM에 저장되고 루트 디스크에 유지되는 작은 I/O 작업인 캐시 제거를 자주 수행해야 합니다. 게이트웨이가 Amazon S3에서 새 데이터를 가져올 때 게이트웨이 성능에 부정적인 영향을 미칠 수 있습니다.

IndexEvictions 지표를 모니터링하여 새 항목을 위한 공간을 확보하기 위해 캐시에서 메타데이터가 제거된 파일 수를 확인할 수 있습니다. 자세한 내용은 게이트웨이 지표 이해를 참조하세요.

UpdateGatewayInformation API 작업을 사용하여 일반적인 작업 세트의 파일 수에 맞게 게이트웨이 용량을 늘리는 것이 좋습니다. 자세한 내용은 UpdateGatewayInformation을 참조하세요.

참고

게이트웨이 용량을 늘리려면 추가 RAM 및 루트 디스크 용량이 필요합니다.

• 소형(5백만 파일)에는 최소 16GB의 RAM과 80GB 루트 디스크가 필요합니다.

• 중간 크기(1천만 파일)에는 최소 32GB의 RAM과 160GB의 루트 디스크가 필요합니다.

• 대용량(2천만 파일)에는 64GB의 RAM과 240GB 루트 디스크가 필요합니다.

중요

게이트웨이 용량은 줄일 수 없습니다.

대규모 워크로드를 위한 여러 게이트웨이 배포

단일 대형 게이트웨이에서 많은 파일 공유를 통합하는 대신 가능하면 워크로드를 여러 게이트웨이로 분할하는 것이 좋습니다. 예를 들어, 자주 사용되지 않는 파일 공유를 다른 게이트웨이에서 그룹화하면서 한 게이트웨이에서 많이 사용되는 파일 공유 하나를 격리할 수 있습니다.

여러 게이트웨이 및 파일 공유를 사용하여 배포를 계획할 때는 다음 사항을 고려하세요.

• 단일 게이트웨이의 최대 파일 공유 수는 50개이지만 게이트웨이에서 관리하는 파일 공유 수는 게이트웨이의 성능에 영향을 미칠 수 있습니다. 자세한 내용은 여러 파일 공유가 있는 게이트웨이에 대한 성능 지침을 참조하세요.

• 각 S3 File Gateway의 리소스는 파티셔닝 없이 모든 파일 공유에서 공유됩니다.

• 사용량이 많은 단일 파일 공유는 게이트웨이에서 다른 파일 공유의 성능에 영향을 미칠 수 있습니다.

참고

하나 이상의 파일 공유가 읽기 전용이 아닌 한 여러 게이트웨이에서 동일한 Amazon S3 위치에 매핑되는 여러 파일 공유를 생성하는 것은 권장하지 않습니다.

여러 게이트웨이의 동일한 파일에 대한 동시 쓰기는 데이터 무결성 문제를 일으킬 수 있는 다중 라이터 시나리오로 간주됩니다.