26Y02d2c
네. 오히려 이 매핑 작업이 가장 중요합니다.
현재 요구사항을 보면 "API Server에서 모두 구현"처럼 보이지만, 실제로는 AIStor가 이미 제공하는 기능은 최대한 그대로 사용하고(API Pass-through), AIStor가 제공하지 않는 기능만 Metadata Control Plane에서 보완하는 구조가 가장 유지보수성과 안정성이 좋습니다.
제가 권장하는 기준은 아래와 같습니다.
- Level A : AIStor API 그대로 호출 (재구현 금지)
- Level B : AIStor API + Metadata DB 조합
- Level C : Metadata Control Plane 자체 구현
- Level D : 향후 AIOps 기능
1. Prefix Lifecycle
| 기능 | AIStor API | API Server 구현 | 비고 |
|---|---|---|---|
| Prefix 생성 | PutObject(.keep) | Name Validation + Placeholder 생성 | B |
| Prefix 삭제 | DeleteObjects / Batch Job | 삭제 Workflow | B |
| Prefix Rename | 미지원 | Alias만 변경 | C |
| Prefix Alias | 없음 | MetaDB | C |
| Prefix Description | 없음 | MetaDB | C |
| Prefix Tag | Object Tagging 활용 불가(Prefix 개념 없음) | MetaDB | C |
| Prefix Template | 없음 | API Server | C |
| Prefix Clone | PutObject + Meta 복사 | Workflow | C |
| Prefix Archive | ILM + Metadata | 상태관리 | B |
| Prefix Freeze | IAM Policy 변경 | API Server | B |
| Prefix Lock | IAM Deny Policy | API Server | B |
| Prefix Expiration | ILM | API 생성 | B |
2. Object 조회
| 기능 | AIStor API | API Server |
|---|---|---|
| Object List | ListObjectsV2 | MetaDB 조회 |
| Object Metadata | StatObject | MetaDB 우선 |
| Object Download | GetObject | Proxy 또는 Presigned URL |
| Object Upload | PutObject | Presigned URL |
| Multipart Upload | Multipart API | Presigned URL |
| Object Delete | DeleteObject | 그대로 호출 |
| Object Restore | Versioning API | Wrapper |
여기서 Object List는 절대 ListObjectsV2를 계속 호출하지 않는 것을 추천합니다.
3. Metadata
AIStor에는 없습니다.
모두 MetaDB
| 기능 |
|---|
| Alias |
| Description |
| Business Unit |
| Project |
| Cost Center |
| Classification |
| Owner |
| Retention |
| Approval |
| Status |
4. Quota
AIStor Bucket Quota는 있습니다.
하지만 Prefix Quota는 없습니다.
따라서
| 기능 | AIStor | API Server |
|---|---|---|
| Bucket Quota | O | Pass |
| Prefix Quota | X | MetaDB |
| Soft Limit | X | Redis |
| Hard Limit | X | Redis |
| Quota Alert | Prometheus + Alertmanager | Wrapper |
| Quota Forecast | X | AI |
5. Authentication
이 부분은 AIStor를 최대한 이용합니다.
| 기능 | AIStor |
|---|---|
| LDAP | O |
| AD | O |
| OIDC | O |
| STS | O |
| IAM | O |
| AssumeRole | O |
API Server는
추가적인
Workflow만 수행합니다.
예)
권한 신청
↓
승인
↓
mc admin policy attach6. Permission
| 기능 | AIStor |
|---|---|
| Read | IAM |
| Write | IAM |
| Admin | IAM |
| Prefix Policy | IAM Policy |
| Dynamic Attach | Attach Policy LDAP |
API Server는
정책 생성
및 Attach
자동화
7. Monitoring
여기는 AIStor가 꽤 잘 되어 있습니다.
| 기능 | AIStor |
|---|---|
| Bucket Usage | O |
| Bucket Object Count | O |
| Cluster Metric | O |
| Node Metric | O |
| Drive Metric | O |
| Network Metric | O |
없는 것
| 기능 |
|---|
| Prefix Usage |
| Prefix Growth |
| Prefix Access Count |
| Prefix Hotspot |
| Prefix Trend |
8. Event
AIStor 기능 적극 활용
| Event | AIStor |
|---|---|
| ObjectCreated | O |
| ObjectRemoved | O |
| ObjectAccessed | O |
| Replication | O |
| Lifecycle | O |
| Notification | Kafka |
API Server는
Consumer만 구현
9. Alert
| 기능 | AIStor |
|---|---|
| Audit Log | O |
| Server Log | O |
| Prometheus | O |
| Alertmanager | O |
추가 구현
-
Prefix Quota Alert
-
Prefix Delete Burst
-
Prefix Growth
10. Governance
AIStor에는 거의 없습니다.
| 기능 |
|---|
| Approval |
| Workflow |
| Metadata |
| Chargeback |
| Cost Center |
| Project |
| Search |
| Report |
전부 API Server
11. Archive
매핑
| 기능 | AIStor |
|---|---|
| Versioning | O |
| Object Lock | O |
| ILM | O |
| Replication | O |
API Server
↓
Archive Workflow
12. Search
AIStor
ListObjects보다
MetaDB
↓
SQL추천
13. Cost
AIStor 없음
Prefix Usage
×
단가
=
ChargebackAPI Server
14. Health
AIStor Metric +
Metadata
조합
예)
Health Score
=
Quota
+
Delete Rate
+
Small Object
+
Growth15. AI Recommendation
전부 API Server
예)
최근
30일
↓
증가율
↓
Quota 추천최종적으로는 이렇게 역할을 나누는 것이 가장 이상적입니다.
| 영역 | AIStor 활용 | API Server 추가 | 비고 |
|---|---|---|---|
| Object CRUD | 100% | Wrapper 최소화 | 기존 S3 API 활용 |
| IAM / STS / LDAP | 100% | 권한 신청·승인 Workflow | AIStor 기능 최대 활용 |
| Bucket 관리 | 100% | 필요 시 관리 API 래핑 | 중복 구현 금지 |
| Event Notification | 100% | Kafka Consumer | 이벤트 처리 파이프라인 |
| Monitoring(Cluster/Bucket) | 100% | 대시보드 구성 | 기존 메트릭 활용 |
| Prefix Metadata | 없음 | 100% 신규 | Control Plane 핵심 |
| Prefix Quota | 없음 | 100% 신규 | Redis + CNPG 기반 |
| Prefix 검색 | 없음 | 100% 신규 | MetaDB 활용 |
| Prefix 통계 | 일부(Event 기반) | 100% 신규 | 집계 엔진 구현 |
| Workflow(승인/Archive/Freeze 등) | 일부(IAM/ILM 활용) | 100% 신규 | 거버넌스 기능 |
| 비용 분석 / Chargeback | 없음 | 100% 신규 | 운영 관리 |
| AIOps / 예측 | 없음 | 100% 신규 | 2차년도 이후 |
추가로 권장하는 설계 원칙
이 프로젝트에서는 "AIStor를 객체 저장소(Object/Data Plane)로, Prefix Management Platform을 메타데이터·정책(Control Plane)로 명확히 분리"하는 것이 핵심입니다.
즉, 데이터 저장·전송·인증과 같은 기능은 AIStor의 검증된 API를 최대한 활용하고, Prefix라는 논리적 개념과 거버넌스, 검색, 쿼터, 비용, 통계, 워크플로우 등 AIStor가 제공하지 않는 기능만 API Server가 담당하도록 경계를 명확히 하면 향후 AIStor 업그레이드에도 영향이 적고 유지보수성이 크게 향상됩니다. 이는 Kubernetes의 Control Plane/Data Plane 분리와 유사한 설계 철학으로 보는 것이 가장 적합합니다.
