볼륨 성능 테스트

Hetzner 볼륨 성능 이슈

https://bilbof.com/posts/kubernetes-on-hetzner
위 링크는 DO에서 헤츠너로 이전한 사람의 후기글이다.

이 사람의 후기글에는 아래 내용이 나온다.

제 경험상 Hetzner 볼륨은 프로덕션 데이터베이스에 사용하기에는 너무 느립니다. 과거에 AWS EBS에서 고객용 데이터베이스를 운영해 본 경험이 있으시겠지만, Hetzner 볼륨에서는 IOPS가 매우 낮으면서 50ms 이상의 IOWAIT가 발생했습니다.

치명적인 이슈다. Hetzner 볼륨에 zalando postgres operator로 데이터베이스를 올릴 생각이었다.\

글 작성자는 로컬 볼륨을 pvc처럼 사용하게 해주는 sig-storage-local-static-provisioner를 사용해서 로컬 스토리지를 볼륨으로 대체한 것 같다.
나에게는 조금 어려운 해결 방법이다. 워커 노드를 삭제/대체할때 고려할게 생길 것이다.\

일단 진짜 성능적으로 문제가 있는지 확인해보려고 한다.

fio 테스트

fio는 스토리지 성능 테스트 도구다.
내 쿠버네티스 클러스터 내부에서 Hetzner volume에 접근하는 것과, 데디케이티드 서버를 따로 띄우고 서버의 로컬 스토리지를 접근하는 것 사이의 성능 차이를 확인해보려고 한다.

먼저 fio를 실행할 pod를 만들었다.

apiVersion: v1
kind: Pod
metadata:
  name: fio-test
  namespace: monitoring
spec:
  containers:
    - name: fio
      image: alpine:latest
      command: ["sh", "-c", "apk add --no-cache fio && sleep 3600"]
      volumeMounts:
        - name: test-volume
          mountPath: /mnt/test
  volumes:
    - name: test-volume
      persistentVolumeClaim:
        claimName: monitoring-prometheus-server
  restartPolicy: Never

persistentVolumeClaim은 기존에 설치되어 있는 monitoring-prometheus-server를 사용했다.

그리고 pod 내부에서 fio 테스트 커맨드를 실행한다.\

fio --name=randtest_libaio \
    --filename=/mnt/test/testfile \
    --size=512M \
    --bs=4k \
    --rw=randrw \
    --rwmixread=70 \
    --iodepth=32 \
    --numjobs=4 \
    --time_based \
    --runtime=60 \
    --group_reporting \
    --ioengine=libaio \
    --direct=1 \

읽기와 쓰기 모두 동시에 테스트하며 부하를 줘서 60초간 테스트를 하고 결과를 받는다.

데디케이티드 서버에서도 동일한 커맨드로 테스트를 했다. 서버 사양은 CCX13으로 vcpu 2, ram 8gb이다.

fio 테스트 결과

결과 로그 긁어서 gemini에게 물어봤다.

테스트 결과

각 레이턴시는 하나의 4KB I/O 요청(읽기 또는 쓰기)이 완료되기까지 걸린 평균 시간을 나타낸다.

요약

전반적인 성능 (IOPS, BW): 이전과 동일하게 로컬 스토리지가 헤츠너 볼륨보다 약 6배 빠릅니다.
평균 지연 시간: 헤츠너 볼륨이 로컬 스토리지보다 느립니다 (읽기 약 7.7배, 쓰기 약 1.6배).
지연 시간 분포 (백분위수):
- 상위 백분위수 (빠른 응답): 1% ~ 70% 구간에서는 로컬 스토리지가 전반적으로 빠르지만, 쓰기 70% 구간에서는 헤츠너 볼륨이 미세하게 더 빠른 경우도 있었습니다. 이는 측정 오차나 특정 상황에서의 캐싱 효과일 수 있습니다.
- 하위 백분위수 (느린 응답, 꼬리 지연 시간): 가장 결정적인 차이는 99% 이상, 특히 99.99% 구간에서 나타납니다.
로컬 스토리지는 99.99%의 요청조차 10ms 미만으로 매우 안정적으로 처리합니다.
헤츠너 볼륨은 99% 구간부터 지연 시간이 급격히 늘어나며, 99.99% 구간에서는 1.3초가 넘는 심각한 지연 시간을 보입니다. 이는 네트워크 스토리지의 특성상 발생할 수 있는 불안정성 및 성능 저하를 명확하게 보여줍니다.

성능차이가 꽤 난다.
볼륨은 서버에 직접 연결된 로컬 디스크가 아니라, 네트워크를 통해 연결되는 스토리지라서 네트워크 단계의 레이턴시가 추가된다고 한다.
볼륨을 쓰면 당장은 편하겠지만, 나중에 문제가 생겼을 때 데이터베이스를 옮기는게 쉽지 않을 것 같다.
나에겐 초기 비용이 조금 더 들더라도, 처음부터 데디케이티드 서버에서 로컬 스토리지로 데이터베이스를 올리는게 좋을 것 같다.

매우 높은 부하의 테스트지만, 데디케이티드 서버의 로컬 스토리지도 평균 읽기시간이 2ms면 SSD치고는 느린 편이라고 한다.
궁금해서 vultr에 같은 사양의 데디케이티드 서버를 생성하고 비교를 해봤다.
결과는 vultr가 2배정도 빨랐다. 헤츠너가 저장소 기본 성능 자체도 좋은 편은 아닌가보다.
대신 99.99 구간에서 vultr가 좀 값이 튀는게 있긴 했다.
(vultr에 쿠버네티스 올리고, 볼륨 스토리지 성능도 확인해보고 싶지만 귀찮아서 안함)

ping 테스트

두서없지만 데디케이티드 서버를 따로 만들면 쿠버네티스 클러스터 내 노드와 통신간에 레이턴시도 궁금해졌다.
같은 리전의 데디케이티드 서버 만든김에 해당 주소로 ping 테스트를 했다.

$ ping 5.78.67.171
64 bytes from 5.78.67.171: seq=0 ttl=57 time=1.671 ms
64 bytes from 5.78.67.171: seq=1 ttl=57 time=0.671 ms
64 bytes from 5.78.67.171: seq=2 ttl=57 time=0.494 ms
64 bytes from 5.78.67.171: seq=3 ttl=57 time=0.552 ms
...
--- 5.78.67.171 ping statistics ---
15 packets transmitted, 15 packets received, 0% packet loss
round-trip min/avg/max = 0.392/0.589/1.671 ms

대충 평균 0.6ms정도다.
쿠버네티스 클러스터 내부 네트워크내에 서버를 넣고, 내부 네트워크 주소로 해도 비슷한 결과였다. (min/avg/max = 0.444/0.596/1.868 ms) 이정도면 통신간 레이턴시는 크게 문제가 될 것 같다.

결론

서문의 블로그에서 본 50ms 정도의 지연은 아니지만, Hetzner의 볼륨은 느린게 맞다.
데이터베이스는 별도 데디케이티드 서버에 올리기로 결정했다.

볼륨 성능 테스트

Hetzner 볼륨 성능 이슈

fio 테스트

fio 테스트 결과

ping 테스트

결론

On this page