IOPS Are A Scam

Introduction

IOPS란 Input/Output Operations Per Second로써, 디바이스에서 1초에 얼마나 많은 물리적인 read/write 동작이 수행가

능한지를 나타내는 척도이다. 많은 벤더들이 이러한 메트릭을 통해서 자신의 상품들을 광고한다. 하지만 사실 7,000 IOPS 스펙을 가진 디바이스와 300 IOPS 스펙의 디바이스 중 항상 7,000 IOPS 디바이스가 빠르다고 장담할 수는 없다.

Background

Latency vs IOPS

Latency는 하나의 요청(request)이 발생하고 그에 대한 응답(response)을 받기까지 걸린 시간이다. Latency는 스토리지 디바이스의 성능을 나타내기 위한 하나의 중요한 메트릭이다. HDD의 동작 구조를 알고 있다면, 물리적 법칙을 간단하게 상상만 해보아도 HDD에서 sequenctial read/wirte 동작과 random read/write 동작의 성능 차이가 크게 차이가 날 것임을 쉽게 유추할 수 있을 것이다.

SSD에는 latency가 없을까?

또 다른 스토리지 디바이스 종류인 SSD에도 이러한 latency는 존재한다. SSD에는 한 개의 컨트롤러가 유한개의 칩을 관리하도록 설계가 되어 있다. 어떤 SSD에는 여러 개의 컨트롤러가 존재하기도 한다. 컨트롤러의 수가 몇 개이든 관계없이 컨트롤러는 디바이스의 데이터를 매우 빠르게 가지고 올 수 있다. 하지만 이러한 요청들이 큐에 쌓일 때 발생하는 latency도 존재한다. 

SSD에서 HDD의 경우 처럼 데이터를 찾기 위한 latency는 0.1ms 정도라고 한다.

PCI-Express^[각주:1] bus는 여러 I/O 컨트롤러와 네트워크 컨트롤러 등 다양한 확장 카드들과 연결되어 있다. 만약 이러한 디바이스들이 동시에 사용된다면 PCI-E bus에 접근하는 것만으로 latency가 발생할 수 있다. 고사양의 PCI-E SSD (TempDB)가 두 개 이상만 되어도 이론적으로 PCI-E bus가 전송할 수 있는 것보다 더 많은 데이터를 생성한다. 그러므로 PCI-E SSD와 Fibre Channel HBA^[각주:2]를 사용하면, PCI-E에서 랜덤한 latency가 발생하게 되는 상황이 발생하게 된다.

Throughput?

Throughput은 주로 IOPS와 수행한 바이트의 크기를 곱하여 계산한다 (Throughput = IOPS X operation size in bytes). 하지만 디스크의 성능 측도로 사용될 뿐, 동작을 수행하기 전에 발생하는 delay가 얼마나 생기는지 등의 정보는 없기 때문에 전체 동작을 수행하는데 걸리는 시간을 예측하는 용도로는 사용될 수는 없다. 그러므로 throughput은 실험에 완벽히 알맞은 환경(controlled environment)에서는 성능을 나타낼 수 있는 좋은 척도가 되지만, real-world 환경에서 성능을 측정하기에는 여전히 부족한 점이 많다.

Amazon의 SQL Server RDS 는 7,000 IOPS라는 사양을 지원한다는 관점에서만 보면 매우 훌륭한 성능을 보여줄 것처럼 기대되지만, 한 번의 I/O 동작에 16 KiB 크기를 수행할 수 있다면, 7,000 IOPS * 16 KiB = 112,000 KiB per second 정도의 성능을 낼 수 있다고 해석할 수 있다. 이는 대략 100 MBps(Mega Byte per second)이고, 1 Gbps (Giga bit per second) 이더넷 정도의 속도이다.

1 Gbps 정도면 개인이 사용하기는 충분한 것 같은데.. 대형 서비스에서는 어느 정도의 성능이 필요할까?

What Does Good Storage Look Like?

이처럼 스토리지의 성능을 측정하는 것은 매우 까다롭다. 위에서 살펴보았듯이 IOPS와 throughput은 동작의 속도를 나타내기는 하지만 시간을 예측하는 용도로 사용할 수는 없다. Latency는 시간을 나타내기는 하지만 동작의 속도를 나타내지 못한다. 그러므로 IOPS와 throughput, latency를 결합하여 성능을 평가하는 것이 가장 적절하다. Latency를 예측하는 것은 디스크 드라이브에 매우 중요한 요소이다. 만약 디스크가 어떻게 동작하는지 알 수 없다면, 어플리케이션의 성능을 예측할 수도, SLA(Service Level Aggrement)를 만족시킬 수도 없다.

EC2 I/O를 모니터링할 수 있는 Scalyr를 통해 EC2의 드라이브 latency가 매우 다변화하는 것을 검증하였다. 이러한 정도는 스토리지 제공자에 따라 다르지만, 공통적으로 latency는 공유 스토리지(shared storage)와 전용 디스크(dedicated disk)모두에 문제를 발생시킬 수 있다는 것을 명심해야 한다.

What Can We Do About IOPS and Latency?

첫 번째 단계는 각 메트릭의 값이 무엇을 의미하는지 이해하는 것이다. 스토리지 벤더에서 제공한 값을 성능 측정의 상황에 관련된 메트릭으로 변환하는 것이 필요하다. 예를 들어, 4k IOPS를 64k IOPS로 변환하거나 IOPS를 MB/s 측정값으로 변환하는 것이 있다. 이처럼 이해할 수 있는 메트릭으로 변환하면 SQLIO^[각주:3]를 사용하여 성능을 확인하고 벤더의 광고에서 사용된 값을 직접 측정한 값과 비교하여 검증할 수 있다.
또한 하드웨어를 최대한 활용하려면 SQL Server의 설정이 적절하게 적용되어 있는지 확인해야 할 필요가 있다. SQL Server가 제대로 설정되었다는 것이 검증된 후에는 메모리 추가[footnote/A Sysadmin’s Guide to Microsoft SQL Server Memory https://www.brentozar.com/archive/2011/09/sysadmins-guide-microsoft-sql-server-memory/[/footnote], 인덱스 조정^[각주:4], 쿼리 방지 ^[각주:5]를 고려해야한다.
이를 통해 스토리지를 더 빠르게 만들 수는 없지만 스토리지의 작업량을 줄일 수는 있다. 스토리지의 작업량이 줄어들면 bus에 의한 병목이 줄어들기 때문에 결국 스토리지를 더 빠르게 만드는 것과 같은 결과를 얻을 수 있다.

 

원글: https://www.brentozar.com/archive/2013/09/iops-are-a-scam/

IOPS Are A Scam - Brent Ozar Unlimited®

1. SATA 3.0 (6 Gbits/s), PCI-E(8 GT/s = 1 GB/s), Fibre [본문으로]
2. What is the difference between an HBA and a NIC https://www.promax.com/blog/what-is-the-difference-between-an-hba-and-a-nic [본문으로]
3. SQLIO Tutorial: How to Test Disk Performance https://www.brentozar.com/archive/2008/09/finding-your-san-bottlenecks-with-sqlio/ [본문으로]
4. sp_BlitzIndex® – SQL Server’s Index Sanity Test https://www.brentozar.com/blitzindex/
   [본문으로]
5. A Developer’s Guide to Dangerous Queries https://www.brentozar.com/archive/2012/07/developers-guide-dangerous-queries-video/ [본문으로]