Skip to main content

Scalabilité

La scalabilité d'Open ENT v3 est assurée par Kubernetes et en utilisant les fonctionnalités de Quarkus et Istio avec une communication asynchrone basée sur EventBus,

Chaque outil permet un niveau différent de szcalabilité.

1. Kubernetes : Scalabilité et Gestion des Conteneurs​

Kubernetes (K8s) est une plateforme d'orchestration de conteneurs qui permet la gestion et la scalabilité des applications conteneurisées.

  • Autoscaling : Kubernetes offre deux types d’autoscaling :

    • Horizontal Pod Autoscaler (HPA) : Kubernetes peut augmenter ou diminuer dynamiquement le nombre de pods en fonction de la charge de travail (CPU, mémoire ou d’autres métriques personnalisées).
    • Cluster Autoscaler : Kubernetes ajuste le nombre de nœuds en fonction des besoins en ressources des pods.

    Pour activer l’HPA :

    • Définis des seuils pour CPU ou d'autres métriques.
    • Utilise des règles de scaling basées sur des événements, des files d'attente ou des métriques externes si nécessaire (grâce à Prometheus, par exemple).

    Exemple de commande pour activer l'HPA pour le portail :

    kubectl autoscale deployment openent-portal --cpu-percent=50 --min=1 --max=10

2. Quarkus : Microservices pour des Temps de Démarrage Rapides​

Quarkus offre des temps de démarrage rapides et une faible consommation de mémoire, ce qui est idéal pour une infrastructure conteneurisée comme Kubernetes.

  • Démarrage rapide : Grâce à GraalVM et à sa capacité de compilation native, Quarkus permet de réduire le temps de démarrage des services, ce qui facilite la scalabilité, car de nouveaux pods peuvent démarrer et répondre rapidement aux requêtes. Avec Open ENT v3, il faut lancer la compilation avec le profile native (mvn -Pnative).

  • Configuration Kubernetes : Quarkus est nativement compatible avec Kubernetes et Istio. Les extensions Quarkus facilitent l'intégration avec des solutions cloud natives comme Kubernetes.

3. Istio : Réseau de Services pour la Gestion du Traffic et de la Sécurité​

Istio apporte le service mesh qui facilite la gestion du réseau entre microservices. Il est particulièrement utile pour :

  • Load balancing (répartition de charge) : Istio permet de gérer la répartition du trafic entre les instances de services.
  • Canary releases et blue-green deployment : Pour des mises à jour progressives des services.
  • Observabilité : Istio fournit des métriques, des logs et des traces pour surveiller l'état des microservices.

Pour gérer la scalabilité et le réseau de services avec Istio, tu peux définir des politiques de trafic. Par exemple, tu peux rediriger une partie du trafic vers de nouvelles instances d’un service déployé, ce qui permet de tester la scalabilité avant de rediriger tout le trafic.

Remarques

Il n'est pas nécessaires de déployer ISTIO pour avoir une scalabilité horizontale. Le load balancing est alors plus simple et réalisé uniquement par un Load balancer Ingress

Ingress

Load balancing avancé : Sans Istio, Kubernetes fournit un simple round-robin pour distribuer les requêtes entre les services. Istio, par contre, permet un équilibrage plus sophistiqué avec des stratégies basées sur la latence, le taux d’erreurs, etc.

Routing intelligent : Istio permet des stratégies de routage avancées comme le canary deployment (déploiement progressif d'une nouvelle version d'un service) ou le blue-green deployment (gestion de différentes versions de services). Sans Istio, tu devras implémenter ces fonctionnalités manuellement via des configurations Kubernetes plus complexes.

Circuit Breakers et Retry : Istio permet de configurer des mécanismes de circuit breaking (pour stopper les appels à un service qui échoue régulièrement) et des politiques de retry (pour réessayer les requêtes échouées), ce que Kubernetes seul ne gère pas facilement.

4. Communication Asynchrone avec EventBus​

L'architecture basée sur des événements avec un EventBus permet de découpler les services et de mieux gérer la charge.

L'utilisation de Hazelcast avec EventBus offre une solution distribuée en mémoire qui fournit des capacités de partage de données, de mise en cache, de gestion d'état, et de messagerie.

1. Scalabilité avec Hazelcast​

Hazelcast est conçu pour être élastique et distribué. Il peut s'étendre horizontalement en ajoutant simplement des nœuds au cluster. La répartition des données et des tâches se fait automatiquement, sans nécessiter de reconfiguration majeure.

Avantages de la Scalabilité avec Hazelcast :​
  • Scalabilité en mémoire : Hazelcast est principalement un data grid en mémoire. Cela signifie que toutes les données sont stockées en RAM, ce qui permet des temps de réponse très rapides et une capacité à traiter de grandes quantités de données en temps réel.
  • Partitionnement automatique : Les données et les tâches sont automatiquement réparties entre les nœuds du cluster. Cela permet une mise à l'échelle dynamique en fonction du nombre de nœuds disponibles.
  • Résilience : Hazelcast assure la redondance des données en répliquant celles-ci sur différents nœuds. En cas de panne d'un nœud, les données restent accessibles, ce qui augmente la tolérance aux pannes.
  • Elasticité : Tu peux ajouter ou retirer des nœuds sans interrompre les opérations, et Hazelcast redistribue automatiquement les données pour assurer un bon équilibre.
Limitations :​

  • Persistant vs In-Memory : Hazelcast n'est pas conçu pour être un log persistant. Il est principalement en mémoire, ce qui peut poser problème si tu as besoin d'une rétention longue ou d'une persistance durable des événements. Une solution avec Kafka à la place de Hazelcast permettrait de conserver les messages sur disque et les rend disponibles pour les consommateurs à tout moment.

  • Taille de la charge : Pour des scénarios de messagerie à très grande échelle, comme ceux traités par Kafka, Hazelcast peut atteindre ses limites en fonction de la taille de la mémoire disponible dans le cluster. Kafka est conçu pour traiter des flux de messages massifs à une échelle beaucoup plus grande.

2. Comparaison avec Kafka et AMQP pour la Scalabilité​

Conseil

Hazelcast offre des avantages de scalabilité pour des scénarios de traitement en mémoire rapide et de cache distribué, mais si tu as besoin d'une architecture centrée sur la gestion de flux massifs d'événements persistants, Kafka ou AMQP (comme RabbitMQ) seraient plus adaptés. Hazelcast excelle dans les systèmes à haute vitesse et faible latence, mais pourrait être limité dans des cas de traitement d'événements massifs avec une forte exigence de persistance à long terme. Dans le cas d'Open ENT, l'eventBus est utilisé pour les messages à faible durée de vie et la persistence n'est pas requise.

Voici une comparaison entre Hazelcast et Kafka/AMQP en termes de scalabilité si on souhaitait des messages persistants :

CritèreHazelcastKafkaAMQP (e.g., RabbitMQ)
Modèle de stockageEn mémoire (pouvant utiliser le disque)Stockage persistant sur disqueEn mémoire avec persistance sur disque
Scalabilité horizontaleBonne (ajout de nœuds, auto-sharding)Excellente (scalabilité massive)Bonne, mais limitée à la gestion des files
DébitTrès rapide (dépend de la RAM disponible)Très élevé (avec partitionnement)Bon, mais moins performant pour de très gros volumes
Persistance des messagesNon prioritaire (mais possible via MapStore)Persistant par défautPersistant, mais dépend du broker
Gestion des partitionsAutomatique (via des shards)Très flexible, partitionnement natifStatique ou dynamique, selon la configuration
RésilienceRéplication en mémoireRéplication sur disque et réseauRéplication, mais plus limitée qu’Hazelcast ou Kafka
Support de la communication asynchroneBon, mais pas spécialisé dans le messagingSpécialiste du streaming et messagingSpécialisé pour la messagerie asynchrone

3. Scalabilité des Consommateurs d'Événements​

En termes de gestion des consommateurs, Hazelcast permet de répartir les tâches et la consommation d'événements sur plusieurs nœuds via son mécanisme de distribution de tâches. Tu peux facilement ajouter des consommateurs en ajoutant des nœuds au cluster, et Hazelcast redistribue automatiquement la charge. Cette approche est adaptée pour les scénarios d'Open ENT où la durée de rétention des messages est moins critique que la vitesse et la disponibilité en temps réel.

Voici un exemple de log des membres d'un cluster Hazelcast automatiquement crée dans Open ENT à chaque ajout d'un nouveau module sous forme d'un container :

2024-08-30 11:49:50,353 INFO  [com.haz.int.clu.ClusterService] (hz.focused_gates.priority-generic-operation.thread-0) [10.42.0.65]:5701 [dev] [4.2.8] 

Members {size:5, ver:79} [
        Member [10.42.0.65]:5701 - 0de0b6a1-2ea8-4ce6-ab74-87e07cbb378e this
        Member [10.42.0.69]:5701 - 34380ad1-52fa-45f1-9c8b-22321f70ad2c
        Member [10.42.0.70]:5701 - 3b216303-77f7-4803-86c9-ac33f2653e04
        Member [10.42.0.98]:5701 - faa437c7-610d-409e-894c-ecea6166fa5f
        Member [10.42.0.101]:5701 - 003c90bc-458a-4a78-8829-6d247fbdd853
]

2024-08-30 11:49:50,604 INFO  [com.haz.int.par.imp.MigrationManager] (hz.focused_gates.migration) [10.42.0.65]:5701 [dev] [4.2.8] Repartitioning cluster data. Migration tasks count: 271
2024-08-30 11:49:50,815 INFO  [com.haz.int.par.imp.MigrationManager] (hz.focused_gates.migration) [10.42.0.65]:5701 [dev] [4.2.8] All migration tasks have been completed. (repartitionTime=Fri Aug 30 11:49:50 UTC 2024, plannedMigrations=271, completedMigrations=271, remainingMigrations=0, totalCompletedMigrations=19128)

4. Configuration du cluster Hazelcast​

Dans chaque module Open ENT, la configuration suivante est précisée dans le fichier application.properties :

####################
# Common Properties
####################

# Activate cluster for Vert.x
quarkus.vertx.cluster.clustered=true

Le paramètre quarkus.vertx.cluster.clustered=true dans une application Quarkus configure Vert.x pour fonctionner en mode cluster. Cela permet aux différentes instances d'Open ENT (réparties sur plusieurs nœuds ou conteneurs) de faire partie d'un même cluster Vert.x et de collaborer en partageant des informations et des ressources.