W&B プラットフォーム

• 1: デプロイメントオプション
• 1.1: W&B マルチテナント SaaS を使用する
• 1.2: 自己管理
• 1.2.1: リファレンス アーキテクチャー
• 1.2.2: W&B サーバーを Kubernetes で実行する
• 1.2.2.1: エアギャップインスタンス用の Kubernetes オペレーター
• 1.2.3: パブリック クラウドにインストールする
• 1.2.3.1: AWS に W&B プラットフォーム をデプロイ
• 1.2.3.2: W&B プラットフォームを GCP にデプロイする
• 1.2.3.3: Azureで W&B プラットフォーム を展開する
• 1.2.4: W&B プラットフォームをオンプレミスで展開する
• 1.2.5: W&B ライセンスと バージョン を更新する
• 1.3: 専用クラウド
• 1.3.1: 専用クラウドがサポートされている地域
• 1.3.2: 専用クラウドからデータをエクスポートする
• 2: アイデンティティとアクセス管理 (IAM)
• 2.1: 認証
• 2.1.1: SDK でフェデレーテッドアイデンティティを使用する
• 2.1.2: SSO を LDAP で設定
• 2.1.3: SSO を OIDC で設定
• 2.1.4: ワークフローを自動化するためにサービスアカウントを使用する
• 2.2: アクセス管理
• 2.2.1: あなたの組織を管理する
• 2.2.2: プロジェクトのアクセス制御を管理する
• 2.3: ユーザーとチームの管理を自動化する
• 2.4: ユーザー、グループ、およびロールを SCIM で管理する
• 2.5: 高度な IAM 設定
• 3: データセキュリティ
• 3.1: 独自の バケット を持ち込む (BYOB)
• 3.2: BYOB に事前署名済みの URL を使用してアクセスする
• 3.3: 専用クラウドのための IP 許可リストを設定する
• 3.4: 専用クラウドへのプライベート接続を設定します
• 3.5: 専用クラウドでのデータ暗号化
• 4: プライバシー設定を設定する
• 5: 監視と利用状況
• 5.1: ユーザーのアクティビティを監査ログで追跡する
• 5.2: Prometheus モニタリングを使用する
• 5.3: Slack アラートの設定
• 5.4: 組織のダッシュボードを表示する
• 6: SMTP を設定
• 7: 環境変数を設定する
• 8: W&B サーバーのリリースプロセス

1 - デプロイメントオプション

1.1 - W&B マルチテナント SaaS を使用する

W&B マルチテナントクラウドは、W&B の Google Cloud Platform (GCP) アカウントに展開されている完全管理型のプラットフォームで、GPC の北米リージョンで利用可能です。W&B マルチテナントクラウドは、GCP の自動スケーリングを利用しており、トラフィックの増減に応じて適切にプラットフォームがスケールします。

データのセキュリティ

非エンタープライズプランのユーザーの場合、すべてのデータは共有クラウドストレージにのみ保存され、共有クラウドコンピューティングサービスで処理されます。料金プランによっては、保存容量制限が適用される場合があります。

エンタープライズプランのユーザーは、セキュアストレージコネクタを使用して独自のバケット（BYOB）をチームレベルで使用することができ、モデルやデータセットなどのファイルを保存できます。複数のチームに対して単一のバケットを設定することも、W&B Teams の異なるために個別のバケットを使用することも可能です。チームにセキュアストレージコネクタを設定しない場合、データは共有クラウドストレージに保存されます。

アイデンティティとアクセス管理 (IAM)

エンタープライズプランの場合、W&B Organization における安全な認証と効果的な権限付与のためのアイデンティティとアクセス管理機能を使用できます。マルチテナントクラウドで利用可能な IAM の機能は以下の通りです：

• OIDC または SAML を使用した SSO 認証。組織で SSO を設定したい場合は、W&B チームまたはサポートにお問い合わせください。
• 組織の範囲およびチーム内で適切なユーザーロールを設定します。
• プロジェクトを制限されたプロジェクトとして定義し、誰がそのプロジェクトを見る、編集する、または W&B Runs を送信できるかを制限します。制限付きプロジェクトを参照。

モニター

組織の管理者は、アカウントビューの Billing タブから使用状況と請求を管理できます。マルチテナントクラウドで共有クラウドストレージを使用している場合、管理者は組織内の異なるチーム間でストレージの使用を最適化することができます。

メンテナンス

W&B マルチテナントクラウドはマルチテナントの完全管理型プラットフォームです。W&B によって管理されているため、W&B プラットフォームのプロビジョニングや維持にかかるオーバーヘッドやコストは発生しません。

コンプライアンス

マルチテナントクラウドのセキュリティ管理は、定期的に内部および外部の監査を受けています。W&B セキュリティポータルを参照して、SOC2 レポートやその他のセキュリティおよびコンプライアンスに関する文書をリクエストしてください。

次のステップ

非エンタープライズ機能を探している場合は、マルチテナントクラウドに直接アクセスしてください。エンタープライズプランを開始するには、このフォームを提出してください。

1.2 - 自己管理

セルフ管理クラウドまたはオンプレインフラストラクチャーを使用

あなたの AWS, GCP, または Azure クラウドアカウント または オンプレミスのインフラストラクチャー に W&B Server をデプロイしてください。

あなたの IT/DevOps/MLOps チームが、デプロイメントのプロビジョニング、アップグレードの管理、セルフマネージド W&B Server インスタンスの継続的な保守を担当します。

セルフ管理クラウドアカウントに W&B Server をデプロイする

W&B は、公式の W&B Terraform スクリプトを使用して、AWS、GCP、または Azure のクラウドアカウントに W&B Server をデプロイすることを推奨します。

AWS、GCP または Azure に W&B Server を設定する方法については、各クラウドプロバイダーのドキュメントを参照してください。

オンプレインフラストラクチャーに W&B Server をデプロイする

W&B Server をオンプレインフラストラクチャーに設定するには、いくつかのインフラストラクチャーコンポーネントを設定する必要があります。これらのコンポーネントには、以下が含まれますが、それに限定されません：

• (強く推奨) Kubernetes クラスター
• MySQL 8 データベースクラスター
• Amazon S3 互換オブジェクトストレージ
• Redis キャッシュクラスター

オンプレインフラストラクチャーに W&B Server をインストールする方法については、Install on on-prem infrastructure を参照してください。W&B はさまざまなコンポーネントに関する推奨事項を提供し、インストールプロセスをガイドします。

カスタムクラウドプラットフォームに W&B Server をデプロイする

AWS、GCP、または Azure ではないクラウドプラットフォームに W&B Server をデプロイすることができます。これには、オンプレインフラストラクチャー にデプロイする場合と同様の要件があります。

W&B Server ライセンスの取得

W&B server の設定を完了するには、W&B のトライアルライセンスが必要です。 Deploy Manager を開いて、無料のトライアルライセンスを生成してください。

URL は Get a License for W&B Local フォームにリダイレクトします。次の情報を提供してください:

1. Choose Platform ステップでデプロイタイプを選択します。
2. Basic Information ステップでライセンスの所有者を選択するか、新しい組織を追加します。
3. Get a License ステップでインスタンスの名前を入力し、任意で Description フィールドに説明を提供します。
4. Generate License Key ボタンを選択します。

インスタンスに関連付けられたライセンスとともにデプロイメントの概要を示すページが表示されます。

1.2.1 - リファレンス アーキテクチャー

このページでは、Weights & Biasesデプロイメントのためのリファレンスアーキテクチャについて説明し、プラットフォームのプロダクションデプロイメントをサポートするための推奨インフラストラクチャとリソースを示します。

Weights & Biases（W&B）のデプロイメント環境に応じて、デプロイメントのレジリエンスを高めるためのさまざまなサービスが利用できます。

たとえば、主要なクラウドプロバイダは、データベースの設定、保守、高可用性、レジリエンスの複雑さを軽減する堅牢な管理データベースサービスを提供しています。

このリファレンスアーキテクチャは、一般的なデプロイメントシナリオに対応し、クラウドベンダーのサービスとW&Bデプロイメントを統合する方法を示します。

始める前に

プロダクション環境でアプリケーションを実行するには、それぞれの課題が伴い、W&Bも例外ではありません。プロセスを簡素化しようとしていますが、個別のアーキテクチャや設計の決定に応じて、ある程度の複雑さが発生する場合があります。通常、プロダクションデプロイメントの管理には、ハードウェア、オペレーティングシステム、ネットワーキング、ストレージ、セキュリティ、W&Bプラットフォーム自体、およびその他の依存関係を含むさまざまなコンポーネントの監督が含まれます。この責任は、環境の初期セットアップとその継続的な保守の両方に及びます。

W&Bを自社で管理するアプローチが、あなたのチームが抱える特定の要件に適しているかどうかを慎重に検討してください。

プロダクションレベルのアプリケーションを実行および維持する方法についての強力な理解は、自己管理型のW&Bをデプロイする前の重要な前提条件です。あなたのチームが支援を必要とする場合、弊社のプロフェッショナルサービスチームとパートナーが、実装と最適化のサポートを提供します。

自分で管理する代わりに、W&Bの管理されたソリューションについて詳しく知るには、W&BマルチテナントクラウドおよびW&B専用クラウドを参照してください。

インフラストラクチャ

アプリケーション層

アプリケーション層は、ノード障害に対するレジリエンスを備えたマルチノードKubernetesクラスターで構成されます。Kubernetesクラスターは、W&Bのポッドを実行および管理します。

ストレージ層

ストレージ層は、MySQLデータベースとオブジェクトストレージで構成されます。MySQLデータベースはメタデータを保存し、オブジェクトストレージはモデルやデータセットなどのアーティファクトを保存します。

インフラストラクチャの要件

Kubernetes

W&Bサーバーアプリケーションは、複数のポッドをデプロイするKubernetesオペレーターとしてデプロイされます。このため、W&Bには以下の要件を備えたKubernetesクラスターが必要です：

• 完全に設定され機能するインフラストラクチャコントローラ。
• 永続ボリュームをプロビジョニングする能力。

MySQL

W&BはメタデータをMySQLデータベースに保存します。データベースのパフォーマンスとストレージの要件は、モデルパラメータの形状と関連するメタデータに依存します。たとえば、トレーニングランをより多くトラッキングするにつれてデータベースはサイズが成長し、ランテーブル、ユーザーワークスペース、およびレポートにおけるクエリに基づいてデータベースの負荷は増加します。

自己管理型のMySQLデータベースをデプロイするときは、以下の点を考慮してください：

• バックアップ. データベースを別の施設に周期的にバックアップするべきです。W&Bは、少なくとも1週間の保持で、毎日のバックアップを推奨します。
• パフォーマンス. サーバーが稼働しているディスクは高速であるべきです。W&Bは、データベースをSSDまたは加速されたNASで実行することを推奨しています。
• モニタリング. データベースは負荷に対して監視されるべきです。システムのCPU使用率が5分以上持続的に40%を超える場合、サーバーがリソース不足であることを示している可能性があります。
• 可用性. 可用性と耐久性の要件によって、プライマリサーバーからリアルタイムですべての更新をストリーミングし、プライマリサーバーがクラッシュするか破損するイベントに備えてフェイルオーバーできるホットスタンバイを別のマシンで設定することを検討するかもしれません。

オブジェクトストレージ

W&Bは、Pre-signed URLとCORSサポートのあるオブジェクトストレージを必要とし、次のいずれかにデプロイします：

• Amazon S3
• Azure Cloud Storage
• Google Cloud Storage
• Amazon S3互換のストレージサービス

バージョン

ネットワーク

ネットワークデプロイメントの際、インストール中およびランタイム中にこれらのエンドポイントへのエージェントのアクセスが必要です:

• https://deploy.wandb.ai
• https://charts.wandb.ai
• https://docker.io
• https://quay.io
• https://gcr.io

エアギャップデプロイメントについて知るには、エアギャップインスタンス用Kubernetesオペレーターを参照してください。 トレーニングインフラストラクチャと実験のニーズを追跡する各システムにおいて、W&Bおよびオブジェクトストレージへのアクセスが必要です。

DNS

W&Bデプロイメントの完全修飾ドメイン名（FQDN）は、Aレコードを使用してインフラストラクチャのIPアドレスに解決する必要があります。

SSL/TLS

W&Bは、クライアントとサーバー間の安全な通信のために、有効な署名されたSSL/TLS証明書を必要とします。SSL/TLSの終端は、インフラストラクチャで行われる必要があります。W&Bサーバーアプリケーションは、SSLまたはTLS接続を終了しません。

ご注意: W&Bは自己署名証明書およびカスタムCAの使用を推奨していません。

対応するCPUアーキテクチャ

W&BはIntel（x86）CPUアーキテクチャ上で実行されます。ARMはサポートされていません。

インフラストラクチャのプロビジョニング

Terraformはプロダクション用にW&Bをデプロイするために推奨される方法です。Terraformを使用すると、必要なリソース、それらの他のリソースへの参照、および依存関係を定義できます。W&Bは主要なクラウドプロバイダ向けにTerraformモジュールを提供しています。詳細については、自己管理型クラウドアカウントでW&Bサーバーをデプロイする方法を参照してください。

サイズ調整

デプロイメントを計画する際の出発点として、以下の一般的なガイドラインを使用してください。W&Bは、新しいデプロイメントのすべてのコンポーネントを厳密に監視し、観察された使用パターンに基づいて調整を行うことを推奨します。時間をかけてプロダクションデプロイメントを監視し、最適なパフォーマンスを維持するために必要に応じて調整を行い続けてください。

Modelsのみ

Kubernetes

数字はKubernetesワーカーノードごとです。

MySQL

数字はMySQLノードごとです。

Weaveのみ

Kubernetes

数字はKubernetesワーカーノードごとです。

MySQL

数字はMySQLノードごとです。

ModelsとWeave

Kubernetes

数字はKubernetesワーカーノードごとです。

MySQL

数字はMySQLノードごとです。

クラウドプロバイダーインスタンスの推奨

サービス

マシンタイプ

これらの推奨事項は、クラウドインフラストラクチャ内でのW&Bの自己管理型デプロイメントの各ノードに適用されます。

AWS

GCP

Azure

1.2.2 - W&B サーバーを Kubernetes で実行する

W&B Kubernetes オペレーター

W&B Kubernetes オペレーターを使用して、Kubernetes 上の W&B Server デプロイメントを展開、管理、トラブルシューティング、およびスケーリングを簡素化します。このオペレーターは、W&B インスタンス用のスマートアシスタントと考えることができます。

W&B Server のアーキテクチャと設計は、AI 開発者のツール提供能力を拡張し、高性能でより優れたスケーラビリティと簡易な管理を提供するために進化し続けています。この進化は、コンピューティングサービス、関連ストレージ、およびそれらの接続性に適用されます。デプロイメントタイプ全体での継続的な更新と改善を促進するために、W&B は Kubernetes オペレーターを使用しています。

Kubernetes オペレーターに関する詳細情報は、Kubernetes のドキュメントにあるオペレーターパターンを参照してください。

アーキテクチャの変更理由

歴史的に、W&B アプリケーションは Kubernetes クラスター内の単一デプロイメントおよびポッド、または単一の Docker コンテナとしてデプロイされていました。W&B は引き続き、データベースおよびオブジェクトストアを外部化することを推奨しています。データベースとオブジェクトストアの外部化は、アプリケーションの状態を切り離します。

アプリケーションが成長するにつれて、モノリシックコンテナから分散システム（マイクロサービス）へ進化するニーズが明らかになりました。この変更はバックエンドロジックの処理を容易にし、組み込みの Kubernetes インフラストラクチャ能力をスムーズに導入します。分散システムはまた、新しいサービスの展開をサポートし、W&B が依存する追加の機能を提供します。

2024年以前、Kubernetes 関連の変更は、terraform-kubernetes-wandb Terraform モジュールを手動で更新する必要がありました。Terraform モジュールを更新することで、クラウドプロバイダー間の互換性が確保され、必要な Terraform 変数が設定され、すべてのバックエンドまたは Kubernetes レベルの変更ごとに Terraform を適用することが保証されました。

このプロセスはスケーラブルではありませんでした。なぜなら、W&B サポートが各顧客に対して Terraform モジュールのアップグレードを支援しなければならなかったからです。

その解決策は、中央の deploy.wandb.ai サーバーに接続するオペレーターを実装し、特定のリリースチャンネルに対する最新の仕様変更を要求して適用することでした。ライセンスが有効な限り、更新が受け取れます。Helm は、W&B オペレーターのデプロイメントメカニズムとして、また W&B Kubernetes スタックのすべての設定テンプレート処理を行う手段として使用され、Helm-セプションを実現します。

仕組み

オペレーターを helm でインストールするか、ソースからインストールすることができます。詳細な手順はcharts/operator を参照してください。

インストールプロセスは controller-manager という名前のデプロイメントを作成し、spec をクラスターに適用する weightsandbiases.apps.wandb.com (shortName: wandb) という名前のカスタムリソース定義を使用します。

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: weightsandbiases.apps.wandb.com

controller-manager は、カスタムリソース、リリースチャンネル、およびユーザー定義の設定の spec に基づいて charts/operator-wandb をインストールします。設定の仕様の階層は、ユーザー側での最大限の設定の柔軟性を実現し、新しい画像、設定、機能、および Helm 更新を自動的にリリースすることが可能です。

設定オプションについては、設定仕様階層および設定参照を参照してください。

設定仕様階層

設定仕様は、上位レベルの仕様が下位レベルのものをオーバーライドする階層モデルに従います。以下はその仕組みです：

• リリースチャンネル値: これは基本レベルの設定で、デプロイメントに対する W&B によって設定されたリリースチャンネルに基づいてデフォルトの値と設定を設定します。
• ユーザー入力値: システムコンソールを通じて、ユーザーはリリースチャンネル Spec によって提供されるデフォルト設定をオーバーライドすることができます。
• カスタムリソース値: ユーザーから提供される最高レベルの仕様です。ここで指定された値は、ユーザー入力およびリリースチャンネルの仕様の両方をオーバーライドします。設定オプションの詳細な説明については、設定参照を参照してください。

この階層モデルは、さまざまなニーズに合わせて柔軟でカスタマイズ可能な設定を保証し、管理可能で体系的なアップグレードと変更のアプローチを維持します。

W&B Kubernetes オペレーターを使用するための要件

W&B を W&B Kubernetes オペレーターでデプロイするために、次の要件を満たしてください:

リファレンスアーキテクチャを参照してください。また、有効な W&B サーバーライセンスを取得します。

セルフマネージドインストールのセットアップと構成方法についての詳細な説明は、こちらのガイドを参照してください。

インストール方法によっては、次の要件を満たす必要がある場合があります:

• 正しい Kubernetes クラスターコンテキストでインストール済みかつ構成済みの Kubectl。
• Helm がインストールされていること。

エアギャップインストール

エアギャップ環境での W&B Kubernetes オペレーターのインストール方法については、Deploy W&B in airgapped environment with Kubernetes チュートリアルを参照してください。

W&B Server アプリケーションのデプロイ

このセクションでは、W&B Kubernetes オペレーターをデプロイするさまざまな方法を説明しています。

以下のいずれかを選択してください:

• 必要なすべての外部サービスをプロビジョニング済みで、Helm CLI を使用して W&B を Kubernetes にデプロイしたい場合はこちらを参照してください。
• インフラストラクチャと W&B Server を Terraform で管理することを好む場合はこちらを参照してください。
• W&B Cloud Terraform Modules を利用したい場合はこちらを参照してください。

Helm CLI で W&B をデプロイする

W&B は W&B Kubernetes オペレーターを Kubernetes クラスターにデプロイするための Helm Chart を提供しています。この方法により、Helm CLI または ArgoCD などの継続的デリバリーツールを使用して W&B Server をデプロイできます。上記の要件が満たされていることを確認してください。

次の手順に従って、Helm CLI を使用して W&B Kubernetes オペレーターをインストールします:

1. W&B Helm リポジトリを追加します。W&B Helm チャートは W&B Helm リポジトリで利用可能です。以下のコマンドでリポジトリを追加します:

helm repo add wandb https://charts.wandb.ai
helm repo update

2. Kubernetes クラスターにオペレーターをインストールします。以下をコピーして貼り付けます:

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

3. W&B オペレーターのカスタムリソースを構成して W&B Server のインストールをトリガーします。この設定の例を operator.yaml というファイルにコピーし、W&B デプロイメントをカスタマイズできるようにします。設定参照を参照してください。

   apiVersion: apps.wandb.com/v1
   kind: WeightsAndBiases
   metadata:
     labels:
       app.kubernetes.io/instance: wandb
       app.kubernetes.io/name: weightsandbiases
     name: wandb
     namespace: default
   
   spec:
     chart:
       url: http://charts.yourdomain.com
       name: operator-wandb
       version: 0.18.0
   
     values:
       global:
         host: https://wandb.yourdomain.com
         license: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
         bucket:
           accessKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
           secretKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
           name: s3.yourdomain.com:port #Ex.: s3.yourdomain.com:9000
           path: bucket_name
           provider: s3
           region: us-east-1
         mysql:
           database: wandb
           host: mysql.home.lab
           password: password
           port: 3306
           user: wandb
         extraEnv:
           ENABLE_REGISTRY_UI: 'true'
   
       # Ensure it's set to use your own MySQL
       mysql:
         install: false
   
       app:
         image:
           repository: registry.yourdomain.com/local
           tag: 0.59.2
   
       console:
         image:
           repository: registry.yourdomain.com/console
           tag: 2.12.2
   
       ingress:
         annotations:
           nginx.ingress.kubernetes.io/proxy-body-size: 64m
         class: nginx
   

   独自の設定でオペレーターを開始して、W&B Server アプリケーションをインストールおよび構成できるようにします。

   kubectl apply -f operator.yaml
   

   デプロイメントが完了するまで待ちます。これには数分かかります。

4. Web UI を使用してインストールを検証するには、最初の管理者ユーザーアカウントを作成し、インストールの検証で説明されている検証手順に従います。

Helm Terraform Module で W&B をデプロイする

この方法は、特定の要件に合わせたカスタマイズされたデプロイメントを可能にし、Terraform のインフラストラクチャ-as-code アプローチを活用して一貫性と再現性を実現します。公式の W&B Helm ベースの Terraform Module はこちらにあります。

以下のコードを出発点として使用し、本番グレードのデプロイメントに必要な設定オプションをすべて含めることができます。

module "wandb" {
  source  = "wandb/wandb/helm"

  spec = {
    values = {
      global = {
        host    = "https://<HOST_URI>"
        license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw"

        bucket = {
          <details depend on the provider>
        }

        mysql = {
          <redacted>
        }
      }

      ingress = {
        annotations = {
          "a" = "b"
          "x" = "y"
        }
      }
    }
  }
}

設定オプションは設定参照に記載されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があります。Terraform モジュールは、W&B カスタムリソース定義 (CRD) を作成します。

W&B&Biases 自身が「Dedicated cloud」インストールをデプロイするために Helm Terraform モジュールをどのように活用しているかを知るには、次のリンクをたどってください：

• AWS
• Azure
• GCP

W&B Cloud Terraform Modules で W&B をデプロイする

W&B は AWS、GCP、および Azure のための Terraform Modules を提供しています。これらのモジュールは、Kubernetes クラスター、ロードバランサー、MySQL データベースなどのインフラ全体と同様に W&B Server アプリケーションをデプロイします。これらの公式 W&B クラウド固有の Terraform Modules には、W&B Kubernetes オペレーターが既に組み込まれています。

この統合により、最小限のセットアップで W&B インスタンス用の W&B Kubernetes オペレーターの準備が整い、クラウド環境での W&B Server のデプロイと管理がスムーズに行えます。

これらのモジュールの使用方法の詳細な説明については、これをセクションのセルフマネージドインストールセクションのドキュメントを参照してください。

インストールを検証する

インストールを検証するには、W&B は W&B CLI を使用することを推奨しています。検証コマンドは、すべてのコンポーネントと設定を検証するいくつかのテストを実行します。

インストールを検証するために以下の手順に従います:

1. W&B CLI をインストールします:

   pip install wandb
   

2. W&B にログインします:

   wandb login --host=https://YOUR_DNS_DOMAIN
   

   例:

   wandb login --host=https://wandb.company-name.com
   

3. インストールを検証します:

   wandb verify
   

正常なインストールと完全に機能する W&B デプロイメントは、次の出力を示します:

Default host selected:  https://wandb.company-name.com
Find detailed logs for this test at: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb
Checking if logged in...................................................✅
Checking signed URL upload..............................................✅
Checking ability to send large payloads through proxy...................✅
Checking requests to base url...........................................✅
Checking requests made over signed URLs.................................✅
Checking CORs configuration of the bucket...............................✅
Checking wandb package version is up to date............................✅
Checking logged metrics, saving and downloading a file..................✅
Checking artifact save and download workflows...........................✅

W&B 管理コンソールへのアクセス

W&B Kubernetes オペレーターには管理コンソールが付属しています。 ${HOST_URI}/console にあり、例えば https://wandb.company-name.com/ です。

管理コンソールにログインする方法は2つあります:

• Option 1 (推奨)
• Option 2

W&B Kubernetes オペレーターの更新

このセクションでは、W&B Kubernetes オペレーターを更新する方法を説明します。

以下のコードスニペットをターミナルにコピーして貼り付けます。

1. まず、 helm repo update でリポジトリを更新します:

   helm repo update
   

2. 次に、 helm upgrade で Helm チャートを更新します:

   helm upgrade operator wandb/operator -n wandb-cr --reuse-values
   

W&B Server アプリケーションの更新

W&B Kubernetes オペレーターを使用する場合、W&B Server アプリケーションの更新は不要です。

オペレーターは、W&B のソフトウェアの新しいバージョンがリリースされると、W&B Server アプリケーションを自動的に更新します。

W&B オペレーターへのセルフマネージドインスタンスの移行

このセクションでは、自分自身で W&B Server インストールを管理することから、W&B オペレーターを使用してこれを実行するための移行プロセスを説明しています。移行プロセスは、W&B Server をインストールした方法によって異なります:

• 公式の W&B Cloud Terraform Modules を使用した場合は、適切なドキュメントを参照し、次の手順に従ってください:
  • AWS
  • GCP
  • Azure
• W&B Non-Operator Helm チャートを使用した場合はこちらを続けてください。
• W&B Non-Operator Helm チャート with Terraform を使用した場合はこちらを続けてください。
• Kubernetes マニフェストでリソースを作成した場合はこちらを続けてください。

オペレーターを基にした AWS Terraform Modules への移行

移行プロセスの詳細な説明については、こちら hereを参照してください。

オペレーターを基にした GCP Terraform Modules への移行

質問がある場合や支援が必要な際は、カスタマーサポートまたは W&B チームにお問い合わせください。

オペレーターを基にした Azure Terraform Modules への移行

質問がある場合や支援が必要な際は、カスタマーサポートまたは W&B チームにお問い合わせください。

オペレーターを基にした Helm チャートへの移行

オペレーターを基にした Helm チャートへの移行手順は次のとおりです:

1. 現在の W&B 設定を取得します。W&B がオペレーターを基にしていないバージョンの Helm チャートでデプロイされている場合、次のように値をエクスポートします:

   helm get values wandb
   

   W&B が Kubernetes マニフェストでデプロイされている場合、次のように値をエクスポートします:

   kubectl get deployment wandb -o yaml
   

   これで、次のステップで必要なすべての設定値が手元にあります。

2. operator.yaml というファイルを作成します。設定参照 で説明されている形式に従ってください。ステップ 1 の値を使用します。

3. 現在のデプロイメントを 0 ポッドにスケールします。このステップで現在のデプロイメントを停止します。

   kubectl scale --replicas=0 deployment wandb
   

4. Helm チャートのリポジトリを更新します:

   helm repo update
   

5. 新しい Helm チャートをインストールします:

   helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
   

6. 新しい helm チャートを構成し、W&B アプリケーションのデプロイメントをトリガーします。新しい設定を適用します。

   kubectl apply -f operator.yaml
   

   デプロイメントが完了するまでに数分かかります。

7. インストールを検証します。すべてが正常に動作することを確認するために、インストールの検証の手順に従います。

8. 古いインストールの削除。古い helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。

オペレーターを基にした Terraform Helm チャートへの移行

オペレーターを基にした Helm チャートへの移行手順は次のとおりです:

1. Terraform 設定を準備します。Terraform 設定内の古いデプロイメントの Terraform コードを、こちらで説明されているものに置き換えます。以前と同じ変数を設定します。.tfvars ファイルがある場合、それを変更しないでください。
2. Terraform run を実行します。terraform init、plan、および apply を実行します。
3. インストールを検証します。すべてが正常に動作することを確認するために、インストールの検証の手順に従います。
4. 古いインストールの削除。古い helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。

Configuration Reference for W&B Server

このセクションでは、W&B サーバーアプリケーションの設定オプションについて説明します。アプリケーションは、WeightsAndBiasesというカスタムリソース定義としてその設定を受け取ります。一部の設定オプションは以下の設定で公開され、他は環境変数として設定する必要があります。

ドキュメントには環境変数が2つのリストに分かれています：basic および advanced。必要な設定オプションが Helm Chart を使用して公開されていない場合にのみ環境変数を使用してください。

本番展開用の W&B サーバーアプリケーションの設定ファイルには、以下の内容が必要です。この YAML ファイルは、W&B デプロイメントの望ましい状態を定義し、バージョン、環境変数、データベースなどの外部リソース、およびその他必要な設定を含みます。

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <details depend on the provider>
      mysql:
        <redacted>
    ingress:
      annotations:
        <redacted>

完全な値セットは W&B Helm リポジトリにあります。オーバーライドする必要がある値のみを変更してください。

完全な例

これは、GCP Kubernetes を使用した GCP Ingress および GCS（GCP オブジェクトストレージ）を使用した設定例です：

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://abc-wandb.sandbox-gcp.wandb.ml
      bucket:
        name: abc-wandb-moving-pipefish
        provider: gcs
      mysql:
        database: wandb_local
        host: 10.218.0.2
        name: wandb_local
        password: 8wtX6cJHizAZvYScjDzZcUarK4zZGjpV
        port: 3306
        user: wandb
      license: eyJhbGnUzaHgyQjQyQWhEU3...ZieKQ2x5GGfw
    ingress:
      annotations:
        ingress.gcp.kubernetes.io/pre-shared-cert: abc-wandb-cert-creative-puma
        kubernetes.io/ingress.class: gce
        kubernetes.io/ingress.global-static-ip-name: abc-wandb-operator-address

ホスト

 # プロトコルと共に完全修飾ドメイン名を提供
global:
  # ホスト名の例、独自のものに置き換え
  host: https://wandb example com

オブジェクトストレージ (バケット)

AWS

global:
  bucket:
    provider: "s3"
    name: ""
    kmsKey: ""
    region: ""

GCP

global:
  bucket:
    provider: "gcs"
    name: ""

Azure

global:
  bucket:
    provider: "az"
    name: ""
    secretKey: ""

その他のプロバイダー（Minio、Ceph、など）

他の S3 互換プロバイダーの場合、バケットの設定は次のようにします：

global:
  bucket:
    # 例の値、独自のものに置き換え
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    accessKey: 5WOA500...P5DK7I
    secretKey: HDKYe4Q...JAp1YyjysnX

AWS 外部でホスティングされている S3 互換ストレージの場合、kmsKey は null にする必要があります。

accessKey および secretKey をシークレットから参照するには：

global:
  bucket:
    # 例の値、独自のものに置き換え
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    secret:
      secretName: bucket-secret
      accessKeyName: ACCESS_KEY
      secretKeyName: SECRET_KEY

MySQL

global:
   mysql:
     # 例の値、独自のものに置き換え
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     password: 8wtX6cJH...ZcUarK4zZGjpV 

password をシークレットから参照するには：

global:
   mysql:
     # 例の値、独自のものに置き換え
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     passwordSecret:
       name: database-secret
       passwordKey: MYSQL_WANDB_PASSWORD

ライセンス

global:
  # 例のライセンス、独自のものに置き換え
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

license をシークレットから参照するには：

global:
  licenseSecret:
    name: license-secret
    key: CUSTOMER_WANDB_LICENSE

Ingress

Kubernetes ingress クラスを識別する方法については、FAQ エントリを参照してください。

TLS なし

global:
# 重要: Ingress は YAML の `global` と同じレベルにあります（子ではありません）
ingress:
  class: ""

TLS 使用

証明書が含まれるシークレットを作成します

kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt

Ingress 設定でシークレットを参照します

global:
# 重要: Ingress は YAML の `global` と同じレベルにあります（子ではありません）
ingress:
  class: ""
  annotations:
    {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  tls: 
    - secretName: wandb-ingress-tls
      hosts:
        - <HOST_URI>

Nginx の場合、次の注釈を追加する必要があるかもしれません：

ingress:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 64m

カスタム Kubernetes ServiceAccounts

W&B ポッドを実行するためにカスタム Kubernetes Service Account を指定します。

次のスニペットは、指定された名前でデプロイメントの一部としてサービスアカウントを作成します：

app:
  serviceAccount:
    name: custom-service-account
    create: true

parquet:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

サブシステム “app” および “parquet” は指定されたサービスアカウントの下で実行されます。他のサブシステムはデフォルトのサービスアカウントで実行されます。

サービスアカウントがクラスター上で既に存在する場合、create: false を設定します：

app:
  serviceAccount:
    name: custom-service-account
    create: false

parquet:
  serviceAccount:
    name: custom-service-account
    create: false
    
global:
  ...

app, parquet, console, その他の様々なサブシステム上にサービスアカウントを指定できます：

app:
  serviceAccount:
    name: custom-service-account
    create: true

console:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

サブシステム間でサービスアカウントを異なるものにすることができます：

app:
  serviceAccount:
    name: custom-service-account
    create: false

console:
  serviceAccount:
    name: another-custom-service-account
    create: true

global:
  ...

外部 Redis

redis:
  install: false

global:
  redis:
    host: ""
    port: 6379
    password: ""
    parameters: {}
    caCert: ""

password をシークレットから参照するには：

kubectl create secret generic redis-secret --from-literal=redis-password=supersecret

下記の設定で参照します：

redis:
  install: false

global:
  redis:
    host: redis.example
    port: 9001
    auth:
      enabled: true
      secret: redis-secret
      key: redis-password

LDAP

TLS を使用しない場合

global:
  ldap:
    enabled: true
    # LDAP サーバーアドレスには "ldap://" または "ldaps://" を含める
    host:
    # ユーザーを見つけるために使用する LDAP 検索ベース
    baseDN:
    # バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
    bindDN:
    # バインドに使用する LDAP パスワードを含むシークレットの名前とキー（匿名バインドを使用しない場合）
    bindPW:
    # 電子メールおよびグループ ID 属性名の LDAP 属性をカンマ区切りの文字列で指定
    attributes:
    # LDAP グループ許可リスト
    groupAllowList:
    # LDAP TLS の有効化
    tls: false

TLS 使用

LDAP TLS 証明書の設定には、証明書内容をプレ作成した config map が必要です。

config map を作成するには、次のコマンドを使用できます：

kubectl create configmap ldap-tls-cert --from-file=certificate.crt

そして、下記の例のように YAML 内で config map を使用します：

global:
  ldap:
    enabled: true
    # LDAP サーバーアドレスには "ldap://" または "ldaps://" を含める
    host:
    # ユーザーを見つけるために使用する LDAP 検索ベース
    baseDN:
    # バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
    bindDN:
    # バインドに使用する LDAP パスワードを含むシークレットの名前とキー（匿名バインドを使用しない場合）
    bindPW:
    # 電子メールおよびグループ ID 属性名の LDAP 属性をカンマ区切りの文字列で指定
    attributes:
    # LDAP グループ許可リスト
    groupAllowList:
    # LDAP TLS の有効化
    tls: true
    # LDAP サーバーの CA 証明書を含む ConfigMap の名前とキー
    tlsCert:
      configMap:
        name: "ldap-tls-cert"
        key: "certificate.crt"

OIDC SSO

global: 
  auth:
    sessionLengthHours: 720
    oidc:
      clientId: ""
      secret: ""
      # IdP が要求する場合のみ含める。
      authMethod: ""
      issuer: ""

authMethod はオプションです。

SMTP

global:
  email:
    smtp:
      host: ""
      port: 587
      user: ""
      password: ""

環境変数

global:
  extraEnv:
    GLOBAL_ENV: "example"

カスタム証明書機関

customCACerts はリストであり、複数の証明書を含むことができます。customCACerts に指定された証明書機関は W&B サーバーアプリケーションのみに適用されます。

global:
  customCACerts:
  - |
    -----BEGIN CERTIFICATE-----
    MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
    MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
    MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
    SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
    P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
    -----END CERTIFICATE-----
  - |
    -----BEGIN CERTIFICATE-----
    MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
    MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
    MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
    SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
    aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
    -----END CERTIFICATE-----

証明書機関を ConfigMap に保存することもできます：

global:
  caCertsConfigMap: custom-ca-certs

ConfigMap は次のようになっている必要があります：

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

カスタムセキュリティコンテキスト

各 W&B コンポーネントは、以下の形式のカスタムセキュリティコンテキスト設定をサポートしています：

pod:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    runAsGroup: 0
    fsGroup: 1001
    fsGroupChangePolicy: Always
    seccompProfile:
      type: RuntimeDefault
container:
  securityContext:
    capabilities:
      drop:
        - ALL
    readOnlyRootFilesystem: false
    allowPrivilegeEscalation: false 

アプリケーションポッドを設定するには、設定に app セクションを追加します：

global:
  ...
app:
  pod:
    securityContext:
      runAsNonRoot: true
      runAsUser: 1001
      runAsGroup: 0
      fsGroup: 1001
      fsGroupChangePolicy: Always
      seccompProfile:
        type: RuntimeDefault
  container:
    securityContext:
      capabilities:
        drop:
          - ALL
      readOnlyRootFilesystem: false
      allowPrivilegeEscalation: false 

同じ概念は console、weave、weave-trace、parquet にも適用されます。

Configuration Reference for W&B Operator

このセクションでは、W&B Kubernetes オペレーター（wandb-controller-manager）の設定オプションを説明しています。オペレーターは、YAML ファイルの形式でその設定を受け取ります。

デフォルトでは、W&B Kubernetes オペレーターには設定ファイルは必要ありません。必要な場合にだけ設定ファイルを作成します。たとえば、カスタム証明書機関を指定したり、エアギャップ環境にデプロイしたりする必要がある場合などです。

仕様のカスタマイズの完全なリストは、Helm リポジトリで確認できます。

カスタム CA

カスタム証明書機関（customCACerts）はリストであり、複数の証明書を含むことができます。それらの証明書機関が追加されると、W&B Kubernetes オペレーター（wandb-controller-manager）のみに適用されます。

customCACerts:
- |
  -----BEGIN CERTIFICATE-----
  MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
  SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
  P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
  -----END CERTIFICATE-----
- |
  -----BEGIN CERTIFICATE-----
  MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
  SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
  aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
  -----END CERTIFICATE-----

CA 証明書を ConfigMap に保存することもできます：

caCertsConfigMap: custom-ca-certs

ConfigMap は次のようになっている必要があります：

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

FAQ

各個別のポッドの役割/目的は何ですか？

• wandb-app: W&B の中枢であり、GraphQL API およびフロントエンドアプリケーションを含みます。これは私たちのプラットフォームの大部分の機能を提供します。
• wandb-console: 管理コンソールであり、/console を通じてアクセスできます。
• wandb-otel: OpenTelemetry エージェントであり、Kubernetes レイヤーでのリソースからメトリクスおよびログを収集して管理コンソールに表示します。
• wandb-prometheus: Prometheus サーバーであり、管理コンソールに表示するためにさまざまなコンポーネントからメトリクスを収集します。
• wandb-parquet: wandb-app ポッドとは別のバックエンドマイクロサービスであり、データベースデータを Parquet 形式でオブジェクトストレージにエクスポートします。
• wandb-weave: UI でクエリテーブルをロードし、さまざまなコアアプリ機能をサポートする別のバックエンドマイクロサービス。
• wandb-weave-trace: LLM ベースのアプリケーションを追跡、実験、評価、展開、および改善するためのフレームワーク。このフレームワークは wandb-app ポッドを介してアクセスできます。

W&B オペレーターコンソールパスワードの取得方法

W&B Kubernetes オペレーターマネジメントコンソールへのアクセスを参照してください。

Ingress が機能しない場合に W&B Operator Console にアクセスする方法

Kubernetes クラスターに到達可能なホストで以下のコマンドを実行してください：

kubectl port-forward svc/wandb-console 8082

https://localhost:8082/ console でブラウザからコンソールにアクセスしてください。

コンソールのパスワードの取得方法については、W&B Kubernetes オペレーターマネジメントコンソールへのアクセス（Option 2）を参照してください。

W&B Server のログを表示する方法

アプリケーションポッドの名前は wandb-app-xxx です。

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

Kubernetes ingress クラスを識別する方法

クラスターにインストールされている ingress クラスを取得するには、次のコマンドを実行します:

kubectl get ingressclass

1.2.2.1 - エアギャップインスタンス用の Kubernetes オペレーター

イントロダクション

このガイドは、顧客管理のエアギャップ環境で W&B プラットフォームをデプロイするためのステップバイステップの手順を提供します。

Helm チャートとコンテナイメージをホストするために内部のリポジトリーまたはレジストリーを使用します。Kubernetes クラスターへの適切なアクセスを備えたシェルコンソールで、すべてのコマンドを実行してください。

Kubernetes アプリケーションをデプロイするために使用している任意の継続的デリバリーツールで、同様のコマンドを利用できます。

ステップ 1: 前提条件

開始する前に、環境が次の要件を満たしていることを確認してください:

• Kubernetes バージョン >= 1.28
• Helm バージョン >= 3
• 必要な W&B イメージを備えた内部コンテナレジストリーへのアクセス
• W&B Helm チャートのための内部 Helm リポジトリーへのアクセス

ステップ 2: 内部コンテナレジストリーの準備

デプロイメントを進める前に、以下のコンテナイメージが内部コンテナレジストリーに利用可能であることを確認する必要があります:

• docker.io/wandb/controller
• docker.io/wandb/local
• docker.io/wandb/console
• docker.io/bitnami/redis
• docker.io/otel/opentelemetry-collector-contrib
• quay.io/prometheus/prometheus
• quay.io/prometheus-operator/prometheus-config-reloader

これらのイメージは、W&B コンポーネントの正常なデプロイメントに不可欠です。W&B はコンテナレジストリーを準備するために WSM を使用することをお勧めします。

もし組織がすでに内部コンテナレジストリーを使用している場合、イメージを追加することができます。そうでない場合は、次のセクションに進み、WSM と呼ばれるものを使用してコンテナリポジトリーを準備してください。

オペレーターの要件を追跡し、イメージのアップグレードを確認してダウンロードすることは、WSM を使用して または組織独自のプロセスを使用して行う責任があります。

WSM のインストール

WSM を次のいずれかのメソッドでインストールします。

Bash

Bash スクリプトを GitHub から直接実行します:

curl -sSL https://raw.githubusercontent.com/wandb/wsm/main/install.sh | bash

スクリプトは、スクリプトを実行したフォルダーにバイナリをダウンロードします。別のフォルダーに移動するには、次を実行します:

sudo mv wsm /usr/local/bin

GitHub

W&B が管理する wandb/wsm GitHub リポジトリーから WSM をダウンロードまたはクローンします。最新リリースについては、wandb/wsm リリースノートを参照してください。

イメージとそのバージョンの一覧表示

wsm list を使用して最新のイメージバージョンのリストを取得します。

wsm list

出力は次のようになります:

:package: デプロイメントに必要なすべてのイメージを一覧表示するプロセスを開始しています...
オペレーターイメージ:
  wandb/controller:1.16.1
W&B イメージ:
  wandb/local:0.62.2
  docker.io/bitnami/redis:7.2.4-debian-12-r9
  quay.io/prometheus-operator/prometheus-config-reloader:v0.67.0
  quay.io/prometheus/prometheus:v2.47.0
  otel/opentelemetry-collector-contrib:0.97.0
  wandb/console:2.13.1
ここに W&B をデプロイするために必要なイメージがあります。これらのイメージが内部コンテナレジストリーで利用可能であることを確認し、`values.yaml` を適切に更新してください。

イメージのダウンロード

最新バージョンのイメージをすべて wsm download を使用してダウンロードします。

wsm download

出力は次のようになります:

オペレーター Helm chart のダウンロード
wandb Helm chart のダウンロード
✓ wandb/controller:1.16.1
✓ docker.io/bitnami/redis:7.2.4-debian-12-r9
✓ otel/opentelemetry-collector-contrib:0.97.0
✓ quay.io/prometheus-operator/prometheus-config-reloader:v0.67.0
✓ wandb/console:2.13.1
✓ quay.io/prometheus/prometheus:v2.47.0

  完了! 7 パッケージがインストールされました。

WSM は各イメージの .tgz アーカイブを bundle ディレクトリーにダウンロードします。

ステップ 3: 内部 Helm チャートリポジトリーの準備

コンテナイメージとともに、以下の Helm チャートが内部 Helm チャートリポジトリーに利用可能であることも確認する必要があります。前のステップで導入した WSM ツールは Helm チャートをダウンロードすることもできます。別の方法として、こちらでダウンロードしてください:

• W&B Operator
• W&B Platform

operator チャートは W&B Oyserator 、つまりコントローラーマネージャーをデプロイするために使用されます。platform チャートは、カスタムリソース定義 (CRD) に設定された値を使用して W&B プラットフォームをデプロイするために使用されます。

ステップ 4: Helm リポジトリーの設定

次に、W&B Helm チャートを内部リポジトリーからプルするために Helm リポジトリーを設定します。以下のコマンドを実行して、Helm リポジトリーを追加および更新します:

helm repo add local-repo https://charts.yourdomain.com
helm repo update

ステップ 5: Kubernetes オペレーターのインストール

W&B Kubernetes オペレーター、別名コントローラーマネージャーは、W&B プラットフォームのコンポーネントを管理する役割を果たします。エアギャップ環境でインストールするには、内部コンテナレジストリーを使用するように設定する必要があります。

そのためには、内部コンテナレジストリーを使用するためにデフォルトのイメージ設定をオーバーライドし、期待されるデプロイメントタイプを示すためにキー airgapped: true を設定する必要があります。以下のように values.yaml ファイルを更新します:

image:
  repository: registry.yourdomain.com/library/controller
  tag: 1.13.3
airgapped: true

タグを内部レジストリーで利用可能なバージョンに置き換えてください。

オペレーターと CRD をインストールします:

helm upgrade --install operator wandb/operator -n wandb --create-namespace -f values.yaml

サポートされている値の詳細については、Kubernetes オペレーター GitHub リポジトリーを参照してください。

ステップ 6: W&B カスタムリソースの設定

W&B Kubernetes オペレーターをインストールした後、内部 Helm リポジトリーおよびコンテナレジストリーを指すようにカスタムリソース (CR) を設定する必要があります。

この設定により、Kubernetes オペレーターが W&B プラットフォームに必要なコンポーネントをデプロイする際に、内部レジストリーとリポジトリーを使用することが保証されます。

この例の CR をコピーし、wandb.yaml という新しいファイルに名前を付けます。

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/instance: wandb
    app.kubernetes.io/name: weightsandbiases
  name: wandb
  namespace: default

spec:
  chart:
    url: http://charts.yourdomain.com
    name: operator-wandb
    version: 0.18.0

  values:
    global:
      host: https://wandb.yourdomain.com
      license: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      bucket:
        accessKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        secretKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        name: s3.yourdomain.com:port #Ex.: s3.yourdomain.com:9000
        path: bucket_name
        provider: s3
        region: us-east-1
      mysql:
        database: wandb
        host: mysql.home.lab
        password: password
        port: 3306
        user: wandb
      extraEnv:
        ENABLE_REGISTRY_UI: 'true'
    
    # インストール: true の場合、Helm はデプロイメントが使用するための MySQL データベースをインストールします。独自の外部 MySQL デプロイメントを使用するには `false` に設定してください。
    mysql:
      install: false

    app:
      image:
        repository: registry.yourdomain.com/local
        tag: 0.59.2

    console:
      image:
        repository: registry.yourdomain.com/console
        tag: 2.12.2

    ingress:
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: 64m
      class: nginx

    

Kubernetes オペレーターは、CR の値を使用して内部リポジトリーから operator-wandb Helm チャートを設定し、W&B プラットフォームをデプロイします。

すべてのタグ/バージョンを内部レジストリーで利用可能なバージョンに置き換えてください。

前述の設定ファイルの作成に関する詳細情報はこちらにあります。

ステップ 7: W&B プラットフォームのデプロイ

Kubernetes オペレーターと CR が設定されたので、wandb.yaml 設定を適用して W&B プラットフォームをデプロイします:

kubectl apply -f wandb.yaml

FAQ

以下のよくある質問 (FAQs) およびデプロイメントプロセス中のトラブルシューティングのヒントを参照してください:

別のイングレスクラスがあります。それを使用できますか？

はい、values.yaml のイングレス設定を変更して、イングレスクラスを設定できます。

証明書バンドルに複数の証明書があります。それは機能しますか？

証明書を values.yaml の customCACerts セクションに複数のエントリに分割する必要があります。

Kubernetes オペレーターが無人更新を適用するのを防ぐ方法はありますか？それは可能ですか？

W&B コンソールから自動更新をオフにできます。サポートされているバージョンについて質問がある場合は、W&B チームにお問い合わせください。また、W&B は過去 6 か月以内にリリースされたプラットフォームバージョンをサポートしていることを確認してください。W&B は定期的なアップグレードを推奨しています。

環境がパブリックリポジトリーに接続されていない場合、デプロイメントは機能しますか？

設定が airgapped を true に設定している場合、Kubernetes オペレーターは内部リソースのみを使用し、パブリックリポジトリーに接続しようとしません。

1.2.3 - パブリック クラウドにインストールする

1.2.3.1 - AWS に W&B プラットフォーム をデプロイ

W&B は AWS 上にプラットフォームをデプロイするために W&B サーバー AWS Terraform モジュール の使用を推奨しています。

始める前に、W&B は Terraform が 状態ファイル を保存するための利用可能なリモートバックエンド を選択することを推奨します。

状態ファイルは、全てのコンポーネントを再作成せずに、アップグレードを展開したりデプロイメントに変更を加えるために必要なリソースです。

Terraform モジュールは以下の 必須 コンポーネントをデプロイします：

• ロードバランサー
• AWS アイデンティティ & アクセスマネジメント (IAM)
• AWS キーマネジメントシステム (KMS)
• Amazon Aurora MySQL
• Amazon VPC
• Amazon S3
• Amazon Route53
• Amazon Certificate Manager (ACM)
• Amazon Elastic Load Balancing (ALB)
• Amazon Secrets Manager

他のデプロイメントオプションには、以下のオプションコンポーネントを含めることもできます：

• Redis 用のエラスティックキャッシュ
• SQS

前提条件の許可

Terraform を実行するアカウントは、イントロダクションで説明されたすべてのコンポーネントを作成できる必要があり、IAM ポリシー と IAM ロール を作成し、リソースにロールを割り当てる許可が必要です。

一般的なステップ

このトピックのステップは、このドキュメントでカバーされる任意のデプロイメントオプションに共通です。

1. 開発環境を準備します。

   • Terraform をインストールします。
   • W&B はバージョンコントロール用の Git リポジトリを作成することを推奨します。

2. terraform.tfvars ファイルを作成します。

   tfvars ファイルの内容はインストールタイプに応じてカスタマイズできますが、推奨される最低限の内容は以下の例のようになります。

   namespace                  = "wandb"
   license                    = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
   subdomain                  = "wandb-aws"
   domain_name                = "wandb.ml"
   zone_id                    = "xxxxxxxxxxxxxxxx"
   allowed_inbound_cidr       = ["0.0.0.0/0"]
   allowed_inbound_ipv6_cidr  = ["::/0"]
   eks_cluster_version        = "1.29"
   

   変数をデプロイ前に tfvars ファイルで定義してください。namespace 変数は Terraform によって作成される全てのリソースのプレフィックスとして使用される文字列です。

   subdomain と domain の組み合わせにより W&B が設定される FQDN が形成されます。上記の例では、W&B の FQDN は wandb-aws.wandb.ml となり、FQDN 記録が作成される DNS zone_id になります。

   allowed_inbound_cidr と allowed_inbound_ipv6_cidr も設定が必要です。このモジュールでは、これは必須の入力です。進行例では、W&B インストールへのアクセスを任意のソースから許可します。

3. versions.tf ファイルを作成します。

   このファイルは、AWS に W&B をデプロイするために必要な Terraformおよび Terraform プロバイダーのバージョンを含むものとします。

   provider "aws" {
     region = "eu-central-1"
   
     default_tags {
       tags = {
         GithubRepo = "terraform-aws-wandb"
         GithubOrg  = "wandb"
         Enviroment = "Example"
         Example    = "PublicDnsExternal"
       }
     }
   }
   

   AWS プロバイダーを設定するには Terraform 公式ドキュメントを参照してください。

   オプションですが強く推奨されるのは、このドキュメントの最初で触れられているリモートバックエンド設定を追加することです。

4. variables.tf ファイルを作成します。

   terraform.tfvars で設定されたオプションごとに、Terraform は対応する変数宣言を必要とします。

   variable "namespace" {
     type        = string
     description = "リソースに使用される名前のプレフィックス"
   }
   
   variable "domain_name" {
     type        = string
     description = "インスタンスにアクセスするために使用されるドメイン名。"
   }
   
   variable "subdomain" {
     type        = string
     default     = null
     description = "Weights & Biases UI にアクセスするためのサブドメイン。"
   }
   
   variable "license" {
     type = string
   }
   
   variable "zone_id" {
     type        = string
     description = "Weights & Biases サブドメインを作成するためのドメイン。"
   }
   
   variable "allowed_inbound_cidr" {
    description = "wandb-server にアクセスを許可される CIDR。"
    nullable    = false
    type        = list(string)
   }
   
   variable "allowed_inbound_ipv6_cidr" {
    description = "wandb-server にアクセスを許可される CIDR。"
    nullable    = false
    type        = list(string)
   }
   
   variable "eks_cluster_version" {
    description = "EKS クラスター用の Kubernetes バージョン"
    nullable    = false
    type        = string
   }
   

推奨されるデプロイメントオプション

これは、全ての 必須 コンポーネントを作成し、最新バージョンの W&B を Kubernetes クラスター にインストールする最も簡単なデプロイメントオプションの設定です。

1. main.tf を作成します。

   一般的なステップ で作成したファイルと同じディレクトリに、以下の内容を持つ main.tf ファイルを作成してください。

   module "wandb_infra" {
     source  = "wandb/wandb/aws"
     version = "~>7.0"
   
     namespace   = var.namespace
     domain_name = var.domain_name
     subdomain   = var.subdomain
     zone_id     = var.zone_id
   
     allowed_inbound_cidr           = var.allowed_inbound_cidr
     allowed_inbound_ipv6_cidr      = var.allowed_inbound_ipv6_cidr
   
     public_access                  = true
     external_dns                   = true
     kubernetes_public_access       = true
     kubernetes_public_access_cidrs = ["0.0.0.0/0"]
     eks_cluster_version            = var.eks_cluster_version
   }
   
    data "aws_eks_cluster" "eks_cluster_id" {
      name = module.wandb_infra.cluster_name
    }
   
    data "aws_eks_cluster_auth" "eks_cluster_auth" {
      name = module.wandb_infra.cluster_name
    }
   
    provider "kubernetes" {
      host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
      cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
      token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
    }
   
   
    provider "helm" {
      kubernetes {
        host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
        cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
        token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
      }
    }
   
    output "url" {
      value = module.wandb_infra.url
    }
   
    output "bucket" {
      value = module.wandb_infra.bucket_name
    }
   

2. W&B をデプロイします。

   W&B をデプロイするには、以下のコマンドを実行してください：

   terraform init
   terraform apply -var-file=terraform.tfvars
   

REDIS を有効にする

別のデプロイメントオプションでは、Redis を使用して SQL クエリをキャッシュし、実験のメトリクスを読み込む際のアプリケーションの応答をスピードアップさせます。

キャッシュを有効にするには、推奨されるデプロイメント Recommended deployment セクションで説明されている同じ main.tf ファイルに create_elasticache_subnet = true オプションを追加する必要があります。

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  subdomain   = var.subdomain
  zone_id     = var.zone_id
	**create_elasticache_subnet = true**
}
[...]

メッセージブローカー（キュー）を有効にする

デプロイメントオプション3は、外部の メッセージブローカー を有効にすることを目的としています。これはオプションですが、W&B 内にブローカーが埋め込まれているため、これによってパフォーマンスが向上するわけではありません。

AWS リソースが提供するメッセージブローカーは SQS です。これを有効にするには、推奨されるデプロイメント Recommended deployment セクションで説明されている同じ main.tf に use_internal_queue = falseオプションを追加する必要があります。

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  subdomain   = var.subdomain
  zone_id     = var.zone_id
  **use_internal_queue = false**

[...]
}

その他のデプロイメントオプション

同じファイルにすべての設定を追加することで、これらの3つのデプロイメントオプションを組み合わせることができます。 Terraform Module は、標準オプションと デプロイメント - 推奨 に見つかる最小限の構成と共に組み合わせることができるいくつかのオプションを提供します。

手動設定

Amazon S3 バケットを W&B のファイルストレージバックエンドとして使用する場合は：

• S3 バケットとバケット通知の作成
• SQS キューの作成
• W&B を実行するノードへの権限付与

バケットと、バケットからのオブジェクト作成通知を受け取るように設定された SQS キューを作成する必要があります。インスタンスにはこのキューを読み取る権限が必要です。

S3 バケットとバケット通知の作成

以下の手順を実行して Amazon S3 バケットを作成し、バケット通知を有効化します。

1. AWS コンソールの Amazon S3 に移動します。
2. バケットを作成 を選択します。
3. 詳細設定 の中で、イベント セクション内の 通知を追加 を選択します。
4. すべてのオブジェクト作成イベントを、先に設定した SQS キューに送信するように構成します。

CORS アクセスを有効にします。あなたの CORS 設定は以下のようになるはずです：

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://YOUR-W&B-SERVER-IP</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

SQS キューの作成

以下の手順に従って SQS キューを作成します：

1. AWS コンソールの Amazon SQS に移動します。
2. キューの作成 を選択します。
3. 詳細 セクションから 標準 キュータイプを選択します。
4. アクセスポリシーセクション内で、以下の主体に許可を追加します：

• SendMessage
• ReceiveMessage
• ChangeMessageVisibility
• DeleteMessage
• GetQueueUrl

また、アクセスポリシー セクションで、高度なアクセスポリシーを追加することもできます。例えば、Amazon SQS へのアクセスを声明するポリシーは以下のようになります：

{
    "Version" : "2012-10-17",
    "Statement" : [
      {
        "Effect" : "Allow",
        "Principal" : "*",
        "Action" : ["sqs:SendMessage"],
        "Resource" : "<sqs-queue-arn>",
        "Condition" : {
          "ArnEquals" : { "aws:SourceArn" : "<s3-bucket-arn>" }
        }
      }
    ]
}

W&B を実行するノードへの権限付与

W&B サーバーが実行されているノードは、Amazon S3 および Amazon SQS へのアクセスを許可するように設定されている必要があります。選択したサーバーデプロイメントの種類に応じて、以下のポリシーステートメントをノードロールに追加する必要があります：

{
   "Statement":[
      {
         "Sid":"",
         "Effect":"Allow",
         "Action":"s3:*",
         "Resource":"arn:aws:s3:::<WANDB_BUCKET>"
      },
      {
         "Sid":"",
         "Effect":"Allow",
         "Action":[
            "sqs:*"
         ],
         "Resource":"arn:aws:sqs:<REGION>:<ACCOUNT>:<WANDB_QUEUE>"
      }
   ]
}

W&B サーバーの設定

最後に、W&B サーバーを設定します。

1. W&B 設定ページに移動: http(s)://YOUR-W&B-SERVER-HOST/system-admin.
2. **外部ファイルストレージバックエンド使用 オプションを有効化
3. 以下の形式であなたの Amazon S3 バケット、リージョン、および Amazon SQS キューに関する情報を提供します：

• ファイルストレージバケット: s3://<bucket-name>
• ファイルストレージリージョン (AWS のみ): <region>
• 通知サブスクリプション: sqs://<queue-name>

4. 設定の更新 を選択して新しい設定を適用します。

W&B のバージョンをアップグレードする

W&B を更新するための手順をここに従ってください：

1. wandb_app モジュール内の設定に wandb_version を追加します。アップグレード先の W&B のバージョンを指定します。例えば、次の行は W&B バージョン 0.48.1 を指定します：

module "wandb_app" {
    source  = "wandb/wandb/kubernetes"
    version = "~>1.0"

    license       = var.license
    wandb_version = "0.48.1"

2. 設定を更新したら、推奨デプロイメントセクションで説明されている手順を完了します。

オペレーターに基づくAWS Terraformモジュールへの移行

このセクションは、terraform-aws-wandb モジュールを使用して、プレオペレーター 環境から ポストオペレーター 環境へのアップグレードに必要な手順を詳細に説明します。

アーキテクチャーのビフォーアフター

以前は、W&B アーキテクチャは以下のように使用されていました：

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "1.16.10"
  ...
}

インフラストラクチャーを管理するために

そしてこのモジュールで W&B サーバーをデプロイしていました：

module "wandb_app" {
  source  = "wandb/wandb/kubernetes"
  version = "1.12.0"
}

移行後、アーキテクチャーは以下のように使用されます：

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "4.7.2"
  ...
}

これにより、インフラストラクチャーと W&B サーバーの Kubernetes クラスターへのインストールの両方を管理し、post-operator.tf で module "wandb_app" は不要となります。

このアーキテクチャーの変更により、OpenTelemetry、Prometheus、HPAs、Kafka、およびイメージの更新などの追加機能を、SRE/インフラストラクチャーチームによる手動の Terraform 操作なしで使用できるようになります。

W&B プレオペレーターの基本インストールを開始するには、post-operator.tf に .disabled ファイル拡張子が付いていることを確認し、pre-operator.tf が有効であることを確認してください（.disabled 拡張子が付いていないもの）。これらのファイルはこちらで確認できます。

前提条件

移行プロセスを開始する前に、次の前提条件が満たされていることを確認してください：

• アウトゴーイング接続: デプロイメントはエアギャップされていない必要があります。リリース チャンネル の最新の仕様を取得するために deploy.wandb.ai へのアクセスが必要です。
• AWS 資格情報: AWS リソースと対話するために適切に構成された AWS 資格情報が必要です。
• Terraform のインストール: 最新バージョンの Terraform がシステムにインストールされている必要があります。
• Route53 ホステッドゾーン: アプリケーションが提供されるドメインに対応した既存の Route53 ホステッドゾーン。
• プレオペレーターTerraformファイル: pre-operator.tf と pre-operator.tfvars のような関連変数ファイルが正しく設定されていることを確認してください。

プリアペレーター セットアップ

プレオペレーター設定の構成を初期化および適用するには、次の Terraform コマンドを実行します：

terraform init -upgrade
terraform apply -var-file=./pre-operator.tfvars

pre-operator.tf は次のようになっています：

namespace     = "operator-upgrade"
domain_name   = "sandbox-aws.wandb.ml"
zone_id       = "Z032246913CW32RVRY0WU"
subdomain     = "operator-upgrade"
wandb_license = "ey..."
wandb_version = "0.51.2"

pre-operator.tf の構成は二つのモジュールを呼び出します：

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "1.16.10"
  ...
}

このモジュールはインフラストラクチャーを起動します。

module "wandb_app" {
  source  = "wandb/wandb/kubernetes"
  version = "1.12.0"
}

このモジュールはアプリケーションをデプロイします。

ポストオペレーター設定

pre-operator.tf に .disabled 拡張子が付いていること、そして post-operator.tf がアクティブであることを確認してください。

post-operator.tfvars には追加の変数が含まれています：

...
# wandb_version = "0.51.2" はリリースチャンネル経由で管理されるか、ユーザースペックで設定されます。

# アップグレードのための必須オペレーター変数：
size                 = "small"
enable_dummy_dns     = true
enable_operator_alb  = true
custom_domain_filter = "sandbox-aws.wandb.ml"

以下のコマンドを実行してポストオペレーター設定を初期化および適用します：

terraform init -upgrade
terraform apply -var-file=./post-operator.tfvars

計画および適用手順は、次のリソースを更新します：

actions:
  create:
    - aws_efs_backup_policy.storage_class
    - aws_efs_file_system.storage_class
    - aws_efs_mount_target.storage_class["0"]
    - aws_efs_mount_target.storage_class["1"]
    - aws_eks_addon.efs
    - aws_iam_openid_connect_provider.eks
    - aws_iam_policy.secrets_manager
    - aws_iam_role_policy_attachment.ebs_csi
    - aws_iam_role_policy_attachment.eks_efs
    - aws_iam_role_policy_attachment.node_secrets_manager
    - aws_security_group.storage_class_nfs
    - aws_security_group_rule.nfs_ingress
    - random_pet.efs
    - aws_s3_bucket_acl.file_storage
    - aws_s3_bucket_cors_configuration.file_storage
    - aws_s3_bucket_ownership_controls.file_storage
    - aws_s3_bucket_server_side_encryption_configuration.file_storage
    - helm_release.operator
    - helm_release.wandb
    - aws_cloudwatch_log_group.this[0]
    - aws_iam_policy.default
    - aws_iam_role.default
    - aws_iam_role_policy_attachment.default
    - helm_release.external_dns
    - aws_default_network_acl.this[0]
    - aws_default_route_table.default[0]
    - aws_iam_policy.default
    - aws_iam_role.default
    - aws_iam_role_policy_attachment.default
    - helm_release.aws_load_balancer_controller

  update_in_place:
    - aws_iam_policy.node_IMDSv2
    - aws_iam_policy.node_cloudwatch
    - aws_iam_policy.node_kms
    - aws_iam_policy.node_s3
    - aws_iam_policy.node_sqs
    - aws_eks_cluster.this[0]
    - aws_elasticache_replication_group.default
    - aws_rds_cluster.this[0]
    - aws_rds_cluster_instance.this["1"]
    - aws_default_security_group.this[0]
    - aws_subnet.private[0]
    - aws_subnet.private[1]
    - aws_subnet.public[0]
    - aws_subnet.public[1]
    - aws_launch_template.workers["primary"]

  destroy:
    - kubernetes_config_map.config_map
    - kubernetes_deployment.wandb
    - kubernetes_priority_class.priority
    - kubernetes_secret.secret
    - kubernetes_service.prometheus
    - kubernetes_service.service
    - random_id.snapshot_identifier[0]

  replace:
    - aws_autoscaling_attachment.autoscaling_attachment["primary"]
    - aws_route53_record.alb
    - aws_eks_node_group.workers["primary"]

以下のような結果が表示されるはずです：

post-operator.tf では一つの以下があります：

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "4.7.2"
  ...
}

ポストオペレーター構成の変更：

1. 必要なプロバイダーの更新: required_providers.aws.version を 3.6 から 4.0 に変更し、プロバイダー互換性を確保します。
2. DNS およびロードバランサーの設定: enable_dummy_dns および enable_operator_alb を統合して、DNS レコードおよび AWS ロードバランサー設定を Ingress 経由で管理します。
3. ライセンスおよびサイズ構成: 新しいオペレーション要件に合わせて、license および size パラメーターを直接 wandb_infra モジュールに転送します。
4. カスタムドメインの処理: 必要に応じて、custom_domain_filter を使用して kube-system 名前空間内の外部 DNS ポッドログをチェックし、DNS 問題のトラブルシューティングを行います。
5. Helmプロバイダー構成: 効果的に Kubernetes リソースを管理するためにHelm プロバイダーを有効にし、構成します：

provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.app_cluster.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.app_cluster.certificate_authority[0].data)
    token                  = data.aws_eks_cluster_auth.app_cluster.token
    exec {
      api_version = "client.authentication.k8s.io/v1beta1"
      args        = ["eks", "get-token", "--cluster-name", data.aws_eks_cluster.app_cluster.name]
      command     = "aws"
    }
  }
}

この包括的なセットアップにより、オペレーターモデルによって可能になった新しい効率性と機能を活用しながら、プレオペレーターからポストオペレーター構成への円滑な移行が可能になります。

1.2.3.2 - W&B プラットフォームを GCP にデプロイする

W&B Server のセルフマネージドを選択した場合、W&B は W&B Server GCP Terraform Module を使用して GCP 上にプラットフォームをデプロイすることを推奨しています。

このモジュールのドキュメントは詳細で、使用可能なすべてのオプションが含まれています。

始める前に、Terraform 用の リモートバックエンド のいずれかを選択し、ステートファイル を保存することをお勧めします。

ステートファイルは、コンポーネントを再作成することなく、アップグレードを展開したり、デプロイメントに変更を加えたりするために必要なリソースです。

Terraform モジュールは以下の 必須 コンポーネントをデプロイします：

• VPC
• Cloud SQL for MySQL
• Cloud Storage バケット
• Google Kubernetes Engine
• KMS 暗号キー
• ロードバランサ

他のデプロイメントオプションには次のオプションコンポーネントが含まれることがあります：

• Redis のためのメモリストア
• Pub/Sub メッセージシステム

事前要件の許可

Terraform を実行するアカウントには、使用される GCP プロジェクトにおいて roles/owner の役割が必要です。

一般的な手順

このトピックの手順は、このドキュメントでカバーされている任意のデプロイメントオプションに共通です。

1. 開発環境を準備します。

   • Terraform をインストールします。
   • 使用するコードを含む Git リポジトリを作成することをお勧めしますが、ファイルをローカルに保持することもできます。
   • Google Cloud Console でプロジェクトを作成します。
   • GCP に認証します（gcloud をインストール しておくことを確認してください） gcloud auth application-default login

2. terraform.tfvars ファイルを作成します。

   tvfars ファイルの内容はインストールタイプに応じてカスタマイズできますが、最低限の推奨事項は以下の例のようになります。

   project_id  = "wandb-project"
   region      = "europe-west2"
   zone        = "europe-west2-a"
   namespace   = "wandb"
   license     = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
   subdomain   = "wandb-gcp"
   domain_name = "wandb.ml"
   

   ここで定義する変数はデプロイメントの前に決定する必要があります。namespace 変数は、Terraform によって作成されたすべてのリソースにプレフィックスとして付ける文字列になります。

   subdomain と domain の組み合わせが W&B が設定される FQDN を形成します。上記の例では、W&B FQDN は wandb-gcp.wandb.ml となります。

3. variables.tf ファイルを作成します。

   terraform.tfvars で設定されたすべてのオプションに対して、Terraform は対応する変数宣言を求めます。

   variable "project_id" {
     type        = string
     description = "Project ID"
   }
   
   variable "region" {
     type        = string
     description = "Google region"
   }
   
   variable "zone" {
     type        = string
     description = "Google zone"
   }
   
   variable "namespace" {
     type        = string
     description = "Namespace prefix used for resources"
   }
   
   variable "domain_name" {
     type        = string
     description = "Domain name for accessing the Weights & Biases UI."
   }
   
   variable "subdomain" {
     type        = string
     description = "Subdomain for access the Weights & Biases UI."
   }
   
   variable "license" {
     type        = string
     description = "W&B License"
   }
   

デプロイメント - 推奨 (~20 分)

これは Mandatory コンポーネントをすべて作成し、Kubernetes Cluster に W&B の最新バージョンをインストールする最も単純なデプロイメントオプション設定です。

1. main.tf を作成します。

   一般的な手順 でファイルを作成したのと同じディレクトリに、次の内容の main.tf ファイルを作成します：

   provider "google" {
    project = var.project_id
    region  = var.region
    zone    = var.zone
   }
   
   provider "google-beta" {
    project = var.project_id
    region  = var.region
    zone    = var.zone
   }
   
   data "google_client_config" "current" {}
   
   provider "kubernetes" {
     host                   = "https://${module.wandb.cluster_endpoint}"
     cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
     token                  = data.google_client_config.current.access_token
   }
   
   # 必須サービスをすべて起動
   module "wandb" {
     source  = "wandb/wandb/google"
     version = "~> 5.0"
   
     namespace   = var.namespace
     license     = var.license
     domain_name = var.domain_name
     subdomain   = var.subdomain
   }
   
   # プロビジョニングされた IP アドレスで DNS を更新する必要があります
   output "url" {
     value = module.wandb.url
   }
   
   output "address" {
     value = module.wandb.address
   }
   
   output "bucket_name" {
     value = module.wandb.bucket_name
   }
   

2. W&B をデプロイします。

   W&B をデプロイするには、次のコマンドを実行します：

   terraform init
   terraform apply -var-file=terraform.tfvars
   

REDIS キャッシュを使用したデプロイメント

別のデプロイメントオプションでは、Redis を使用して SQL クエリをキャッシュし、実験のメトリクスをロードする際のアプリケーションの応答速度を向上させます。

推奨される Deployment option section に示されている同じ main.tf ファイルに create_redis = true のオプションを追加する必要があります。

[...]

module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 1.0"

  namespace    = var.namespace
  license      = var.license
  domain_name  = var.domain_name
  subdomain    = var.subdomain
  allowed_inbound_cidrs = ["*"]
  # Redis を有効化
  create_redis = true

}
[...]

外部キューを使用したデプロイメント

デプロイメントオプション 3 は外部の メッセージブローカー を有効化することから成ります。これは W&B が組み込みのブローカーを提供しているため、オプションです。性能改善はもたらしません。

メッセージブローカーを提供する GCP リソースは Pub/Sub であり、これを有効にするには、推奨される Deployment option section に示されている同じ main.tf に use_internal_queue = false のオプションを追加する必要があります。

[...]

module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 1.0"

  namespace          = var.namespace
  license            = var.license
  domain_name        = var.domain_name
  subdomain          = var.subdomain
  allowed_inbound_cidrs = ["*"]
  # Pub/Sub を作成して使用
  use_internal_queue = false

}

[...]

その他のデプロイメントオプション

すべてのデプロイメントオプションを組み合わせて、すべての設定を同じファイルに追加することができます。 Terraform Module は、標準のオプションや Deployment - Recommended で見つかる最小限の設定と共に組み合わせることができる複数のオプションを提供しています。

手動設定

GCP ストレージバケットを W&B のファイルストレージバックエンドとして使用するには、以下を作成する必要があります：

• PubSub Topic と Subscription
• ストレージバケット
• PubSub 通知

PubSub Topic と Subscription の作成

以下の手順に従って、PubSub トピックとサブスクリプションを作成します：

1. GCP Console 内の Pub/Sub サービスに移動します。
2. Create Topic を選択してトピックに名前を付けます。
3. ページの下部で、Create subscription を選択します。 Delivery Type が Pull に設定されていることを確認します。
4. Create をクリックします。

サービスアカウントまたはインスタンスが実行中のアカウントが、このサブスクリプションの pubsub.admin ロールを持っていることを確認します。 詳細については、https://cloud.google.com/pubsub/docs/access-control#console を参照してください。

ストレージバケットの作成

1. Cloud Storage バケット ページに移動します。
2. Create bucket を選択してバケットに名前を付けます。 Standard の ストレージクラス を選択していることを確認します。

インスタンスが実行中のサービスアカウントまたはアカウントが、以下の条件をすべて満たしていることを確認してください：

• 前のステップで作成したバケットへのアクセス
• このバケットに対する storage.objectAdmin ロール。 詳細については、https://cloud.google.com/storage/docs/access-control/using-iam-permissions#bucket-add を参照してください。

3. CORS アクセスを有効化します。これはコマンドラインのみで実行できます。まず、以下の CORS 設定を含む JSON ファイルを作成します。

cors:
- maxAgeSeconds: 3600
  method:
   - GET
   - PUT
     origin:
   - '<YOUR_W&B_SERVER_HOST>'
     responseHeader:
   - Content-Type

ここでの origin の値のスキーム、ホスト、およびポートが正確に一致していることを確認してください。

4. gcloud が正しくインストールされ、適切な GCP プロジェクトにログインしていることを確認してください。
5. 次に、以下を実行します：

gcloud storage buckets update gs://<BUCKET_NAME> --cors-file=<CORS_CONFIG_FILE>

PubSub 通知の作成

コマンドラインで以下の手順に従って、ストレージバケットから Pub/Sub トピックへの通知ストリームを作成します。

1. GCP プロジェクトにログインします。
2. ターミナルで次の操作を実行します：

gcloud pubsub topics list  # トピックの名前を参照用にリスト表示
gcloud storage ls          # バケットの名前を参照用にリスト表示

# バケット通知を作成
gcloud storage buckets notifications create gs://<BUCKET_NAME> --topic=<TOPIC_NAME>

Cloud Storage のウェブサイトにさらに参考資料があります。

W&B サーバーの設定

1. 最後に、W&B の System Connections ページに http(s)://YOUR-W&B-SERVER-HOST/console/settings/system を開きます。
2. プロバイダーとして Google Cloud Storage (gcs) を選択します。
3. GCS バケットの名前を提供します。

4. 設定を更新 を押して、新しい設定を適用します。

W&B サーバーのアップグレード

ここに示された手順に従って W&B を更新します：

1. あなたの wandb_app モジュールに wandb_version を追加します。アップグレードしたい W&B のバージョンを指定します。例えば、以下の行は W&B バージョン 0.48.1 を指定します：

module "wandb_app" {
    source  = "wandb/wandb/kubernetes"
    version = "~>5.0"

    license       = var.license
    wandb_version = "0.58.1"

2. 設定を更新した後、Deployment option section に記載されている手順を完了します。

1.2.3.3 - Azureで W&B プラットフォーム を展開する

自己管理の W&B サーバーを選択した場合、W&B は W&B Server Azure Terraform Module を使用して Azure 上でプラットフォームをデプロイすることをお勧めします。

このモジュールのドキュメントは詳細で、使用可能なオプションがすべて含まれています。本書では、一部のデプロイメント オプションについて説明します。

開始する前に、Terraform の State File を保存するために利用可能な リモート バックエンド のいずれかを選択することをお勧めします。

State File は、アップグレードを展開したり、すべてのコンポーネントを再作成することなくデプロイメントの変更を行ったりするために必要なリソースです。

Terraform モジュールは、次の「必須」コンポーネントをデプロイします。

• Azure リソース グループ
• Azure 仮想ネットワーク (VPC)
• Azure MySQL Flexible サーバー
• Azure ストレージ アカウント & Blob ストレージ
• Azure Kubernetes サービス
• Azure アプリケーション ゲートウェイ

その他のデプロイメント オプションには、次のオプション コンポーネントが含まれる場合があります。

• Azure Cache for Redis
• Azure Event Grid

前提条件の権限

AzureRM プロバイダーを設定する最も簡単な方法は Azure CLI 経由ですが、Azure サービス プリンシパル を使用した自動化の場合も便利です。 使用される認証メソッドに関わらず、Terraform を実行するアカウントはイントロダクションで説明されているすべてのコンポーネントを作成できる必要があります。

一般的な手順

このトピックの手順は、このドキュメントでカバーされているいずれのデプロイメント オプションにも共通しています。

1. 開発環境を準備します。

• Terraform をインストールします。
• 使用するコードで Git リポジトリを作成することをお勧めしますが、ファイルをローカルに保持することもできます。

2. terraform.tfvars ファイルを作成します tvfars ファイルの内容はインストール タイプに応じてカスタマイズできますが、最低限の推奨事項は以下の例のようになります。

    namespace     = "wandb"
    wandb_license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
    subdomain     = "wandb-aws"
    domain_name   = "wandb.ml"
    location      = "westeurope"
   

   ここで定義されている変数は、デプロイメントの前に決定する必要があります。namespace 変数は、Terraform によって作成されるすべてのリソースの接頭辞となる文字列です。

   subdomain と domain の組み合わせは、W&B が設定される FQDN を形成します。上記の例では、W&B の FQDN は wandb-aws.wandb.ml となり、FQDN レコードが作成される DNS zone_id が指定されます。

3. versions.tf ファイルを作成します このファイルには、AWS に W&B をデプロイするのに必要な Terraform および Terraform プロバイダーのバージョンが含まれています。

terraform {
  required_version = "~> 1.3"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.17"
    }
  }
}

AWS プロバイダーを設定するには、Terraform Official Documentation を参照してください。

また、強く推奨される のは、ドキュメントの冒頭で言及された リモート バックエンド設定 を追加することです。

4. ファイル variables.tf を作成します。terraform.tfvars で構成されたすべてのオプションについて、Terraform は対応する変数宣言を必要とします。

  variable "namespace" {
    type        = string
    description = "リソースの接頭辞に使用される文字列。"
  }

  variable "location" {
    type        = string
    description = "Azure リソース グループの場所"
  }

  variable "domain_name" {
    type        = string
    description = "Weights & Biases UI へのアクセス用ドメイン。"
  }

  variable "subdomain" {
    type        = string
    default     = null
    description = "Weights & Biases UI へのアクセス用サブドメイン。デフォルトは Route53 Route でレコードを作成します。"
  }

  variable "license" {
    type        = string
    description = "あなたの wandb/local ライセンス"
  }

推奨デプロイメント

これは、すべての「必須」コンポーネントを作成し、最新バージョンの W&B を Kubernetes クラスター にインストールする最も簡単なデプロイメント オプション設定です。

1. main.tf を作成します General Steps で作成したファイルと同じディレクトリに、次の内容で main.tf ファイルを作成します：

provider "azurerm" {
  features {}
}

provider "kubernetes" {
  host                   = module.wandb.cluster_host
  cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
  client_key             = base64decode(module.wandb.cluster_client_key)
  client_certificate     = base64decode(module.wandb.cluster_client_certificate)
}

provider "helm" {
  kubernetes {
    host                   = module.wandb.cluster_host
    cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
    client_key             = base64decode(module.wandb.cluster_client_key)
    client_certificate     = base64decode(module.wandb.cluster_client_certificate)
  }
}

# 必要なすべてのサービスをスピンアップ
module "wandb" {
  source  = "wandb/wandb/azurerm"
  version = "~> 1.2"

  namespace   = var.namespace
  location    = var.location
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain

  deletion_protection = false

  tags = {
    "Example" : "PublicDns"
  }
}

output "address" {
  value = module.wandb.address
}

output "url" {
  value = module.wandb.url
}

2. W&B にデプロイ W&B にデプロイするには、次のコマンドを実行します：

   terraform init
   terraform apply -var-file=terraform.tfvars
   

REDIS キャッシュを使用したデプロイメント

別のデプロイメント オプションとして、Redis を使用して SQL クエリをキャッシュし、実験のメトリクスを読み込む際のアプリケーション応答を高速化します。

キャッシュを有効にするには、recommended deployment(#recommended-deployment) で使用したのと同じ main.tf ファイルに create_redis = true オプションを追加する必要があります。

# 必要なすべてのサービスをスピンアップ
module "wandb" {
  source  = "wandb/wandb/azurerm"
  version = "~> 1.2"


  namespace   = var.namespace
  location    = var.location
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain

  create_redis       = true # Redis を作成
  [...]

外部キューを使用したデプロイメント

デプロイメント オプション 3 は、外部の message broker を有効にすることです。 これはオプションであり、W&B にはブローカーが組み込まれているため、パフォーマンスの向上はもたらされません。

message broker を提供する Azure リソースは Azure Event Grid であり、有効にするには、recommended deployment(#recommended-deployment) で使用したのと同じ main.tf に use_internal_queue = false オプションを追加する必要があります。

# 必要なすべてのサービスをスピンアップ
module "wandb" {
  source  = "wandb/wandb/azurerm"
  version = "~> 1.2"


  namespace   = var.namespace
  location    = var.location
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain

  use_internal_queue       = false # Azure Event Grid を有効にする
  [...]
}

その他のデプロイメント オプション

3 つのデプロイメント オプションすべてを組み合わせて、すべての構成を同じファイルに追加できます。 Teraform モジュール は、標準オプションや recommended deployment に見られる最小構成と組み合わせることができるいくつかのオプションを提供します。

1.2.4 - W&B プラットフォームをオンプレミスで展開する

関連する質問については、W&B セールスチームにお問い合わせください: contact@wandb.com.

インフラストラクチャーガイドライン

W&B のデプロイメントを開始する前に、特にインフラストラクチャー要件を確認するために、リファレンスアーキテクチャーを参照してください。

MySQL データベース

スケーラブルな MySQL データベースの運用を簡素化するエンタープライズサービスがいくつかあります。W&B は次のソリューションのいずれかを検討することを推奨します:

https://www.percona.com/software/mysql-database/percona-server

https://github.com/mysql/mysql-operator

以下の条件を満たすようにしてください。W&B Server MySQL 8.0 を実行する場合、または MySQL 5.7 から 8.0 へのアップグレード時に以下を行います:

binlog_format = 'ROW'
innodb_online_alter_log_max_size = 268435456
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
binlog_row_image = 'MINIMAL'

MySQL 8.0 で sort_buffer_size の扱いにいくつか変更があったため、デフォルトの値である 262144 から sort_buffer_size パラメータを更新する必要があるかもしれません。W&B と MySQL が効率よく連携することを保証するために、値を 67108864 (64MiB) に設定することを推奨します。MySQL はこの設定を v8.0.28 からサポートしています。

データベースに関する考慮事項

次の SQL クエリを使用してデータベースとユーザーを作成します。SOME_PASSWORD を希望のパスワードに置き換えてください:

CREATE USER 'wandb_local'@'%' IDENTIFIED BY 'SOME_PASSWORD';
CREATE DATABASE wandb_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL ON wandb_local.* TO 'wandb_local'@'%' WITH GRANT OPTION;

パラメータグループ設定

データベースのパフォーマンスを最適化するために、次のパラメータグループが設定されていることを確認してください:

binlog_format = 'ROW'
innodb_online_alter_log_max_size = 268435456
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
binlog_row_image = 'MINIMAL'
sort_buffer_size = 67108864

オブジェクトストレージ

オブジェクトストアは、Minio クラスター または署名付き URL をサポートする Amazon S3 互換のオブジェクトストアでホストできます。次のスクリプト を実行して、オブジェクトストアが署名付き URL をサポートしているか確認してください。

さらに、次の CORS ポリシーをオブジェクトストアに適用する必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://YOUR-W&B-SERVER-IP</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Amazon S3 互換のオブジェクトストアに接続する際、自分の資格情報を接続文字列で指定できます。たとえば、次のように指定します:

s3://$ACCESS_KEY:$SECRET_KEY@$HOST/$BUCKET_NAME

オブジェクトストア用の信頼された SSL 証明書を設定している場合、W&B が TLS 経由でのみ接続するように指示することもできます。それには、URL に tls クエリパラメータを追加します。たとえば、次の URL 例は、Amazon S3 URI に TLS クエリパラメータを追加する方法を示しています:

s3://$ACCESS_KEY:$SECRET_KEY@$HOST/$BUCKET_NAME?tls=true

サードパーティのオブジェクトストアを使用している場合、BUCKET_QUEUE を internal:// に設定します。これにより、外部の SQS キューやそれに相当するものに依存せずに、W&B サーバーがすべてのオブジェクト通知を内部で管理できるようになります。

独自のオブジェクトストアを運用する際に考慮すべき最も重要なことは次のとおりです:

1. ストレージ容量とパフォーマンス。磁気ディスクを使用しても構いませんが、これらのディスクの容量を監視している必要があります。平均的な W&B の使用量は 10 ギガバイトから 100 ギガバイトに達します。大量使用はペタバイトのストレージ消費を引き起こす可能性があります。
2. フォールトトレランス。最低限、オブジェクトを保存する物理ディスクは RAID アレイにあるべきです。minio を使用する場合は、分散モード での実行を検討してください。
3. 可用性。ストレージが利用可能であることを確認するために監視を設定する必要があります。

独自のオブジェクトストレージサービスを運用するためのエンタープライズ代替策は多数存在します:

1. https://aws.amazon.com/s3/outposts/
2. https://www.netapp.com/data-storage/storagegrid/

MinIO 設定

minio を使用する場合、次のコマンドを実行してバケットを作成できます。

mc config host add local http://$MINIO_HOST:$MINIO_PORT "$MINIO_ACCESS_KEY" "$MINIO_SECRET_KEY" --api s3v4
mc mb --region=us-east1 local/local-files

W&B Server アプリケーションを Kubernetes にデプロイ

公式の W&B Helm チャートを使用することが推奨されるインストール方法です。こちらのセクションに従って W&B Server アプリケーションをデプロイしてください。

OpenShift

W&B は、OpenShift Kubernetes クラスター 内からの運用をサポートしています。

コンテナを非特権ユーザーとして実行

デフォルトでは、コンテナは $UID 999 を使用します。オーケストレーターが非ルートユーザーでのコンテナ実行を要求する場合、$UID >= 100000 そして $GID を 0 に指定します。

Kubernetes のセキュリティコンテキストの例は次のようになります:

spec:
  securityContext:
    runAsUser: 100000
    runAsGroup: 0

ネットワーキング

ロードバランサー

適切なネットワーク境界でネットワークリクエストを停止するロードバランサーを実行します。

一般的なロードバランサーには以下があります:

1. Nginx Ingress
2. Istio
3. Caddy
4. Cloudflare
5. Apache
6. HAProxy

機械学習のペイロードを実行するために使用されるすべてのマシンと、Web ブラウザを介してサービスにアクセスするために使用されるデバイスがこのエンドポイントと通信できることを確認してください。

SSL / TLS

W&B Server は SSL を停止しません。信頼されたネットワーク内での SSL 通信がセキュリティポリシーで求められている場合、Istio や サイドカーコンテナ などのツールを使用してください。ロードバランサー自体は有効な証明書で SSL を終了させる必要があります。自己署名証明書はサポートされておらず、ユーザーに多くの問題を引き起こします。可能であれば、Let’s Encrypt のようなサービスを使用してロードバランサーに信頼された証明書を提供することは素晴らしい方法です。Caddy や Cloudflare のようなサービスは SSL を自動的に管理します。

nginx 設定の例

以下は、nginx をリバースプロキシとして使用する例の設定です。

events {}
http {
    # If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
    # scheme used to connect to this server
    map $http_x_forwarded_proto $proxy_x_forwarded_proto {
        default $http_x_forwarded_proto;
        ''      $scheme;
    }

    # Also, in the above case, force HTTPS
    map $http_x_forwarded_proto $sts {
        default '';
        "https" "max-age=31536000; includeSubDomains";
    }

    # If we receive X-Forwarded-Host, pass it though; otherwise, pass along $http_host
    map $http_x_forwarded_host $proxy_x_forwarded_host {
        default $http_x_forwarded_host;
        ''      $http_host;
    }

    # If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
    # server port the client connected to
    map $http_x_forwarded_port $proxy_x_forwarded_port {
        default $http_x_forwarded_port;
        ''      $server_port;
    }

    # If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
    # Connection header that may have been passed to this server
    map $http_upgrade $proxy_connection {
        default upgrade;
        '' close;
    }

    server {
        listen 443 ssl;
        server_name         www.example.com;
        ssl_certificate     www.example.com.crt;
        ssl_certificate_key www.example.com.key;

        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_set_header Host $http_host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $proxy_connection;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
        proxy_set_header X-Forwarded-Host $proxy_x_forwarded_host;

        location / {
            proxy_pass  http://$YOUR_UPSTREAM_SERVER_IP:8080/;
        }

        keepalive_timeout 10;
    }
}

インストールの確認

W&B Server が正しく設定されていることを確認してください。次のコマンドをターミナルで実行します:

pip install wandb
wandb login --host=https://YOUR_DNS_DOMAIN
wandb verify

開始時に W&B Server にヒットするエラーを表示するためにログファイルを確認してください。次のコマンドを実行します:

• Docker
• Kubernetes

docker logs wandb-local

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

エラーが発生した場合は W&B サポートにお問い合わせください。

1.2.5 - W&B ライセンスと バージョン を更新する

W&B Server の バージョン と ライセンスのアップデートは、W&B Server のインストール方法と同じ方法で行います。次の表に、さまざまな デプロイメント メソッド に基づいたライセンスとバージョンのアップデート方法を示します。

Terraform を使用してアップデート

Terraform を使ってライセンスと バージョン を更新します。以下の表に、クラウド プラットフォーム に基づく W&B 管理Terraform モジュールを示します。

1. まず、お使いの クラウド プロバイダー 用の W&B 管理の Terraform モジュールに移動します。前の表を参照して、クラウド プロバイダー に基づいた適切な Terraform モジュールを見つけてください。

2. Terraform 設定内で、Terraform wandb_app モジュールの設定で wandb_version と license を更新します:

   module "wandb_app" {
       source  = "wandb/wandb/<cloud-specific-module>"
       version = "new_version"
       license       = "new_license_key" # 新しいライセンス キー
       wandb_version = "new_wandb_version" # 希望する W&B バージョン
       ...
   }
   

3. terraform plan および terraform apply コマンドで Terraform 設定を適用します。

   terraform init
   terraform apply
   

4. (オプション) terraform.tfvars またはその他の .tfvars ファイルを使用する場合。

   新しい W&B バージョン と ライセンス キー を指定して terraform.tfvars ファイルを更新または作成します。

   terraform plan -var-file="terraform.tfvars"
   

   設定を適用します。Terraform ワークスペース ディレクトリー で以下を実行します:

   terraform apply -var-file="terraform.tfvars"
   

Helm を使用してアップデート

Spec を使って W&B をアップデート

1. Helm チャート *.yaml 設定 ファイルで image.tag および/または license の 値 を変更して新しい バージョン を指定します:

   license: 'new_license'
   image:
     repository: wandb/local
     tag: 'new_version'
   

2. 以下の コマンド で Helm アップグレード を実行します:

   helm repo update
   helm upgrade --namespace=wandb --create-namespace \
     --install wandb wandb/wandb --version ${chart_version} \
     -f ${wandb_install_spec.yaml}
   

ライセンスと バージョン を直接アップデート

1. 新しい ライセンス キー と イメージ タグ を 環境 変数として設定します:

   export LICENSE='new_license'
   export TAG='new_version'
   

2. 以下の コマンド で Helm リリース をアップグレードし、新しい 値 を既存の設定とマージします:

   helm repo update
   helm upgrade --namespace=wandb --create-namespace \
     --install wandb wandb/wandb --version ${chart_version} \
     --reuse-values --set license=$LICENSE --set image.tag=$TAG
   

詳細については、パブリック リポジトリのアップグレード ガイドを参照してください。

管理者 UI を使用してアップデート

この方法は、通常、自己ホスト型 Docker インストール で、環境 変数 を使用して W&B サーバー コンテナ内に設定されていないライセンスを更新する場合にのみ使用されます。

1. W&B デプロイメント ページ から新しいライセンスを取得し、アップグレードしようとしている デプロイメント に対して正しい組織およびデプロイメント ID と一致することを確認します。
2. W&B 管理者 UI に <host-url>/system-settings でアクセスします。
3. ライセンス管理セクションに移動します。
4. 新しいライセンスキーを入力し、変更を保存します。

1.3 - 専用クラウド

専用クラウドの利用 (シングルテナント SaaS)

W&B 専用クラウドは、シングルテナントで完全に管理されたプラットフォームであり、W&B の AWS、GCP または Azure クラウドアカウントにデプロイされます。各専用クラウドインスタンスは、他の W&B 専用クラウドインスタンスと隔離されたネットワーク、コンピュート、ストレージを持っています。W&B 固有のメタデータとデータは、隔離されたクラウドストレージに保存され、隔離されたクラウドコンピュートサービスを使って処理されます。

W&B 専用クラウドは各クラウドプロバイダーにとって複数の世界各地域で利用可能です

データセキュリティ

セキュアストレージコネクタを使用して、インスタンスおよびチームレベルで自分のバケット (BYOB) を持ち込むことで、モデル、データセットなどのファイルを保存できます。

W&B マルチテナントクラウドと同様に、複数のチーム用に 1 つのバケットを設定するか、異なるチームに対して別々のバケットを使用することができます。チーム用にセキュアストレージコネクタを設定しない場合、そのデータはインスタンスレベルのバケットに保存されます。

セキュアストレージコネクタを使用した BYOB に加えて、信頼できるネットワーク場所からのみ専用クラウドインスタンスにアクセスを制限するために IP 許可リストを利用できます。

また、クラウドプロバイダーのセキュア接続ソリューションを使用して、専用クラウドインスタンスにプライベートに接続することもできます。

アイデンティティとアクセス管理 (IAM)

W&B 組織での安全な認証と効果的な認可のためのアイデンティティおよびアクセス管理機能を利用してください。専用クラウドインスタンスの IAM には、次の機能があります:

• OpenID Connect (OIDC) を使用した SSO または LDAP で認証します。
• 組織の範囲およびチーム内で適切なユーザー役割を設定します。
• 制限付きプロジェクトで、誰が W&B プロジェクトを閲覧、編集、または W&B runs に送信できるかの範囲を定義します。
• JSON Web トークンをアイデンティティフェデレーションと組み合わせて利用し、W&B API にアクセスします。

監視

監査ログを使用して、チーム内でのユーザー活動を追跡し、企業ガバナンス要件に準拠します。また、専用クラウドインスタンス内の W&B 組織ダッシュボードを使用して、組織の利用状況を確認できます。

メンテナンス

W&B マルチテナントクラウドと同様に、専用クラウドを使用することで、W&B プラットフォームのプロビジョニングやメンテナンスに関するオーバーヘッドやコストを負担することはありません。

専用クラウドで W&B がどのようにアップデートを管理するかを理解するためには、サーバーリリースプロセスを参照してください。

コンプライアンス

W&B 専用クラウドのセキュリティ管理は、定期的に内部および外部で監査されています。セキュリティ評価演習のためのセキュリティとコンプライアンス文書をリクエストするには、W&B セキュリティポータルを参照してください。

移行オプション

セルフマネージドインスタンスまたはマルチテナントクラウドから専用クラウドへの移行がサポートされています。

次のステップ

専用クラウドの利用に興味がある場合は、このフォームを提出してください。

1.3.1 - 専用クラウドがサポートされている地域

AWS、GCP、Azure は世界中の複数の場所でクラウドコンピューティングサービスをサポートしています。グローバル地域は、データの居住地やコンプライアンス、レイテンシー、コスト効率などに関連する要件を満たすのに役立ちます。W&B は、Dedicated Cloud のために利用可能な多くのグローバル地域をサポートしています。

サポートされている AWS 地域

以下の表は、W&B が現在 Dedicated Cloud インスタンスについてサポートしている AWS 地域 の一覧です。

AWS 地域についての詳細は、AWS ドキュメントの Regions, Availability Zones, and Local Zones を参照してください。

AWS 地域を選択する際に考慮すべき要素の概要については、What to Consider when Selecting a Region for your Workloads をご覧ください。

サポートされている GCP 地域

以下の表は、W&B が現在 Dedicated Cloud インスタンスについてサポートしている GCP 地域 の一覧です。

GCP 地域についての詳細は、GCP ドキュメントの Regions and zones を参照してください。

サポートされている Azure 地域

以下の表は、W&B が現在 Dedicated Cloud インスタンスについてサポートしている Azure 地域 の一覧です。

Azure 地域についての詳細は、Azure ドキュメントの Azure geographies を参照してください。

1.3.2 - 専用クラウドからデータをエクスポートする

もし専用クラウドインスタンスで管理されているすべてのデータをエクスポートしたい場合、W&B SDK APIを使用して、インポートおよびエクスポートAPIを利用して runs、メトリクス、Artifacts などを抽出できます。以下の表は、いくつかの主要なエクスポートユースケースについて説明しています。

専用クラウドで保管されている Artifacts を Secure Storage Connector で管理している場合、W&B SDK APIを使用してアーティファクトをエクスポートする必要はないかもしれません。

2 - アイデンティティとアクセス管理 (IAM)

W&B プラットフォームには、W&B 内での 3 つの IAM スコープがあります: Organizations、Teams、および Projects。

Organization

Organization は、あなたの W&B アカウントまたはインスタンスのルートスコープです。ユーザー管理、チーム管理、チーム内のプロジェクト管理、使用状況の追跡など、アカウントまたはインスタンス内のすべてのアクションは、このルートスコープのコンテキスト内で行われます。

Multi-tenant Cloud を使用している場合、複数の組織を持っている可能性があります。それぞれが事業部門、個人のユーザー、他社との共同パートナーシップなどに対応する場合があります。

Dedicated Cloud または Self-managed instance を使用している場合、それは1つの組織に対応しています。あなたの会社は、異なる事業部門または部門に対応するために Dedicated Cloud または Self-managed インスタンスを複数持つことができますが、それは業務や部門全体にわたる AI 実践者を管理するためのオプションの方法に過ぎません。

詳細については、Manage organizations を参照してください。

Team

Team は、組織内のサブスコープであり、事業部門、機能、部門、または会社内のプロジェクトチームに対応する場合があります。デプロイメントタイプと価格プランに応じて、組織内に複数のチームを持つことができます。

AI プロジェクトはチームのコンテキスト内で編成されます。チーム内のアクセス制御は、親組織レベルで管理者であるかどうかに関係なく、チーム管理者によって管理されます。

詳細については、Add and manage teams を参照してください。

Project

Project は、特定の目標を持つ実際の AI プロジェクトに対応するチーム内のサブスコープです。チーム内に複数のプロジェクトを持つことができます。各プロジェクトには、誰がプロジェクトにアクセスできるかを決定する公開範囲モードがあります。

各プロジェクトは、Workspaces と Reports で構成され、関連する Artifacts、Sweeps、および Automations とリンクされています。

2.1 - 認証

2.1.1 - SDK でフェデレーテッドアイデンティティを使用する

W&B SDKを使用して、組織の資格情報を使用したサインインにアイデンティティ連携を利用します。W&Bの組織管理者が組織向けにSSOを設定している場合、すでに組織の資格情報を使用してW&BアプリのUIにサインインしています。この意味で、アイデンティティ連携はW&B SDKのためのSSOに似ていますが、JSON Web Tokens (JWTs) を直接使用しています。APIキーの代わりにアイデンティティ連携を使用できます。

RFC 7523は、SDKを使用したアイデンティティ連携の基盤を形成しています。

JWTイシュア設定

最初のステップとして、組織管理者はW&B組織とアクセス可能なJWTイシュアの間で連携を設定しなければなりません。

• 組織ダッシュボードの Settings タブに移動します。
• Authentication オプションで Set up JWT Issuer をクリックします。
• テキストボックスにJWTイシュアのURLを追加し、Create を押します。

W&Bは、${ISSUER_URL}/.well-known/oidc-configuration パスでOIDCディスカバリードキュメントを自動的に探し、ディスカバリードキュメント内の関連URLでJSON Web Key Set (JWKS) を見つけようとします。JWKSは、JWTが関連するアイデンティティプロバイダーによって発行されたものであることを確認するために使用されるリアルタイム検証に利用されます。

W&BへのJWTを使用

JWTイシュアがW&B組織のために設定されると、ユーザーはそのアイデンティティプロバイダーによって発行されたJWTを使用して関連するW&B Projectsへのアクセスを開始できます。JWTを使用するメカニズムは次の通りです：

• 組織内で利用可能なメカニズムの1つを使用して、アイデンティティプロバイダーにサインインする必要があります。一部のプロバイダーはAPIやSDKを使用して自動化された方法でアクセスでき、他のプロバイダーは関連するUIを使用してのみアクセス可能です。詳細については、W&B組織管理者やJWTイシュアの所有者にお問い合わせください。
• アイデンティティプロバイダーにサインインした後、JWTをセキュアな場所に保存し、環境変数 WANDB_IDENTITY_TOKEN_FILE に絶対ファイルパスを設定してください。
• W&B SDKやCLIを使用してW&Bプロジェクトにアクセスします。SDKやCLIは自動的にJWTを検出し、JWTが正常に検証された後にそれをW&Bアクセストークンと交換します。W&Bアクセストークンは、AIワークフローを有効にするためにrun、メトリクス、アーティファクトのログを記録するための関連するAPIにアクセスするために使用されます。アクセストークンはデフォルトで ~/.config/wandb/credentials.json のパスに保存されます。環境変数 WANDB_CREDENTIALS_FILE を指定することでそのパスを変更することができます。

JWT検証

JWTをW&Bアクセストークンと交換し、プロジェクトにアクセスするためのワークフローの一環として、JWTは以下の検証を受けます：

• JWT署名はW&B組織レベルでJWKSを使用して検証されます。これが最初の防御線であり、これが失敗した場合、あなたのJWKSやJWTの署名に問題があることを意味します。
• JWT内の iss クレームは、組織レベルで設定されたイシュアURLと等しいものである必要があります。
• JWT内の sub クレームは、W&B組織で設定されたユーザーのメールアドレスと等しいものである必要があります。
• JWT内の aud クレームは、AIワークフローの一部としてアクセスしているプロジェクトを保有しているW&B組織の名前と同じである必要があります。Dedicated Cloud または セルフマネージド インスタンスの場合、インスタンスレベルの環境変数 SKIP_AUDIENCE_VALIDATION を true に設定してオーディエンスクレームの検証をスキップするか、wandb をオーディエンスとして使用します。
• JWT内の exp クレームは、トークンが有効で期限が切れていないか、リフレッシュが必要であるかを確認するためにチェックされます。

外部サービスアカウント

W&Bは長期間のAPIキーを持つ組み込みのサービスアカウントを長年にわたりサポートしてきました。SDKとCLIのアイデンティティ連携機能を使用すると、外部サービスアカウントを持ち込むことができ、JWTを使用して認証することも可能です。ただし、それらが組織レベルで設定されている同じイシュアによって発行されている限りです。チーム管理者は、組み込みのサービスアカウントのように、チームの範囲内で外部サービスアカウントを設定することができます。

外部サービスアカウントを設定するには：

• チームの Service Accounts タブに移動します。
• New service account を押します。
• サービスアカウントの名前を入力し、Authentication Method として Federated Identity を選択し、Subject を提供して Create を押します。

外部サービスアカウントのJWT内の sub クレームは、チーム管理者がチームレベルの Service Accounts タブでそのサブジェクトとして設定したものと同じである必要があります。このクレームは、JWT検証 の一環として検証されます。aud クレームの要件は、人間のユーザーJWTと同様です。

W&Bへの外部サービスアカウントのJWTを使用するとき、通常、初期JWTを生成し、継続的にリフレッシュするワークフローを自動化する方が簡単です。外部サービスアカウントを使用してログに記録されたrunを人間ユーザーに帰属させる場合、組み込みサービスアカウントと同様に、AIワークフローのために環境変数 WANDB_USERNAME または WANDB_USER_EMAIL を設定することができます。

2.1.2 - SSO を LDAP で設定

資格情報を W&B Server の LDAP サーバーで認証します。次のガイドは W&B Server の設定を行う方法を説明しています。必須およびオプションの設定、システム設定 UI から LDAP 接続を設定する手順をカバーしています。また、アドレス、ベース識別名、属性など、LDAP 設定のさまざまな入力についての情報を提供します。これらの属性は W&B アプリ UI から、または環境変数を使用して指定できます。匿名バインドを設定するか、管理者 DN とパスワードでバインドすることができます。

LDAP 接続の設定

• W&B アプリ
• 環境変数

設定パラメータ

以下の表には、必須およびオプションの LDAP 設定を一覧し説明しています。

2.1.3 - SSO を OIDC で設定

W&B サーバーは、OpenID Connect (OIDC) 互換のアイデンティティ プロバイダーをサポートしており、Okta、Keycloak、Auth0、Google、および Entra などの外部アイデンティティ プロバイダーを通じてユーザー アイデンティティとグループ メンバーシップを管理できます。

OpenID Connect (OIDC)

W&B サーバーは、外部アイデンティティプロバイダー (IdP) とのインテグレーションのために、次の OIDC 認証フローをサポートします。

1. フォームポストを使用したインプリシットフロー
2. コードエクスチェンジのための証明キーを使用した認可コードフロー (PKCE)

これらのフローはユーザーを認証し、必要なアイデンティティ情報 (ID トークンの形式) を W&B サーバーに提供してアクレス制御を管理します。

ID トークンは、ユーザーの名前、ユーザー名、メール、およびグループメンバーシップなど、ユーザーのアイデンティティ情報を含む JWT です。W&B サーバーはこのトークンを使用してユーザーを認証し、システム内で適切なロールやグループにマッピングします。

W&B サーバーのコンテキストでは、アクセストークンはユーザーを代表して API へのリクエストを認可しますが、W&B サーバーの主な関心はユーザー認証とアイデンティティであるため、ID トークンのみが必要です。

環境変数を使用して、Dedicated cloud の IAM オプションを設定するか、Self-managed インスタンスを設定することができます。

Dedicated cloud または Self-managed W&B サーバーインストールのためにアイデンティティ プロバイダーを設定する際は、さまざまな IdP に関するこれらのガイドラインに従ってください。SaaS バージョンの W&B を使用している場合は、組織の Auth0 テナントを設定するための支援を求めるには support@wandb.com に連絡してください。

• Cognito
• Okta
• Entra

W&B サーバーでの SSO 設定

SSO を設定するには、管理者権限と次の情報が必要です：

• OIDC クライアント ID
• OIDC 認証方法（implicit または pkce）
• OIDC 発行者 URL
• OIDC クライアントシークレット (オプション; IdP の設定方法に依存します)

SSO の設定は、W&B サーバー UI を使用するか、wandb/local pod に環境変数 を渡して設定することができます。環境変数が UI よりも優先されます。

• System Console
• System settings

System Console は System Settings ページの後継です。これは W&B Kubernetes Operator ベースのデプロイメントで利用可能です。

1. Access the W&B Management Console を参照してください。

2. Settings に移動し、次に Authentication を選択します。Type ドロップダウンで OIDC を選択します。

3. 値を入力します。

4. Save をクリックします。

5. ログアウトし、IdP ログイン画面を使用して再度ログインします。

1. Weights&Biases インスタンスにサインインします。

2. W&B アプリに移動します。

   

3. ドロップダウンから System Settings を選択します:

   

4. 発行者、クライアント ID、および認証方法を入力します。

5. Update settings を選択します。

セキュリティ・アサーション・マークアップ言語 (SAML)

W&B サーバーは SAML をサポートしていません。

2.1.4 - ワークフローを自動化するためにサービスアカウントを使用する

サービスアカウントは、チーム内のプロジェクト全体または複数チームにわたって、一般的なタスクを自動で実行できる人間でない（または機械の）ユーザーを表します。

• 組織の管理者は、組織のスコープでサービスアカウントを作成することができます。
• チームの管理者は、そのチームのスコープでサービスアカウントを作成することができます。

サービスアカウントの APIキー により、呼び出し元はサービスアカウントのスコープ内のプロジェクトを読み書きできます。

サービスアカウントは、W&B Modelsの実験管理を自動化したり、W&B Weaveのトレースをログ記録したりするために、複数のユーザーやチームによるワークフローを集中管理することを可能にします。また、WANDB_USERNAMEまたはWANDB_USER_EMAILの環境変数を使用することにより、サービスアカウントで管理されているワークフローに人間ユーザーのアイデンティティを関連付けるオプションもあります。

組織スコープのサービスアカウント

組織スコープのサービスアカウントは、チームに関係なく、組織内のすべてのプロジェクトを読み書きする権限を持ちます。ただし、制限付きプロジェクトは例外です。制限付きプロジェクトにアクセスする前に、そのプロジェクトの管理者は明示的にサービスアカウントをプロジェクトに追加する必要があります。

組織管理者は、組織またはアカウントダッシュボードの Service Accounts タブから組織スコープのサービスアカウントの APIキー を取得できます。

新しい組織スコープのサービスアカウントを作成するには：

• 組織ダッシュボードの Service Accounts タブで New service account ボタンをクリックします。
• Name を入力します。
• サービスアカウントのデフォルトチームを選択します。
• Create をクリックします。
• 新しく作成されたサービスアカウントの横で Copy API key をクリックします。
• コピーした APIキー を秘密管理マネージャーまたは他の安全でアクセス可能な場所に保存します。

チームスコープのサービスアカウント

チームスコープのサービスアカウントは、そのチーム内のすべてのプロジェクトを読み書きできますが、そのチーム内の制限付きプロジェクトは除きます。制限付きプロジェクトにアクセスする前に、そのプロジェクトの管理者は明示的にサービスアカウントをプロジェクトに追加する必要があります。

チームの管理者として、 <WANDB_HOST_URL>/<your-team-name>/service-accounts でチームスコープのサービスアカウントの APIキー を取得できます。あるいは、チームの Team settings で Service Accounts タブを参照してください。

チーム用の新しいチームスコープのサービスアカウントを作成するには：

• チームの Service Accounts タブで New service account ボタンをクリックします。
• Name を入力します。
• 認証メソッドとして Generate API key (Built-in) を選択します。
• Create をクリックします。
• 新しく作成されたサービスアカウントの横で Copy API key をクリックします。
• コピーした APIキー を秘密管理マネージャーまたは他の安全でアクセス可能な場所に保存します。

チームスコープのサービスアカウントを使用する モデルトレーニング や生成AIアプリの環境でチームを設定しないと、モデルのrunやweaveトレースがサービスアカウントの親チーム内の指定されたプロジェクトにログ記録されます。このようなシナリオでは、参照されているユーザーがサービスアカウントの親チームの一部でない限り、WANDB_USERNAME または WANDB_USER_EMAIL 変数を使用したユーザー帰属は 機能しません。

外部サービスアカウント

Built-in サービスアカウントに加えて、W&B は アイデンティティのフェデレーション を使用して、JSON Web Tokens (JWTs) を発行できるアイデンティティプロバイダー (IdPs) とともに、W&B SDK と CLI を用いたチームスコープの 外部サービスアカウント もサポートしています。

2.2 - アクセス管理

組織内でのユーザーとチームの管理

ユニークな組織ドメインで W&B に初めてサインアップしたユーザーは、その組織のインスタンス管理者ロールに割り当てられます。組織管理者は特定のユーザーにチーム管理者ロールを割り当てます。

チーム管理者は、チーム内で管理権限を持つ組織内のユーザーです。

組織管理者は、https://wandb.ai/account-settings/ の組織アカウント設定にアクセスして、ユーザーを招待したり、ユーザーの役割を割り当てたり更新したり、チームを作成したり、組織からユーザーを削除したり、請求管理者を割り当てたりすることができます。詳細については、ユーザーの追加と管理を参照してください。

組織管理者がチームを作成すると、インスタンス管理者またはチーム管理者は次のことができます：

• デフォルトでは、管理者のみがそのチームにユーザーを招待したり、チームからユーザーを削除したりできます。この振る舞いを変更するには、チーム設定を参照してください。
• チームメンバーの役割を割り当てたり更新したりします。
• 組織に参加した際に自動的に新しいユーザーをチームに追加します。

組織管理者とチーム管理者は、https://wandb.ai/<your-team-name> のチームダッシュボードを使用してチームを管理します。詳細とチームのデフォルトの公開範囲を設定するには、チームの追加と管理を参照してください。

特定のプロジェクトへの公開範囲の制限

W&B プロジェクトの範囲を定義して、誰がそのプロジェクトを閲覧、編集、そして W&B の run をサブミットできるかを制限します。プロジェクトを閲覧できる人を制限することは、特にチームが機密または秘密のデータを扱う場合に役立ちます。

組織管理者、チーム管理者、またはプロジェクトの所有者は、プロジェクトの公開範囲を設定および編集することができます。

詳細については、プロジェクトの公開範囲を参照してください。

2.2.1 - あなたの組織を管理する

組織の管理者として、組織内の個々のユーザーを管理し、チームを管理できます。

チーム管理者として、チームを管理できます。

組織内のユーザー管理を簡素化したい場合は、ユーザーとチームの管理を自動化するを参照してください。

組織名の変更

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウン内の アカウント セクションで 設定 を選択します。
3. 設定 タブ内で 一般 を選択します。
4. 名前を変更 ボタンを選択します。
5. 表示されるモーダル内に、新しい組織名を入力し、名前を保存 ボタンを選択します。

ユーザーの追加と管理

管理者として、組織のダッシュボードを使用して次のことを行います。

• ユーザーを招待または削除する。
• ユーザーの組織の役割を割り当てまたは更新し、カスタム役割を作成する。
• 請求管理者を割り当てる。

組織の管理者がユーザーを組織に追加する方法はいくつかあります。

1. 招待によるメンバー
2. SSOによる自動プロビジョニング
3. ドメインキャプチャ

シートと価格

以下の表は、Models と Weave のシートの仕組みをまとめたものです。

ユーザーを招待する

管理者は、組織内の特定のチームに加えてユーザーを組織に招待できます。

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

ユーザーの自動プロビジョニング

一致するメールドメインを持つW&Bユーザーは、SSOを設定し、SSOプロバイダーが許可した場合、SSOを使ってW&B組織にサインインすることができます。SSOはすべてのエンタープライズライセンスに利用可能です。

W&Bはデフォルトで自動プロビジョニングされたユーザーに「メンバー」役割を割り当てます。自動プロビジョニングされたユーザーの役割はいつでも変更可能です。

Dedicated cloudインスタンスおよびSelf-managedデプロイメントでは、SSOを使ったユーザーの自動プロビジョニングがデフォルトでオンになっています。自動プロビジョニングをオフにすることができ、特定のユーザーを選んでW&B組織に追加することができます。

以下のタブでは、デプロイメントタイプに基づいてSSOをオフにする方法を説明します：

• Dedicated cloud
• Self-managed

カスタム役割を作成する

組織の管理者は、View-Only または Member 役割に基づいて新しい役割を作成し、追加の許可を追加することで詳細なアクセス制御を実現できます。チーム管理者は、チームメンバーにカスタム役割を割り当てることができます。カスタム役割は組織レベルで作成され、チームレベルで割り当てられます。

カスタム役割を作成するには：

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

チーム管理者は、今後、チーム設定 からチームのメンバーにカスタム役割を割り当てることができます。

ドメインキャプチャ

ドメインキャプチャは、従業員があなたの会社の組織に参加する手助けをし、新しいユーザーが会社の管轄外で資産を作成することがないようにします。

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

ユーザーの役割を割り当てまたは更新する

組織内のすべてのメンバーは、W&B Models および Weave のための組織役割とシートを持っています。彼らのシートタイプによって、彼らの請求状況と各製品ラインで取ることのできるアクションが決まります。

組織に招待する際に、ユーザーに組織の役割を初めて割り当てます。後でどのユーザーの役割も変更できます。

組織内のユーザーは、以下のいずれかの役割を持つことができます：

ユーザーの役割を変更するには：

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー ドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを入力します。
4. チーム役割 ドロップダウンからユーザー名の横にある役割を選択します。

ユーザーのアクセスを割り当てまたは更新する

組織内のユーザーは、以下のいずれかのモデルシートまたは Weave アクセスタイプを持っています：フル、ビューアー、またはアクセスなし。

モデルシートタイプと Weave アクセスタイプは組織レベルで定義され、チームに継承されます。ユーザーのシートタイプを変更したい場合は、組織の設定に移動し、次のステップに従ってください：

1. SaaS ユーザーの場合、https://wandb.ai/account-settings/<organization>/settings にある組織の設定に移動します。角括弧（<>）で囲まれた値を組織名に置き換えてください。他の専用または自己管理のデプロイメントの場合は、https://<your-instance>.wandb.io/org/dashboard に移動します。
2. ユーザー タブを選択します。
3. 役割 ドロップダウンからユーザーに割り当てたいシートタイプを選択します。

ユーザーを削除する

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを提供します。
4. 表示されたら、三点リーダーまたは3つの点のアイコン（…）を選択します。
5. ドロップダウンから メンバーを削除 を選択します。

請求管理者を割り当てる

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを入力します。
4. 請求管理者 列の下で、請求管理者として割り当てたいユーザーを選択します。

チームを追加し管理する

組織のダッシュボードを使って、組織内でチームを作成し管理します。組織の管理者またはチーム管理者は、以下のことができます：

• ユーザーをチームに招待したり、チームからユーザーを削除したりする。
• チームメンバーの役割を管理する。
• 組織に参加した時にユーザーをチームに自動的に追加する。
• https://wandb.ai/<team-name> にあるチームのダッシュボードでチームストレージを管理する。

チームを作成する

組織のダッシュボードを使用してチームを作成します：

1. https://wandb.ai/home に移動します。
2. チーム の下の左側のナビゲーションパネルで コラボレーション用のチームを作成 を選択します。
3. 表示されるモーダルで チーム名 フィールドにチームの名前を入力します。
4. ストレージタイプを選択します。
5. チームを作成 ボタンを選択します。

チームを作成 ボタンを選択すると、W&Bは https://wandb.ai/<team-name> の新しいチームページにリダイレクトします。<team-name> はチーム作成時に入力した名前を使用します。

チームを持ったら、そのチームにユーザーを追加することができます。

チームにユーザーを招待する

組織内のチームにユーザーを招待します。ユーザーがすでにW&Bアカウントを持っている場合は、メールアドレスまたはW&Bユーザー名を使用してチームのダッシュボードからユーザーを招待します。

1. https://wandb.ai/<team-name> に移動します。
2. ダッシュボードの左側のグローバルナビゲーションで チーム設定 を選択します。
3. ユーザー タブを選択します。
4. 新しいユーザーを招待する を選びます。
5. 表示されるモーダルで、メールまたはユーザー名 フィールドにそのユーザーのメールを提供し、チームを選択する ドロップダウンからそのユーザーに割り当てる役割を選択します。チーム内でユーザーが持つことができる役割について詳しくは、チーム役割 を参照してください。
6. 招待を送信 ボタンを選びます。

デフォルトでは、チームまたはインスタンスの管理者のみがメンバーをチームに招待できます。この動作を変更するには、チーム設定を参照してください。

メール招待でユーザーを手動で招待することに加えて、新しいユーザーのメールがあなたの組織のドメインと一致する場合は、自動的に新しいユーザーをチームに追加できます。

新メンバーを登録時にチーム組織と一致させる

新規ユーザーがサインアップ時に組織内のチームを発見できるようにします。新しいユーザーは、あなたの組織の確認済みメールドメインと一致する確認済みのメールドメインを持っている必要があります。確認済みの新規ユーザーは、W&Bアカウントに登録する際に組織に属する確認済みのチームの一覧を見ることができます。

組織の管理者はドメイン請求を有効にする必要があります。ドメインキャプチャを有効にするには、ドメインキャプチャに記載されている手順を参照してください。

チームメンバーの役割を割り当てまたは更新する

1. チームメンバーの名前の横にあるアカウントタイプのアイコンを選択します。
2. ドロップダウンから、そのチームメンバーが持つことを望むアカウントタイプを選択します。

この表は、チームメンバーに割り当てることができる役割を示しています：

チームからユーザーを削除する

チームのダッシュボードを使用してユーザーをチームから削除します。メンバーが作成したrunは、そのメンバーがそのチームにいなくなった場合でもW&Bに保存されます。

1. https://wandb.ai/<team-name> に移動します。
2. 左側のナビゲーションバーで チーム設定 を選択します。
3. ユーザー タブを選択します。
4. 削除したいユーザーの名前の横にマウスをホバーします。表示されたら、三点リーダーまたは3つの点のアイコン（…）を選択します。
5. ドロップダウンから ユーザーを削除 を選択します。

2.2.2 - プロジェクトのアクセス制御を管理する

W&B プロジェクトの範囲を設定し、誰が W&B の run を表示、編集、提出できるかを制限します。

W&B チーム内の任意のプロジェクトに対するアクセスレベルを設定するために、いくつかのコントロールを組み合わせて使用できます。 公開範囲は、上位レベルのメカニズムです。これを使用して、どのユーザーグループがプロジェクト内の run を表示または提出できるかを制御します。Team または Restricted の公開範囲を持つプロジェクトでは、プロジェクトレベルの役割を使用して、各ユーザーのプロジェクト内でのアクセスレベルを制御できます。

公開範囲

選択できるプロジェクトの公開範囲は4つあります。最も公開されているものから最もプライベートなものの順に、それらは次のとおりです：

新規または既存のプロジェクトの公開範囲を設定する

プロジェクトを作成するとき、または後で編集するときに、プロジェクトの公開範囲を設定します。

新しいプロジェクトを作成するときに公開範囲を設定する

1. SaaS クラウド、専用クラウド、または自己管理インスタンスで W&B 組織に移動します。
2. 左側のサイドバーの My projects セクションで Create a new project ボタンをクリックします。代わりに、チームの Projects タブに移動し、右上のコーナーの Create new project ボタンをクリックします。
3. 親チームを選択し、プロジェクトの名前を入力した後、プロジェクトの公開範囲 ドロップダウンから希望の範囲を選択します。

Restricted の公開範囲を選択した場合、次のステップを完了します。

4. プロジェクトでコラボレーションするために必要な W&B チームメンバーの名前を 招待チームメンバー フィールドに入力します。

既存のプロジェクトの公開範囲を編集する

1. W&B プロジェクトに移動します。
2. 左の列で Overview タブを選択します。
3. 右上のコーナーで Edit Project Details ボタンをクリックします。
4. Project Visibility ドロップダウンから希望の範囲を選択します。

Restricted の公開範囲を選択した場合、次のステップを完了します。

5. プロジェクトの Users タブに移動し、特定のユーザーをリストリクションプロジェクトに招待するために ユーザーを追加 ボタンをクリックします。

リストリクション範囲についてのその他の重要な注意事項

• チームレベルのサービスアカウントをリストリクションプロジェクトで使用したい場合は、そのアカウントをプロジェクトに特に招待または追加する必要があります。そうでないと、デフォルトではチームレベルのサービスアカウントはリストリクションプロジェクトにアクセスできません。
• リストリクションプロジェクトから run を移動することはできませんが、非リストリクションプロジェクトからリストリクションプロジェクトに run を移動することはできます。
• プロジェクトの公開範囲をチームにのみ変換することができ、その際、チームのプライバシー設定 Make all future team projects private (public sharing not allowed) に依存しません。
• リストリクションプロジェクトのオーナーが親チームの一員でなくなった場合、チーム管理者はスムーズなプロジェクト運営のためにオーナーを変更する必要があります。

プロジェクトレベルの役割

チーム内の Team または Restricted 範囲のプロジェクトでは、ユーザーに特定の役割を割り当てることができ、その役割はそのユーザーのチームレベルの役割と異なる場合があります。例えば、ユーザーがチームレベルで Member 役割を持っている場合、そのユーザーに View-Only、Admin、または利用可能なカスタム役割をそのチーム内の Team あるいは Restricted 範囲のプロジェクトで割り当てることができます。

ユーザーにプロジェクトレベルの役割を割り当てる

1. W&B プロジェクトに移動します。
2. 左の列で Overview タブを選択します。
3. プロジェクトの Users タブに進みます。
4. 関連するユーザーの Project Role フィールドに現在割り当てられている役割をクリックすると、他の利用可能な役割がリストされているドロップダウンが開きます。
5. ドロップダウンから別の役割を選択します。それは即座に保存されます。

プロジェクトレベルの役割についてのその他の重要な注意事項

• デフォルトでは、チーム_または_リストリクション のプロジェクトにおける全ユーザーのプロジェクトレベルの役割は、それぞれのチームレベルの役割を継承します。
• チームレベルで View-Only 役割を持つユーザーのプロジェクトレベルの役割を変更することはできません。
• 特定のプロジェクト内でのユーザーのプロジェクトレベル役割がチームレベルの役割と同じである場合、チーム管理者がいつかチームレベルの役割を変更した場合、関連するプロジェクト役割も自動的にチームレベルの役割に追随して変更されます。
• 特定のプロジェクト内のユーザーのプロジェクトレベル役割をチームレベルの役割と異なるものに変更した場合、チーム管理者がいつかチームレベルの役割を変更しても、関連するプロジェクトレベルの役割はそのままとなります。
• プロジェクトレベルの役割がチームレベルの役割と異なる場合に、リストリクション プロジェクトからユーザーを削除し、その後しばらくしてユーザーをプロジェクトに戻した場合、デフォルトの振る舞いによりそのチームレベルの役割を継承します。必要であれば、プロジェクトレベルの役割を再度チームレベルの役割と異なるものに変更する必要があります。

2.3 - ユーザーとチームの管理を自動化する

SCIM API

SCIM API を使用して、ユーザーやその所属するチームを効率的かつ再現可能な方法で管理します。また、SCIM API を使用してカスタムロールを管理したり、 W&B 組織内のユーザーにロールを割り当てたりすることもできます。ロールエンドポイントは公式の SCIM スキーマの一部ではありません。 W&B はカスタムロールの自動管理をサポートするためにロールエンドポイントを追加しています。

SCIM API は特に以下の場合に役立ちます：

• 大規模なユーザーのプロビジョニングおよびプロビジョニング解除の管理
• SCIMサポートのアイデンティティプロバイダーを使用してユーザーを管理

SCIM API には大きく分けて 3 つのカテゴリがあります - User 、 Group 、および Roles 。

User SCIM API

User SCIM API を使用すると、ユーザーの作成、無効化、詳細の取得、または W&B 組織内の全ユーザーの一覧を表示できます。この API は、組織内のユーザーに事前定義されたロールまたはカスタムロールを割り当てることもサポートしています。

Group SCIM API

Group SCIM API は、組織内での W&B チームの作成や削除を含めた管理を行うことができます。 PATCH Group を使用して、既存のチームにユーザーを追加または削除します。

Custom role API

Custom role SCIM API は、組織内でのカスタムロールの作成、一覧表示、更新を含めた管理を行うことができます。

W&B Python SDK API

SCIM API がユーザーとチームの管理を自動化するのと同様に、一部のメソッドを使用して W&B Python SDK API も同様の目的で使用できます。以下のメソッドに注意してください：

2.4 - ユーザー、グループ、およびロールを SCIM で管理する

クロスドメイン・アイデンティティ管理システム (SCIM) API は、インスタンスまたは組織の管理者が W&B 組織内のユーザー、グループ、およびカスタムロールを管理できるようにします。SCIM グループは W&B のチームにマップされます。

SCIM API は <host-url>/scim/ でアクセス可能であり、RC7643 プロトコルに見られるフィールドのサブセットを持つ /Users と /Groups エンドポイントをサポートしています。さらに、公式の SCIM スキーマの一部ではない /Roles エンドポイントを含んでいます。W&B は /Roles エンドポイントを追加して、W&B 組織でのカスタムロールの自動管理をサポートしています。

認証

組織またはインスタンスの管理者は、自分の API キーを使用した基本認証を利用して SCIM API にアクセスできます。HTTP リクエストの Authorization ヘッダーを文字列 Basic の後にスペースを置き、その後のベース64エンコードされた文字列を username:API-KEY 形式に設定します。つまり、ユーザー名と API キーを : 文字で区切った後、その結果をベース64エンコードします。例えば、demo:p@55w0rd として認証するには、ヘッダーは Authorization: Basic ZGVtbzpwQDU1dzByZA== であるべきです。

ユーザーリソース

SCIM ユーザーリソースは W&B のユーザーにマップされます。

ユーザーの取得

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: GET
• 説明: ユーザーの一意の ID を提供することにより、SaaS Cloud 組織または Dedicated Cloud または Self-managed インスタンス内の特定のユーザーの情報を取得します。
• リクエスト例:

GET /scim/Users/abc

• レスポンス例:

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

ユーザーのリスト

• エンドポイント: <host-url>/scim/Users
• メソッド: GET
• 説明: SaaS Cloud 組織または Dedicated Cloud または Self-managed インスタンス内のすべてのユーザーのリストを取得します。
• リクエスト例:

GET /scim/Users

• レスポンス例:

(Status 200)

{
    "Resources": [
        {
            "active": true,
            "displayName": "Dev User 1",
            "emails": {
                "Value": "dev-user1@test.com",
                "Display": "",
                "Type": "",
                "Primary": true
            },
            "id": "abc",
            "meta": {
                "resourceType": "User",
                "created": "2023-10-01T00:00:00Z",
                "lastModified": "2023-10-01T00:00:00Z",
                "location": "Users/abc"
            },
            "schemas": [
                "urn:ietf:params:scim:schemas:core:2.0:User"
            ],
            "userName": "dev-user1"
        }
    ],
    "itemsPerPage": 9999,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 1
}

ユーザーの作成

• エンドポイント: <host-url>/scim/Users
• メソッド: POST
• 説明: 新しいユーザーリソースを作成します。
• サポートされているフィールド:

• リクエスト例:

POST /scim/Users

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "emails": [
    {
      "primary": true,
      "value": "admin-user2@test.com"
    }
  ],
  "userName": "dev-user2"
}

• レスポンス例:

(Status 201)

{
    "active": true,
    "displayName": "Dev User 2",
    "emails": {
        "Value": "dev-user2@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "def",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "location": "Users/def"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user2"
}

ユーザーの削除

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: DELETE
• 説明: ユーザーの一意の ID を提供することにより、SaaS Cloud 組織または Dedicated Cloud または Self-managed インスタンスから完全にユーザーを削除します。必要に応じて Create user API を使用して組織またはインスタンスに再度ユーザーを追加してください。
• リクエスト例:

DELETE /scim/Users/abc

• レスポンス例:

(Status 204)

ユーザーの無効化

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: ユーザーの一意の ID を提供することにより、Dedicated Cloud または Self-managed インスタンス内で一時的にユーザーを無効化します。必要に応じて Reactivate user API を使用してユーザーを再有効化します。
• サポートされているフィールド:

• リクエスト例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "value": {"active": false}
        }
    ]
}

• レスポンス例: この操作はユーザーオブジェクトを返します。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

ユーザーの再有効化

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: ユーザーの一意の ID を提供することにより、Dedicated Cloud または Self-managed インスタンス内で無効化されたユーザーを再有効化します。
• サポートされているフィールド:

• リクエスト例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "value": {"active": true}
        }
    ]
}

• レスポンス例: この操作はユーザーオブジェクトを返します。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

組織レベルのロールをユーザーに割り当てる

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: 組織レベルのロールをユーザーに割り当てます。このロールは、ここで説明されているように admin、viewer または member のいずれかになります (こちらを参照)。 SaaS Cloud では、ユーザー設定で SCIM API の正しい組織を設定することを確認してください。
• サポートされているフィールド:

• リクエスト例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "organizationRole",
            "value": "admin" // ユーザーの組織スコープのロールを admin に設定
        }
    ]
}

• レスポンス例: この操作はユーザーオブジェクトを返します。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1",
    "teamRoles": [  // ユーザーが所属するすべてのチームでのロールを返します
        {
            "teamName": "team1",
            "roleName": "admin"
        }
    ],
    "organizationRole": "admin" // 組織スコープでのユーザーのロールを返します
}