> ## Documentation Index > Fetch the complete documentation index at: https://docs.wandb.ai/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 pour les déploiements W&B autogérés couvrant Kubernetes, MySQL, le stockage d’objets et le 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 prendre en charge un déploiement de production de la plateforme. Utilisez-la comme guide de planification pour dimensionner, provisionner et intégrer les composants requis pour une installation autogérée fiable. Cette page s’adresse aux ingénieurs plateforme, aux ingénieurs SRE et aux administrateurs d’infrastructure qui déploient et exploitent W\&B sur leur propre infrastructure. Selon l’environnement de déploiement W\&B que vous avez choisi, 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 permettent de réduire la complexité de la configuration, de la maintenance, de la haute disponibilité et de 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 à des services de fournisseurs de cloud pour les performances et la fiabilité.
## Avant de commencer
L’exploitation de toute application en production s’accompagne de son lot de défis, et W\&B ne fait pas exception. Bien que W\&B vise à simplifier le processus, des complexité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, notamment le matériel, les systèmes d’exploitation, le réseau, le stockage, la sécurité, la plateforme W\&B elle-même, ainsi que d’autres dépendances. Cette responsabilité couvre à la fois la configuration initiale de l’environnement et sa maintenance continue. Déterminez avec soin si une approche Autogérée avec W\&B convient à votre équipe et à vos besoins. Une solide compréhension de l’exploitation et de la maintenance d’une application de production constitue un prérequis important avant de déployer W\&B Autogéré. Si votre équipe a besoin d’assistance, l’équipe W\&B Professional Services et nos partenaires proposent une assistance pour la mise en œuvre et l’optimisation. Pour en savoir plus sur les solutions gérées permettant d’exécuter W\&B au lieu de le gérer vous-même, reportez-vous à [W\&B Multi-tenant Cloud](/fr/platform/hosting/hosting-options/multi_tenant_cloud) et [W\&B Dedicated Cloud](/fr/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 schéma suivant montre comment ces couches s’articulent, et les sous-sections ci-dessous décrivent chacune d’elles. Schéma de l’infrastructure W&B
### Couche applicative
La couche applicative se compose d’un cluster Kubernetes à plusieurs nœuds, résistant aux pannes de nœuds. Le cluster Kubernetes assure l’exécution et la gestion des pods de W\&B.
### Couche de stockage
La couche de stockage comprend une base de données MySQL et un stockage d’objets. La base de données MySQL stocke les métadonnées, et le stockage d’objets stocke des Artifacts tels que des modèles et des jeux de données.
## Exigences d’infrastructure
Les sections suivantes détaillent les exigences pour un déploiement W\&B, notamment la configuration du cluster Kubernetes, MySQL, Redis, le stockage d’objets, les versions logicielles, le réseau, le DNS, l’équilibreur de charge et l’ingress, SSL/TLS, ainsi que les architectures CPU prises en charge. Vérifiez que votre environnement respecte chacune de ces exigences avant de commencer un déploiement.
### Kubernetes
W\&B déploie l’application W\&B Server sous la forme d’un [opérateur Kubernetes](/fr/platform/hosting/self-managed/operator) qui déploie plusieurs pods. W\&B nécessite donc un cluster Kubernetes avec : * Un contrôleur d’ingress entièrement configuré et opérationnel. * La capacité de provisionner des volumes persistants. 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 air-gapped. Pour des instructions de configuration spécifiques, voir la [section OpenShift](/fr/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é doivent exécuter une version de MySQL prise en charge, qui reçoit des correctifs de sécurité et des corrections de bugs critiques. Si vous exécutez MySQL Community, installez ou mettez à niveau vers **MySQL 8.4.x**. Si vous utilisez un service géré, exécutez une version du moteur que votre fournisseur indique comme prise en charge et maintenue avec 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 de [Mettre à niveau MySQL vers 8.4.x](/fr/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 en matière 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 base de données grossit à mesure que vous suivez davantage de runs d'entraînement, et la charge sur la base de données augmente selon les requêtes effectuées dans les tableaux de runs, les workspaces des utilisateurs et Reports. **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 automatiques, la surveillance, la haute disponibilité et le patching, et réduisent la complexité opérationnelle. Voir la section [Recommandations d'instances du fournisseur de cloud](#cloud-provider-instance-recommendations) pour des recommandations de service spécifiques. Si vous choisissez de déployer une base de données MySQL autogérée, tenez compte des points suivants : * **Sauvegardes** : sauvegardez périodiquement la base de données vers un site distinct. W\&B recommande des sauvegardes quotidiennes avec au moins 1 semaine de rétention. * **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 se maintient à > 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 sur une machine distincte. Le serveur de secours transmet en temps réel toutes les mises à jour depuis le déploiement principal et est prêt à prendre le relais si le serveur principal tombe en panne, est corrompu ou subit une indisponibilité prolongée.
#### Topologie MySQL
En production, un service MySQL managé est la solution la plus simple pour assurer une haute disponibilité, car le fournisseur de cloud gère le basculement, les sauvegardes et les correctifs. Utilisez l'option de haute disponibilité du fournisseur, par exemple Aurora Multi-AZ sur AWS. Si vous exécutez MySQL en mode autogéré, utilisez une base de données principale avec une instance de 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 pas en charge une topologie multi-primaire ni des réplicas en lecture seule pour la base de données de l'application.
#### Création de la base de données MySQL
Pour savoir comment créer manuellement la base de données MySQL et l’utilisateur, consultez la [section relative à la base de données MySQL du guide bare-metal](/fr/platform/hosting/self-managed/operator#mysql-database).
#### Paramètres de configuration de MySQL
Ces paramètres ajustent MySQL aux modèles d’écriture et aux modifications de schéma que W\&B effectue à grande échelle. Si vous utilisez votre propre instance MySQL, configurez MySQL avec ces paramètres : ```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 a validé ces paramètres afin de garantir les performances et la fiabilité.
### Redis
W\&B dépend d’un déploiement Redis 7.x sur un seul nœud, utilisé par les composants de W\&B 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 ne convient pas 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 requiert 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](https://docs.coreweave.com/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 offrant une évolutivité, une disponibilité des données, une sécurité et des performances. * [Google Cloud Storage](https://cloud.google.com/storage) est un service géré 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, comme du texte, des données binaires, des images, des vidéos et des journaux. * Un stockage compatible S3 tel que [MinIO Enterprise (AIStor)](https://www.min.io/product/aistor), [NetApp StorageGRID](https://www.netapp.com/data-storage/storagegrid/) ou d’autres solutions de classe 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é doivent utiliser une version prise en charge de MySQL qui reçoit des correctifs de sécurité et des corrections de bugs critiques. Installez ou mettez à niveau vers **MySQL 8.4.x**, ou utilisez une version de service géré que votre fournisseur indique comme prise en charge et corrigée.
Les chaînes de version d'Aurora MySQL diffèrent de celles de MySQL communautaire. Utilisez `SELECT version()` pour voir la chaîne complète de version du moteur et `SELECT aurora_version()` pour voir la version d'Aurora. La [version 3 d'Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html) est compatible avec MySQL 8.0.x et reste prise en charge. Voir la [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 lorsque vous choisissez une version cible. | | Redis | v7.x |
### Réseau
Pour un déploiement connecté au réseau, autorisez le trafic sortant vers ces points de terminaison pendant l’installation et à l’exécution : * `https://deploy.wandb.ai` * `https://charts.wandb.ai` * `https://quay.io` (utilisé pour les images Prometheus) Des registres de conteneurs supplémentaires peuvent être requis selon votre configuration de déploiement : * `https://gcr.io` lorsque vous déployez Bufstream et etcd pour les évaluations en ligne de Weave. Pour en savoir plus sur les déploiements air-gapped, consultez [l’opérateur Kubernetes pour les instances air-gapped](/fr/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 entièrement qualifié (FQDN) du déploiement W\&B doit pointer vers l’adresse IP de l’ingress ou de l’équilibreur de charge via 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 redirige les requêtes vers les services en fonction des chemins d’URL et de différents ports. Le contrôleur d’ingress doit être accessible depuis toutes les machines qui exécutent des charges de travail de machine learning ou accèdent au service via un navigateur web.
#### Exigences du contrôleur d’ingress
Votre cluster Kubernetes doit disposer d’une `IngressClass`. Parmi les options courantes de contrôleur d’ingress : * [Nginx Ingress Controller](https://kubernetes.github.io/ingress-nginx/). * [Istio](https://istio.io). * [Traefik](https://traefik.io/). * Contrôleurs d’ingress des fournisseurs de cloud (AWS ALB, GCP Ingress et Azure Application Gateway).
#### Routage du service W\&B
L’opérateur W\&B achemine automatiquement les requêtes vers plusieurs services backend selon le chemin : | Chemin | Service | Port par défaut | Objectif | | ----------- | ------------------- | --------------- | ----------------------------------------------------- | | `/` | `wandb-app` | 8080 | Interface utilisateur principale de l’application web | | `/api` | `wandb-api` | 8081 | service API | | `/graphql` | `wandb-api` | 8081 | API endpoint GraphQL | | `/graphql2` | `wandb-api` | 8081 | API endpoint GraphQL v2 | | `/console` | `wandb-console` | 8082 | Console système | | `/traces` | `wandb-weave-trace` | 8722 | Service de tracing Weave (si activé) |
#### Exemple de configuration d’ingress
Voici un exemple de ressource ingress créée par l’opérateur W\&B : ```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 ``` L’opérateur W\&B crée et gère automatiquement la configuration d’ingress. En général, 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 exige un certificat SSL/TLS valide, signé par une autorité reconnue, pour sécuriser les communications entre les clients et le serveur. La terminaison SSL/TLS doit se faire au niveau de l’ingress ou de l’équilibreur de charge. L’application W\&B Server ne termine pas les connexions SSL ou TLS. W\&B ne prend pas en charge les certificats auto-signés ni les autorités de certification personnalisées. Les certificats auto-signés entraînent des problèmes pour les utilisateurs et ne sont pas pris en charge. Si possible, utilisez un service comme [Let's Encrypt](https://letsencrypt.org) pour fournir des certificats approuvés à votre équilibreur de charge. Des services comme Caddy et Cloudflare gèrent le SSL pour vous. Si vos politiques de sécurité exigent une communication SSL au sein de vos réseaux de confiance, envisagez d’utiliser un outil comme Istio et 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 d’Intel et d’AMD. ARM n’est pas pris en charge.
## Méthode de déploiement
Une fois que votre infrastructure satisfait aux exigences ci-dessus, choisissez comment installer W\&B et provisionner les ressources sous-jacentes. Les sections suivantes décrivent la méthode de déploiement recommandée ainsi que l’approche recommandé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é consiste à utiliser l’**opérateur Kubernetes W\&B**, déployé via Helm. Cette approche offre : * des mises à jour automatisées et une gestion simplifiée 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 air-gapped). Pour obtenir des instructions d’installation détaillées, voir : * [Déployer la plateforme W\&B sur site](/fr/platform/hosting/self-managed/operator) - Guide d’installation principal. * [Opérateur Kubernetes pour les instances air-gapped](/fr/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 et leurs dépendances. W\&B fournit des modules Terraform pour les principaux fournisseurs cloud. Pour plus de détails, référez-vous à [Déployer W\&B Server au sein de comptes cloud Autogérés](/fr/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 de près tous les composants d’un déploiement et d’apporter des ajustements en fonction des tendances d’utilisation observées. Continuez à surveiller les déploiements de production au fil du temps et apportez les ajustements nécessaires pour maintenir les performances. Lors de la planification de la capacité, vous devez dimensionner deux composants principaux : un cluster Kubernetes pour la charge de travail de W\&B Operator et une base de données MySQL pour les métadonnées. Les recommandations varient selon l’**environnement** (Test/Dev 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 un minimum de 3 nœuds worker pour Test/Dev comme pour 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/Dev | 2 cœurs | 16 GB | 100 GB | | Production | 8 cœurs | 64 GB | 100 GB | Les valeurs sont indiquées par nœud worker Kubernetes. | Environnement | CPU | Mémoire | Disque | | ------------- | -------- | ------- | ------ | | Test/Dev | 4 cœurs | 32 GB | 100 GB | | Production | 12 cœurs | 96 GB | 100 GB | Les valeurs sont indiquées par nœud worker Kubernetes. | Environnement | CPU | Mémoire | Disque | | ------------- | -------- | ------- | ------ | | Test/Dev | 4 cœurs | 32 GB | 100 GB | | Production | 16 cœurs | 128 GB | 100 GB | Les valeurs sont indiquées par nœud worker Kubernetes.
### Dimensionnement MySQL
Ces recommandations ne varient pas en fonction de la combinaison de produits. Pour obtenir des conseils sur la topologie et la disponibilité, voir [Topologie MySQL](#mysql-topology) sous [MySQL](#mysql). | Environnement | CPU | Mémoire | Disque | | ------------- | ------- | ------- | ------ | | Test/Dev | 2 cœurs | 16 GB | 100 GB | | Production | 8 cœurs | 64 GB | 500 GB | Les valeurs sont indiquées par nœud MySQL.
## Recommandations d’instances par fournisseur de cloud
Après avoir déterminé les exigences par nœud en matière de CPU, de mémoire et de disque à partir des tableaux de dimensionnement précédents, utilisez les recommandations suivantes pour choisir des types d’instances spécifiques chez les fournisseurs de cloud et des services managés qui répondent à ces exigences. Ces recommandations s’appliquent à chaque nœud d’un déploiement W\&B autogéré sur 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\&Weave) | MySQL | | ------------- | ----------------------- | ---------------------- | ------------------- | -------------- | | Test/Dev | 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\&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 | **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\&Weave) | MySQL | | ------------- | ----------------------- | ---------------------- | ------------------- | ---------------------- | | Test/Dev | 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 |