Architecture de référence

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 et à Cloud dédié de W&B.

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.

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, 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 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 du guide de l’opérateur.

MySQL

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 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.

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 :

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.
Google Cloud Memory Store.
Azure Cache for Redis.
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 est un service de stockage d’objets compatible S3, optimisé pour les charges de travail d’IA.
Amazon S3 est un service de stockage d’objets qui offre évolutivité, disponibilité des données, sécurité et performances.
Google Cloud Storage est un service managé permettant de stocker des données non structurées à grande échelle.
Azure Blob Storage 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), NetApp 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)
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 est compatible avec MySQL 8.0.x et reste prise en charge. Pour choisir une version cible, consultez Gestion des versions d’Amazon Aurora 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 et Versions du serveur W&B prises en charge.

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. 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.
Istio.
Traefik.
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 :

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 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.

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 - Guide d’installation principal.
Opérateur Kubernetes pour les instances isolées du réseau - 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.

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

Models uniquement
Weave uniquement
Models et Weave

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

Environnement	CPU	Mémoire	Disque
Test/Dév	4 cœurs	32 Go	100 Go
Production	16 cœurs	128 Go	100 Go

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 dans la section 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.

AWS
Google Cloud
Azure

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

​Avant de commencer

​Infrastructure

​Couche applicative

​Couche de stockage

​Exigences d’infrastructure

​Kubernetes

​MySQL

​Topologie MySQL

​Création de la base de données MySQL

​Paramètres de configuration de MySQL

​Redis

​Stockage d’objets

​Versions

​Réseau

​DNS

​Équilibreur de charge et ingress

​Exigences relatives au contrôleur d’ingress

​Acheminement du service W&B

​Exemple de configuration d’ingress

​SSL/TLS

​Architectures de CPU prises en charge

​Méthode de déploiement

​Opérateur Kubernetes W&B avec Helm

​Provisionnement de l’infrastructure

​Dimensionnement

​Dimensionnement Kubernetes

​Dimensionnement de MySQL

​Recommandations d’instances par fournisseur de cloud

Avant de commencer

Infrastructure

Couche applicative

Couche de stockage

Exigences d’infrastructure

Kubernetes

MySQL

Topologie MySQL

Création de la base de données MySQL

Paramètres de configuration de MySQL

Redis

Stockage d’objets

Versions

Réseau

DNS

Équilibreur de charge et ingress

Exigences relatives au contrôleur d’ingress

Acheminement du service W&B

Exemple de configuration d’ingress

SSL/TLS

Architectures de CPU prises en charge

Méthode de déploiement

Opérateur Kubernetes W&B avec Helm

Provisionnement de l’infrastructure

Dimensionnement

Dimensionnement Kubernetes

Dimensionnement de MySQL

Recommandations d’instances par fournisseur de cloud