EC2(Elastic Compute Cloud) 웹 서비스를 통해 제공되는 다양한 클라우드 서비스와 관련하여 Amazon이 선두주자라는 데는 의심의 여지가 없습니다. 상대적으로 간단한 프로비저닝 프로세스와 인스턴스 및 스토리지 요구 사항을 쉽게 확장 또는 축소할 수 있는 기능을 통해 EC2는 클라우드의 모든 가능성을 비용 효율적인 가격대로 제공하는 것을 목표로 합니다. 그러나 일부 사람들에게 클라우드는 유연성과 배포 용이성에 관한 것이 아닙니다. 성능에 관한 것입니다. 분석과 같은 중요한 애플리케이션을 위해 강력한 환경을 가동 또는 가동 중지할 수 있는 비즈니스 이점은 종종 CAPEX의 장기 투자 대신 OPEX를 통해 그렇게 하는 비용보다 훨씬 클 수 있습니다. 이를 위해 Amazon은 3월에 기본 서버의 CPU 및 메모리 리소스에 대한 직접 액세스를 제공하는 iXNUMX 베어 메탈 인스턴스 제품군을 GA했습니다.
EC2(Elastic Compute Cloud) 웹 서비스를 통해 제공되는 다양한 클라우드 서비스와 관련하여 Amazon이 선두주자라는 데는 의심의 여지가 없습니다. 상대적으로 간단한 프로비저닝 프로세스와 인스턴스 및 스토리지 요구 사항을 쉽게 확장 또는 축소할 수 있는 기능을 통해 EC2는 클라우드의 모든 가능성을 비용 효율적인 가격대로 제공하는 것을 목표로 합니다. 그러나 일부 사람들에게 클라우드는 유연성과 배포 용이성에 관한 것이 아닙니다. 성능에 관한 것입니다. 분석과 같은 중요한 애플리케이션을 위해 강력한 환경을 가동 또는 가동 중지할 수 있는 비즈니스 이점은 종종 CAPEX의 장기 투자 대신 OPEX를 통해 그렇게 하는 비용보다 훨씬 클 수 있습니다. 이를 위해 Amazon은 3월에 기본 서버의 CPU 및 메모리 리소스에 대한 직접 액세스를 제공하는 iXNUMX 베어 메탈 인스턴스 제품군을 GA했습니다.
i3.metal 인스턴스는 "EC2 인스턴스에 고성능 네트워킹 및 스토리지 리소스를 안전하게 제공"하는 AWS 구축 하드웨어 오프로드 및 서버 보호 구성 요소 모음인 Nitro 시스템에 구축됩니다. i3.metal 인스턴스는 또한 이 검토의 일부로 활용한 EBS(Elastic Block Store)와 같은 AWS 클라우드가 제공하는 다른 모든 서비스를 활용합니다. 또한 이 인스턴스는 최대 15.2TB의 NVMe SSD 지원 인스턴스 스토리지와 2.3개의 하이퍼 스레드 코어(36개의 논리적 프로세서) 및 72GiB의 메모리를 제공하는 512GHz Intel Xeon 프로세서를 갖추고 있습니다. 패브릭 측면에서 i3.metal 인스턴스는 최대 25Gbps의 총 네트워크 대역폭을 제공하여 ENA(Elastic Network Adapter) 기반 향상된 네트워킹을 통해 높은 네트워킹 처리량과 짧은 지연 시간을 제공합니다.
EC2에는 여러 인스턴스 유형이 있습니다. i3 인스턴스는 "스토리지 최적화" 범주에 속하며 i3.metal 인스턴스는 맨틀을 해당 그룹의 최고 성능으로 간주합니다. 아래 표는 인스턴스 유형의 패밀리 및 구성을 강조 표시합니다.
| 모델 | vCPU | 메모리(GiB) | 네트워킹 성능 | 스토리지(TB) |
| i3.대형 | 2 | 15.25 | 최대 10기가비트 | 1 NVMe SSD 0.475개 |
| i3.xlarge | 4 | 30.5 | 최대 10기가비트 | 1 NVMe SSD 0.95개 |
| i3.2xlarge | 8 | 61 | 최대 10기가비트 | 1 NVMe SSD 1.9개 |
| i3.4xlarge | 16 | 122 | 최대 10기가비트 | 2 NVMe SSD 1.9개 |
| i3.8xlarge | 32 | 244 | 10 기가비트 | 4 NVMe SSD 1.9개 |
| i3.16xlarge | 64 | 488 | 25 기가비트 | 8 NVMe SSD 1.9개 |
| i3.메탈 | 72 | 512 | 25 기가비트 | 8 NVMe SSD 1.9개 |
i3.metal 인스턴스는 AWS 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤), 유럽(프랑크푸르트) 및 유럽(아일랜드) 리전에서 사용할 수 있으며 온디맨드 인스턴스로 구매할 수 있습니다. 예약 인스턴스(3년, 1년 및 컨버터블) 또는 스팟 인스턴스. 이 검토의 목적을 위해 우리는 북버지니아 지역에서 테스트했습니다. NVMe 스토리지와 EBS 블록 볼륨을 모두 테스트했습니다.
퍼포먼스
VDBench 워크로드 분석
EC2 i3.metal 인스턴스의 성능을 평가하기 위해 로컬에 설치된 VDBench를 활용하여 EBS(30x1TB) 및 NVMe(8×1.7TB) 스토리지를 모두 테스트했습니다. 두 스토리지 유형 모두에서 각 장치의 12%를 할당하고 함께 그룹화하여 적당한 양의 데이터 지역성과 함께 최고 시스템 성능을 살펴보았습니다.
이러한 워크로드는 "포 코너" 테스트, 공통 데이터베이스 전송 크기 테스트, 다양한 VDI 환경의 트레이스 캡처에 이르는 다양한 테스트 프로필을 제공합니다. 이러한 모든 테스트는 스크립팅 엔진과 함께 공통 vdBench 워크로드 생성기를 활용하여 대규모 컴퓨팅 테스트 클러스터에서 결과를 자동화하고 캡처합니다. 이를 통해 플래시 어레이 및 개별 스토리지 장치를 포함한 광범위한 스토리지 장치에서 동일한 워크로드를 반복할 수 있습니다.
프로필 :
- 4K 임의 읽기: 100% 읽기, 128 스레드, 0-120% iorate
- 4K 임의 쓰기: 100% 쓰기, 64 스레드, 0-120% iorate
- 64K 순차 읽기: 100% 읽기, 16개 스레드, 0-120% iorate
- 64K 순차 쓰기: 100% 쓰기, 8개 스레드, 0-120% 속도
- 합성 데이터베이스: SQL 및 Oracle
- VDI 연결된 클론 추적
이 리뷰에서는 EBS와 NVMe를 모두 살펴봅니다. 극적인 성능 차이가 있기 때문에 결과를 두 개의 차트로 분리했습니다(대기 시간이 너무 멀어서 차트를 읽기가 매우 어렵습니다).
첫 번째 테스트는 4K 랜덤 읽기를 살펴봅니다. 여기에서 EBS 인스턴스는 끝까지 지연 시간이 밀리초 미만이었습니다. 약 64K IOPS에서 59.46 IOPS의 성능으로 대기 시간이 64,047ms로 급증했습니다.
NVMe 4K 피크 임의 읽기를 보면 인스턴스가 훨씬 더 잘 수행되는 것을 볼 수 있습니다. 인스턴스는 2,802,904μs의 지연 시간과 함께 348 IOPS로 정점을 찍었습니다.
EBS를 사용한 4K 임의 쓰기는 EBS를 사용한 4K 읽기와 거의 동일했습니다. 인스턴스는 1ms 더 일찍 중단되어 약 60K IOPS였으며 지연 시간은 64,003ms로 29.97 IOPS로 정점에 도달했습니다.
인스턴스의 NVMe 버전의 경우 지연 시간이 약간 급증했지만 여전히 1ms 미만이었습니다. 인스턴스는 920,975μs의 지연 시간과 함께 545 IOPS로 정점을 찍었습니다.
순차 테스트로 전환하여 EBS 64K 최고 읽기 성능을 위해 인스턴스의 지연 시간은 약 70K IOPS 또는 약 450MB/s까지 밀리초 미만이었고 최대 지연 시간은 17,360ms인 1.08 IOPS 또는 27.65GB/s였습니다.
NVMe를 사용한 64K 순차 읽기는 244,037μs의 대기 시간으로 15.25 IOPS 또는 514GB/s의 최고 성능을 제공했습니다.
EBS를 사용한 64K 쓰기에서 인스턴스는 1ms 이상에서 시작하여 17,359ms의 지연 시간과 함께 1.08 IOPS 또는 13.8GB/s로 정점을 찍었습니다.
64K 순차 쓰기는 NVMe 인스턴스가 1ms를 넘는 것을 처음으로 본 것입니다. 인스턴스는 58,572ms의 지연 시간과 함께 3.66 IOPS 또는 1.08GB/s로 정점을 찍었습니다.
SQL 워크로드로 전환한 EBS 인스턴스는 약 55K IOPS까지 밀리초 미만의 지연 시간 성능을 보였고 지연 시간은 64,036ms로 최고 14.93 IOPS였습니다.
인스턴스의 NVMe 버전의 경우 SQL 테스트에 대해 834,231μs의 대기 시간과 함께 302 IOPS의 최고 성능을 확인했습니다.
EBS를 사용하는 SQL 90-10의 경우 인스턴스는 다시 약 1K IOPS의 55ms 지연 시간을 중단하고 64,036ms 지연 시간의 14.99 IOPS에서 정점에 도달했습니다.
SQL 90-10에 있는 인스턴스의 NVMe 버전은 최고 성능이 605,150 IOPS이고 대기 시간이 415μs였습니다.
EBS가 포함된 SQL 80-20은 다시 밀리초 미만의 지연 시간이 약 55K IOPS로 끝나고 최대 64,036 IOPS와 14.93ms 지연 시간으로 거의 동일한 수치를 제공했습니다.
NVMe가 포함된 SQL 80-20은 인스턴스 적중 횟수가 511,840 IOPS이고 대기 시간이 493μs였습니다.
EBS에 대한 Oracle 테스트는 거의 동일한 수치의 동일한 홀수 피크 성능을 보여주었습니다. Oracle의 경우 인스턴스는 64,036ms의 대기 시간으로 13.6 IOPS를 기록했습니다. 인스턴스는 약 55K IOPS까지 지연 시간 성능이 밀리초 미만이었습니다.
NVMe를 사용하는 인스턴스는 Oracle 테스트에서 457,372μs의 대기 시간으로 613 IOPS를 기록했습니다.
Oracle 90-10은 64,035ms의 대기 시간과 함께 10.3 IOPS에서 EBS 인스턴스 피크를 보였습니다. 인스턴스는 약 1K IOPS에서 55ms를 중단했습니다.
Oracle 90-10 인스턴스의 NVMe 버전은 520,448μs의 대기 시간으로 333 IOPS를 달성할 수 있었습니다.
Oracle 80-20은 EBS가 약 1K IOPS에서 55ms를 중단하고 지연 시간이 64,036ms인 10.3 IOPS에서 피크를 기록했습니다.
NVMe가 있는 인스턴스는 435,265μs의 지연 시간과 함께 400 IOPS의 최고 성능을 보였습니다.
다음으로 VDI Linked Clone(LC) 테스트를 살펴봅니다. Boot에서 시작하여 인스턴스의 EBS 버전은 약 35K IOPS까지 지연 시간이 밀리초 미만이었고 최대 지연 시간은 42,893ms인 11.2 IOPS였습니다.
인스턴스의 NVMe 버전은 VDI LC 부팅 테스트에서 349,799 IOPS와 363μs의 지연 시간으로 정점을 찍을 수 있었습니다.
VDI LC 초기 로그인의 경우 EBS 인스턴스는 약 1K IOPS로 떨어지기 전에 얼마 동안 31ms 라인을 걸었습니다. 인스턴스는 최고 34,486 IOPS 및 6.95ms 지연 시간을 기록했습니다.
VDI LC 초기 로그인을 통해 NVMe 인스턴스는 93,405μs의 대기 시간과 함께 677 IOPS로 정점을 찍었습니다.
VDI LC 월요일 로그인을 사용하면 EBS 인스턴스가 다시 한 번 1ms로 시시덕거린 후 약 25K IOPS로 급락한 후 34,643ms의 대기 시간으로 13.85 IOPS에서 정점에 도달했습니다.
마지막으로 NVMe를 사용한 VDI LC 월요일 로그인은 119,615ms의 대기 시간과 함께 1.1 IOPS에서 인스턴스 최고치를 기록했습니다.
결론
Amazon의 클라우드 서비스는 일반적으로 가장 다재다능한 것으로 간주됩니다. 컴퓨팅과 스토리지는 확실히 다양하지만 Amazon에는 성능 옵션도 있습니다. Amazon은 i2 베어 메탈 인스턴스를 포함하여 EC3 웹 서비스에서 다양한 성능 옵션을 제공합니다. 이러한 인스턴스는 특별히 제작된 하드웨어 및 소프트웨어의 AWS Nitro 시스템을 활용합니다. i3.metal 인스턴스는 CPU 및 메모리에 대한 직접 액세스를 통해 더 나은 성능을 제공하는 동시에 사용자에게 AWS EBS 연결 스토리지 및 로컬 NVMe 스토리지와 같은 다른 기능을 활용할 수 있는 기능을 제공합니다.
성능을 위해 블록 스토리지(EBS)와 NVMe를 모두 테스트했습니다. 이것은 독자들에게 옵션 측면에서 무엇을 기대해야 하는지에 대한 아이디어를 제공하기 위한 것이며, 둘 중 하나가 다른 것보다 낫습니다(일반적으로 NVMe 스토리지는 성능이 더 좋고 대기 시간이 훨씬 낮기 때문에 두 세트의 차트가 있습니다). EBS를 살펴보면 인스턴스가 1ms를 초과한 후 얼마 지나지 않아 대기 시간이 증가하고 완료되는 패턴을 볼 수 있었습니다. 테스트 내내 EBS는 EBS에 허용되는 최대값인 약 64K IOPS로 정점을 찍었습니다. 여기에는 4K 테스트와 세 가지 SQL 및 Oracle 테스트가 모두 포함되었습니다. VDI 테스트를 위해 인스턴스가 약간 느려졌습니다. Amazon은 규정된 64K 이상의 IOPS를 달성하기 위해 설정을 조정할 수 있음을 나타내지만, 이를 달성하기 위한 프로세스는 대부분의 고객이 경험할 수 있는 것이 아니므로 이 경로를 따르지 않았습니다.
NVMe 테스트의 경우 일반 벤치마크와 더 일치하는 결과를 확인했습니다. 여기서 하이라이트는 4만 IOPS의 임의 2.8K 읽기 성능, 4K IOPS의 920K 쓰기, 64GB/s의 15.25K 읽기 및 세 가지 테스트 모두에서 500K IOPS 이상의 SQL 성능(SQL 테스트는 약 834K IOPS임)을 포함했습니다. Oracle 테스트도 NVMe에서 435K IOPS에서 520K IOPS 사이의 결과로 강력한 결과를 보였습니다. VDI Linked Clone은 약 350K IOPS의 강력한 부팅 성능을 보여주었습니다. 여기서 유일한 실망은 고객이 i3.metal 인스턴스에서 더 많은 로컬 NVMe를 선택할 수 없다는 것입니다.
전반적으로 i3.metal 인스턴스는 Amazon이 약속한 것과 정확히 일치했습니다. 이는 약속된 서비스 수준을 받을 것인지 알고 싶어하는 고객에게 안심이 됩니다. 물론 이것은 비용이 들지 않는 것은 아닙니다. 모든 클라우드 배포와 마찬가지로 문제는 사용 용이성과 클라우드 대 다른 클라우드 공급자 대 온프레미스의 결과에 관한 것입니다. 즉, 더 낮은 IOPS 수준으로 처리할 수 있는 워크로드가 있는 고객은 상당한 비용을 절약할 수 있습니다. 그러나 실제로는 특정 인스턴스에 대한 궁극적인 요구 사항이 무엇인지에 달려 있습니다. 이를 위해 i3.metal 인스턴스는 i3.metal이 제공하는 성능 제한을 초과하지 않거나 초과할 수 없고 온프레미스의 올플래시 어레이가 제공하는 IOPS가 필요하지 않은 주류 애플리케이션에 적합합니다. 사례. 또한 이미 Amazon 제품군에 속해 있는 경우 베어 메탈로의 이동이 익숙하며 여러 AWS 프로그램을 대량으로 사용하는 동안 비용 이점이 있을 수 있습니다.
