自己管理

• 1: リファレンス アーキテクチャー
• 2: W&B サーバーを Kubernetes で実行する
• 2.1: エアギャップインスタンス用の Kubernetes オペレーター
• 3: パブリック クラウドにインストールする
• 3.1: AWS に W&B プラットフォーム をデプロイ
• 3.2: W&B プラットフォームを GCP にデプロイする
• 3.3: Azureで W&B プラットフォーム を展開する
• 4: W&B プラットフォームをオンプレミスで展開する
• 5: W&B ライセンスと バージョン を更新する

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

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

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 オペレーターは内部リソースのみを使用し、パブリックリポジトリーに接続しようとしません。

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

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"
    }
  }
}

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

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 に記載されている手順を完了します。

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 に見られる最小構成と組み合わせることができるいくつかのオプションを提供します。

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 サポートにお問い合わせください。

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. 新しいライセンスキーを入力し、変更を保存します。