ログイン 出店する
← 가이드 목록
시작하기

Queue Depth란? SSD·HDD에 동시에 몇 개의 I/O 요청이 쌓여 있는지 쉽게 이해하기

Queue Depth는 Storage에 동시에 제출된 I/O 요청 수입니다. QD1·QD32, IOPS·Latency Trade-off, Knee Point, Admission·Load Shedding까지 초보 기준으로 정리합니다.

Queue Depth란? SSD·HDD에 동시에 몇 개의 I/O 요청이 쌓여 있는지 쉽게 이해하기

SSD Benchmark에 QD1 · QD4 · QD32가 보이면 「QD32면 32배 빠르다」로 읽기 쉽습니다. 그렇지 않습니다. Queue Depth(QD)는 Storage에 동시에 제출되어 처리 중이거나 대기 중인 I/O 요청 수입니다 — 주방 앞에 주문이 몇 장 쌓였는지와 같습니다. QD1은 한 번에 하나, QD32는 최대 약 32개가 Storage 쪽에 들어가 있는 상황입니다. 광고의 최대 IOPS가 QD256·4KB Random 조건일 수 있어 체감과 다를 수 있습니다.

낮은 QD → Latency에 유리 · 병렬성 덜 씀
높은 QD → Throughput/IOPS↑ 가능 · Waiting↑ 가능
Total Latency ≈ Queue Wait + Device Service

왜 QD를 올리면 IOPS가 오를까 · Trade-off

NVMe SSD는 Flash Channel 등 내부 Parallelism이 있습니다. 요청 하나면 Channel 일부만 일하고, 여러 요청이면 병렬로 채울 수 있어 IOPS·Throughput이 늘 수 있습니다. 하지만 Capacity를 넘기면 앞 요청을 기다리며 Latency의 Queue Waiting이 커집니다. QD1은 Device Latency에 가깝고, QD32는 처리량에 유리할 수 있습니다. Knee Point 이후에는 QD만 늘려도 IOPS는 정체·Latency만 급증합니다(Queueing · Little's Law 감각: QD ≈ IOPS × Latency).

Queue Depth 증가에 따른 IOPS 상승 후 Saturation과 Latency 급증
QD↑ → 처음엔 IOPS↑ · Saturation 후 IOPS 정체·Latency 급증

Concurrency · Scheduler · App Queue

Application Concurrency·Thread 수와 QD는 같지 않습니다. Connection 100개여도 Disk I/O는 10개일 수 있고, Thread 하나라도 Async로 32 Block을 보내면 QD가 올라갑니다. OS I/O Scheduler는 요청 순서·공정성을 다루고, HDD에서는 Seek 줄이는 재정렬이 중요했습니다. SSD·NVMe는 Head가 없어도 Queue·Fairness는 남습니다. Device에 만 건을 밀어 넣기보다 App에서 동시 I/O를 제한하면 Timeout·Priority·취소를 다루기 쉽습니다 — Admission·Bounded Queue·Load Shedding. Backup이 Queue를 채우면 Login Read가 밀립니다(Contention · Noisy Neighbor). Async는 Capacity를 만들지 않고 기다리기 효율만 올립니다.

신호: QD↑ + IOPS↑ → 병렬성 활용 중
QD↑ + IOPS 정체 + Latency↑ → Saturation 의심
Batch = Throughput 우선 · Interactive = Latency 우선

조사 · SEO · 운영

QD Spike 시 Traffic·Backup·Batch·Query 변경을 보고 IOPS·Latency를 같이 봅니다. CPU Core Queue처럼 「수요 > Capacity」 신호일 수 있지만 QD 0이 항상 최선은 아닙니다 — Backup은 깊은 QD로 처리량을 쓸 수 있고 Web API DB는 Tail을 막아야 합니다. Worker·Connection Pool을 Benchmark 없이 키우면 Storage QD가 폭증합니다. Profiling에서 코드 10ms·전체 2초면 Worker/DB Pool/Storage Queue 대기를 찾습니다(Scheduling·iowait). SEO 전용 지표는 아니지만 Timeout·5xx면 UX에 간접 영향(모니터링·503).

초보 FAQ

QD가 높으면 무조건 좋은가?

아닙니다. Latency·Throughput 균형을 봐야 합니다.

QD와 Concurrency 차이?

Concurrency는 App 동시 작업 수, QD는 Storage에 제출된 I/O 수입니다.

QD↑ IOPS 정체면?

Storage Saturation을 의심합니다.

광고 최대 IOPS만 믿어도 되나?

QD·Block Size 조건을 함께 봅니다. Desktop 체감은 QD1이 중요할 수 있습니다.

정리

Queue Depth = Storage에 동시에 제출되어 처리·대기 중인 I/O 수입니다. 적절히 높이면 내부 병렬성으로 IOPS·Throughput이 늘 수 있고, Capacity를 넘기면 Throughput은 거의 그대로인데 Latency만 커집니다. 좋은 시스템은 Queue만 키우는 것이 아니라 Storage가 감당할 수준으로 요청량을 조절합니다. Storage가 초당 10,000건만 처리하는데 App이 20,000건을 계속 보내면 QD는 끝없이 늘고 Memory·Latency도 같이 커질 수 있습니다. 이처럼 Consumer가 처리할 수 있는 속도에 맞춰 Producer의 생성·전송 속도를 조절하는 원리Backpressure(백프레셔)라고 합니다.