Bring your own bucket (BYOB)

이 가이드는 모든 W&B 배포 유형에 적용됩니다.

Multi-tenant Cloud: 팀 수준 BYOB
Dedicated Cloud: 인스턴스 수준 및 팀 수준 BYOB
Self-Managed: 인스턴스 수준 및 팀 수준 BYOB

이 가이드의 버킷 프로비저닝 절차는 배포 유형과 관계없이 동일합니다.

이 페이지는 W&B Platform의 Secure Storage Connector 또는 BYOB에 관한 내용이며 Weave에는 적용되지 않습니다. 자체 클라우드 버킷에 저장된 이미지와 비디오를 Weave로 바이트를 임포트하지 않고 Weave에서 렌더링하려면 Weave BYOB 레퍼런스를 참조하세요.

개요

Bring your own bucket(BYOB)을 사용하면 W&B 아티팩트와 기타 민감한 데이터를 자체 클라우드 또는 온프레미스 인프라에 저장할 수 있습니다. Dedicated Cloud 또는 Multi-tenant Cloud에서는 버킷에 저장한 데이터를 W&B가 W&B 관리형 인프라로 복사하지 않습니다. 이 페이지는 데이터 거버넌스, 데이터 상주 또는 규정 준수 요구 사항을 충족하기 위해 아티팩트 저장소의 소유권을 직접 유지해야 하는 W&B 관리자와 플랫폼 엔지니어를 위한 문서입니다.

W&B SDK / CLI / UI와 버킷 간의 통신에는 사전 서명된 URL이 사용됩니다.
W&B는 가비지 컬렉션 및 관련 프로세스를 통해 삭제된 아티팩트와 run 데이터를 버킷에서 점진적으로 제거합니다. 아티팩트 삭제에 대한 자세한 내용은 아티팩트 삭제를 참조하세요. Dedicated Cloud 및 Self-Managed 배포에서는 삭제된 run 데이터의 제거가 환경 변수 설정에 설명된 GORILLA_DATA_RETENTION_PERIOD 값의 영향도 받습니다. W&B는 정리 시점을 보장하지 않습니다. 버킷 사용량과 비용을 한눈에 파악하려면 버킷 저장소 및 비용 관리를 참조하세요.
버킷을 설정할 때 하위 경로를 지정하면 W&B가 버킷 루트의 폴더에 파일을 저장하지 않도록 할 수 있습니다. 이렇게 하면 조직의 버킷 거버넌스 정책을 더 잘 준수할 수 있습니다.

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

BYOB 기능을 사용하면 W&B는 일부 유형의 데이터를 W&B 중앙 데이터베이스에 저장하고, 나머지 유형의 데이터는 사용자의 버킷에 저장합니다. 다음 목록을 참고하여 W&B가 관리하는 인프라에 보관되는 데이터와 W&B가 사용자 소유의 저장소에 기록하는 데이터를 확인하세요.

데이터베이스

W&B 중앙 데이터베이스에는 다음 데이터가 저장됩니다.

사용자, 팀, 아티팩트, 실험, 프로젝트의 메타데이터
Reports
실험 로그
시스템 메트릭
콘솔 로그

버킷

저장소 버킷은 다음 데이터를 저장합니다:

실험 파일 및 메트릭.
아티팩트 파일.
미디어 파일.
run 파일.
Parquet 형식으로 내보낸 이력 메트릭 및 시스템 이벤트.

버킷 범위

저장소 버킷을 다음 두 가지 범위 중 하나로 설정할 수 있습니다.

범위	설명
인스턴스 수준	Dedicated Cloud 및 Self-Managed에서는 조직 또는 인스턴스 내에서 필요한 권한을 가진 모든 사용자가 인스턴스의 저장소 버킷에 저장된 파일에 액세스할 수 있습니다. Multi-tenant Cloud에는 적용되지 않습니다.
팀 수준	W&B 팀이 팀 수준 저장소 버킷을 사용하도록 설정하면, 팀 구성원은 해당 버킷에 저장된 파일에 액세스할 수 있습니다. 팀 수준 저장소 버킷은 민감한 데이터나 엄격한 규정 준수 요구 사항이 있는 팀을 위해 더 강력한 데이터 액세스 제어 및 데이터 격리를 제공합니다. 팀 수준 저장소는 인스턴스를 공유하는 다양한 비즈니스 단위나 부서가 인프라 및 관리 리소스를 효율적으로 사용할 수 있도록 지원합니다. 또한 별도의 프로젝트 팀이 개별 고객 프로젝트를 위한 AI 워크플로를 관리할 수 있게 해줍니다. 모든 배포 유형에서 사용할 수 있습니다. 팀을 설정할 때 팀 수준 BYOB를 설정합니다.

이 설계는 조직의 요구 사항에 따라 다양한 저장소 토폴로지를 지원합니다. 예를 들면 다음과 같습니다.

동일한 버킷이 인스턴스와 하나 이상의 팀을 서빙할 수 있습니다.
각 팀은 별도의 버킷을 사용할 수 있고, 일부 팀은 인스턴스 버킷에 쓰기를 선택할 수 있으며, 여러 팀이 하위 경로에 기록하여 버킷을 공유할 수도 있습니다.
서로 다른 팀의 버킷은 서로 다른 클라우드 인프라 환경이나 리전에 상주할 수 있으며, 서로 다른 저장소 관리 팀이 이를 관리할 수 있습니다.

예를 들어, 조직에 Kappa라는 팀이 있다고 가정해 보겠습니다. 조직(및 Kappa 팀)은 기본적으로 인스턴스 수준 저장소 버킷을 사용합니다. 다음으로 Omega라는 팀을 생성합니다. Omega 팀을 생성할 때 해당 팀을 위한 팀 수준 저장소 버킷을 설정합니다. Kappa 팀은 Omega 팀이 생성한 파일에 액세스할 수 없습니다. 하지만 Omega 팀은 Kappa 팀이 생성한 파일에 액세스할 수 있습니다. Kappa 팀의 데이터를 격리하려면 해당 팀을 위한 팀 수준 저장소 버킷도 설정해야 합니다.

Availability matrix

시작하기 전에 BYOB이 배포 유형과 저장소 공급자에 사용 가능한지 확인하세요. W&B는 다음 저장소 공급자에 연결할 수 있습니다:

CoreWeave AI Object Storage: AI 워크로드에 최적화된 고성능 S3 호환 object storage 서비스입니다.
Amazon S3: 확장성, 데이터 가용성, 보안 및 performance를 제공하는 object storage 서비스입니다.
Google Cloud Storage: 대규모 비정형 데이터 저장을 위한 관리형 서비스입니다.
Azure Blob Storage: 텍스트, binary data, 이미지, 비디오, logs와 같은 대량의 비정형 데이터를 저장하기 위한 클라우드 기반 object storage 솔루션입니다.
MinIO Enterprise (AIStor)와 같은 S3 호환 저장소 또는 클라우드 또는 온프레미스 인프라에 호스팅된 기타 엔터프라이즈급 솔루션입니다.

다음 table은 각 W&B 배포 유형별 범위에서 BYOB의 가용성을 보여줍니다.

W&B 배포 유형	인스턴스 수준	팀 수준	Additional information
Dedicated Cloud	✓	✓	인스턴스 및 팀 수준 BYOB은 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage, 그리고 클라우드 또는 온프레미스 인프라에 호스팅된 MinIO Enterprise (AIStor)와 같은 S3 호환 저장소에서 지원됩니다.
Multi-tenant Cloud	Not applicable	✓¹	팀 수준 BYOB은 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage에서 지원됩니다.
Self-Managed	✓	✓	인스턴스 및 팀 수준 BYOB은 CoreWeave AI Object Storage, Amazon S3, Google Cloud Storage, Microsoft Azure Blob Storage, 그리고 클라우드 또는 온프레미스 인프라에 호스팅된 MinIO Enterprise (AIStor)와 같은 S3 호환 저장소에서 지원됩니다.

^1.Azure Blob Storage는 Multi-tenant Cloud에서 팀 수준 BYOB에 지원되지 않습니다. 다음 섹션에서는 BYOB 설정 과정을 안내합니다.

Provision your bucket

verify availability를 확인한 후, 저장소 버킷을 프로비저닝할 준비가 되었습니다. 여기에는 액세스 정책과 CORS가 포함됩니다. 프로비저닝은 W&B가 쓰는 버킷을 생성하고, W&B Platform이 사용자를 대신해 사전 서명된 URL을 생성하는 데 필요한 권한을 부여합니다. 탭을 선택하여 계속하세요.

CoreWeave
AWS
Google Cloud
Azure
S3-compatible

요구 사항:

Multi-tenant Cloud, 또는
Dedicated Cloud v0.73.0 이상, 또는
Self-Managed v0.73.0 이상이며 v0.33.14+의 Helm 차트로 배포된 경우
AI Object Storage가 활성화되어 있고 버킷, API 액세스 키, 시크릿 키를 생성할 수 있는 권한이 있는 CoreWeave 계정.
W&B 인스턴스가 CoreWeave network endpoints에 연결할 수 있어야 합니다.

자세한 내용은 CoreWeave 문서의 CoreWeave AI Object Storage 버킷 만들기를 참조하세요.

Multi-tenant Cloud: 버킷 정책에 필요한 조직 ID를 획득하세요.
1. W&B App에 로그인하세요.
2. 왼쪽 내비게이션에서 새 팀 만들기를 클릭하세요.
3. 열리는 드로어에서 팀 구성원 초대 위에 표시되는 W&B 조직 ID를 복사하세요.
4. 이 페이지를 열어 두세요. W&B 설정을 위해 사용합니다.
Dedicated Cloud / Self-Managed: 버킷 정책에 필요한 Customer Namespace를 획득하세요.
1. W&B App에서 사용자 프로필 아이콘을 클릭한 다음 System Console을 클릭하세요.
2. Authentication 탭을 클릭하세요.
3. 페이지 하단에서 Customer Namespace 값을 복사하세요. 이 값은 버킷 정책을 구성하는 데 사용하세요.
4. System Console을 닫으세요.
CoreWeave에서 원하는 이름으로 버킷을 선호하는 CoreWeave Availability Zone에 생성하세요. 선택적으로 W&B가 모든 W&B 파일의 하위 경로로 사용할 폴더를 생성하세요. 버킷 이름, Availability Zone, API 액세스 키, 시크릿 키, 하위 경로를 기록해 두세요.

버킷에 다음 CORS(Cross-Origin Resource Sharing) 정책을 설정하세요.

[
  {
    "AllowedHeaders": [
      "*"
    ],
    "AllowedMethods": [
      "GET",
      "HEAD",
      "PUT"
    ],
    "AllowedOrigins": [
      "*"
    ],
    "ExposeHeaders": [
      "ETag"
    ],
    "MaxAgeSeconds": 3000
  }
]

CoreWeave 저장소는 S3-compatible입니다. CORS에 대한 자세한 내용은 AWS 설명서의 교차 오리진 리소스 공유(CORS) 구성을 참조하세요.

W&B 배포가 버킷에 액세스하고 사전 서명된 URL을 생성할 수 있도록 필요한 권한을 부여하는 버킷 정책을 설정하세요. 해당 URL은 클라우드 인프라 또는 사용자 브라우저의 AI 워크로드가 버킷에 액세스하는 데 사용됩니다. CoreWeave 문서의 버킷 정책 레퍼런스를 참조하세요.

{
  "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"로 시작하는 절은 조직의 사용자에게 버킷에 대한 직접 액세스 권한을 부여합니다. 이 권한이 필요하지 않다면 정책에서 해당 절을 생략해도 됩니다.

버킷 정책에서 플레이스홀더를 교체하세요:
- <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>:
  - Multi-tenant Cloud: Provision your bucket에서 확인한 조직 ID입니다.
  - Dedicated Cloud 또는 Self-Managed: Provision your bucket에서 확인한 Customer Namespace입니다.
Dedicated Cloud: 지원에 문의하여 추가 단계를 완료하세요.
Self-Managed: W&B 배포를 업데이트하여 환경 변수 GORILLA_SUPPORTED_FILE_STORES를 정확한 문자열 cw://로 설정하고 W&B를 다시 시작하세요. 그렇지 않으면 팀 저장소를 설정할 때 CoreWeave가 옵션으로 표시되지 않습니다.

다음으로, W&B 설정하기.

자세한 내용은 AWS 설명서의 S3 버킷 생성을 참조하세요.

KMS 키를 프로비저닝하세요. W&B에서는 S3 버킷의 데이터를 암호화하고 복호화하기 위해 KMS 키를 프로비저닝해야 합니다. 키 사용 유형은 ENCRYPT_DECRYPT이어야 합니다. 다음 정책을 키에 부여하세요.
{ "Version": "2012-10-17", "Statement": [ { "Sid" : "Internal", "Effect" : "Allow", "Principal" : { "AWS" : "<Your_Account_Id>" }, "Action" : "kms:*", "Resource" : "<aws_kms_key.key.arn>" }, { "Sid" : "External", "Effect" : "Allow", "Principal" : { "AWS" : "<aws_principal_and_role_arn>" }, "Action" : [ "kms:Decrypt", "kms:Describe*", "kms:Encrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*" ], "Resource" : "<aws_kms_key.key.arn>" } ] }
<Your_Account_Id>와 <aws_kms_key.key.arn>를 그에 맞게 교체하세요. Multi-tenant Cloud 또는 Dedicated Cloud을 사용하는 경우, <aws_principal_and_role_arn>을 해당 값으로 교체하세요:
- Multi-tenant Cloud: arn:aws:iam::725579432336:role/WandbIntegration
- Dedicated Cloud: arn:aws:iam::830241207209:root
이 정책은 AWS 계정에 키에 대한 전체 액세스 권한을 부여하며, W&B 플랫폼을 호스팅하는 AWS 계정에 필요한 권한도 부여합니다. KMS 키 ARN을 기록해 두세요.

S3 버킷을 프로비저닝하세요. AWS 계정에서 S3 버킷을 프로비저닝하려면 다음 단계를 따르세요:

원하는 이름으로 S3 버킷을 생성하세요. 선택적으로, 모든 W&B 파일을 저장할 하위 경로로 구성할 수 있는 폴더를 생성하세요.
이전 단계의 KMS 키를 사용하여 서버 측 암호화를 활성화하세요.

다음 정책으로 CORS를 구성하세요:

[
  {
      "AllowedHeaders": [
          "*"
      ],
      "AllowedMethods": [
          "GET",
          "HEAD",
          "PUT"
      ],
      "AllowedOrigins": [
          "*"
      ],
      "ExposeHeaders": [
          "ETag"
      ],
      "MaxAgeSeconds": 3000
  }
]

버킷의 데이터가 object lifecycle management policy로 인해 만료되면 일부 run의 이력을 읽을 수 있는 기능을 잃을 수 있습니다.

W&B 플랫폼을 호스팅하는 AWS 계정에 필요한 S3 권한을 부여하세요. 이 권한은 클라우드 인프라 또는 사용자 브라우저의 AI 워크로드가 버킷에 액세스하는 데 사용하는 사전 서명된 URL을 생성하는 데 필요합니다.

{
  "Version": "2012-10-17",
  "Id": "WandBAccess",
  "Statement": [
    {
      "Sid": "WAndBAccountAccess",
      "Effect": "Allow",
      "Principal": { "AWS": "<aws_principal_and_role_arn>" },
        "Action" : [
          "s3:GetObject*",
          "s3:GetEncryptionConfiguration",
          "s3:ListBucket",
          "s3:ListBucketMultipartUploads",
          "s3:ListBucketVersions",
          "s3:AbortMultipartUpload",
          "s3:DeleteObject",
          "s3:PutObject",
          "s3:GetBucketCORS",
          "s3:GetBucketLocation",
          "s3:GetBucketVersioning"
        ],
      "Resource": [
        "arn:aws:s3:::<wandb_bucket>",
        "arn:aws:s3:::<wandb_bucket>/*"
      ]
    }
  ]
}

<wandb_bucket>을 적절히 교체하고 버킷 이름을 기록해 두세요. 다음으로 W&B 구성을 진행하세요. Multi-tenant Cloud 또는 Dedicated Cloud를 사용하는 경우 <aws_principal_and_role_arn>을 해당 값으로 교체하세요.

Multi-tenant Cloud의 경우: arn:aws:iam::725579432336:role/WandbIntegration
Dedicated Cloud의 경우: arn:aws:iam::830241207209:root

자세한 내용은 AWS 자체 관리형 호스팅 가이드를 참조하세요.

자세한 내용은 Google Cloud 문서의 버킷 만들기를 참조하세요.

GCS 버킷을 프로비저닝합니다. Google Cloud 프로젝트에서 GCS 버킷을 프로비저닝하려면 다음 단계를 따르세요.
1. 원하는 이름으로 GCS 버킷을 생성합니다. 선택 사항으로, 모든 W&B 파일을 저장할 하위 경로로 설정할 폴더를 생성할 수 있습니다.
2. 암호화 유형을 Google-managed로 설정합니다.
3. 일시 삭제(soft deletion)를 켭니다. 버킷의 일시 삭제 정책 수정을 참조하세요.
4. gsutil을 사용하여 CORS 정책을 설정합니다. 이 작업은 UI에서는 할 수 없습니다.
  1. 로컬에 cors-policy.json이라는 이름의 파일을 생성합니다.
  2. 다음 CORS 정책을 파일에 복사하고 저장합니다.
    [ { "origin": ["*"], "responseHeader": ["Content-Type"], "exposeHeaders": ["ETag"], "method": ["GET", "HEAD", "PUT"], "maxAgeSeconds": 3000 } ]
    객체 라이프사이클 관리 정책으로 인해 버킷의 데이터가 만료되면 일부 run의 이력을 조회하지 못할 수 있습니다.
5. <bucket_name>을 올바른 버킷 이름으로 바꾸고 gsutil을 실행합니다.
  gsutil cors set cors-policy.json gs://<bucket_name>
6. 버킷의 정책을 확인합니다. <bucket_name>을 올바른 버킷 이름으로 바꿉니다.
  gsutil cors get gs://<bucket_name>
Multi-tenant Cloud 또는 Dedicated Cloud를 사용하는 경우, W&B 플랫폼에 연결된 Google Cloud 서비스 계정에 storage.admin 역할을 부여합니다. W&B는 버킷의 CORS 설정과 객체 버전 관리 활성화 여부 등의 속성을 확인하려면 이 역할이 필요합니다. 서비스 계정에 storage.admin 역할이 없으면 이 확인 과정에서 HTTP 403 오류가 발생합니다.
- Multi-tenant Cloud의 계정: wandb-integration@wandb-production.iam.gserviceaccount.com
- Dedicated Cloud의 계정: deploy@wandb-production.iam.gserviceaccount.com
버킷 이름을 기록해 두세요. 다음으로 BYOB용 W&B 설정을 진행하세요.

자세한 내용은 Azure 문서의 Create a blob storage container를 참조하세요.인스턴스 수준 BYOB:

Azure Blob Storage 컨테이너를 프로비저닝합니다. Self-Managed 배포와 이 Terraform 모듈을 사용하지 않는 Dedicated Cloud 배포에서는 다음 단계에 따라 Azure 구독에 Azure Blob Storage 컨테이너를 프로비저닝하세요.
1. 원하는 이름으로 컨테이너를 생성합니다. 필요한 경우 모든 W&B 파일을 저장할 하위 경로로 설정할 폴더를 생성합니다.
2. 컨테이너에 CORS 정책을 설정합니다. UI에서 CORS 정책을 설정하려면 블롭 저장소로 이동한 다음 Settings/Resource Sharing (CORS)까지 스크롤하여 다음과 같이 설정하세요.
  매개변수 값
  Allowed Origins *
  Allowed Methods GET, HEAD, PUT
  Allowed Headers *
  Exposed Headers *
  Max Age 3000
  
  객체 라이프사이클 관리 정책에 따라 버킷의 데이터가 만료되면 일부 run의 이력을 조회하지 못할 수 있습니다.
인증 방법을 선택합니다.
- 저장소 계정 키: 저장소 계정 액세스 키를 생성하고 키와 저장소 계정 이름을 기록해 둡니다. Dedicated Cloud를 사용하는 조직은 안전한 공유 수단을 통해 이 값을 W&B 계정 팀에 전달하세요.
- Workload Identity: Azure 관리 ID에 저장소 계정 액세스 권한을 부여하고 W&B가 이 ID를 사용하도록 설정합니다. 이 방법을 사용하면 저장소 계정 키를 공유할 필요가 없습니다. 배포 유형별 Workload Identity 안내를 따르세요.

매개변수	값
Allowed Origins	`*`
Allowed Methods	`GET`, `HEAD`, `PUT`
Allowed Headers	`*`
Exposed Headers	`*`
Max Age	`3000`

팀 수준 BYOB:Dedicated Cloud 배포에서는 Terraform을 사용하여 필요한 액세스 메커니즘과 권한을 갖춘 Azure Blob Storage 컨테이너를 프로비저닝할 것을 권장합니다. Terraform을 사용하지 않는 Dedicated Cloud 배포 또는 Self-Managed 배포에서는 인스턴스 수준 저장소 프로비저닝 단계에 따라 버킷을 프로비저닝하세요. 인스턴스의 OIDC issuer URL을 제공하고, 다음 정보를 기록해 두세요.

저장소 계정 이름
저장소 컨테이너 이름
관리 ID 클라이언트 ID
Azure 테넌트 ID

다음으로, 저장소 주소를 확인.

저장소 주소 확인

버킷을 프로비저닝한 후에는 W&B가 버킷을 찾고 인증하는 데 사용할 저장소 주소가 필요합니다. 다음 섹션에서는 W&B 팀을 BYOB 저장소 버킷에 연결하는 데 사용하는 구문을 설명합니다. 예시에서 꺾쇠괄호(<>) 안의 자리 표시자 값을 버킷 정보로 바꾸세요. 자세한 안내는 해당 탭을 선택하세요.

CoreWeave
AWS
Google Cloud
Azure
S3 호환

이 섹션은 Dedicated Cloud 또는 Self-Managed의 팀 수준 BYOB에만 해당합니다. 인스턴스 수준 BYOB 또는 Multi-tenant Cloud를 사용하는 경우 바로 W&B 설정으로 진행하세요.다음 형식에 따라 전체 버킷 경로를 확인하세요. 꺾쇠괄호(<>) 안의 자리 표시자를 버킷 값으로 바꾸세요.버킷 형식:

cw://<accessKey>:<secretAccessKey>@cwobject.com/<bucketName>?tls=true

W&B는 cwobject.com HTTPS 엔드포인트를 지원하며, TLS 1.3이 필요합니다. 다른 CoreWeave 엔드포인트 사용을 원하는 경우 지원팀에 문의하세요.

버킷 형식:

s3://<accessKey>:<secretAccessKey>@<s3_regional_url_endpoint>/<bucketName>?region=<region>

W&B 인스턴스와 저장소 버킷이 모두 AWS에 배포되어 있고 W&B 인스턴스의 AWS_REGION이 버킷의 AWS S3 리전과 일치하는 경우가 아니라면, 주소에 region 매개변수를 반드시 포함해야 합니다.

버킷 형식:

gs://<serviceAccountEmail>:<urlEncodedPrivateKey>@<bucketName>

버킷 형식:

az://:<urlEncodedAccessKey>@<storageAccountName>/<containerName>

버킷 형식:

s3://<accessKey>:<secretAccessKey>@<url_endpoint>/<bucketName>?region=<region>&tls=true

주소에 region 매개변수를 반드시 포함해야 합니다.

이 섹션은 MinIO Enterprise (AIStor)나 온프레미스에서 호스팅되는 기타 엔터프라이즈급 S3 호환 솔루션처럼 S3에서 호스팅되지 않는 S3 호환 저장소 버킷에 해당합니다. AWS S3에서 호스팅되는 저장소 버킷은 AWS 탭을 참조하세요.MinIO 오픈 소스는 유지 관리 모드 상태로, 더 이상 활발히 개발되지 않으며 사전 컴파일된 바이너리도 제공되지 않습니다. 프로덕션 배포에는 엔터프라이즈급 S3 호환 솔루션을 사용하세요.S3 호환 모드를 선택적으로 지원하는 클라우드 네이티브 저장소 버킷에서는 가능하면 클라우드 네이티브 프로토콜 지정자를 사용하세요. 예를 들어 CoreWeave 버킷에는 s3:// 대신 cw://를 사용하세요.

저장소 주소를 확인했다면 팀 수준 BYOB 설정으로 진행하세요.

W&B 설정

버킷을 프로비저닝하고 그 주소를 확인한 후, 인스턴스 수준 또는 팀 수준에서 BYOB를 설정할 준비가 되었습니다. 이 마지막 단계는 W&B가 아티팩트, run 파일 및 기타 대형 객체의 저장소를 사용자의 버킷으로 라우팅하도록 지시합니다.

저장소 버킷 레이아웃을 신중하게 플랜하세요. W&B에 대한 저장소 버킷을 설정한 후, 데이터를 다른 버킷으로 마이그레이션하는 것은 복잡하며 W&B의 지원이 필요합니다. 이는 Dedicated Cloud 및 Self-Managed의 저장소뿐만 아니라 Multi-tenant Cloud의 팀 수준 저장소에도 적용됩니다. 질문이 있으시면 지원에 문의하세요.

인스턴스 수준 BYOB

인스턴스 수준에서 CoreWeave AI Object Storage를 사용하려면 이 안내를 따르지 말고 W&B 지원팀에 문의하세요. 셀프 서비스 설정은 아직 지원되지 않습니다.

Dedicated Cloud의 경우: 인스턴스를 설정하는 담당 W&B 팀에 버킷 세부 정보를 전달하세요. Azure workload identity를 사용하는 경우 저장소 계정에 대한 액세스 권한을 부여하고 저장소 계정 이름, 컨테이너 이름, 경로(선택)를 제공하세요. Self-Managed의 경우: W&B System Console에서 인스턴스 수준 BYOB를 설정하세요. Azure workload identity를 사용하는 경우 먼저 ID 설정을 완료하세요.

admin 역할이 있는 사용자로 W&B에 로그인하세요.
상단의 사용자 아이콘을 클릭한 다음 System Console을 클릭하세요.
Settings > System Connections로 이동하세요.
Bucket Storage에서 Provider를 선택하고 버킷 세부 정보를 입력하세요. Azure의 경우 **Azure Blob Storage (az)**를 선택하고 Storage account와 Blob container를 각각 입력하세요.
선택 사항: 새 버킷에서 사용할 Path를 입력하세요.
선택한 공급자의 ID 또는 자격 증명에 버킷 액세스 권한이 있는지 확인하세요. Azure의 경우 Authentication 방법을 선택하세요.
- Storage account key: Storage account key를 입력하세요.
- Workload identity (user-delegation SAS): 배포 Admin이 설정한 ID를 사용하세요. 이 옵션을 사용할 수 없는 경우 ID 설정을 완료하세요.
Save를 클릭하세요.

저장하면 W&B는 설정된 버킷을 인스턴스 수준에서 새 아티팩트와 run 파일의 기본 저장 위치로 사용합니다. 설정을 편집할 수 없는 경우 배포 Admin에게 문의하세요.

Azure workload identity 설정

Workload identity를 사용하면 W&B가 저장소 계정 키 없이 Azure 버킷에 액세스할 수 있습니다. 설정 방법을 확인하려면 배포 유형을 선택하세요.

Dedicated Cloud
Self-Managed

배포 설정은 W&B가 담당하며, 사용자는 Azure 저장소 계정에 대한 액세스를 설정합니다.

저장소 계정의 테넌트 ID를 담당 W&B 팀에 전달하여 사용할 관리 ID를 확인하세요.
해당 ID가 사용자의 Azure 테넌트에 있다면 아래 역할 할당에 해당 ID의 보안 주체 ID를 사용하세요. 그렇지 않다면 테넌트에서 관리 ID를 생성하거나 선택한 다음, W&B가 제공한 issuer, subject, audience 값으로 페더레이션 자격 증명을 설정하세요. 관리 ID는 다른 테넌트의 저장소에 직접 액세스할 수 없습니다.
BYOB 저장소 계정에서 저장소 계정 범위로 해당 ID의 보안 주체에 Reader 및 Storage Blob Data Contributor 역할을 부여하세요.
저장소 계정 이름, 컨테이너 이름, 경로(선택), ID의 테넌트 ID 및 클라이언트 ID를 담당 W&B 팀에 공유하세요.

W&B에서 연결 설정을 마치면 run 파일 또는 아티팩트를 업로드하고 다운로드하여 액세스를 확인하세요.

배포 Admin은 Azure와 Kubernetes에서 workload identity를 설정한 다음 System Console에서 이를 선택합니다.이 워크플로에는 다음 버전을 사용하세요.

컴포넌트	필수 버전
W&B Server	v0.84.0 이상(저장소에 액세스하는 모든 컴포넌트 포함)
Operator Helm chart	v0.44.13 이상
W&B System Console	인증 선택기를 사용하려면 v2.20.0 이상

Kubernetes 클러스터에서 OpenID Connect(OIDC) 토큰 페더레이션과 Azure workload identity를 활성화하세요. Azure Kubernetes Service(AKS)를 사용하는 경우 Microsoft Entra Workload ID 구성을 참조하세요.
Azure 관리 ID를 생성하거나 선택하고 테넌트 ID, 클라이언트 ID, 보안 주체 ID를 기록해 두세요. BYOB 저장소 계정에서 저장소 계정 범위로 해당 보안 주체에 Reader 및 Storage Blob Data Contributor 역할을 부여하세요.
Helm values의 global.azureStorageIdentity에 ID의 테넌트 ID, 클라이언트 ID, 보안 주체 ID를 설정하세요. 저장소에 액세스하는 Kubernetes service account에 페더레이션과 azure.workload.identity/client-id 어노테이션을 설정하세요. Helm 설정에 대한 자세한 내용은 Azure workload identity 설정을 참조하세요.
Console 절차에 따라 workload identity를 선택하고 버킷 설정을 저장하세요. run 파일 또는 아티팩트를 업로드하고 다운로드하여 액세스를 확인하세요.

팀 수준 BYOB

W&B App에서 팀을 생성할 때 또는 SCIM API를 사용하여 팀을 생성할 때(POST Groups, 선택 storageBucket) 팀 수준 BYOB를 설정할 수 있습니다. 두 가지 옵션이 있습니다:

기존 버킷 사용: 먼저 버킷의 저장소 위치를 확인해야 합니다.
새 버킷 생성 (Multi-tenant Cloud 전용): 팀을 생성할 때 W&B가 클라우드 제공업체에 버킷을 자동으로 생성할 수 있습니다. W&B는 CoreWeave, AWS, Google Cloud를 지원합니다.

팀을 생성한 후에는 저장소를 변경할 수 없습니다.
인스턴스 수준 BYOB는 인스턴스 수준 BYOB를 참조하세요.
팀에 CoreWeave 저장소를 설정하려는 경우 CoreWeave 요구 사항을 검토하고 지원에 문의하여 버킷이 CoreWeave에 올바르게 설정되었는지 확인하고 팀 설정을 검증하십시오. 팀 생성 후에는 저장소 세부 정보를 변경할 수 없기 때문입니다.

배포 유형을 선택하여 계속 진행하세요.

Multi-tenant Cloud
Dedicated Cloud and Self-Managed

새 팀 생성을 시작한 브라우저 창으로 전환하여 W&B 조직 ID를 찾으세요. 그렇지 않으면 admin 역할을 가진 사용자로 W&B에 로그인한 후, 왼쪽 상단의 아이콘을 클릭하여 왼쪽 내비게이션을 열고 Create a team to collaborate를 클릭하세요.
팀 이름을 입력하세요.
Storage Type을 External storage로 설정하세요.
Bucket location을 클릭하세요.
기존 버킷을 사용하려면 목록에서 선택하세요.
새 버킷을 생성하려면 하단의 Add bucket을 클릭한 후 다음을 수행하세요:
1. Cloud provider를 클릭하고 CoreWeave, AWS 또는 Google Cloud를 선택하세요.
2. 버킷 세부 정보를 입력하세요:
  - Name: 버킷 이름을 입력하세요.
  - Path (선택): 버킷 내에서 사용할 하위 경로를 입력하세요.
3. 선택한 클라우드 제공업체에 대한 추가 연결 설정을 제공하세요:
  - CoreWeave: 추가 설정이 필요하지 않습니다.
  - AWS: 암호화를 위해 KMS key ARN을 선택적으로 제공하세요.
  - Google Cloud: 추가 설정이 필요하지 않습니다.
Create team을 클릭하면 W&B가 지정된 설정으로 클라우드 제공업체에 버킷을 자동으로 생성합니다.
팀에 구성원을 초대하세요. Invite team members에서 쉼표로 구분된 이메일 주소 목록을 지정하세요. 그렇지 않으면 팀을 생성한 후에 구성원을 초대할 수 있습니다.
Create team을 클릭하세요.

W&B가 버킷에 액세스하는 중 오류를 발견하거나 잘못된 설정을 감지하면 페이지 하단에 오류 또는 경고가 표시됩니다. 그렇지 않으면 W&B가 팀을 생성합니다.

Dedicated Cloud: 팀에 대한 저장소 버킷을 사용하기 위해 나머지 단계를 진행하기 전에 계정 팀에 버킷 경로를 제공하여 인스턴스의 지원되는 파일 저장소에 추가해야 합니다.
Self-Managed: 팀에 대한 저장소 버킷을 사용하기 위해 나머지 단계를 진행하기 전에 GORILLA_SUPPORTED_FILE_STORES 환경 변수에 버킷 경로를 추가한 후 W&B를 다시 시작해야 합니다.
admin 역할을 가진 사용자로 W&B에 로그인한 후, 왼쪽 상단의 아이콘을 클릭하여 왼쪽 내비게이션을 열고 Create a team to collaborate를 클릭하세요.
팀 이름을 입력하세요.
Storage Type을 External storage로 설정하세요.
인스턴스 수준 저장소(내부 또는 외부 여부와 관계없이)를 팀 저장소로 사용하려면 인스턴스 수준 버킷이 BYOB용으로 구성된 경우에도 Storage Type을 Internal로 유지하세요. 팀에 대해 별도의 외부 저장소를 사용하려면 팀의 Storage Type을 External로 설정하고 다음 단계에서 버킷 세부 정보를 구성하세요.
Bucket location을 클릭하세요.
기존 버킷을 사용하려면 목록에서 선택하세요. 새 버킷을 추가하려면 하단의 Add bucket을 클릭한 후 버킷 세부 정보를 제공하세요. Cloud provider를 클릭하고 CoreWeave, AWS, Google Cloud 또는 Azure를 선택하세요. 클라우드 제공업체가 목록에 없으면 Provision your bucket의 지침에 따라 인스턴스의 지원되는 파일 저장소에 버킷 경로를 추가했는지 확인하세요. 저장소 공급자가 여전히 표시되지 않으면 지원팀에 문의하세요.
버킷 세부 정보를 지정하세요.
- 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 ID와 Managed Identity Client ID 값을 지정하세요. GORILLA_SUPPORTED_FILE_STORES로 연결 문자열을 구성하지 않은 경우 이 필드는 필수입니다.
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 문서의 교차 출처 리소스 공유(CORS) 구성을 참조하세요.
- AllowedMethods에는 GET, PUT, HEAD 메서드가 포함되어야 합니다.
- ExposeHeaders에는 ETag가 포함되어야 합니다.
- CORS 정책의 AllowedOrigins에는 W&B 프런트엔드 도메인이 포함되어야 합니다. 이 페이지의 CORS 정책 예시는 *를 사용하여 모든 도메인을 허용합니다.
LOTA 엔드포인트 문제
- W&B는 아직 LOTA 엔드포인트 연결을 지원하지 않습니다. 관심이 있으시면 지원팀에 문의하세요.
액세스 키 및 권한 오류
- CoreWeave API 액세스 키가 만료되지 않았는지 확인하세요.
- CoreWeave API 액세스 키와 시크릿 키에 GetObject, PutObject, DeleteObject, ListBucket 권한이 모두 부여되어 있는지 확인하세요. 이 페이지의 예시는 이 요구 사항을 충족합니다. 자세한 내용은 CoreWeave 문서의 액세스 키 생성 및 관리를 참조하세요.

Google Cloud

이 섹션은 Google Cloud Storage에 연결하는 문제를 해결하는 데 도움이 됩니다.

Bucket does not have soft deletion enabled Google Cloud Storage 버킷에 소프트 삭제가 켜져 있는지 확인하세요. 버킷의 소프트 삭제 정책 편집을 참조하세요.

​개요

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

​데이터베이스

​버킷

​버킷 범위

​Availability matrix

​Provision your bucket

​저장소 주소 확인

​W&B 설정

​인스턴스 수준 BYOB

​Azure workload identity 설정

​팀 수준 BYOB

​문제 해결

​CoreWeave

​Google Cloud

개요

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

데이터베이스

버킷

버킷 범위

Availability matrix

Provision your bucket

저장소 주소 확인

W&B 설정

인스턴스 수준 BYOB

Azure workload identity 설정

팀 수준 BYOB

문제 해결

CoreWeave

Google Cloud