AWS EFS의 처리량 모드(Throughput mode)를 정리—언제 Bursting/Elastic/Provisioned를 써야 “예측 가능한 지연”을 만들 수 있을까

• 세 가지 모드: Bursting, Elastic, Provisioned. 각 모드는 파일 시스템이 낼 수 있는 처리량을 결정한다. (AWS Documentation)

• Bursting: 용량(저장 데이터 크기)에 비례한 베이스라인 처리량 + 버스트 크레딧으로 일시 고처리량. 크레딧이 0이 되면 베이스라인으로 급락한다. 작은 용량일수록 베이스라인이 낮아 크레딧 소진 시 지연 변동이 커질 수 있다. (AWS Documentation)

• Elastic: 워크로드 활동에 맞춰 자동으로 처리량을 올리고 내리는 모드(사이징 신경 덜 씀). 기본값인 Bursting과 달리 파일 시스템 크기나 크레딧에 덜 얽매인다. (AWS Documentation)

• Provisioned: 파일 시스템 크기·크레딧과 무관하게 지정한 MiB/s를 항상 보장한다. 처리량 예측이 최우선인 워크로드에 적합하다. CloudFormation에서도 ThroughputMode=provisioned와 ProvisionedThroughputInMibps를 명시한다. (AWS Documentation)

언제 Provisioned가 유리한가?

• 동일 대용량 파일을 동시에 콜드 스타트가 읽는 패턴(예: Lambda 여러 함수의 동시 cold start로 공통 모델/리소스 파일을 EFS에서 읽기)처럼, 짧은 시간에 동시 읽기 피크가 반복되고 지연 예측이 중요한 경우. 이때 Bursting은 크레딧 소진 후 처리량이 베이스라인으로 떨어지며 지연이 흔들릴 수 있지만, Provisioned는 설정한 처리량을 계속 유지한다. (AWS Documentation)

• EFS를 Lambda와 함께 쓰면 /tmp 로컬 디스크보다는 느리지만(수 ms~수십 ms 레이턴시), S3보다 일관성과 동시 접근에서 이점이 있어, 필요한 처리량을 Provisioned로 고정하면 피크 시 지연 분산을 줄이는 데 도움이 된다. (Lumigo)

빠른 선택 가이드

• 작고 드문 I/O + 비용 최적: Bursting → 먼저 시작해 보고, BurstCreditBalance가 자주 0에 근접하면 재검토. (New Relic Documentation)

• 패턴이 들쭉날쭉하나 자동 스케일 원함: Elastic. 운영 단순화에 유리. (AWS Documentation)

• 피크에도 지연 예측이 최우선(모델/에셋 동시 읽기, 미디어 트랜스코딩 허브 등): Provisioned로 필요한 MiB/s를 산정해 설정. 필요 시 나중에 모드 전환·수치 조정 가능. (AWS Documentation)