EFS 파일 시스템 성능이 느린 이유가 무엇인가요?

간략한 설명

Amazon EFS의 분산 다중 가용 영역 아키텍처에서는 각 파일 작업에 약간의 지연 시간 오버헤드가 발생합니다. 평균 I/O 크기가 증가함에 따라 일반적으로 전체 처리량이 증가합니다. 오버헤드가 더 큰 양의 데이터에 분할되기 때문입니다.

Amazon EFS 성능은 다음을 비롯한 여러 요인에 따라 달라집니다.

• EFS의 스토리지 클래스입니다.
• 성능 및 처리량 모드입니다.
• EFS에 대해 수행된 작업 유형(예: 메타데이터 집약적 등)입니다.
• EFS에 저장된 데이터의 속성(예: 파일 크기 및 수)입니다.
• 탑재 옵션입니다.
• 클라이언트 측 제한 사항입니다.

해결 방법

EFS의 스토리지 클래스

자세한 내용은 성능 요약을 참조하세요.

성능 및 처리량 모드

성능 모드

Amazon EFS는 범용과 최대 I/O라는 두 가지 성능 모드를 제공합니다. 애플리케이션은 성능 모드와 관련된 한계까지 탄력적으로 IOPS를 확장할 수 있습니다. 사용할 성능 모드를 결정하려면 Amazon EFS에서 범용 및 최대 I/O 성능 모드의 차이점은 무엇입니까?를 참조하세요.

처리량 모드

파일 기반 워크로드는 일반적으로 급증하여 단기간 동안 높은 수준의 처리량을 구동하지만 장기간 동안에는 낮은 수준의 처리량을 구동합니다. Amazon EFS는 일정 기간 동안 높은 처리량 수준으로 버스트하도록 설계되었습니다.

구성된 처리량과 IOPS는 Amazon EFS의 성능에 영향을 미칩니다. 모범 사례는 적절한 처리량 및 성능 모드를 선택할 수 있도록 워크로드 요구 사항을 벤치마킹하는 것입니다. 프로비저닝된 처리량을 선택할 때 워크로드 요구 사항을 적절히 수용하는 값을 선택합니다. 버스팅 처리량 모드의 경우 더미 파일을 사용하여 Amazon EFS의 크기를 늘려 기준 처리량을 늘릴 수 있습니다. 파일 시스템에서 사용하는 처리량 및 IOPS를 분석하려면 Amazon EFS에서 지표 수식 사용을 참조하세요.

또한 Amazon EFS는 스토리지 볼륨을 페타바이트까지 스케일 업할 수 있으며 두 가지 처리량 모드(버스팅 및 프로비저닝)를 제공합니다. 버스팅 모드에서 EFS 파일 시스템의 크기가 클수록 처리량 확장도 높아집니다. 프로비저닝 모드의 경우 파일 시스템의 처리량은 데이터 양에 관계없이 MB/초 단위로 설정됩니다. 처리량 모드에 대한 자세한 내용은 Amazon EFS 버스트 크레딧은 어떻게 작동합니까?를 참조하세요.

EC2 인스턴스에서 수행되는 작업 유형

메타데이터 I/O 작업

다음과 같은 상황에서는 EFS 성능이 저하됩니다.

• 분산 시스템이기 때문에 파일 크기가 작은 경우. 이 분산 아키텍처로 각 파일 작업에 약간의 지연 시간 오버헤드가 발생합니다. 이러한 작업별 지연 시간으로 인해, 평균 I/O 크기가 증가함에 따라 일반적으로 전체 처리량이 증가합니다. 오버헤드가 더 큰 양의 데이터에 분할되기 때문입니다.
• 워크로드 또는 작업에서 여러 개의 작은 파일이 순차적으로 생성되면 공유 파일 시스템의 성능이 저하됩니다. 이로 인해 각 작업의 오버헤드가 증가합니다.
• 메타데이터 I/O는 애플리케이션이 "ls", "rm", "mkdir", "rmdir", "lookup", "getattr" 또는 "setattr" 등과 같이 메타데이터 집약적 작업을 수행하는 경우 발생합니다. 시스템에서 특정 블록의 주소를 가져와야 하는 모든 작업은 메타데이터 집약적인 워크로드로 간주됩니다. 자세한 내용은 다음을 참조하세요.
  측정: Amazon EFS에서 파일 시스템 및 객체 크기를 보고하는 방식입니다.
  작은 파일 성능 최적화입니다.

탑재 옵션

• amazon-efs-utils를 사용하여 파일 시스템을 탑재하는 경우 권장 탑재 옵션이 기본적으로 적용됩니다.
• 기본이 아닌 탑재 옵션을 사용하면 성능이 저하될 수 있습니다. 예를 들어, 더 낮은 rsize 및 wsize를 사용하여 **속성 캐싱(Attribute Caching)**을 낮추거나 끕니다. 탑재(mount) 명령의 출력을 확인하여 현재 사용 중인 탑재 옵션을 확인할 수 있습니다.

자세한 내용은 EC2 인스턴스에 파일 시스템 탑재 및 테스트를 참조하세요.

명령 예

>> mount

출력 예

fs-EXAMPLE3f75f.efs.us-east-1.amazonaws.com:/ on /home/ec2-user/efs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<EXAMPLEIP>,local_lock=none,addr=<EXAMPLEIP>)

NFS 클라이언트 버전

네트워크 파일 시스템(NFS) 버전 4.1(NFSv4) 프로토콜은 NFSv4.0(초당 1,000개 파일 미만)에 비해 병렬 작은 파일 읽기 작업(초당 10,000개 파일 초과)에서 더 나은 성능을 제공합니다.

자세한 내용은 NFS 클라이언트 탑재 설정을 참조하세요.

클라이언트 측 제한 사항

EC2 인스턴스의 병목 현상

파일 시스템을 사용하는 애플리케이션이 EFS의 예상 성능을 달성하지 못하는 경우 애플리케이션을 최적화합니다. 또한 Amazon EC2, AWS Lambda 등과 같이 애플리케이션이 호스팅되는 호스트 또는 서비스를 벤치마킹합니다. EC2 인스턴스의 리소스 부족은 EFS를 효과적으로 사용하는 애플리케이션의 기능에 영향을 줄 수 있습니다.

EC2가 애플리케이션 요구 사항에 맞게 과소 프로비저닝되었는지 확인하려면 CPU, Amazon Elastic Block Store(Amazon EBS) 등과 같은 Amazon EC2 CloudWatch 지표를 모니터링하세요. 애플리케이션 아키텍처 및 리소스 요구 사항에 대한 다양한 지표를 분석하면 요구 사항에 따라 애플리케이션 또는 인스턴스를 재구성해야 하는지 여부를 결정하는 데 도움이 됩니다.

4.0+ Linux 커널 버전 사용

성능을 최적화하고 알려진 다양한 NFS 클라이언트 버그를 방지하려면 모범 사례는 Linux 커널 버전 4.0 이상이 있는 AMI를 사용하는 것입니다.

이 규칙의 예외는 RHEL 및 CentOS 7.3 이상입니다. 이러한 운영 체제의 커널은 NFS v4.1에 적용된 수정 사항 및 개선 사항의 백포트된 버전을 받았습니다. 자세한 내용은 NFS 지원을 참조하세요.

파일 복사

cp 명령을 사용하여 파일을 복사할 때 속도가 느려질 수 있습니다. 이는 복사 명령이 직렬 작업이어서 각 파일을 한 번에 하나씩 복사하기 때문입니다. 각 파일의 파일 크기가 작으면 해당 파일을 전송하는 처리량이 적습니다.

또한 파일을 전송할 때 지연 시간이 발생할 수도 있습니다. EFS의 분산 특성상 모든 탑재 지점에 복제해야 하므로 파일 작업당 오버헤드가 발생합니다. 따라서 파일 전송 시 지연 시간은 예상된 동작입니다.

권장 사항

모범 사례는 rsync 사용과 같은 병렬 I/O 작업을 실행하는 것입니다. rsync를 사용하는 경우 cp와 rsync는 병렬 작업 대신 직렬(단일 스레드)작업에서 작동한다는 점을 유의하세요. 이렇게 하면 복사 속도가 느려집니다. fpart 또는 NU Parallel과 같은 도구를 사용하세요. Fpart는 파일 트리를 정렬하고 "파티션"으로 묶는 데 도움이 되는 도구입니다. Fpart에는 fpart와 rsync를 래핑하여 여러 rsync를 병렬로 실행하는 fpsync라는 셸 스크립트가 함께 제공됩니다. Fpsync는 자체 임베디드 스케줄러를 제공합니다. 이렇게 하면 일반적인 직렬 방법을 사용하는 것보다 이러한 작업을 더 빨리 완료할 수 있습니다.

자세한 내용은 Amazon EFS 성능 팁을 참조하세요.

---

관련 정보

NFS 클라이언트에 대한 할당량