기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
EBS 볼륨 벤치마킹
I/O 워크로드를 시뮬레이션하여 Amazon EBS 볼륨의 성능을 테스트할 수 있습니다. 프로세스는 다음과 같습니다.
-
EBS에 최적화된 인스턴스 시작.
-
새 EBS 볼륨을 생성합니다.
-
EBS에 최적화된 인스턴스에 볼륨 추가.
-
블록 디바이스를 구성하고 마운트합니다.
-
I/O 성능 벤치마크를 위한 도구 설치.
-
볼륨의 I/O 성능 벤치마크.
-
요금이 계속 발생하지 않도록 볼륨 삭제 및 인스턴스 종료.
중요
일부 절차를 수행할 경우 자신이 벤치마크하는 EBS 볼륨에 있는 기존 데이터가 소멸되는 결과를 낳게 됩니다. 벤치마킹 절차는 프로덕션 볼륨이 아니라 테스트 목적으로 특별히 생성된 볼륨에 적용하기 위한 것입니다.
인스턴스 설정
EBS 볼륨에서 최적의 성능을 얻으려면 EBS에 최적화된 인스턴스를 사용하는 것이 좋습니다. EBS에 최적화된 인스턴스는 인스턴스와 함께 Amazon EC2와 Amazon EBS 사이의 전용 처리량을 제공합니다. EBS에 최적화된 인스턴스는 Amazon EC2 ~ Amazon EBS 간에 전용 대역폭을 전송하며, 인스턴스 유형에 따라 지정할 수 있습니다.
EBS 최적화 인스턴스를 생성하려면 Amazon EC2 콘솔을 사용하여 인스턴스를 시작할 때 EBS 최적화 인스턴스로 시작을 선택하거나 명령줄을 사용할 때 --ebs-optimized를 지정합니다. 이 옵션이 지원되는 인스턴스 유형을 선택해야 합니다.
Provisioned IOPS SSD 또는 범용 SSD 볼륨 설정
Amazon EC2 콘솔을 사용하여 프로비저닝된 IOPS SSD(io1
및 io2
) 또는 범용 SSD(gp2
및 gp3
) 볼륨을 생성하려면 [볼륨 유형(Volume type)]에서 [프로비저닝된 IOPS SSD(io1)(Provisioned IOPS SSD (io1))], [프로비저닝된 IOPS SSD(io2)(Provisioned IOPS SSD (io2))], [범용 SSD(gp2)(General Purpose SSD (gp2))] 또는 [범용 SSD(gp3)(General Purpose SSD (gp3))]를 선택합니다. 명령줄에서 io1
파라미터에 대해 io2
, gp2
, gp3
또는 --volume-type을 지정합니다. io1
, io2
및 gp3
볼륨의 경우 --iops 파라미터에 대한 IOPS(초당 I/O 작업) 수를 지정합니다. 자세한 내용은 Amazon EBS 볼륨 유형 및 Amazon EBS 볼륨 생성 섹션을 참조하세요.
(Linux 인스턴스에만 해당) 예시 테스트의 경우 6개의 볼륨이 있는 RAID 0 어레이를 생성하는 것이 좋습니다. 이 어레이는 높은 수준의 성능을 제공합니다. 볼륨 수가 아닌 프로비저닝된 기가바이트와 io1, io2 및 gp3 볼륨에 대해 프로비저닝된 IOPS 수를 기준으로 요금이 부과되므로, 여러 개의 작은 볼륨을 생성하고 볼륨을 사용하여 스트라이프 세트를 생성하는 데 드는 추가 비용은 없습니다. Oracle Orion을 사용하여 볼륨을 벤치마크하는 경우 Oracle ASM과 동일한 방법으로 스트라이프를 시뮬레이트할 수 있으므로 Orion을 사용하여 스트라이프를 수행하는 것이 좋습니다. 다른 벤치마크 도구를 사용하는 경우 볼륨을 직접 스트라이프해야 합니다.
RAID 0 어레이 생성 방법에 대한 자세한 내용은 RAID 0 어레이 생성 섹션을 참조하세요.
처리량 최적화 HDD(st1
) 또는 콜드 HDD(sc1
) 볼륨 설정
st1
볼륨을 생성하려면 Amazon EC2 콘솔을 사용하여 볼륨을 생성할 때 처리량 최적화 HDD를 선택하거나 명령줄을 사용할 때 --type st1
을 지정합니다. sc1
볼륨을 생성하려면 Amazon EC2 콘솔을 사용하여 볼륨을 생성할 때 콜드 HDD를 선택하거나 명령줄을 사용할 때 --type sc1
을 지정합니다. EBS 볼륨 생성에 대한 자세한 내용은 Amazon EBS 볼륨 생성 섹션을 참조하세요. 인스턴스에 이러한 볼륨 연결에 대한 자세한 내용은 인스턴스에 Amazon EBS 볼륨 연결 섹션을 참조하세요.
(Linux 인스턴스만 해당) AWS 에서는 함께 사용할 JSON 템플릿을 제공하여 AWS CloudFormation 이 설정 절차를 간소화합니다. 템플릿에st1
평가하기 위한 성능 테스트 환경을 설정하는 더 쉬운 방법을 제공합니다. 템플릿은 현재 세대 인스턴스와 2TiB st1
볼륨을 생성하고, /dev/xvdf
에서 볼륨을 인스턴스에 연결합니다.
(Linux 인스턴스에만 해당) 템플릿을 사용하여 HDD 볼륨을 생성하는 방법
https://console.aws.amazon.com/cloudformation
에서 AWS CloudFormation 콘솔을 엽니다. -
스택 생성을 선택합니다.
-
Amazon S3에 템플릿 업로드를 선택하고 이전에 얻은 JSON 템플릿을 선택합니다.
-
스택에 "ebs-perf-testing" 같은 이름을 붙이고 인스턴스 유형(기본은 r3.8xlarge)과 SSH 키를 선택합니다.
-
다음을 두 번 선택한 다음, 스택 생성을 선택합니다.
-
새로운 스택의 상태가 CREATE_IN_PROGRESS에서 COMPLETE로 전환된 후에 [출력(Outputs)]을 선택하여 새 인스턴스의 퍼블릭 DNS 항목을 가져옵니다. 새 인스턴스에는 2TiB
st1
볼륨이 연결됩니다. -
이전 단계의 DNS 항목에서 얻은 호스트 이름을 통해 SSH를 사용하여
ec2-user
라는 사용자로 새로운 스택에 연결합니다. -
벤치마크 도구 설치 항목으로 이동합니다.
벤치마크 도구 설치
EBS 볼륨 성능 벤치마크에 사용할 수 있는 도구 일부가 다음 표에 나열되어 있습니다.
도구 | 설명 |
---|---|
fio |
I/O 성능을 벤치마크합니다. (fio는 fio을 Amazon Linux에 설치하려면 다음 명령을 실행하십시오.
Ubuntu에 fio를 설치하려면 다음 명령을 실행합니다.
|
Oracle 데이터베이스와 함께 사용할 스토리지 시스템의 I/O 성능을 보정합니다. |
도구 | 설명 |
---|---|
DiskSpd |
DiskSpd Microsoft의 Windows, Windows 서버 및 클라우드 서버 인프라 엔지니어링 팀이 제공하는 스토리지 성능 도구입니다. https://github.com/Microsoft/diskspd/releases
원하는 의 소스 코드는 https://github.com/Microsoft/diskspd GitHub |
CrystalDisk마크 |
CrystalDiskMark 간단한 디스크 벤치마크 소프트웨어입니다. https://crystalmark.info/en/software/crystaldiskmark/ |
이러한 벤치마크 도구는 다양한 테스트 파라미터를 지원합니다. 볼륨이 지원하는 작업에 근접하는 명령을 사용해야 합니다. 아래 제공된 명령은 사용자가 시작하는 데 도움이 되는 예시용입니다.
볼륨 대기열 길이 선택
워크로드와 볼륨 유형에 따라 최적의 볼륨 대기열 길이를 선택합니다
SSD 지원 볼륨에서 대기열 길이
SSD 기반 볼륨의 워크로드에 대한 최적의 대기열 길이를 확인하려면 사용 가능한 모든 1000 IOPS에 대해 대기열 길이를 1로 지정하는 것이 좋습니다(범용 SSD 볼륨의 경우 기준 및 Provisioned IOPS SSD 볼륨의 경우 프로비저닝된 양). 그러면 애플리케이션 성능을 모니터링하고 애플리케이션 요구 사항을 기준으로 해당 값을 조정할 수 있습니다.
대기열 길이를 길게 하면 프로비저닝된 IOPS, 처리량 또는 최적 시스템 대기열 길이 값(현재 32로 설정)을 얻을 때까지 유용합니다. 예를 들어 프로비저닝된 IOPS가 3,000인 볼륨은 대기열 길이 3을 목표로 해야 합니다. 이 값을 높이거나 낮추면서 튜닝을 시도하여 애플리케이션에 가장 적합한 설정을 찾아야 합니다.
HDD 지원 볼륨에서 대기열 길이
HDD 지원 볼륨에서 워크로드에 가장 적합한 대기열 길이를 알아내려면 1MiB 순차 I/O를 수행하는 동시에 최소 4 이상의 대기열 길이를 목표로 하는 것이 좋습니다. 그러면 애플리케이션 성능을 모니터링하고 애플리케이션 요구 사항을 기준으로 해당 값을 조정할 수 있습니다. 예를 들어 버스트 처리량은 500MiB/s, IOPS는 500인 2TiB st1
볼륨의 경우 1,024KiB, 512KiB 또는 256KiB 순차 I/O를 수행하는 동시에 각각 4, 8 또는 16 대기열 길이를 목표로 해야 합니다. 이 값을 높이거나 낮추면서 튜닝을 시도하여 애플리케이션에 가장 적합한 설정을 찾아야 합니다.
C 상태 비활성화
벤치마킹 실행 전에 프로세서 C 상태를 비활성화해야 합니다. 일시적으로 지원 CPU 내 유휴 코어가 C 상태가 되어 전력을 절감할 수 있습니다. 코어가 호출되어 처리를 재개할 때 코어가 다시 완전히 작동하기까지 특정 시간이 흐릅니다. 이 지연 시간이 프로세서 벤치마킹 루틴을 방해할 수 있습니다. C 상태 및 이를 지원하는 EC2 인스턴스 유형에 대한 자세한 내용은 EC2 인스턴스에 대한 프로세서 상태 제어를 참조하세요.
Amazon Linux, RHEL 및 CentOS에서 다음과 같이 C 상태를 비활성화할 수 있습니다.
C 상태 수를 가져옵니다.
$
C:\>
cpupower idle-info | grep "Number of idle states:"
c1부터 cN까지 C 상태를 비활성화합니다. 이상적인 경우 코어는 c0 상태여야 합니다.
$
C:\>
for i in `seq 1 $((N-1))`; do cpupower idle-set -d $i; done
다음과 같이 Windows에서 C 상태를 비활성화할 수 있습니다.
-
에서 PowerShell 현재 유효 전력 구성표를 구하십시오.
$current_scheme = powercfg /getactivescheme
-
전력 체계 GUID를 가져옵니다.
(Get-WmiObject -class Win32_PowerPlan -Namespace "root\cimv2\power" -Filter "ElementName='High performance'").InstanceID
-
전력 설정 GUID를 가져옵니다.
(Get-WmiObject -class Win32_PowerSetting -Namespace "root\cimv2\power" -Filter "ElementName='Processor idle disable'").InstanceID
-
전력 설정 하위 그룹 GUID를 가져옵니다.
(Get-WmiObject -class Win32_PowerSettingSubgroup -Namespace "root\cimv2\power" -Filter "ElementName='Processor power management'").InstanceID
-
인덱스의 값을 1로 설정하여 C 상태를 비활성화합니다. 값이 0인 경우 C 상태가 비활성화되었음을 나타냅니다.
powercfg /setacvalueindex
<power_scheme_guid>
<power_setting_subgroup_guid>
<power_setting_guid>
1 -
활성 체계를 설정하여 설정이 저장되었는지 확인합니다.
powercfg /setactive
<power_scheme_guid>
벤치마킹 수행
다음 절차에서는 다양한 EBS 볼륨 유형에 대한 벤치마킹 명령을 설명합니다.
연결된 EBS 볼륨이 있는 EBS에 최적화된 인스턴스에서 다음 명령을 실행합니다. 스냅샷에서 EBS 볼륨을 생성한 경우, 반드시 벤치마킹 전에 초기화해야 합니다. 자세한 정보는 Amazon EBS 볼륨 초기화을 참조하세요.
볼륨 테스트를 마치면 정리 도움말은 Amazon EBS 볼륨 삭제 및 인스턴스 종료를 참조하세요.
Provisioned IOPS SSD 및 범용 SSD 볼륨 벤치마크
생성한 RAID 0 어레이에서 fio를 실행합니다.
다음 명령은 16KB 임의 쓰기 작업을 수행합니다.
[ec2-user ~]$
sudo fio--directory=/mnt/
p_iops_vol0
--ioengine=psync--name
fio_test_file
--direct=1 --rw=randwrite --bs=16k --size=1G --numjobs=16 --time_based --runtime=180 --group_reporting --norandommap
다음 명령은 16KB 임의 읽기 작업을 수행합니다.
[ec2-user ~]$
sudo fio--directory=/mnt/
p_iops_vol0
--name
fio_test_file
--direct=1 --rw=randread --bs=16k --size=1G --numjobs=16 --time_based --runtime=180 --group_reporting --norandommap
결과를 해석하는 방법에 대한 자세한 내용은 Inspecting disk IO performance with fio
생성한 볼륨에서 DiskSpd를 실행합니다.
다음 명령은 C:
드라이브에 있는 20GB 테스트 파일(25% 쓰기 및 75% 읽기 비율, 8K 블록 크기)을 사용하여 30초 임의 I/O 테스트를 실행합니다. 각각 4개의 미해결 I/O와 1GB의 쓰기 엔트로피 값 시드가 있는 8개의 작업자 스레드를 사용합니다. 테스트 결과는 DiskSpeedResults.txt
라는 텍스트 파일에 저장됩니다. 이러한 파라미터는 SQL Server OLTP 워크로드를 시뮬레이션합니다.
diskspd -b8K -d30 -o4 -t8 -h -r -w25 -L -Z1G -c20G C:\iotest.dat > DiskSpeedResults.txt
결과를 해석하는 방법에 대한 자세한 내용은 Inspecting disk IO performance with DiskSPd
st1
및 sc1
볼륨 벤치마크(Linux 인스턴스)
fio 또는 st1
볼륨에서 sc1
를 실행합니다.
참고
이러한 테스트를 실행하기 전, st1 및 sc1에서 처리량이 많은 읽기 중심 워크로드의 미리 읽기 향상(Linux 인스턴스에만 해당)에 설명된 대로 인스턴스에 버퍼 I/O를 설정합니다.
다음 명령은 연결된 st1
블록 디바이스(예: /dev/xvdf
)에 대해 1MiB 순차 읽기 작업을 수행합니다.
[ec2-user ~]$
sudo fio--filename=/dev/
<device>
--direct=1 --rw=read
--randrepeat=0 --ioengine=libaio --bs=1024k --iodepth=8 --time_based=1 --runtime=180
--name=fio_direct_read_test
다음 명령은 연결된 st1
블록 디바이스에 대해 1MiB 순차 쓰기 작업을 수행합니다.
[ec2-user ~]$
sudo fio--filename=/dev/
<device>
--direct=1 --rw=write
--randrepeat=0 --ioengine=libaio --bs=1024k --iodepth=8 --time_based=1 --runtime=180
--name=fio_direct_write_test
일부 워크로드는 블록 디바이스의 다양한 부분에 순차 읽기와 순차 쓰기를 혼합하여 수행합니다. 이러한 워크로드를 벤치마크하려면 읽기와 쓰기에 별도의 fio 작업을 동시에 사용하고, 각 작업에 대해 서로 다른 블록 디바이스 위치를 목표로 하기 위해 fio offset_increment
옵션을 사용하는 것이 좋습니다.
이 워크로드 실행은 순차 쓰기나 순차 읽기 워크로드보다 다소 복잡합니다. 텍스트 편집기를 사용하여 다음을 포함한 fio 작업 파일(이 예에서는 fio_rw_mix.cfg
)을 만듭니다.
[global] clocksource=clock_gettime randrepeat=0 runtime=180 [sequential-write] bs=1M ioengine=libaio direct=1 iodepth=8 filename=/dev/
<device>
do_verify=0 rw=write rwmixread=0 rwmixwrite=100 [sequential-read] bs=1M ioengine=libaio direct=1 iodepth=8 filename=/dev/<device>
do_verify=0 rw=read rwmixread=100 rwmixwrite=0 offset=100g
그런 다음, 다음 명령을 실행합니다.
[ec2-user ~]$
sudo fiofio_rw_mix.cfg
결과를 해석하는 방법에 대한 자세한 내용은 Inspecting disk I/O performance with fio
순차 읽기나 쓰기 작업을 사용하는 경우라 하더라도 직접 I/O에 대한 다수의 fio 작업은 st1
및 sc1
볼륨에 기대했던 처리량보다 낮은 수준을 나타낼 수 있습니다. 하나의 직접 I/O 작업을 사용하고 iodepth
파라미터를 사용해 동시 I/O 작업의 개수를 제어하는 것이 좋습니다.