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

このページでは、Weights & Biases デプロイメントのリファレンスアーキテクチャについて説明し、本番デプロイメントをサポートするために推奨されるインフラストラクチャーとリソースの概要を示します。信頼性の高いセルフマネージドインストールに必要なコンポーネントのサイズ設定、プロビジョニング、統合のための計画ガイドとして使用してください。このページは、独自のインフラストラクチャー上でWeights & Biasesをデプロイおよび運用するプラットフォームエンジニア、サイト信頼性エンジニア、インフラストラクチャー管理者を対象としています。 Weights & Biasesの選択したデプロイメント環境に応じて、さまざまなサービスがデプロイメントの回復力を強化するのに役立ちます。たとえば、主要なクラウドプロバイダーは、データベースの設定、メンテナンス、高可用性、回復力の複雑さを軽減するマネージドデータベースサービスを提供しています。このリファレンスアーキテクチャは、一般的なデプロイメントシナリオに対応し、パフォーマンスと信頼性のためにクラウドベンダーサービスとWeights & Biasesデプロイメントを統合する方法を示します。

始める前に

アプリケーションを本番環境で稼働させるには固有の課題があり、Weights & Biases も例外ではありません。Weights & Biases は作業の簡素化を目指していますが、アーキテクチャや設計上の判断によっては複雑な問題が生じる場合があります。通常、本番デプロイメントの管理には、ハードウェア、オペレーティングシステム、ネットワーク、ストレージ、セキュリティ、Weights & Biases プラットフォーム自体、およびその他の依存関係を含む構成要素の監督が伴います。この責任は、環境の初期設定だけでなく、継続的な保守にも及びます。 Weights & Biases のセルフマネージド方式が、チームと要件に適しているかを慎重に検討してください。セルフマネージド Weights & Biases をデプロイする前に、本番環境向けアプリケーションの運用と保守について十分に理解しておくことが重要です。チームが支援を必要とする場合は、CoreWeave Professional Services チームとパートナーが導入と最適化をサポートします。 Weights & Biases を自分で管理する代わりに利用できるマネージドソリューションについては、W&B Multi-tenant Cloud と W&B 専用クラウドを参照してください。

インフラストラクチャー

Weights & Biases のデプロイメントは、アプリケーション層とストレージ層で構成されます。次の図は、これらの層の関係を示しています。続く各セクションでは、それぞれについて説明します。

アプリケーション層

アプリケーション層は、ノード障害に対する耐障害性を備えた複数ノードの Kubernetes クラスターで構成されます。Kubernetes クラスターは Weights & Biases の Pod を実行し、維持します。

ストレージ層

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

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

以下のセクションでは、Kubernetes クラスターの詳細、MySQL、Redis、オブジェクトストレージ、ソフトウェアバージョン、ネットワーク、DNS、ロードバランサーとイングレス、SSL/TLS、サポートされる CPU アーキテクチャーなど、Weights & Biases のデプロイメントに関する要件を詳しく説明します。デプロイメントを開始する前に、環境がこれらの要件をすべて満たしていることを確認してください。

Kubernetes

Weights & Biases は、複数の Pod をデプロイする Kubernetes Operator として W&B Server アプリケーションをデプロイします。このため、Weights & Biases には以下を備えた Kubernetes クラスターが必要です。

完全に設定され、正常に機能するIngress コントローラー。
Persistent Volume をプロビジョニングする機能。

Weights & Biases は、クラウド、オンプレミス、エアギャップ環境の OpenShift Kubernetes クラスターへのデプロイをサポートします。具体的な設定手順については、オペレーターガイドの OpenShift セクションを参照してください。

MySQL

Weights & Biases はメタデータを MySQL データベースに保存します。データベースに必要なパフォーマンスとストレージは、モデルのパラメーターや関連するメタデータの構造によって異なります。たとえば、トラッキングするトレーニング run が増えるとデータベースのサイズが大きくなり、run テーブル、ユーザーの workspace、report でのクエリに応じてデータベースの負荷が増加します。 Weights & Biases は、本番デプロイメントにはマネージドデータベースサービスの使用を強く推奨します (AWS RDS Aurora MySQL、Google Cloud SQL for MySQL、Azure Database for MySQL など)。マネージドサービスは、自動バックアップ、モニタリング、高可用性、パッチ適用を提供し、運用の複雑さを軽減します。具体的なサービスの推奨事項については、クラウドプロバイダーのインスタンスに関する推奨事項セクションを参照してください。セルフマネージドの MySQL データベースをデプロイする場合は、次の点を考慮してください。

バックアップ: データベースを定期的に別の場所にバックアップします。Weights & Biases は、少なくとも 1 週間の保持期間を設けた日次バックアップを推奨します。
パフォーマンス: データベースには、SSD や高速 NAS など、高速なストレージハードウェアが必要です。
モニタリング: データベースには十分な CPU リソースが必要です。データベースサーバーの CPU 負荷を監視してください。CPU 使用量がシステム全体の 90% を超える状態で 5 分以上続く場合は、CPU キャパシティの追加を検討してください。
可用性: 可用性と耐久性の要件を満たすために、Weights & Biases は別のマシンにホットスタンバイのデプロイメントを構成することを推奨します。スタンバイはプライマリのデプロイメントからすべての更新をリアルタイムで受信し、プライマリサーバーがクラッシュした場合、破損した場合、またはダウンタイムが長引いた場合に切り替えられる状態を維持します。

MySQL のトポロジ

本番環境で高可用性を実現するには、マネージド MySQL サービスの利用が最も簡単です。フェイルオーバー、バックアップ、パッチ適用をクラウドプロバイダーに任せられます。AWS の Aurora Multi-AZ など、プロバイダーが提供する高可用性オプションを使用してください。セルフマネージドの MySQL を運用する場合は、リアルタイムでレプリケーションデータを受信し、障害時に処理を引き継げるホットスタンバイをプライマリデータベースに用意してください。Weights & Biases は、アプリケーションデータベースのマルチプライマリトポロジや読み取り専用レプリカをサポートしていません。

MySQL データベースの作成

MySQL データベースとユーザーを手動で作成する手順については、ベアメタルガイドの MySQL データベースセクションを参照してください。

MySQL 設定パラメーター

これらのパラメーターは、Weights & Biases が大規模に実行する書き込みパターンとスキーマ変更に合わせて MySQL を調整します。独自の MySQL インスタンスを運用している場合は、以下の設定で MySQL を構成してください。

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

Weights & Biases はこれらの設定のパフォーマンスと信頼性を検証済みです。

Redis

Weights & Biases は、Weights & Biases コンポーネントがジョブのキュー管理とデータキャッシュに使用する、単一ノードの Redis 7.x デプロイメントに依存します。テストや概念実証の開発の便宜上、W&B セルフマネージドには本番デプロイメントには適さないローカル Redis デプロイメントが含まれています。 Weights & Biases は、以下の環境の Redis インスタンスに接続できます：

AWS Elasticache.
Google Cloud Memory Store.
Azure Cache for Redis.
クラウドまたはオンプレミスのインフラストラクチャーでホストされる Redis デプロイメント。

オブジェクトストレージ

Weights & Biases には、事前署名付き URL と CORS をサポートするオブジェクトストレージが必要です。次のいずれかにデプロイしてください。

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

バージョン

ソフトウェア	最低バージョン
Kubernetes	v1.34 以降 (サポートされる Kubernetes バージョン)
Helm	v3.x
MySQL	W&B Self-Managed のデプロイメントでは、セキュリティパッチと重要なバグ修正が提供されている、サポート対象の MySQL バージョンを実行する必要があります。MySQL 8.4.x をインストールするか、同バージョンにアップグレードしてください。または、プロバイダーがサポート対象かつパッチ適用済みと明記しているマネージドサービスのバージョンを使用してください。 Aurora MySQL のバージョン文字列は、コミュニティ版 MySQL のバージョンとは異なります。データベースエンジンの完全なバージョン文字列を確認するには `SELECT version()` を、Aurora のバージョンを確認するには `SELECT aurora_version()` を使用してください。Aurora MySQL バージョン 3 は MySQL 8.0.x と互換性があり、引き続きサポートされています。移行先のバージョンを選択する際は、Amazon Aurora のバージョン管理およびご利用のクラウドプロバイダーのドキュメントを参照してください。
Redis	v7.x
ClickHouse	セルフマネージドのデプロイで Weave を使用する場合は必須です。Weave を使用しないデプロイメントでは不要です。アップグレード時の ClickHouse 互換性およびサポートされる W&B Server リリースを参照してください。

ネットワーク

ネットワーク接続されたデプロイメントでは、インストール時と実行時の両方で、以下のエンドポイントへの外向き通信を許可してください。

https://deploy.wandb.ai
https://charts.wandb.ai
https://quay.io (Prometheus のイメージに使用)

デプロイメントの設定によっては、追加のコンテナーレジストリが必要になる場合があります。

Weave のオンライン評価のために Bufstream と etcd をデプロイする場合は、https://gcr.io。

エアギャップ環境のデプロイメントについては、エアギャップ環境のインスタンス向け Kubernetes Operatorを参照してください。トレーニングインフラストラクチャーと各実験管理システムに、W&B とオブジェクトストレージへのアクセス権を付与してください。

DNS

Weights & Biases デプロイメントの完全修飾ドメイン名 (FQDN) は、A レコードを使用してイングレスまたはロードバランサーの IP アドレスに解決する必要があります。

ロードバランサーとイングレス

W&B Kubernetes Operator は、URL パスに基づいて異なるポートのサービスエンドポイントへルーティングする Kubernetes Ingress コントローラーを使用してサービスを公開できます。Ingress コントローラーは、機械学習のペイロードを実行するすべてのマシン、またはブラウザーを介してサービスにアクセスするすべてのマシンからアクセス可能である必要があります。

Ingress コントローラー requirements

Kubernetes クラスターでは、IngressClass が利用可能である必要があります。一般的な Ingress コントローラーには、次の選択肢があります。

Nginx Ingress コントローラー。
Istio。
Traefik。
cloud provider の Ingress コントローラー (AWS ALB、GCP Ingress、Azure Application Gateway) 。

Weights & Biases サービスのルーティング

W&B オペレーターは、パスに基づいてリクエストを複数のバックエンドサービスに自動的にルーティングします。

パス	サービス	デフォルトポート	用途
`/`	`wandb-app`	8080	メインのウェブアプリケーション UI
`/api`	`wandb-api`	8081	API サービス
`/graphql`	`wandb-api`	8081	GraphQL API エンドポイント
`/graphql2`	`wandb-api`	8081	GraphQL API v2 エンドポイント
`/console`	`wandb-console`	8082	システムコンソール
`/traces`	`wandb-weave-trace`	8722	Weave トレースサービス (有効な場合)

イングレス設定の例

以下は、W&B オペレーターによって作成された Ingress リソースの例です：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wandb
  namespace: wandb
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
spec:
  ingressClassName: nginx
  rules:
  - host: wandb.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wandb-app
            port:
              number: 8080
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: wandb-api
            port:
              number: 8081
      - path: /graphql
        pathType: Prefix
        backend:
          service:
            name: wandb-api
            port:
              number: 8081
      - path: /graphql2
        pathType: Prefix
        backend:
          service:
            name: wandb-api
            port:
              number: 8081
      - path: /console
        pathType: Prefix
        backend:
          service:
            name: wandb-console
            port:
              number: 8082
  tls:
  - hosts:
    - wandb.example.com
    secretName: wandb-tls

W&B オペレーターはイングレスの設定を自動的に作成および管理します。通常、Ingress リソースを手動で作成する必要はありません。クラスターに機能する Ingress controller と適切な IngressClass が設定されていることを確認してください。

SSL/TLS

W&B では、クライアントとサーバー間の安全な通信のために、有効な署名済み SSL/TLS 証明書が必要です。SSL/TLS の終端は、イングレスまたはロードバランサーで行う必要があります。W&B Server アプリケーション自体は SSL/TLS 接続を終端しません。

W&B は自己署名証明書やカスタム CA をサポートしていません。自己署名証明書はユーザー側で問題を引き起こすため、サポート対象外です。

可能であれば、Let’s Encrypt などのサービスを使用して、信頼された証明書をロードバランサーに提供してください。Caddy や Cloudflare などのサービスを利用すると、SSL の管理を任せることができます。セキュリティポリシー上、信頼されたネットワーク内でも SSL 通信が必要な場合は、Istio などのツールとサイドカーコンテナーの使用を検討してください。

サポートされる CPU アーキテクチャー

Weights & Biases は Intel および AMD の 64 ビットアーキテクチャで動作します。ARM はサポートされていません。

デプロイ方法

インフラストラクチャーが前述の要件を満たしたら、Weights & Biases のインストール方法と基盤となるリソースのプロビジョニング方法を選択します。以下のセクションでは、推奨されるデプロイ方法とインフラストラクチャーのプロビジョニング方法について説明します。

Helm を使用した W&B Kubernetes Operator

W&B セルフマネージドの推奨インストール方法では、Helm を通じてデプロイされる W&B Kubernetes Operator を使用します。この方法には、次の利点があります。

Weights & Biases コンポーネントの更新と管理の自動化。
設定とデプロイの簡素化。
すべてのデプロイメントシナリオ (クラウド、オンプレミス、エアギャップ) へのサポート。

詳しいインストール手順については、以下を参照してください。

W&B プラットフォームをオンプレミスにデプロイする - 基本となるインストールガイド。
エアギャップ環境のインスタンス向け Kubernetes Operator - 外部ネットワークから切り離された環境向け。

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

Weights & Biases の本番デプロイメント向けインフラストラクチャーのプロビジョニングには、Terraform の使用を推奨します。Terraform では、必要なリソース、他のリソースへの参照、リソース間の依存関係を定義できます。Weights & Biases は主要なクラウドプロバイダー向けに Terraform モジュールを提供しています。詳しくは、セルフマネージドのクラウドアカウントに W&B Server をデプロイするをご覧ください。

サイジング

デプロイメントを計画する際は、以下のガイドラインを出発点として使用してください。Weights & Biases は、デプロイメントのすべてのコンポーネントを注意深く監視し、観測された使用パターンに基づいて調整することを推奨します。本番デプロイメントも継続的に監視し、パフォーマンスを維持するために必要に応じて調整してください。キャパシティを計画する際は、W&B オペレーターのワークロードを実行する Kubernetes クラスターと、メタデータを保存する MySQL データベースという 2 つの主要コンポーネントのサイズを決定します。推奨事項は、環境 (Test/Dev または本番) によって異なり、Kubernetes については プロダクトの組み合わせ (Models のみ、Weave のみ、または Models と Weave) によっても異なります。Weights & Biases は、Test/Dev と本番のどちらも最低 3 台のワーカーノードから始め、本番ではクラスターのオートスケーリングを有効にすることを推奨します。以下のセクションでは、Kubernetes クラスターと MySQL データベースについて、ノードごとの推奨サイズを示します。

Kubernetes のサイジング

Models のみ
Weave のみ
Models と Weave

環境	CPU	メモリ	ディスク
Test/Dev	2 コア	16 GB	100 GB
本番	8 コア	64 GB	100 GB

数値は Kubernetes のワーカーノード 1 台あたりの値です。

環境	CPU	メモリ	ディスク
Test/Dev	4 コア	32 GB	100 GB
本番	12 コア	96 GB	100 GB

環境	CPU	メモリ	ディスク
Test/Dev	4 コア	32 GB	100 GB
本番	16 コア	128 GB	100 GB

MySQL のサイジング

これらの推奨事項は、プロダクトの組み合わせによって変わりません。トポロジと可用性に関するガイダンスについては、MySQL の MySQL のトポロジを参照してください。

環境	CPU	メモリ	ディスク
Test/Dev	2 コア	16 GB	100 GB
本番	8 コア	64 GB	500 GB

数値は MySQL ノードあたりの値です。

run の幅に応じた MySQL のサイジング

データベースの負荷は run の幅 にも左右されます。run の幅とは、単一の run が各 step でログする一意のメトリクスの数です。たとえば、step ごとに 50,000 個の一意のメトリクスをログする run の幅は 50K です。幅の広い run はデータベースの CPU 負荷を増大させます。特に、UI が Workspace や report でこうした run を読み込む際に負荷が高くなります。チームで幅の広い run をログする場合は、想定される最も幅の広い run に合わせて各 MySQL ノードのサイズを決定してください。

run の幅 (step あたりのメトリクス数)	CPU	メモリ	AWS インスタンスクラスの例
最大 1K	2 コア	16 GB	`db.r6g.large`
最大 25K	4 コア	32 GB	`db.r6g.xlarge`
最大 50K	8 コア	64 GB	`db.r6g.2xlarge`
最大 75K	16 コア	128 GB	`db.r6g.4xlarge`
最大 100K	32 コア	256 GB	`db.r6g.8xlarge`

MySQL のサイジングの表に記載されている本番環境向けの推奨構成は、最大 50K の run の幅に対応しています。

クラウドプロバイダーのインスタンスタイプに関する推奨事項

前述のサイジング表を基にノードごとの CPU、メモリ、ディスクの要件を把握したら、以下を参考に、要件を満たすクラウドプロバイダーのインスタンスタイプとマネージドサービスを選択してください。これらの推奨事項は、クラウドインフラストラクチャー上に Weights & Biases をセルフマネージドでデプロイする場合の各ノードに適用されます。

AWS
Google Cloud
Azure

推奨マネージドサービス

Kubernetes: Amazon EKS
MySQL: Amazon RDS Aurora
オブジェクトストレージ: Amazon S3

環境	K8s (Models のみ)	K8s (Weave のみ)	K8s (Models & Weave)	MySQL
Test/Dev	r6i.large	r6i.xlarge	r6i.xlarge	db.r6g.large
本番	r6i.2xlarge	r6i.4xlarge	r6i.4xlarge	db.r6g.2xlarge

推奨マネージドサービス

Kubernetes: Google Kubernetes Engine (GKE)
MySQL: Google Cloud SQL for MySQL
オブジェクトストレージ: Google Cloud Storage (GCS)

環境	K8s (Models のみ)	K8s (Weave のみ)	K8s (Models & Weave)	MySQL
Test/Dev	n2-highmem-2	n2-highmem-4	n2-highmem-4	db-n1-highmem-2
本番	n2-highmem-8	n2-highmem-16	n2-highmem-16	db-n1-highmem-8

推奨マネージドサービス

Kubernetes: Azure Kubernetes Service (AKS)
MySQL: Azure Database for MySQL
オブジェクトストレージ: Azure Blob Storage

環境	K8s (Models のみ)	K8s (Weave のみ)	K8s (Models & Weave)	MySQL
Test/Dev	Standard_E2_v5	Standard_E4_v5	Standard_E4_v5	MO_Standard_E2ds_v4
本番	Standard_E8_v5	Standard_E16_v5	Standard_E16_v5	MO_Standard_E8ds_v4

​始める前に

​インフラストラクチャー

​アプリケーション層

​ストレージ層

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

​Kubernetes

​MySQL

​MySQL のトポロジ

​MySQL データベースの作成

​MySQL 設定パラメーター

​Redis

​オブジェクトストレージ

​バージョン

​ネットワーク

​DNS

​ロードバランサーとイングレス

​Ingress コントローラー requirements

​Weights & Biases サービスのルーティング

​イングレス設定の例

​SSL/TLS

​サポートされる CPU アーキテクチャー

​デプロイ方法

​Helm を使用した W&B Kubernetes Operator

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

​サイジング

​Kubernetes のサイジング

​MySQL のサイジング

​run の幅に応じた MySQL のサイジング

​クラウドプロバイダーのインスタンスタイプに関する推奨事項

始める前に

インフラストラクチャー

アプリケーション層

ストレージ層

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

Kubernetes

MySQL

MySQL のトポロジ

MySQL データベースの作成

MySQL 設定パラメーター

Redis

オブジェクトストレージ

バージョン

ネットワーク

DNS

ロードバランサーとイングレス

Ingress コントローラー requirements

Weights & Biases サービスのルーティング

イングレス設定の例

SSL/TLS

サポートされる CPU アーキテクチャー

デプロイ方法

Helm を使用した W&B Kubernetes Operator

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

サイジング

Kubernetes のサイジング

MySQL のサイジング

run の幅に応じた MySQL のサイジング

クラウドプロバイダーのインスタンスタイプに関する推奨事項