> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Reference architecture > Review the reference architecture for self-managed W&B deployments covering Kubernetes, MySQL, object storage, and networking. このページでは、W\&B デプロイメントのリファレンスアーキテクチャについて説明し、本番デプロイメントをサポートするために推奨されるインフラストラクチャーとリソースの概要を示します。信頼性の高いセルフマネージドインストールに必要なコンポーネントのサイズ設定、プロビジョニング、統合のための計画ガイドとして使用してください。 このページは、独自のインフラストラクチャー上でW\&Bをデプロイおよび運用するプラットフォームエンジニア、サイト信頼性エンジニア、インフラストラクチャー管理者を対象としています。 W\&Bの選択したデプロイメント環境に応じて、さまざまなサービスがデプロイメントの回復力を強化するのに役立ちます。 たとえば、主要なクラウドプロバイダーは、データベースの設定、メンテナンス、高可用性、回復力の複雑さを軽減するマネージドデータベースサービスを提供しています。 このリファレンスアーキテクチャは、一般的なデプロイメントシナリオに対応し、パフォーマンスと信頼性のためにクラウドベンダーサービスとW\&Bデプロイメントを統合する方法を示します。

始める前に

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

インフラストラクチャー

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

アプリケーション層

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

ストレージ層

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

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

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

Kubernetes

W\&B は、複数の Pod をデプロイする [Kubernetes Operator](/ja/products/wandb/platform/hosting/self-managed/operator) として W\&B Server アプリケーションをデプロイします。このため、W\&B には以下を備えた Kubernetes クラスターが必要です。 * 完全に設定され、正常に機能するイングレスコントローラー。 * Persistent Volume をプロビジョニングする機能。 W\&B は、クラウド、オンプレミス、エアギャップ環境の [OpenShift Kubernetes クラスター](https://www.redhat.com/en/technologies/cloud-computing/openshift)へのデプロイをサポートします。具体的な設定手順については、オペレーターガイドの [OpenShift セクション](/ja/products/wandb/platform/hosting/self-managed/operator#openshift-kubernetes-clusters)を参照してください。

MySQL

MySQL 8.0.x は 2026 年 4 月にサポート終了を迎えました。W\&B Self-Managed のデプロイメントでは、セキュリティパッチと重要なバグ修正が提供される、サポート対象の MySQL バージョンを実行する必要があります。コミュニティ版 MySQL を使用している場合は、**MySQL 8.4.x** をインストールするか、8.4.x にアップグレードしてください。マネージドサービスを使用している場合は、プロバイダーがサポート対象かつパッチ適用済みとして明記しているエンジンバージョンを実行してください (例: Amazon RDS for MySQL、Google Cloud SQL for MySQL、Azure Database for MySQL)。W\&B は、MySQL 8.4.0 および現行の 8.4.x リリースでプラットフォームの動作を検証済みです。まだ MySQL 8.0.x を使用している場合は、[MySQL を 8.4.x にアップグレードする](/ja/products/wandb/platform/hosting/self-managed/operator#upgrade-mysql-to-84x) の手順を参照して、アップグレードを計画してください。 W\&B はメタデータを MySQL データベースに保存します。データベースに必要なパフォーマンスとストレージは、モデルのパラメーターや関連するメタデータの構造によって異なります。たとえば、トラッキングするトレーニング run が増えるとデータベースのサイズが大きくなり、run テーブル、ユーザーの workspace、report でのクエリに応じてデータベースの負荷が増加します。 **W\&B は、本番デプロイメントにはマネージドデータベースサービスの使用を強く推奨します** (AWS RDS Aurora MySQL、Google Cloud SQL for MySQL、Azure Database for MySQL など)。マネージドサービスは、自動バックアップ、モニタリング、高可用性、パッチ適用を提供し、運用の複雑さを軽減します。具体的なサービスの推奨事項については、[クラウドプロバイダーのインスタンスに関する推奨事項](#cloud-provider-instance-recommendations)セクションを参照してください。 セルフマネージドの MySQL データベースをデプロイする場合は、次の点を考慮してください。 * **バックアップ**: データベースを定期的に別の場所にバックアップします。W\&B は、少なくとも 1 週間の保持期間を設けた日次バックアップを推奨します。 * **パフォーマンス**: データベースには、SSD や高速 NAS など、高速なストレージハードウェアが必要です。 * **モニタリング**: データベースには十分な CPU リソースが必要です。データベースサーバーの CPU 負荷を監視してください。CPU 使用量がシステム全体の 90% を超える状態で 5 分以上続く場合は、CPU キャパシティの追加を検討してください。 * **可用性**: 可用性と耐久性の要件を満たすために、W\&B は別のマシンにホットスタンバイのデプロイメントを構成することを推奨します。スタンバイはプライマリのデプロイメントからすべての更新をリアルタイムで受信し、プライマリサーバーがクラッシュした場合、破損した場合、またはダウンタイムが長引いた場合に切り替えられる状態を維持します。

MySQL のトポロジ

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

MySQL データベースの作成

MySQL データベースとユーザーを手動で作成する手順については、[ベアメタルガイドの MySQL データベースセクション](/ja/products/wandb/platform/hosting/self-managed/operator#mysql-database)を参照してください。

MySQL 設定パラメーター

これらのパラメーターは、W\&B が大規模に実行する書き込みパターンとスキーマ変更に合わせて MySQL を調整します。独自の MySQL インスタンスを運用している場合は、以下の設定で MySQL を構成してください。 ```ini theme={"system"} 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 インスタンスに接続できます： * [AWS Elasticache](https://aws.amazon.com/elasticache/). * [Google Cloud Memory Store](https://cloud.google.com/memorystore?hl=en). * [Azure Cache for Redis](https://azure.microsoft.com/en-us/products/cache). * クラウドまたはオンプレミスのインフラストラクチャーでホストされる Redis デプロイメント。

オブジェクトストレージ

W\&B には、事前署名付き URL と CORS をサポートするオブジェクトストレージが必要です。次のいずれかにデプロイしてください。 * [CoreWeave AI Object Storage](/products/storage/object-storage) は、AI ワークロード向けに最適化された S3互換のオブジェクトストレージサービスです。 * [Amazon S3](https://aws.amazon.com/s3/) は、スケーラビリティ、データの可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。 * [Google Cloud Storage](https://cloud.google.com/storage) は、非構造化データを大規模に保存するためのマネージドサービスです。 * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs) は、テキスト、バイナリデータ、画像、動画、ログなどの非構造化データを保存するためのクラウドベースのオブジェクトストレージソリューションです。 * [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor)、[NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/)、またはクラウドやオンプレミスのインフラストラクチャーでホストされるその他のエンタープライズ向けソリューションなどの S3互換ストレージ。

バージョン

| ソフトウェア | 最低バージョン | | - | - | | Kubernetes | v1.34 以降 ([サポートされる Kubernetes バージョン](https://kubernetes.io/releases/patch-releases/)) | | 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html) は MySQL 8.0.x と互換性があり、引き続きサポートされています。移行先のバージョンを選択する際は、[Amazon Aurora のバージョン管理](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.Versioning.html) およびご利用のクラウドプロバイダーのドキュメントを参照してください。 | | Redis | v7.x | | ClickHouse | セルフマネージドのデプロイで Weave を使用する場合は必須です。Weave を使用しないデプロイメントでは不要です。[アップグレード時の ClickHouse 互換性](/ja/products/wandb/platform/hosting/self-managed/operator#clickhouse-compatibility-for-upgrades) および [サポートされる W\&B Server リリース](/ja/release-notes/server-releases) を参照してください。 |

ネットワーク

ネットワーク接続されたデプロイメントでは、インストール時と実行時の両方で、以下のエンドポイントへの外向き通信を許可してください。 * `https://deploy.wandb.ai` * `https://charts.wandb.ai` * `https://quay.io` (Prometheus のイメージに使用) デプロイメントの設定によっては、追加のコンテナーレジストリが必要になる場合があります。 * Weave のオンライン評価のために Bufstream と etcd をデプロイする場合は、`https://gcr.io`。 エアギャップ環境のデプロイメントについては、[エアギャップ環境のインスタンス向け Kubernetes Operator](/ja/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped)を参照してください。 トレーニング インフラストラクチャーと各実験管理システムに、W\&B とオブジェクトストレージへのアクセス権を付与してください。

DNS

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

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

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

Ingress controller requirements

Kubernetes クラスター では、`IngressClass` が利用可能である必要があります。一般的な イングレス コントローラー には、次の選択肢があります。 * [Nginx Ingress Controller](https://kubernetes.github.io/ingress-nginx/)。 * [Istio](https://istio.io)。 * [Traefik](https://traefik.io/)。 * cloud provider の イングレス コントローラー (AWS ALB、GCP Ingress、Azure Application Gateway) 。

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

W\&B Operator は、パスに基づいてリクエストを複数のバックエンドサービスに自動的にルーティングします。 | パス | サービス | デフォルトポート | 用途 | | - | - | - | - | | `/` | `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 リソースの例です： ```yaml theme={"system"} 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](https://letsencrypt.org) などのサービスを使用して、信頼された証明書をロードバランサーに提供してください。Caddy や Cloudflare などのサービスを利用すると、SSL の管理を任せることができます。 セキュリティポリシー上、信頼されたネットワーク内でも SSL 通信が必要な場合は、Istio などのツールと[サイドカーコンテナー](https://istio.io/latest/docs/reference/config/networking/sidecar/)の使用を検討してください。

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

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

デプロイ方法

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

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

W\&B Self-Managed の推奨インストール方法では、Helm を通じてデプロイされる **W\&B Kubernetes Operator** を使用します。この方法には、次の利点があります。 * W\&B コンポーネントの更新と管理の自動化。 * 設定とデプロイの簡素化。 * すべてのデプロイメントシナリオ (クラウド、オンプレミス、エアギャップ) へのサポート。 詳しいインストール手順については、以下を参照してください。 * [W\&B プラットフォームをオンプレミスにデプロイする](/ja/products/wandb/platform/hosting/self-managed/operator) - 基本となるインストールガイド。 * [エアギャップ環境のインスタンス向け Kubernetes Operator](/ja/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped) - 外部ネットワークから切り離された環境向け。

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

W\&B の本番デプロイメント向けインフラストラクチャーのプロビジョニングには、Terraform の使用を推奨します。Terraform では、必要なリソース、他のリソースへの参照、リソース間の依存関係を定義できます。W\&B は主要なクラウドプロバイダー向けに Terraform モジュールを提供しています。詳しくは、[セルフマネージドのクラウドアカウントに W\&B Server をデプロイする](/ja/products/wandb/platform/hosting/hosting-options/self-managed#deploy-wb-server-within-Self-Managed-cloud-accounts)をご覧ください。

サイジング

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

Kubernetes のサイジング

| 環境 | 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 | 数値は Kubernetes のワーカーノード 1 台あたりの値です。 | 環境 | CPU | メモリ | ディスク | | - | - | - | - | | Test/Dev | 4 コア | 32 GB | 100 GB | | 本番 | 16 コア | 128 GB | 100 GB | 数値は Kubernetes のワーカーノード 1 台あたりの値です。

MySQL のサイジング

これらの推奨事項は、プロダクトの組み合わせによって変わりません。トポロジと可用性に関するガイダンスについては、[MySQL](#mysql) の [MySQL のトポロジ](#mysql-topology) を参照してください。 | 環境 | CPU | メモリ | ディスク | | - | - | - | - | | Test/Dev | 2 コア | 16 GB | 100 GB | | 本番 | 8 コア | 64 GB | 500 GB | 数値は MySQL ノードあたりの値です。

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

前述のサイジング表を基にノードごとの CPU、メモリ、ディスクの要件を把握したら、以下を参考に、要件を満たすクラウドプロバイダーのインスタンスタイプとマネージドサービスを選択してください。これらの推奨事項は、クラウドインフラストラクチャー上に W\&B をセルフマネージドでデプロイする場合の各ノードに適用されます。 **推奨マネージドサービス** * **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 | ## Related topics - [Terraform reference architecture](/platform/reference-architecture.md)