VPS에서 NVMe와 SSD 차이가 중요한가?

VPS에서 NVMe가 중요한가?

소프트웨어가 작은 읽기 및 쓰기 작업을 많이 보내고 각 작업이 완료될 때까지 기다리는 경우 VPS에서 NVMe가 중요합니다. 캐시된 페이지를 제공하는 사이트나 네트워크를 기다리는 데 대부분의 시간을 사용하는 프로그램에서는 NVMe가 성능을 거의 바꾸지 않습니다. 저장 매체는 여러 요인 중 하나입니다. 디스크 앞의 hypervisor와 동일한 호스트를 공유하는 다른 게스트가 실제로 얻을 수 있는 성능의 상한을 결정합니다.

NVMe가 변경하는 것과 변경하지 않는 것

NVMe(non-volatile memory express)는 플래시 메모리의 한 종류가 아니다. 플래시에 접근하는 데 사용하는 프로토콜이자 연결 방식이다. NVMe 장치는 PCIe(peripheral component interconnect express) 레인에 연결되어 NVMe 프로토콜로 통신한다. SATA(serial ATA) SSD는 SATA 링크에 연결되어 AHCI(advanced host controller interface) 프로토콜로 통신한다. 데이터를 저장하는 메모리 칩은 두 방식에서 동일할 수 있다.

달라지는 것은 2가지이며, 둘 다 스토리지 자체가 아니라 명령 경로와 관련된다.

큐. AHCI는 커널에 32개의 명령을 저장하는 명령 큐 1개를 제공한다. NVMe는 수천 개의 큐를 허용하며, 실제로는 CPU 코어당 1개씩 사용할 수 있고 각 큐의 깊이도 32보다 훨씬 크다. 한 프로세스가 한 번에 블록 1개를 읽는 경우에는 이 차이를 확인할 수 없다. 64개의 읽기 요청을 동시에 처리하는 데이터베이스에서는 차이가 나타난다. SATA에서는 33번째 요청이 큐 슬롯을 기다린 후에야 장치에 전달되지만, NVMe 장치는 모든 요청을 받아 동시에 처리한다.

링크 폭. SATA III 링크는 6 Gbit/s로 동작하며, 프로토콜 오버헤드를 제외하면 실제 데이터 전송량은 약 550 MB/s이다. 링크 뒤에 어떤 플래시 메모리가 있든 이 한계는 고정된다. PCIe 레인 4개는 초당 수 GB를 전송하므로 링크가 더 이상 병목이 되지 않는다.

지연 시간에서는 일반적인 예상이 자주 빗나간다. 큐 깊이 1, 즉 처리 중인 요청이 1개인 경우 SATA SSD는 4k 읽기 요청에 약 100~150마이크로초 만에 응답한다. NVMe는 약 80~100마이크로초 만에 응답한다. 두 방식 모두 빠르므로 단일 요청에서는 실행 중인 어떤 작업도 그 차이를 감지하지 못한다. 동시성이 높아지면 차이가 나타난다. 큐 깊이, 즉 동시에 처리 중인 요청 수가 두 매체가 비슷하게 보일지 매우 다르게 보일지를 결정하는 설정이다.

네트워크 블록 스토리지는 작동 방식이 다른 세 번째 유형이다. 쓰기 요청은 네트워크를 통해 스토리지 클러스터로 전달되고 클러스터가 데이터를 보유한 후에만 확인 응답을 반환하므로, 지연 시간은 마이크로초가 아니라 밀리초 단위로 측정된다. 이 지연 시간을 감수하고 얻는 것은 내구성이다. 볼륨은 연결된 호스트가 종료된 후에도 유지되며, 스냅샷을 생성하고 크기를 조정할 수 있다.

일반적으로 공개되는 수치: NVMe, SATA SSD 및 네트워크 스토리지

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

로컬 NVMe 장치는 일반적으로 queue depth 32에서 184,000회의 무작위 4k 읽기 IOPS(초당 입출력 작업)로 소개됩니다. SATA SSD에서 동일한 테스트를 수행하면 약 90,000회로 소개됩니다. 단일 AHCI queue와 6 Gbit/s 링크의 제약을 받기 때문입니다. 네트워크 블록 스토리지는 일반적으로 하드웨어가 아니라 공급자가 한도를 설정하며, 12,500가 문서에 자주 명시되는 상한입니다.

지연 시간은 사용자가 체감하는 단위에서도 같은 차이를 보여 줍니다. p99 읽기 지연 시간은 요청 중 가장 느린 1%를 의미하며, 로컬 NVMe에서는 약 0.4 ms, SATA에서는 1.2 ms입니다. 경로에 네트워크가 추가되면 6.5 ms가 되어 NVMe 수치보다 10배 이상 길어집니다.

순차 읽기 성능의 차이가 가장 크지만, 유용성은 가장 낮습니다. 수치는 3,400 MB/s와 550 MB/s입니다. 서버에서 하나의 큰 파일을 처음부터 끝까지 최고 속도로 읽는 작업은 거의 없습니다. 데이터베이스, 메일 queue 또는 package manager의 실제 동작을 설명하는 것은 무작위 처리량과 지연 시간입니다.

디스크의 영향을 받는 워크로드

모든 경우에 적용되는 한 가지 원칙이 있습니다. 워크로드는 디스크를 기다릴 때만 디스크의 영향을 받습니다. Linux는 최근에 사용한 파일 데이터를 page cache인 RAM에 유지하므로, 파일을 두 번째로 읽을 때는 storage에 접근하지 않습니다. 실제로 사용 중인 데이터인 working set이 RAM에 들어가면 첫 번째 읽기 이후의 읽기는 memory 읽기가 됩니다. 쓰기는 다릅니다. 애플리케이션이 fsync()으로 flush하는 모든 쓰기는 애플리케이션이 계속 실행되기 전에 stable storage에 기록되어야 합니다.

commit을 수행하는 작업. PostgreSQL, MySQL, SQLite는 commit할 때 fsync() 또는 fdatasync()를 호출하며, 각 commit은 device의 응답을 기다립니다. 따라서 하나의 connection에서 발생하는 commit rate는 bandwidth가 아니라 write latency로 결정됩니다. 0.2 ms에 flush하는 device는 5 ms가 걸리는 device보다 초당 훨씬 많은 commit을 처리할 수 있으며, throughput을 아무리 높여도 이 차이는 바뀌지 않습니다. flush가 처리 속도를 따라가지 못하면 MySQL은 error log에 이를 기록합니다.

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL은 checkpoint line에 이 문제를 기록합니다. 여기서 큰 sync= 값은 flush 자체가 느렸다는 뜻입니다.

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

작은 파일을 많이 처리하는 작업. 모든 파일에는 큰 sequential read 하나에는 없는 metadata 작업이 수반됩니다. 큰 repository에서 npm install, git clone, container image 압축 해제, Maildir mail store, 큰 tree를 순회하는 backup은 모두 작은 random access에 시간을 사용합니다. VPS에서 실행되는 restic backup 작업은 이전에 처리하지 않은 모든 파일을 읽고 hash를 계산하므로, 백만 개 파일을 backup하는 데 걸리는 wall-clock time은 random read latency와 밀접하게 연관됩니다. metadata만 읽는 du -sh도 마찬가지입니다.

RAM을 초과할 정도로 커진 database도 여기에 해당합니다. index가 page cache에 더 이상 들어가지 않으면 모든 lookup이 random read가 되며, disk가 다시 critical path에 포함됩니다.

디스크를 인식하지 못하는 워크로드는 무엇입니까

블로그 또는 소규모 회사 사이트입니다. 페이지가 작고, 첫 번째 요청 이후 페이지 캐시에 모든 페이지가 저장됩니다. 이 경우 한계 요인은 렌더링에 필요한 CPU 또는 정적 자산을 전송하는 대역폭입니다. 트래픽이 적은 사이트를 제공하는 Ubuntu 24.04의 LAMP 스택은 캐시가 예열된 후 디스크 IO를 거의 수행하지 않습니다.

미디어 스트리밍입니다. 4K 스트림 1개는 40 Mbit/s로 데이터를 읽으며, 이는 5 MB/s입니다. 10개 스트림은 50 MB/s를 읽습니다. 이 정도는 네트워크 블록 스토리지도 무리 없이 처리합니다. VPS에서 실행하는 Jellyfin 미디어 서버의 성능은 스토리지 매체가 아니라 네트워크 송신량 제한과 트랜스코딩 시 필요한 CPU에 의해 제한됩니다.

로컬 모델 추론입니다. LLM을 직접 호스팅하기 위해 VPS에서 Ollama 실행은 모델 파일을 한 번 읽은 다음 RAM에서 작업합니다. NVMe는 20 GB 모델의 로드 시간을 몇 분에서 몇 초로 줄입니다. 그러나 메모리 대역폭과 CPU에 의해 결정되는 초당 토큰 수는 변경하지 않습니다.

외부 서비스를 기다리는 모든 작업입니다. 작업 하나당 HTTP 요청에 800 ms를 사용하는 워커는 더 빠른 디스크를 사용해도 빨라지지 않습니다.

매체만큼 하이퍼바이저가 중요한 이유

장치와 직접 통신하지 않습니다. 일반적으로 virtio를 통해 하이퍼바이저가 제공하는 가상 디스크와 통신합니다. 이 계층의 여러 결정이 NVMe와 SATA의 차이보다 더 큰 영향을 줍니다.

게스트 내부에서는 매체를 확인할 수 없습니다. lsblk -d -o NAME,ROTA,SIZE,MODEL은(는) 모델 정보가 비어 있는 vda을(를) 표시합니다. virtio가 드라이브 식별 정보를 전달하지 않기 때문입니다. cat /sys/block/vda/queue/rotational은(는) 하이퍼바이저가 광고하는 값을 보고하므로, 해당 값이 0이라고 해서 플래시 저장 장치라는 증거는 아닙니다. nvme-cli 패키지에서 제공하는 nvme list은(는) 호스트에 NVMe 드라이브가 가득 차 있어도 대부분의 VPS에서 아무것도 표시하지 않습니다. 사용자의 디스크는 NVMe 장치가 아니라 virtio 장치이기 때문입니다. NVMe라고 표시된 요금제는 일반적으로 호스트에 포함된 저장 장치를 설명합니다. 사용자의 볼륨은 여전히 네트워크 연결 방식일 수 있습니다.

호스트 캐시 모드는 매체보다 측정값을 더 크게 바꿉니다. 호스트에서 writeback 캐싱을 사용하면 게스트의 fsync()이(가) 호스트가 자체 RAM에 데이터를 저장한 즉시 반환될 수 있습니다. 그러면 물리적 장치가 제공할 수 없는 벤치마크 결과가 나옵니다. 또한 호스트가 충돌하면 데이터베이스가 안전하다고 판단한 쓰기 작업이 손실될 수 있습니다. 캐시 모드가 none이면 측정값은 더 낮지만 실제 성능을 정직하게 반영합니다.

제한과 버스트 크레딧. 많은 공급자는 볼륨 또는 요금제별 IOPS를 제한합니다. 또한 많은 네트워크 볼륨은 버스트 허용량을 사용합니다. 버스트 허용량은 크레딧 풀입니다. 크레딧이 남아 있는 동안 볼륨은 빠르게 동작하고, 크레딧을 모두 사용하면 훨씬 낮은 기준 성능으로 떨어집니다. 증상은 쉽게 확인할 수 있습니다. 가져오기 또는 복원이 몇 분 동안 빠르게 실행된 후 급격히 느려지고, 구성은 변경하지 않았는데 느린 상태가 계속됩니다. 크레딧을 모두 사용한 것입니다.

이웃 테넌트. 공유 호스트에서는 다른 게스트가 수행하는 작업에 따라 디스크 지연 시간이 달라집니다. 따라서 한 번 이상 측정해야 합니다. 같은 테스트를 아침에 실행하고 저녁에 다시 실행한 다음 결과의 편차를 비교합니다. 부하가 높은 호스트에서는 같은 볼륨에서 실행한 두 번의 결과 차이가 게시된 두 매체 간 성능 차이보다 큰 경우가 많습니다.

VPS에 실제로 할당된 디스크 측정 방법

표준 IO 벤치마크인 fio를 설치하고 측정합니다. 먼저 3가지를 주의해야 합니다. 테스트는 파일을 생성하므로 디스크 공간을 사용합니다. 또한 청구되는 IOPS 허용량에도 포함됩니다. 실행 시간은 짧게 유지합니다. 실시간 트래픽을 처리하는 볼륨에 최대 queue depth로 실행하지 마십시오. 자체 애플리케이션과 디스크를 함께 사용하게 됩니다.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

공급업체가 제시하는 queue depth인 32에서 무작위 읽기를 수행합니다.

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

중요한 줄은 read:로 시작합니다.

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1은 guest page cache를 우회합니다. 따라서 결과는 RAM이 아니라 장치의 성능을 나타냅니다. 이 옵션을 생략하면 메모리 성능을 측정하게 됩니다. 그러면 어떤 디스크도 도달할 수 없는 값이 반환됩니다. 공간이 있다면 --size=4G 이상을 사용하십시오. 1G 파일은 호스트의 cache에 전부 들어갈 수 있어 결과가 실제보다 높게 나타날 수 있습니다.

queue depth 1은 원시 latency를 보여 줍니다. 단일 스레드 프로세스가 체감하는 값입니다.

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

commit 테스트는 데이터베이스 동작을 예측합니다. 4k를 기록한 후 매번 fdatasync()을 호출하므로 보고되는 속도에는 flush 시간이 포함됩니다.

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

이 실행에서 얻은 IOPS 수치는 하나의 데이터베이스 연결이 commit할 수 있는 작은 트랜잭션의 초당 최대 수에 가깝습니다. commit은 동일한 flush가 완료될 때까지 기다리기 때문입니다.

fio 없이 빠르게 측정하려면 다음을 실행합니다.

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

평균 편차를 나타내는 mdev 값은 평균값만큼 중요합니다. 유휴 상태인 서버에서 편차가 크다면 storage backend를 여러 사용자가 공유하고 있으며 사용량이 높은 상태라는 의미입니다.

결과 읽는 방법

2026년 7월 기준으로 소형 VPS에서는 다음과 같이 해석할 수 있습니다. queue depth 32에서 4k random read IOPS가 수만이고 queue depth 1 latency가 약 0.3 ms 미만이면 로컬 flash와 일치합니다. queue depth 1 latency가 수 ms이면 요금제가 무엇으로 불리든 network path를 의미합니다. 550 MB/s 부근에서 멈추는 sequential read는 SATA link의 특징입니다. 단일 device가 처리할 수 있는 한계를 훨씬 초과하는 수치는 거의 항상 host에서 caching이 수행되고 있음을 의미합니다.

실시간 workload가 disk에 미치는 영향을 확인하려면 다음을 실행합니다.

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

iostat -x 출력에서 요청이 대기한 평균 시간(밀리초)인 r_await 및 w_await와 평균 queue length인 aqu-sz를 확인합니다. virtual disk에서는 %util을 무시합니다. %util은 하나 이상의 요청이 outstanding 상태였던 시간의 비율을 보고합니다. 따라서 여러 요청을 동시에 처리하는 device의 saturation 여부는 알 수 없습니다. 그러므로 r_await이 0.2 ms일 때 %util이 100이라도 disk가 정상적으로 바쁜 상태일 수 있습니다. vmstat에서는 wa 열이 IO 대기에 사용된 CPU time의 비율입니다. kernel에 /proc/pressure/io이 있으면 some avg10= 값은 최근 10초 동안 하나 이상의 task가 IO 때문에 stalled 상태였던 시간의 비율입니다. 이는 storage가 bottleneck인지 판단하는 가장 직접적인 지표입니다.

디스크 병목 VPS의 상태

CPU가 유휴 상태인데 load average가 높고 wa의 vmstat 값이 크면 프로세스가 디스크 작업 뒤에서 대기 중이라는 뜻입니다. 가장 명확한 커널 신호는 dmesg -T에 기록되는 다음 메시지입니다.

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

이 줄은 커널 스레드가 스토리지의 응답을 2분 넘게 기다렸기 때문에 나타납니다. 따라서 hung task watchdog이 이를 기록한 것입니다. jbd2은 ext4 저널 스레드입니다. 이는 문제가 있는 프로그램 하나가 아니라 파일 시스템 전체가 대기 중이었다는 뜻입니다. VPS에서는 일반적으로 스토리지 백엔드에 문제가 있거나 IOPS 할당량을 모두 사용했다는 의미입니다.

애플리케이션 증상도 같은 양상을 보입니다. 디스크에 접근하는 요청만 지연되므로 중앙값 응답 시간은 허용 가능한 수준으로 유지되지만 가장 느린 요청의 지연 시간은 긴 꼬리를 형성합니다. apt upgrade은 dpkg가 쓰기 작업을 수행하면서 데이터를 flush하기 때문에 수분 동안 Unpacking 상태에 머뭅니다. 대규모 저장소에서 git status을 수행하면 몇 초가 걸립니다. 이는 메타데이터 및 flush 비용이므로 대역폭을 늘려도 해결되지 않습니다.

디스크가 한계일 때 수행할 작업

IOPS를 구매하기 전에 RAM을 구매합니다. 작업 세트가 페이지 캐시에 들어가면 읽기 작업이 디스크에 전혀 도달하지 않습니다. 메모리를 2배로 늘리는 것이 더 빠른 스토리지 클래스로 이전하는 것보다 효과적인 경우가 많고, 일반적으로 비용도 더 적게 듭니다.

데이터 특성상 허용된다면 flush 횟수를 줄입니다. PostgreSQL에서 synchronous_commit = off를 사용하면 쓰기 작업이 디스크에 기록되기 전에 commit이 반환될 수 있습니다. 서버가 중단되면 마지막 몇 분의 1초 동안의 트랜잭션을 잃을 수 있습니다. write-ahead log가 여전히 순서대로 기록되므로 데이터베이스는 손상되지 않습니다. 이 방식은 분석용 복제본에는 적합하지만 결제 시스템에는 적합하지 않습니다. MySQL의 innodb_flush_log_at_trx_commit = 2도 동일한 방식입니다.

작은 파일을 일괄 처리합니다. 작은 파일 1000000개의 전송 또는 백업은 파일별 처리 비용의 영향을 크게 받습니다. 따라서 먼저 아카이브한 후 하나의 스트림으로 이동하면, 파일 트리의 각 파일을 개별적으로 복사하는 것보다 지연 시간이 긴 스토리지에서 더 빠릅니다.

thin volume에서 discard가 작동하도록 유지합니다. thin provisioned storage에서는 파일 시스템이 블록이 비어 있다고 알리기 전까지 backend가 해당 블록을 사용할 수 없다는 사실을 알지 못합니다. trim을 전혀 수행하지 않는 volume은 시간이 지나면서 쓰기 성능이 저하됩니다. Ubuntu는 이를 위한 weekly timer를 제공합니다.

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av는 각 mount point에서 trim된 bytes를 출력합니다. discard operation이 지원되지 않는다는 메시지는 virtual disk가 discard를 host로 전달하지 않는다는 의미이므로, 사용자가 수정할 문제는 없습니다.

IO scheduler 튜닝은 건너뜁니다. virtio disk에서는 cat /sys/block/vda/queue/scheduler가 일반적으로 이미 none를 표시합니다. 실제 scheduling은 사용자가 액세스할 수 없는 host에서 수행됩니다. noatime도 건너뜁니다. Ubuntu는 기본적으로 relatime로 mount하므로 atime 쓰기의 거의 대부분을 이미 방지합니다.

플랜 선택

데이터베이스, 메일 서버, CI runner 또는 패키지가 많은 빌드가 해당 서버에서 실행된다면 NVMe에 비용을 지불합니다. 캐시된 웹사이트나 외부 호출에 시간이 소요되는 애플리케이션에는 프리미엄을 지불하지 않습니다. 확신이 없다면 디스크가 병목이 아닐 가능성이 큽니다. 대부분의 소규모 VPS 워크로드는 디스크보다 RAM이나 bandwidth가 먼저 부족해집니다.

첫날에 새 VPS에서 처음 10분 동안 수행할 작업을 진행하면서 측정하고, 결과를 파일에 저장합니다. baseline은 나중에 호스트가 느려진 것인지 코드가 느려진 것인지 입증하는 기준입니다. 스토리지 등급과 IOPS 제한을 문서로 명시하는 provider를 우선 선택합니다. 플랜에 NVMe라고 적혀 있는데 queue depth 1 읽기 작업에 4 ms가 걸린다면, NVMe를 장착한 호스트에서 network storage를 사용하고 있는 것입니다. 이는 판매 가능한 서비스이지만, 구매하는 대상은 다릅니다.

FAQ

NVMe는 VPS에서 항상 SATA SSD보다 빠릅니까?

아닙니다. queue depth 1에서는 두 장치의 성능이 비슷합니다. 4k 읽기 기준으로 대략 80~150 microseconds입니다. 단일 스레드 프로그램에서는 차이를 확인하기 어렵습니다. 여러 요청이 동시에 처리 중일 때는 NVMe가 더 빠릅니다. AHCI는 깊이가 32개 명령인 queue 1개를 제공하지만, NVMe는 더 깊은 queue를 수천 개 제공합니다. 공유 host에서는 다른 guest의 부하가 저장 장치보다 latency에 더 큰 영향을 줄 수 있습니다. 따라서 plan 이름을 확인하는 대신 fio로 직접 사용하는 volume을 측정해야 합니다.

VPS가 실제로 NVMe를 사용하는지 어떻게 확인합니까?

직접 확인할 수 없습니다. virtio가 물리 장치를 숨기기 때문입니다. lsblk은 model 문자열 없이 vda을 표시하고, nvme list은 아무것도 반환하지 않으며, /sys/block/vda/queue/rotational은 hypervisor가 알리는 정보만 보고합니다. 대신 동작을 측정해야 합니다. queue depth 1에서 무작위 4k 읽기 latency가 약 0.3 ms 미만이면 로컬 flash일 가능성이 높습니다. 수 milliseconds가 걸리면 network hop이 경로에 있다는 뜻입니다. 순차 읽기 속도가 약 550 MB/s에서 멈추면 SATA link를 사용한다는 의미입니다.

NVMe를 사용하면 website가 더 빨리 로드됩니까?

대개 그렇지 않습니다. 첫 번째 요청 이후에는 Linux가 파일을 RAM의 page cache에서 제공하므로 disk는 유휴 상태가 됩니다. 소형 VPS에서 page speed는 일반적으로 application CPU time과 bandwidth의 제약을 받습니다. 사이트가 모든 요청에서 write를 수행하면 disk가 다시 critical path에 포함됩니다. 예를 들어 database-backed cart가 자주 commit하면 각 commit이 flush 완료를 기다려야 합니다.

VPS에서 좋은 fio 결과는 어느 정도입니까?

2026년 7월 기준으로 로컬 flash를 사용하는 소형 VPS는 일반적으로 queue depth 32에서 4k 무작위 읽기 IOPS 수만 건을 반환합니다. queue depth 1 latency는 0.3 ms 미만입니다. Network block storage는 일반적으로 수천 IOPS를 반환하며 latency는 수 milliseconds입니다. 서로 다른 시간대에 테스트를 3회 실행해야 합니다. 실행 결과의 편차가 크다면 평균보다 더 중요한 정보를 얻을 수 있습니다. 그 편차는 host의 다른 guest가 사용자에게 미치는 영향을 보여주기 때문입니다.

Database를 network block storage에 배치해야 합니까?

가능하며 많은 managed service가 그렇게 합니다. 그러나 commit path에서 network block storage의 비용을 부담해야 합니다. 모든 flush가 network를 통과하므로 단일 connection은 local flash를 사용할 때보다 초당 처리할 수 있는 작은 transaction 수가 적습니다. 그 대신 host 장애 이후에도 유지되는 durability를 얻습니다. Write-heavy database에 network storage를 선택한다면 작업을 더 큰 transaction으로 묶어야 합니다. 그러면 더 적은 수의 flush로 더 많은 row를 처리할 수 있습니다.