26Y02d1c

Young-Kyoo Kim·어제

제안해 드린 아키텍처와 추가 기능들을 구현할 때, 맨땅에서 모두 개발하는 것이 아니라 MinIO AIStor가 제공하는 강력한 엔터프라이즈 기능(Primitives) 및 표준 S3 API를 백엔드 삼아 매핑해야 시스템이 가볍고 견고해집니다.

요구사항 및 확장 기능들이 MinIO AIStor의 어떤 핵심 기능/API와 직접 연결되고, API Server가 이를 어떻게 활용해야 하는지 구체적인 매핑 명세로 정리해 드립니다.

1. 인증·인가 및 보안 제어 체계

대상 요구사항: REQ-02-01 ~ 04 (AD 연동 및 권한 격리), 추가 기능 ① (서킷 브레이커)

MinIO AIStor는 AWS IAM과 100% 호환되는 자체 IAM 엔진을 내장하고 있어, Prefix 단위의 권한 제어를 완벽하게 백엔드에서 처리해 줍니다.

  • 매핑되는 AIStor 기능: AWS IAM Policy 규격 + OpenID Connect(OIDC)/LDAP 연동 + STS AssumeRole API
  • 구현 및 매핑 방식:
  • 글로벌 정책 단일화: AIStor에 사번이나 테넌트별로 정책을 수천 개 만들면 성능이 저하됩니다. 대신 Policy Variables(${aws:username})를 활용한 단 하나의 글로벌 정책만 등록합니다.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": ["arn:aws:s3:::my-lakehouse"],
            "Condition": {"StringLike": {"s3:prefix": ["${aws:username}/*"]}}
        },
        {
            "Effect": "Allow",
            "Action": ["s3:GetObject", "s3:PutObject"],
            "Resource": ["arn:aws:s3:::my-lakehouse/${aws:username}/*"]
        }
    ]
}
  • 토큰 발급 매핑: 사용자가 로그인하면 API Server는 내부적으로 사내 AD와 연동된 AIStor의 STS AssumeRoleWithLDAPIdentity API를 호출하여 해당 사번(username)이 주입된 임시 자격 증명(AccessKey/SecretKey/SessionToken)을 받아 사용자에게 전달합니다. 이 순간 AIStor 스토리지 레벨에서 타인 Prefix로의 접근이 원천 차단됩니다(REQ-02-02).
  • 서킷 브레이커 연계: 이상 징후 감지 시 API Server가 MinIO Admin API의 mc admin policy attach --deny 명령을 날려 해당 사용자의 AD 그룹에 명시적 Deny 정책을 실시간 바인딩하여 스토리지를 즉시 동결합니다.

2. 라이프사이클 및 데이터 보호

대상 요구사항: REQ-01-08 ~ 09 (삭제 및 Soft Delete), 추가 기능 ⑥ (콜드 데이터 티어링)

스토리지 내 객체를 물리적으로 지우고 옮기는 고부하 작업은 API Server가 직접 하지 않고, AIStor의 백그라운드 엔진에게 API로 위임합니다.

  • 매핑되는 AIStor 기능: Bucket Versioning + ILM (Object Lifecycle Management) Engines
  • 구현 및 매핑 방식:
  • 소프트 삭제 (REQ-01-09): 버킷의 Versioning을 활성화합니다. 사용자가 API Server를 통해 삭제 요청을 보낼 때, API Server는 표준 S3 API인 DeleteObject를 호출합니다. AIStor는 물리적 삭제 대신 DeleteMarker를 생성하여 소프트 삭제 상태로 만듭니다.
  • 자동 완전 삭제 규칙 매핑: AIStor의 ILM Policy에 Prefix 필터를 동적으로 추가하여, 특정 테넌트 경로의 영구 삭제 주기를 제어합니다.
<Rule>
    <ID>SoftDeleteRuleForTenantA</ID>
    <Filter><Prefix>tenant-a/</Prefix></Filter>
    <Status>Enabled</Status>
    <NoncurrentVersionExpiration><NoncurrentDays>30</NoncurrentDays></NoncurrentVersionExpiration>
</Rule>

이렇게 설정하면 API Server가 신경 쓰지 않아도 AIStor 가 백그라운드에서 정확히 30일 뒤에 청소합니다.

  • 콜드 데이터 티어링 매핑: AIStor의 핵심인 Storage Tiering (Transition) 기능과 매핑합니다. NVMe 기반의 핫 풀(Hot Pool)에서 저비용 HDD 기반의 콜드 풀(Cold Pool)로 객체를 이동시키는 매커니즘을 ILM Rule의 <Transition> 태그에 Prefix별로 매핑하여 비용을 최적화합니다.

3. 실시간 이벤트 수집 및 모니터링

대상 요구사항: REQ-03-02 (용량 트래킹), REQ-06-01 (성능 최적화), RFQ-05-01 (알람 엔진)

파일이 들어오고 나갈 때마다 이를 탐지하는 핵심 파이프라인입니다.

  • 매핑되는 AIStor 기능: Bucket Notification (MinIO Event Subsystem)
  • 구현 및 매핑 방식:
  • 이벤트 라우팅 매핑: AIStor는 웹훅뿐만 아니라 Kafka로 이벤트를 직결하는 내장 드라이버를 가지고 있습니다. mc event add 명령을 통해 AIStor 자체를 Kafka Producer로 등록합니다.
  • 이벤트 필터 최적화 (REQ-06-01): 모든 API 호출을 다 받으면 Kafka 부하가 심해지므로, AIStor 내부 필터를 통해 s3:ObjectCreated:* 와 s3:ObjectRemoved:* 이벤트만 골라서 Kafka 토픽으로 쏘도록 1차 매핑합니다.
  • 메시지 바디에 포함된 Records[].s3.object.size와 Records[].s3.object.key를 Kafka Consumer(Event Consumer)가 파싱하여 Redis 카운터를 플러그인 형태로 증감시킵니다.

4. 대규모 데이터 정합성 및 비용 정산 (가장 중요)

대상 요구사항: REQ-06-03 (정합성 보정 배치), 추가 기능 ⑤ (비용 배부)

수억 개의 파일이 쌓였을 때 정합성을 맞추기 위해 ListObjects API를 쓰면 AIStor 인프라 전체가 마비됩니다. 메타 DB와 스토리지를 초고속으로 싱크하는 매핑 방식입니다.

  • 매핑되는 AIStor 기능: MinIO Inventory API
  • 구현 및 매핑 방식:
  • 인벤토리 덤프 매핑: AIStor는 하루에 한 번 버킷 전체를 스캔하여 모든 객체의 메타데이터(Prefix, 크기, 수정일 등)를 Parquet 또는 CSV 파일로 생성해 특정 내부 버킷에 저장해 주는 Inventory 기능을 제공합니다.
  • 배치 프로세스 구현: 2차년도 정합성 보정 배치(REQ-06-03) 작동 시, API Server/배치 엔진은 AIStor가 떨구어 놓은 대용량 Parquet 파일을 읽어 들입니다. (DuckDB나 Spark 등의 임베디드 엔진을 활용하면 몇 분 만에 수억 건 분석 가능).
  • 이 인벤토리 데이터와 메타 DB(CNPG)의 테넌트별 테이블을 조인(Join)하여 오차를 단번에 보정하고, 이 데이터를 그대로 활용해 부서별 스토리지 사용 비용(Chargeback) 가산출 데이터로 매핑합니다.

5. 인프라 운영 및 자동화

대상 요구사항: REQ-01-01 (동적 Prefix 생성), 추가 기능 ③ (GitOps 프로비저닝)

  • 매핑되는 AIStor 기능: MinIO Admin Go SDK 및 MinIO Client (mc) CLI
  • 구현 및 매핑 방식:
  • S3 표준 API에는 'Prefix 생성'이라는 개념이 없고 객체가 올라가야 경로가 생깁니다. 따라서 REQ-01-01의 동적 생성을 만족하기 위해, API Server는 요청을 받으면 MinIO Admin SDK를 통해 해당 테넌트 이름의 .placeholder (또는 .keep) 가상 객체를 즉시 생성(PutObject)하여 폴더 구조를 시각화합니다.
  • GitOps 코드가 Push되면 API Server가 이 Admin SDK를 통해 테넌트용 서비스 어카운트(Service Account)를 동적으로 생성하고 Quota 모니터링 룰을 Redis에 인젝트(Inject)하도록 자동화 흐름을 매핑합니다.

요약: API Server의 개발 범위 최소화 전략

이 매핑 구조를 가져가면 개발 팀이 짜야 하는 코드 로직은 "사용자가 들어올 때 Redis에서 Quota 값 확인하고 Pre-signed URL 주기", 그리고 "Kafka에서 알림 받아 Redis/CNPG 숫자 올려주기" 두 가지 핵심 코어에만 집중할 수 있게 되어 1차년도 공수(M/M)를 크게 절감하면서도 분산 환경에서 완벽한 안정성을 확보할 수 있습니다.

profile
Young-Kyoo Kim
engineer
이전 포스트

26Y02d2c

다음 포스트

26Y02e1

0개의 댓글