メインコンテンツへスキップ
このガイドは、すべての 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 つあります。
ScopeDescription
インスタンス レベル専用クラウド と セルフマネージド では、組織またはインスタンス内で必要な権限を持つ任意のユーザーが、インスタンスのストレージバケットに保存されたファイルにアクセスできます。マルチテナントクラウド には適用されません。
チームレベル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がサポートされます。
マルチテナントクラウド該当なし✓1CoreWeave 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 を含むストレージバケットをプロビジョニングできます。続行するには、タブを選択してください。
要件:
  • 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>:
  7. 専用クラウド: 追加のstepを完了するには、サポートまでお問い合わせください。
  8. セルフマネージド: W&B のデプロイを更新して、環境変数 GORILLA_SUPPORTED_FILE_STORES を厳密に文字列 cw:// に設定し、W&B を再起動します。そうしないと、チームストレージの設定時に CoreWeave が選択肢として表示されません。
次に、W&Bを設定します。
次に、ストレージアドレスを確認します。

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

このセクションでは、W&B Team を BYOB ストレージバケットに接続するための構文を説明します。例では、山かっこ (<>) で囲まれたプレースホルダーの値を、お使いのバケットの詳細に置き換えてください。 詳細な手順を表示するタブを選択してください。
このセクションは、専用クラウド または セルフマネージド でのチームレベル BYOB にのみ関連します。インスタンス レベルの BYOB または マルチテナントクラウド の場合は、W&B を設定 に進んでください。次の形式を使用して、完全なバケットパスを確認します。山かっこ (<>) で囲まれたプレースホルダーを、バケットの値に置き換えてください。バケット形式:
cw://<accessKey>:<secretAccessKey>@cwobject.com/<bucketName>?tls=true
cwobject.com の HTTPS エンドポイントがサポートされます。TLS 1.3 が必須です。その他の CoreWeave エンドポイントをご希望の場合は、サポート までお問い合わせください。
ストレージアドレスを確認したら、チームレベル 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 がバケットへのアクセス時にエラーを検出した場合、または無効な設定を検出した場合は、ページ下部にエラーまたは警告が表示されます。問題がなければ、チームが作成されます。

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

​
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 エンドポイントの問題
  • アクセスキーと権限エラー
    • 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 への接続に関する問題をトラブルシューティングする方法を説明します。