핵심 개념

핵심 개념 (Core Concepts)

MinIO(현 AIStor)가 어떤 구조로 돌아가는지 먼저 잡고 가야, 분산 배포와 에라스처 코딩이 자연스럽게 이해돼요. 핵심은 여러 호스트를 하나의 객체 스토어로 묶는 서버 풀(server pool) 개념이에요. 이 페이지는 AIStor 배포의 기본 토폴로지와 클라이언트 연결 방식을 설명해 드릴게요.

출처: Core Concepts — MinIO AIStor Documentation

본문

프로덕션 AIStor 서버 배포는 균질한(homogeneous) 저장·컴퓨트 리소스를 가진 최소 8개 호스트로 구성돼요.

풀의 모든 호스트는 컴퓨트, 메모리, 네트워크, 저장 공간이 일치해요. AIStor는 이 풀을 클라이언트에게 단일 객체 스토어로 제시해요.

이 호스트들이 서버 풀(server pool) 을 구성하는데, AIStor 서버는 합산된 컴퓨트·메모리·저장 공간을 클라이언트에게 단일 리소스로 제시해요. 각 풀은 하나 이상의 에라스처 셋으로 구성돼요.

Kubernetes 배포에서 국지적 장애의 영향을 줄이려면 스프레드 존을 구성해서 AIStor가 파드를 랙이나 가용 영역 같은 별도의 장애 도메인에 분산시키게 하세요.

각 AIStor 서버는 분산 토폴로지의 전체 그림을 갖고 있어서, 애플리케이션은 배포의 어떤 노드에든 연결해 작업을 지시할 수 있어요.

애플리케이션은 보통 이런 연결을 직접 관리하면 안 돼요. 배포 토폴로지가 바뀌면 애플리케이션 업데이트가 필요해지기 때문이에요. 프로덕션 배포는 로드 밸런서나 유사한 네트워크 컨트롤 플레인 컴포넌트를 사용해 AIStor 서버 배포로 가는 연결을 관리해야 해요.

클라이언트 애플리케이션은 모든 S3 호환 SDK나 라이브러리를 사용해 AIStor 서버 배포와 상호작용할 수 있어요.

MinIO는 SDK를 Go, Python, Java, .NET 등으로 제공해요. 이들은 S3 API를 지원하고, Go·C++·Rust·Python SDK는 S3 over RDMA도 구현해요.

같은 배포가 S3 API 이상의 것에도 응답해요.

  • AIStor Tables는 객체 스토어 자체에서 Apache Iceberg REST 카탈로그를 서빙해요. 별도의 카탈로그 서비스나 메타데이터 DB가 필요 없어요.
  • S3 over RDMA는 객체를 RDMA 패브릭을 통해 GPU 메모리로 바로 읽어요. 페이로드가 커널 네트워크 스택을 통과하지 않아요.
  • FTP, FTPS, SFTP는 내보내기나 앞단 게이트웨이 없이 파일 클라이언트가 같은 버킷에 접근하게 해 줘요.

이 표면들과 이들을 둘러싼 제어가 트레이닝·추론 파이프라인에 어떻게 쓰이는지는 AI Workloads를 보세요. 클러스터가 데이터를 저장하고 스스로 복구하는 방식은 Erasure Coding과 Healing을 보세요.

서버 풀 확장(pool expansion)으로 AIStor 서버의 사용 가능한 저장 공간을 늘릴 수 있어요.

각 풀은 고유한 에라스처 셋을 가진 독립적인 노드 그룹으로 구성돼요. 새 풀 추가는 배포의 모든 노드를 새 토폴로지로 업데이트해야 해요. 멀티-풀 클러스터에서 수신 AIStor 서버 노드가 특정 요청을 어느 풀로 라우팅할지 결정해요.

풀 확장은 새 호스트명 레이아웃으로 로드 밸런서나 유사한 네트워크 컨트롤 플레인 컴포넌트를 업데이트해 노드 전체에 로드가 고르게 분산되게 해야 해요.

더 알아보기