여기서 다루는 내용
· 들어가며
· EFS의 2가지 Throughput Mode 옵션
· Bursting 옵션 동작 방식
· Provisioned 옵션으로의 전환 및 테스트 결과
· 과금 및 결론
EFS 서비스는 만능인가?
안녕하십니까, GS네오텍 최준승입니다.
그토록 기다리던 EFS 서비스가 서울 리전에 런칭된지 어느덧 두달이 되었습니다.
동시에 제가 준비했던 EFS 성능 포스팅도 두달이 묵었습니다. 맘은 불편하고. 테스트 설계는 점점 복잡해져만 갑니다.
성능이 좀 문제가 될수도 있겠다. 라는 결론을 내려고 했는데 그 와중에 Provisioned 쓰루풋이라는 성능 옵션이 새로 생겼네요.
글을 다시 쓰기로 했습니다. 이번에는 EFS 기본 성능보다는 가급적 새로운 성능 옵션에 집중해서 썰을 풀려고 합니다.
다시 처음으로 돌아와서. EFS 서비스는 사용자 관점에서 꽤나 많은 장점을 갖고 있습니다.
- 초기 구성이 쉽고
- 용량을 사전에 프로비저닝할 필요가 없으며
- 범용적인 NFS 프로토콜을 사용하고
- 관리 이슈가 적습니다
하지만 삶이 그렇듯 모든게 완벽할 수 있나요?
EFS에도 단점이 있었으니, 일정 조건에서 읽기/쓰기 성능이 급격히 저하되는 현상이 종종 있었습니다.
이것은 서비스가 잘못 만들어진 것이 아니라. Bursting 방식으로 동작하는 성능 구조상 근본적으로 어쩔 수 없는 부분이었죠.
대체 무슨 말인지 잘 이해가 안가신다구요?
그럼 일단 EFS가 어떤 방식의 성능 모델을 갖고 있는지부터 함께 살펴 보겠습니다.
파일 시스템 생성시 Throughput Mode?
자, 나는 지금 EFS 서비스에서 파일 시스템을 하나 만들려고 합니다.
STEP1에서는 파일시스템이 구성될 VPC와 Subnet, Security Group 등을 먼저 선택합니다.
그리고 STEP2에서 아래 옵션들이 등장하죠.
※ EFS 파일 시스템을 처음 생성할때 선택하는 옵션들. Performance Mode와 Throughput Mode를 각각 선택해야 한다
Performance 항목은 오늘의 주제가 아니라 자세히 다루지 않으려 합니다.
설명서상으로는 일반 환경에서는 General Purpose를 선택하면 되고.
붙이는 Client 수가 상대적으로 많은 경우에는 레이턴시를 좀 손해보더라도 Max I/O를 선택하라고 되어 있습니다. 끝.
오늘의 핵심 주제는 Throughput Mode 입니다.
얼마전까지는 Bursting 모드밖에 없었기 때문에 딱히 선택할 것이 없었고.
이번 `18년 7월부터 Provisioned Throughput 모드가 새로 생겨서 선택지가 2개가 되었습니다. 쟈잔..
AWS 설명서에는 어떻게 적혀 있나 한번 볼까요?
- With Bursting Throughput mode
→ throughput on Amazon EFS scales as your file system grows
- With Provisioned Throughput mode
→ you can instantly provision the throughput of your file system (in MiB/s) independent of the amount of data stored
아하. 핵심은 이겁니다.
Bursting 모드는
"저장된 용량 기반"으로 쓰루풋이 나오고
Provisioned 모드는 저장된 용량 기반과 독립적으로
"직접 설정한 쓰루풋"만큼 성능이 나온다
그럼 이번에는 기존 Bursting 모드의 동작방식을 좀 더 구체적으로 살펴봐야 겠군요!
EFS의 Bursting 옵션 살펴보기
버스팅이라는 개념은. AWS에서 유난히 많이 등장합니다.
T2 인스턴스의 CPU 성능에서도 나오고 GP2 타입의 EBS 성능에서도 나오고. 또 몇개 더 있는데.. 암튼 자주 나옵니다.
Bursting 이란 단어는 몇가지 의미를 동시에 내포하고 있는데 제 기준에서 3줄로 요약하면 다음과 같습니다.
- 기본 성능은 정해져 있다
- 일정 조건에서 제한적인 시간에 성능이 향상(Bursting)되어 동작한다
- 제한적인 시간을 결정하는 요소는 잔여 Credit과 현재 사용량
EFS의 Bursting 모드도 여기서 크게 벗어나지 않습니다.
- 기본 Throughput 성능은 정해져 있다. 단, 이 값은 "저장된 용량값"에 종속적이다.
- 일정 조건에서 제한적인 시간에 성능이 향상(Bursting)되어 동작한다.
- Bursting은 언제까지? Credit이 다 없어질때까지.
모든 정보는
설명서에 적혀있습니다. 관심있으시면 링크 걸려있으니 참고하시구요.
저장된 용량에 따라 기본성능은 어떻게 되고 뻐스팅은 어느범위까지 되는지 정리된 예시표는 다음과 같습니다.
계산식은 좀 복잡해서 설명을 줄이구요. 그냥 용량이 커질수록 기본 성능과 버스팅 성능이 비례해서 커진다. 정도로 이해하시면 OK.
[table id=15 /]
자, 이제 실제 예시를 봅시다. 제 실험 설계는 다음과 같습니다.
- STEP1: 최초 환경에서 Bursting 성능을 측정한다
- STEP2: 인위적으로 Credit을 오링내서, Bursting이 제공되지 않는 환경의 기본성능을 측정한다
- STEP3: 파일 시스템의 쓰루풋 모드를 Bursting 에서 Provisioned로 변경한 후, 성능을 재측정한다
이제 얼마 남지 않았습니다. 다음장에서 결과를 확인해 보시죠.
테스트 결과
테스트는 아래 환경에서 진행되었습니다.
- Region: Seoul
- Benchmark Tool: fio v2.14
- Command: sudo fio --directory=/home/ec2-user/efs --name fio_test_file --direct=1 --rw=randread --bs=16k --size=1G --numjobs=16 --time_based --runtime=60 --group_reporting --norandommap
테스트를 하기 위해 파일시스템을 하나 만들었습니다. 처음에 파일 시스템을 만들면 2.1TiB라는 기본 Credit을 제공한다고 하네요.
이 Credit을 임의로 오링시키기 위해 EC2 인스턴스 4대를 준비했습니다.
※ 크레딧 오링을 위한 오링군단.. 모두 동일한 파일시스템에 마운트하고.. 읽기/쓰기 작업을 몇시간동안 반복시켰다.
일단 Credit이 오링나기 전에 기본 성능을 한번 측정해봅시다.
파라미터가 좀 많은데 랜덤-읽기 작업을 기준으로 16개의 쓰레드를 만들어 테스트를 돌렸습니다.
fio-2.14
Starting 16 processes
Jobs: 16 (f=16): [r(16)] [100.0% done] [92096KB/0KB/0KB /s] [5756/0/0 iops] [eta 00m:00s]
[중략]
Run status group 0 (all jobs):
READ: io=5493.7MB, aggrb=93752KB/s, minb=93752KB/s, maxb=93752KB/s, mint=60004msec, maxt=60004msec
설명서대로 Bursting이 동작하면서, 100MB/s에 좀 못미치는 쓰루풋이 나왔습니다. 여기까지가 STEP1입니다.
이제 STEP2로 Credit을 오링시킬 차례입니다. 길고 지루한 작업이었습니다.
※ 3시간반동안 4대의 Client에서 읽기/쓰기를 반복하니 초기 Credit이 모두 소모되었다
이제 더이상 버스팅이 불가능한 환경에서의 성능값을 동일한 방법으로 측정해 보았습니다.
fio-2.14
Starting 16 processes
Jobs: 12 (f=12): [f(6),_(1),f(1),_(2),f(2),_(1),f(3)] [100.0% done] [256KB/0KB/0KB /s] [16/0/0 iops] [eta 00m:00s]
[중략]
Run status group 0 (all jobs):
READ: io=16048KB, aggrb=263KB/s, minb=263KB/s, maxb=263KB/s, mint=60837msec, maxt=60837msec
예상한대로, 1MB/s도 안되는 읽기 쓰루풋이 나왔습니다. 저장된 데이터가 얼마 없다보니 기본 성능이 낮게 나오는 셈입니다.
이게 만약 웹서버에서 제공하는 이미지였다? 그럼 아마도 꽤나 응답이 느렸을겁니다.
이번엔 STEP3 단계로 갑시다. 다행스럽게도 EFS는 최초 생성 이후에도 Throughtput 모드를 변경할 수 있습니다.
※ Bursting에서 Provisioned로 변경, 100MiB/s를 설정. 예상비용은 월 660달라라고 한다.
※ Throughput 모드 변경중..
※ 변경이 완료되었다. 변경에 걸린 시간은 불과 15초
자, 이제 마지막 측정값은 다음과 같습니다.
fio-2.14
Starting 16 processes
Jobs: 16 (f=16): [r(16)] [100.0% done] [68656KB/0KB/0KB /s] [4291/0/0 iops] [eta 00m:00s]
[중략]
Run status group 0 (all jobs):
READ: io=4049.4MB, aggrb=69097KB/s, minb=69097KB/s, maxb=69097KB/s, mint=60010msec, maxt=60010msec
약 70MB/s 정도의 읽기 성능이 나왔습니다. 다른 클라이언트가 아직 붙어있는게 있었는지. 예상보다 좀 덜 나왔네요.
확실한건 크레딧이 오링난 상태에서 원하는 수준의 성능이 나왔다는 것입니다. 역시 돈내니까 쾌적하네요.
마치며
이제 마무리하겠습니다.
위 설정 화면에서 보셨던 것처럼 Provisioned 옵션을 선택하게 되면 설정한 값에 비례해서 추가 과금이 됩니다.
계산 방식이 좀 복잡하긴 한데, 생략하면 성능 1MB/s를 향상시킬때마다 월 7천원정도가 더든다고 생각하시면 됩니다.
문제는 반드시 이 옵션이 필요한가? 에 대한 판단이 필요하다는 것입니다.
만약 Bursting 옵션에서 실제 Credit이 줄어들지 않고 증가하는 환경이라면? 필요 없겠죠. 버스팅 잘되고. 그정도 성능이 충분하다면.
만약 Credit이 줄어들고는 있지만 그 경사도가 완만하다면? Provisioned 옵션의 설정값을 최소화해서 비용도 최소화할 수 있습니다.
예전에 Provisioned 옵션이 없었을때. 성능에 대한 해결책은.
어쨌든 Busting 옵션은 저장된 용량 기반이니까. 거대한 Dummy 파일을 EFS에 넣고. 기본 성능을 최대한 올려 쓰는 것이었습니다.
물론 지금도 그렇게 해도 되지만. 훨씬 간단한 해결책이 생긴 셈입니다.
최소한 여러분이 지금 EFS를 사용중이시고, 기존 Bursting 옵션을 사용중이시라면.
CloudWatch 서비스에서 EFS ▷ "BurstCreditBalance" 메트릭 값의 경사도를 한번 살펴보시는게 어떨까요?
그럼 마치겠습니다. 끝!
