AWS 기술 블로그

Amazon EFS의 처리량 및 성능 모드에 대한 이해와 올바른 선택

서론

Amazon Elastic File System (Amazon EFS)는 서버리스 방식의 완전 탄력적인 파일 스토리지 서비스입니다. AWS 컴퓨팅 시스템을 위한 공유 파일 시스템을 간편하고 빠르게 생성하고 구성할 수 있으며, 파일시스템의 프로비저닝, 배포, 패치 적용 또는 유지 관리가 필요하지 않습니다. 또한 온디맨드 방식으로 페타바이트 규모의 용량과 초당 기가바이트의 처리량으로 즉시 확장할 수 있으며, 사용한 용량과 성능에 따라 과금이 되므로 비용 효율적으로 사용할 수 있습니다.

EFS는 워크로드의 비용, 가용성, 성능 요건에 따라서 최적의 파일 시스템을 생성하고 활용할 수 있도록, 다양한 파일 시스템 유형과 스토리지 클래스를 제공합니다. 그리고, 파일 시스템의 요구 성능을 충족시킬 수 있도록, MiBps와 IOPS의 성능 설정을 위한 처리량 및 성능 모드를 제공합니다. 그러나, 적합한 파일 시스템 유형, 스토리지 클래스, 처리량 및 성능 모드를 선택하지 않을 경우, 워크로드의 성능 지연, 과도한 비용 과금, 또는 데이터의 가용성과 같은 문제가 발생할 수도 있습니다. 따라서, 최적의 파일 시스템 조합을 선택하는 것은 중요한 작업이지만, EFS 스토리지 서비스에 대한 이해가 부족할 경우에는 어려움에 부딪힐 수 있습니다. 이 블로그는, 이와 같은 어려움에 부딪힌 독자들이 EFS 서비스의 성능에 대한 선택 사항들을 잘 이해하고, 최적의 파일 시스템 구성을 선택할 수 있도록 돕기 위한 것입니다.

EFS 파일 시스템의 유형과 스토리지 클래스

성능에 대해 알아 보기 전에, 가용성과 비용 최적화를 위한 선택 사항으로 EFS 파일 시스템의 유형과 스토리지 클래스를 먼저 살펴 보겠습니다.

EFS 파일 시스템 유형

EFS는 리전(Regional)과 원존(One Zone)의 두 가지 파일 시스템 유형을 제공합니다. 이 두 유형의 파일 시스템은, 데이터의 가용성 측면에서 명확한 차이를 보이므로, 적절한 유형을 선택하는 데 어려움이 없습니다. 최고의 가용성을 위해서는, 리전 유형 파일 시스템의 사용을 권고하며, 원존 유형의 파일 시스템은 매우 드물게 발생하는 가용 영역 수준의 장애에 대비하기 위하여 주기적인 백업을 수행하시는 것을 권고합니다.
AWS의 리전과 가용 영역의 개념에 대한 보다 자세한 사항은, AWS 글로벌 인프라의 리전 및 가용 영역을 참고하여 주십시오.

  • 리전(Regional) – 일반적으로 권고되어지는 리전 파일 시스템은, AWS 리전 내에서 지리적으로 분리된 여러 가용 영역에 데이터를 중복하여 저장합니다. 여러 가용 영역에 걸쳐 데이터가 저장되기 때문에, AWS 리전에서 하나 이상의 가용 영역을 사용할 수 없는 경우에도 데이터에 대한 지속적인 가용성이 제공됩니다.
  • 원존(One Zone) – 원존 파일 시스템은 AWS 리전의 단일 가용 영역 내에 데이터를 저장합니다. 단일 가용 영역에 데이터를 저장하면 데이터에 대한 지속적인 가용성이 제공됩니다. 그러나, 매우 드물게 가용 영역 전체 또는 일부가 손실되거나 손상되는 경우에는, 파일 시스템에 저장된 데이터가 손실될 수도 있습니다.

EFS 스토리지 클래스

EFS는 성능과 비용에 대한 균형을 맞출 수 있도록, 세 가지의 스토리지 클래스를 제공하며 데이터 수명 주기 정책지능형 티어링을 사용하여 비용을 최적화 할 수 있습니다. 자주 접근이 필요하고 성능이 중요한 데이터는 표준 스토리지 클래스를 사용하고, 자주 접근이 되지 않는 데이터는 비용 절감을 위하여 다른 스토리지 클래스를 함께 사용할 수 있습니다.

  • EFS 표준(Standard) – 솔리드 스테이트 드라이브(SSD) 스토리지를 사용하여 자주 접근하는 데이터에 대해 최저 수준의 지연 시간을 제공합니다.
  • EFS IA(Infrequent Access) – 분기에 몇 번만 액세스되고 EFS Standard의 밀리초 미만의 지연 시간이 요구되지 않는 데이터에 대해 비용이 최적화된 스토리지 클래스입니다.
  • EFS 아카이브(Archive) – 1년에 몇 번 또는 그 이하로 액세스되는 장기 저장 데이터에 대해 비용이 최적화된 스토리지 클래스로, EFS IA 스토리지 클래스와 유사한 성능을 제공합니다. 아카이브 스토리지 클래스는 탄력적 처리량 모드에서만 사용이 가능하기 때문에, 이 블로그 게시글을 추가적으로 참고하시기를 권장하여 드립니다.

EFS 파일 시스템 생성시 선택 항목

EFS는 파일 시스템의 유형, 스토리지 클래스, 처리량 모드, 성능 모드의 조합에 따라서 최대로 제공할 수 있는 성능과 지연 시간이 달라집니다. 빠른 생성으로 파일 시스템을 생성하게 되면, “리전 유형”, “탄력적 처리량 모드”, “범용 성능 모드”를 기본값으로 파일 시스템이 생성됩니다. 일반적으로 권장이 되는 구성이지만, 워크로드의 유형에 따라 보다 세밀하게 설정하기 위해서는, 사용자 지정으로 파일 시스템을 생성하면서 아래와 같은 사항들을 목적에 맞게 선택을 해야 합니다.

  • 파일 시스템 유형 – 리전 또는 원존
  • 스토리지 클래스 – 데이터 수명 주기 정책을 설정하면, 정책에 따라 표준, IA, 아카이브 스토리지 클래스를 함께 사용하게 됩니다.
  • 성능 설정

앞서 살펴본 바와 같이, 파일 시스템의 유형과 스토리지 클래스는 그 사용 목적을 명확하게 구분할 수 있기 때문에, 이 블로그에서는 리전 유형, 그리고 표준 스토리지 클래스 파일 시스템의 성능에 대한 부분을 중심으로 다룰 것입니다.

EFS 파일 시스템의 처리량 모드와 성능 모드

지금 부터는 EFS의 성능에 직접적으로 영향을 주게 되는, 성능과 관련된 설정 항목들에 대해서 알아 보겠습니다. 전체적인 EFS 성능에 관한 요약은 Amazon EFS 사용자 가이드의 성능 페이지에서 확인할 수 있습니다.

파일 시스템 성능 모니터링 지표 및 수식

EFS는 파일 시스템의 모니터링을 위한 Amazon CloudWatch 지표들을 제공합니다. 이러한 CloudWatch 지표들을 계산하여 파일 시스템의 사용량과 성능을 보다 상세히 관찰하고 분석할 수 있습니다. EFS의 처리량과 성능 모드를 올바르게 선택하려면, 아래의 세 가지 항목에 대한 이해가 필요합니다.

  • IOPS 처리량(Throughput) – 단위 시간당 처리된 I/O 작업의 수로, 측정된 IOBytes의 샘플 카운트 지표를 초로 나누어, 초당 읽기 및 쓰기 작업수의 처리량을 확인할 수 있으며 IOPS로 표현이 됩니다.
  • MiBps 처리량(Throughput) – 단위 시간당 처리된 데이터의 양으로, 측정된 IOBytes의 합계 지표를 초로 나누어, 초당 읽기 및 쓰기 데이터 처리량을 확인할 수 있으며 MiBps로 표현이 됩니다.
  • 지연 시간(Latency) – 단위 읽기 또는 쓰기 작업이 완료된 시간으로, 일반적으로 밀리 초(millisecond, ms) 또는 마이크로 초(microseconds, µs)로 표현이 됩니다.

EFS 처리량 모드(Throughput mode)

EFS의 처리량 모드는 파일 시스템이 제공할 수 있는 최대 MiBps 처리량을 결정하는 항목입니다. EFS는 버스팅, 프로비전드, 탄력적 모드의 세 가지 처리량 모드를 제공하며 각각의 모드에 대해서 자세히 알아보도록 하겠습니다. 그리고, 쓰기 처리량보다 높은 읽기 처리량을 제공할 수 있도록 읽기 처리량은 1/3로 측정이 됩니다. 즉, 3 MiBps의 읽기 작업은 1 MiBps의 쓰기 작업으로 측정이 됩니다. 또한, 각 모드의 최대 처리량은 AWS 리전에 따라 달라집니다. 리전별 최대 파일 시스템 처리량에 대한 자세한 내용은 Amazon EFS 할당량 을 참조하시기 바랍니다.

버스팅 처리량 모드(Bursting throughput mode)

  • 버스팅 처리량 모드는 파일 시스템의 사용 용량에 따라서 성능이 달라지는 모드입니다.
  • 버스팅 처리량 모드의 성능은, 파일 시스템의 사용 용량에 따라 증가가 되는 기본 성능과, 버스트 크레딧을 이용하여 확장될 수 있는 버스팅 성능으로 나뉘어 집니다
  • 기본 성능은 최소 1 MiBps가 제공되며, 사용 용량 GiB 당 50 KiBps (TiB 당 50 MiBps) 단위로 증가합니다. 버스팅 성능은 TiB 당 100 MiBps가 제공됩니다.
  • 파일 시스템의 사용 용량이 1 TiB 이하이면 2.1 TiB 의 초기 버스트 크레딧이 제공됩니다. 사용 용량이 1 TiB 보다 큰 파일시스템은 TiB 당 2.1 TiB의 초기 버스트 크레딧이 제공됩니다.
  • 버스트 크레딧이 남아 있을 경우에는 버스팅 성능으로 동작할 수 있으며, 크레딧이 모두 소진이 되었다면 기본 성능으로 동작을 합니다. 만약, 기본 성능보다 낮게 사용이 되면 버스트 크레딧이 누적됩니다.
  • 예를 들어, 100 MiBps의 성능으로 3분간 쓰기 작업을 수행하였다면, 100 MiB * 180초 = 18,000 MiB의 버스트 크레딧을 소진하게 됩니다. 보다 상세한 버스트 크레딧의 소진과 누적은 “표 1. Amazon EFS 버스팅 처리량 모드 파일 시스템의 동작 예제”를 참고하시기 바랍니다.
  • 비용은 파일 시스템의 사용 용량에만 과금이 되며, 별도의 성능 비용은 과금되지 않습니다. 따라서, 파일 시스템의 사용 용량이 증가할 수록 높은 성능이 필요한 워크로드의 경우에, 가장 비용과 성능에 대한 균형을 맞출 수 있는 처리량 모드입니다.
  • 버스팅 모드의 일반적인 동작의 예제는 EFS 사용자 가이드의 Amazon EFS 버스트 크레딧에 대한 이해를 참고할 수 있습니다. 아래의 표 1은 사용자 가이드의 동작 예제 표를 보다 더 다양하게 확장한 것이며, 처리량 성능 수치는 쓰기 작업 기준으로 작성이 되어 있으며, 100 MiBps의 쓰기 작업은 300 MiBps의 읽기 작업으로 환산할 수 있습니다.
  • 즉, 1 TiB 를 사용하는 파일 시스템의 경우에 기본 성능은 50 MiBps를 제공합니다. 그리고, 버스트 크레딧이 완전히 충전되어 있는 경우, 하루에 12시간 동안은 버스팅 성능 100 MiBps로 동작할 수 있음을 의미하며, 기본 성능 50 MiBps 보다 낮게 동작하면 버스트 크레딧이 분당 3,000 MiB가 충전이 됩니다.

표 1. Amazon EFS 버스팅 처리량 모드 파일 시스템의 동작 예제

프로비전드 처리량 모드(Provisioned throughput mode)

  • 프로비전드 처리량 모드는 사용자가 필요한 처리량 성능을 직접 설정하는 모드로, 워크로드의 데이터 사용 용량과는 무관하게 지속적인 처리량 성능이 필요할 경우에 사용할 수 있습니다.
  • 예를 들어, 200 GiB의 버스팅 모드 파일 시스템일 경우, 기본 성능 10 MiBps와 버스팅 성능은 100 MiBps를 제공합니다. 만약, 필요한 성능이 150 MiBps 일 경우 버스팅 모드를 사용하면 성능 요구 사항을 충족할 수 없습니다. 그러나, 프로비전드 모드는 150 MiBps를 프로비전하여 용량이 작음에고 불구하고, 필요한 성능을 보장할 수 있습니다.
  • 리전에 따라서 최대로 프로비전할 수 있는 처리량이 다르므로, 자세한 내용은 Amazon EFS 할당량 을 참조하시기 바랍니다. 서울 리전의 경우 쓰기 1 GiBps, 읽기 3 GiBps 까지 프로비전할 수 있습니다.
  • 비용은 200 GiB의 스토리지 사용 용량 요금과 MB/s-월 단위의 프로비전된 성능 비용이 추가 과금이 됩니다. 리전별로 프로비전된 성능에 대한 요금이 다르기 때문에 Amazon EFS 요금 페이지를 참고하시기 바랍니다.
  • 파일 시스템을 생성하여 사용할 수 있게 된 후에, 처리량 모드와 프로비전된 처리량을 변경할 수 있습니다. 파일 시스템을 프로비전드 모드로 변경하거나 프로비전된 처리량을 증가시키는 것은 수시로 가능하지만, 다시 다른 처리량 모드로 변경하거나 프로비전된 처리량을 감소시키는 것은 최소 24시간 이후에 가능합니다.

탄력적 처리량 모드(Elastic throughput mode)

  • 버스팅 모드 또는 프로비전드 모드는 사용자가 워크로드의 성능 사용 패턴에 대해서 명확하게 파악을 하고 있어야 합니다. 하지만, 성능 사용 패턴을 예측할 수 없거나, 불규칙한 스파이크성 워크로드일 경우에 탄력적 처리량 모드를 사용할 수 있습니다.
  • 탄력적 모드는 워크로드를 처리하기 위해 자동으로 성능을 확장하고 축소하기 때문에, 성능 사용 패턴을 명확하게 정의할 수 없는 워크로드를 위한 좋은 선택 사항이 됩니다.
  • 하지만, 기본 스토리지 사용 용량에 대한 요금과 함께, 실제로 처리된 데이터의 양에 따라 추가적인 성능 비용이 과금이 됩니다. 예를 들어, 300MiBps의 성능으로 5분 동안 쓰기 작업을 수행을 했다면, 300 MiB * 300초 = 90 GiB의 데이터에 대한 성능 비용 요금이 과금되며, AWS 리전 마다 읽기와 쓰기 작업에 대한 요금이 다르기 때문에, Amazon EFS 요금 페이지를 참고하시기 바랍니다.
  • 또한, 높은 처리량 성능을 사용하는 시간의 비율이 높을 경우, 처리된 데이터 용량에 따른 추가적인 성능 비용이 과도하게 과금이 될 수도 있습니다. 일반적으로 성능의 평균 대비 피크 비율이 5% 이하일 경우에 권장을 하며, 5% 를 초과할 수 있는 경우에는 프로비전드 처리량 모드로의 전환도 고려해 보아야 합니다.

EFS 성능 모드(Performance mode)

EFS의 성능 모드는 파일 시스템이 제공할 수 있는 최대 IOPS 처리량을 결정하는 항목입니다. 범용 모드(General purpose)와 최대 I/O 모드(Max I/O)의 두 가지 성능 모드를 제공합니다. 일반적으로 대부분의 워크로드에는 범용 모드를 사용하는 것을 권장합니다. 또한, 성능 모드는 파일 시스템이 생성이 된 후에는, 변경할 수 없으니 명확히 워크로드의 요건을 파악하고 선택하는 것도 중요합니다.

범용 모드(General purpose mode)

작업당 지연 시간이 가장 낮으며 EFS 파일 시스템의 기본 성능 모드입니다. 원존 파일 시스템은 항상 범용 성능 모드를 사용합니다. 더 빠른 성능을 위해 항상 범용 성능 모드를 사용하는 것이 좋습니다. 범용 모드의 최대 IOPS 처리량은 읽기 35,000 ~ 250,000 IOPS와 쓰기 7,000 ~ 50,000 IOPS 까지 제공이 되며, 앞서 살펴본 파일 시스템의 유형과 처리량 모드의 조합에 따라 달라집니다. 따라서, 적절한 조합을 선택하기에 앞서서 Amazon EFS 사용자 가이드의 성능 요약을 참고로 확인하여 보시기 바랍니다.

최대 I/O 모드(Max I/O mode)

범용 모드보다 더 긴 지연 시간을 견딜 수 있고, 수백대 이상의 인스턴스가 파일 시스템을 사용하는, 고도로 병렬화된 워크로드용으로 설계된 이전 세대의 성능 유형입니다. 원존 파일 시스템 또는 탄력적 처리량 모드를 사용하는 파일 시스템에서는 최대 I/O 모드가 지원되지 않습니다. 또한, 지연 시간이 범용 모드보다 더 높기 때문에, 일반적으로 범용 모드의 사용을 권고합니다.

EFS 처리량 및 성능 모드의 조합

지금까지 살펴본 파일 시스템 유형, 스토리지 클래스, 그리고 처리량 모드와 성능 모드를 조합하면, 총 8개의 형태를 사용할 수 있다는 것을 알 수 있으며, 최대 I/O 성능 모드를 제외한 6개의 조합에 대한 요약표는 아래와 같습니다. 이 표는 Amazon EFS 사용자 가이드의 성능 요약Amazon EFS 할당량을 요약한 것입니다. 이 표를 참고하여, 워크로드에서 필요한 MiBps 처리량 성능과 IOPS 처리량 성능을 충족시킬 수 있는 조합을 선택할 수 있습니다. 즉, 워크로드에서 요구되는 성능에 대한 지표들을 명확하게 파악하는 것은 매우 중요합니다.

표 2. Amazon EFS 처리량 및 성능 모드의 조합

올바른 처리량 모드 선택을 위한 비용 계산 예제

[참고 사항] 지금 까지는 용량과 성능의 단위가 Amazon EFS 사용자 가이드를 기반으로 MiB, GiB 또는 TiB를 사용하여 작성이 되었습니다. 비용 계산 예제는 EFS 요금 페이지FAQ가 참조가 되었으며 요금 페이지와 FAQ는 MB, GB, TB 단위로 작성이 되어 있습니다. 그래서, 공식 문서와의 일관성을 유지하기 위하여 비용 계산 예제는 MB, GB의 단위가 사용이 되었으니 참고하여 주시기 바랍니다.

이제 데이터의 용량 및 성능 요구 사항에 따라서, 어떤 파일 시스템을 사용하는것이 적합한 지에 대한, 예제를 알아 보도록 하겠습니다.

  • 이 예제들은 리전 유형, 표준 스토리지 클래스를 사용하며, 파일 시스템의 처리량 모드 또는 구성의 변경이 없이 1개월 동안 사용한 파일 시스템을 가정한 것입니다.
  • 성능 모드는 범용 모드이며, 필요한 IOPS 처리량도 함께 고려하여 선택이 필요합니다.
  • 탄력적 처리량 모드는 읽기 75% 및 쓰기 25% 작업의 비율로 계산이 되었습니다.
  • 비용은 서울 리전 기준이며, 비용 계산에 대한 참고 사항은 Amazon EFS FAQ의 요금 및 결제 항목에서 확인할 수 있습니다.

예제 1: 버스팅 처리량 모드를 선택해야 하는 워크로드

  • 스토리지 사용 용량: 10 TB
  • 필요한 처리량: 일일 8 시간 동안 최대 900 MB/s으로 읽기 또는 쓰기 성능 필요

이러한 경우, 버스팅 처리량 모드를 선택하면 됩니다. “표 1. Amazon EFS 버스팅 처리량 모드 파일 시스템의 동작 예“과 같이, 10 TiB를 사용하는 파일 시스템은, 1,000 MiBps의 처리량 성능으로 최대 12시간 동안 버스팅 할 수 있습니다. 즉, 높은 처리량 성능이 요구되지만, 버스팅 모드의 사용 용량에 따른 버스팅 성능으로, 요구 성능과 지속 시간의 수용이 가능하며 또한 가장 비용 효율적인 선택이 됩니다.

표 3. 버스팅 처리량 모드를 선택해야 하는 워크로드

예제 2: 프로비전드 처리량 모드를 선택해야 하는 워크로드

  • 스토리지 사용 용량: 800GB
  • 필요한 처리량: 일일 8 시간 동안 최대 500 MB/s으로 읽기 또는 쓰기 성능 필요

이 워크로드는, 프로비전드 처리량 모드를 선택하면 됩니다. 사용 용량이 800GB로 크지 않기 때문에, 버스팅 모드에서는 요구되는 성능과 지속시간을 충족할 수 없습니다. 또한, 최대 8시간 동안 지속적으로 성능을 사용하므로, 탄력적 모드는 매우 높은 성능 비용이 발생하게 됩니다. 따라서, 용량과 무관하게 지속적인 성능을 제공하기 위해서는, 프로비전드 모드가 가장 비용 효율적인 선택이 됩니다.

표 4. 프로비전드 처리량 모드를 선택해야 하는 워크로드

예제 3: 탄력적 처리량 모드를 선택해야 하는 워크로드

  • 스토리지 사용 용량: 800GB
  • 필요한 처리량: 일일 1 시간 동안 최대 500 MB/s으로 읽기 또는 쓰기 성능 필요

예제 2와 유사하지만, 이 워크로드는 하루에 최대 1시간만 500 MB/s로 동작을 하면 되는 환경입니다. 버스팅 모드는 요구 성능을 충족시킬 수 없으며, 프로비전드 모드는 과도한 프로비전드 성능 비용이 과금이 될 것입니다. 따라서, 이러한 워크로드는 탄력적 처리량 모드를 선택하면 필요한 성능 요건을 충족시키면서도, 가장 비용 효율적인 선택이 될 것입니다.

표 5. 탄력적 처리량 모드를 선택해야 하는 워크로드

결론

EFS는 워크로드의 비용, 가용성, 성능 요건에 따라서 최적의 파일 시스템을 생성하고 활용할 수 있도록, 다양한 파일 시스템 유형과 스토리지 클래스를 제공합니다. 그리고, 파일 시스템의 요구 성능을 충족시킬 수 있도록, MiBps와 IOPS의 성능 설정을 위한 처리량 및 성능 모드를 제공합니다.
하지만, 적합한 파일 시스템의 유형, 스토리지 클래스, 처리량 및 성능 모드를 선택하지 않을 경우, 워크로드의 성능 지연, 과도한 비용 과금, 또는 데이터의 가용성과 같은 문제가 발생할 수도 있습니다.
즉, 하나의 파일 시스템 구성만으로는 모든 워크로드의 요구 조건을 100% 충족시킬 수는 없기 때문에, 워크로드의 다양한 요구 조건을 명확하게 파악하고 분석하는 것은 매우 중요합니다.
분석된 워크로드 요구 조건을 바탕으로 본 블로그에 소개된 파일 시스템의 유형, 스토리지 클래스, 처리량 및 성능 모드의 특징에 대해서 이해하고, 적절한 조합을 선택하여 사용한다면 용량, 성능, 뿐만 아니라 비용 최적화를 어렵지 않게 실천할 수 있습니다.
마지막으로, 2024년에 새롭게 발표된 EFS의 성능 관련 소식을 소개하여 드리면서 글을 마무리 하겠습니다.

Amazon EFS, 클라이언트당 최대 처리량을 1.5GiB/s로 증가
Amazon EFS, 이제 최대 20GiB/s의 처리량 지원
AWS, Amazon Elastic File System의 더 높아진 읽기 IOPS 발표

SeungYong Baek

SeungYong Baek

백승용 솔루션즈 아키텍트는 다양한 분야의 IT 인프라 스트럭처와 산업군에 대한 엔지니어 경험을 바탕으로, 고객이 AWS 클라우드를 활용하여 비즈니스 성과를 달성할 수 있도록, 고객과 함께 효율적인 아키텍처를 구성하는 역할을 수행하고 있습니다.