メインコンテンツへスキップ
このページでは、W&B のデプロイのためのリファレンスアーキテクチャを説明し、プラットフォームの本番運用を支えるために推奨されるインフラストラクチャとリソースについて概説します。 選択した W&B のデプロイ環境に応じて、さまざまなサービスを利用することで、デプロイのレジリエンスを高めることができます。 たとえば、主要なクラウドプロバイダーは、データベースの設定、運用、可用性、およびレジリエンスに関する複雑さを軽減する堅牢なマネージドデータベースサービスを提供しています。 このリファレンスアーキテクチャでは、一般的なデプロイシナリオのいくつかを取り上げ、W&B のデプロイをクラウドベンダーのサービスと統合して、パフォーマンスと信頼性を最適化する方法を示します。

​
開始する前に

本番環境でアプリケーションを実行する場合には固有の課題が伴い、W&B も例外ではありません。W&B はこのプロセスの簡素化を目指していますが、アーキテクチャや設計上の判断によっては、特有の複雑さが生じる可能性があります。一般に、本番環境へのデプロイを運用するということは、ハードウェア、オペレーティングシステム、ネットワーク、ストレージ、セキュリティ、W&B プラットフォーム本体、およびその他の依存コンポーネントなど、さまざまな要素を管理することを意味します。この責任は、環境の初期セットアップと、その後の継続的なメンテナンスの両方に及びます。 W&B を Self-Managed で運用するアプローチが、お客様のチームおよび特定の要件に適しているかどうかを慎重に検討してください。 本番グレードのアプリケーションを実行・運用する方法を十分に理解していることは、Self-Managed W&B をデプロイする前の重要な前提条件です。チームが支援を必要とする場合は、Professional Services チームやパートナーが、導入や最適化に関するサポートを提供します。 W&B を自分で運用する代わりに、マネージドなソリューションについて詳しく知りたい場合は、W&B Multi-tenant Cloud および W&B Dedicated Cloud を参照してください。

​
インフラストラクチャ

W&B インフラストラクチャの構成図

​
アプリケーション層

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

​
ストレージレイヤー

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

​
インフラ要件

​
Kubernetes

W&B Server アプリケーションは、複数の Pod をデプロイする Kubernetes Operator としてデプロイされます。このため、W&B には次の要件を満たす Kubernetes クラスターが必要です：
  • 適切に設定され正常に動作している Ingress コントローラ
  • Persistent Volumes をプロビジョニングする能力
W&B は、クラウド、オンプレミス、およびエアギャップ環境における OpenShift Kubernetes クラスター へのデプロイをサポートします。具体的な設定手順については、Operator ガイドの OpenShift セクション を参照してください。

​
MySQL

W&B はメタデータを MySQL データベースに保存します。データベースのパフォーマンスおよびストレージ要件は、モデルパラメータや関連メタデータの形状に依存します。たとえば、より多くの学習 run をトラッキングするとデータベースサイズが増加し、run テーブル、ユーザーのワークスペース、およびレポートに対するクエリに応じてデータベースへの負荷も増加します。 W&B は本番環境ではマネージドデータベースサービスの利用を強く推奨します（AWS RDS Aurora MySQL、Google Cloud SQL for MySQL、Azure Database for MySQL など）。マネージドサービスは自動バックアップ、モニタリング、高可用性、パッチ適用を提供し、運用の複雑さを大幅に軽減します。具体的なサービスの推奨事項については、以下の クラウドプロバイダーのインスタンス推奨 セクションを参照してください。 自前運用の MySQL データベースをデプロイする場合は、次の点を検討してください。
  • バックアップ: データベースは定期的に別の場所にバックアップする必要があります。W&B は、少なくとも 1 週間分を保持する毎日のバックアップを推奨します。
  • パフォーマンス: データベースには SSD や高速 NAS などの高速ストレージハードウェアが必要です。
  • モニタリング: データベースには十分な CPU リソースが必要です。データベースサーバーの CPU 負荷を監視してください。CPU 使用率がシステム全体の 90% を超える状態が 5 分以上継続する場合は、CPU キャパシティの追加を検討してください。
  • 可用性: 必要な可用性と耐久性を満たすために、W&B は別マシン上にホットスタンバイの Server デプロイメントを構成し、プライマリデプロイメントからのすべての更新をリアルタイムでストリーミングし、プライマリサーバーがクラッシュしたり破損したり、長時間のダウンタイムが発生した場合にフェイルオーバーできるようにすることを推奨します。なお、W&B はマルチマスタートポロジーや読み取り専用レプリカをサポートしていません。

​
MySQL データベースの作成

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

​
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
これらの設定は、最適なパフォーマンスと信頼性が得られることを W&B が検証済みです。

​
Redis

W&B は、ジョブキューイングとデータキャッシュのために W&B のコンポーネントで使用される、単一ノードの Redis 7.x デプロイメントに依存しています。テストや PoC（概念実証）の開発を容易にするために、W&B Self-Managed にはローカルの Redis デプロイメントが含まれていますが、これは本番環境での利用には適していません。 W&B は、次のような環境で稼働している Redis インスタンスに接続できます。

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

W&B には、事前署名付き URL と CORS をサポートするオブジェクトストレージが必要であり、次のいずれかとしてデプロイされている必要があります。
  • CoreWeave AI Object Storage は、AI ワークロード向けに最適化された高性能な S3 互換オブジェクトストレージサービスです。
  • Amazon S3 は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。
  • Google Cloud Storage は、大規模な非構造化データを保存するためのマネージドサービスです。
  • Azure Blob Storage は、テキスト、バイナリデータ、画像、動画、ログなどの大量の非構造化データを保存するためのクラウドベースのオブジェクトストレージソリューションです。
  • MinIO Enterprise (AIStor)、NetApp StorageGRID などの S3 互換ストレージ、またはクラウドもしくはオンプレミス環境でホストされるその他のエンタープライズグレードのソリューション。

​
対応バージョン

ソフトウェア最低バージョン
Kubernetesv1.32 以降（サポートされている Kubernetes のバージョン）
Helmv3.x
MySQLv8.0.x が必須で、v8.0.32 以降。ただし v8.0.44 以降を推奨。
Aurora MySQL 3.x リリースは v3.05.2 以上である必要があります
Redisv7.x

​
ネットワーク

ネットワーク接続されたデプロイメントでは、インストール時と実行時の_両方_で、次のエンドポイントへの送信（egress）が必要です：
デプロイメントの構成によっては、追加のコンテナレジストリが必要になる場合があります：
  • Weave のオンライン評価で Bufstream と etcd をデプロイする場合、https://gcr.io が必要です。
エアギャップ環境でのデプロイについては、エアギャップインスタンス向け Kubernetes オペレーター を参照してください。 学習用インフラストラクチャおよび各実験の要件をトラッキングする各システムには、W&B とオブジェクトストレージへのアクセスが必要です。

​
DNS

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

​
ロードバランサーと Ingress

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

​
Ingress controller の要件

Kubernetes クラスターには利用可能な IngressClass が必要です。一般的な Ingress controller のオプションには次のものがあります。

​
W&B サービスのルーティング

W&B Operator は、パスに応じて複数のバックエンドサービスへリクエストを自動的にルーティングします。
PathServiceDefault portPurpose
/wandb-app8080メインの Web アプリケーション UI
/apiwandb-api8081API サービス
/graphqlwandb-api8081GraphQL API エンドポイント
/graphql2wandb-api8081GraphQL API v2 エンドポイント
/consolewandb-console8082システムコンソール
/traceswandb-weave-trace8722Weave のトレーシングサービス（有効な場合）

​
Ingress 設定の例

以下は、W&B Operator によって作成された 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 Operator は、ingress の設定を自動的に作成および管理します。通常、ingress リソースを手動で作成する必要はありません。クラスターに動作する ingress コントローラがあり、適切な IngressClass が設定されていることを確認してください。

​
SSL/TLS

W&B では、クライアントとサーバー間の安全な通信のために、有効な署名付き SSL/TLS 証明書が必要です。SSL/TLS の終端は必ず ingress／ロードバランサー上で行う必要があります。W&B Server アプリケーションは SSL または TLS 接続を終端しません。 重要: W&B は自己署名証明書およびカスタム CA をサポートしません。自己署名証明書を使用するとユーザーにとって問題となり、サポート対象外となります。 可能であれば、Let’s Encrypt のようなサービスを利用することで、ロードバランサーに対して信頼された証明書を提供できます。Caddy や Cloudflare のようなサービスは、SSL を代行管理してくれます。 セキュリティポリシーによって、信頼済みネットワーク内でも SSL 通信が必要な場合は、Istio や サイドカーコンテナ のようなツールの利用を検討してください。

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

W&B は Intel および AMD の 64ビットアーキテクチャ上で動作します。ARM アーキテクチャはサポート対象外です。

​
デプロイ方法

Self-Managed 版 W&B の推奨インストール方法は、Helm 経由でデプロイする W&B Kubernetes Operator を使用する方法です。このアプローチにより、次のことが可能になります。
  • W&B コンポーネントの自動更新と管理
  • 設定およびデプロイの簡素化
  • すべてのデプロイシナリオ（クラウド、オンプレミス、エアギャップ環境）への対応
詳細なインストール手順については、次を参照してください。

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

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

​
サイジング

デプロイを計画する際の出発点として、次の一般的な指針を使用してください。W&B では、新しいデプロイのすべてのコンポーネントを注意深く監視し、観測された利用パターンに基づいて調整を行うことを推奨します。本番環境のデプロイについても継続的に監視を行い、最適なパフォーマンスを維持できるよう、必要に応じて調整を行ってください。

​
Models のみ

​
Kubernetes

EnvironmentCPUMemoryDisk
Test/Dev2 cores16 GB100 GB
Production8 cores64 GB100 GB
これらの数値は Kubernetes ワーカーノード 1 台あたりの値です。

​
MySQL

EnvironmentCPUMemoryDisk
Test/Dev2 cores16 GB100 GB
Production8 cores64 GB500 GB
各数値は MySQL ノード 1 台あたりの要件です。

​
Weave のみ

​
Kubernetes

環境CPUメモリディスク
テスト/開発4 cores32 GB100 GB
本番12 cores96 GB100 GB
数値は Kubernetes のワーカーノード 1 台あたりの値です。

​
MySQL

環境CPUメモリディスク
テスト／開発2 コア16 GB100 GB
本番8 コア64 GB500 GB
数値は MySQL ノード 1 台あたりの値です。

​
Models と Weave

​
Kubernetes

EnvironmentCPUMemoryDisk
Test/Dev4 コア32 GB100 GB
Production16 コア128 GB100 GB
数値は各 Kubernetes ワーカーノードあたりの値です。

​
MySQL

環境CPUメモリディスク
テスト/開発2 コア16 GB100 GB
本番8 コア64 GB500 GB
各値は MySQL ノード 1 台あたりの値です。

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

​
サービス

| クラウド | Kubernetes | MySQL | オブジェクトストレージ |
| ----------- | ------------ | ------------------------ | -------------------------- | | AWS | EKS | RDS Aurora | S3 | | Google Cloud | GKE | Google Cloud SQL - MySQL | Google Cloud Storage (GCS) | | Azure | AKS | Azure Database for MySQL | Azure Blob Storage |

​
マシンタイプ

これらの推奨事項は、クラウドインフラ上にセルフマネージド構成でデプロイされた W&B の各ノードに適用されます。

​
AWS

| 環境 | K8s (Models only) | K8s (Weave only) | K8s (Models&Weave) | MySQL |
| ----------- | ------------------ | ------------------ | ------------------- | ------------------ |
| テスト／開発 | r6i.large | r6i.xlarge | r6i.xlarge | db.r6g.large | | 本番 | r6i.2xlarge | r6i.4xlarge | r6i.4xlarge | db.r6g.2xlarge |

​
Google Cloud

| Environment | K8s (Models のみ) | K8s (Weave のみ) | K8s (Models & Weave) | MySQL |
| ----------- | ------------------ | ------------------ | --------------------- | ------------------ |
| Test/Dev | n2-highmem-2 | n2-highmem-4 | n2-highmem-4 | db-n1-highmem-2 | | Production | n2-highmem-8 | n2-highmem-16 | n2-highmem-16 | db-n1-highmem-8 |

​
Azure

| Environment | K8s (Models only) | K8s (Weave only) | K8s (Models&Weave) | MySQL |
| ----------- | ------------------ | ------------------ | ------------------- | ------------------- |
| テスト/開発環境 | 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 |