Passer au contenu principal
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. 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 services cloud proposent des services de base de données managés robustes, 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 certains scénarios de déploiement courants et montre comment intégrer votre déploiement W&B à des services de fournisseurs cloud pour obtenir des performances et une fiabilité optimales.

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 nous nous efforcions de simplifier le processus, certaines 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 divers 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 spécifiques. 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, notre équipe 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 et W&B Dedicated Cloud.

Infrastructure

Schéma de l’infrastructure W&B

Couche application

La couche application 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

Kubernetes

L’application W&B Server est déployée sous la forme d’un opérateur Kubernetes 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, dans le cloud, sur site et dans des environnements air-gapped. Pour des instructions de configuration spécifiques, voir 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 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 l’application des correctifs, tout en réduisant considérablement la complexité opérationnelle. Voir la section Recommandations d’instances du fournisseur cloud ci-dessous 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 : vous devez sauvegarder 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 serveur de secours à chaud sur une machine distincte, qui 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. Notez que W&B ne prend pas en charge une topologie multi-maître ni les réplicas en lecture seule.

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.

Paramètres de configuration de MySQL

Si vous utilisez votre propre instance MySQL, configurez MySQL avec ces paramètres :
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
Ces paramètres ont été validés par W&B afin de garantir des performances et une fiabilité optimales.

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 :

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 est un service de stockage d’objets à hautes performances, compatible S3, optimisé pour les charges de travail d’IA.
  • Amazon S3 est un service de stockage d’objets offrant une évolutivité, une disponibilité des données, une sécurité et des performances de premier plan.
  • Google Cloud Storage est un service géré 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 de grands volumes de 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), NetApp StorageGRID ou d’autres solutions de classe entreprise hébergées dans votre cloud ou sur votre infrastructure sur site.

Versions

LogicielVersion minimale
Kubernetesv1.32 ou ultérieure (Versions de Kubernetes prises en charge)
Helmv3.x
MySQLv8.0.x est requis ; v8.0.32 ou ultérieure ; v8.0.44 ou ultérieure est recommandée.
Les versions Aurora MySQL 3.x doivent être en v3.05.2 ou ultérieure
Redisv7.x

Réseau

Pour un déploiement connecté au réseau, un accès sortant à ces endpoints est requis à la fois pendant l’installation et à l’exécution :
Des registres de conteneurs supplémentaires peuvent être requis selon votre configuration de déploiement :
  • https://gcr.io est nécessaire lors du déploiement de Bufstream et d’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. L’accès à W&B et au stockage d’objets est requis pour l’infrastructure d’entraînement ainsi que pour chaque système utilisé pour suivre les besoins des expériences.

DNS

Le nom de domaine entièrement qualifié (FQDN) du déploiement W&B doit pointer vers l’adresse IP de l’ingress/é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 :

Routage du service W&B

L’opérateur W&B achemine automatiquement les requêtes vers plusieurs services backend selon le chemin :
CheminServicePort par défautObjectif
/wandb-app8080Interface utilisateur principale de l’application web
/apiwandb-api8081service API
/graphqlwandb-api8081API endpoint GraphQL
/graphql2wandb-api8081API endpoint GraphQL v2
/consolewandb-console8082Console système
/traceswandb-weave-trace8722Service de tracing Weave (si activé)

Exemple de configuration d’ingress

Voici un exemple de ressource ingress créée par l’opérateur W&B :
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/de l’équilibreur de charge. L’application W&B Server ne termine pas les connexions SSL ou TLS. Important : W&B ne prend pas en charge les certificats auto-signés ni les autorités de certification personnalisées. L’utilisation de certificats auto-signés entraînera des problèmes pour les utilisateurs et n’est pas prise en charge. Si possible, utiliser un service comme Let’s Encrypt est un excellent moyen de 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.

Architectures de processeur 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

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, air-gapped)
Pour obtenir des instructions d’installation détaillées, voir :

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.

Dimensionnement

Utilisez les recommandations générales suivantes comme point de départ pour planifier un déploiement. W&B recommande de surveiller de près tous les composants d’un nouveau 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 des performances optimales.

Modèles uniquement

Kubernetes

EnvironnementCPUMémoireDisque
Test/Dev2 cœurs16 GB100 GB
Production8 cœurs64 GB100 GB
Ces valeurs sont indiquées par nœud worker Kubernetes.

MySQL

EnvironnementCPUMémoireDisque
Test/Dev2 cœurs16 GB100 GB
Production8 cœurs64 GB500 GB
Les valeurs sont indiquées pour chaque nœud MySQL.

Weave uniquement

Kubernetes

EnvironnementCPUMémoireDisque
Test/Dev4 cœurs32 GB100 GB
Production12 cœurs96 GB100 GB
Les valeurs s’entendent par nœud worker Kubernetes.

MySQL

EnvironnementCPUMémoireDisque
Test/Dev2 cœurs16 GB100 GB
Production8 cœurs64 GB500 GB
Les valeurs sont indiquées par nœud MySQL.

Models et Weave

Kubernetes

EnvironnementCPUMémoireDisque
Test/Dev4 cœurs32 GB100 GB
Production16 cœurs128 GB100 GB
Les valeurs sont indiquées par nœud worker Kubernetes.

MySQL

EnvironnementCPUMémoireDisque
Test/Dev2 cœurs16 GB100 GB
Production8 cœurs64 GB500 GB
Les valeurs sont indiquées par nœud MySQL.

Recommandations d’instances par fournisseur de cloud

Services

CloudKubernetesMySQLStockage d’objets
AWSEKSRDS AuroraS3
Google CloudGKEGoogle Cloud SQL - MysqlGoogle Cloud Storage (GCS)
AzureAKSAzure Database for MysqlAzure Blob Storage

Types de machines

Ces recommandations s’appliquent à chaque nœud d’un déploiement Autogéré de W&B sur une infrastructure cloud.

AWS

EnvironnementK8s (Modèles uniquement)K8s (Weave uniquement)K8s (Models&Weave)MySQL
Test/Devr6i.larger6i.xlarger6i.xlargedb.r6g.large
Productionr6i.2xlarger6i.4xlarger6i.4xlargedb.r6g.2xlarge

Google Cloud

EnvironnementK8s (Modèles uniquement)K8s (Weave uniquement)K8s (Models&Weave)MySQL
Test/Devn2-highmem-2n2-highmem-4n2-highmem-4db-n1-highmem-2
Productionn2-highmem-8n2-highmem-16n2-highmem-16db-n1-highmem-8

Azure

EnvironnementK8s (Modèles uniquement)K8s (Weave uniquement)K8s (Models&Weave)MySQL
Test/DevStandard_E2_v5Standard_E4_v5Standard_E4_v5MO_Standard_E2ds_v4
ProductionStandard_E8_v5Standard_E16_v5Standard_E16_v5MO_Standard_E8ds_v4