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

​
開始前に

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

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

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

​
アプリケーション層

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

​
ストレージ層

ストレージ層は、MySQL データベースとオブジェクトストレージで構成されます。MySQL データベースにはメタデータが保存され、オブジェクトストレージにはモデルやデータセットなどのArtifactsが保存されます。

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

​
Kubernetes

W&B Server アプリケーションは、複数の pod をデプロイする Kubernetes Operator としてデプロイされます。そのため、W&B では次の要件を満たす Kubernetes クラスターが必要です。
  • 十分に設定され、正常に動作している Ingress controller。
  • Persistent Volumes をプロビジョニングできること。
W&B は、クラウド、オンプレミス、air-gapped 環境における OpenShift Kubernetes clusters へのデプロイをサポートします。具体的な設定手順については、Operator ガイドの OpenShift セクション を参照してください。

​
MySQL

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

​
MySQL データベースの作成

MySQL データベースとユーザーを手動で作成する手順については、ベアメタル ガイドの 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 デプロイに依存しています。テストや概念実証の開発を手軽に行えるよう、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 version は v3.05.2 以降である必要があります
Redisv7.x

​
ネットワーク

ネットワーク接続されたデプロイでは、インストール時とランタイム時の_両方で_、以下のエンドポイントへのアウトバウンド通信が必要です。
デプロイ設定によっては、追加のコンテナーレジストリが必要になる場合があります。
  • Weave のオンライン評価用に Bufstream と etcd をデプロイする場合は、https://gcr.io が必要です。
エアギャップ環境でのデプロイについては、エアギャップ環境向け Kubernetes Operatorを参照してください。 W&B とオブジェクトストレージへのアクセスは、トレーニングインフラストラクチャーと、Experiments の要件をトラッキングする各システムで必要です。

​
DNS

W&B デプロイの完全修飾ドメイン名 (FQDN) は、Aレコードで ingress/load balancer の IP アドレスに名前解決される必要があります。

​
ロードバランサーと ingress

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

​
ingress controller の要件

Kubernetes クラスターで IngressClass が利用可能である必要があります。一般的な ingress controller の選択肢は次のとおりです。

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

W&B Operator は、パスに応じてリクエストを複数のバックエンドサービスに自動的にルーティングします。
パスサービスデフォルトポート用途
/wandb-app8080メインの Web アプリケーション UI
/apiwandb-api8081API サービス
/graphqlwandb-api8081GraphQL API endpoint
/graphql2wandb-api8081GraphQL API v2 endpoint
/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 controller があり、適切な IngressClass が設定されていることを確認してください。

​
SSL/TLS

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

​
サポート対象のCPUアーキテクチャ

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

​
デプロイ方法

W&B セルフマネージド の推奨インストール方法は、Helm 経由で W&B Kubernetes Operator をデプロイすることです。この方法には、次の利点があります。
  • W&B コンポーネントの更新と管理を自動化できる
  • 設定とデプロイを簡素化できる
  • すべてのデプロイ シナリオ (クラウド、オンプレミス、air-gapped) をサポートする
詳細なインストール手順については、以下を参照してください。

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

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

​
サイジング

デプロイを計画する際は、まず以下の一般的なガイドラインを目安にしてください。W&B では、新しいデプロイのすべてのコンポーネントを注意深く監視し、実際に観測された使用パターンに基づいて調整することを推奨しています。最適なパフォーマンスを維持するため、本番デプロイは継続的に監視し、必要に応じて調整を行ってください。

​
Models のみ

​
Kubernetes

環境CPUメモリディスク
Test/Dev2 コア16 GB100 GB
本番8 コア64 GB100 GB
数値は Kubernetes の各ワーカーノードあたりです。

​
MySQL

環境CPUメモリディスク
Test/Dev2 コア16 GB100 GB
本番8 コア64 GB500 GB
各 MySQL ノードあたりの数値です。

​
Weaveのみ

​
Kubernetes

環境CPUメモリディスク
Test/Dev4 コア32 GB100 GB
本番12 コア96 GB100 GB
数値は Kubernetes の各ワーカーノードあたりです。

​
MySQL

環境CPUメモリディスク
Test/Dev2 コア16 GB100 GB
本番8 コア64 GB500 GB
数値は各 MySQL ノードあたりの値です。

​
Models および Weave

​
Kubernetes

環境CPUメモリディスク
Test/Dev4 コア32 GB100 GB
本番16 コア128 GB100 GB
数値は各 Kubernetes ワーカーノードあたりの値です。

​
MySQL

環境CPUメモリディスク
Test/Dev2 コア16 GB100 GB
本番8 コア64 GB500 GB
数値は各 MySQL ノードあたりの値です。

​
クラウドプロバイダごとの推奨インスタンス

​
サービス

クラウドKubernetesMySQLオブジェクトストレージ
AWSEKSRDS AuroraS3
Google CloudGKEGoogle Cloud SQL - MySQLGoogle Cloud Storage (GCS)
AzureAKSAzure Database for MySQLAzure Blob Storage

​
マシンタイプ

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

​
AWS

環境K8s (Models のみ)K8s (Weave のみ)K8s (Models & Weave)MySQL
Test/Devr6i.larger6i.xlarger6i.xlargedb.r6g.large
本番r6i.2xlarger6i.4xlarger6i.4xlargedb.r6g.2xlarge

​
Google Cloud

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

​
Azure

環境K8s (Models のみ)K8s (Weave のみ)K8s (Models & Weave)MySQL
Test/DevStandard_E2_v5Standard_E4_v5Standard_E4_v5MO_Standard_E2ds_v4
本番Standard_E8_v5Standard_E16_v5Standard_E16_v5MO_Standard_E8ds_v4