VPS 선택 시 NVMe와 SSD 성능 차이 비교

VPS에서 NVMe가 중요한가?

VPS에서 NVMe가 중요한 경우는 소프트웨어가 작은 읽기 및 쓰기 작업을 빈번하게 수행하고 각 작업이 완료될 때까지 대기해야 할 때입니다. 캐시된 페이지를 제공하는 사이트나 네트워크 대기 시간이 긴 프로그램의 경우에는 성능 차이가 거의 없습니다. 저장 매체는 하나의 요소일 뿐입니다. 실제 성능의 상한선은 디스크 앞단의 하이퍼바이저와 동일한 호스트를 공유하는 다른 게스트 환경에 의해 결정됩니다.

NVMe의 변화와 변하지 않는 것

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

두 방식의 차이는 저장 매체 자체가 아니라 명령 경로에 있습니다.

큐(Queues). AHCI는 커널에 32개의 명령을 담을 수 있는 단일 명령 큐를 제공합니다. NVMe는 수천 개의 큐를 허용하며, 실제로는 CPU 코어당 하나씩 할당하고 각 큐의 깊이도 32보다 훨씬 큽니다. 한 번에 하나의 블록을 읽는 프로세스는 이 차이를 체감할 수 없습니다. 하지만 64개의 읽기 요청이 동시에 발생하는 데이터베이스라면 다릅니다. SATA에서는 33번째 요청이 큐 슬롯이 빌 때까지 대기해야 장치가 이를 인식할 수 있지만, NVMe 장치는 모든 요청을 동시에 받아 처리합니다.

링크 대역폭(Link width). SATA III 링크는 6 Gbit/s로 동작하며, 프로토콜 오버헤드를 제외한 실제 데이터 전송 속도는 약 550 MB/s입니다. 이는 뒤에 어떤 플래시 메모리가 있든 고정된 한계치입니다. 반면 4개의 PCIe 레인은 초당 수 기가바이트를 전송할 수 있으므로, 링크 자체가 병목 현상을 일으키지 않습니다.

지연 시간(Latency)에 대해서는 흔히 잘못된 기대를 하기 쉽습니다. 큐 깊이가 1일 때, 즉 하나의 요청만 처리 중일 때 SATA SSD는 4k 읽기 요청에 약 100에서 150 마이크로초 내에 응답합니다. NVMe는 약 80에서 100 마이크로초 내에 응답합니다. 둘 다 매우 빠르며, 단일 요청만 수행하는 작업에서는 그 차이를 체감할 수 없습니다. 격차는 동시성 환경에서 벌어집니다. 한 번에 처리 중인 요청의 수인 큐 깊이가 두 매체의 성능이 비슷하게 보일지, 아니면 매우 다르게 보일지를 결정하는 핵심 설정입니다.

네트워크 블록 스토리지는 물리적 특성이 다른 제3의 범주입니다. 쓰기 작업은 네트워크를 거쳐 스토리지 클러스터로 전달되며, 클러스터가 데이터를 완전히 저장한 후에야 완료 응답을 보냅니다. 따라서 지연 시간은 마이크로초가 아닌 밀리초 단위로 측정됩니다. 이러한 지연 시간을 감수하는 이유는 내구성을 얻기 위해서입니다. 볼륨은 연결된 호스트보다 오래 유지되며, 스냅샷 생성 및 크기 조절이 가능합니다.

일반적인 발표 수치: 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 장치는 일반적으로 큐 깊이 32에서 184,000의 랜덤 4k 읽기 IOPS(초당 입출력 작업 수)를 기록합니다. SATA SSD에서 동일한 테스트를 수행하면 단일 AHCI 큐와 6 Gbit/s 링크의 제한으로 인해 90,000 근처의 수치가 나옵니다. 네트워크 블록 스토리지는 하드웨어보다는 제공업체에 의해 제한되는 경우가 많으며, 12,500가 흔히 문서화된 상한선입니다.

지연 시간(Latency)은 사용자가 체감하는 단위로 동일한 결과를 보여줍니다. 요청 중 가장 느린 1퍼센트를 의미하는 p99 읽기 지연 시간은 로컬 NVMe에서 약 0.4 ms이며, SATA에서는 1.2 ms입니다. 경로에 네트워크가 포함되면 6.5 ms가 되어 NVMe 수치보다 10배 이상 커집니다.

순차 읽기(Sequential read)는 가장 큰 격차를 보이지만 가장 덜 유용한 지표입니다. 3,400 MB/s 대 550 MB/s입니다. 서버에서 하나의 큰 파일을 처음부터 끝까지 최고 속도로 읽는 작업은 거의 없습니다. 랜덤 읽기 열과 지연 시간 열은 데이터베이스, 메일 큐 또는 패키지 관리자가 실제로 수행하는 작업을 설명합니다.

어떤 워크로드가 디스크를 체감하는가

모든 경우를 설명하는 하나의 규칙이 있습니다. 워크로드는 디스크를 기다릴 때만 디스크를 체감합니다. Linux는 최근에 사용한 파일 데이터를 RAM의 페이지 캐시(page cache)에 보관하므로, 파일에 대한 두 번째 읽기 작업은 스토리지까지 도달하지 않습니다. 실제로 사용 중인 데이터인 워킹 셋(working set)이 RAM 용량 안에 들어온다면, 첫 번째 읽기 이후의 모든 읽기 작업은 메모리 읽기로 처리됩니다. 쓰기 작업은 다릅니다. 애플리케이션이 fsync()을 호출하여 플러시(flush)하는 모든 쓰기 작업은, 애플리케이션이 다음 작업을 계속하기 전에 반드시 안정적인 스토리지에 기록되어야 합니다.

커밋을 수행하는 작업. PostgreSQL, MySQL, SQLite는 커밋 시점에 fsync() 또는 fdatasync()를 호출하며, 각 커밋은 장치의 응답을 기다립니다. 따라서 단일 연결의 커밋 속도는 대역폭이 아닌 쓰기 지연 시간(write latency)에 의해 결정됩니다. 0.2 ms 만에 플러시를 완료하는 장치는 5 ms가 걸리는 장치보다 초당 훨씬 더 많은 커밋을 처리할 수 있으며, 처리량(throughput)을 아무리 늘려도 이 사실은 변하지 않습니다. MySQL은 플러시 속도가 따라가지 못할 경우 에러 로그에 다음과 같이 기록합니다:

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

PostgreSQL은 체크포인트 라인에서 이를 보고하며, 여기서 큰 sync= 값은 플러시 작업 자체가 느렸음을 의미합니다:

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

많은 작은 파일을 다루는 작업. 모든 파일은 하나의 큰 순차 읽기 작업에는 없는 메타데이터 연산을 수반합니다. npm install, 대규모 저장소의 git clone, 컨테이너 이미지 압축 해제, Maildir 메일 저장소, 그리고 대규모 트리 구조를 탐색하는 백업 작업은 모두 작은 무작위 접근(random access)에 시간을 소비합니다. VPS에서의 restic 백업 작업은 이전에 보지 못한 모든 파일을 읽고 해시를 생성하므로, 백만 개의 파일을 처리하는 백업의 실제 소요 시간은 무작위 읽기 지연 시간과 밀접하게 연관됩니다. 메타데이터만 읽는 du -sh의 경우도 마찬가지입니다.

RAM 용량을 초과하는 데이터베이스도 여기에 해당합니다. 인덱스가 더 이상 페이지 캐시에 들어가지 않게 되면 모든 조회 작업이 무작위 읽기가 되며, 디스크는 다시 핵심 경로(critical path)로 돌아옵니다.

디스크 성능의 영향을 받지 않는 워크로드

블로그 또는 소규모 기업 사이트. 페이지 크기가 작아 첫 요청 이후에는 페이지 캐시가 모든 데이터를 보유하며, 렌더링을 위한 CPU나 에셋 전송을 위한 대역폭이 성능의 병목이 됩니다. 트래픽이 적은 사이트를 운영하는 Ubuntu 24.04 기반의 LAMP 스택은 캐시가 준비된 이후에는 디스크 I/O를 거의 발생시키지 않습니다.

미디어 스트리밍. 40 Mbit/s 속도의 4K 스트림 하나는 초당 5 MB를 읽습니다. 10개를 동시에 재생해도 초당 50 MB 수준이며, 이는 네트워크 블록 스토리지로도 충분히 감당할 수 있는 수치입니다. VPS에서 운영하는 Jellyfin 미디어 서버의 성능은 스토리지 매체가 아니라 네트워크 송신 허용량이나 트랜스코딩 시의 CPU 성능에 의해 제한됩니다.

로컬 모델 추론. LLM을 자체 호스팅하기 위해 VPS에서 Ollama를 실행하는 경우 모델 파일을 한 번 읽어 들인 뒤에는 RAM에서 작업이 수행됩니다. NVMe를 사용하면 20 GB 모델의 로드 시간을 분 단위에서 초 단위로 단축할 수 있지만, 메모리 대역폭과 CPU에 의해 결정되는 초당 토큰 생성 속도(tokens per second)에는 영향을 주지 않습니다.

외부 서비스를 대기하는 모든 작업. 작업당 800 ms를 HTTP 요청 대기에 소비하는 워커는 더 좋은 디스크를 사용한다고 해서 처리 속도가 빨라지지 않습니다.

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

사용자는 장치와 직접 통신하지 않습니다. 하이퍼바이저가 제공하는 가상 디스크와 통신하며, 보통 virtio를 통해 이루어집니다. 이 계층에서 내리는 몇 가지 결정은 NVMe와 SATA의 차이보다 더 큰 영향을 미칩니다.

게스트 내부에서는 매체를 확인할 수 없습니다. lsblk -d -o NAME,ROTA,SIZE,MODEL은 모델 정보가 비어 있는 vda을 보여줍니다. virtio는 드라이브 식별 정보를 전달하지 않기 때문입니다. cat /sys/block/vda/queue/rotational는 하이퍼바이저가 알리는 내용을 보고할 뿐이므로, 여기서 0이 출력된다고 해서 플래시 메모리라는 증거가 되지는 않습니다. nvme-cli 패키지에 포함된 nvme list은 대부분의 VPS에서 아무것도 나열하지 않습니다. 호스트가 NVMe 드라이브로 가득 차 있더라도, 사용자의 디스크는 NVMe 장치가 아닌 virtio 장치이기 때문입니다. NVMe를 명시한 플랜은 보통 호스트의 사양을 설명하는 것입니다. 사용자의 볼륨은 여전히 네트워크로 연결되어 있을 수 있습니다.

호스트 캐시 모드는 매체보다 성능 수치에 더 큰 영향을 줍니다. 호스트에서 writeback 캐싱을 사용하면, 호스트가 데이터를 자신의 RAM에 확보하는 즉시 게스트의 fsync()가 완료될 수 있습니다. 이는 물리적 장치로는 도달할 수 없는 벤치마크 결과를 만들어냅니다. 또한 호스트가 충돌할 경우 데이터베이스가 안전하다고 판단했던 쓰기 작업이 유실될 수 있음을 의미합니다. 캐시 모드를 none으로 설정하면 수치는 낮아지지만 더 정확한 결과를 얻을 수 있습니다.

제한 및 버스트 크레딧. 많은 제공업체가 볼륨별 또는 플랜별로 IOPS를 제한하며, 많은 네트워크 볼륨이 버스트 허용량을 사용합니다. 버스트 허용량은 크레딧 풀입니다. 크레딧이 남아 있는 동안 볼륨은 빠르게 작동하다가, 소진되면 훨씬 낮은 기본 성능으로 떨어집니다. 이 증상은 쉽게 식별할 수 있습니다. 데이터 가져오기나 복구 작업이 몇 분 동안은 빠르게 진행되다가 갑자기 느려진 뒤 계속 느린 상태로 유지된다면, 설정 변경 없이 크레딧을 모두 소진한 것입니다.

이웃 사용자. 공유 호스트 환경에서는 다른 게스트의 작업에 따라 디스크 지연 시간이 변합니다. 이것이 테스트를 여러 번 수행해야 하는 이유입니다. 같은 테스트를 아침과 저녁에 각각 실행하여 편차를 비교하십시오. 부하가 높은 호스트에서는 동일한 볼륨에서 수행한 두 번의 테스트 결과 차이가, 서로 다른 매체 간의 공식적인 성능 차이보다 큰 경우가 많습니다.

VPS의 실제 디스크 성능 측정 방법

표준 IO 벤치마크 도구인 fio를 설치하여 측정합니다. 먼저 세 가지 주의 사항이 있습니다. 이 테스트는 파일을 생성하므로 디스크 공간을 사용하며, 과금 대상인 IOPS 허용량에 포함됩니다. 테스트는 짧게 유지하십시오. 실제 트래픽을 처리 중인 볼륨에 대해 최대 큐 깊이(queue depth)로 테스트하지 마십시오. 본인의 애플리케이션과 자원 경쟁이 발생하기 때문입니다.

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

벤더가 사양으로 제시하는 큐 깊이 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은 게스트 페이지 캐시를 우회하므로, RAM이 아닌 디바이스 자체의 성능을 측정합니다. 이 옵션을 제외하면 디스크가 도달할 수 없는 메모리 속도가 측정됩니다. 공간이 충분하다면 --size=4G 이상의 크기를 사용하십시오. 1G 파일은 호스트 캐시에 완전히 적재되어 결과가 왜곡될 수 있습니다.

큐 깊이 1은 단일 스레드 프로세스가 체감하는 원시 지연 시간(raw latency)을 보여줍니다:

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

커밋 테스트는 데이터베이스의 동작을 예측합니다. 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 수치는 단일 데이터베이스 연결이 초당 커밋할 수 있는 작은 트랜잭션의 최대치와 비슷합니다. 커밋 역시 동일한 플러시 과정을 기다리기 때문입니다.

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 값인 평균 편차는 평균값만큼이나 중요합니다. 유휴 상태인 서버에서 편차가 크다면, 공유 스토리지 백엔드가 혼잡하다는 의미입니다.

결과 해석 방법

2026년 7월 기준으로, 다음은 소규모 VPS에서 합리적인 측정값입니다. 큐 깊이(queue depth) 32에서 수만 단위의 4k 랜덤 읽기 IOPS가 나오고 큐 깊이 1에서의 지연 시간이 약 0.3 ms 미만이라면 로컬 플래시 스토리지와 일치합니다. 큐 깊이 1에서의 지연 시간이 수 밀리초라면, 요금제 명칭과 관계없이 네트워크 경로를 거치는 스토리지입니다. 550 MB/s 부근에서 멈추는 순차 읽기 속도는 SATA 링크의 특징입니다. 단일 장치가 낼 수 있는 성능을 훨씬 상회하는 수치는 호스트 측의 캐싱이 개입하고 있음을 의미합니다.

현재 실행 중인 워크로드가 디스크에 미치는 영향을 확인하려면 다음을 수행합니다.

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

iostat -x 출력에서 r_await 및 w_await(요청이 대기한 평균 밀리초)와 aqu-sz(평균 큐 길이)를 확인합니다. 가상 디스크에서는 %util을 무시하십시오. 이 값은 최소 하나의 요청이 처리 중이었던 시간의 비율을 나타내는데, 여러 요청을 동시에 처리하는 장치의 포화 상태에 대해서는 아무런 정보를 주지 못합니다. 따라서 r_await이 0.2 ms인 상태에서 %util이 100인 것은 디스크가 정상적으로 바쁘게 작동하고 있음을 의미합니다. vmstat에서는 wa 열이 IO 대기에 소요된 CPU 시간의 비율을 나타냅니다. 커널에서 /proc/pressure/io을 지원하는 경우, some avg10= 값은 최근 10초 동안 최소 하나의 작업이 IO로 인해 지연된 시간의 비율을 나타내며, 이는 스토리지 병목 현상 여부를 판단하는 가장 직접적인 지표입니다.

디스크 제한이 걸린 VPS의 증상

CPU는 유휴 상태인데 로드 에버리지(load average)가 높고 wa이 vmstat에서 크게 나타난다면, 프로세스들이 디스크 I/O를 기다리며 대기열에 쌓여 있다는 뜻입니다. 커널이 보내는 가장 명확한 신호는 dmesg -T에 기록되는 다음 메시지입니다.

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

이 줄이 나타나는 이유는 커널 스레드가 스토리지의 응답을 2분 넘게 기다렸기 때문이며, 이에 따라 hung task watchdog이 해당 상황을 기록한 것입니다. jbd2은 ext4 저널 스레드이므로, 특정 프로그램의 문제가 아니라 파일 시스템 전체가 응답을 기다리고 있음을 의미합니다. VPS 환경에서 이는 대개 스토리지 백엔드 문제이거나 IOPS 할당량을 모두 소진했을 때 발생합니다.

애플리케이션의 증상도 같은 패턴을 보입니다. 디스크를 사용하는 요청만 지연되기 때문에 중앙값 응답 시간은 정상 범위에 머물지만, 가장 느린 요청들은 긴 꼬리(long tail)를 그리며 지연 시간이 늘어납니다. apt upgrade은 dpkg가 쓰기 작업을 수행하며 데이터를 플러시(flush)하기 때문에 압축 해제 단계에서 수 분씩 멈춰 있습니다. 대규모 저장소에서의 git status 작업도 수 초씩 소요됩니다. 이는 메타데이터 처리와 플러시 비용에 따른 문제이므로, 대역폭을 늘리는 것으로는 해결되지 않습니다.

디스크 용량이 한계에 도달했을 때의 대처법

IOPS를 구매하기 전에 RAM을 먼저 확보하십시오. 작업 세트가 페이지 캐시(page cache)에 들어갈 수 있다면 읽기 작업이 디스크까지 도달하지 않게 됩니다. 메모리를 두 배로 늘리는 것이 더 빠른 스토리지 클래스로 교체하는 것보다 나은 결과를 내는 경우가 많으며, 비용도 일반적으로 더 저렴합니다.

데이터가 허용하는 범위 내에서 플러시(flush) 횟수를 줄이십시오. PostgreSQL에서 synchronous_commit = off를 설정하면 쓰기 작업이 디스크에 기록되기 전에 커밋(commit)이 완료된 것으로 간주합니다. 서버가 갑자기 종료될 경우 마지막 1초 미만의 트랜잭션이 유실될 수 있습니다. 하지만 쓰기 선행 로그(write-ahead log)는 순서대로 기록되므로 데이터베이스 자체가 손상되지는 않습니다. 이러한 트레이드오프는 분석용 데이터 복제본에는 적합하지만, 결제 시스템에는 부적합합니다. MySQL의 innodb_flush_log_at_trx_commit = 2도 동일한 트레이드오프를 가집니다.

작은 파일들을 묶으십시오. 수백만 개의 작은 파일을 전송하거나 백업할 때는 파일당 발생하는 오버헤드가 전체 성능을 좌우합니다. 따라서 지연 시간이 긴 스토리지에서는 파일을 하나씩 복사하는 것보다 먼저 아카이브로 묶은 뒤 하나의 스트림으로 이동시키는 것이 훨씬 빠릅니다.

씬 프로비저닝(thin provisioned) 볼륨에서 discard가 작동하도록 유지하십시오. 씬 프로비저닝 스토리지에서는 파일 시스템이 알려주기 전까지 백엔드에서 블록이 비어 있다는 사실을 알지 못합니다. 따라서 trim 작업을 수행하지 않는 볼륨은 시간이 지날수록 쓰기 성능이 저하됩니다. Ubuntu는 이를 위해 매주 실행되는 타이머를 제공합니다.

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av은 마운트 지점별로 trim된 바이트 수를 출력합니다. discard 작업을 지원하지 않는다는 메시지가 나타난다면 가상 디스크가 호스트로 discard 명령을 전달하지 않는 것이므로, 사용자가 수정할 수 있는 부분은 없습니다.

IO 스케줄러 튜닝은 건너뛰십시오. virtio 디스크의 경우 cat /sys/block/vda/queue/scheduler를 확인하면 이미 none으로 설정되어 있는 경우가 많으며, 실제 스케줄링은 접근 권한이 없는 호스트 측에서 이루어집니다. noatime 또한 건너뛰어도 됩니다. Ubuntu는 기본적으로 relatime 옵션으로 마운트되는데, 이는 이미 대부분의 atime 쓰기 작업을 방지하고 있기 때문입니다.

요금제 선택

데이터베이스, 메일 서버, CI 러너 또는 패키지가 많은 빌드 작업을 서버에서 수행한다면 NVMe 요금제를 선택하십시오. 캐시된 웹사이트나 외부 호출에 대부분의 시간을 소비하는 애플리케이션에는 추가 비용을 지불할 필요가 없습니다. 확신이 서지 않는다면 디스크가 병목 지점일 가능성은 낮습니다. 대부분의 소규모 VPS 워크로드는 RAM이나 대역폭이 먼저 부족해지기 때문입니다.

새 VPS에서의 첫 10분 작업을 진행하는 첫날에 성능을 측정하고 그 결과를 파일로 보관하십시오. 기준점(baseline)은 나중에 호스트 성능이 저하되었는지, 아니면 본인의 코드 문제인지를 증명하는 근거가 됩니다. 스토리지 등급과 IOPS 제한을 명시하는 제공업체를 선택하십시오. 요금제에는 NVMe라고 되어 있는데 큐 깊이 1에서의 읽기 속도가 4 ms라면, 이는 NVMe가 장착된 호스트의 네트워크 스토리지를 사용하는 것입니다. 판매 측에서는 그럴 수 있는 일이지만, 구매자 입장에서는 분명히 다른 제품입니다.

FAQ

VPS에서 NVMe가 항상 SATA SSD보다 빠른가?

아닙니다. 큐 깊이(queue depth)가 1일 때는 두 방식의 성능 차이가 거의 없으며, 4k 읽기 기준 약 80에서 150 마이크로초 정도입니다. 단일 스레드 프로그램은 이 둘을 구분하지 못합니다. NVMe는 다수의 요청이 동시에 처리될 때 앞서 나갑니다. AHCI는 32개 명령어를 담는 큐를 하나만 제공하지만, NVMe는 수천 개의 더 깊은 큐를 제공하기 때문입니다. 공유 호스트 환경에서는 매체 자체의 성능보다 다른 게스트의 부하가 지연 시간에 더 큰 영향을 미칩니다. 따라서 요금제 이름만 보지 말고 fio를 사용하여 직접 볼륨 성능을 측정하십시오.

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

virtio가 물리 장치를 숨기기 때문에 직접 확인할 수는 없습니다. lsblk은 모델 문자열 없이 vda을 보여주며, nvme list은 아무것도 반환하지 않고, /sys/block/vda/queue/rotational는 하이퍼바이저가 알리는 정보만 보고합니다. 대신 동작을 측정하십시오. 큐 깊이 1에서 4k 랜덤 읽기 지연 시간이 약 0.3 ms 미만이라면 로컬 플래시를 사용하는 것입니다. 수 밀리초가 걸린다면 경로상에 네트워크 홉이 존재하는 것입니다. 순차 읽기 속도가 550 MB/s 근처에서 멈춘다면 SATA 링크를 사용하는 것입니다.

NVMe를 사용하면 웹사이트 로딩이 더 빨라집니까?

대개 그렇지 않습니다. 첫 번째 요청 이후에는 Linux가 RAM의 페이지 캐시에서 파일을 제공하므로 디스크는 유휴 상태가 됩니다. 소규모 VPS의 페이지 로드 속도는 일반적으로 애플리케이션의 CPU 시간과 대역폭에 의해 결정됩니다. 사이트가 모든 요청마다 쓰기 작업을 수행하는 경우(예: 자주 커밋하는 데이터베이스 기반 장바구니)에는 디스크가 중요한 경로로 다시 돌아옵니다. 각 커밋은 플러시가 완료될 때까지 기다려야 하기 때문입니다.

VPS의 적절한 fio 결과는 어느 정도입니까?

2026년 7월 기준으로, 로컬 플래시를 사용하는 소규모 VPS는 일반적으로 큐 깊이 32에서 수만 단위의 4k 랜덤 읽기 IOPS를 기록하며, 큐 깊이 1에서의 지연 시간은 0.3 ms 미만입니다. 네트워크 블록 스토리지는 일반적으로 수천 단위의 IOPS와 수 밀리초의 지연 시간을 기록합니다. 테스트를 서로 다른 시간에 3회 수행하십시오. 실행 결과 간의 편차가 크다면 평균값보다 더 많은 정보를 줍니다. 이는 호스트의 다른 게스트들이 귀하에게 얼마나 영향을 미치는지 보여주기 때문입니다.

데이터베이스를 네트워크 블록 스토리지에 두어야 합니까?

그렇게 할 수 있으며 많은 관리형 서비스가 그렇게 운영하지만, 커밋 경로에서 비용을 치러야 합니다. 모든 플러시 작업이 네트워크를 거치므로, 단일 연결에서 초당 처리하는 작은 트랜잭션의 수가 로컬 플래시보다 적습니다. 대신 호스트 장애 시에도 데이터가 보존되는 내구성을 얻게 됩니다. 쓰기 작업이 많은 데이터베이스에 네트워크 스토리지를 선택한다면, 작업을 더 큰 트랜잭션으로 묶어 더 적은 플러시 횟수로 더 많은 행을 처리하도록 하십시오.