전체 요구사항과 현재 AIStor의 제약을 보면, "Prefix Management Platform(PMP)"을 별도 제품처럼 설계하는 것이 가장 적절합니다.

특히 사용자가 구축 중인 환경(200~300노드 Kubernetes, CNPG, Keycloak, Kafka, Redis, GitOps, 대규모 멀티테넌시)을 고려하면 단순 API Server가 아니라 Metadata Control Plane으로 설계하는 것이 향후 AIOps나 Data Catalog까지 확장성이 훨씬 좋습니다.

제가 권장하는 방향은 기존보다 조금 더 구조를 바꾸는 것입니다.

---

전체 방향

현재 생각

MinIO Event

Kafka

Redis

API Server

CNPG

보다

아래처럼 역할을 분리하는 것을 추천합니다.

                +-------------------------+
                |     Client / Portal     |
                +-----------+-------------+
                            |
                            |
                     Prefix API Server
                            |
        +-------------------+--------------------+
        |                                        |
        |                                        |
 Metadata Service                        Auth Service
        |                                        |
        |                                        |
        +------------+---------------+-----------+
                     |
              Metadata DB(CNPG)
                     |
      -------------------------------
      |              |              |
 Prefix Table    Object Table   History Table
                     ^
                     |
             Metadata Updater
                     ^
                     |
              Redis Aggregator
                     ^
                     |
              Kafka Consumer
                     ^
                     |
          MinIO Bucket Notification
                     |
                 Kafka Topic

즉

API Server와

Event 처리기를 분리합니다.

이게 상당히 중요합니다.

---

왜 분리해야 하는가

API Server는

절대로

초당 수만 Event를 처리하면 안됩니다.

역할이 다릅니다.

API Server는

• REST API
• 인증
• Prefix CRUD
• 조회
• 권한

만 담당

Event는

별도의 Worker가 처리합니다.

그러면

API Scale과

Event Scale을

독립적으로 늘릴 수 있습니다.

예)

API Server

2 Pods

↓

Event Consumer

30 Pods

이렇게 됩니다.

---

추천 Architecture

① Prefix API

역할

• Prefix 생성
• Alias 수정
• Prefix 조회
• Quota 설정
• 권한 설정
• Presigned URL 발급
• Object List 조회

이 서버는

Event 처리하지 않습니다.

---

② Metadata Updater

이게 핵심입니다.

Kafka Consumer입니다.

하는 일은

Kafka

↓

ObjectCreated

↓

Redis 증가

↓

ObjectCreated Log 저장

↓

Batch Flush

↓

CNPG

삭제도 동일합니다.

---

③ Redis Aggregator

Redis는 Cache가 아니라

Aggregation 용도로 사용합니다.

예)

Prefix A

+100MB

+200MB

-30MB

+400MB

CNPG에는

매번 UPDATE 하지 않습니다.

Redis

prefix_usage_delta

+670MB

만 저장합니다.

5초

또는

1000건

마다

CNPG UPDATE

usage = usage +670MB

합니다.

DB IOPS가 엄청 줄어듭니다.

---

Redis에 무엇을 저장할까?

추천

prefix_usage_delta

Hash

prefix

delta_bytes

delta_count

또

daily_upload_count

daily_download_count

도 Redis

Sorted Set

추천합니다.

---

Kafka Topic 설계

절대로 하나의 Topic만 쓰지 않습니다.

추천

bucket-events

audit-events

server-events

quota-events

분리

---

그리고

Partition Key

추천

bucket/prefix

입니다.

Object Key까지 넣지 않습니다.

왜냐면

Prefix 순서를 보장해야 합니다.

---

CNPG Schema

Object Table

object_id

bucket

object_name

prefix

size

etag

owner

created

modified

deleted

---

Prefix Table

prefix

bucket

alias

quota

used_size

object_count

owner

status

ilm

created

updated

---

History Table

event_time

event_type

object

size

before

after

user

ip

---

Daily Statistic

date

prefix

upload_count

download_count

growth

delete

---

Object Table를 유지해야 하는가?

이게 가장 큰 설계 포인트입니다.

많은 사람이

Object Table을 만들지만

추천하지 않습니다.

왜냐하면

100억 Object

가면

DB가 터집니다.

추천

Level 분리

Level1

Prefix Metadata

항상 유지

Level2

최근 N일 Object

예)

30일

Level3

Inventory

Parquet

필요 시 조회

이게 가장 현실적입니다.

---

Object List는?

요구사항에는

Object List 조회가 있습니다.

그런데

Object Metadata를

영구 저장하는 건

추천하지 않습니다.

추천

최근 30일

↓

CNPG

30일 이상

↓

Inventory(Table)

조회 시

자동 Merge

---

Event 처리 Flow

ObjectCreated

↓

Kafka

↓

Consumer

↓

Redis

↓

5초

↓

CNPG Update

↓

Prometheus Exporter

↓

Grafana

---

Reconciliation

이건 반드시 필요합니다.

추천

매일

Inventory

↓

Parquet

↓

Spark

↓

Compare

↓

Difference

↓

CNPG Update

입니다.

Object Scan

하지 않습니다.

Inventory를 이용합니다.

---

API Server 기능

추천

모듈 분리

Prefix API

Quota API

Metadata API

Search API

Admin API

Presigned API

Policy API

---

Redis가 꼭 필요한가?

제 의견은

YES입니다.

조건은

Event가

초당

500건 이상

이면

필수입니다.

100TPS 이하

없어도 됩니다.

대규모 AIStor는

거의 필수입니다.

---

Kafka가 꼭 필요한가?

YES

Webhook는 추천하지 않습니다.

이유

재전송

Replay

Consumer 추가

Backpressure

가 안됩니다.

Kafka가 훨씬 안정적입니다.

---

Event Sourcing

가능하면

CNPG는

Current State만 저장합니다.

Event는

Kafka에 남깁니다.

필요하면

Replay

가능합니다.

이게 운영성이 매우 좋습니다.

---

1차년도 추천 범위

제가 조금 수정하고 싶은 부분입니다.

현재 제안보다

Metadata 기반을 먼저 튼튼히 만드는 것이 중요합니다.

구분	내용
API	Prefix CRUD
API	Alias
API	Object Search
API	Quota CRUD
Kafka	Event 수집
Redis	Aggregation
CNPG	Metadata
Reconciliation	Daily Inventory
STS	Presigned
Monitoring	API 상태

여기까지만 해도 충분합니다.

Quota Enforcement

Soft Delete

Dashboard

Anomaly Detection

은

2차로 넘기는 것이 리스크가 훨씬 적습니다.

---

2차년도 추천

여기부터는 AIOps 영역입니다.

Trend 분석

↓

Forecast

↓

Quota 예측

↓

Auto Expand

↓

Auto Archive

↓

Recommendation

또는

비정상 삭제

↓

ML Detection

↓

Alert

그리고

Heat Prefix

Cold Prefix

ILM 추천

Compression 추천

Small Object 추천

같은 기능이 추가될 수 있습니다.

---

추가로 반드시 고려해야 할 사항 (현재 요구사항에 없는 핵심 항목)

현재 요구사항를 검토하면서 가장 크게 보완이 필요하다고 판단되는 부분은 다음과 같습니다.

항목	중요도	이유
Metadata Versioning	★★★★★	Prefix/Quota/Alias 변경 이력을 모두 버전 관리하여 롤백 및 감사 지원
Event Idempotency Store	★★★★★	Kafka 재전송 및 Consumer 재시작 시 중복 반영 방지
Metadata Snapshot	★★★★★	대량 장애 발생 시 Prefix 메타데이터를 특정 시점으로 복구
DLQ(Dead Letter Queue)	★★★★★	처리 실패 이벤트를 별도 보관하여 데이터 유실 방지
Backpressure 제어	★★★★☆	Redis 또는 DB 지연 시 Consumer 속도를 동적으로 조절
Multi-Worker Lock	★★★★☆	동일 Prefix를 여러 Worker가 동시에 갱신하는 상황 방지
Schema Evolution	★★★★☆	향후 AI 기능(예: Owner, Data Classification, Cost Center 등) 추가를 고려한 확장형 스키마 설계
Observability	★★★★★	Kafka Lag, Redis Flush 지연, CNPG Write Latency, Event 처리율 등 플랫폼 자체 상태를 지속적으로 모니터링

이러한 요소까지 포함해 설계하면, 이 플랫폼은 단순한 "Prefix 관리 API"가 아니라 향후 Data Lakehouse Metadata Control Plane으로 발전시킬 수 있으며, 사용 중인 AIStor 및 Kubernetes 기반 멀티테넌시 환경에서도 안정성과 확장성을 확보할 수 있습니다.