26Z03a

Young-Kyoo Kim·2026년 8월 3일

MinIO AIStor의 ObjectCreated(PutObject, CompleteMultipartUpload) 이벤트 로그를 Kafka $\rightarrow$ StarRocks(Internal Catalog) 파이프라인으로 흘려보내, 1st depth prefix별 실시간 사용량 측정 및 Quota 기반 Upload 제어를 구현하는 아키텍처에 대한 Kafka 자원 산정 가이드입니다.

제시해주신 트래픽 스펙(노드 128대 규모, 주요 버킷 2개 + 유사 버킷 3~4개 추가)을 기준으로 Kafka Topic의 파티션 수, 보관 기간(Retention), Retention 용량, 핵심 Config 설정값을 정밀 산정해 드립니다.

1. 전체 이벤트 트래픽(TPS & MB/s) 및 Payload 산정

MinIO Event Notification(Webhook/Kafka) 메시지 1건의 평균 크기는 약 1.5KB ~ 2KB 수준입니다. (JSON 형태: bucket, object key, size, etag, userAgent, timestamp 등 포함)

① 전체 버킷 총 RPS (이벤트 발생 건수)

Bucket A: Avg 21.7 rps / Max 64.7 rps (Put + CompleteMultipart)
Bucket B: Avg ~220 rps / Max 850 rps (Put 260 + CompleteMultipart 590)
추가 버킷 4개 (A/B 버킷 평균치 상회 가정): Max ~1,000 rps 내외
클러스터 전체 Peak TPS: 약 2,000 ~ 2,500 TPS (안전율 고려 3,000 TPS로 설계)

② Kafka로 전송되는 Event Payload 데이터량 (네트워크 Ingress)

초당 데이터 전송량: $3,000 \text{ events/sec} \times 2 \text{ KB/event} = \mathbf{6 \text{ MB/s}}$ (Peak 기준)
참고: 객체 본문 데이터( $980\text{MB/s}$ )는 MinIO S3로 들어가고, Kafka로는 메타데이터 이벤트 로그( $6\text{MB/s}$ )만 들어갑니다.

2. Kafka Topic 적정 Partition 개수 산정

파티션 개수는 (1) Producer(MinIO) Write 병렬성, (2) Consumer(StarRocks Routine Load) Read 처리량, (3) Key 기반 순서 보장을 종합 고려해야 합니다.

산정 논리

MinIO 클러스터 규모 (128 Nodes):
128개 노드의 MinIO AIStor가 동시에 Kafka로 이벤트를 발행합니다. 파티션 수가 너무 적으면 특정 Kafka Broker에 Network/I/O Bottleneck이 생깁니다.
StarRocks Routine Load 구조:
StarRocks의 Routine Load는 Topic의 Partition 개수 $\ge$ Routine Load Task 개수(Desired Concurrent Execution) 공식으로 동작합니다. StarRocks FE/BE가 파티션을 1:1 또는 N:1로 병렬 인제스천하므로, 파티션 수가 곧 StarRocks 파이프라인의 Parallelism이 됩니다.
Prefix별 Quota 집계 특성:
Prefix별 정밀 집계를 위해 StarRocks에서 GROUP BY를 수행하지만, Kafka단에서 Object Key(또나 Bucket Name)를 Message Key로 설정할 경우 동일 객체의 이벤트 순서가 보장됩니다.

💡 파티션 수 추천

추천 파티션 개수: 24개 ~ 32개 (단일 토픽 통합 기준) 또는 버킷별 토픽 분리 시 버킷당 8~16개
권장 구조 (단일 통합 토픽 minio-object-events 기준): 32 Partitions
이유: 32개 파티션 구성 시 파티션당 Peak TPS는 약 $100 \text{ TPS} (200\text{KB/s})$ 수준으로 매우 여유로우며, StarRocks Routine Load의 병렬 인제스천 성능을 극대화할 수 있습니다.

3. 보관 기간 (Retention Period) 및 용량 산정

Quota 계산용 데이터는 StarRocks Internal Catalog(OLAP Table)에 영구/주기적 적재되어 집계되므로, Kafka는 순수 버퍼(Message Queue) 역할만 수행하면 됩니다.

① Retention Time 설정

추천 retention.ms: 24시간 (86,400,000 ms) (최대 48시간)
사유: StarRocks 장애, 장애 복구(Maintenance), Schema 변경 등으로 인제스천이 중단되어도 하루 이상 메시지가 소실되지 않고 Queueing될 수 있는 충분한 Recovery Window를 제공합니다.

② Retention Capacity (토픽 필요 용량) 산정

일일 평균 이벤트 발생량:
평균 $1,200 \text{ TPS} \times 2 \text{ KB} = 2.4 \text{ MB/s}$
1일(24시간) 누적 데이터량:
$2.4 \text{ MB/s} \times 86,400 \text{ sec} \approx \mathbf{207 \text{ GB}}$
Peak 기준 (안전 수치):
$6 \text{ MB/s} \times 86,400 \text{ sec} \approx \mathbf{518 \text{ GB}}$
Replication Factor = 3 반영 시 필요 순수 디스크 용량:
$518 \text{ GB} \times 3 = \mathbf{1.55 \text{ TB}}$

💡 보관 용량 요청값 추천

토픽 물리 저장 용량 요청: 1.5 TB ~ 2 TB (Replica 3 기준)
Topic retention.bytes 설정: 파티션당 20 GB ( $20 \text{GB} \times 32 \text{ Partitions} = 640 \text{GB}$ Uncompressed)

4. Kafka 자원 요청 및 토픽 Config 명세서

Kafka 인프라 팀에 신청 시 전달할 표준 명세 정리입니다.

[Topic 요청 스펙]

항목	추천 값	설명 및 산정 근거
Topic Name	`minio-aistor-object-events`	MinIO AIStor ObjectCreated 전용 토픽
Partition Count	`32`	128 노드 분산 및 StarRocks Routine Load 병렬 처리 최적화
Replication Factor	`3`	엔터프라이즈 HA 표준 (min.insync.replicas=2)
Retention Time	`24 hours` (`86400000`)	StarRocks 장애 시 복구 버퍼용 (24시간)
Retention Size	`20 GB per partition`	토픽 전체 약 640GB (복제본 포함 1.92TB)
Expected Throughput	Ingress 6 MB/s (3,000 TPS)	Max Peak 기준 메시지 전송량
Cleanup Policy	`delete`	기간 및 용량 초과 시 자동 삭제

[추천 Topic Configuration (주요 설정값)]

# 메시지 보관 주기 설정 (24시간)
retention.ms=86400000

# 파티션 당 최대 보관 용량 (약 20GB)
retention.bytes=21474836480

# 단일 메시지 최대 크기 (MinIO 메타데이터 이벤트는 2KB 미만이므로 1MB로 충분)
max.message.bytes=1048576

# 데이터 유실 방지 (Acks=all과 조합)
min.insync.replicas=2

# 압축 옵션 (MinIO 이벤트는 JSON 형태이므로 zstd/lz4 압축률 매우 높음)
compression.type=zstd

5. 추가 고려사항 (StarRocks & Quota 제어)

MinIO Event Message Key 설정:

MinIO AIStor에서 Kafka Target 설정 시, Object Key(또는 bucket/1st-depth-prefix)가 Kafka의 Message Key로 들어가도록 설정하시는 것을 권장합니다.
이렇게 하면 특정 Prefix/Object의 Put/Complete Event가 동일한 Kafka Partition으로 순서대로 들어가, StarRocks로 유입될 때 순서 꼬임을 방지합니다.

StarRocks Routine Load 분산 수량:

StarRocks FE에서 Routine Load 생성 시 desired_concurrent_number를 8~16 정도로 설정하면, 32개 파티션을 효율적으로 나눠 마이크로 배치를 수행합니다.

Quota 판정 및 Upload 차단 루틴:

StarRocks 연산: StarRocks 내부에서 1st_depth_prefix 기준 SUM(object_size) 및 COUNT(1)를 계산하는 Materialized View 또는 실시간 쿼리를 준비합니다.
Custom Quota Controller (자체 개발): 주기적(예: 10초~1분 간격)으로 StarRocks를 조회하여 Quota 초과 여부를 감지하고, 초과 시 MinIO AIStor의 Bucket Policy 또는 User/Group Policy에 해당 Prefix에 대한 s3:PutObject Deny 문을 dynamic하게 적용(SetBucketPolicy / Policy Enforcement)하는 구조로 설계하시면 깔끔하게 제어 가능합니다.