26J29m2

Young-Kyoo Kim·2026년 6월 29일

결론부터 말하면 충분히 실현 가능하며, 오히려 AIStor Enterprise에서 부족한 "Prefix Metadata Layer"를 만드는 아키텍처라고 생각합니다.

특히 현재 AIStor는

Bucket = First-class Object
Object = First-class Object
Prefix = Object Name의 문자열

취급이기 때문에 Prefix 자체에 대한 메타정보는 거의 없습니다.

반면 실제 Enterprise Data Lake에서는 관리 단위가 Bucket이 아니라 거의 대부분 Prefix(Project, Team, Dataset, User Sandbox) 입니다.

예)

bucket
 ├── finance/
 ├── sales/
 ├── hr/
 ├── ai/
 └── users/
       ├── user01/
       ├── user02/
       └── user03/

실제 운영자는 bucket이 아니라

finance/

를 관리하고 싶어합니다.

그래서 별도의 Metadata Server를 두는 접근은 상당히 좋은 구조입니다.

API Server가 담당하는 기능

API Server는 크게 5가지 역할을 하게 됩니다.

1. Prefix Registry

가장 중요한 기능입니다.

예를 들어

finance/raw/

finance/report/

sales/2026/

각 Prefix를 하나의 Entity처럼 관리합니다.

Prefix

id

bucket

prefix

owner

created_at

updated_at

alias

description

status

이게 모든 기능의 중심이 됩니다.

2. Statistics Engine

사용자가 원하는

총 Object 개수

총 용량

평균 Object 크기

최근 증가량

최근 삭제량

등을 관리합니다.

예)

prefix_statistics

prefix_id

object_count

size

last_scan

daily_growth

weekly_growth

monthly_growth

이 정보는

mc inventory

또는

S3 LIST

에서 갱신됩니다.

3. Policy Cache

AIStor에서 조회 가능한

ILM

Versioning

Object Lock

Replication

등을 캐싱합니다.

왜냐하면 UI에서

6000 Prefix를 매번 API 호출하면 느립니다.

그래서

Bucket Policy

↓

API Server Cache

↓

Prefix Mapping

으로 가져가는 것이 좋습니다.

4. Quota Engine

AIStor는 Prefix Quota가 없습니다.

그래서

Quota

50TB

10M Objects

같은 기능은

Metadata Layer에서 구현해야 합니다.

업로드 시

Current

+

Incoming

>

Quota

이면

Webhook

또는

Proxy

또는

OPA

에서 차단 가능합니다.

5. Prefix Lifecycle

이 부분이 가장 Enterprise스럽습니다.

예)

POST

/prefix

{
 bucket
 prefix
 owner
}

하면

자동으로

.placeholder

생성

Metadata 생성

Owner 등록

Quota 생성

Alias 생성

Audit 기록

까지 수행합니다.

Metadata DB 추천 Schema

제가 추가하고 싶은 컬럼들입니다.

Prefix

id

bucket

prefix

alias

display_name

description

owner

group

business_unit

dataset_type

status

depth

created_at

updated_at

created_by

updated_by

placeholder_object

Statistics

object_count

size

deleted_size

deleted_count

small_object_ratio

average_object_size

max_object_size

last_scan

Growth

daily_growth

weekly_growth

monthly_growth

prediction_30d

prediction_90d

Quota

soft_limit

hard_limit

warning_ratio

Policy

versioning

ilm

replication

retention

legal_hold

Alert

last_large_delete

last_spike

last_slowdown

Inventory Update

이 부분은 거의 필수입니다.

Owner

Owner도 매우 좋은 기능입니다.

Bucket Owner와 별도로

Finance Team

AI Team

홍길동

처럼 관리 가능합니다.

Alias

굉장히 좋은 아이디어입니다.

예)

실제

dataset/raw/project123/

Alias

AI Raw Data

Portal에서는 Alias만 보여주면 됩니다.

Prediction

이건 AI를 넣기 좋은 부분입니다.

예)

최근 90일

↓

ARIMA

Prophet

LSTM

↓

30일 후

120TB 예상

Capacity Planning이 됩니다.

Alert

추천하는 Alert 종류입니다.

분류	조건
Large Delete	5분간 삭제량 > 기준
Growth Spike	평균 대비 5배 증가
PUT 폭증	PUT/sec 급증
GET 폭증	GET/sec 급증
Latency 증가	평균 대비 2배
Inventory 변화 없음	수집 실패
Quota 80%	경고
Quota 95%	Critical

Dashboard

권한별 Dashboard도 매우 좋습니다.

예)

Admin

전체

↓

BU 관리자

Finance

↓

팀장

AI Team

↓

사용자

내 Prefix만

Keycloak JWT의 Group Claim을 그대로 활용하면 구현이 깔끔합니다.

제가 추가하고 싶은 기능

여기서 끝내지 않고 Enterprise라면 아래도 거의 필수입니다.

① Audit Log ★★★★★

누가

생성

삭제

Alias 변경

Quota 변경

Owner 변경

했는지 모두 저장해야 합니다.

② Prefix Tag

Environment

PII

Production

Archive

ML

Finance

Tag 검색이 가능해야 합니다.

③ Prefix Health Score

예)

Health

97

계산

Quota

Growth

Errors

Delete

Latency

Availability

④ Cost

OpenCost와 연결하면

Storage Cost

Request Cost

Growth Cost

까지 나옵니다.

⑤ Recommendation Engine

Object 너무 작음

↓

Compress 추천

ILM 없음

↓

추천

Versioning 필요

↓

추천

⑥ Prefix Search

Google처럼

raw

finance

2026

검색 가능해야 합니다.

⑦ Approval Workflow

100TB 이상 Prefix 생성

↓

Manager Approval

↓

자동 생성

기업 환경에서는 특히 유용합니다.

장기적으로 추천하는 방향

현재 구상은 단순한 Prefix 메타 관리 수준을 넘어, AIStor 위에 "Enterprise Metadata Control Plane"을 구축하는 방향으로 발전시키는 것이 좋습니다.

                Enterprise Portal
                       │
        ┌──────────────┴──────────────┐
        │                             │
  Prefix Metadata API           Admin API
        │                             │
        ├──────────────┬──────────────┤
        │              │              │
 Prefix Registry   Statistics    Policy Engine
        │              │              │
        ├──────────────┴──────────────┤
        │       PostgreSQL (CNPG)     │
        └──────────────┬──────────────┘
                       │
        ┌──────────────┼────────────────────────────┐
        │              │                            │
 Inventory Sync   Event Processor           Metrics Collector
(mc inventory)   (S3 Event/Kafka/NATS)   (Prometheus/OpenCost)
        │              │                            │
        └──────────────┴──────────────┬─────────────┘
                                      │
                               MinIO AIStor

이 구조는 사용자가 추진 중인 Cloud Native Data Lakehouse와도 매우 잘 맞습니다. 여기에 이미 계획 중인 OpenCost, Prometheus, Keycloak, GitOps 체계를 연계하면 단순한 메타 관리가 아니라 스토리지 운영, 비용, 보안, 용량 계획, 이상 탐지까지 통합하는 플랫폼으로 확장할 수 있습니다.

추가로 제안드리자면, API Server를 플러그인(Provider) 구조로 설계하는 것을 권장합니다. Storage Provider 인터페이스를 두어 현재는 AIStor만 구현하고, 이후에는 S3 호환 스토리지나 HDFS, NAS까지 동일한 Prefix 메타 모델로 관리할 수 있게 하면 특정 스토리지에 종속되지 않는 데이터 관리 플랫폼으로 발전시킬 수 있습니다. 이는 향후 데이터 마이그레이션이나 멀티 스토리지 운영 시에도 큰 장점이 됩니다.

Young-Kyoo Kim

engineer

이전 포스트

26J29m1

다음 포스트

26J29m2

추천 전체 구조

API Server가 담당하는 기능

1. Prefix Registry

2. Statistics Engine

3. Policy Cache

4. Quota Engine

5. Prefix Lifecycle

Metadata DB 추천 Schema

Inventory Update

Owner

Alias

Prediction

Alert

Dashboard

제가 추가하고 싶은 기능

① Audit Log ★★★★★

② Prefix Tag

③ Prefix Health Score

④ Cost

⑤ Recommendation Engine

⑥ Prefix Search

⑦ Approval Workflow

장기적으로 추천하는 방향

26J29m1

26J29m3

0개의 댓글