메인 콘텐츠로 건너뛰기
이 가이드는 모든 W&B 배포 유형에 적용됩니다.
  • Multi-tenant Cloud: 팀 수준 BYOB
  • Dedicated Cloud: 인스턴스 및 팀 수준 BYOB
  • Self-Managed: 인스턴스 및 팀 수준 BYOB
이 가이드의 버킷 프로비저닝 지침은 배포 유형과 관계없이 동일합니다.

Overview

Bring your own bucket(BYOB)을 사용하면 W&B 아티팩트 및 기타 관련 민감한 데이터를 자체 클라우드나 온프레미스 인프라에 저장할 수 있습니다. Dedicated Cloud 또는 Multi-tenant Cloud의 경우, 사용자의 버킷에 저장된 데이터는 W&B 관리형 인프라로 복사되지 않습니다.
  • W&B SDK / CLI / UI와 사용자의 버킷 간 통신은 사전 서명된 URL을 통해 이루어집니다.
  • W&B는 시간이 지나면서 사용자의 버킷에서 삭제된 아티팩트run 데이터를 제거하기 위해 가비지 컬렉션 및 관련 프로세스를 사용합니다. 아티팩트 삭제는 아티팩트 삭제에서 다룹니다. Dedicated Cloud 및 Self-Managed deployment에서 삭제된 run 데이터는 환경 변수 구성에 설명된 GORILLA_DATA_RETENTION_PERIOD의 영향도 받습니다. 정리 시점은 보장되지 않습니다. 버킷 사용량 및 비용에 대한 전체 개요는 버킷 저장소 및 비용 관리를 참조하세요.
  • 버킷을 구성할 때 하위 경로를 지정하면 W&B가 버킷 루트 폴더에 파일을 저장하지 않도록 할 수 있습니다. 이렇게 하면 조직의 버킷 거버넌스 정책을 더 잘 준수하는 데 도움이 됩니다.

중앙 데이터베이스와 버킷에 저장되는 데이터

BYOB 기능을 사용하면 일부 데이터 유형은 W&B 중앙 데이터베이스에 저장되고, 다른 유형은 사용자의 버킷에 저장됩니다.

데이터베이스

  • Users, Teams, 아티팩트, 실험, 프로젝트의 메타데이터
  • Reports
  • 실험 로그
  • 시스템 메트릭
  • 콘솔 로그

버킷

  • 실험 파일 및 메트릭
  • Artifact 파일
  • 미디어 파일
  • run 파일
  • Parquet 형식으로 내보낸 이력 메트릭과 시스템 이벤트

버킷 범위

저장소 버킷에 구성할 수 있는 범위는 두 가지입니다.
범위설명
Instance levelDedicated CloudSelf-Managed에서는 조직 또는 인스턴스 내에서 필요한 권한을 가진 모든 사용자가 인스턴스의 저장소 버킷에 저장된 파일에 액세스할 수 있습니다. Multi-tenant Cloud에는 적용되지 않습니다.
Team levelW&B Team이 Team level 저장소 버킷을 사용하도록 구성된 경우, 팀 구성원은 해당 버킷에 저장된 파일에 액세스할 수 있습니다. Team level 저장소 버킷은 매우 민감한 데이터를 다루거나 엄격한 규정 준수 요구 사항이 있는 팀에 더 강력한 데이터 액세스 제어와 데이터 격리를 제공합니다.

Team level 저장소는 하나의 인스턴스를 공유하는 여러 사업부나 부서가 인프라와 관리 리소스를 효율적으로 활용하는 데 도움이 될 수 있습니다. 또한 서로 다른 프로젝트 팀이 개별 고객 업무를 위한 AI 워크플로를 관리할 수 있게 해줍니다. 모든 deployment 유형에서 사용할 수 있습니다. 팀을 설정할 때 Team level BYOB를 구성합니다.
이 유연한 설계를 통해 조직의 요구 사항에 따라 다양한 저장소 토폴로지를 구성할 수 있습니다. 예를 들면 다음과 같습니다.
  • 동일한 버킷을 인스턴스와 하나 이상의 팀에 사용할 수 있습니다.
  • 각 팀은 별도의 버킷을 사용할 수 있고, 일부 팀은 인스턴스 버킷에 쓰도록 선택할 수 있으며, 여러 팀이 하위 경로에 기록해 하나의 버킷을 공유할 수도 있습니다.
  • 서로 다른 팀의 버킷은 서로 다른 클라우드 인프라 환경이나 리전에 호스팅될 수 있으며, 서로 다른 저장소 관리자 팀이 관리할 수도 있습니다.
예를 들어, 조직에 Kappa라는 팀이 있다고 가정해 보겠습니다. 조직(및 Team Kappa)은 기본적으로 Instance level 저장소 버킷을 사용합니다. 다음으로 Omega라는 팀을 생성합니다. Team Omega를 생성할 때 해당 팀에 Team level 저장소 버킷을 구성합니다. Team Omega가 생성한 파일에는 Team Kappa가 액세스할 수 없습니다. 그러나 Team Kappa가 생성한 파일에는 Team Omega가 액세스할 수 있습니다. Team Kappa의 데이터를 격리하려면 해당 팀에도 Team level 저장소 버킷을 구성해야 합니다.

가용성 매트릭스

W&B는 다음 저장소 제공업체에 연결할 수 있습니다:
  • CoreWeave AI Object Storage: AI 워크로드에 최적화된 고성능 S3 호환 객체 저장소 서비스입니다.
  • Amazon S3: 업계 최고 수준의 확장성, 데이터 가용성, 보안, 성능을 제공하는 객체 저장소 서비스입니다.
  • Google Cloud Storage: 비정형 데이터를 대규모로 저장할 수 있는 관리형 서비스입니다.
  • Azure Blob Storage: 텍스트, 바이너리 데이터, 이미지, 비디오, 로그 등 대량의 비정형 데이터를 저장하기 위한 클라우드 기반 객체 저장소 솔루션입니다.
  • MinIO Enterprise (AIStor)와 같은 S3 호환 저장소 또는 클라우드나 온프레미스 인프라에서 호스팅되는 기타 엔터프라이즈급 솔루션.
다음 표는 각 W&B deployment type에서 각 범위별 BYOB 가용성을 보여줍니다.
W&B deployment typeInstance levelTeam levelAdditional information
Dedicated CloudInstance level 및 Team level BYOB는 클라우드나 온프레미스 인프라에서 호스팅되는 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage, 그리고 MinIO Enterprise (AIStor)와 같은 S3 호환 저장소에서 지원됩니다.
Multi-tenant Cloud해당 없음1Team level BYOB는 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage에서 지원됩니다.
Self-ManagedInstance level 및 Team level BYOB는 클라우드나 온프레미스 인프라에서 호스팅되는 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage, 그리고 MinIO Enterprise (AIStor)와 같은 S3 호환 저장소에서 지원됩니다.
1.Multi-tenant Cloud에서는 Team level BYOB에 Azure Blob Storage가 지원되지 않습니다. 다음 섹션에서는 BYOB 설정 방법을 안내합니다.

버킷 프로비저닝

가용성 확인을 마치면 액세스 정책과 CORS를 포함한 저장소 버킷을 프로비저닝할 수 있습니다. 계속하려면 탭을 선택하세요.
요구 사항:
  • Multi-tenant Cloud, 또는
  • Dedicated Cloud v0.73.0 이상 또는
  • Self-Managed v0.73.0 이상, Helm chart v0.33.14+로 배포된 경우
  • AI Object Storage가 활성화되어 있고 버킷, API 액세스 키, 시크릿 키를 생성할 권한이 있는 CoreWeave 계정.
  • W&B 인스턴스는 CoreWeave 네트워크 엔드포인트에 연결 가능해야 합니다.
자세한 내용은 CoreWeave 문서의 Create a CoreWeave AI Object Storage bucket을 참조하세요.
  1. Multi-tenant Cloud: 버킷 정책에 필요한 조직 ID를 획득하세요.
    1. W&B App에 로그인합니다.
    2. 왼쪽 내비게이션에서 새 팀 만들기를 클릭합니다.
    3. 열리는 드로어에서 팀 구성원 초대 위에 있는 W&B 조직 ID를 복사합니다.
    4. 이 페이지는 열린 상태로 둡니다. 나중에 W&B를 구성할 때 사용합니다.
  2. Dedicated Cloud / Self-Managed: 버킷 정책에 필요하므로 고객 네임스페이스를 획득하세요.
    1. W&B App에서 사용자 프로필 아이콘을 클릭한 후 System Console을 클릭합니다.
    2. Authentication 탭을 클릭합니다.
    3. 페이지 하단에서 Customer Namespace 값을 복사합니다. 이 값은 버킷 정책을 구성할 때 필요하므로 보관해 두세요.
    4. System Console을 닫아도 됩니다.
  3. CoreWeave에서 원하는 CoreWeave 가용 영역에 원하는 이름으로 버킷을 생성합니다. 필요에 따라 모든 W&B 파일의 하위 경로로 사용할 폴더를 W&B용으로 생성할 수 있습니다. 버킷 이름, 가용 영역, API 액세스 키, 시크릿 키, 하위 경로를 기록해 둡니다.
  4. 버킷에 다음 CORS(Cross-Origin Resource Sharing) 정책을 설정합니다:
    [
      {
        "AllowedHeaders": [
          "*"
        ],
        "AllowedMethods": [
          "GET",
          "HEAD",
          "PUT"
        ],
        "AllowedOrigins": [
          "*"
        ],
        "ExposeHeaders": [
          "ETag"
        ],
        "MaxAgeSeconds": 3000
      }
    ]
    
    CoreWeave 저장소는 S3 호환입니다. CORS에 대한 자세한 내용은 AWS 문서의 교차 출처 리소스 공유(CORS) 구성을 참고하세요.
  5. W&B 배포 환경이 버킷에 액세스하고, 클라우드 인프라의 AI 워크로드 또는 사용자 브라우저가 버킷에 액세스하는 데 사용하는 사전 서명된 URL을 생성하는 데 필요한 권한을 부여하는 버킷 정책을 구성하세요. 자세한 내용은 CoreWeave 문서의 Bucket Policy Reference를 참고하세요.
    {
      "Version": "2012-10-17",
      "Statement": [
      {
        "Sid": "AllowWandbUser",
        "Action": [
          "s3:GetObject*",
          "s3:GetEncryptionConfiguration",
          "s3:ListBucket",
          "s3:ListBucketMultipartUploads",
          "s3:ListBucketVersions",
          "s3:AbortMultipartUpload",
          "s3:DeleteObject",
          "s3:PutObject",
          "s3:GetBucketCORS",
          "s3:GetBucketLocation",
          "s3:GetBucketVersioning"
        ],
        "Effect": "Allow",
        "Resource": [
          "arn:aws:s3:::<cw-bucket>/*",
          "arn:aws:s3:::<cw-bucket>"
        ],
        "Principal": {
          "CW": "arn:aws:iam::wandb:static/<wb-cw-principal>"
        },
        "Condition": {
          "StringLike": {
            "wandb:OrgID": [
              "<wb-org-id>"
            ]
          }
        }
      },
      {
        "Sid": "AllowUsersInOrg",
        "Action": "s3:*",
        "Effect": "Allow",
        "Resource": [
          "arn:aws:s3:::<cw-bucket>",
          "arn:aws:s3:::<cw-bucket>/*"
        ],
        "Principal": {
          "CW": "arn:aws:iam::<cw-storage-org-id>:*"
        }
      }]
    }
    
    "Sid": "AllowUsersInOrg"로 시작하는 절은 조직의 사용자에게 버킷에 직접 액세스할 수 있는 권한을 부여합니다. 이 권한이 필요하지 않다면 정책에서 해당 절을 생략할 수 있습니다.
  6. 버킷 정책에서 플레이스홀더를 바꾸세요:
    • <cw-bucket>: 버킷 이름입니다.
    • <cw-wandb-principal>:
      • Multi-tenant Cloud: arn:aws:iam::wandb:static/wandb-integration-public
      • Dedicated Cloud 또는 Self-Managed: arn:aws:iam::wandb:static/wandb-integration
    • <wb-org-id>:
  7. Dedicated Cloud: 추가 step을 마치려면 지원팀에 문의하세요.
  8. Self-Managed: W&B 배포를 업데이트하여 환경 변수 GORILLA_SUPPORTED_FILE_STORES를 정확히 cw://로 설정한 후 W&B를 다시 시작하세요. 그렇지 않으면 팀 저장소를 설정할 때 CoreWeave가 옵션으로 표시되지 않습니다.
다음으로, W&B를 설정합니다.
다음으로 저장소 주소를 확인하세요.

저장소 주소 확인

이 섹션에서는 W&B Team을 BYOB 저장소 버킷에 연결할 때 사용하는 구문을 설명합니다. 예시에서는 꺾쇠괄호(<>) 안의 자리 표시자 값을 버킷 세부 정보로 바꾸세요. 자세한 지침은 탭을 선택해 확인하세요.
이 섹션은 Dedicated Cloud 또는 Self-Managed의 team level BYOB에만 해당합니다. instance level BYOB 또는 Multi-tenant Cloud의 경우 W&B 구성으로 바로 진행하면 됩니다.다음 형식에 따라 전체 버킷 경로를 확인합니다. 꺾쇠괄호(<>) 안의 자리 표시자를 버킷 값으로 바꾸세요.Bucket 형식:
cw://<accessKey>:<secretAccessKey>@cwobject.com/<bucketName>?tls=true
cwobject.com HTTPS 엔드포인트를 지원합니다. TLS 1.3이 필요합니다. 다른 CoreWeave 엔드포인트에 관심이 있다면 지원팀에 문의하세요.
저장소 주소를 확인했다면 이제 team level BYOB 구성으로 진행할 수 있습니다.

W&B 설정

버킷을 프로비저닝하고 스토리지 주소를 확인한 후에는 인스턴스 수준 또는 팀 수준에서 BYOB를 설정할 수 있습니다.
저장소 버킷 레이아웃은 신중하게 계획하세요. W&B에서 저장소 버킷을 설정한 후에는 해당 데이터를 다른 버킷으로 마이그레이션하는 작업이 복잡하며 W&B의 도움이 필요합니다. 이는 Dedicated Cloud 및 Self-Managed의 저장소뿐 아니라 Multi-tenant Cloud의 팀 수준 저장소에도 적용됩니다. 문의 사항이 있으면 지원팀에 문의하세요.

인스턴스 수준 BYOB

인스턴스 수준 CoreWeave AI Object Storage의 경우, 이 안내를 따르지 말고 W&B 지원팀에 문의하세요. 셀프서비스 설정은 아직 지원되지 않습니다.
Dedicated Cloud의 경우: 버킷 세부 정보를 담당 W&B 팀에 공유하면 담당 팀에서 Dedicated Cloud 인스턴스를 설정합니다. Self-Managed의 경우, W&B App을 사용해 인스턴스 수준 BYOB를 설정할 수 있습니다:
  1. admin 역할이 있는 사용자로 W&B에 로그인합니다.
  2. 상단의 사용자 아이콘을 클릭한 다음 System Console을 클릭합니다.
  3. Settings > System Connections로 이동합니다.
  4. Bucket Storage 섹션에서 Identity 필드의 ID에 새 버킷에 대한 액세스 권한이 부여되어 있는지 확인합니다.
  5. Provider를 선택합니다.
  6. Bucket Name을 입력합니다.
  7. 필요에 따라 새 버킷에서 사용할 Path를 입력합니다.
  8. Save를 클릭합니다.

Team level BYOB

W&B App에서 팀을 만들 때 또는 SCIM API(선택적 storageBucket이 포함된 POST Groups)를 사용할 때 Team level BYOB를 설정할 수 있습니다. 옵션은 두 가지입니다.
  • 기존 버킷 사용: 먼저 버킷의 저장소 위치를 확인해야 합니다.
  • 새 버킷 생성(Multi-tenant Cloud 전용): 팀을 만들 때 W&B가 클라우드 제공업체에 버킷을 자동으로 생성할 수 있습니다. 이 옵션은 CoreWeave, AWS, Google Cloud에서 지원됩니다.
  • 팀이 생성된 후에는 저장소를 변경할 수 없습니다.
  • Instance level BYOB는 Instance level BYOB를 참고하세요.
  • 팀에 CoreWeave 저장소를 설정할 계획이라면 CoreWeave requirements를 검토하고, 지원팀에 문의해 CoreWeave에서 버킷이 올바르게 설정되었는지와 팀 설정이 유효한지를 확인하세요. 팀이 생성된 후에는 저장소 세부 정보를 변경할 수 없습니다.
계속하려면 배포 유형을 선택하세요.
  1. Dedicated Cloud: 팀에서 저장소 버킷을 사용하려면, 아래 나머지 단계를 진행하기 전에 버킷 경로를 담당 account team에 반드시 제공하여 인스턴스의 지원 파일 저장소에 추가하도록 해야 합니다.
  2. Self-Managed: 팀에서 저장소 버킷을 사용하려면, 아래 나머지 단계를 진행하기 전에 버킷 경로를 GORILLA_SUPPORTED_FILE_STORES 환경 변수에 반드시 추가한 다음 W&B를 재시작해야 합니다.
  3. admin 역할이 있는 사용자로 W&B에 로그인한 다음, 왼쪽 상단의 아이콘을 클릭해 왼쪽 내비게이션을 열고 협업할 팀 만들기를 클릭합니다.
  4. 팀 이름을 입력합니다.
  5. Storage TypeExternal storage로 설정합니다.
    팀 저장소로 인스턴스 수준 저장소를 사용하려면(내부/외부 여부와 관계없이), 인스턴스 수준 버킷이 BYOB로 설정되어 있더라도 Storage TypeInternal로 그대로 두세요. 팀에 별도의 외부 저장소를 사용하려면 팀의 Storage TypeExternal로 설정하고 다음 단계에서 버킷 세부 정보를 구성하세요.
  6. Bucket location을 클릭합니다.
  7. 기존 버킷을 사용하려면 목록에서 선택합니다. 새 버킷을 추가하려면 하단의 Add bucket을 클릭한 다음 버킷 세부 정보를 입력합니다. Cloud provider를 클릭하고 CoreWeave, AWS, Google Cloud, 또는 Azure를 선택합니다. 클라우드 제공업체가 목록에 없으면 Provision your bucket의 안내에 따라 인스턴스의 지원 파일 저장소에 버킷 경로를 추가했는지 확인하세요. 저장소 제공업체가 여전히 표시되지 않으면 지원팀에 문의하세요.
  8. 버킷 세부 정보를 지정합니다.
    • CoreWeave의 경우 버킷 이름만 입력합니다.
    • Amazon S3, Google Cloud 또는 S3 호환 저장소의 경우 앞서 확인한 전체 버킷 경로를 입력합니다.
    • W&B Dedicated 또는 Self-Managed의 Azure에서는 Account name을 Azure 계정으로, Container name을 Azure blob storage 컨테이너로 설정합니다.
    • 필요에 따라 추가 연결 설정을 입력합니다.
      • 해당하는 경우 Path를 버킷 하위 경로로 설정합니다.
      • CoreWeave: 추가 연결 설정이 필요하지 않습니다.
      • AWS: KMS key ARN을 KMS 암호화 키의 ARN으로 설정합니다.
      • Google Cloud: 추가 연결 설정이 필요하지 않습니다.
      • Azure: Tenant IDManaged Identity Client ID 값을 지정합니다. GORILLA_SUPPORTED_FILE_STORES로 연결 문자열을 구성하지 않았다면 이 필드는 필수입니다.
  9. Create team을 클릭합니다.
W&B가 버킷에 액세스하는 중 오류가 발생하거나 잘못된 설정을 감지하면 페이지 하단에 오류 또는 경고가 표시됩니다. 그렇지 않으면 팀이 생성됩니다.

문제 해결

CoreWeave

이 섹션에서는 CoreWeave AI Object Storage 연결 시 발생하는 문제를 해결하는 방법을 안내합니다.
  • 연결 오류
    • W&B 인스턴스가 CoreWeave 네트워크 엔드포인트에 연결할 수 있는지 확인합니다.
    • CoreWeave는 가상 호스팅 스타일 경로를 사용하며, 이때 버킷 이름은 경로 시작 부분의 서브도메인입니다. 예를 들어 cw://bucket-name.cwobject.com은 올바르지만, cw://cwobject.com/bucket-name/은 올바르지 않습니다.
    • 버킷 이름에는 밑줄(_)이나 DNS 규칙과 호환되지 않는 다른 문자가 포함되어서는 안 됩니다.
    • 버킷 이름은 CoreWeave의 모든 위치에서 전역적으로 고유해야 합니다.
    • 버킷 이름은 예약된 접두사인 cw- 또는 vip-로 시작해서는 안 됩니다.
  • CORS 검증 실패
    • CORS 정책이 필요합니다. CoreWeave는 S3 호환 스토리지이므로, CORS에 대한 자세한 내용은 AWS 문서의 Configuring cross-origin resource sharing (CORS)를 참조하세요.
    • AllowedMethods에는 GET, PUT, HEAD 메서드가 포함되어야 합니다.
    • ExposeHeaders에는 ETag가 포함되어야 합니다.
    • W&B 프런트엔드 도메인이 CORS 정책의 AllowedOrigins에 포함되어야 합니다. 이 페이지에 제공된 예시 CORS 정책은 *를 사용해 모든 도메인을 포함합니다.
  • LOTA 엔드포인트 문제
  • 액세스 키 및 권한 오류
    • CoreWeave API Access Key가 만료되지 않았는지 확인합니다.
    • CoreWeave API Access Key와 Secret Key에 GetObject, PutObject, DeleteObject, ListBucket 권한이 충분히 있는지 확인합니다. 이 페이지의 예시는 이 요구 사항을 충족합니다. 자세한 내용은 CoreWeave 문서의 Create and Manage Access Keys를 참고하세요.

Google Cloud

이 섹션은 Google Cloud Storage 연결 문제를 해결하는 데 도움이 됩니다.
  • Bucket does not have soft deletion enabled Google Cloud Storage 버킷에서 소프트 삭제가 활성화되어 있는지 확인하세요. 버킷의 소프트 삭제 정책 수정을 참조하세요.