> ## 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. # Architecture de référence > Consultez l’architecture de référence des déploiements W&B autogérés : Kubernetes, MySQL, stockage d’objets et réseau. Cette page décrit une architecture de référence pour un déploiement W\&B et présente l’infrastructure et les ressources recommandées pour un déploiement de la plateforme en production. Utilisez-la comme guide de planification pour dimensionner, provisionner et intégrer les composants nécessaires à une installation autogérée fiable. Cette page s’adresse aux ingénieurs plateforme, aux ingénieurs en fiabilité des sites (SRE) et aux administrateurs d’infrastructure qui déploient et exploitent W\&B sur leur propre infrastructure. Selon l’environnement de déploiement choisi pour W\&B, différents services peuvent contribuer à renforcer la résilience de votre déploiement. Par exemple, les principaux fournisseurs de cloud proposent des services de base de données managés qui simplifient la configuration, la maintenance, la haute disponibilité et la résilience des bases de données. Cette architecture de référence couvre des scénarios de déploiement courants et montre comment intégrer votre déploiement W\&B aux services des fournisseurs de cloud pour gagner en performances et en fiabilité.

Avant de commencer

Exécuter une application en production comporte toujours son lot de défis, et W\&B ne fait pas exception. Bien que W\&B s’efforce de simplifier le processus, certaines difficultés peuvent survenir selon votre architecture et vos choix de conception. En règle générale, la gestion d’un déploiement en production implique de superviser des composants tels que le matériel, les systèmes d’exploitation, le réseau, le stockage, la sécurité, la plateforme W\&B elle-même et d’autres dépendances. Cette responsabilité englobe aussi bien la configuration initiale de l’environnement que sa maintenance au quotidien. Évaluez avec soin si une approche autogérée de W\&B convient à votre équipe et à vos exigences. Une solide maîtrise de l’exploitation et de la maintenance d’applications en production est un prérequis indispensable avant de déployer W\&B en mode autogéré. Si votre équipe a besoin d’aide, l’équipe W\&B Professional Services et ses partenaires proposent une assistance pour la mise en œuvre et l’optimisation. Pour en savoir plus sur les solutions gérées qui vous permettent d’exécuter W\&B sans avoir à le gérer vous-même, reportez-vous à [Cloud mutualisé de W\&B](/fr/products/wandb/platform/hosting/hosting-options/multi_tenant_cloud) et à [Cloud dédié de W\&B](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud).

Infrastructure

Un déploiement W\&B se compose d’une couche applicative et d’une couche de stockage. Le diagramme suivant montre comment ces couches s’articulent, et les sous-sections suivantes décrivent chacune d’elles. Diagramme de l’infrastructure W&B

Couche applicative

La couche applicative repose sur un cluster Kubernetes multi-nœuds, résilient aux défaillances de nœuds. Ce cluster Kubernetes exécute et maintient les pods W\&B.

Couche de stockage

La couche de stockage se compose d’une base de données MySQL et d’un stockage d’objets. La base de données MySQL stocke les métadonnées, tandis que le stockage d’objets héberge les artifacts, comme les modèles et les jeux de données.

Exigences d’infrastructure

Les sections suivantes détaillent les exigences d’un déploiement W\&B : caractéristiques du cluster Kubernetes, MySQL, Redis, stockage d’objets, versions logicielles, réseau, DNS, équilibreur de charge et ingress, SSL/TLS, ainsi que les architectures de CPU prises en charge. Avant de lancer un déploiement, vérifiez que votre environnement satisfait à chacune de ces exigences.

Kubernetes

W\&B déploie l’application serveur W\&B sous la forme d’un [opérateur Kubernetes](/fr/products/wandb/platform/hosting/self-managed/operator), qui lance lui-même plusieurs pods. C’est pourquoi W\&B exige un cluster Kubernetes disposant des éléments suivants : * Un contrôleur d’ingress entièrement configuré et opérationnel. * La possibilité de provisionner des Persistent Volumes. W\&B prend en charge le déploiement sur des [clusters Kubernetes OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift) dans le cloud, sur site et dans des environnements isolés du réseau. Pour obtenir les instructions de configuration propres à OpenShift, consultez la [section OpenShift](/fr/products/wandb/platform/hosting/self-managed/operator#openshift-kubernetes-clusters) du guide de l’opérateur.

MySQL

MySQL 8.0.x a atteint sa fin de vie en avril 2026. Les déploiements W\&B autogérés doivent exécuter une version de MySQL prise en charge qui bénéficie encore des correctifs de sécurité et des corrections de bugs critiques. Si vous utilisez MySQL Community, installez **MySQL 8.4.x** ou effectuez une mise à niveau vers cette version. Si vous utilisez un service géré, exécutez une version du moteur que votre fournisseur indique comme prise en charge et à jour des correctifs (par exemple Amazon RDS for MySQL, Google Cloud SQL for MySQL ou Azure Database for MySQL). W\&B a validé la plateforme avec MySQL 8.4.0 et les versions 8.4.x actuelles. Si vous utilisez encore MySQL 8.0.x, planifiez une mise à niveau en suivant les étapes décrites dans [Mettre à niveau MySQL vers 8.4.x](/fr/products/wandb/platform/hosting/self-managed/operator#upgrade-mysql-to-84x). W\&B stocke les métadonnées dans une base de données MySQL. Les exigences de performances et de stockage de la base de données dépendent de la forme des paramètres du modèle et des métadonnées associées. Par exemple, la taille de la base de données augmente à mesure que vous suivez davantage de runs d’entraînement, et sa charge augmente en fonction des requêtes effectuées dans les tableaux de runs, les workspaces des utilisateurs et les rapports. **W\&B recommande vivement d’utiliser des services de base de données managés** (tels qu’AWS RDS Aurora MySQL, Google Cloud SQL for MySQL ou Azure Database for MySQL) pour les déploiements en production. Les services managés assurent les sauvegardes automatisées, la surveillance, la haute disponibilité et le patching, tout en réduisant la complexité opérationnelle. Consultez la section [Recommandations d’instances des fournisseurs de cloud](#cloud-provider-instance-recommendations) pour obtenir des recommandations de services spécifiques. Si vous choisissez de déployer une base de données MySQL autogérée, tenez compte des points suivants : * **Sauvegardes** : sauvegardez régulièrement la base de données vers un site distinct. W\&B recommande des sauvegardes quotidiennes conservées pendant au moins une semaine. * **Performances** : la base de données nécessite un matériel de stockage rapide, tel qu’un SSD ou un NAS accéléré. * **Surveillance** : la base de données nécessite des ressources CPU suffisantes. Surveillez la charge CPU du serveur de base de données. Si l’utilisation du CPU du système reste supérieure à 90 % pendant plus de 5 minutes, envisagez d’ajouter de la capacité CPU. * **Disponibilité** : pour répondre à vos exigences de disponibilité et de durabilité, W\&B recommande de configurer un déploiement de secours à chaud (hot standby) sur une machine distincte. L’instance de secours reçoit en temps réel toutes les mises à jour du déploiement principal et est prête à prendre le relais si le serveur principal plante, est corrompu ou subit une interruption de service prolongée.

Topologie MySQL

En production, un service MySQL managé est la solution la plus simple pour assurer la haute disponibilité, car le fournisseur de cloud prend en charge le basculement, les sauvegardes et le patching. Utilisez l’option de haute disponibilité proposée par le fournisseur, par exemple Aurora Multi-AZ sur AWS. Si vous exploitez MySQL en mode autogéré, utilisez une base de données principale associée à une instance de secours à chaud (secours à chaud) qui reçoit un flux de réplication en temps réel et peut prendre le relais en cas de défaillance. W\&B ne prend en charge ni les topologies multi-primaires ni les réplicas en lecture seule pour la base de données de l’application.

Création de la base de données MySQL

Pour créer manuellement la base de données MySQL et l’utilisateur, consultez la [section consacrée à la base de données MySQL du guide bare metal](/fr/products/wandb/platform/hosting/self-managed/operator#mysql-database).

Paramètres de configuration de MySQL

Ces paramètres optimisent MySQL pour les schémas d’écriture et les modifications de schéma que W\&B effectue à grande échelle. Si vous exécutez votre propre instance MySQL, configurez-la avec les paramètres suivants : ```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 a validé ces paramètres du point de vue des performances et de la fiabilité.

Redis

W\&B s’appuie sur un déploiement Redis 7.x à nœud unique, que les composants W\&B utilisent pour la mise en file d’attente des jobs et la mise en cache des données. Pour faciliter les tests et le développement de preuves de concept, W\&B autogéré inclut un déploiement Redis local, qui n’est pas adapté aux déploiements de production. W\&B peut se connecter à une instance Redis dans les environnements suivants : * [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). * Un déploiement Redis hébergé dans votre cloud ou sur votre infrastructure sur site.

Stockage d’objets

W\&B nécessite un stockage d’objets prenant en charge les URL pré-signées et CORS, déployé sur l’une des solutions suivantes : * [CoreWeave AI Object Storage](/products/storage/object-storage) est un service de stockage d’objets compatible S3, optimisé pour les charges de travail d’IA. * [Amazon S3](https://aws.amazon.com/s3/) est un service de stockage d’objets qui offre évolutivité, disponibilité des données, sécurité et performances. * [Google Cloud Storage](https://cloud.google.com/storage) est un service managé permettant de stocker des données non structurées à grande échelle. * [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs) est une solution de stockage d’objets dans le cloud permettant de stocker des données non structurées telles que du texte, des données binaires, des images, des vidéos et des journaux. * Un stockage compatible S3, comme [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor), [NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/) ou d’autres solutions de niveau entreprise hébergées dans votre cloud ou sur votre infrastructure sur site.

Versions

| Logiciel | Version minimale | | - | - | | Kubernetes | v1.34 ou ultérieure ([Versions de Kubernetes prises en charge](https://kubernetes.io/releases/patch-releases/)) | | Helm | v3.x | | MySQL | Les déploiements W\&B autogérés doivent exécuter une version de MySQL prise en charge qui bénéficie des patchs de sécurité et des corrections de bugs critiques. Installez **MySQL 8.4.x** ou effectuez une mise à niveau vers cette version, ou utilisez une version de service managé que votre fournisseur indique comme prise en charge et maintenue à jour.
Les chaînes de version d’Aurora MySQL diffèrent de celles des versions communautaires de MySQL. Utilisez `SELECT version()` pour afficher la chaîne de version complète du moteur et `SELECT aurora_version()` pour afficher la version d’Aurora. [Aurora MySQL version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html) est compatible avec MySQL 8.0.x et reste prise en charge. Pour choisir une version cible, consultez [Gestion des versions d’Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.VersionPolicy.Versioning.html) ainsi que la documentation de votre fournisseur de cloud. | | Redis | v7.x | | ClickHouse | Requis pour Weave sur les déploiements autogérés. Non requis si votre déploiement n’utilise pas Weave. Voir [Compatibilité de ClickHouse pour les mises à niveau](/fr/products/wandb/platform/hosting/self-managed/operator#clickhouse-compatibility-for-upgrades) et [Versions du serveur W\&B prises en charge](/fr/release-notes/server-releases). |

Réseau

Pour un déploiement connecté au réseau, autorisez le trafic sortant vers les points de terminaison suivants, aussi bien pendant l’installation que pendant l’exécution : * `https://deploy.wandb.ai` * `https://charts.wandb.ai` * `https://quay.io` (utilisé pour les images Prometheus) Selon la configuration de votre déploiement, d’autres registres de conteneurs peuvent être nécessaires : * `https://gcr.io` si vous déployez Bufstream et etcd pour les évaluations en ligne de Weave. Pour en savoir plus sur les déploiements isolés du réseau, consultez [Opérateur Kubernetes pour les instances isolées du réseau](/fr/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped). Accordez à l’infrastructure d’entraînement et à chaque système de suivi des expériences l’accès à W\&B et au stockage d’objets.

DNS

Le nom de domaine complet (FQDN) du déploiement W\&B doit pointer vers l’adresse IP de l’ingress ou de l’équilibreur de charge au moyen d’un enregistrement `A`.

Équilibreur de charge et ingress

L’opérateur Kubernetes W\&B peut exposer des services à l’aide d’un contrôleur d’ingress Kubernetes, qui achemine le trafic vers les points de terminaison des services en fonction des chemins d’URL, sur différents ports. Le contrôleur d’ingress doit être accessible depuis toutes les machines qui exécutent des charges utiles de machine learning ou qui accèdent au service via un navigateur web.

Exigences relatives au contrôleur d’ingress

Une `IngressClass` doit être disponible dans votre cluster Kubernetes. Parmi les contrôleurs d’ingress courants, citons : * [Nginx Ingress Controller](https://kubernetes.github.io/ingress-nginx/). * [Istio](https://istio.io). * [Traefik](https://traefik.io/). * Les contrôleurs d’ingress des fournisseurs de cloud (AWS ALB, GCP Ingress et Azure Application Gateway).

Acheminement du service W\&B

Le W\&B Operator achemine automatiquement les requêtes vers plusieurs services backend en fonction du chemin : | Chemin | Service | Port par défaut | Rôle | | - | - | - | - | | `/` | `wandb-app` | 8080 | Interface utilisateur principale de l’application web | | `/api` | `wandb-api` | 8081 | Service d’API | | `/graphql` | `wandb-api` | 8081 | Point de terminaison de l’API GraphQL | | `/graphql2` | `wandb-api` | 8081 | Point de terminaison de l’API GraphQL v2 | | `/console` | `wandb-console` | 8082 | System Console | | `/traces` | `wandb-weave-trace` | 8722 | Service de traçage Weave (s’il est activé) |

Exemple de configuration d’ingress

Voici un exemple de ressource ingress créée par le W\&B Operator : ```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 ``` Le W\&B Operator crée et gère automatiquement la configuration de l’ingress. En règle générale, vous n'avez pas besoin de créer manuellement des ressources d’ingress. Assurez-vous que votre cluster dispose d’un contrôleur d’ingress opérationnel et que l’`IngressClass` appropriée est configurée.

SSL/TLS

W\&B nécessite un certificat SSL/TLS valide et signé pour sécuriser les communications entre les clients et le serveur. La terminaison SSL/TLS doit être effectuée au niveau de l’ingress ou de l’équilibreur de charge. L’application serveur W\&B n’assure pas la terminaison des connexions SSL ou TLS. W\&B ne prend pas en charge les certificats autosignés ni les autorités de certification (CA) personnalisées. Les certificats autosignés posent des problèmes aux utilisateurs et ne sont pas pris en charge. Dans la mesure du possible, utilisez un service comme [Let's Encrypt](https://letsencrypt.org) pour fournir des certificats de confiance à votre équilibreur de charge. Des services comme Caddy et Cloudflare gèrent le SSL pour vous. Si vos politiques de sécurité exigent des communications SSL au sein de vos réseaux de confiance, envisagez d’utiliser un outil comme Istio avec des [conteneurs sidecar](https://istio.io/latest/docs/reference/config/networking/sidecar/).

Architectures de CPU prises en charge

W\&B fonctionne sur les architectures 64 bits Intel et AMD. L’architecture ARM n’est pas prise en charge.

Méthode de déploiement

Une fois que votre infrastructure répond aux exigences ci-dessus, choisissez la manière d’installer W\&B et de provisionner les ressources sous-jacentes. Les sections suivantes décrivent la méthode de déploiement recommandée ainsi que l’approche conseillée pour le provisionnement de l’infrastructure.

Opérateur Kubernetes W\&B avec Helm

La méthode d’installation recommandée pour W\&B autogéré repose sur l’**opérateur Kubernetes W\&B**, déployé via Helm. Cette approche offre : * Des mises à jour et une gestion automatisées des composants W\&B. * Une configuration et un déploiement simplifiés. * La prise en charge de tous les scénarios de déploiement (cloud, sur site et isolé du réseau). Pour des instructions d’installation détaillées, voir : * [Déployer W\&B Platform sur site](/fr/products/wandb/platform/hosting/self-managed/operator) - Guide d’installation principal. * [Opérateur Kubernetes pour les instances isolées du réseau](/fr/products/wandb/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped) - Pour les environnements déconnectés.

Provisionnement de l’infrastructure

Terraform est la méthode recommandée pour provisionner l’infrastructure des déploiements W\&B en production. Avec Terraform, vous définissez les ressources requises, leurs références à d’autres ressources ainsi que leurs dépendances. W\&B fournit des modules Terraform pour les principaux fournisseurs de cloud. Pour plus de détails, reportez-vous à [Déployer le serveur W\&B dans des comptes cloud autogérés](/fr/products/wandb/platform/hosting/hosting-options/self-managed#deploy-wb-server-within-Self-Managed-cloud-accounts).

Dimensionnement

Utilisez les recommandations suivantes comme point de départ pour planifier un déploiement. W\&B recommande de surveiller étroitement tous les composants d’un déploiement et de procéder à des ajustements en fonction des schémas d’utilisation observés. Continuez à surveiller les déploiements en production dans la durée et ajustez-les si nécessaire pour maintenir les performances. Pour planifier la capacité, vous devez dimensionner deux composants principaux : un cluster Kubernetes pour la charge de travail du W\&B Operator et une base de données MySQL pour les métadonnées. Les recommandations varient selon l’**environnement** (Test/Dév ou Production) et, pour Kubernetes uniquement, selon la **combinaison de produits** (Models uniquement, Weave uniquement, ou Models et Weave). W\&B recommande de commencer avec au minimum 3 nœuds workers, en Test/Dév comme en Production, et d’activer l’autoscaling du cluster en Production. Les sections suivantes fournissent des recommandations de dimensionnement par nœud pour le cluster Kubernetes et la base de données MySQL.

Dimensionnement Kubernetes

| Environnement | CPU | Mémoire | Disque | | - | - | - | - | | Test/Dév | 2 cœurs | 16 Go | 100 Go | | Production | 8 cœurs | 64 Go | 100 Go | Les valeurs indiquées s’entendent par nœud worker Kubernetes. | Environnement | CPU | Mémoire | Disque | | - | - | - | - | | Test/Dév | 4 cœurs | 32 Go | 100 Go | | Production | 12 cœurs | 96 Go | 100 Go | Les valeurs indiquées s’entendent par nœud worker Kubernetes. | Environnement | CPU | Mémoire | Disque | | - | - | - | - | | Test/Dév | 4 cœurs | 32 Go | 100 Go | | Production | 16 cœurs | 128 Go | 100 Go | Les valeurs indiquées s’entendent par nœud worker Kubernetes.

Dimensionnement de MySQL

Ces recommandations ne dépendent pas de la combinaison de produits utilisée. Pour obtenir des conseils sur la topologie et la disponibilité, consultez [Topologie MySQL](#mysql-topology) dans la section [MySQL](#mysql). | Environnement | CPU | Mémoire | Disque | | - | - | - | - | | Test/Dév | 2 cœurs | 16 Go | 100 Go | | Production | 8 cœurs | 64 Go | 500 Go | Les valeurs indiquées s’entendent par nœud MySQL.

Recommandations d’instances par fournisseur de cloud

Une fois que vous avez déterminé les exigences en CPU, en mémoire et en disque par nœud à l’aide des tableaux de dimensionnement précédents, appuyez-vous sur les recommandations suivantes pour choisir les types d’instances et les services managés du fournisseur de cloud qui répondent à ces exigences. Ces recommandations s’appliquent à chaque nœud d’un déploiement autogéré de W\&B dans une infrastructure cloud. **Services managés recommandés** * **Kubernetes** : Amazon EKS * **MySQL** : Amazon RDS Aurora * **Stockage d’objets** : Amazon S3 | Environnement | K8s (Models uniquement) | K8s (Weave uniquement) | K8s (Models et Weave) | MySQL | | - | - | - | - | - | | Test/Dév | r6i.large | r6i.xlarge | r6i.xlarge | db.r6g.large | | Production | r6i.2xlarge | r6i.4xlarge | r6i.4xlarge | db.r6g.2xlarge | **Services managés recommandés** * **Kubernetes** : Google Kubernetes Engine (GKE) * **MySQL** : Google Cloud SQL for MySQL * **Stockage d’objets** : Google Cloud Storage (GCS) | Environnement | K8s (Models uniquement) | K8s (Weave uniquement) | K8s (Models et Weave) | MySQL | | - | - | - | - | - | | Test/Dév | 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 | **Services managés recommandés** * **Kubernetes** : Azure Kubernetes Service (AKS) * **MySQL** : Azure Database for MySQL * **Stockage d’objets** : Azure Blob Storage | Environnement | K8s (Models uniquement) | K8s (Weave uniquement) | K8s (Models et Weave) | MySQL | | - | - | - | - | - | | Test/Dév | Standard\_E2\_v5 | Standard\_E4\_v5 | Standard\_E4\_v5 | MO\_Standard\_E2ds\_v4 | | Production | Standard\_E8\_v5 | Standard\_E16\_v5 | Standard\_E16\_v5 | MO\_Standard\_E8ds\_v4 |