[MinIO Study 2주차] MinIO Performance
CoudNet@ 팀의 가시다님께서 리딩하시는 MinIO Study 2주차 스터디 내용 정리
이번 주차에는 MinIO 스토리지 사용과 관련된 DirectPV 그리고 성능에 대해서 공부했습니다.
1. MinIO Hardware Checklist
이전 글에서는 MinIO 를 위한 Software Checklist 를 알아보았다면, 이번에는 Hardware Checklist 를 확인해보겠습니다.
다만, 실제 물리서버가 없는 관계로 이론적인 내용으로만 확인이 가능합니다.
1.1. MinIO Hardware Checklist
- MinIO 를 통해 저장할 예상 데이터 양 (테라바이트 단위)
- 향후 2년 간 데이터 볼륨의 예상 성장률
- 평균 객체 크기별 객체 수
- 데이터의 평균 보존 기간 (년)
- 배포할 사이트 수
- 예상 버킷 수
1.2. Hardware 권장사항
| 항목 | 최소 사양 | 권장 사양 |
| Kubernetes 워커 노드 (MinIO Tenant 전용) | 테넌트당 4개 워커 | 테넌트당 8개 이상 워커 |
| 전용 퍼시스턴트 볼륨 (PV) (MinIO 서버 Pod용) | 서버 Pod당 4개 PV | 서버 Pod당 8개 이상 PV |
| 네트워크 인프라 속도 | 25GbE | 100GbE |
| 서버급 CPU (최신 SIMD 명령어 지원, 예: AVX-512 / Intel® Xeon® Scalable 이상) | Pod당 4 vCPU | Pod당 8개 이상 vCPU |
| 메모리 (서버당 사용량 + 여유 버퍼 확보) | 워커 노드당 32GB | 워커 노드당 128GB 이상 |
1.3. Hardware 성능 영향 중요도
| 항목 | 문제 원인 | 영향 |
| 네트워크 인프라 | 처리량 부족 또는 제한 | 성능 저하 |
| 스토리지 컨트롤러 | 오래된 펌웨어, 제한된 처리량, 하드웨어 오류 | 성능 저하 및 안정성 저하 |
| 저장 장치(드라이브) | 오래된 펌웨어, 느리거나 노후된 장치, 하드웨어 고장 | 성능 저하 및 안정성 저하 |
네트워킹
- MinIO는 연결된 스토리지(집계 드라이브, 스토리지 컨트롤러 및 PCIe 버스)의 최대 처리량을 지원하기 위해 고속 네트워킹을 권장
| NIC 대역폭(Gbps) | 예상 집계 스토리지 처리량(GBps) |
| 10Gbps | 1.25GBps (x 8 = 10) |
| 25Gbps | 3.125GBps (x 8 = 25) |
| 50Gbps | 6.25GBps |
| 100Gbps | 12.5GBps |
1.4. PCIe
MinIO 하드웨어 문서를 확인하면 PCIe 에 관한 내용이 많이 있습니다.
PCIe (Peripheral Component Interconnect Express) 는 컴퓨터 안에서 CPU ↔ 그래픽카드, SSD, 네트워크 카드 같은 고성능 장치를 연결하기 위한 고속 직렬 인터페이스(버스 표준)입니다.
PCIe 정보 확인
PCIe 정보는 아래 명령어로 확인이 가능하지만, T 패밀리 EC2 환경에서는 확인이 불가합니다.
lspci -vv | grep -A40 -i "nvme"
2. Warp
2.1. Warp 소개
Warp 는 MinIO 에서 제공하는 대표적인 S3 성능 벤치마크 도구
AWS S3 API 호환 스토리지를 대상으로 실제 워크로드를 흉내 내면서 성능(throughput, latency, IOPS 등)을 측정할 수 있도록 만든 도구입니다.
Warp 특징
1.S3 호환 API 벤치마크
- AWS S3, MinIO, Ceph, 또는 다른 S3 API 호환 스토리지 대상으로 테스트 가능
- PUT, GET, DELETE, LIST 같은 S3 작업을 실제처럼 실행
2.워크로드 시뮬레이션
- 단순 성능 측정뿐 아니라, 객체 크기/분포/요청 비율 등을 커스터마이징해서 실제 애플리케이션 패턴에 가까운 테스트 가능
3.다양한 벤치마크 모드
- warp put : 객체 업로드 성능 측정
- warp get : 객체 다운로드 성능 측정
- warp mixed : 업로드/다운로드/삭제 혼합 워크로드
- warp latency : 지연(latency) 중심 측정
4.분산 실행 지원
- 여러 클라이언트에서 동시에 실행해 대규모 워크로드 시뮬레이션 가능
5.결과 분석
- 초당 처리량, 평균/백분위(latency p95, p99), 오류율 등을 리포트로 제공
- 결과를 JSON, CSV 등으로 export 가능 → Grafana 대시보드 연동 가능
2.2. Warp 설치
wget https://github.com/minio/warp/releases/download/v1.3.0/warp_Linux_x86_64.tar.gz
tar zxvf warp_Linux_x86_64.tar.gz
chmod +x warp
mv warp /usr/local/bin
warp --version
2.3. MinIO 인증서 등록
기존처럼 그냥 MinIO Client 를 사용하려면 --insecure 명령어를 사용하면 되지만,
Warp 를 실행하기 위해서는 MinIO Client 인증서 등록이 필요합니다.
임시 테스트를 위해서는 Ubuntu 서버의 RootCA 에 Tenant 인증서를 등록하여 사용하면 됩니다.
# CRT 추출
kubectl get secret -n tenant1 tenant1-tls -o jsonpath='{.data.public\.crt}' | base64 -d > tenant1.crt
# RootCA 로 복사
cp tenant1.crt /usr/local/share/ca-certificates/tenant1.crt
update-ca-certificates
# 호스트 등록
echo "127.0.0.1 minio.tenant1.svc" >> /etc/hosts
MinIO Client 재등록
mc alias set k8s-tenant1 https://minio.tenant1.svc:30002 minio minio123
mc ls --summarize --recursive k8s-tenant1
이제 --insecure 없이 MC 호출이 가능해졌습니다.
2.4. Warp 테스트
Warp 테스트를 위한 변수 등록
export WARP_ENDPOINT="minio.tenant1.svc:30002"
export WARP_ACCESS_KEY="minio"
export WARP_SECRET_KEY="minio123"
Warp 테스트 전 모니터링을 위해 4 개의 터미널을 동시에 실행했습니다.
# 1번 - Warp 명령어 수행
# 2번 - Disk 모니터링
iostat nvme1n1 nvme2n1 nvme3n1 nvme4n1 1 -x -d
# 3번 - CPU 모니터링
htop
# 4번 - Network 모니터링 - 실행 후 General interface statistics 선택
apt install iptraf-ng -y
iptraf-ng
객체 업로드 테스트
warp put --host $WARP_ENDPOINT \
--access-key $WARP_ACCESS_KEY \
--secret-key $WARP_SECRET_KEY \
--tls \
--obj.size 1MiB \
--duration 2m \
--concurrent 32 \
--bucket mybucket
Warp 결과 분석
Reqs: 25736, Errs:0, Objs:25736, Bytes: 25.13GiB
- PUT Average: 216 Obj/s, 215.8MiB/s; Current 230 Obj/s, 229.9MiB/s, 149.2 ms/req
# 총 요청 수 (Reqs): 25,736
# 에러 (Errs): 0 → 모든 요청이 성공적으로 완료됨
# 총 객체 수 (Objs): 25,736 → 요청 수와 동일 (모두 PUT 성공)
# 총 전송 데이터량 (Bytes): 약 25.13 GiB
# 평균 업로드 처리량:
# 216 Obj/s (초당 객체 216개 업로드)
# 215.8 MiB/s (초당 215.8 MiB 전송)
# 현재 속도 (테스트 종료 시점 근처):
# 230 Obj/s
# 229.9 MiB/s
# 평균 응답시간 149.2 ms/req
Report: PUT. Concurrency: 32. Ran: 1m57s
* Average: 215.97 MiB/s, 215.97 obj/s
* Reqs: Avg: 148.2ms, 50%: 137.5ms, 90%: 210.1ms, 99%: 321.5ms, Fastest: 41.2ms, Slowest: 592.4ms, StdDev: 49.5ms
# 동시성 (Concurrency): 32개의 클라이언트 스레드가 동시에 PUT 요청 실행
# 테스트 시간: 1분 57초
# 평균 처리량: 215.97 MiB/s, 215.97 Obj/s
# 응답시간 분포:
# 평균: 148.2ms
# 50% (Median): 137.5ms → 절반의 요청은 약 0.14초 이내에 완료
# 90%: 210.1ms → 90% 요청은 0.21초 이내에 완료
# 99%: 321.5ms → 대부분 요청이 0.32초 이하
# 가장 빠른 요청: 41.2ms
# 가장 느린 요청: 592.4ms
# 표준편차: 49.5ms → 응답시간이 큰 폭으로 흔들리진 않음
Throughput, split into 117 x 1s:
* Fastest: 267.3MiB/s, 267.27 obj/s
* 50% Median: 227.2MiB/s, 227.17 obj/s
* Slowest: 94.9MiB/s, 94.94 obj/s
# 테스트는 117초 동안 진행됨 (약 2분)
# 가장 빠른 1초: 267.3 MiB/s
# 중간값(50% Median): 227.2 MiB/s
# 가장 느린 1초: 94.9 MiB/s
종합적으로 해석하면 다음처럼 정리할 수 있습니다.
1. 성능 안정성: 보통
- 평균 ~216 MiB/s, 피크 267 MiB/s → 꽤 안정적으로 동작
2. 지연시간: 양호
- 대부분의 요청이 0.14~0.21초 사이에 완료 → S3 API 기준으로 양호
3. 편차: 보통
- 응답시간 StdDev 49.5ms → 일부 느린 요청이 있긴 하지만 전체적으로 큰 흔들림은 없음
4. 에러 없음: 매우 중요
- 부하 시에도 100% 성공률