Mise à l'échelle de la Plateforme IIoT

À mesure que le nombre d’utilisateurs, le volume de données et le nombre d’appareils augmentent, la Plateforme IIoT doit pouvoir monter en charge. L’architecture sur laquelle elle repose et son potentiel de mise à l’échelle sous-jacent sont décrits dans Évolutivité du système ; cette page se concentre sur les stratégies concrètes de mise à l’échelle d’un déploiement de production.

Stratégies de mise à l’échelle de la plateforme

flowchart LR
subgraph subGraph0["IIoT Platform Scaling Strategies"]
F["Vertical Scaling"]
A["Application Servers (Ruby on Rails)"]
G["Horizontal Scaling"]
B["Data Collection Servers (GO)"]
C["PostgreSQL Database"]
H["Database Optimization"]
D["Docker/Kubernetes"]
E["Frontend Scaling"]
end
A --> F & G
B --> F & G
C --> F & G & H
D --> B & A
E -- Efficient_Distribution --> D

Mise à l’échelle verticale et horizontale

La plateforme prend en charge deux approches complémentaires de mise à l’échelle : la mise à l’échelle verticale ajoute des ressources aux serveurs existants, tandis que la mise à l’échelle horizontale ajoute davantage de serveurs.

Mise à l’échelle verticale

• Augmentation des ressources des serveurs :

  • Ajout de CPU, de RAM et de stockage SSD aux serveurs applicatifs (Ruby on Rails) et aux serveurs de collecte de données (Go).
  • Amélioration des performances de PostgreSQL grâce à des baies de disques plus puissantes et à l’optimisation des index.

• Avantages : simple à mettre en œuvre, avec des modifications minimes de l’architecture.

• Limites : les limites physiques des serveurs individuels et le coût élevé.

Mise à l’échelle horizontale

• Ajout de nouveaux serveurs :
  • Ruby on Rails : déploiement d’instances applicatives supplémentaires derrière un répartiteur de charge (par exemple, Nginx ou HAProxy).
  • Serveurs Go : mise à l’échelle aisée grâce au multithreading et à la prise en charge native de la mise à l’échelle horizontale.
  • PostgreSQL : réplication et partitionnement des données pour équilibrer la charge.
• Avantages : haute tolérance aux pannes et évolutivité pratiquement illimitée.
• Limites : la complexité supplémentaire liée à la gestion d’un système distribué.

Utilisation de Kubernetes/Docker Compose pour l’orchestration de conteneurs

Migration vers Kubernetes/Docker Compose

• Conteneurisation des applications :
  • Les serveurs Ruby on Rails et Go sont empaquetés dans des conteneurs Docker.
  • Kubernetes/Docker Compose gère le déploiement, la mise à l’échelle et la supervision de ces conteneurs.
• Mise à l’échelle automatique :
  • Le Horizontal Pod Autoscaler (HPA) augmente automatiquement le nombre de pods en fonction de la charge.
  • Le Cluster Autoscaler ajoute de nouveaux nœuds au cluster lorsque les ressources viennent à manquer.
• Avantages : grande flexibilité, automatisation et tolérance aux pannes.

Exemple d’architecture sur Kubernetes

• Ingress Controller : achemine les requêtes vers les serveurs Ruby on Rails et Go.
• StatefulSets : gèrent les réplicas PostgreSQL avec état.
• Service Mesh : utilise Istio ou Linkerd pour gérer le trafic et renforcer la sécurité.

Optimisation de la base de données

La couche base de données monte en charge grâce à une combinaison de réplication, de partitionnement et de mise en cache.

Réplication et partitionnement de PostgreSQL

• Réplication :
  • Configuration d’une réplication maître-esclave pour répartir la charge de lecture.
  • Utilisation d’outils tels que Patroni pour gérer automatiquement la réplication.
• Partitionnement :
  • Répartition des données sur plusieurs clusters PostgreSQL pour distribuer la charge d’écriture.
  • Utilisation de Citus pour mettre à l’échelle PostgreSQL horizontalement.

Mise en cache

• Redis ou Memcached :
  • Mise en cache des données fréquemment demandées afin de réduire la charge sur la base de données.
  • Intégration avec Ruby on Rails via ActiveSupport::Cache.

Mise à l’échelle du frontend

• Mise en cache côté client :

  • Utilisation des Service Workers et de l’API Cache pour mettre en cache les ressources statiques.

• CDN (Content Delivery Network) :

  • Distribution des fichiers statiques via un CDN afin de réduire la charge sur les serveurs.

Avantages de la solution proposée

• Haute tolérance aux pannes : grâce à Kubernetes/Docker Compose et à la réplication de PostgreSQL.
• Flexibilité : l’ajout de nouveaux serveurs et microservices est aisé.
• Automatisation : la mise à l’échelle ne requiert qu’une intervention humaine minimale.
• Rentabilité : l’utilisation des ressources est optimisée grâce à la mise à l’échelle automatique.

Le scénario de mise à l’échelle décrit ci-dessus permet au système de télémétrie de gérer efficacement des charges croissantes, en offrant des performances élevées, une tolérance aux pannes et une grande flexibilité. En adoptant ces technologies modernes, la plateforme est prête à relever les défis à venir.