메뉴
Amazon Elastic Compute Cloud
User Guide for Linux Instances

I/O 특성 및 모니터링

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

IOPS

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

소용량 I/O 작업이 물리적으로 연속되는 경우, Amazon EBS가 최대 크기까지 단일 I/O로 병합을 시도합니다. 예를 들어, SSD 볼륨의 경우 1건의 1,024KiB I/O 작업은 4건(1,024÷256=4)의 작업으로 계산되지만 각각 32KiB인 8건의 연속하는 I/O 작업은 1건(8×32=256)의 작업으로 계산됩니다. 하지만 각각 32KiB인 8건의 랜덤 I/O 작업은 8건의 작업으로 계산됩니다. 각각 32KiB보다 작은 I/O 작업은 1건의 작업으로 계산됩니다.

마찬가지로, HDD 지원 볼륨의 경우 1,024KiB I/O 작업 1건과 128KiB 순차 작업 8건은 모두 각각 1건의 작업으로 계산됩니다. 하지만 랜덤 128KiB I/O 작업 8건은 8건의 작업으로 계산됩니다.

그러므로 3,000 IOPS를 지원하는 SSD 지원 볼륨을 생성하여(io1 볼륨을 3,000 IOPS에서 프로비저닝하거나 gp2 볼륨의 크기를 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 지원 io1gp2 볼륨에 적합합니다. 대기열 길이를 줄이고 볼륨에서 사용할 수 있는 IOPS 개수를 늘리면 높은 IOPS를 유지하는 동시에 지연 시간을 단축할 수 있습니다. 볼륨이 수용할 수 있는 수준보다 높은 IOPS를 계속 구동하면 I/O 지연 시간이 길어질 수 있습니다.

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

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

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

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

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

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

CloudWatch로 I/O 특성 모니터링

각 볼륨의 CloudWatch 측정치로 이러한 I/O 특성을 모니터링할 수 있습니다. 고려해야 할 중요 측정치로는 다음 항목이 포함됩니다.

  • BurstBalance

  • VolumeReadBytes

  • VolumeWriteBytes

  • VolumeReadOps

  • VolumeWriteOps

  • VolumeQueueLength

BurstBalancegp2, st1, sc1 볼륨에 대한 버스트 버킷 잔고를 남은 잔고에 대한 비유로 표시합니다. 버스트 버킷이 모두 사용되면 볼륨 I/O 크레딧(gp2 볼륨) 또는 볼륨 처리량 크레딧(st1sc1 볼륨)이 기준 수준으로 스로틀링됩니다. BurstBalance 값을 확인하여 이런 이유로 볼륨이 조절되는지 판단합니다.

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

참고

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

I/O 지연 시간이 필요한 것보다 긴 경우 VolumeQueueLength를 확인하여 애플리케이션이 프로비저닝한 것보다 많은 IOPS를 구동하려고 하고 있지 않은지 확인하십시오. 볼륨이 제공할 수 있는 것보다 많은 수의 IOPS를 요구하는 애플리케이션인 경우, 기준 성능 수준이 높은 대용량 gp2 볼륨 또는 프로비저닝된 IOPS가 더 많은 io1 볼륨을 사용하여 지연 시간을 줄이는 것을 고려해야 합니다.

Amazon EBS I/O 특성에 관한 자세한 내용은 이 주제를 다룬 Amazon EBS: Designing for Performance re:Invent 발표를 참조하십시오.