새로운 전용 서버에서 수행하는 깨끗한 fio 또는 dd 벤치마크는 동시적이고 혼합된 패턴의 운영 부하(production load) 하에서의 실제 I/O 성능과는 동일하지 않습니다. 이 두 가지 사이의 격차는 생각보다 많은 팀을 곤경에 빠뜨립니다.

새로운 전용 서버를 준비하는 모든 팀은 어느 시점에 동일한 의식을 치릅니다. 서버를 구동하고, SSH로 접속하여, fio, dd, iozone 등 팀이 선호하는 도구로 빠른 스토리지 벤치마크를 실행한 뒤, 훌륭하게 나오는 수치들을 지켜봅니다. 초당 기가바이트 단위의 순차 쓰기 처리량(Sequential write throughput). 1밀리초 미만의 읽기 지연 시간(Read latency). 모든 것이 벤더의 사양서(spec sheet)가 약속한 것과 정확히 일치해 보입니다.

하지만 데이터베이스가 라이브 상태가 되고 실제 트래픽이 유입되면, 부하 상황에서의 쿼리 지연 시간(query latency)은 벤치마크가 암시했던 것과 전혀 일치하지 않습니다. 합성 스토리지 벤치마크(synthetic storage benchmarks)와 실제 운영 I/O 동작 사이의 이러한 격차는 전용 서버 성능 계획에서 가장 지속적으로 과소평가되는 요인 중 하나이며, 왜 이런 일이 발생하는지 정확히 이해할 가치가 있습니다.

순차 벤치마크가 (의도치 않게) 거짓말을 하는 이유

대부분의 엔지니어가 사용하는 기본 스토리지 벤치마크는 순차 읽기 또는 쓰기 처리량(sequential read or write throughput), 즉 하나의 크고 연속적인 데이터 블록을 가능한 한 빠르게 쓰거나 읽는 것을 테스트합니다. 이는 스토리지 하드웨어의 이론적 한계치를 이해하는 데 진정으로 유용한 수치입니다. 하지만 이것이 실제 운영 데이터베이스가 수행하는 작업의 대표성을 띠는 경우는 거의 없습니다.

실제 데이터베이스 워크로드(workloads)는 순차적(sequential)인 것이 아니라 무작위 I/O(random I/O)가 지배적입니다. 동시 접속 사용자를 처리하는 트랜잭션 데이터베이스는 디스크 전체에 걸쳐 작고 흩어진 데이터 블록을 끊임없이 읽고 씁니다. 인덱스 조회(index lookups), 행 업데이트(row updates), 쓰기 전 로그(write-ahead log) 항목 등이 모두 서로 뒤섞여 있으며, 종종 여러 연결에서 동시에 발생합니다.

_함께 읽어보세요 - 지연 시간 지도: 서버 위치는 생각보다 더 중요합니다

NVMe 스토리지 (storage)는 기존의 회전식 디스크 (spinning disk)나 심지어 SATA SSD 기술보다 무작위 I/O (random I/O)를 훨씬 더 잘 처리하며, 이것이 바로 NVMe가 본격적인 데이터베이스 워크로드 (workload)의 표준이 된 정확한 이유입니다. 하지만 "대안보다 훨씬 더 낫다"는 말이 "순차적 벤치마크 (sequential benchmark) 수치와 동일하다"는 의미는 아닙니다. 순차 쓰기 (sequential write) 테스트에서 3.5 GB/s를 제공하는 드라이브라도, 높은 큐 깊이 (queue depth)와 동시 접속 (concurrent access)이 발생하는 실제 무작위 I/O (random I/O) 패턴 하에서는 유의미하게 다르고 더 가변적인 성능을 보일 수 있습니다.

큐 깊이 (Queue Depth) 문제

여기서 끊임없이 간과되는 세부 사항이 있습니다. 대부분의 기본 벤치마크 설정은 큐 깊이 (queue depth) 1에서 테스트를 수행한다는 점입니다. 이는 한 번에 하나의 I/O 작업만 처리 중임을 의미합니다. 이는 장치의 내부 리소스에 대한 경합 (contention)이 없기 때문에 가능한 가장 낮은 지연 시간 (latency) 수치를 만들어냅니다.

실제 부하 하의 운영 데이터베이스 (production databases)는 서로 다른 연결 (connections)과 스레드 (threads)로부터 많은 작업이 동시에 처리되는 훨씬 더 높은 유효 큐 깊이 (effective queue depths)에서 작동합니다. 큐 깊이 (queue depth)가 증가함에 따라, 훌륭한 하드웨어에서도 개별 작업의 지연 시간 (latency)은 일반적으로 함께 증가합니다. 이는 단순히 작업들이 하부 장치의 컨트롤러 (controller)의 주의를 끌기 위해 서로의 뒤에서 대기하게 되기 때문입니다.

큐 깊이 (queue depth) 1에서 실행된 벤치마크와 유효 큐 깊이 (effective queue depth) 32 또는 64에서 실행되는 운영 워크로드 (production workload)는 동일한 물리적 드라이브를 사용하더라도 근본적으로 다른 것을 테스트하고 있는 것입니다. 기본 설정으로 벤치마크를 수행한 뒤 그 수치를 외삽 (extrapolate)하여 동시 부하 하의 운영 성능을 예측하는 팀들은, 자신도 모르게 서로 다른 두 가지 시나리오를 비교하고 있는 것입니다.

실제 부하 하에서 실제로 변하는 것

파일 시스템 및 데이터베이스 엔진 오버헤드 (Filesystem and database engine overhead). 로우 블록 디바이스 (Raw block-device) 벤치마크는 실제 쿼리가 거치는 파일 시스템 및 데이터베이스 엔진 로직의 상당 부분을 우회합니다. Write-ahead logging (WAL), 저널링 (journaling), 체크섬 (checksumming), 그리고 트랜잭션 커밋 세맨틱스 (transaction commit semantics)는 모두 로우 dd 테스트에서는 전혀 접할 수 없는 오버헤드를 추가합니다. 강력한 내구성 (durability) 보장을 위해 구성된 데이터베이스 (동기식 커밋 (synchronous commits), 모든 쓰기 작업에 대한 fsync 적용)는 로우 스토리지 벤치마크와 유의미하게 다른 I/O 레이턴시 (latency) 특성을 보일 것입니다. 왜냐하면 논리적 연산당 실제로 더 많은 작업을 수행하기 때문입니다.

동시 프로세스로 인한 리소스 경합 (Resource contention from concurrent processes). 갓 프로비저닝되어 다른 작업이 없는 전용 서버는 스토리지 벤치마크에 I/O 서브시스템 전체를 독점적으로 제공합니다. 반면 운영 서버는 애플리케이션 레이어 (application layer), 백그라운드 작업 (background jobs), 모니터링 에이전트 (monitoring agents), 로그 전송 (log shipping), 그리고 종종 동시에 실행되는 여러 데이터베이스 연결까지 함께 실행하며, 이 모든 것들이 동일한 기반 I/O 리소스를 두고 경쟁합니다. 깨끗한 상태에서 수행되는 벤치마크 실행 중에는 이러한 경합이 전혀 존재하지 않습니다.

발열 및 지속 쓰기 동작 (Thermal and sustained-write behavior). 많은 NVMe 드라이브는 뛰어난 버스트 성능 (burst performance)을 보여주지만, 온보드 캐시 (onboard cache)가 소진되고 컨트롤러가 장시간의 쓰기 집약적 기간 동안 열 부하 (thermal load)를 관리해야 하면 지속 쓰기 처리량 (sustained write throughput)이 감소하는 모습을 보입니다. 짧은 벤치마크 실행은 버스트 성능만을 포착합니다. 수 시간 동안 지속적인 헤비 쓰기 부하를 받는 데이터베이스는 드라이브의 실제 지속 성능 특성에 직면할 수 있으며, 이는 헤드라인에 나오는 버스트 수치보다 유의미하게 낮을 수 있습니다.

RAID 구성 오버헤드 (RAID configuration overhead). 만약 전용 서버가 중복성 (redundancy)을 위해 RAID를 사용한다면 — 대부분의 운영 데이터베이스 배포 환경은 그래야 합니다 — 선택된 RAID 레벨에 따라 쓰기 작업에 패리티 계산 (parity calculation) 또는 미러링 (mirroring)을 위한 추가 오버헤드가 발생합니다. 단일 디스크 벤치마크는 이를 포착하지 못하며, 이 오버헤드는 RAID 1, RAID 5, RAID 10, 그리고 소프트웨어 대 하드웨어 RAID 구현 방식에 따라 크게 달라집니다.

실제 운영 동작을 실제로 예측할 수 있는 벤치마크 방법

단순한 순차적 (sequential) 접근이 아닌, 실제와 유사한 액세스 패턴 (access patterns)으로 테스트하세요. 기본값인 대규모 순차 블록 테스트에 의존하지 말고, fio(또는 선택한 벤치마킹 도구)를 설정하여 실제 데이터베이스의 전형적인 I/O 크기(데이터베이스 엔진에 따라 보통 4K, 8K 또는 16K)와 일치하는 혼합 무작위 읽기/쓰기 (mixed random read/write) 패턴을 사용하도록 구성하세요.

실제적인 큐 깊이 (queue depths)에서 테스트하세요. 단순히 큐 깊이 1에서만 테스트하지 말고, 예상되는 동시 접속 수 (concurrent connection count)와 유사한 수치를 포함하여 다양한 큐 깊이에서 벤치마킹을 수행하세요. 이를 통해 단일한 낙관적인 수치가 아닌 지연 시간 곡선 (latency curve)을 얻을 수 있으며, 이 곡선은 용량 계획 (capacity planning)에 훨씬 더 유용합니다.

짧은 버스트 (burst)가 아닌 지속적인 테스트를 실행하세요. 30초 동안의 벤치마크는 버스트 성능만을 포착합니다. 버스트 테스트가 완전히 놓치는 지속적인 처리량 (throughput) 저하 현상을 드러내려면 15~30분 또는 그 이상 동안 테스트를 실행하세요.

단순한 로우 스토리지 (raw storage) 도구만이 아니라, 실제적인 동시 부하 (concurrent load) 상황에서 실제 데이터베이스 엔진으로 벤치마킹하세요. 대표적인 스키마 (schema)와 쿼리 혼합 (query mix)으로 구성된 데이터베이스 전용 벤치마킹 도구인 sysbench와 같은 도구를 사용하면, 로우 스토리지 벤치마크로는 포착할 수 없는 엔진 레벨의 오버헤드 (engine-level overhead)를 드러낼 수 있습니다. 이는 단일 로우 I/O 도구보다 운영 환경의 동작을 훨씬 더 의미 있게 예측해 줍니다.

격리된 환경이 아닌 경합 (contention) 상황에서 검증하세요. 가능하다면, 실제 애플리케이션의 리소스 점유율 (resource footprint)과 유사한 합성 CPU 및 메모리 부하를 스토리지 벤치마크와 동시에 실행하여, 서버 내에서 I/O가 유일한 작업이 아닐 때 I/O 성능이 어떻게 유지되는지 포착하세요.

정직한 결론 (The Honest Bottom Line)

새로 프로비저닝된 (provisioned) 전용 서버에서 얻은 깨끗한 벤치마크 수치는 해당 하드웨어가 성능을 발휘할 능력이 있다는 것을 알려줍니다. 하지만 그것이 실제 운영 워크로드 (workload)의 구체적이고, 무질서하며, 동시적이고, 혼합된 패턴의 현실 속에서 해당 하드웨어가 어떻게 동작할지는 알려주지 않습니다. 이 두 가지 사이의 격차는 하드웨어가 나쁘다거나 제공업체가 무언가를 잘못 설명했다는 신호가 아닙니다. 이는 단순히 합성 벤치마크 (synthetic benchmarks)와 운영 워크로드가 근본적으로 다른 시나리오를 테스트하고 있다는 사실을 반영할 뿐입니다.

합성 벤치마크 수치만을 기반으로 용량 계획 (capacity planning) 모델을 구축하는 팀은 실제 성능을 체계적으로 과장하는 데이터를 바탕으로 작업하고 있는 것입니다. 해결책은 벤치마크를 불신하는 것이 아닙니다. 하드드로 수행할 작업과 실제로 유사한 벤치마크를 실행하고, 용량 계획을 확정하기 전에 실제 애플리케이션 동작과 대조하여 해당 결과들을 검증하는 것입니다.