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

간략한 설명

Amazon EFS의 분산형 다중 가용성 영역 아키텍처는 각 파일 작업에 대한 지연 시간 오버헤드가 적습니다. 오버헤드는 더 많은 양의 데이터에 대해 상각되기 때문에 일반적으로 평균 I/O 크기가 증가함에 따라 전체 처리량이 증가합니다.

Amazon EFS 성능은 다음과 같은 여러 요인에 따라 달라집니다.

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

해결 방법

EFS의 스토리지 클래스

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

성능 및 처리량 모드

성능 모드

Amazon EFS는 범용 및 최대 I/O의 두 가지 성능 모드를 제공합니다. 애플리케이션은 성능 모드와 관련된 한도까지 탄력적으로 IOPS를 확장할 수 있습니다.

사용할 성능 모드를 확인하려면 성능 모드를 참고하세요.

처리량 모드

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

구성된 처리량과 IOPS는 Amazon EFS의 성능에 영향을 미칩니다.

적절한 처리량 및 성능 모드를 선택하는 데 도움이 되도록 워크로드 요구 사항을 벤치마킹하는 것이 좋습니다. 프로비저닝된 처리량을 선택할 때는 워크로드 요구 사항을 충족하는 값을 선택합니다. 파일 시스템에서 소비되는 처리량 및 IOPS를 분석하려면 Amazon EFS로 지표 수학 사용하기를 참조하세요.

Amazon EFS는 버스팅, 탄력적, 프로비저닝의 세 가지 처리량 모드를 통해 최대 페타바이트의 스토리지 볼륨까지 확장할 수 있습니다. 버스팅 처리량을 사용하는 경우, 파일 시스템이 증가함에 따라 Amazon EFS의 처리량이 확장됩니다. 프로비저닝된 처리량을 사용하는 경우, 저장된 데이터의 양에 관계없이 파일 시스템의 처리량을 즉시 프로비저닝할 수 있습니다. 탄력적 처리량을 사용하면 워크로드에 따라 처리량을 늘리거나 줄일 수 있습니다. 처리량 모드에 대한 자세한 내용은 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 인스턴스에 파일 시스템 마운트 및 테스트를 참고하세요.

NFS 클라이언트 버전

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

클라이언트 측 제한 사항

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 클라이언트에 대한 할당량