AWS Storage Gateway는 IDC 혹은 AWS EC2 간 스토리지(EBS)를 S3와 연동하여 하이브리드 형태로 사용할 수 있는 서비스입니다.
지원되는 프로토콜은 NFS(파일게이트웨이), iSCSI(볼륨 게이트웨이), VTL(테이프 게이트웨이)가 있습니다. 데이터 백업 및 데이터 S3 이전 용도로 사용합니다. 구성은 document에 설명이 잘 되어있습니다. Web Console을 통해 Cache 디스크 및 권한 관리 등을 설정할 수 있습니다.
(Document - https://d0.awsstatic.com/whitepapers/aws-storage-gateway-file-gateway-for-hybrid-architectures.pdf)
File Gateway(EC2) 내 OS는 직접 접근할 수 없습니다. 따라서 HA구성은 제약이 있을 듯 합니다.
FAQ를 보면 Gateway 2EA -> S3 구성의 경우도 데이터 정합성을 보장하지는 못한다고 되어 있습니다.
이번 블로깅은 파일 게이트웨이의 성능 테스트 결과입니다.
AWS EC2(NFS Client) - EC2(File Gateway) - S3 구성으로 S3를 이용하여 NFS 프로토콜을 사용하는 형태입니다.
참고로 File Gateway는 자동적으로 File Read 시 Caching이 되는 것을 알아야 한다. (동일 네임으로 업데이트 후 Raed 시 반영이 안 될 수도 있음)
환경:
EC2(NFS Client) - m4.2xlarge(EBS GP2 1000GiB_3000 IOPS)
EC2(File Gateway) - m4.2xlarge(EBS GP2 1000GiB_3000IOPS / Caching Disk)
CPU, DISK, Network Bottleneck을 우회하기 위해 더 좋은 성능의 EC2 Type(m4.10xlarge)을 이용해도 동일한 결과를 확인할 수 있었습니다. 일반적인 디스크 HHD SATA/SAS 성능 보다는 높으나, SSD보다는 떨어지는 성능.
대략 최대 read IOPS 3000 이상, write IOPS 250~350 정도의 수치의 결과를 얻을 수 있었습니다. write 시에 비동기적으로 S3에 저장되어도 어떤 구간?에서 한계가 있는 듯 보입니다.
Case Open을 해도 수치에 대한 명확한 답은 제시해주지 않는다.
You can see faster performance on a standalone NFS server over File Gateway, however even with a standalone NFS server you would not be able to achieve the fast low level random access you would see with a block level local device.
One reason you would see a difference in performance from a standalone NFS server vs File Gateway is that File Gateway is an S3 interpolation layer for NFS where NFS calls are transcribed to S3 calls. As the File Gateway is interpreting between NFS and S3 operations there would be more levels of complexity running in the service than on a standard Linux NFS server.
또한 Storage Gateway 를 통하지 않고, 바로 S3에 오브젝트를 업로드 한 경우 EC2 내의 파일시스템에서는 해당 오브젝트를 확인할 수 없다.
이 경우 Storage Gateway에서 Refresh를 적용해주면 확인 가능하다.
감사합니다.