Random IOPS와 Sequential IOPS의 차이, 벤치마크 결과를 읽는 방법

この文書の適用条件

そのまま実行できるコマンド

# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み取り権限（デバイス直接指定なら root）
# 変更作業: なし（読み取りのみ）だが実行中は他処理の I/O 性能に影響する
# Production 実行: 非推奨。検証環境で実行すること
fio --name=rand_read_4k \
    --filename=/mnt/testdir/fio_testfile \
    --size=64G \
    --rw=randread \
    --bs=4k \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=32 \
    --numjobs=4 \
    --runtime=300 \
    --time_based \
    --ramp_time=30 \
    --group_reporting

# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み取り権限
# 変更作業: なし（読み取りのみ）だが I/O 帯域を占有する
# Production 実行: 非推奨。検証環境で実行すること
fio --name=seq_read_1m \
    --filename=/mnt/testdir/fio_testfile \
    --size=64G \
    --rw=read \
    --bs=1M \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=8 \
    --numjobs=1 \
    --runtime=300 \
    --time_based \
    --group_reporting

# 対象: Linux + fio 3.x
# 権限: 対象ファイルへの読み書き権限
# 変更作業: あり（テストファイルに書き込む。既存データを指定しないこと）
# Production 実行: 不可。専用の検証領域でのみ実行すること
fio --name=rand_rw_70_30 \
    --filename=/mnt/testdir/fio_testfile \
    --size=64G \
    --rw=randrw \
    --rwmixread=70 \
    --bs=8k \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=32 \
    --numjobs=4 \
    --runtime=600 \
    --time_based \
    --ramp_time=60 \
    --group_reporting

# 対象: Linux（sysstat / nvme-cli）
# 権限: 一般ユーザー（nvme list は root が必要な場合がある）
# 変更作業: なし（参照のみ）
# Production 実行: 可能
lsblk -o NAME,SIZE,TYPE,ROTA,MOUNTPOINT,MODEL
sudo nvme list
iostat -x 1 10

結果の読み方

こういう状況で使います

• 제품 카탈로그의 IOPS 값과 직접 측정한 값이 크게 다름
• 같은 스토리지인데 측정하는 사람에 따라 수치가 몇 배씩 달라짐
• 벤치마크로는 빠른데 데이터베이스 처리는 기대만큼 빨라지지 않음
• SATA SSD에서 NVMe SSD로 바꿨는데 체감이 달라지지 않음
• NVMe를 다수 탑재한 구성으로 만들었는데 개수에 비례해 성능이 오르지 않음
• 순차 수치와 랜덤 수치 중 어느 것을 봐야 할지 모르겠음

考えられる原因（可能性の高い順）

1. 01

   IOPS라는 수치가 단독으로는 정의되지 않음

   IOPS는 "초당 I/O 횟수"일 뿐이며, 1회 I/O의 크기, 동시에 발행하고 있는 I/O 수(큐 깊이), 읽기/쓰기 비율, 캐시를 우회하고 있는지가 정해져야 비로소 의미를 갖습니다. 이 4가지가 갖춰지지 않은 수치끼리는 비교할 수 없습니다.

2. 02

   HDD에서는 물리적 동작이 랜덤 접근을 지배함

   회전 매체에서는 랜덤 I/O 1회마다 헤드 이동(탐색)과 섹터가 돌아올 때까지의 대기(회전 대기)가 발생합니다. 순차 접근에서는 이것이 거의 발생하지 않으므로 같은 장치라도 랜덤과 순차에서 자릿수 차이가 납니다.

3. 03

   SSD/NVMe에서도 차이는 0이 되지 않음

   기계적 동작이 없기 때문에 랜덤과 순차의 차이는 HDD보다 크게 줄지만, 플래시의 페이지/블록 구조, 쓰기 증폭, 가비지 컬렉션, 매핑 테이블 참조 비용이 있기 때문에 차이는 남습니다. 특히 쓰기에서는 여유 공간이 줄어든 정상 상태와 초기 상태에서 수치가 달라집니다.

4. 04

   SATA(AHCI)와 NVMe는 큐 구조가 다름

   AHCI는 기본적으로 단일 명령 큐를 가지는 설계로, 동시에 발행할 수 있는 명령 수가 제한됩니다. NVMe는 CPU 코어마다 다수의 깊은 큐를 가질 수 있는 설계입니다. 이 차이가 효과를 내는 것은 고병렬 시이며, 큐 깊이 1의 순차적 접근에서는 차이가 작아집니다. "NVMe로 바꿨는데 빨라지지 않는다"면 측정 조건이 저병렬일 가능성이 있습니다.

5. 05

   벤치마크가 캐시를 측정하고 있음

   `direct=1` 지정이 없거나, 테스트 크기가 RAM보다 작거나, 실행 시간이 짧아 워밍업만으로 끝나는 등의 조건에서는 측정하고 있는 것이 페이지 캐시나 컨트롤러의 라이트백 캐시입니다.

6. 06

   데이터베이스의 접근 패턴과 측정 조건이 맞지 않음

   데이터베이스의 데이터 파일 접근은 일반적으로 랜덤 쪽에 가깝고, 트랜잭션 로그 쓰기는 순차적이며 동기적입니다. 로그 쓰기는 IOPS나 처리량이 아니라 쓰기 지연 시간이 효과를 줍니다. 순차 읽기 수치가 좋아도 이 두 성능은 보장되지 않습니다.

確認手順

1. 1

   실제 워크로드의 I/O 특성을 먼저 측정하기

   参照のみ

   `iostat -x`로 `rareq-sz`·`wareq-sz`(평균 I/O 크기), `r/s`·`w/s`, `aqu-sz`(큐 길이)를 가져옵니다. 벤치마크 조건은 이에 맞춥니다.

2. 2

   장치 구성 확인하기

   参照のみ

   `lsblk -o ...,ROTA,MODEL`과 `nvme list`로 측정 대상이 무엇인지(HDD인지 SSD인지, 로컬인지 네트워크 연결인지) 확정합니다.

3. 3

   측정 조건을 명시한 상태로 fio 실행하기

   低

   `--bs`·`--iodepth`·`--numjobs`·`--rw`·`--direct=1`을 명시하고 조건을 그대로 기록합니다. 조건 기록이 없는 벤치 결과는 나중에 해석할 수 없습니다.

4. 4

   큐 깊이를 바꾼 여러 지점에서 측정하기

   低

   iodepth를 바꾸며 IOPS와 지연 시간을 모두 기록합니다. IOPS가 한계에 도달한 후에도 지연 시간만 늘어나는 지점이 실용상의 상한입니다.

5. 5

   쓰기는 정상 상태까지 실행하기

   中

   SSD에서는 짧은 시간 측정이면 초기 상태의 값만 나옵니다. `--runtime`을 길게 잡고 `--ramp_time`으로 초기 구간을 제외합니다.

6. 6

   다수 장치 구성에서는 계층별로 분리해 확인하기

   低

   단일 장치, RAID/볼륨 계층, 파일시스템 계층, 애플리케이션 계층 순으로 측정해 어디서 한계에 부딪히는지 특정합니다.

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• CPU가 포화되지 않았는지 확인하기

  고IOPS 측정에서는 인터럽트 처리와 I/O 발행으로 CPU를 다 써버리는 경우가 있습니다. `iostat`과 함께 `mpstat`으로 CPU 사용률을 확인하십시오.

• I/O 스케줄러 설정 확인하기

  NVMe에서는 `none`이 적합한 경우가 많으며, 회전 매체용 스케줄러를 그대로 쓰면 불필요한 재정렬이 들어갑니다.

• 파일시스템의 정렬(alignment) 확인하기

  파티션이나 스트라이프의 경계가 어긋나 있으면 1회의 논리 I/O가 여러 물리 I/O로 분할됩니다.

• 애플리케이션의 동시 실행 수 확인하기

  스토리지가 상한에 도달하지 않았는데도 느리다면 제한 요인은 애플리케이션 쪽의 병렬도나 락 경쟁입니다.

• 비교 대상의 측정 조건 확보하기

  다른 곳의 수치와 비교하는 경우, 그 측정의 bs·iodepth·numjobs·rw·direct 지정이 공개되어 있는지 확인합니다. 공개되지 않은 수치와는 비교할 수 없습니다.

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• SATA SSD와 NVMe SSD의 Random Read IOPS 차이
• 24개 NVMe SSD 구성에서 병목이 되는 지점
• 벤치마크의 IOPS 값이 제품 카탈로그와 다른 이유
• 데이터베이스는 랜덤 I/O와 순차 중 어느 것이 중요한가

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

여기까지의 내용은 측정 조건만 맞추면 누구나 재현할 수 있습니다. 실제 운영에서 어려운 것은 올바르게 측정하는 것이 아니라, 측정한 조건을 기록하고 다음 측정과 비교할 수 있는 상태를 유지하는 것입니다. GIIP에서는 AWS와 Azure 상의 여러 데이터베이스 및 약 30개의 웹 서비스에 대해 I/O 크기·큐 길이·대기 시간을 AI 에이전트가 동일 조건으로 지속적으로 수집하고, 과거 분포와 비교해 벗어난 시점에 사람인 전문가가 원인을 파악합니다. 단발성 벤치마크 값이 아니라 같은 조건으로 계속 수집한 시계열을 판단 근거로 삼기 위한 체계입니다.

関連サービス

• データベース性能チューニング
• 構成と測定条件について相談する