개발자가 실제로 알아야 할 8가지 VPS 성능 세부 사항

안녕하세요, 저는 Arthur입니다.

만약 여러분이 VPS 서버를 다루신다면, 아마도 vCPU, RAM, 스토리지, 대역폭 같은 일반적인 사양은 이미 알고 계실 겁니다.

하지만 그 수치들이 항상 왜 어떤 서버가 다른 서버보다 더 빠게 느껴지는지 설명해주지는 않습니다.

데이터베이스, API, 컨테이너, 백그라운드 워커 또는 기타 까다로운 워크로드를 실행하기 시작하면, 몇 가지 덜 명확한 것들이 중요해지기 시작합니다.

개발자들이 알아야 할 8가지 VPS 성능 세부 사항을 소개합니다.

1. CPU Steal Time 확인하기

VPS의 사용량이 낮게 표시되어도 느리다고 느껴질 수 있습니다.

왜일까요?

가상화된 환경에서 여러분의 가상 CPU는 다른 워크로드와 물리적 CPU 자원을 공유합니다.

CPU steal time은 VM이 CPU를 원했지만 기다려야 했던 시간을 보여줍니다.

만약 steal 시간이 지속적으로 높다면, 문제는 여러분의 코드가 아닐 수 있습니다.

기반 호스트(host)가 과부하 상태일 수 있다는 것입니다.

이는 실제로 주된 문제가 아닌 애플리케이션을 최적화하는 데 시간을 들이기 전에 확인해 볼 가치가 있는 부분입니다.

2. vCPU 개수가 모든 것을 말해주지 않는다

“8 vCPU”는 간단하게 들립니다.

하지만 한 물리적 CPU 플랫폼의 8 vCPU가 다른 곳의 8 vCPU와 반드시 같지는 않습니다.

CPU 세대, 아키텍처, 클럭 동작 방식, 가상화 및 자원 할당 등 모든 것이 실제 성능에 영향을 미칠 수 있습니다.

CPU 집약적인 워크로드의 경우, 단순히 vCPU 개수를 비교하는 것보다 실제 서버를 벤치마킹하는 것이 훨씬 유용합니다.

3. NVMe가 동일한 I/O 성능을 보장하지 않는다

개발자들은 종종 NVMe를 보고 스토리지 문제가 해결되었다고 가정합니다.

반드시 그렇지는 않습니다.

두 VPS 제공업체 모두 NVMe를 제공할 수 있지만, 매우 다른 I/O 성능을 보여줄 수 있습니다.

여러분의 워크로드는 다음 요소에 따라 달라질 수 있습니다:

• 랜덤 읽기 (Random reads)
• 랜덤 쓰기 (Random writes)
• 순차적 I/O (Sequential I/O)
• IOPS
• 스토리지 지연 시간 (Storage latency)
• 큐 깊이 (Queue depth)

데이터베이스는 특히 랜덤 I/O와 지연 시간에 민감할 수 있습니다.

따라서 애플리케이션이 느린데 CPU 사용량은 정상으로 보인다면, 더 많은 CPU가 필요하다고 가정하기 전에 디스크 지연 시간과 I/O 대기 시간을 확인해 보세요.

4. 네트워크 속도와 지연 시간은 다르다

1 Gbps 연결을 가진 서버가 자동으로 낮은 지연 시간(low-latency)의 연결을 제공하는 것은 아닙니다.

분산 애플리케이션, API, 데이터베이스 및 마이크로서비스(microservices)의 경우, 최대 대역폭(maximum bandwidth)보다 지연 시간이 더 중요할 수 있습니다.

서버가 충분한 대역폭을 가지고 있더라도 다른 서비스로 가는 네트워크 경로가 좋지 않을 수 있습니다.

이것이 바로 서버 위치가 단순히 지리적 선호도가 아니라 실제 성능 결정 요인이 될 수 있는 이유입니다.

5. 부하 평균(Load Average)은 단순한 CPU 사용률 그 이상이다

Linux의 부하 평균은 오해하기 쉬운 또 다른 측정 항목입니다.

높은 부하가 항상 CPU가 100%로 작동하고 있다는 것을 의미하지는 않습니다.

I/O를 포함하여 특정 리소스를 기다리는 프로세스들이 시스템 부하에 기여할 수 있습니다.

예를 들어, CPU 사용률은 보통이지만 프로세스가 스토리지(storage)를 기다리느라 부하가 높은 서버가 있을 수 있습니다.

부하 평균을 CPU 사용률, I/O 대기 시간(I/O wait), 디스크 지연 시간과 함께 살펴보면 훨씬 더 명확한 그림을 얻을 수 있습니다.

6. 스왑 사용량(Swap Usage)이 곧 RAM 증설 필요성을 의미하지는 않는다

스왑 사용량을 보면 놀랄 수 있습니다.

하지만 적은 양의 스왑 활동이 VPS가 반드시 더 많은 RAM을 필요로 한다는 것을 자동으로 의미하지는 않습니다.

Linux는 덜 자주 사용되는 메모리 페이지를 스왑으로 옮기면서도 파일 시스템 캐싱(filesystem caching)을 위해 RAM을 확보할 수 있습니다.

더 중요한 질문은 시스템이 메모리 압박(memory pressure) 상태에 있으며 충분한 메모리가 없어 적극적으로 스와핑하고 있는지 여부입니다.

심각한 스와핑은 다른 상황입니다.

시스템이 RAM과 스왑 사이에서 지속적으로 데이터를 이동하면 애플리케이션 성능이 심하게 저하될 수 있습니다.

7. 컨테이너는 여전히 호스트(Host)에 의존한다

Docker를 사용하면 VPS에서 여러 서비스를 쉽게 실행할 수 있습니다.

하지만 컨테이너가 마법처럼 추가적인 CPU, RAM 또는 디스크 성능을 만들어내지는 않습니다.

만약 다섯 개의 컨테이너가 동일한 리소스를 놓고 경쟁하고 있다면, 여전히 서로에게 영향을 미칠 수 있습니다.

이것이 바로 리소스 제한(resource limits)과 모니터링이 중요한 이유입니다.

예를 들어, 사용 가능한 모든 CPU를 소모하는 백그라운드 워커가 API 컨테이너 자체에 변화가 없더라도 느리게 보이게 만들 수 있습니다.

Container 레벨 모니터링은 어떤 서비스가 실제로 문제의 원인인지 파악하는 데 도움을 줄 수 있습니다.

8. 무조건 큰 VPS가 정답은 아니다

이것이 아마 가장 유용한 교훈일 것입니다.

애플리케이션 속도가 느려지면, 4 vCPU에서 8 vCPU로 업그레이드하는 것이 당연한 해결책처럼 느껴집니다.

때로는 효과가 있습니다.

하지만 때로는 그렇지 않습니다.

만약 실제 병목 현상이 데이터베이스 쿼리, 스토리지 지연 시간(storage latency), 네트워크 지연 시간(network latency), 메모리 압력(memory pressure) 또는 비효율적인 백그라운드 프로세스 때문이라면, CPU를 두 배로 늘리는 것이 진짜 문제를 해결해주지 못합니다.

업그레이드를 하기 전에, 병목 현상을 찾아야 합니다.

애플리케이션을 확인하세요.

데이터베이스를 확인하세요.

디스크를 확인하세요.

메모리 압력을 확인하세요.

네트워크 동작을 확인하세요.

그 후에 무엇이 바뀌어야 할지 결정하세요.

VPS 선택 전 제가 확인하는 것들

저는 더 이상 사양표만 보지 않습니다.

워크로드에 맞춰 서버를 매칭하려고 노력합니다.

PostgreSQL 중심의 애플리케이션은 정적 웹사이트와는 다른 요구 사항을 가집니다.

Kubernetes 클러스터는 소규모 API와는 다른 요구 사항을 가집니다.

데이터 처리 워크로드는 CPU 성능과 스토리지 I/O에 훨씬 더 신경 쓸 수 있습니다.

만약 VPS 제공업체를 비교하고 있다면, **HelloServer VPS**는 다른 제공업체와 함께 확인해 볼 만한 옵션 중 하나이지만, 중요한 부분은 자원을 애플리케이션이 실제로 무엇을 하는지에 맞춰 매칭하는 것입니다.

마지막 생각

VPS 성능은 단순히 몇 개의 코어나 얼마나 많은 RAM을 구매했는지에 관한 것이 아닙니다.

흥미로운 부분은 워크로드가 실제로 그 자원들을 사용하기 시작할 때 무슨 일이 일어나는가입니다.

CPU steal time, I/O wait, 스토리지 지연 시간(storage latency), 네트워크 라우팅(network routing), 메모리 압력(memory pressure), 그리고 컨테이너 리소스 제한(container resource limits) 등 모든 것이 병목 현상이 될 수 있습니다.

그러니 다음에 VPS가 느리게 느껴진다면, 즉시 업그레이드하지 마세요.

먼저 측정하세요. 병목 현상을 찾으세요. 그런 다음 실제로 당신을 제한하는 자원을 변경하세요.