> ## Documentation Index > Fetch the complete documentation index at: https://wb-21fd5541-run-filter-ui-updates.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # リファレンスアーキテクチャ > Kubernetes、MySQL、オブジェクトストレージ、ネットワークを対象とした、セルフマネージドのW&Bデプロイ向けリファレンスアーキテクチャを確認します。 このページでは、W\&B のデプロイ向けリファレンスアーキテクチャについて説明し、プラットフォームの本番デプロイをサポートするために推奨されるインフラストラクチャーとリソースの概要を示します。これを計画ガイドとして使用し、信頼性の高いセルフマネージド インストールに必要なコンポーネントのサイジング、プロビジョニング、統合を行ってください。 このページは、自社のインフラストラクチャー上で W\&B をデプロイして運用するプラットフォームエンジニア、サイトリライアビリティエンジニア、インフラストラクチャー管理者を対象としています。 W\&B 用に選択したデプロイ環境によっては、さまざまなサービスを活用してデプロイのレジリエンスを強化できます。 たとえば、主要なクラウドプロバイダーはマネージドデータベースサービスを提供しており、これによりデータベースの設定、保守、高可用性、耐障害性に伴う複雑さを軽減できます。 このリファレンスアーキテクチャでは、一般的なデプロイシナリオを取り上げ、パフォーマンスと信頼性を実現するために、W\&B のデプロイをクラウドベンダーのサービスとどのように統合できるかを示します。
## 開始前に
本番環境でアプリケーションを運用するには、さまざまな固有の課題が伴います。W\&B も例外ではありません。W\&B はプロセスの簡素化を目指していますが、アーキテクチャや設計上の判断によっては、複雑さが生じることがあります。一般に、本番デプロイの管理では、ハードウェア、オペレーティングシステム、ネットワーク、storage、セキュリティ、W\&B プラットフォーム自体、さらにその他の依存関係を含むさまざまなコンポーネントを管理する必要があります。この責任は、環境の初期セットアップだけでなく、その後の継続的な保守にも及びます。 W\&B をセルフマネージドで運用するアプローチが、チームや要件に適しているかどうかを慎重に検討してください。 セルフマネージド版 W\&B をデプロイする前提として、本番環境レベルのアプリケーションを運用し、保守する方法を十分に理解していることが重要です。チームに支援が必要な場合は、W\&B Professional Services チームおよびパートナーが、実装と最適化のサポートを提供しています。 自分で管理する代わりに W\&B を利用できるマネージドソリューションの詳細については、[W\&B Multi-tenant Cloud](/ja/platform/hosting/hosting-options/multi_tenant_cloud) および [W\&B Dedicated Cloud](/ja/platform/hosting/hosting-options/dedicated-cloud) を参照してください。
## インフラストラクチャー
W\&B のデプロイメントは、アプリケーション層とストレージ層で構成されています。次の図は、これらのレイヤーの関係を示したもので、以降の各サブセクションでそれぞれについて説明します。 W&Bのインフラストラクチャー図
### アプリケーション層
アプリケーション層は、ノード障害に対する耐障害性を備えたマルチノードの Kubernetes クラスターで構成されています。Kubernetes クラスターは W\&B の pod を実行し、管理します。
### ストレージ層
ストレージ層は、MySQL データベースとオブジェクトストレージで構成されます。MySQL データベースにはメタデータが保存され、オブジェクトストレージにはモデルやデータセットなどのArtifactsが保存されます。
## インフラストラクチャー要件
以下のセクションでは、Kubernetes クラスターの詳細、MySQL、Redis、オブジェクトストレージ、ソフトウェアバージョン、ネットワーク、DNS、ロードバランサーと ingress、SSL/TLS、サポートされる CPU アーキテクチャなど、W\&B のデプロイメントに関する各種要件を詳しく説明します。デプロイメントを開始する前に、お使いの環境がこれらすべての要件を満たしていることを確認してください。
### Kubernetes
W\&B は、複数の pod をデプロイする [Kubernetes Operator](/ja/platform/hosting/self-managed/operator) として W\&B Server アプリケーションをデプロイします。そのため、W\&B では次の要件を満たす Kubernetes クラスターが必要です。 * 十分に設定され、正常に動作している Ingress controller。 * Persistent Volumes をプロビジョニングできること。 W\&B は、クラウド、オンプレミス、air-gapped 環境における [OpenShift Kubernetes clusters](https://www.redhat.com/en/technologies/cloud-computing/openshift) へのデプロイをサポートします。具体的な設定手順については、Operator ガイドの [OpenShift セクション](/ja/platform/hosting/self-managed/operator#openshift-kubernetes-clusters) を参照してください。
### MySQL
W\&B はメタデータを MySQL データベースに保存します。データベースのパフォーマンス要件とストレージ要件は、モデル パラメーターの形状や関連メタデータに応じて変わります。たとえば、トラッキングするトレーニング run が増えるほどデータベースのサイズは大きくなり、run テーブル、ユーザー Workspace、Reports でのクエリに応じてデータベースの負荷も増加します。 **W\&B は、本番デプロイではマネージドデータベースサービスの使用を強く推奨します** (AWS RDS Aurora MySQL、Google Cloud SQL for MySQL、Azure Database for MySQL など) 。マネージドサービスでは、自動バックアップ、監視、高可用性、パッチ適用が提供され、運用の複雑さを軽減できます。具体的なサービスの推奨事項については、[クラウドプロバイダーのインスタンス推奨事項](#cloud-provider-instance-recommendations) セクションを参照してください。 セルフマネージドの MySQL データベースをデプロイする場合は、次の点を考慮してください。 * **Backups**: 定期的に、別の場所にデータベースをバックアップしてください。W\&B は、少なくとも 1 週間の保持期間を設けた日次バックアップを推奨します。 * **Performance**: データベースには、SSD や高速な NAS などの高速ストレージ ハードウェアが必要です。 * **Monitoring**: データベースには十分な CPU リソースが必要です。データベースサーバーの CPU 負荷を監視してください。CPU 使用率がシステム全体の 90% を超えた状態で 5 分以上継続する場合は、CPU リソースの増強を検討してください。 * **Availability**: 可用性と耐久性の要件を満たすために、W\&B は、別のマシン上にホットスタンバイ デプロイを構成することを推奨します。スタンバイは、プライマリデプロイからすべての更新をリアルタイムでストリーミングし、プライマリサーバーがクラッシュした場合、破損した場合、または継続的なダウンタイムが発生した場合にフェイルオーバーできるよう待機します。
#### MySQL のトポロジ
本番環境では、高可用性を実現する最も簡単な方法は、マネージド MySQL サービスを使用することです。フェイルオーバー、バックアップ、パッチ適用はクラウドプロバイダが処理するためです。たとえば、AWS の Aurora Multi-AZ など、プロバイダの高可用性オプションを使用してください。 セルフマネージド MySQL を使用する場合は、リアルタイムレプリケーションストリームを受信し、障害発生時に引き継げるホットスタンバイを備えたプライマリデータベースを使用してください。W\&B は、アプリケーションデータベースに対するマルチプライマリトポロジや読み取り専用レプリカをサポートしていません。
#### MySQL データベースの作成
MySQL データベースとユーザーを手動で作成する手順については、[ベアメタル ガイドの MySQL データベース セクション](/ja/platform/hosting/self-managed/operator#mysql-database)を参照してください。
#### MySQL の設定パラメーター
これらのパラメーターは、W\&B が大規模に行う書き込みパターンやスキーマの変更に合わせて MySQL を調整するためのものです。独自の MySQL インスタンスを実行している場合は、以下の設定を使用して MySQL を構成してください。 ```ini theme={null} 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 セルフマネージド にはローカルの 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](https://docs.coreweave.com/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.32 以降 ([サポートされる Kubernetes バージョン](https://kubernetes.io/releases/patch-releases/)) | | Helm | v3.x | | MySQL | v8.0.x が必須です (v8.0.32 以降) 。v8.0.44 以降を推奨します。
Aurora MySQL 3.x version は v3.05.2 以降である必要があります | | Redis | v7.x |
### ネットワーク
ネットワーク接続されたデプロイでは、インストール時とランタイム時の\_両方で\_、以下のエンドポイントへのアウトバウンド通信が必要です。 * [https://deploy.wandb.ai](https://deploy.wandb.ai) * [https://charts.wandb.ai](https://charts.wandb.ai) * [https://quay.io](https://quay.io) (Prometheus イメージで使用) デプロイ設定によっては、追加のコンテナーレジストリが必要になる場合があります。 * Weave のオンライン評価用に Bufstream と etcd をデプロイする場合は、`https://gcr.io` が必要です。 エアギャップ環境でのデプロイについては、[エアギャップ環境向け Kubernetes Operator](/ja/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped)を参照してください。 W\&B とオブジェクトストレージへのアクセスは、トレーニングインフラストラクチャーと、Experiments の要件をトラッキングする各システムで必要です。
### DNS
W\&B デプロイの完全修飾ドメイン名 (FQDN) は、`A` レコードを使用して ingress または ロードバランサー の IP アドレスに名前解決される必要があります。
### ロードバランサーと ingress
W\&B Kubernetes Operator は、URL パスに基づいて異なるポートのサービスエンドポイントにルーティングする Kubernetes ingress controller を使用して、サービスを公開できます。ingress controller には、機械学習ペイロードを実行するすべてのマシン、または Web ブラウザー経由でサービスにアクセスするすべてのマシンからアクセスできる必要があります。
#### ingress controller の要件
Kubernetes クラスターで `IngressClass` が利用可能である必要があります。一般的な ingress controller の選択肢は次のとおりです。 * [Nginx Ingress Controller](https://kubernetes.github.io/ingress-nginx/). * [Istio](https://istio.io). * [Traefik](https://traefik.io/). * クラウドプロバイダの ingress controller (AWS ALB、GCP Ingress、Azure Application Gateway).
#### W\&B サービスのルーティング
W\&B Operator は、パスに応じてリクエストを複数のバックエンドサービスに自動的にルーティングします。 | パス | サービス | デフォルトポート | 用途 | | ----------- | ------------------- | -------- | ----------------------- | | `/` | `wandb-app` | 8080 | メインの Web アプリケーション UI | | `/api` | `wandb-api` | 8081 | API サービス | | `/graphql` | `wandb-api` | 8081 | GraphQL API endpoint | | `/graphql2` | `wandb-api` | 8081 | GraphQL API v2 endpoint | | `/console` | `wandb-console` | 8082 | システムコンソール | | `/traces` | `wandb-weave-trace` | 8722 | Weave トレースサービス (有効な場合) |
#### ingress の設定例
以下は、W\&B Operator によって作成された ingress リソースの例です。 ```yaml theme={null} 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](https://letsencrypt.org) のようなサービスを使用して、load balancer に信頼できる証明書を提供するのが効果的です。Caddy や Cloudflare のようなサービスを使えば、SSL を代わりに管理できます。 セキュリティポリシーで、信頼できるネットワーク内でも SSL 通信が必要な場合は、Istio のようなツールや [side car containers](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 セルフマネージド の推奨インストール方法では、Helm 経由で **W\&B Kubernetes Operator** をデプロイします。この方法には、次の利点があります。 * W\&B コンポーネントの更新と管理を自動化できる。 * 設定とデプロイを簡素化できる。 * すべてのデプロイ シナリオ (クラウド、オンプレミス、air-gapped) をサポートする。 詳細なインストール手順については、以下を参照してください。 * [オンプレミス環境に W\&B Platform をデプロイする](/ja/platform/hosting/self-managed/operator) - メインのインストール ガイド。 * [air-gapped インスタンス向け Kubernetes operator](/ja/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped) - 外部接続のない環境向け。
### インフラストラクチャーのプロビジョニング
W\&Bの本番デプロイ向けのインフラストラクチャーをプロビジョニングするには、Terraformの使用を推奨します。Terraformを使用すると、必要なリソース、それらがほかのリソースを参照する関係、そして依存関係を定義できます。W\&Bは、主要なクラウドプロバイダ向けのTerraformモジュールを提供しています。詳細は、[セルフマネージドのクラウドアカウント内にW\&B Serverをデプロイする](/ja/platform/hosting/hosting-options/self-managed#deploy-wb-server-within-Self-Managed-cloud-accounts)を参照してください。
## サイジング
デプロイを計画する際は、まず以下のガイドラインを目安にしてください。W\&B では、デプロイのすべてのコンポーネントを注意深く監視し、実際に観測された使用パターンに基づいて調整することを推奨しています。パフォーマンスを維持するため、本番デプロイは継続的に監視し、必要に応じて調整を行ってください。 容量を計画する際は、2 つの中核コンポーネントのサイジングを行います。1 つは W\&B Operator ワークロード用の Kubernetes クラスター、もう 1 つはメタデータ用の MySQL データベースです。推奨事項は、**環境** (Test/Dev または Production) と、Kubernetes の場合のみ、**プロダクト構成** (Models のみ、Weave のみ、または Models と Weave) によって異なります。W\&B では、Test/Dev と Production の両方で最小 3 台のワーカーノードから開始し、Production ではクラスターオートスケーリングを有効にすることを推奨しています。 以下のセクションでは、Kubernetes クラスターと MySQL データベースのノードごとのサイジング推奨事項を示します。
### Kubernetes のサイジング
| 環境 | CPU | メモリ | ディスク | | -------- | ---- | ----- | ------ | | Test/Dev | 2 コア | 16 GB | 100 GB | | 本番 | 8 コア | 64 GB | 100 GB | 数値は各 Kubernetes ワーカーノードあたりの値です。 | 環境 | CPU | メモリ | ディスク | | -------- | ----- | ----- | ------ | | Test/Dev | 4 コア | 32 GB | 100 GB | | 本番 | 12 コア | 96 GB | 100 GB | 数値は各 Kubernetes ワーカーノードあたりの値です。 | 環境 | CPU | メモリ | ディスク | | -------- | ----- | ------ | ------ | | Test/Dev | 4 コア | 32 GB | 100 GB | | 本番 | 16 コア | 128 GB | 100 GB | 数値は各 Kubernetes ワーカーノードあたりの値です。
### 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 |