IOPS 볼륨 대기열 길이 및 지연 시간 I/O 크기 및 볼륨 처리량 제한이 없음 CloudWatch를 사용하여 I/O 특성 모니터링 관련 리소스

Amazon EBS I/O 기능 및 모니터링

지정된 볼륨 구성에서 특정 I/O 특성은 EBS 볼륨의 성능 동작을 구동합니다. 범용 SSD(gp2 및 gp3) 및 프로비저닝된 IOPS SSD(io1 및 io2)와 같은 SSD 지원 볼륨은 I/O 작업이 임의든 순차든 관계없이 일관된 성능을 제공합니다. 처리량 최적화 HDD(st1) 및 콜드 HDD(sc1)와 같은 HDD 지원 볼륨은 I/O 작업이 대용량이고 순차인 경우에만 최적의 성능을 제공합니다. SSD 및 HDD 볼륨이 애플리케이션에서 어떻게 작동하는지 이해하려면 볼륨 수요와 가용 IOPS 수량, I/O 작업을 완료하는 데 소요되는 시간, 볼륨의 처리량 제한 사이의 관계를 아는 것이 중요합니다.

IOPS

IOPS는 초당 입력/출력 작업을 나타내는 측정 단위입니다. 작업은 KiB로 측정되며 볼륨 유형에서 단일 I/O로 계산되는 데이터의 최대 양은 기반 드라이브 기술에 따라 결정됩니다. I/O 크기는 SSD 볼륨의 경우 256KiB로, HDD 볼륨의 경우 1,024KiB로 제한되는데 SSD 볼륨은 소량 또는 임의 I/O를 HDD 볼륨보다 훨씬 더 효율적으로 처리하기 때문입니다.

소량의 I/O 작업이 물리적으로 연속되는 경우 Amazon EBS는 최대 I/O 크기까지 단일 I/O 작업으로 병합을 시도합니다. 마찬가지로, I/O 작업이 최대 I/O 크기보다 큰 경우 Amazon EBS는 I/O 작업을 더 작은 I/O 작업으로 분할을 시도합니다. 다음 표에 몇 가지 예가 나와 있습니다.

볼륨 유형	최대 I/O 크기	애플리케이션의 I/O 작업	IOPS 수	참고
SSD	256KiB	1 x 1024KiB I/O 작업	4(1,024÷256=4)	Amazon EBS는 1,024 크기의 I/O 작업을 4개의 더 작은 256KiB 작업으로 분할합니다.
		8 x 순차적 32KiB I/O 작업	1(8x32=256)	Amazon EBS는 8개의 순차적 32KiB I/O 작업을 하나의 256KiB 작업으로 병합합니다.
		8개의 임의 32KiB I/O 작업	8	Amazon EBS는 임의 I/O 작업을 별도로 계산합니다.
HDD	1,024KiB	1 x 1024KiB I/O 작업	1	I/O 작업이 이미 최대 I/O 크기와 같습니다. 병합되거나 분할되지 않습니다.
		8 x 순차적 128KiB I/O 작업	1(8x128=1,024)	Amazon EBS는 8개의 순차적 128KiB I/O 작업을 하나의 1,024KiB I/O 작업으로 병합합니다.
		8개의 임의 32KiB I/O 작업	8	Amazon EBS는 임의 I/O 작업을 별도로 계산합니다.

그러므로 3,000 IOPS를 지원하는 SSD 지원 볼륨을 생성하여(Provisioned IOPS SSD 볼륨을 3,000 IOPS에서 프로비저닝하거나 범용 SSD 볼륨의 크기를 1,000GiB에서 조정하는 방법으로), 충분한 대역폭을 제공할 수 있는 EBS 최적화 인스턴스에 연결할 경우, 초당 최대 3,000 I/O 데이터 전송이 가능하며 처리량은 I/O 크기에 따라 결정됩니다.

볼륨 대기열 길이 및 지연 시간

볼륨 대기열 길이는 디바이스에 대해 보류 중인 I/O 요청 수입니다. 지연 시간은 I/O 작업의 실제 종단 간 클라이언트 시간입니다. 다시 말해 EBS로 I/O를 전송한 후 EBS로부터 I/O 읽기 또는 쓰기가 완료되었다는 승인을 받기까지 소요된 시간입니다. 대기열 길이를 I/O 크기 및 지연 시간에 따라 정확히 보정하여, 게스트 운영 체제나 EBS로 연결되는 네트워크 링크에 병목 현상이 발생하지 않도록 해야 합니다.

최적의 대기열 길이는 워크로드마다 다른데, IOPS 및 지연 시간에 대한 특정 애플리케이션의 민감도에 따라 결정됩니다. 워크로드가 EBS 볼륨에 대해 사용 가능한 성능을 전부 사용할 만큼 충분한 I/O 요청을 제공하지 않는 경우, 프로비저닝된 처리량이나 IOPS를 볼륨이 제공하지 못할 수 있습니다.

트랜잭션 집약적 애플리케이션은 I/O 지연 시간 증가에 민감하며, SSD 기반 볼륨에 적합합니다. 대기열 길이를 줄이고 볼륨에서 사용할 수 있는 IOPS 개수를 늘리면 높은 IOPS를 유지하는 동시에 지연 시간을 단축할 수 있습니다. 볼륨이 수용할 수 있는 수준보다 높은 IOPS를 계속 구동하면 I/O 지연 시간이 길어질 수 있습니다.

처리량 집약적인 애플리케이션은 I/O 지연 시간 증가에 덜 민감하며, HDD 기반 볼륨에 적합합니다. 대용량 순차 I/O를 수행할 때 대기열 길이를 길게 유지하면 HDD 지원 볼륨에서 높은 처리량을 유지할 수 있습니다.

I/O 크기 및 볼륨 처리량 제한이 없음

SSD 지원 볼륨의 경우, I/O 크기가 매우 크면 볼륨 처리량 제한에 도달하기 때문에 프로비저닝한 것보다 IOPS가 적을 수 있습니다. 예를 들어 버스트 크레딧을 사용할 수 있는 1,000GiB 미만의 gp2 볼륨에는 3,000 IOPS 제한과 250MiB/s의 볼륨 처리량 제한이 있습니다. 256KiB I/O 크기를 사용하는 경우, 볼륨은 1000 IOPS에서 처리량 제한에 도달합니다(1000 x 256KiB = 250MiB). I/O 크기가 작다면(예: 16KiB), 처리량이 250MiB/s에 훨씬 못 미치기 때문에 동일한 볼륨이 3,000 IOPS를 유지할 수 있습니다. (이 예제는 볼륨의 I/O가 인스턴스의 처리량 제한에 도달하지 않는다고 가정합니다.) 각 EBS 볼륨 유형의 처리량 제한에 대한 자세한 내용은 Amazon EBS 볼륨 유형 섹션을 참조하세요.

소용량 I/O 작업의 경우, 인스턴스 내에서 측정했을 때 프로비저닝된 IOPS 값보다 큰 값을 관찰할 수 있습니다. 인스턴스 운영 체제가 소용량 I/O 작업을 Amazon EBS로 전달하기 전 대용량 작업에 병합할 때 이런 결과가 발생합니다.

워크로드가 HDD 지원 st1 및 sc1 볼륨의 순차 I/O를 사용한다면 인스턴스 내에서 측정했을 때 예상보다 높은 IOPS를 관찰할 수 있습니다. 인스턴스 운영 체제가 순차 I/O를 병합하고 1,024KiB 크기 단위로 계산되는 경우에 이런 결과가 발생합니다. 워크로드가 소용량 또는 랜덤 I/O를 사용하는 경우 예상보다 적은 처리량을 관찰할 수 있습니다. 이는 각각의 비순차적인 랜덤 I/O를 총 IOPS 계산에 적용하기 때문이며, 이로 인해 예상보다 일찍 볼륨의 IOPS 제한에 도달할 수 있습니다.

EBS 볼륨 유형이 무엇이든 현재 구성에서 기대한 IOPS 또는 처리량을 달성하지 못할 경우에는 EC2 인스턴스 대역폭이 제한 요소가 아닌지 확인하세요. 최적의 성능을 위해 항상 현재 세대 EBS 최적화 인스턴스(또는 10Gb/s 네트워크 연결을 포함한 인스턴스)를 사용해야 합니다. EBS 볼륨에 충분한 I/O를 구동하고 있지 않은 경우에도 IOPS가 예상과 다를 수 있습니다.

CloudWatch를 사용하여 I/O 특성 모니터링

각 볼륨의 CloudWatch 볼륨 지표로 이러한 I/O 특성을 모니터링할 수 있습니다. 고려해야 할 중요한 지표는 다음과 같습니다.

VolumeStalledIOCheck
BurstBalance
VolumeReadBytes | VolumeWriteBytes
VolumeReadOps | VolumeWriteOps
VolumeQueueLength

VolumeStalledIOCheck는 EBS 볼륨의 상태를 모니터링하여 볼륨이 손상된 시점을 확인합니다. 지표는 EBS 볼륨이 I/O 작업을 완료할 수 있는지 여부에 따라 0(통과) 또는 1(실패) 상태를 반환하는 바이너리 값입니다. 이 검사는 다음과 같은 Amazon EBS 인프라의 기본 문제를 감지합니다.

EBS 볼륨의 기반이 되는 스토리지 하위 시스템의 하드웨어 또는 소프트웨어 문제
EC2 인스턴스에서 EBS 볼륨의 연결성에 영향을 주는 물리적 호스트의 하드웨어 문제
인스턴스와 EBS 볼륨 간의 연결 문제

VolumeStalledIOCheck 지표가 실패하면 AWS에서 문제가 해결될 때까지 기다리거나 영향을 받는 볼륨을 교체하거나 볼륨이 연결된 인스턴스를 중지하고 다시 시작하는 등의 조치를 취할 수 있습니다. 대부분의 경우 이 지표가 실패하면 EBS는 몇 분 내에 볼륨을 자동으로 진단하고 복구합니다. AWS Fault Injection Service에서 I/O 일시 중지 작업으로 제어된 실험을 실행하여 이 지표를 기준으로 아키텍처 및 모니터링을 테스트하여 스토리지 장애에 대한 복원력을 향상시킬 수 있습니다.

VolumeReadOps, VolumeWriteOps, VolumeTotalReadTime 및 VolumeTotalWriteTime을 사용하여 Amazon EBS 스토리지 I/O 지연 시간을 측정할 수 있습니다. 다음 공식을 사용하여 볼륨의 평균 I/O 지연 시간을 모니터링할 수 있습니다.


Average I/O latency in ms/op = (VolumeTotalReadTime + VolumeTotalWriteTime) / (VolumeReadOps + VolumeWriteOps)

I/O 지연 시간이 필요한 것보다 긴 경우 구동 IOPS를 확인하여 애플리케이션이 프로비저닝한 것보다 많은 IOPS를 구동하려고 하고 있지 않은지 확인합니다. 다음 공식을 사용하여 볼륨의 평균 구동 IOPS를 모니터링할 수 있습니다.


Estimated average IOPS in ops/s = (Sum(VolumeReadOps) + Sum(VolumeWriteOps)) / (Period - Sum(VolumeIdleTime))

IOPS가 볼륨에서 제공할 수 있는 수보다 많이 애플리케이션에 필요한 경우 다음 중 하나를 사용하는 것을 고려해야 합니다.

필수 지연 시간 달성에 충분한 IOPS가 프로비저닝되는 gp3, io2 또는 io1 볼륨
충분한 기준 IOPS 성능을 제공하는 더 큰 gp2 볼륨

HDD 지원 st1 및 sc1 볼륨은 1,024KiB 최대 I/O 크기를 활용하는 워크로드에서 가장 잘 작동하도록 설계되었습니다. 볼륨의 평균 I/O 크기를 구하려면 VolumeWriteBytes 를 VolumeWriteOps 값으로 나눕니다. 읽기 작업에도 같은 계산 방법이 적용됩니다. 평균 I/O 크기는 64KiB 미만이며, st1 또는 sc1 볼륨으로 보내는 I/O 작업의 크기가 큰 경우 성능을 개선해야 합니다.

참고

평균 I/O 크기가 44KiB이거나 그에 가까운 경우에는 간접 서술자가 지원되지 않는 인스턴스 또는 커널을 사용 중일 수 있습니다. 현재 세대 인스턴스뿐만 아니라 Linux 커널 3.8 이상 버전도 모두 이 지원을 제공합니다.

BurstBalance는 gp2, st1, sc1 볼륨에 대한 버스트 버킷 잔고를 남은 잔고에 대한 비유로 표시합니다. 버스트 버킷이 모두 사용되면 볼륨 I/O(gp2 볼륨용) 또는 볼륨 처리량(st1 및 sc1 볼륨용)이 기준 수준으로 스로틀링됩니다. BurstBalance 값을 확인하여 이런 이유로 볼륨이 조절되는지 판단합니다. 사용 가능한 Amazon EBS 지표의 전체 목록은 아마존 CloudWatch EBS용 아마존 메트릭스 및 Nitro 기반 인스턴스용 Amazon EBS 지표를 참조하세요.