Storage Latency란? SSD·HDD의 읽기·쓰기 요청 하나가 완료되기까지 걸리는 시간 쉽게 이해하기
Storage Latency는 I/O 요청 하나가 완료될 때까지 걸리는 시간입니다. Queue Waiting·Service Time, Saturation, Tail Latency, fsync·Cache까지 초보 기준으로 정리합니다.
광고에 3,500MB/s나 100,000 IOPS가 보여도 Database·웹에서는 Storage Latency가 체감을 좌우합니다. Read/Write 요청을 보낸 뒤 그 I/O가 완료될 때까지 걸리는 시간입니다 — 주문 후 음식이 나오는 시간과 같습니다. 하루 손님 수(처리량)와 한 접시 대기 시간은 다릅니다. Throughput은 「초당 몇 MB·GB?」, IOPS는 「초당 몇 번?」, Latency는 「한 번에 몇 ms(또는 μs)?」입니다. CPU에는 1ms도 길어서 I/O Wait 중 다른 Thread를 돌립니다(CPU Scheduling·iowait).
Total Latency ≈ Queue Waiting + Device Service Device 1ms + Queue 20ms → App이 느끼는 약 21ms
HDD·SSD · Queue · Saturation
HDD는 Seek Time·Rotational Latency 때문에 Random이 느릴 수 있고, SSD·NVMe는 Flash·PCIe로 더 낮은 Latency를 낼 수 있습니다. App이 보는 시간은 System Call·File System·Scheduler·Device Queue까지 포함합니다. Device가 느려지지 않아도 요청이 Capacity에 가까우면 Queue만으로 Latency가 급증합니다 — Throughput/IOPS는 정체인데 Latency만 오르는 Saturation 신호입니다(Queueing). Write는 GC·Wear Leveling·Write Amplification으로 Read와 다를 수 있고, DB Commit·fsync Latency는 Transaction에 바로 붙습니다. App CPU 2ms를 1ms로 깎아도 Storage Flush 100ms면 체감이 거의 없습니다.
Tail · Cache · Concurrency · 경로
평균만 보지 말고 p95·p99 Tail을 봅니다 — GC·Flush·Thermal·Queue Spike가 일부를 수백 ms로 밀어낼 수 있습니다. Page Cache·Buffer Pool Hit면 Disk를 안 가서 Latency가 매우 낮아 보입니다(Cache Miss·Cold/Warm·재시작 후 Warm-Up). Queue Depth를 키우면 Throughput은 늘 수 있어도 개별 Latency는 늘 수 있습니다. Connection·동시 I/O를 과하면 Knee Point 이후 Waiting만 증가합니다 — Admission·Backpressure. Network Block/NFS·Object Storage는 Local NVMe와 같은 Latency를 기대하면 안 됩니다. Metadata·작은 파일 수백만 개도 Bottleneck이 될 수 있습니다.
완화: Cache · 빠른 Media · Index/Query 축소 Concurrency 제한 · Backup/Log 분리 · Locality/Batch Baseline 대비 Spike · p99 · Trace로 계층 좁히기
조사 · 완화 · SEO
Index로 Physical Read를 줄이되 Index가 많으면 Write 비용이 늘고, Backup과 DB가 같은 Disk면 Contention이 납니다. CPU 낮고 API만 느리면 Storage·Lock·Network을 의심합니다. Slow Query는 Plan·Physical Reads·동시 Disk Latency를 같이 보고, 분산 추적으로 HTTP→App→DB→Storage Wait를 내려갑니다. Alert는 Storage 종류별 Baseline·Percentile 기준이 맞습니다. SEO 전용 지표는 아니지만 Timeout·5xx면 UX에 간접 영향(모니터링·503).
초보 FAQ
IOPS 높으면 Latency도 낮나?
아닙니다. Queue가 길면 개별 요청 Latency는 높을 수 있습니다.
CPU 낮은데 느리면 Storage?
가능합니다. I/O·Lock·Network 대기를 함께 확인합니다.
평균만 보면 되나?
부족합니다. p95·p99 Tail Latency도 봅니다.
포화되면?
처리량은 정체되고 Queue Waiting으로 Latency가 급증할 수 있습니다.
정리
Storage Latency = I/O 요청 하나가 완료될 때까지 걸리는 시간입니다. 한가하면 거의 바로 처리되지만 Capacity에 가까우면 Queue Waiting이 커지며 Latency만 급증할 수 있습니다. 앞에 요청이 1개인 것과 100개가 동시에 쌓인 것은 다릅니다. Storage는 여러 요청을 동시에 받아 병렬성을 쓸 수도 있지만, 너무 많으면 각 I/O 대기 시간이 크게 늘어납니다. 이처럼 Storage에 동시에 제출되어 처리 중이거나 대기 중인 I/O 요청 수를 Queue Depth(큐 깊이)라고 합니다.