test0824a

Young-Kyoo Kim·2025년 8월 24일

좋은 질문이에요 👍
지금 상황을 정리하면:

  • 스토리지 노드 수: 58대

  • 노드당 디스크: 20 × 7 TiB NVMe SSD = 140 TiB

  • 총 raw capacity: 58 × 140 TiB ≈ 8.12 PiB

  • EC: 8:3 (데이터 8 + 패리티 3 → 11개 shard, overhead 약 37.5%)
    → 유효 용량 ≈ 5.9 PiB 수준

  • 네트워크: 노드당 25 Gbps × 2 (bond) = 50 Gbps
    스위치 포트는 40 Gbps, 백본은 200 Gbps

즉, 스토리지 자체 IOPS/Throughput은 NVMe라 충분히 빠르지만, 네트워크가 bottleneck이 될 가능성이 높습니다.

1. 데이터를 빠르게 채워 넣는 방법

MinIO/AIStor은 S3 PUT API 기반이므로, 아래 방법을 병행해야 합니다:

  1. 병렬 클라이언트

    • mc mirror 대신 warp, s3-bench, fio-s3, k6 + S3 plugin 같은 부하도구 사용
    • 노드 수만큼 클라이언트 pod/job을 띄워서 동시 PUT
    • 파일 사이즈 분포에 따라 워크로드 조합 (예: small object vs large object)

  2. 멀티파트 업로드

    • 64MB 이상 object는 반드시 multipart upload (parallel upload chunk)
    • 네트워크 파이프를 최대한 활용 가능

  3. 데이터 생성 후 업로드

    • 무작위 데이터 생성: fio --rw=write --bs=4M → pipe → aws s3 cp -
    • 또는 MinIO warp의 --obj.size 24MiB --objects 1e9 형태로 직접 object 생성

2. 데이터 채우기 예상 속도/시간

  • 노드당 네트워크 대역폭 40 Gbps (5 GB/s) 가 한계
  • 58노드 전체 = 58 × 5 GB/s ≈ 290 GB/s (2.3 Tbps)
  • EC(8:3)로 인해 실제 write는 (11/8) ≈ 1.375 배 더 네트워크 소모
    → 유효 쓰기 대역폭 ≈ 210 GB/s

→ 채우기 속도 계산

  • 1 PiB = 1024 TiB = 약 1.1e6 GB
  • 210 GB/s = 756,000 GB/h ≈ 738 TiB/h ≈ 0.72 PiB/h
  • 총 유효 스토리지 5.9 PiB → 이론적으론 약 8~9시간이면 풀 채움 가능
    (현실은 클라이언트 수, EC 연산, small object overhead → 2~3배 느려질 수 있음 → 24시간~2일 예상)

3. small vs large object 병목 분석

(a) Small object (4KB ~ 64KB)

  • MinIO 메타데이터 처리 + 네트워크 패킷 오버헤드가 지배적
  • IOPS 한계에 걸림 (NIC / TCP stack / MinIO metadata)
  • 40 Gbps NIC라도 small object 처리량은 수천~수만 OPS 수준
  • 실제 Throughput은 네트워크 Full 못 쓰고 수백 MB/s 수준일 가능성 높음
  • 즉, 메타데이터 서버/Drive IOPS가 병목

(b) Large object (24 MB ~ 128 MB)

  • Throughput이 지배적, 멀티파트 업로드 효율↑
  • 24 MB 이상이면 네트워크 선형적 스케일링 가능 → 노드당 4–5 GB/s 근접
  • 병목은 스위치 포트(40G 제한)

4. Hadoop block size (128 MB) vs S3 object size

  • HDFS block size = 128MB는 HDFS 내부 분산 단위일 뿐, S3 object에 그대로 맞출 필요 없음.

  • Hadoop → S3 마이그레이션 시:

    • DistCp 같은 도구는 block을 그대로 object로 옮겨서 평균 128MB object 생성됨
    • 하지만 Spark, Trino, Presto 같은 엔진은 S3 object를 split 가능 (24MB도 충분)

👉 따라서

  • 마이그레이션 도구 쓰면 128MB object가 자연스럽게 생김
  • 새 데이터 저장 설계 시는 워크로드 패턴에 따라 평균 object size를 16–64MB 정도로 맞추는 것이 best practice
  • 24MB는 괜찮은 선택 (작으면 small object 병목, 크면 병렬 처리 효율↓)

✅ 정리

  1. 빠르게 채우려면 warp/multipart 기반 병렬 업로드, node별 클라이언트 동시 투입.
  2. 5.9 PiB를 채우는 데 이론적 9h, 현실적 24–48h 예상.
  3. Small object는 metadata/IOPS가 병목, Large object는 네트워크(40G 포트)가 병목.
  4. Hadoop 128MB block은 migration tool에선 그대로, 신규 데이터는 24–64MB로 설계해도 무방.

👉 원하시면 제가 채우기용 스크립트 (예: warp, k6, fio-s3 조합) 만들어서 예상 OPS/Throughput 통계까지 자동 CSV 뽑는 버전을 작성해드릴까요?

좋은 포인트 집으셨어요 👍
말씀하신 NIC / TCP stack / MinIO metadata IOPS 한계는 실제 S3 스토리지에서 작은 오브젝트(4KB~64KB) 업로드 시 자주 문제되는 병목입니다. 크게 3가지 레이어에서 병목이 걸립니다:

1. NIC / TCP stack IOPS 한계

  • 네트워크 인터페이스 카드 (NIC) 는 패킷당 처리 성능이 제한적입니다.

    • 25/40/100Gbps NIC 기준으로 1~3M pps(packet per second) 정도가 현실적 한계
    • 4KB 오브젝트는 TCP/IP + S3 header까지 합치면 거의 1 packet ≈ 1 object 수준
    • 따라서 최대 IOPS = NIC PPS 한계 ≈ 1~3M ops/sec

  • 이 한계는 커널 TCP/IP 스택, 드라이버, 인터럽트 처리에도 영향받습니다.

    • Linux 커널 튜닝 (irqbalance, RPS/RFS, XDP/eBPF, io_uring)로 개선 가능

확인 방법

  • ethtool -S <nic> : NIC pps/err drop 확인
  • sar -n DEV 1 또는 nload, ifstat : 초당 패킷 전송량 확인
  • perf top : 커널 TCP/IP stack CPU 사용률 확인

2. MinIO 메타데이터 IOPS 한계

  • MinIO는 Object의 메타데이터 (namespace, version, erasure coding layout, checksum 등) 를 내부 key-value DB(RocksDB/boltdb-like)와 분산 구조에 저장

  • 작은 object가 많아지면 메타데이터 update IOPS가 bottleneck 됨

    • 실무 보고치: 수십만~수백만 objects/sec 정도가 상한선
    • 오브젝트 크기가 작을수록 Throughput은 떨어지고 OPS는 올라감

  • 특히 PUT/DELETE 같은 write path에서 부하 큼

확인 방법

  • MinIO의 mc admin trace : API call latency 확인
  • mc admin prometheus → Prometheus metrics (minio_s3_requests_total, minio_s3_requests_inflight, minio_disk_storage_requests)
  • RocksDB level stats (minio_rocksdb_* metrics)

3. Linux 파일시스템 + NVMe IOPS 한계

  • NVMe SSD 자체는 개당 500K~1M IOPS (4K random write 기준)
  • 노드당 20개 NVMe → 이론상 수천만 IOPS 가능
  • 그러나 작은 object는 NVMe에 기록되는 데이터량보다 MinIO의 메타데이터/네트워크가 먼저 병목

확인 방법

  • fio --rw=randwrite --bs=4k --iodepth=64 --numjobs=8 : NVMe IOPS baseline 측정
  • MinIO 실동작 비교하여 디스크가 아니라 네트워크/메타데이터에서 막히는지 확인

4. 실제 관찰되는 IOPS 수준 (경험치)

  • 4KB object PUT 기준: 수만 ~ 수십만 OPS/sec (클러스터 전체)
  • 64KB object: 수십만 ~ 백만 OPS/sec 가능
  • 1MB 이상 object: OPS는 낮아지지만 Throughput은 네트워크 포화 근처까지 도달 (10~40Gbps 단일 NIC 한계)

즉, 작은 object는 IOPS → 네트워크 패킷 처리와 메타데이터 병목,
큰 object는 Throughput → NIC 대역폭과 EC 연산 병목이라고 이해하면 됩니다.

✅ 정리

  • NIC 한계: 1~3M PPS 수준 → 작은 오브젝트에서 직접 IOPS 한계로 드러남
  • MinIO 메타데이터 한계: 수십~수백만 object/sec 수준 (작을수록 오버헤드↑)
  • 확인 방법: NIC(ethtool -S, sar), MinIO metrics(mc admin prometheus), 디스크(fio) 조합

👉 원하시면 제가 "작은 object IOPS vs 큰 object Throughput"을 측정하는 벤치마크 시나리오 (warp + fio + mc admin metrics 수집) 예시를 작성해드릴까요?

좋은 질문이에요 👍
mc의 od (object distribution) 서브커맨드를 말씀하신 것 같네요. 이건 최근 MinIO Client에 들어간 기능인데, 이름 때문에 혼동하기 쉽습니다.

1. mc od 의 역할

  • od = object distribution

  • 주 용도는 S3 버킷 안의 오브젝트 분포/패턴을 통계로 확인하는 것입니다.

    • prefix별 object 수, object 크기 분포, 스토리지 사용량
    • 예: small object 비율, 평균 object 크기, 특정 prefix 핫스팟 확인

즉, mc od는 데이터를 생성하거나 채우는 툴이 아님 → 벤치마크/데이터 채움 용도로는 부적합합니다.

2. S3 스토리지를 채우려면

데이터 채워 넣는 목적으로는 mc od 대신 다음을 써야 합니다:

  1. mc alias set + mirror/cp

    • 로컬에서 생성한 대용량 파일이나 디렉터리를 S3에 복제
    • mc mirror /data myminio/bucket --overwrite --watch

  2. warp (MinIO 제공 부하툴)

    • warp put --obj.size 24MiB --objects 1e9 --concurrent 512 myminio/bucket
    • 대량 object 빠른 병렬 생성

  3. fio + s3 plugin

    • 무작위 데이터 → S3 PUT
    • fio --rw=write --bs=24M --ioengine=http_s3 --numjobs=64

  4. s3-bench / k6 / JMeter

    • 다양한 사이즈/패턴 조합 가능
    • OPS / Throughput 동시에 관찰

3. mc od와 보강 활용 방법

mc od 자체로 채우지는 못하지만, 데이터 채운 후에 상태를 점검하는 데는 유용합니다:

  • 데이터 분포 확인

    • 10억 개 object 채운 후 object size histogram 확인

  • 워크로드 검증

    • small object와 large object 비율이 계획대로 들어갔는지 체크

  • 성능 해석 보조

    • small object가 많으면 IOPS 병목, large object가 많으면 네트워크 포화 → 병목 지점 해석에 도움

✅ 결론

  • mc od는 스토리지를 채우는 도구가 아니라, 채워진 데이터를 분석하는 도구입니다.
  • 따라서 데이터 생성/적재 = warp, fio, s3-bench 같은 툴 사용,
  • 적재 후 상태 분석 = mc od 활용이 가장 현실적 조합이에요.

👉 원하시면 제가 **“warp로 채우고 → mc od로 분포 분석 → Prometheus/Metrics로 성능 확인”**까지 자동화된 샘플 스크립트(예: bash + Jenkinsfile) 짜드릴까요?

오케이, 요청하신 “warp로 채우고 → mc od 분석 → Prometheus 메트릭 수집” 자동화를 Bash 스크립트 + Jenkinsfile로 캔버스에 올려놨어요.
캔버스 파일에는:

  • aistor_bench.sh (단일 스크립트): 버킷 준비 → warp put 실행 → mc od --json 분석 → Prometheus API로 핵심 메트릭 스냅샷 수집 → CSV 요약까지 생성
  • Jenkinsfile (Declarative): 파라미터로 OBJ_SIZE/OBJECTS/CONCURRENCY/DURATION 등 받아 자동 실행, 리포트 아카이빙

바로 쓰실 때는 다음만 바꿔주시면 됩니다:

  • --url, --access, --secret, --prom-url, --prom-token
  • warp/mc 버전에 따라 옵션명이 조금 다를 수 있어 --help로 확인 후 맞춰주세요.

원하시면 같은 파이프라인에서 소형(예: 64KiB) → 대형(예: 128MiB) 두 번 돌려 비교 CSV를 하나로 합치고, Jenkins에서 HTML 리포트로 시각화하는 버전까지 확장해 드릴게요.

개요

AIStor/MinIO 클러스터에 대해 warp로 데이터 채우기 → mc od로 분포 분석 → Prometheus로 성능 수집을 한 번에 수행하는 샘플입니다.

⚠️ 주의: 아래 스크립트에서 arp는 오타로 보며 warp 를 사용합니다. 각 바이너리 버전에 따라 옵션명이 약간 다를 수 있으니 warp --help, mc od --help로 확인 후 필요 시 수정하세요.

1) Bash: aistor_bench.sh

  • 역할: 버킷 생성 → warp put 실행(채우기) → mc od 분포 분석 → Prometheus에서 핵심 메트릭 스냅샷 수집 → CSV/JSON 리포트 정리
  • 실행 예시:
./aistor_bench.sh \
  --alias aistor \
  --url https://minio.example.com \
  --access "MINIO_ACCESS_KEY" \
  --secret "MINIO_SECRET_KEY" \
  --bucket bench-$(date +%Y%m%d) \
  --prefix run1/ \
  --obj-size 24MiB \
  --objects 1000000 \
  --concurrency 512 \
  --duration 0 \
  --prom-url https://prometheus.example.com \
  --prom-token "PROME_TOKEN"
#!/usr/bin/env bash
set -euo pipefail

# =====================
# Defaults
# =====================
ALIAS="aistor"
URL=""
ACCESS=""
SECRET=""
BUCKET="bench-$(date +%Y%m%d)"
PREFIX="run1/"
OBJ_SIZE="24MiB"        # 예: 4KiB, 64KiB, 24MiB, 128MiB
OBJECTS=100000           # 총 오브젝트 개수
CONCURRENCY=256          # 동시성
DURATION=0               # 0이면 objects 개수 기준으로 종료
PART_SIZE="16MiB"       # 멀티파트 파트 크기(대용량에 권장)
WORKDIR="$(pwd)/reports"
PROM_URL=""
PROM_TOKEN=""
WARP_BIN="warp"
MC_BIN="mc"

TS="$(date +%Y%m%d_%H%M%S)"
RUN_DIR="$WORKDIR/$TS"
mkdir -p "$RUN_DIR"

# =====================
# Args
# =====================
while [[ $# -gt 0 ]]; do
  case "$1" in
    --alias) ALIAS="$2"; shift 2;;
    --url) URL="$2"; shift 2;;
    --access) ACCESS="$2"; shift 2;;
    --secret) SECRET="$2"; shift 2;;
    --bucket) BUCKET="$2"; shift 2;;
    --prefix) PREFIX="$2"; shift 2;;
    --obj-size) OBJ_SIZE="$2"; shift 2;;
    --objects) OBJECTS="$2"; shift 2;;
    --concurrency) CONCURRENCY="$2"; shift 2;;
    --duration) DURATION="$2"; shift 2;;
    --part-size) PART_SIZE="$2"; shift 2;;
    --workdir) WORKDIR="$2"; RUN_DIR="$WORKDIR/$TS"; shift 2;;
    --prom-url) PROM_URL="$2"; shift 2;;
    --prom-token) PROM_TOKEN="$2"; shift 2;;
    --warp-bin) WARP_BIN="$2"; shift 2;;
    --mc-bin) MC_BIN="$2"; shift 2;;
    *) echo "Unknown arg: $1"; exit 1;;
  esac
done

if [[ -z "$URL" || -z "$ACCESS" || -z "$SECRET" ]]; then
  echo "[ERR] --url/--access/--secret 는 필수입니다"; exit 1
fi

# =====================
# Functions
# =====================
json() { jq -r ".${1}" 2>/dev/null || true; }

prom_query() {
  local q="$1"; local out="$2";
  if [[ -z "$PROM_URL" ]]; then
    echo "[WARN] PROM_URL 미지정 - Prometheus 수집 생략"; return 0
  fi
  echo "[INFO] PromQL: $q"
  if [[ -n "$PROM_TOKEN" ]]; then
    curl -sS -H "Authorization: Bearer $PROM_TOKEN" --get --data-urlencode "query=$q" "$PROM_URL/api/v1/query" > "$out" || true
  else
    curl -sS --get --data-urlencode "query=$q" "$PROM_URL/api/v1/query" > "$out" || true
  fi
}

# =====================
# Configure mc alias
# =====================
export MC_HOST_$ALIAS="$URL"
$MC_BIN alias set "$ALIAS" "$URL" "$ACCESS" "$SECRET" --api S3v4 >/dev/null

# =====================
# Prepare bucket/prefix
# =====================
$MC_BIN mb --ignore-existing "$ALIAS/$BUCKET" || true

# =====================
# Warp PUT (채우기)
# =====================
WARP_OUT_JSON="$RUN_DIR/warp_put.json"
WARP_CMD=("$WARP_BIN" put --host "$ALIAS" --bucket "$BUCKET" \
          --obj.size "$OBJ_SIZE" --objects "$OBJECTS" \
          --concurrent "$CONCURRENCY" --part.size "$PART_SIZE" \
          --autoterm)
if [[ "$DURATION" != "0" ]]; then WARP_CMD+=(--duration "$DURATION"); fi

echo "[INFO] RUN: ${WARP_CMD[*]}"
"${WARP_CMD[@]}" | tee "$RUN_DIR/warp_put.log"
# warp는 보통 표준출력에 요약/JSON을 제공합니다. 버전에 따라 --json 옵션이 존재할 수도 있습니다.
# 필요 시 --json 추가 후 tee "$WARP_OUT_JSON" 로 캡처하세요.

# =====================
# mc od (분포 분석)
# =====================
# 참고: mc 버전에 따라 'mc od --json ALIAS/BUCKET[/PREFIX]' 사용법이 다를 수 있습니다.
OD_JSON="$RUN_DIR/od.json"
$MC_BIN od --json "$ALIAS/$BUCKET/$PREFIX" | tee "$OD_JSON"

# 히스토그램/요약 CSV 추출 (jq 필요)
OD_CSV="$RUN_DIR/od_summary.csv"
if command -v jq >/dev/null 2>&1; then
  echo "metric,value" > "$OD_CSV"
  AVG_SIZE=$(jq -r '..|.avgObjectSize? // empty' "$OD_JSON" | head -n1)
  TOTAL_OBJS=$(jq -r '..|.objects? // empty' "$OD_JSON" | head -n1)
  TOTAL_SIZE=$(jq -r '..|.totalSize? // empty' "$OD_JSON" | head -n1)
  echo "avg_object_size,$AVG_SIZE" >> "$OD_CSV"
  echo "objects,$TOTAL_OBJS" >> "$OD_CSV"
  echo "total_size_bytes,$TOTAL_SIZE" >> "$OD_CSV"
fi

# =====================
# Prometheus: 핵심 메트릭 스냅샷 (벤치 직후)
# =====================
# 환경에 맞는 잡 라벨(job, instance 등)을 넣으세요.
PROM_DIR="$RUN_DIR/prom"
mkdir -p "$PROM_DIR"

# 예시 쿼리들 (필요 시 수정)
prom_query 'sum(rate(minio_s3_requests_total[5m])) by (api)' "$PROM_DIR/minio_s3_requests_rate.json"
prom_query 'sum(rate(minio_http_requests_duration_seconds_count[5m]))' "$PROM_DIR/minio_http_rps.json"
prom_query 'sum(rate(minio_network_sent_bytes_total[5m]))' "$PROM_DIR/minio_tx_bps.json"
prom_query 'sum(rate(minio_network_received_bytes_total[5m]))' "$PROM_DIR/minio_rx_bps.json"
prom_query 'sum(irate(node_cpu_seconds_total{mode!="idle"}[1m]))' "$PROM_DIR/node_cpu.json"

# 간단 CSV 요약 만들기 (가능한 경우)
SUMMARY_CSV="$RUN_DIR/summary.csv"
echo "key,value" > "$SUMMARY_CSV"
echo "alias,$ALIAS" >> "$SUMMARY_CSV"
echo "bucket,$BUCKET" >> "$SUMMARY_CSV"
echo "prefix,$PREFIX" >> "$SUMMARY_CSV"
echo "obj_size,$OBJ_SIZE" >> "$SUMMARY_CSV"
echo "objects,$OBJECTS" >> "$SUMMARY_CSV"
echo "concurrency,$CONCURRENCY" >> "$SUMMARY_CSV"
echo "part_size,$PART_SIZE" >> "$SUMMARY_CSV"

if command -v jq >/dev/null 2>&1; then
  # warp 로그에서 대략적인 처리량/지연 추정치 추출 (버전에 따라 다를 수 있음)
  TPS=$(grep -Eo '([0-9]+(\.[0-9]+)?) obj/s' "$RUN_DIR/warp_put.log" | awk '{print $1}' | tail -n1 || true)
  THR=$(grep -Eo '([0-9]+(\.[0-9]+)?) (MiB|GiB)/s' "$RUN_DIR/warp_put.log" | tail -n1 || true)
  echo "warp_ops_per_sec,$TPS" >> "$SUMMARY_CSV"
  echo "warp_throughput,$THR" >> "$SUMMARY_CSV"
  if [[ -f "$OD_CSV" ]]; then
    AVG=$(awk -F, 'NR==2{print $2}' "$OD_CSV" 2>/dev/null || true)
    echo "od_avg_object_size,$AVG" >> "$SUMMARY_CSV"
  fi
fi

echo "[OK] 결과 디렉토리: $RUN_DIR"

2) Jenkinsfile (Declarative)

  • 역할: 파라미터 기반으로 채우기 → 분포 분석 → 메트릭 수집 → 아티팩트 보관 자동화
  • 전제: Jenkins 에이전트에 warp, mc, jq, curl 설치되어 있어야 합니다.
pipeline {
  agent { label 'aistor-bench' }
  options {
    timestamps()
    ansiColor('xterm')
  }
  parameters {
    string(name: 'MINIO_URL', defaultValue: 'https://minio.example.com', description: 'MinIO/AIStor S3 Endpoint')
    string(name: 'MINIO_ACCESS', defaultValue: 'ACCESS_KEY', description: 'S3 Access Key')
    password(name: 'MINIO_SECRET', defaultValue: 'SECRET_KEY', description: 'S3 Secret Key')
    string(name: 'ALIAS', defaultValue: 'aistor', description: 'mc alias 명')
    string(name: 'BUCKET', defaultValue: 'bench-${new Date().format("yyyyMMdd")}', description: '테스트 버킷')
    string(name: 'PREFIX', defaultValue: 'run1/', description: '오브젝트 prefix')

    string(name: 'OBJ_SIZE', defaultValue: '24MiB', description: '예: 4KiB, 64KiB, 24MiB, 128MiB')
    string(name: 'OBJECTS', defaultValue: '100000', description: '총 오브젝트 개수')
    string(name: 'CONCURRENCY', defaultValue: '256', description: 'warp 동시성')
    string(name: 'DURATION', defaultValue: '0', description: '0이면 objects 기준, 그 외는 예: 10m')
    string(name: 'PART_SIZE', defaultValue: '16MiB', description: '멀티파트 파트 사이즈')

    string(name: 'PROM_URL', defaultValue: 'https://prometheus.example.com', description: 'Prometheus URL (선택)')
    password(name: 'PROM_TOKEN', defaultValue: '', description: 'Prometheus Bearer Token (옵션)')
  }
  environment {
    WORKDIR = "${env.WORKSPACE}/reports"
  }
  stages {
    stage('Checkout') {
      steps {
        deleteDir()
        writeFile file: 'aistor_bench.sh', text: libraryResource('aistor_bench.sh')
        sh 'chmod +x aistor_bench.sh'
      }
    }
    stage('Run Bench (warp → od → prometheus)') {
      steps {
        sh '''
          ./aistor_bench.sh \
            --alias ${ALIAS} \
            --url ${MINIO_URL} \
            --access ${MINIO_ACCESS} \
            --secret ${MINIO_SECRET} \
            --bucket ${BUCKET} \
            --prefix ${PREFIX} \
            --obj-size ${OBJ_SIZE} \
            --objects ${OBJECTS} \
            --concurrency ${CONCURRENCY} \
            --duration ${DURATION} \
            --part-size ${PART_SIZE} \
            --workdir ${WORKDIR} \
            --prom-url ${PROM_URL} \
            --prom-token ${PROM_TOKEN}
        '''
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: 'reports/**', fingerprint: true
      echo "결과 리포트 경로: ${WORKDIR}"
    }
  }
}

Note

  • 위 Jenkinsfile은 libraryResource('aistor_bench.sh')로 스크립트를 로드하는 예시입니다. 간단히 쓰시려면 Jenkinsfile 옆에 aistor_bench.sh를 커밋하고 writeFile 대신 sh 'chmod +x aistor_bench.sh'만 호출하세요.

3) 결과물(리포트) 구조

reports/
  2025XXXX_HHMMSS/
    warp_put.log            # warp 실행 로그 (OPS/Throughput 요약 포함)
    od.json                 # mc od 원본 JSON 결과
    od_summary.csv          # mc od 요약 CSV (평균 크기, 개수, 총 용량)
    summary.csv             # 전체 파라미터/핵심 요약치
    prom/
      minio_s3_requests_rate.json
      minio_http_rps.json
      minio_tx_bps.json
      minio_rx_bps.json
      node_cpu.json

4) 팁 & 튜닝 체크리스트

  • 작은 오브젝트(4–64KiB) 테스트 시: CONCURRENCY 값을 크게(512~2048) 늘리되 CPU/IRQ 한계 감시 (sar -n DEV 1, ethtool -S, top -H).
  • 대형 오브젝트(≥ 64MiB): --part-size 8–32MiB로 조정, 멀티파트 병렬성 확보.
  • MinIO 서버 측: GOMAXPROCS, ulimit -n, 오브젝트 캐시/메타디비 파라미터, EC 8:3/10:2 등 조합으로 시험.
  • 네트워크: LACP hashing, RPS/RFS, irqbalance, TSO/GRO/GSO 옵션 점검.

5) 문제 해결

  • mc od 옵션/출력 스키마는 릴리스에 따라 다릅니다. mc od --help/--json으로 맞춰주세요.
  • Prometheus 메트릭 네이밍이 환경과 다르면 쿼리를 수정하세요(예: _total vs _bytes 이름).
  • 인증서/사설 CA 환경: mc alias set에 --insecure 또는 시스템 CA에 CA chain 추가.

필요하시면 작은/큰 오브젝트 2경로를 한 파이프라인에서 연속으로 돌려 비교 그래프까지 그리는 버전(CSV → Grafana/Matplotlib)도 만들어 드릴게요.

좋은 질문이에요 👍
MinIO 같은 분산 오브젝트 스토리지에서 메타데이터 처리 한계(특히 IOPS 관점)는 보통 S3 API 레벨 요청 처리량과 백엔드 KV 엔진(MinIO는 디스크+erasure coding 메타데이터, 분산 락/namespace 관리) 처리량에 의해 결정됩니다.

1. 어디서 병목이 생기나?

  • NIC / TCP stack

    • 초당 처리 가능한 S3 요청 수가 NIC IRQ, 커널 네트워크 스택, MinIO 프로세스 큐에 의해 제한됨.
    • 예: 25Gbps NIC × 2 본딩이면 최대 대역폭은 50Gbps지만, 4KB 작은 오브젝트라면 대역폭보다 packet rate가 한계가 됨.

  • MinIO metadata 경로

    • 각 PUT/GET/DELETE 요청마다 오브젝트 메타데이터를 생성/조회해야 함.
    • EC(8:3) 환경에서는 메타데이터 업데이트도 모든 shard에 반영해야 해서 작은 오브젝트일수록 metadata IOPS → 병목.

  • 디스크/파일시스템

    • NVMe SSD라 해도 실제 메타데이터는 파일시스템 inode/dir entry 갱신을 동반. 초당 수십만 단위 이상 가면 OS 메타데이터 락이 병목이 될 수 있음.

2. 보통 한계 수치 (레퍼런스 수준)

  • 작은 오브젝트 (4–64KB)

    • 한 노드 기준: 10~50K ops/s 선에서 CPU/metadata bottleneck 발생.
    • 58노드 전체: 최적화 시 수백만 ops/s 가능하지만, 보통 네트워크/메타데이터 병목으로 더 낮게 나타남.

  • 큰 오브젝트 (≥ 24MB)

    • Throughput은 네트워크/디스크 대역폭이 지배 → metadata 오버헤드 비중이 작아져 NIC line-rate 근처(수십 GB/s 집계) 도달 가능.

  • 메타데이터 DB (namespace ops)

    • 실환경에서는 1억~10억 오브젝트 이상에서 LIST, STAT, DELETE 성능이 급격히 떨어지기 시작.
    • 이건 MinIO 자체라기보다는 underlying FS와 Linux VFS 한계 영향이 큼.

3. 어떻게 직접 확인하나?

(A) MinIO Metrics (Prometheus)

  • minio_s3_requests_total{api="PutObject"} / rate(...[1m]) → 초당 요청 수 (IOPS equivalent)
  • minio_http_requests_duration_seconds_bucket → 요청 latency 분포
  • minio_disk_storage_used_bytes, minio_node_disk_usage_total → 데이터/메타데이터 사용량 추이
  • 요청량을 점차 늘려보면서 TPS vs latency 곡선이 꺾이는 지점을 찾으면 메타데이터 처리 한계.

(B) OS 레벨

  • iostat -x 1, pidstat -d 1 → NVMe 메타데이터 IOPS 확인
  • perf top 또는 flamegraph → MinIO 프로세스가 sys_futex, inode_lock 같은 커널 락에서 CPU를 많이 쓰는지 확인
  • ethtool -S / sar -n DEV 1 → 작은 오브젝트일 때 네트워크 패킷 처리율 확인

(C) 워크로드 시뮬레이션

  • warp put --obj.size 4KiB --objects 10M ... → 소형 오브젝트 한계 확인
  • warp get --obj.size 24MiB → 대형 오브젝트 throughput 확인
  • 오브젝트 개수(10억개)와 사용률(90%)까지 채운 후 LIST/DELETE workload 돌려서 메타데이터 병목 측정 가능.

4. 정리

  • 작은 오브젝트: 메타데이터 + 커널 path lookup이 IOPS를 제한 → 수만 ops/s 레벨에서 한계 감지 가능.
  • 큰 오브젝트: metadata 영향이 미미 → 네트워크/스토리지 throughput이 지배.
  • 측정법: MinIO Prometheus 메트릭 + OS iostat/pidstat + warp 부하 테스트로 TPS vs Latency 곡선을 관찰.

👉 혹시 제가 실험용으로 작은 오브젝트 워크로드용 warp 스크립트랑, Prometheus에서 바로 IOPS vs Latency 그래프 뽑는 PromQL 예제도 만들어드릴까요?

좋습니다 🙌 그럼 작은 오브젝트 워크로드 측정용 warp 스크립트 + Prometheus에서 IOPS vs Latency 그래프용 PromQL 예제를 드릴게요.

1. warp 워크로드 스크립트 (작은 오브젝트 PUT/GET)

warp_smallobj.sh

#!/bin/bash
# MinIO warp 테스트 스크립트 (작은 오브젝트 IOPS 한계 확인)

# 환경 설정
TARGET="myminio/testbucket"   # 대상 버킷
OBJ_SIZE="4KiB"               # 작은 오브젝트 크기
OBJECTS="1000000"             # 생성할 오브젝트 수 (예: 100만개)
CONCURRENCY="512"             # 동시 클라이언트 수

echo ">>> 버킷 준비 중..."
mc mb --ignore-existing $TARGET

echo ">>> 작은 오브젝트 쓰기 워크로드 시작 (PUT)..."
warp put --host $TARGET \
         --obj.size $OBJ_SIZE \
         --objects $OBJECTS \
         --concurrent $CONCURRENCY \
         --duration 5m \
         --noclear --insecure \
         --benchdata warp_put_4k.json

echo ">>> 작은 오브젝트 읽기 워크로드 시작 (GET)..."
warp get --host $TARGET \
         --obj.size $OBJ_SIZE \
         --objects $OBJECTS \
         --concurrent $CONCURRENCY \
         --duration 5m \
         --noclear --insecure \
         --benchdata warp_get_4k.json

echo ">>> 결과 CSV 생성"
warp report --benchdata warp_put_4k.json > report_put_4k.csv
warp report --benchdata warp_get_4k.json > report_get_4k.csv
  • PUT 4KB 오브젝트 → metadata IOPS 병목 확인
  • GET 4KB 오브젝트 → 읽기 path 성능 확인
  • warp 결과(warp_*_4k.json)는 그대로 Prometheus/Grafana와 대조 가능

2. Prometheus에서 IOPS vs Latency 추적

(A) IOPS (초당 요청 수)

sum(rate(minio_s3_requests_total{api="PutObject"}[1m]))
  • 초당 PUT 오브젝트 처리량 (IOPS)
  • GetObject로 바꾸면 읽기 처리량

(B) 평균 Latency

rate(minio_s3_requests_duration_seconds_sum{api="PutObject"}[1m])
/
rate(minio_s3_requests_duration_seconds_count{api="PutObject"}[1m])
  • 요청 평균 응답시간 (초)

(C) P95 Latency (분포 버킷 기반)

histogram_quantile(0.95,
  sum(rate(minio_http_requests_duration_seconds_bucket{api="PutObject"}[1m])) by (le)
)
  • PUT 요청의 95th percentile latency

3. 그래프 해석 포인트

  • IOPS가 계속 증가하다가 latency 곡선이 급상승하는 지점 = 메타데이터 처리 한계
  • 4KB vs 64KB vs 1MB 사이즈별로 비교하면, 작은 오브젝트는 latency 한계가 빨리 오고, 큰 오브젝트는 네트워크 대역폭 포화 시점에서 제한됨.
  • 오브젝트 수를 10억개까지 채운 후 LIST/DELETE 워크로드를 추가하면, 메타데이터 DB 및 파일시스템 디렉토리 구조의 병목이 더 빨리 드러남.

✅ 정리

  • warp_smallobj.sh로 작은 오브젝트 IOPS/Latency를 측정
  • Prometheus PromQL로 TPS vs Latency 곡선을 시각화 → 메타데이터 처리 한계 지점 식별

👉 혹시 이걸 Jenkins 파이프라인에 연동해서 테스트 실행 후 Grafana 대시보드 스냅샷 자동 캡처 → 리포트 PDF 저장까지 자동화하는 버전도 만들어드릴까요?

좋습니다 🚀
그럼 작은 오브젝트 워크로드 측정 (warp) → Prometheus/Grafana 대시보드 스냅샷 캡처 → PDF 리포트 저장까지 자동화하는 Jenkins 파이프라인 예제를 드릴게요.

1. Bash 스크립트 (워크로드 + Grafana 스냅샷 저장)

aistor_smallobj_bench.sh

#!/bin/bash
# 작은 오브젝트 워크로드 + Grafana 스냅샷 저장 스크립트

# === 환경 변수 ===
TARGET="myminio/testbucket"
OBJ_SIZE="4KiB"
OBJECTS="1000000"
CONCURRENCY="512"
DURATION="5m"

# Prometheus / Grafana 설정
GRAFANA_URL="http://grafana.local:3000"
GRAFANA_API_KEY="YOUR_GRAFANA_API_KEY"
DASHBOARD_UID="minio-perf"   # Grafana 대시보드 UID
PANEL_ID="2"                 # 특정 Panel ID (IOPS vs Latency 그래프)
SNAPSHOT_FILE="grafana_snapshot.png"
REPORT_PDF="warp_report.pdf"

# === 스토리지 준비 ===
echo ">>> 버킷 생성"
mc mb --ignore-existing $TARGET

# === 워크로드 실행 ===
echo ">>> 작은 오브젝트 PUT 실행"
warp put --host $TARGET \
         --obj.size $OBJ_SIZE \
         --objects $OBJECTS \
         --concurrent $CONCURRENCY \
         --duration $DURATION \
         --benchdata warp_put.json

echo ">>> 작은 오브젝트 GET 실행"
warp get --host $TARGET \
         --obj.size $OBJ_SIZE \
         --objects $OBJECTS \
         --concurrent $CONCURRENCY \
         --duration $DURATION \
         --benchdata warp_get.json

# === 리포트 CSV 생성 ===
warp report --benchdata warp_put.json > report_put.csv
warp report --benchdata warp_get.json > report_get.csv

# === Grafana 스냅샷 캡처 ===
echo ">>> Grafana 대시보드 이미지 캡처"
curl -s -H "Authorization: Bearer $GRAFANA_API_KEY" \
     -o $SNAPSHOT_FILE \
     "$GRAFANA_URL/render/d/$DASHBOARD_UID/minio-perf?panelId=$PANEL_ID&width=1000&height=500"

# === PDF 리포트 합치기 ===
echo ">>> PDF 리포트 생성"
python3 <<'EOF'
from reportlab.lib.pagesizes import A4
from reportlab.pdfgen import canvas

c = canvas.Canvas("warp_report.pdf", pagesize=A4)
c.setFont("Helvetica-Bold", 16)
c.drawString(50, 800, "MinIO Small Object Benchmark Report")

c.setFont("Helvetica", 12)
c.drawString(50, 770, "Object Size: 4KiB")
c.drawString(50, 750, "Concurrency: 512")
c.drawString(50, 730, "Duration: 5m")

c.drawString(50, 700, "PUT Results (report_put.csv)")
c.drawString(50, 680, "GET Results (report_get.csv)")

# Grafana 스냅샷 이미지 삽입
from reportlab.platypus import Image
img = Image("grafana_snapshot.png", width=500, height=250)
img.drawOn(c, 50, 400)

c.save()
EOF

echo ">>> 완료: warp_report.pdf"

2. Jenkinsfile (자동 실행 파이프라인)

Jenkinsfile

pipeline {
  agent any
  parameters {
    string(name: 'OBJ_SIZE', defaultValue: '4KiB', description: 'Object size')
    string(name: 'OBJECTS', defaultValue: '1000000', description: 'Number of objects')
    string(name: 'CONCURRENCY', defaultValue: '512', description: 'Concurrency level')
    string(name: 'DURATION', defaultValue: '5m', description: 'Test duration')
  }
  stages {
    stage('Checkout') {
      steps {
        git 'https://your.repo.url/minio-bench.git'
      }
    }
    stage('Run Warp Benchmark') {
      steps {
        sh "bash aistor_smallobj_bench.sh"
      }
    }
    stage('Archive Results') {
      steps {
        archiveArtifacts artifacts: '*.csv, *.json, *.pdf, *.png', fingerprint: true
      }
    }
    stage('Publish Report') {
      steps {
        publishHTML([reportDir: '.', reportFiles: 'warp_report.pdf', reportName: 'MinIO Benchmark Report'])
      }
    }
  }
}

3. 실행 흐름

  1. Jenkins가 aistor_smallobj_bench.sh 실행
  2. warp PUT/GET 테스트 → CSV/JSON 리포트 생성
  3. Grafana API로 대시보드 스냅샷 PNG 캡처
  4. Python(reportlab)으로 PDF 리포트 생성 (메타데이터 + 그래프 포함)
  5. Jenkins에서 PDF/CSV/PNG 아카이브 및 HTML 리포트로 제공

✅ 이렇게 하면 테스트 끝나자마자 Jenkins에서 PDF 리포트를 바로 내려받을 수 있고, IOPS vs Latency 그래프까지 자동으로 포함돼요.

좋습니다 👍 이제 멀티 오브젝트 사이즈 (4KiB / 64KiB / 24MiB / 128MiB) 를 한 번에 돌리고 → 결과를 모두 모아 → 비교 그래프 + PDF 리포트까지 Jenkins 파이프라인으로 자동화하는 버전을 드릴게요.

1. 멀티 사이즈 워크로드 스크립트

aistor_multisize_bench.sh

#!/bin/bash
# 여러 오브젝트 사이즈 벤치마크 후 PDF 리포트 자동 생성

# === 환경 변수 ===
TARGET="myminio/testbucket"
OBJECTS="200000"         # 사이즈 커질수록 개수는 줄여야 시간/공간 절약
CONCURRENCY="256"
DURATION="3m"
SIZES=("4KiB" "64KiB" "24MiB" "128MiB")

GRAFANA_URL="http://grafana.local:3000"
GRAFANA_API_KEY="YOUR_GRAFANA_API_KEY"
DASHBOARD_UID="minio-perf"
PANEL_ID="2"

mkdir -p results

# === 버킷 준비 ===
mc mb --ignore-existing $TARGET

# === 워크로드 반복 실행 ===
for SIZE in "${SIZES[@]}"; do
  echo ">>> 워크로드 시작 (PUT/GET, size=$SIZE)"
  warp put --host $TARGET \
           --obj.size $SIZE \
           --objects $OBJECTS \
           --concurrent $CONCURRENCY \
           --duration $DURATION \
           --benchdata results/warp_put_${SIZE}.json

  warp get --host $TARGET \
           --obj.size $SIZE \
           --objects $OBJECTS \
           --concurrent $CONCURRENCY \
           --duration $DURATION \
           --benchdata results/warp_get_${SIZE}.json

  warp report --benchdata results/warp_put_${SIZE}.json > results/report_put_${SIZE}.csv
  warp report --benchdata results/warp_get_${SIZE}.json > results/report_get_${SIZE}.csv
done

# === Grafana 스냅샷 저장 ===
curl -s -H "Authorization: Bearer $GRAFANA_API_KEY" \
     -o results/grafana_snapshot.png \
     "$GRAFANA_URL/render/d/$DASHBOARD_UID/minio-perf?panelId=$PANEL_ID&width=1200&height=600"

# === PDF 통합 리포트 생성 ===
python3 <<'EOF'
import glob
import pandas as pd
import matplotlib.pyplot as plt
from reportlab.lib.pagesizes import A4
from reportlab.pdfgen import canvas

# 결과 CSV 불러오기
sizes = ["4KiB", "64KiB", "24MiB", "128MiB"]
put_rates = []
get_rates = []

for size in sizes:
    put = pd.read_csv(f"results/report_put_{size}.csv")
    get = pd.read_csv(f"results/report_get_{size}.csv")
    put_rate = put["Throughput"].iloc[0]
    get_rate = get["Throughput"].iloc[0]
    put_rates.append(put_rate)
    get_rates.append(get_rate)

# 그래프 생성
plt.figure(figsize=(8,5))
plt.plot(sizes, put_rates, marker="o", label="PUT ops/s")
plt.plot(sizes, get_rates, marker="s", label="GET ops/s")
plt.xlabel("Object Size")
plt.ylabel("Throughput (ops/s)")
plt.title("MinIO Performance by Object Size")
plt.legend()
plt.grid(True)
plt.savefig("results/summary.png")

# PDF 생성
c = canvas.Canvas("results/warp_multisize_report.pdf", pagesize=A4)
c.setFont("Helvetica-Bold", 16)
c.drawString(50, 800, "MinIO Multi-Size Benchmark Report")

c.setFont("Helvetica", 12)
y = 770
for size, pr, gr in zip(sizes, put_rates, get_rates):
    c.drawString(50, y, f"Size={size}: PUT={pr:.2f} ops/s, GET={gr:.2f} ops/s")
    y -= 20

c.drawImage("results/summary.png", 50, 400, width=500, height=300)
c.drawImage("results/grafana_snapshot.png", 50, 100, width=500, height=250)
c.save()
EOF

echo ">>> 완료: results/warp_multisize_report.pdf"

2. Jenkinsfile (멀티 사이즈 파이프라인)

pipeline {
  agent any
  stages {
    stage('Checkout') {
      steps {
        git 'https://your.repo.url/minio-bench.git'
      }
    }
    stage('Run Multi-Size Warp Benchmark') {
      steps {
        sh "bash aistor_multisize_bench.sh"
      }
    }
    stage('Archive Results') {
      steps {
        archiveArtifacts artifacts: 'results/*.csv, results/*.json, results/*.png, results/*.pdf', fingerprint: true
      }
    }
    stage('Publish Report') {
      steps {
        publishHTML([reportDir: 'results', reportFiles: 'warp_multisize_report.pdf', reportName: 'MinIO Benchmark Report'])
      }
    }
  }
}

3. 결과물

  • 사이즈별 PUT/GET 성능 CSV (report_put_*.csv, report_get_*.csv)
  • 성능 비교 그래프 (summary.png)
  • Grafana 대시보드 스냅샷 (grafana_snapshot.png)
  • 최종 PDF 리포트 (warp_multisize_report.pdf) → Jenkins에서 다운로드 가능

✅ 이렇게 하면 한 번의 파이프라인 실행으로 4KiB → 64KiB → 24MiB → 128MiB 성능 곡선과 Grafana 실시간 메트릭 스냅샷이 모두 들어간 PDF가 자동으로 생성돼요.

👉 혹시 PDF에 Latency (평균, P95) 까지 포함해서 Throughput vs Latency 이중 축 그래프로 보여드릴까요?

좋은 질문이에요 👍 성능테스트에서 object size를 어떻게 설정하느냐는 워크로드 특성을 얼마나 잘 재현하느냐와 직결됩니다. 지금 상황(기존 워크로드, 향후 마이그레이션 계획)을 놓고 보면 이렇게 생각하면 돼요:

1. 극단적인 사이즈 (1B, 1KiB, 100MiB) 테스트의 의미

  • 1B ~ 1KiB

    • 현실적인 워크로드에서는 잘 안 씁니다.
    • 하지만 메타데이터/네임스페이스 IOPS 한계를 확인하기 위한 “스트레스 테스트” 용도로 의미가 있어요.
    • 예: “작은 오브젝트를 10억 개 넣으면 MinIO metadata 계층이나 etcd 쪽에서 어떤 병목이 나는지” 확인.
    • 따라서 운영 workload와 직접적 관련은 없지만, 시스템의 최악 케이스 내성을 보는 데는 의미 있음.

  • 100MiB+

    • 네트워크/스토리지 대역폭 포화 지점을 확인할 수 있음.
    • Hadoop block size(128MiB)와도 관련되므로 “S3 마이그레이션 시 병목 없을지”를 점검하는데는 꽤 중요.

2. 실제 워크로드 기반 (3KiB~512KiB / 24MiB / 128MiB)

  • 소형 오브젝트 (3KiB~512KiB)

    • 서비스성 요청 (API, 로그, IoT 이벤트) 같은 workload 패턴 반영.
    • 이 구간에서는 metadata IOPS / TCP stack이 주 병목.
    • 성능 측정 시 → Throughput (ops/s) vs Latency (ms)를 보는 게 핵심.

  • 대형 오브젝트 (24MiB / 128MiB)

    • Hadoop/Spark/HDFS 마이그레이션 시 현실적인 사이즈.
    • 여기서는 메타데이터 부담은 거의 없고, 네트워크 및 디스크 대역폭이 성능 한계 결정.
    • 따라서 EC(8:3) 인코딩 비용 + 네트워크 본딩(50Gbps) vs 스위치 백플레인(40G/200G) 영향 평가에 의미 있음.

3. 추천 테스트 전략 (POC 시)

👉 운영과 무관한 사이즈(1B, 1KiB)는 짧게 sanity check 정도로만,
👉 실제 중요 workload (3–512KiB / 24MiB / 128MiB)는 집중적으로 성능曲線을 뽑는 게 효과적입니다.

즉,

  • 소형 테스트 세트: 4KiB, 64KiB, 256KiB
  • 중간: 1MiB, 8MiB
  • 대형: 24MiB, 128MiB
  • (옵션) 극단: 1B, 100MiB → 한 번씩만 돌려 시스템 내성 확인

4. Migration 관점 (Hadoop → S3)

  • Hadoop block size 128MiB라고 해서 S3 object를 꼭 128MiB로 맞출 필요는 없음

    • S3 API는 object 단위로만 관리되고, 내부적으로 block이란 개념 없음.
    • 일반적으로 map/reduce job이나 reader가 평균 object size에 맞춰 처리하므로, 24MiB 같은 크기로도 충분히 가능.
    • 다만, S3 Select / Spark connector / Presto 같은 엔진들이 object 개수 증가 시 list/seek 비용이 커지므로, 너무 잘게 쪼개면 불리.

  • 결론적으로:

    • 128MiB object는 HDFS block 1:1 매핑이 쉬워서 마이그레이션 도구 설계가 단순.
    • 24MiB object는 object 수가 많아져서 metadata 부담은 커지지만, 분산성(병렬성) 확보에 유리.
    • 두 사이즈 모두 테스트해보고, list latency vs 병렬 처리 효율 trade-off를 확인하는 게 가장 확실.

✅ 요약

  • 1B, 1KiB 같은 극단 사이즈는 “참고용 스트레스 테스트”로만 → 실제 workload 분석에는 크게 필요 없음.
  • 반드시 테스트해야 하는 건 3–512KiB (소형), 24MiB, 128MiB (대형).
  • Hadoop → S3 마이그레이션 시 object size는 꼭 128MiB 고정일 필요 없고, 24MiB/128MiB 모두 테스트 후 trade-off 결정하는 게 맞음.

👉 원하시면 제가 위에 추천한 테스트 사이즈 세트(4KiB, 64KiB, 256KiB, 1MiB, 8MiB, 24MiB, 128MiB) 기준으로 warp + Jenkinsfile 멀티러너 자동화 버전을 만들어드릴까요?

profile
Young-Kyoo Kim
engineer
이전 포스트

test0824

다음 포스트

test0824b

0개의 댓글