다중 스토리지 백엔드(Multiple Storage Backends)

원문 보기 위키 갱신 2026.10.11

lakeFS Team 및 lakeFS Enterprise에서 제공되는 기능이에요. 무료 체험을 시작하거나 문의하기를 통해 연락해 보세요.

출처: 문서

본문

다중 스토리지 백엔드 지원이란?

lakeFS의 다중 스토리지 백엔드 지원은 온프레미스, 퍼블릭 클라우드 간, 하이브리드 환경을 아우르는 여러 스토리지 시스템을 매끄럽게 관리할 수 있게 해 줘요. 이 기능 덕분에 lakeFS가 모든 조직 데이터 자산을 위한 통합 데이터 관리 플랫폼이 되죠. 여러 위치에 흩어진 다양한 데이터셋에 의존하는 AI/ML 환경에서 특히 중요해요.

멀티 스토어 구성으로 lakeFS는 다음을 포함한 지원되는 스토리지 시스템의 어떤 조합이든 연결하고 관리할 수 있어요:

AWS S3
Azure Blob
Google Cloud Storage
기타 S3 호환 스토리지
로컬 스토리지

Note

멀티 스토리지 백엔드 지원은 lakeFS Enterprise 1.51.0 버전부터 제공돼요.

사용 사례

분산 데이터 관리:
데이터 사일로를 없애고 클라우드를 넘나드는 매끄러운 협업을 가능하게 해요.
서로 다른 스토리지 제공자에 걸쳐 일관성과 재현성을 위해 버전 관리를 유지해요.
데이터셋이 여러 스토리지 위치에 분산된 AI/ML 환경에 이상적이에요.
통합 데이터 접근:
단일하고 일관된 URI 형식으로 여러 스토리지 백엔드에 걸친 데이터에 접근해요.
중앙화된 접근 제어와 거버넌스:
접근 권한과 정책은 lakeFS RBAC로 연결된 모든 스토리지 시스템에 걸쳐 중앙 관리할 수 있어요.
데이터가 어디에 저장되었든 컴플라이언스와 보안 통제는 일관되게 유지돼요.

구성

lakeFS 서버가 여러 스토리지 백엔드에 연결하도록 구성하려면 서버 설정의 blockstores 섹션 아래에 정의하세요. blockstores.stores 필드는 스토리지 백엔드 배열이며 각각 자신만의 구성을 가져요.

사용 가능한 옵션의 전체 목록은 서버 설정 레퍼런스를 참고하세요.

Note

단일 스토어 lakeFS 구성에서 업그레이드한다면 원활한 전환을 위해 업그레이드 가이드라인을 참고하세요.

구성 예시

On-PremMulti-CloudHybrid

이 예제 구성은 lakeFS가 두 개의 별도 MinIO 인스턴스에 걸친 데이터를 관리하게 해요:

예시

blockstores:
  signing:
    secret_key: "some-secret"
  stores:
    - id: "minio-prod"
      description: "Primary on-prem MinIO storage for production data"
      type: "s3"
      s3:
        force_path_style: true
        endpoint: 'http://minio-prod.local'
        discover_bucket_region: false
        credentials:
          access_key_id: "prod_access_key"
          secret_access_key: "prod_secret_key"
    - id: "minio-backup"
      description: "Backup MinIO storage for disaster recovery"
      type: "s3"
      s3:
        force_path_style: true
        endpoint: 'http://minio-backup.local'
        discover_bucket_region: false
        credentials:
          access_key_id: "backup_access_key"
          secret_access_key: "backup_secret_key"

이 예제 구성은 lakeFS가 AWS와 Azure라는 두 퍼블릭 클라우드 제공자에 걸친 데이터를 관리하게 해요:

예시

blockstores:
  signing:
    secret_key: "some-secret"
  stores:
    - id: "s3-prod"
      description: "AWS S3 storage for production data"
      type: "s3"
      s3:
        region: "us-east-1"
    - id: "azure-analytics"
      description: "Azure Blob storage for analytics data"
      type: "azure"
      azure:
        storage_account: "analytics-account"
        storage_access_key: "EXAMPLE45551FSAsVVCXCF"

이 하이브리드 구성은 lakeFS가 클라우드와 온프레미스 스토리지에 걸친 데이터를 관리하게 해요.

예시

blockstores:
  signing:
    secret_key: "some-secret"
  stores:
    - id: "s3-archive"
      description: "AWS S3 storage for long-term archival"
      type: "s3"
      s3:
        region: "us-west-2"
    - id: "minio-fast-access"
      description: "On-prem MinIO for high-performance workloads"
      type: "s3"
      s3:
        force_path_style: true
        endpoint: 'http://minio.local'
        discover_bucket_region: false
        credentials:
          access_key_id: "minio_access_key"
          secret_access_key: "minio_secret_key"

주요 고려 사항

고유한 블록스토어 ID: 각 스토리지에는 고유한 id가 필요해요.
블록스토어 ID의 영속성: 한번 정의된 id는 바뀌면 안 돼요.
S3 인증 처리:
모든 표준 S3 인증 방식이 지원돼요.
모든 블록스토어는 인증되어야 해요. s3 유형의 모든 스토리지에 프로파일이나 정적 자격 증명을 구성했는지 확인하세요. S3 스토리지는 기본적으로 자격 증명 체인을 사용하므로 한 스토리지에는 그걸 쓸 수 있을 거예요.

Warning

스토리지 ID 변경은 지원되지 않으며 예기치 않은 동작을 일으킬 수 있어요. 구성 후에는 ID를 일관되게 유지하세요.

단일 스토리지 백엔드에서 다중 스토리지 백엔드로 업그레이드

단일 스토리지 백엔드에서 멀티 스토리지 구성으로 업그레이드할 때는 다음 가이드라인을 따르세요:

새 blockstores 구조를 사용해 기존 blockstore 구성을 대체하세요. blockstore와 blockstores 구성은 상호 배타적이라서 lakeFS는 둘을 동시에 지원하지 않아요.
이전에 사용 가능했던 모든 단일 블록스토어 설정을 해당 스토리지 백엔드 아래에 정의하세요.
signing.secret_key는 연결된 모든 스토어에 전역으로 필요한 설정이에요.
기존 스토리지 백엔드에 backward_compatible: true를 설정해 다음을 보장하세요:
기존 리포지토리가 원래 스토리지 백엔드를 계속 사용해요.
명시적으로 다른 백엔드를 지정하지 않는 한 새로 만들어지는 리포지토리는 이 백엔드를 기본으로 사용해요. 파괴 없는 업그레이드를 위해서예요.
이 설정은 필수예요 — 설정되지 않으면 lakeFS가 동작하지 않아요.
업그레이드 전에 만들어진 리포지토리를 지원해야 하는 동안에는 이 설정을 제거하지 마세요. 제거하면 lakeFS가 기존 리포지토리를 어떤 구성된 스토리지와도 연결되지 않은 것으로 간주해 시작에 실패해요.

스토리지 백엔드 추가 또는 제거

스토리지 백엔드를 추가하려면 서버 설정에 새 스토리지 항목을 넣고 서버를 재시작하세요.

스토리지 백엔드를 제거하려면:

그 스토리지 백엔드와 연관된 모든 리포지토리를 삭제하세요. (정의만 삭제)
설정에서 스토리지 항목을 제거하세요.
서버를 재시작하세요.

Warning

제거된 스토리지에 정의된 리포지토리가 남아 있으면 lakeFS가 시작에 실패해요. 스토리지 백엔드를 제거하기 전에 필요한 정리를 모두 마치세요.

연결된 스토리지 백엔드 나열

Get Config API 엔드포인트가 스토리지 구성 목록을 반환해요. 멀티 스토리지 구성에서는 이것이 연결된 스토리지 백엔드를 나열하고 세부 사항을 확인하는 권장 방법이에요.

트러블슈팅

Issue	Cause	Solution
블록스토어 ID 충돌	stores에 중복된 id 값	각 스토리지 백엔드에 고유한 ID를 부여하세요
backward_compatible 누락	플래그를 설정하지 않은 채 단일→멀티 스토리지 업그레이드	기존 스토리지에 backward_compatible: true를 추가하세요
lakeFS Community 또는 미라이선스 Enterprise 계정에서 지원되지 않는 구성	지원되지 않는 구성에서 멀티 스토리지 기능 사용	기능 사용을 시작하려면 문의하세요

다중 스토리지 백엔드에서 단일 스토리지 백엔드로 마이그레이션

멀티 스토리지 구성으로 업그레이드한 뒤에는 blockstores를 blockstore로 바꾼다고 단순히 되돌릴 수 없어요. 내부 리포지토리 메타데이터 형식이 멀티 스토리지 백엔드를 지원하도록 바뀌었고, 단일 스토리지 형식과 하위 호환되지 않아요. 데이터를 통합해 멀티 스토리지 구성에서 단일 스토리지 백엔드로 되돌려야 한다면 다음 단계에 따라 전체 마이그레이션을 수행해야 해요:

개요

마이그레이션 프로세스는 다음을 포함해요:

멀티 스토리지 구성에서 리포지토리 레퍼런스를 덤프
멀티 스토리지 환경에서 리포지토리 삭제
단일 스토리지 백엔드로 lakeFS 구성
(선택) 리포지토리 데이터를 새 단일 스토리지 위치로 복사
단일 스토리지 환경으로 리포지토리 복원

단계별 가이드

lakefs-refs.py 스크립트를 사용하세요. 구하는 방법은 Backup and Restore 문서에 나와 있어요.

리포지토리 레퍼런스 덤프 리포지토리 메타데이터를 덤프하려면:

# Dump a single repository
python lakefs-refs.py dump my-repository

# Or dump all repositories
python lakefs-refs.py dump --all

이렇게 하면 리포지토리마다 매니페스트 파일이 만들어져요. 선택적으로 --rm 플래그로 성공적인 덤프 후 리포지토리를 자동 삭제할 수 있어요:

# Dump and delete a single repository
python lakefs-refs.py dump my-repository --rm

# Or dump and delete all repositories
python lakefs-refs.py dump --all --rm

소스 리포지토리 삭제 (--rm 플래그를 쓰지 않은 경우) 1단계에서 --rm 플래그를 쓰지 않았다면 리포지토리를 수동 삭제해야 해요. 리포지토리 삭제는 lakeFS에서 리포지토리 레코드만 제거할 뿐 실제 데이터 파일이나 메타데이터는 스토리지에서 지우지 않아요. 리포지토리는 다음으로 삭제할 수 있어요: a. lakeFS UI b. lakectl 사용 (예: lakectl repo delete lakefs://my-repository)
lakeFS 단일 스토리지 구성
lakeFS 구성을 단일 스토리지 백엔드를 사용하도록 업데이트하세요 (blockstores 대신 blockstore 섹션 사용).
새 구성 적용 후 lakeFS를 시작하거나 재시작하세요

단일 스토리지 백엔드 구성 예시

...
blockstore:
  type: s3
  s3:
    region: us-east-1
...

리포지토리 데이터 복사 (필요한 경우) 복원하려는 리포지토리가 lakeFS가 더 이상 연결되지 않은 스토리지 시스템 위에서 만들어졌다면: a. 오래된 스토리지 위치에서 새 위치로 데이터를 복사하세요:

# Example for S3
aws s3 sync s3://old-bucket/path/to/storge-namespace s3://new-bucket/path/to/storage-namespace

# Alternative: Using rclone for cross-provider transfers
# rclone supports various storage providers (S3, Azure, GCS, etc.)
rclone sync azure:old-container/path/to/storage-namespace aws:new-bucket/path/to/storage-namespace

b. 1단계(리포지토리 레퍼런스 덤프)에서 만든 매니페스트 파일을 새 스토리지 네임스페이스로 업데이트하세요:

{
    "repository": {
        "name": "my-repository",
        "storage_namespace": "s3://new-bucket/path/to/repo", // ... update here ...
        "default_branch": "main",
        "storage_id": "storage-1"
    },
    "refs": {
        // ... existing refs data ...
    }
}

리포지토리 복원 !!! note 4단계에서 데이터를 새 위치로 복사했다면 복원 전에 매니페스트 파일의 스토리지 네임스페이스를 업데이트했는지 확인하세요. 단일 스토리지 환경에서 리포지토리가 storage ID 없이 만들어지도록 --ignore-storage-id 플래그를 사용하세요:

# Restore a single repository
python lakefs-refs.py restore my-repository_manifest.json --ignore-storage-id

# Or restore multiple repositories
python lakefs-refs.py restore repo1_manifest.json repo2_manifest.json --ignore-storage-id

중요 참고 사항

매니페스트 파일에는 리포지토리 메타데이터가 담겨 있으니 안전하게 보관하세요
다른 스토리지 백엔드를 사용한다면 데이터 복사에 적절한 접근 권한이 있는지 확인하세요
덤프 전 모든 변경이 커밋되도록 하려면 --commit 플래그를 쓸 수 있어요
새 스토리지 백엔드에 모든 리포지토리 데이터를 담을 충분한 공간이 있는지 확인하세요
단일 스토리지 유형으로 구성된 lakeFS 인스턴스는 멀티 스토리지 구성에서 만들어진 리포지토리가 남아 있으면 시작하지 않아요

리포지토리 작업하기

lakeFS Enterprise가 여러 스토리지 백엔드에 연결되도록 구성했다면, 이 섹션은 lakeFS 작업 시 이 연결된 스토리지들을 사용하는 방법을 설명해요.

여러 스토리지 백엔드가 구성되면 lakeFS 리포지토리는 특정 스토리지에 연결돼요. 리포지토리의 스토리지 네임스페이스와 함께, 이것이 리포지토리 데이터가 저장되는 기반 스토리지의 정확한 위치를 정의해요.

스토리지 백엔드의 선택은 다음 lakeFS 연산에 영향을 줘요:

리포지토리 만들기

멀티 스토리지 구성에서는 리포지토리를 만들 때 스토리지 ID를 지정해야 해요. 다음 방법으로 할 수 있어요:

UICLIAPIHigh-Level Python SDK

드롭다운 메뉴에서 스토리지 백엔드를 선택하세요.

repo create 명령에 --storage-id 플래그를 사용하세요:

lakectl repo create lakefs://my-repo s3://my-bucket --storage-id my-storage

Note

--storage-id 플래그는 현재 CLI에서 숨겨져 있어요.

Create Repository 엔드포인트의 storage_id 파라미터를 사용하세요.

High-level Python SDK 0.9.0 버전부터 kwargs로 create repository 메서드를 호출할 때 storage_id를 동적으로 전달할 수 있어요:

import lakefs

repo = lakefs.Repository("example-repo").create(
    storage_namespace="s3://storage-bucket/repos/example-repo",
    storage_id="my-storage-id"
)

중요 참고 사항

*스토리지 백엔드가 backward_compatible: true로 표시된 멀티 스토리지 구성에서는 스토리지 ID 없는 리포지토리 생성 요청이 이 스토리지를 기본으로 사용해요.

backward_compatible로 표시된 스토리지 백엔드가 없다면 스토리지 ID 없는 리포지토리 생성 요청은 실패해요.
각 리포지토리는 단일 백엔드에 연결되며 그 백엔드의 단일 스토리지 네임스페이스 안에 데이터를 저장해요.

리포지토리 세부 사항 보기

리포지토리에 어떤 스토리지 백엔드가 연결되어 있는지 확인하려면:

UIAPI

스토리지 ID는 리포지토리 설정 페이지의 "Storage" 아래에 표시돼요.

List Repositories 엔드포인트를 사용하세요. 응답에 스토리지 ID가 포함돼요.

리포지토리에 데이터 임포트

리포지토리의 블록스토어 자격 증명이 스토리지 위치에 대한 읽기·나열 접근을 허용하면 리포지토리에 데이터 임포트가 지원돼요.

제한 사항

지원되는 스토리지

멀티 스토리지 백엔드 지원은 다음에서 검증되었어요:

셀프 매니지드 S3 호환 객체 스토리지 (MinIO)
Amazon S3
로컬 스토리지

Warning

다른 스토리지 백엔드도 동작할 수 있지만 공식 테스트되지 않았어요. 추가 구성을 탐색하고 싶다면 문의해 주세요.

지원되지 않는 클라이언트

다음 클라이언트는 현재 여러 스토리지 백엔드와의 작업을 지원하지 않아요. 다만 이 격차를 해소하기 위해 활발히 작업 중이에요:

Spark 기반 GC
Spark 클라이언트
lakeFS Hadoop FileSystem

더 알아보기 (Learn more)

공식 문서의 다중 스토리지 백엔드 페이지는 https://docs.lakefs.io/admin/multiple-storage-backends 에서 확인할 수 있어요.