longhorn 스토리지 테스트

longhorn

이전 포스팅에서 hetzner 볼륨을 사용할 때 postgresql 성능 테스트를 했다.

그리고 longhorn 이라는 오픈소스를 찾았다.
워커 서버의 로컬 스토리지를 볼륨처럼 사용할 수 있게 해준다.
로컬 스토리지라서 볼륨 스토리지를 사용할 때 보다 훨씬 성능이 좋지 않을까 해서 테스트 해봤다.

결과

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 20
query mode: simple
number of clients: 20
number of threads: 4
maximum number of tries: 1
duration: 60 s
number of transactions actually processed: 25850
number of failed transactions: 0 (0.000%)
latency average = 46.326 ms
initial connection time = 177.542 ms
tps = 431.724146 (without initial connection time)

Longhorn 볼륨을 사용할 때 결과

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1000
query mode: simple
number of clients: 20
number of threads: 4
maximum number of tries: 1
duration: 60 s
number of transactions actually processed: 36254
number of failed transactions: 0 (0.000%)
latency average = 33.046 ms
initial connection time = 135.371 ms
tps = 605.224338 (without initial connection time)

헤츠너에서 제공하는 네트워크 볼륨을 사용할 때 결과.

표로 정리하면 아래와 같다.

항목	Longhorn 사용 (로컬 볼륨)	네트워크 볼륨 사용
Transaction Type	`<builtin: TPC-B (sort of)>`	`<builtin: TPC-B (sort of)>`
Scaling Factor	20	1000
Query Mode	simple	simple
Number of Clients	20	20
Number of Threads	4	4
Max Tries	1	1
Test Duration	60초	60초
Transactions Processed	25,850	36,254
Failed Transactions	0 (0.000%)	0 (0.000%)
평균 Latency	46.326 ms	33.046 ms
초기 연결 시간	177.542 ms	135.371 ms
TPS (초기 연결 제외)	431.72	605.22

실수로 scale factor를 동일하게 설정 못했는데, 네트워크 볼륨이 더 불리한 조건임에도 평균 latency나 TPS 모두 좋았다.

Longhorn은 로컬 스토리지를 사용하긴 하지만,
여러 노드에 볼륨을 분산시켜놓고 쓰기 요청시에 동기적으로 복제과정을 거치기 때문에 오버헤드가 있다.
그리고 노드간에 동기화를 위해 네트워크 트래픽이 발생해서, 네트워크 볼륨이 가지는 단점도 그대로 가진다.

결국 성능적으로는 사용할 이유를 못찾았고, 남아도는 노드서버의 로컬 스토리지를 활용하는데 비용적인 이점은 있었다.

longhorn 스토리지 테스트

longhorn

결과

On this page