Bring your own bucket(BYOB)

Bring your own bucket(BYOB) 기능을 사용해 자체 클라우드 저장소 버킷에 W&B 아티팩트와 데이터를 저장하세요.

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

• Multi-tenant Cloud: 팀 수준 BYOB
• Dedicated Cloud: 인스턴스 및 팀 수준 BYOB
• Self-Managed: 인스턴스 및 팀 수준 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 데이터를 제거합니다. 아티팩트 삭제에 대해서는 Delete an artifact를 참조하세요. Dedicated Cloud 및 Self-Managed 배포에서 삭제된 run 데이터는 Configure environment variables에 설명된 GORILLA_DATA_RETENTION_PERIOD 설정의 영향도 받습니다. W&B는 정리 시점을 보장하지 않습니다. 버킷 사용량과 비용을 한곳에서 확인하려면 Manage bucket storage and costs를 참조하세요.
• 버킷을 구성할 때 하위 경로를 지정하면 W&B가 버킷 루트 폴더에 파일을 저장하지 않도록 할 수 있습니다. 이렇게 하면 조직의 버킷 거버넌스 정책을 더 잘 준수할 수 있습니다.

​

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

BYOB 기능을 사용하면 W&B는 일부 데이터 유형은 W&B 중앙 데이터베이스에 저장하고, 다른 데이터 유형은 사용자의 버킷에 저장합니다. 어떤 데이터가 W&B 관리 인프라에 남고 어떤 데이터를 W&B가 사용자의 자체 저장소에 기록하는지 확인하려면 다음 목록을 참조하세요.

​

데이터베이스

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

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

​

버킷

저장소 버킷에는 다음 데이터가 저장됩니다:

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

​

버킷 범위

저장소 버킷은 두 가지 범위 중 하나로 구성할 수 있습니다.

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

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

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

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

​

가용성 매트릭스

시작하기 전에 사용 중인 배포 유형과 저장소 공급자에서 BYOB를 사용할 수 있는지 확인하세요. 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 type	인스턴스 수준	팀 수준	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	해당 없음	✓1	팀 수준 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.Multi-tenant Cloud에서는 팀 수준 BYOB에 Azure Blob Storage가 지원되지 않습니다.

다음 섹션에서는 BYOB 설정 방법을 안내합니다.

​

버킷 프로비저닝

가용성 확인을 마치면 액세스 정책과 CORS를 포함한 저장소 버킷을 프로비저닝할 수 있습니다. 프로비저닝을 수행하면 W&B가 기록할 버킷이 생성되고, W&B 플랫폼이 사용자를 대신해 사전 서명된 URL을 생성하는 데 필요한 권한이 부여됩니다. 계속하려면 탭을 선택하세요.

CoreWeave

요구 사항:

• 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>:
     • Multi-tenant Cloud: Provision your bucket에서 확인한 조직 ID입니다.
     • Dedicated Cloud 또는 Self-Managed: Provision your bucket에서 확인한 고객 네임스페이스입니다.

7. Dedicated Cloud: 추가 step을 마치려면 지원팀에 문의하세요.

8. Self-Managed: W&B 배포를 업데이트하여 환경 변수 GORILLA_SUPPORTED_FILE_STORES를 정확히 cw://로 설정한 후 W&B를 다시 시작하세요. 그렇지 않으면 팀 저장소를 설정할 때 CoreWeave가 옵션으로 표시되지 않습니다.

다음으로, W&B를 설정합니다.

AWS

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

1. 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을 기록해 두세요.

2. S3 버킷을 생성하세요.

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

   1. 원하는 이름으로 S3 버킷을 생성합니다. 필요하면 폴더를 만들어 모든 W&B 파일을 저장할 하위 경로로 설정할 수 있습니다.

   2. 이전 단계의 KMS 키를 사용해 서버 측 암호화를 활성화합니다.

   3. 다음 정책으로 CORS를 설정합니다.

      [
        {
            "AllowedHeaders": [
                "*"
            ],
            "AllowedMethods": [
                "GET",
                "HEAD",
                "PUT"
            ],
            "AllowedOrigins": [
                "*"
            ],
            "ExposeHeaders": [
                "ETag"
            ],
            "MaxAgeSeconds": 3000
        }
      ]
      
      버킷의 데이터가 객체 수명 주기 관리 정책으로 인해 만료되면 일부 run의 이력을 조회하지 못할 수 있습니다.

   4. W&B platform을 호스팅하는 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 Self-Managed 호스팅 가이드를 참조하세요.

Google Cloud

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

1. GCS 버킷을 프로비저닝합니다.

   Google Cloud 프로젝트에서 GCS 버킷을 프로비저닝하려면 다음 단계를 따르세요.

   1. 원하는 이름으로 GCS 버킷을 생성합니다. 필요에 따라 모든 W&B 파일을 저장할 하위 경로로 사용할 폴더를 생성할 수도 있습니다.

   2. 암호화 유형을 Google-managed로 설정합니다.

   3. 소프트 삭제를 켭니다. 버킷의 소프트 삭제 정책 수정을 참조하세요.

   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>
      

2. Multi-tenant Cloud 또는 Dedicated Cloud를 사용하는 경우, W&B Platform에 연결된 Google Cloud 서비스 계정에 storage.admin 역할을 부여합니다. W&B는 버킷의 CORS 설정과 객체 버전 관리 활성화 여부 등의 속성을 확인하기 위해 이 역할이 필요합니다. 서비스 계정에 storage.admin 역할이 없으면 이러한 확인 과정에서 HTTP 403 오류가 발생합니다.

   • Multi-tenant Cloud의 계정은 다음과 같습니다: [e-mail]
   • Dedicated Cloud의 계정은 다음과 같습니다: [e-mail]

   버킷 이름을 기록해 두세요. 다음으로 BYOB용 W&B를 설정하세요.

Azure

자세한 내용은 Azure 설명서의 blob storage 컨테이너 만들기를 참조하세요.

Instance level BYOB:

1. Azure Blob Storage 컨테이너를 프로비저닝합니다.

   Self-Managed 배포와 이 Terraform module을 사용하지 않는 Dedicated Cloud 배포의 경우, 다음 단계에 따라 Azure 구독에 Azure Blob Storage 컨테이너를 프로비저닝하세요.

   1. 원하는 이름으로 컨테이너를 생성합니다. 필요하면 모든 W&B 파일을 저장하는 하위 경로로 설정할 폴더를 만들 수도 있습니다.

   2. 컨테이너에 CORS 정책을 구성합니다.

      UI에서 CORS 정책을 설정하려면 blob storage로 이동한 다음 아래로 스크롤하여 Settings/Resource Sharing (CORS)로 이동하고, 다음과 같이 설정하세요.

      매개변수	값
      허용된 원본	*
      허용된 방법	GET, HEAD, PUT
      허용된 헤더	*
      노출된 헤더	*
      최대 기간	3000

      객체 lifecycle 관리 정책으로 인해 버킷의 데이터가 만료되면 일부 run의 이력을 조회하지 못할 수 있습니다.

2. 저장소 계정 액세스 키를 생성하고, 해당 키 이름과 저장소 계정 이름을 기록해 두세요. Dedicated Cloud를 사용하는 경우에는 안전한 공유 메커니즘을 사용해 저장소 계정 이름과 액세스 키를 W&B 팀과 공유하세요.

Team level BYOB:

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

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

S3 호환

S3 호환 버킷을 생성하세요. 다음 항목을 기록해 두세요.

• 액세스 키
• 시크릿 액세스 키
• URL 엔드포인트
• 버킷 이름
• 해당하는 경우 폴더 경로
• 리전

다음으로 저장소 주소를 확인하세요.

​

저장소 주소 확인

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

CoreWeave

이 섹션은 Dedicated Cloud 또는 Self-Managed의 팀 수준 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 엔드포인트에 관심이 있다면 지원팀에 문의하세요.

AWS

Bucket 형식:

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

주소에서 region 매개변수는 W&B 인스턴스와 저장소 버킷이 모두 AWS에 배포되어 있고, W&B 인스턴스의 AWS_REGION이 버킷의 AWS S3 리전과 일치하는 경우를 제외하면 필수입니다.

Google Cloud

Bucket 형식:

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

Azure

Bucket 형식:

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

S3-compatible

Bucket 형식:

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

주소에서 region 매개변수는 필수입니다.

이 섹션은 MinIO Enterprise (AIStor) 또는 온프레미스에서 호스팅되는 기타 엔터프라이즈급 S3 호환 솔루션처럼, S3에 호스팅되지 않은 S3 호환 저장소 버킷에 해당합니다. AWS S3에 호스팅된 저장소 버킷은 대신 AWS 탭을 참조하세요.

MinIO Open Source는 활성 개발이나 사전 컴파일된 바이너리 제공 없이 maintenance mode 상태입니다. 프로덕션 배포에는 엔터프라이즈급 S3 호환 솔루션을 사용하세요.

선택적 S3 호환 모드를 제공하는 클라우드 네이티브 저장소 버킷은 가능하면 클라우드 네이티브 프로토콜 지정자를 사용하세요. 예를 들어 CoreWeave 버킷에는 s3:// 대신 cw://를 사용하세요.

저장소 주소를 확인했다면 이제 팀 수준 BYOB 구성으로 진행할 수 있습니다.

​

W&B 설정

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

저장소 버킷 레이아웃은 신중하게 계획하세요. 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. 공급자를 선택합니다.
6. Bucket Name을 입력합니다.
7. 필요에 따라 새 버킷에서 사용할 Path를 입력합니다.
8. Save를 클릭합니다.

저장한 후에는 W&B가 인스턴스 수준에서 새 아티팩트와 run 파일의 기본 저장소 대상으로 설정된 버킷을 사용합니다.

​

팀 수준 BYOB

W&B App에서 팀을 만들 때 또는 SCIM API(선택적 storageBucket이 포함된 POST Groups)를 사용할 때 팀 수준 BYOB를 설정할 수 있습니다. 옵션은 두 가지입니다.

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

• 팀을 생성한 후에는 저장소를 변경할 수 없습니다.
• 인스턴스 수준 BYOB는 Instance level BYOB를 참고하세요.
• 팀에 CoreWeave 저장소를 설정할 계획이라면 CoreWeave requirements를 검토하고, 지원팀에 문의해 CoreWeave에서 버킷이 올바르게 설정되었는지와 팀 설정이 유효한지를 확인하세요. 팀을 생성한 후에는 저장소 세부 정보를 변경할 수 없습니다.

계속하려면 배포 유형을 선택하세요.

Dedicated Cloud / Self-Hosted

1. Dedicated Cloud: 팀에서 저장소 버킷을 사용하려면, 아래 나머지 단계를 진행하기 전에 버킷 경로를 담당 account team에 반드시 제공하여 인스턴스의 지원 파일 저장소에 추가하도록 해야 합니다.

2. Self-Managed: 팀에서 저장소 버킷을 사용하려면, 아래 나머지 단계를 진행하기 전에 버킷 경로를 GORILLA_SUPPORTED_FILE_STORES 환경 변수에 반드시 추가한 다음 W&B를 재시작해야 합니다.

3. admin 역할이 있는 사용자로 W&B에 로그인한 다음, 왼쪽 상단의 아이콘을 클릭해 왼쪽 내비게이션을 열고 협업할 팀 만들기를 클릭합니다.

4. 팀 이름을 입력합니다.

5. Storage Type을 External storage로 설정합니다.

   팀 저장소로 인스턴스 수준 저장소를 사용하려면(내부/외부 여부와 관계없이), 인스턴스 수준 버킷이 BYOB로 설정되어 있더라도 Storage Type은 Internal로 그대로 두세요. 팀에 별도의 외부 저장소를 사용하려면 팀의 Storage Type을 External로 설정하고 다음 단계에서 버킷 세부 정보를 구성하세요.

6. Bucket location을 클릭합니다.

7. 기존 버킷을 사용하려면 목록에서 선택합니다. 새 버킷을 추가하려면 하단의 Add bucket을 클릭한 다음 버킷 세부 정보를 입력합니다.

   Cloud 공급자를 클릭하고 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 ID와 Managed Identity Client ID 값을 지정합니다. GORILLA_SUPPORTED_FILE_STORES로 연결 문자열을 구성하지 않았다면 이 필드는 필수입니다.

9. Create team을 클릭합니다.

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

Multi-tenant Cloud

1. 이전에 새 팀 생성을 시작하면서 W&B 조직 ID를 확인했던 브라우저 창으로 전환합니다. 해당 창이 없다면, admin 역할이 있는 사용자로 W&B에 로그인한 다음 왼쪽 상단의 아이콘을 클릭해 왼쪽 내비게이션을 열고 협업할 팀 만들기를 클릭합니다.

2. 팀 이름을 입력합니다.

3. Storage Type을 External storage로 설정합니다.

4. Bucket location을 클릭합니다.

5. 기존 버킷을 사용하려면 목록에서 선택합니다.

6. 새 버킷을 만들려면 하단의 Add bucket을 클릭한 다음 다음을 수행합니다.

   1. Cloud 공급자를 클릭하고 CoreWeave, AWS, 또는 Google Cloud를 선택합니다.
   2. 버킷 세부 정보를 입력합니다.
      • Name: 버킷 이름을 입력합니다.
      • Path (선택): 버킷 내에서 사용할 하위 경로를 입력합니다.
   3. 선택한 클라우드 제공업체에 대한 추가 연결 설정을 입력합니다.
      • CoreWeave: 추가 설정이 필요하지 않습니다.
      • AWS: 필요에 따라 암호화를 위한 KMS key ARN을 입력합니다.
      • Google Cloud: 추가 설정이 필요하지 않습니다.
   Create team을 클릭하면 W&B가 지정한 설정으로 클라우드 제공업체에 버킷을 자동으로 생성합니다.

7. 팀에 구성원을 초대합니다. Invite team members에 쉼표로 구분된 이메일 주소 목록을 입력합니다. 또는 팀이 생성된 후에 구성원을 초대할 수도 있습니다.

8. Create team을 클릭합니다.

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

​

문제 해결

W&B에서 버킷을 검증하거나 연결하는 중 오류가 발생하는 경우, 다음 섹션을 참고하여 저장소 공급자별로 가장 일반적인 원인을 진단하세요.

​

CoreWeave

이 섹션은 CoreWeave AI Object Storage에 연결할 때 발생하는 문제를 해결하는 데 도움이 됩니다.

• 연결 오류
  • W&B 인스턴스가 CoreWeave 네트워크 엔드포인트에 연결할 수 있는지 확인하세요.
  • CoreWeave는 버킷 이름이 경로 시작 부분의 서브도메인으로 들어가는 virtual-hosted 스타일 경로를 사용합니다. 예를 들어 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 버킷에서 소프트 삭제가 활성화되어 있는지 확인하세요. 버킷의 소프트 삭제 정책 수정을 참조하세요.