独自のバケットを使用する (BYOB)

Bring Your Own Bucket (BYOB) 機能を使用して、W&B Artifacts とデータをお使いのクラウドストレージバケットに保存します。

このガイドは、すべての W&B のデプロイタイプに適用されます。

• マルチテナントクラウド: チームレベルの BYOB
• 専用クラウド: インスタンスレベルとチームレベルの BYOB
• セルフマネージド: インスタンスレベルとチームレベルの BYOB

このガイドのバケットのプロビジョニング手順は、デプロイタイプにかかわらず共通です。

​

概要

独自のバケットを使用する (BYOB) を使用すると、W&B Artifacts やその他の関連する機密データを、お使いのクラウドまたはオンプレミスのインフラストラクチャーに保存できます。専用クラウド または マルチテナントクラウド の場合、バケットに保存したデータが W&B 管理のインフラストラクチャーにコピーされることはありません。

• W&B SDK / CLI / UI とお客様のバケット間の通信は、事前署名付き URL を使用して行われます。
• W&B は、ガベージコレクションおよび関連プロセスを使用して、削除済みの アーティファクト と run データ を時間の経過とともにお客様のバケットから削除します。アーティファクトの削除については、アーティファクトを削除する で説明しています。専用クラウドおよびセルフマネージドのデプロイで削除された run データは、環境変数を設定する で説明されている GORILLA_DATA_RETENTION_PERIOD にも依存します。クリーンアップのタイミングは保証されません。バケットの使用状況とコストの概要については、バケット ストレージとコストを管理する を参照してください。
• バケットの設定時にサブパスを指定すると、W&B がバケットのルート直下のフォルダにファイルを保存しないようにできます。これにより、組織のバケットガバナンスポリシーに準拠しやすくなります。

​

中央データベースとバケットに保存されるデータ

BYOB 機能を使用すると、一部のタイプのデータは W&B の中央データベースに保存され、他のタイプのデータはお使いのバケットに保存されます。

​

データベース

• Users、Teams、Artifacts、Experiments、Projects のメタデータ
• Reports
• Experiments のログ
• システムメトリクス
• コンソールログ

​

バケット

• 実験ファイルとメトリクス
• Artifact ファイル
• メディアファイル
• run ファイル
• エクスポートされた history メトリクスおよび Parquet 形式のシステムイベント

​

バケットのスコープ

ストレージバケットに設定できるスコープは 2 つあります。

Scope	Description
インスタンス レベル	専用クラウド と セルフマネージド では、組織またはインスタンス内で必要な権限を持つ任意のユーザーが、インスタンスのストレージバケットに保存されたファイルにアクセスできます。マルチテナントクラウド には適用されません。
チームレベル	W&B Teams が チームレベル のストレージバケットを使用するように設定されている場合、そのチームメンバーはそこに保存されたファイルにアクセスできます。チームレベル のストレージバケットを使用すると、機密性の高いデータや厳格なコンプライアンス要件を持つチームに対して、よりきめ細かなデータアクセス制御とデータ分離を実現できます。 チームレベル のストレージは、1 つのインスタンスを共有する異なる事業部門や部署が、インフラストラクチャーと管理リソースを効率的に活用するのに役立ちます。また、別々のプロジェクトチームが、それぞれ異なる顧客案件向けの AI ワークフローを管理できるようにもなります。すべてのデプロイタイプで利用できます。チームの設定時にチームレベル BYOB を設定します。

この柔軟な設計により、組織のニーズに応じてさまざまなストレージ構成を実現できます。たとえば、次のようなものがあります。

• 同じバケットをインスタンスと 1 つ以上のチームで使用できます。
• 各チームが個別のバケットを使用することも、一部のチームがインスタンスのバケットに書き込むことを選ぶことも、複数のチームがサブパスに書き込んで 1 つのバケットを共有することもできます。
• チームごとのバケットを、異なるクラウドインフラストラクチャー環境やリージョンでホストし、異なるストレージ管理チームが管理することもできます。

たとえば、組織内に Kappa というチームがあるとします。組織 (および Team Kappa) は、デフォルトで インスタンス レベル のストレージバケットを使用します。次に、Omega というチームを作成します。Team Omega を作成するときに、そのチーム用の チームレベル のストレージバケットを設定します。Team Omega が生成したファイルには、Team Kappa はアクセスできません。一方、Team Kappa が作成したファイルには、Team Omega からアクセスできます。Team Kappa のデータも分離したい場合は、そのチームについても チームレベル のストレージバケットを設定する必要があります。

​

利用可否マトリクス

W&Bは、以下のストレージプロバイダーに接続できます。

• CoreWeave AI Object Storage: AIワークロード向けに最適化された、高パフォーマンスのS3互換オブジェクトストレージサービス。
• Amazon S3: 業界最高水準のスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを備えたオブジェクトストレージサービス。
• Google Cloud Storage: 非構造化データを大規模に保存するためのマネージドサービス。
• Azure Blob Storage: テキスト、バイナリデータ、画像、動画、ログなど、大量の非構造化データを保存するためのクラウドベースのオブジェクトストレージソリューション。
• MinIO Enterprise (AIStor) などのS3互換ストレージや、お使いのクラウドまたはオンプレミスのインフラストラクチャーでホストされる、その他のエンタープライズ向けソリューション。

次の表は、各W&Bデプロイタイプにおける各スコープでのBYOBの利用可否を示しています。

W&B デプロイタイプ	インスタンス レベル	チームレベル	追加情報
専用クラウド	✓	✓	CoreWeave AI Object Storage、Amazon S3、Google Cloud Storage、Microsoft Azure Blob Storage、およびお使いのクラウドまたはオンプレミスのインフラストラクチャーでホストされる MinIO Enterprise (AIStor) などのS3互換ストレージで、インスタンス レベルとチームレベルのBYOBがサポートされます。
マルチテナントクラウド	該当なし	✓1	CoreWeave AI Object Storage、Amazon S3、Google Cloud Storageでは、チームレベルBYOBがサポートされます。
セルフマネージド	✓	✓	CoreWeave AI Object Storage、Amazon S3、Google Cloud Storage、Microsoft Azure Blob Storage、およびお使いのクラウドまたはオンプレミスのインフラストラクチャーでホストされる MinIO Enterprise (AIStor) などのS3互換ストレージで、インスタンス レベルとチームレベルのBYOBがサポートされます。

^1.マルチテナントクラウドのチームレベルBYOBでは、Azure Blob Storageはサポートされません。

以下のセクションでは、BYOBの設定手順を説明します。

​

バケットをプロビジョニングする

可用性を確認したら、アクセスポリシーと CORS を含むストレージバケットをプロビジョニングできます。続行するには、タブを選択してください。

CoreWeave

要件:

• Multi-tenant Cloud、または
• 専用クラウド v0.73.0 以上、または
• セルフマネージド v0.73.0 以降で、Helm チャート 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. 左側のナビゲーションで、Create a new team をクリックします。
   3. 開いたドロワーで、Invite team members の上にある W&B 組織 ID をコピーします。
   4. このページは開いたままにしておきます。後で W&B を設定 する際に使用します。

2. 専用クラウド / セルフマネージド: バケットポリシーに必要なカスタマーネームスペースを取得します。

   1. W&B App で、ユーザーのプロフィールアイコンをクリックし、System Console をクリックします。
   2. Authentication タブをクリックします。
   3. ページ下部で、Customer Namespace の値をコピーします。bucket ポリシーの設定で使用するため、この値は控えておいてください。
   4. System Console は閉じてかまいません。

3. CoreWeave で、任意の名前のバケットを、希望する CoreWeave のアベイラビリティゾーンに作成します。必要に応じて、すべての W&B ファイルのサブパスとして W&B が使用するフォルダーも作成します。バケット名、アベイラビリティゾーン、API アクセスキー、シークレットキー、サブパスを控えておいてください。

4. バケットに次のクロスオリジン リソース共有 (CORS) ポリシーを設定します:

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

   CoreWeave のストレージは S3 互換です。CORS の詳細については、AWS ドキュメントの Configuring cross-origin resource sharing (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
     • 専用クラウド または セルフマネージド: arn:aws:iam::wandb:static/wandb-integration
   • <wb-org-id>:
     • Multi-tenant Cloud: Provision your bucket の組織 ID。
     • 専用クラウド または セルフマネージド: Provision your bucket のカスタマーネームスペース。

7. 専用クラウド: 追加のstepを完了するには、サポートまでお問い合わせください。

8. セルフマネージド: 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 または 専用クラウド を利用している場合は、<aws_principal_and_role_arn> を該当する値に置き換えてください。

   • Multi-tenant Cloud: arn:aws:iam::725579432336:role/WandbIntegration
   • 専用クラウド: arn:aws:iam::830241207209:root

   このポリシーにより、お使いのAWSアカウントにキーへのフルアクセスが付与され、あわせてW&B PlatformをホストしているAWSアカウントに必須の権限が割り当てられます。KMS Key ARNを控えておいてください。

2. S3 バケットを作成します。

   AWS アカウントで S3 バケットをプロビジョニングするには、次の step に従ってください。

   1. 任意の名前で S3 バケットを作成します。必要に応じて、すべての W&B ファイルの保存先となるサブパスとして設定できるフォルダーも作成します。

   2. 前の step で作成した KMS キーを使用して、サーバー側の暗号化を有効にします。

   3. 次のポリシーで CORS を設定します。

      [
        {
            "AllowedHeaders": [
                "*"
            ],
            "AllowedMethods": [
                "GET",
                "HEAD",
                "PUT"
            ],
            "AllowedOrigins": [
                "*"
            ],
            "ExposeHeaders": [
                "ETag"
            ],
            "MaxAgeSeconds": 3000
        }
      ]
      
      バケット内のデータが object lifecycle management policy によって期限切れになると、一部の 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 または 専用クラウド を使用している場合は、<aws_principal_and_role_arn> を対応する値に置き換えてください。

      • Multi-tenant Cloud: arn:aws:iam::725579432336:role/WandbIntegration
      • 専用クラウド: arn:aws:iam::830241207209:root

詳細については、AWS セルフマネージドホスティングガイドを参照してください。

Google Cloud

詳細については、Google Cloud ドキュメントのバケットを作成するを参照してください。

1. GCS バケットをプロビジョニングします。

   Google Cloud プロジェクトで GCS バケットをプロビジョニングするには、次の step に従います。

   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 または 専用クラウド を使用している場合は、W&B Platform に関連付けられている Google Cloud サービスアカウントに storage.admin ロールを付与します。W&B がバケットの CORS 設定や、オブジェクトのバージョン管理が有効かどうかといった属性を確認するには、このロールが必要です。サービスアカウントに storage.admin ロールがない場合、これらの確認は HTTP 403 エラーになります。

   • Multi-tenant Cloud の場合、アカウントは次のとおりです: [e-mail]
   • 専用クラウド の場合、アカウントは次のとおりです: [e-mail]

   バケット名を記録しておいてください。次に、BYOB 向けに W&B を設定します。

Azure

詳細については、Azure のドキュメントの Create a blob storage container を参照してください。

インスタンス レベルの BYOB:

1. Azure Blob Storage コンテナーをプロビジョニングします。

   セルフマネージドのデプロイ、および this Terraform module を使用しない専用クラウドのデプロイでは、以下の手順に従って Azure サブスクリプションに Azure Blob Storage コンテナーをプロビジョニングします。

   1. 任意の名前でコンテナーを作成します。必要に応じて、すべての W&B ファイルの保存先となるサブパスとして設定できるフォルダーを作成します。

   2. コンテナーの CORS ポリシーを設定します。

      UI から CORS ポリシーを設定するには、blob storage に移動し、下にスクロールして Settings/Resource Sharing (CORS) を開き、以下のように設定します。

      パラメーター	値
      Allowed Origins	*
      Allowed Methods	GET, HEAD, PUT
      Allowed Headers	*
      Exposed Headers	*
      Max Age	3000

      object lifecycle management policy によって bucket 内のデータが期限切れになると、一部の run の履歴を参照できなくなる可能性があります。

2. ストレージ アカウントのアクセス キーを生成し、その名前とストレージ アカウント名を控えておいてください。専用クラウド を使用している場合は、安全な共有手段を使用してストレージ アカウント名とアクセス キーを W&B チームに共有してください。

チームレベル BYOB:

専用クラウドのデプロイでは、必要なアクセス メカニズムと権限を備えた Azure Blob Storage コンテナーをプロビジョニングするために、W&B は Terraform の使用を推奨しています。Terraform を使用しない専用クラウドのデプロイ、またはセルフマネージドのデプロイでは、インスタンス レベルのストレージをプロビジョニングする手順に従って bucket をプロビジョニングしてください。インスタンスの OIDC issuer URL を提供してください。以下の詳細を控えておいてください。

• ストレージ アカウント名
• ストレージ コンテナー名
• マネージド アイデンティティのクライアント ID
• Azure テナント ID

S3互換

S3互換のバケットを作成します。次の項目を控えておいてください。

• アクセスキー
• シークレットアクセスキー
• エンドポイントURL
• バケット名
• 該当する場合は、フォルダーパス
• リージョン

次に、ストレージアドレスを確認します。

​

ストレージアドレスを確認する

このセクションでは、W&B Team を BYOB ストレージバケットに接続するための構文を説明します。例では、山かっこ (<>) で囲まれたプレースホルダーの値を、お使いのバケットの詳細に置き換えてください。 詳細な手順を表示するタブを選択してください。

CoreWeave

このセクションは、専用クラウド または セルフマネージド でのチームレベル BYOB にのみ関連します。インスタンス レベルの BYOB または マルチテナントクラウド の場合は、W&B を設定 に進んでください。

次の形式を使用して、完全なバケットパスを確認します。山かっこ (<>) で囲まれたプレースホルダーを、バケットの値に置き換えてください。

バケット形式:

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

cwobject.com の HTTPS エンドポイントがサポートされます。TLS 1.3 が必須です。その他の CoreWeave エンドポイントをご希望の場合は、サポート までお問い合わせください。

AWS

バケット形式:

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

このアドレスでは、region パラメーターは必須です。ただし、W&B インスタンスとストレージバケットの両方が AWS にデプロイされており、W&B インスタンスの AWS_REGION がバケットの AWS S3 リージョンと一致している場合は除きます。

Google Cloud

バケット形式:

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

Azure

バケット形式:

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

S3-compatible

バケット形式:

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

このアドレスでは、region パラメーターは必須です。

このセクションは、MinIO Enterprise (AIStor) や、オンプレミスでホストされるその他のエンタープライズグレードの S3-compatible ソリューションなど、S3 以外でホストされる S3-compatible ストレージバケットを対象としています。AWS S3 でホストされるストレージバケットについては、代わりに AWS タブを参照してください。

MinIO Open Source は、アクティブな開発や事前コンパイル済みバイナリーの提供がない maintenance mode です。本番デプロイでは、エンタープライズグレードの S3-compatible ソリューションを使用してください。

オプションで S3-compatible モードを備えたクラウドネイティブのストレージバケットでは、可能であればクラウドネイティブのプロトコル指定子を使用してください。たとえば、CoreWeave バケットには s3:// ではなく cw:// を使用します。

ストレージアドレスを確認したら、チームレベル BYOB を設定 できます。

​

W&B を設定する

バケットをプロビジョニングし、そのアドレスを確認したら、インスタンス レベルまたはチームレベルで BYOB を設定できます。

ストレージバケットの構成は慎重に計画してください。W&B 用のストレージバケットを設定した後で、そのデータを別のバケットに移行するのは複雑で、W&B の支援が必要です。これは、専用クラウドおよびセルフマネージドのストレージだけでなく、マルチテナントクラウド のチームレベルのストレージにも当てはまります。ご不明な点は、サポートまでお問い合わせください。

​

インスタンス レベルの BYOB

インスタンス レベルで CoreWeave AI Object Storage を使用する場合は、この手順には従わず、W&B サポート にお問い合わせください。セルフサービスでの設定はまだサポートされていません。

専用クラウド の場合: バケットの詳細を担当の W&B チームに共有してください。担当チームが専用クラウド インスタンスを設定します。

セルフマネージド の場合は、W&B App を使用してインスタンス レベルの BYOB を設定できます。

1. admin ロールを持つユーザーとして W&B にログインします。
2. 上部のユーザーアイコンをクリックし、System Console をクリックします。
3. Settings > System Connections にアクセスします。
4. Bucket Storage セクションで、Identity フィールドに指定されたアイデンティティに、新しいバケットへのアクセス権が付与されていることを確認します。
5. Provider を選択します。
6. Bucket Name を入力します。
7. 必要に応じて、新しいバケットで使用する Path を入力します。
8. Save をクリックします。

​

チームレベル BYOB

W&B App でチームを作成するとき、または SCIM API (storageBucket を省略可能な POST Groups) を使用するときに、チームレベル BYOB を設定できます。選択肢は 2 つあります。

• 既存のバケットを使用する: まず、そのバケットのストレージの場所を特定する必要があります。
• 新しいバケットを作成する (マルチテナントクラウド のみ) : チームの作成時に、W&B はクラウドプロバイダ内にバケットを自動的に作成できます。これは CoreWeave、AWS、Google Cloud でサポートされます。

• チームの作成後、そのストレージは変更できません。
• インスタンス レベルの BYOB については、代わりに Instance level BYOB を参照してください。
• チーム用に CoreWeave ストレージを設定する予定がある場合は、CoreWeave requirements を確認し、バケットが CoreWeave で正しく設定されていることの確認と、チームの設定内容の検証のために サポート に連絡してください。チーム作成後はストレージの詳細を変更できないためです。

続行するには、デプロイ タイプを選択してください。

専用クラウド / セルフホスト

1. 専用クラウド: チームでストレージバケットを使用するには、この後の手順を進める前に、アカウントチームがそのバケットパスをインスタンスのサポート対象ファイルストアに追加できるよう、必ずバケットパスをアカウントチームに共有してください。

2. セルフマネージド: チームでストレージバケットを使用するには、この後の手順を進める前に、必ずバケットパスを GORILLA_SUPPORTED_FILE_STORES 環境変数に追加し、その後 W&B を再起動してください。

3. admin ロールを持つユーザーとして W&B にログインし、左上のアイコンをクリックして左側のナビゲーションを開き、Create a team to collaborate をクリックします。

4. チーム名を入力します。

5. Storage Type を External storage に設定します。

   チームストレージとしてインスタンス レベルのストレージを使用する場合 (内部か外部かを問わず) 、インスタンス レベルのバケットが BYOB 用に設定されていても、Storage Type は Internal のままにしてください。チーム用に別の外部ストレージを使用する場合は、チームの Storage Type を External に設定し、次の手順でバケットの詳細を設定してください。

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 または セルフマネージドの 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 がバケットへのアクセス時にエラーを検出した場合、または無効な設定を検出した場合は、ページ下部にエラーまたは警告が表示されます。問題がなければ、チームが作成されます。

マルチテナントクラウド

1. 以前に新しいチームの作成を開始し、W&B の組織 ID を確認したブラウザーウィンドウに切り替えます。そうでない場合は、admin ロールを持つユーザーとして W&B にログインし、左上のアイコンをクリックして左側のナビゲーションを開き、Create a team to collaborate をクリックします。

2. チーム名を入力します。

3. Storage Type を External storage に設定します。

4. Bucket location をクリックします。

5. 既存のバケットを使用する場合は、リストから選択します。

6. 新しいバケットを作成するには、下部の Add bucket をクリックしてから、次の手順を実行します。

   1. Cloud provider をクリックし、CoreWeave、AWS、または Google Cloud を選択します。
   2. バケットの詳細を入力します。
      • Name: バケット名を入力します。
      • Path (optional): バケット内で使用するサブパスを入力します。
   3. 選択したクラウドプロバイダーの追加の接続設定を指定します。
      • CoreWeave: 追加設定は不要です。
      • AWS: 必要に応じて、暗号化用の KMS key ARN を指定します。
      • Google Cloud: 追加設定は不要です。
   Create team をクリックすると、W&B は指定した設定でクラウドプロバイダー内にバケットを自動的に作成します。

7. チームにメンバーを招待します。Invite team members に、メールアドレスをカンマ区切りで入力します。チームの作成後にメンバーを招待することもできます。

8. Create team をクリックします。

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 ドキュメントの Configuring cross-origin resource sharing (CORS) を参照してください。
  • AllowedMethods には、GET、PUT、HEAD の各 method を含める必要があります。
  • ExposeHeaders には ETag を含める必要があります。
  • W&B のフロントエンドドメインを、CORS ポリシーの AllowedOrigins に含める必要があります。このページで提供している CORS ポリシーの例では、* を使用してすべてのドメインを含めています。
• LOTA エンドポイントの問題
  • W&B から 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 のバケットでソフト削除が有効になっていることを確認してください。詳細は、バケットのソフト削除ポリシーを編集するを参照してください。