Bring your own bucket (BYOB)

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

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

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

このページは W&B Platform のセキュアストレージコネクタ (BYOB) に関する内容であり、Weave には適用されません。ご自身のクラウド bucket に保存されている画像や動画を、バイトデータを Weave に取り込むことなく Weave で表示する方法については、Weave BYOB リファレンスをご覧ください。

概要

Bring your own bucket (BYOB) を使用すると、W&B のアーティファクトやその他の機密データを、お客様自身のクラウドまたはオンプレミスのインフラストラクチャーに保存できます。専用クラウドまたはマルチテナントクラウドでは、W&B はお客様のバケットに保存されたデータを W&B 管理のインフラストラクチャーにコピーしません。このページは、データガバナンス、データレジデンシー、またはコンプライアンス要件を満たすために、アーティファクトストレージの所有権を維持する必要がある W&B 管理者およびプラットフォームエンジニアを対象としています。

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

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

BYOB 機能を使用すると、W&B は一部の種類のデータを W&B の中央データベースに保存し、それ以外の種類のデータはお使いのバケットに保存します。以下の一覧では、どのデータが W&B 管理のインフラストラクチャーに保持され、どのデータが W&B によってお客様自身のストレージに書き込まれるかを確認できます。

データベース

W&B の中央データベースには、次のデータが保存されます。

Users、Teams、アーティファクト、Experiments、Projects のメタデータ。
Reports。
Experiments のログ。
システムメトリクス。
コンソールログ。

バケット

ストレージバケットには、次のデータが保存されます:

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

バケットのスコープ

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

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

この設計は、組織のニーズに応じたさまざまなストレージトポロジをサポートします。たとえば、次のようなものがあります。

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

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

利用可否マトリクス

開始する前に、お使いのデプロイメントタイプとストレージプロバイダーでBYOBが利用可能であることを確認してください。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がサポートされます。
マルチテナントクラウド	該当なし	✓¹	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 を含むストレージバケットをプロビジョニングできます。プロビジョニングにより、W&B が書き込むバケットが作成され、W&B プラットフォームに、お客様に代わって事前署名付き URL を生成するために必要な権限が付与されます。続行するには、タブを選択してください。

CoreWeave
AWS
Google Cloud
Azure
S3互換

要件:

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を参照してください。

Multi-tenant Cloud: バケットポリシーに必要な組織IDを取得します。
1. W&B App にログインします。
2. 左側のナビゲーションで、Create a new team をクリックします。
3. 開いたドロワーで、Invite team members の上にある W&B 組織 ID をコピーします。
4. このページは開いたままにしておきます。後で W&B を設定する際に使用します。
専用クラウド / セルフマネージド: バケットポリシーに必要なカスタマーネームスペースを取得します。
1. W&B App で、ユーザーのプロフィールアイコンをクリックし、System Console をクリックします。
2. Authentication タブをクリックします。
3. ページ下部で、Customer Namespace の値をコピーします。bucket ポリシーの設定で使用するため、この値は控えておいてください。
4. System Console は閉じてかまいません。
CoreWeave で、任意の名前のバケットを、希望する CoreWeave のアベイラビリティゾーンに作成します。必要に応じて、すべての W&B ファイルのサブパスとして W&B が使用するフォルダーも作成します。バケット名、アベイラビリティゾーン、API アクセスキー、シークレットキー、サブパスを控えておいてください。

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

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

CoreWeave のストレージは S3 互換です。CORS の詳細については、AWS ドキュメントの Configuring cross-origin resource sharing (CORS) を参照してください。

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" で始まる条項は、組織内のユーザーにそのバケットへの直接アクセスを許可します。このアクセスが不要な場合は、ポリシーからこの条項を省略できます。

バケットポリシー内のプレースホルダーを置き換えます:
- <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 のカスタマーネームスペース。
専用クラウド: 追加のstepを完了するには、サポートまでお問い合わせください。
セルフマネージド: 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 または専用クラウドを使用している場合は、<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を控えておいてください。
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 ドキュメントのバケットを作成するを参照してください。

GCS バケットをプロビジョニングします。 Google Cloud project で GCS バケットをプロビジョニングするには、次の step に従います。
1. 任意の名前で GCS バケットを作成します。必要に応じて、すべての W&B ファイルの保存先となるサブパスとして設定できるフォルダも作成します。
2. 暗号化タイプを Google-managed に設定します。
3. ソフト削除を有効にします。バケットのソフト削除ポリシーを編集するを参照してください。
4. gsutil で CORS ポリシーを設定します。これは UI では実行できません。
  1. ローカルに cors-policy.json という名前の file を作成します。
  2. 次の CORS ポリシーをその file にコピーして保存します。
    [ { "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 または専用クラウドを使用している場合は、W&B プラットフォームに関連付けられている Google Cloud サービスアカウントに storage.admin ロールを付与します。W&B がバケットの CORS 設定や、オブジェクトのバージョン管理が有効かどうかといった属性を確認するには、このロールが必要です。サービスアカウントに storage.admin ロールがない場合、これらの確認は HTTP 403 エラーになります。
- Multi-tenant Cloud の場合、アカウントは次のとおりです: wandb-integration@wandb-production.iam.gserviceaccount.com
- 専用クラウドの場合、アカウントは次のとおりです: deploy@wandb-production.iam.gserviceaccount.com
バケット名を記録しておいてください。次に、BYOB 向けに W&B を設定します。

詳細については、Azure のドキュメントの Create a blob storage container を参照してください。インスタンスレベルの BYOB:

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 の履歴を参照できなくなる可能性があります。
認証方式を選択します。
- ストレージアカウントキー: ストレージアカウントのアクセスキーを生成し、そのキーとストレージアカウント名を控えておきます。専用クラウドをご利用の組織の場合は、安全な共有手段を使用してこれらの値を W&B の account team に共有してください。
- ワークロードアイデンティティ: Azure マネージドアイデンティティにストレージアカウントへのアクセスを付与し、それを使用するように W&B を設定します。ストレージアカウントキーを共有する必要はありません。デプロイメントタイプに応じたワークロードアイデンティティの手順に従ってください。

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

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

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

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

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

バケットをプロビジョニングしたら、W&B がその場所の特定と認証に使用するストレージアドレスが必要です。このセクションでは、W&B Team を BYOB ストレージバケットに接続するための構文を説明します。例では、山かっこ (<>) で囲まれたプレースホルダーの値を、お使いのバケットの詳細に置き換えてください。詳細な手順を表示するタブを選択してください。

CoreWeave
AWS
Google Cloud
Azure
S3-compatible

このセクションは、専用クラウド または セルフマネージド でのチームレベル BYOB にのみ関連します。インスタンスレベルの BYOB またはマルチテナントクラウドの場合は、W&B を設定に進んでください。次の形式を使用して、完全なバケットパスを確認します。山かっこ (<>) で囲まれたプレースホルダーを、バケットの値に置き換えてください。バケット形式:

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

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

バケット形式:

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

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

バケット形式:

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 Open Source は、アクティブな開発や事前コンパイル済みバイナリーの提供がない maintenance mode です。本番デプロイでは、エンタープライズグレードの S3互換ソリューションを使用してください。オプションで S3互換モードを備えたクラウドネイティブのストレージバケットでは、可能であればクラウドネイティブのプロトコル指定子を使用してください。たとえば、CoreWeave バケットには s3:// ではなく cw:// を使用します。

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

W&B を設定する

バケットをプロビジョニングし、そのアドレスを確認したら、インスタンスレベルまたはチームレベルで BYOB を設定できます。この最後の手順では、アーティファクト、run ファイル、その他の大きなオブジェクトの保存先をお使いのバケットにルーティングするよう W&B に指示します。

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

インスタンスレベルの BYOB

インスタンスレベルで CoreWeave AI オブジェクトストレージを使用する場合は、以下の手順ではなく W&B サポートにお問い合わせください。セルフサービスでの設定はまだサポートされていません。

専用クラウド の場合: バケットの詳細を W&B チームに共有してください。W&B チームがインスタンスを設定します。Azure ワークロードアイデンティティを使用する場合は、ストレージアカウントへのアクセスを許可し、ストレージアカウント名、コンテナー名、および必要に応じてパスをお知らせください。 セルフマネージド の場合は、W&B System Console でインスタンスレベルの BYOB を設定します。Azure ワークロードアイデンティティを使用する場合は、先にアイデンティティのセットアップを完了してください。

admin ロールを持つユーザーとして W&B にログインします。
上部のユーザーアイコンをクリックし、System Console をクリックします。
Settings > System Connections にアクセスします。
Bucket Storage で Provider を選択し、バケットの詳細を入力します。Azure の場合は Azure Blob Storage (az) を選択し、Storage account と Blob container をそれぞれ入力します。
任意: 新しいバケットで使用する Path を入力します。
選択したプロバイダーのアイデンティティまたは認証情報がバケットにアクセスできることを確認します。Azure の場合は、Authentication の方式を選択します。
- Storage account key: Storage account key を入力します。
- Workload identity (user-delegation SAS): デプロイメント管理者が設定したアイデンティティを使用します。このオプションが表示されない場合は、アイデンティティのセットアップを完了してください。
Save をクリックします。

保存すると、W&B はインスタンスレベルで、新しいアーティファクトと run ファイルのデフォルトのストレージ送信先として、設定したバケットを使用します。設定を編集できない場合は、デプロイメント管理者にお問い合わせください。

Azure ワークロードアイデンティティを設定する

ワークロードアイデンティティを使用すると、ストレージアカウントキーなしで W&B が Azure バケットにアクセスできます。設定手順を確認するには、デプロイメントタイプを選択してください。

専用クラウド
セルフマネージド

デプロイメントは W&B が設定します。お客様は Azure ストレージアカウントへのアクセスを設定します。

ストレージアカウントのテナント ID を添えて W&B チームに連絡し、使用するマネージド ID を確認します。
その ID がお客様の Azure テナント内にある場合は、そのプリンシパル ID を以下のロール割り当てに使用します。テナント外にある場合は、お客様のテナント内でマネージド ID を作成または選択し、W&B から提供される issuer、subject、オーディエンスの値を使用してフェデレーション認証情報を設定します。マネージド ID から別のテナント内のストレージに直接アクセスすることはできません。
BYOB ストレージアカウントに対して、ストレージアカウントスコープで ID のプリンシパルに Reader と Storage Blob Data Contributor を付与します。
ストレージアカウント名、コンテナー名、パス (任意) 、および ID のテナント ID とクライアント ID を W&B チームに共有します。

W&B が接続を設定した後、run ファイルまたはアーティファクトのアップロードとダウンロードを実行して、アクセスできることを確認します。

デプロイメント管理者として、Azure と Kubernetes でワークロードアイデンティティを設定し、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 ワークロードアイデンティティを有効にします。Azure Kubernetes Service (AKS) の場合は、Configure Microsoft Entra Workload ID に従ってください。
Azure マネージド ID を作成または選択し、そのテナント ID、クライアント ID、プリンシパル ID を記録します。BYOB ストレージアカウントに対して、ストレージアカウントスコープでそのプリンシパルに Reader と Storage Blob Data Contributor を付与します。
Helm values で global.azureStorageIdentity に ID のテナント ID、クライアント ID、プリンシパル ID を設定します。ストレージにアクセスする Kubernetes サービスアカウントには、フェデレーションと azure.workload.identity/client-id アノテーションを設定します。Helm の設定の詳細については、Azure workload identity configuration を参照してください。
Console の手順に従ってワークロードアイデンティティを選択し、バケット設定を保存します。run ファイルまたはアーティファクトのアップロードとダウンロードを実行して、アクセスできることを確認します。

チームレベル BYOB

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

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

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

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

専用クラウド / セルフホスト
マルチテナントクラウド

専用クラウド: チームでストレージバケットを使用するには、この後の手順を進める前に、アカウントチームがそのバケットパスをインスタンスのサポート対象ファイルストアに追加できるよう、必ずバケットパスをアカウントチームに共有してください。
セルフマネージド: チームでストレージバケットを使用するには、この後の手順を進める前に、必ずバケットパスを 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 またはセルフマネージドの 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 がバケットへのアクセス時にエラーを検出した場合、または無効な設定を検出した場合は、ページ下部にエラーまたは警告が表示されます。問題がなければ、W&B がチームを作成します。

以前に新しいチームの作成を開始し、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 (optional): バケット内で使用するサブパスを入力します。
3. 選択したクラウドプロバイダーの追加の接続設定を指定します。
  - CoreWeave: 追加設定は不要です。
  - AWS: 必要に応じて、暗号化用の KMS key ARN を指定します。
  - Google Cloud: 追加設定は不要です。
Create team をクリックすると、W&B は指定した設定でクラウドプロバイダー内にバケットを自動的に作成します。
チームにメンバーを招待します。Invite team members に、メールアドレスをカンマ区切りで入力します。チームの作成後にメンバーを招待することもできます。
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 メソッドを含める必要があります。
- ExposeHeaders には ETag を含める必要があります。
- CORS ポリシーの AllowedOrigins には、W&B のフロントエンドドメインを含める必要があります。このページに掲載されている CORS ポリシーの例では、* を使用してすべてのドメインを含めています。
LOTA endpoint の問題
- W&B は現時点では LOTA endpoints への接続をサポートしていません。ご要望があれば、サポートにお問い合わせください。
アクセスキーおよび権限エラー
- CoreWeave API アクセスキーの有効期限が切れていないことを確認してください。
- CoreWeave API アクセスキーとシークレットキーに、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 のバケットでソフト削除が有効になっていることを確認してください。詳細は、バケットのソフト削除ポリシーを編集するを参照してください。

Weights & Biases

CoreWeave 提供

プラットフォームの詳細

リソース

概要

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

データベース

バケット

バケットのスコープ

利用可否マトリクス

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

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

W&B を設定する

インスタンスレベルの BYOB

Azure ワークロードアイデンティティを設定する

チームレベル BYOB

トラブルシューティング

CoreWeave

Google Cloud

​概要

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

​データベース

​バケット

​バケットのスコープ

​利用可否マトリクス

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

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

​W&B を設定する

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

​Azure ワークロード アイデンティティを設定する

​チームレベル BYOB

​トラブルシューティング

​CoreWeave

​Google Cloud

概要

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

データベース

バケット

バケットのスコープ

利用可否マトリクス

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

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

W&B を設定する

インスタンスレベルの BYOB

Azure ワークロードアイデンティティを設定する

チームレベル BYOB

トラブルシューティング

CoreWeave

Google Cloud