1. Déployer un microservice dans Kubernetes pour traiter les messages à partir de la file d'attente OCI
  2. A propos du redimensionnement des consommateurs de file d'attente OCI dans Kubernetes

A propos du redimensionnement des consommateurs de file d'attente OCI dans Kubernetes

Ce livre de jeux explique comment utiliser les fonctionnalités de la file d'attente Oracle Cloud Infrastructure (OCI) et fournit une recette adaptée à la plupart des cas d'utilisation nécessitant un redimensionnement dynamique, en fonction de la quantité de demande client, sans entraîner de problèmes de pression arrière ou de goulot d'étranglement des performances.

Vous pouvez déployer un microservice vers Oracle Kubernetes Engine (OKE), qui traite les messages à partir d'une file d'attente OCI, puis tirer parti de la profondeur de la file d'attente pour redimensionner horizontalement les instances de microservice exécutées sur un cluster OKE. L'exemple inclut un générateur de messages que vous pouvez exécuter depuis n'importe où, par exemple à partir de votre ordinateur local ou dans le cadre d'un autre conteneur ou d'une autre machine virtuelle.

Ce livre de jeux fournit également du code et des instructions de configuration détaillées, disponibles dans le référentiel Oracle-DevRel GitHub, oci-arch-queue-oke-demo (accessible à partir de la section Explorer plus de ce livre de jeux). Cette solution fournit l'ensemble du code Java, des scripts et des fichiers de configuration, ainsi que les étapes détaillées de création, de déploiement et d'exécution des blocs de construction. Ce document présente une vue architecturale et examine les éléments clés de l'implémentation, y compris l'identification des parties du code que vous devrez modifier pour adapter la solution à vos propres besoins.

En savoir plus sur les API de file d'attente OCI

Les solutions traitent très rarement des processus uniques ; la communication entre les applications doit souvent être asynchrone pour éviter de limiter la solution par la partie la plus limitante d'une solution (par exemple, nécessiter une CPU, une latence, etc.). Vous pouvez résoudre ces problèmes en établissant une communication dans laquelle le(s) producteur(s) et le(s) consommateur(s) ne dépendent pas l'un de l'autre. C'est ce que la file d'attente OCI prend en charge à des performances très élevées.

Tandis que la file d'attente peut amortir les applications des fluctuations de la demande, lorsque les utilisateurs sont impliqués, vous ne voulez pas beaucoup de temps pour passer entre la création des messages et le traitement des messages. Par conséquent, le back-end doit pouvoir évoluer dynamiquement en fonction de la demande. Cette demande est déterminée par le nombre de messages placés dans la file d'attente ; davantage de messages signifie plus de demande et donc plus d'effort de calcul nécessaire. Inversement, une file d'attente vide ne représente aucune demande et nécessite donc un minimum de ressources back-end. La mise à l'échelle dynamique résout ces variations constantes.

Architecture

Cette architecture nécessite une file d'attente pour les messages qui résident en dehors de nos domaines de pannes visibles car il s'agit d'un service entièrement géré.

Dans OCI, vous pouvez exécuter Kubernetes avec des noeuds gérés par le client ou avec des noeuds gérés par Oracle. Ce scénario utilise l'ancienne approche des noeuds client. Vous avez donc besoin de noeuds Compute attachés au cluster. Il est recommandé de répartir ces noeuds entre les domaines de pannes et au sein d'une zone de disponibilité.

Remarque :

Dans ce livre de jeux, la génération de la demande provient de votre machine locale et, par conséquent, en dehors de l'environnement OCI.

Les deux derniers éléments clés contrôlent la mise à l'échelle. Tout d'abord, une fonction OCI est appelée périodiquement et extrait les détails de la profondeur de la file d'attente. Pour résumer la façon dont la profondeur de file d'attente est vérifiée, une passerelle d'API est utilisée, ce qui facilite l'appel des fonctions OCI.

Enfin, nous avons besoin de services auxiliaires, tels que Vault, pour stocker les informations d'identification permettant d'accéder à la file d'attente, la surveillance de l'observation générale de l'état, etc.


Description de l'image queue-scaling-oke-arch.png
Description de l'illustration queue-scaling-oke-arch.png

queue-scaling-oke-arch-oracle.zip

Les numéros du diagramme précédent représentent cette séquence d'événements :
  1. Le producteur hébergé localement place les messages dans la file d'attente OCI.
  2. Nos instances de consommateur OCI extraient des messages de la file d'attente. Dans le code, le taux de consommation est limité en utilisant un délai. Cela garantit que le fournisseur génère plus de messages qu'un seul consommateur ne peut les supprimer de la file d'attente. En conséquence, les mécanismes de redimensionnement fonctionneront.
  3. Périodiquement, un travail programmé Kubernetes prendra en charge KEDA pour appeler l'API publiée afin d'obtenir le nombre de messages dans la file d'attente.
  4. API Gateway dirige la demande vers une instance de la fonction OCI.
  5. La fonction OCI interroge la file d'attente OCI.
  6. La réponse est renvoyée, ce qui entraîne le déclenchement par KEDA d'une augmentation ou d'une diminution des instances du microservice.
De plus, (a) cette implémentation permet également à l'utilisateur d'interroger à tout moment l'état de la profondeur de la file d'attente.
Cette architecture contient les composants suivants :
  • Région

    Une région OCI est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans des pays voire des continents).

  • Domaines de disponibilité

    Les domaines de disponibilité sont des centres de données indépendants autonomes au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui assure la tolérance aux pannes. Les domaines de disponibilité ne partagent pas les services d'infrastructure tels que l'alimentation, le refroidissement ou le réseau interne du domaine de disponibilité. Ainsi, il est peu probable qu'un problème survenant dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.

  • Domaine de pannes

    Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec une alimentation et un matériel indépendants. Lorsque vous distribuez des ressources sur plusieurs domaines de pannes, vos applications peuvent tolérer les pannes de serveur physique, de maintenance du système et d'alimentation au sein d'un domaine de pannes.

  • Compartiment

    Les compartiments sont des partitions logiques inter-région au sein d'une location OCI. Utilisez des compartiments pour organiser vos ressources dans Oracle Cloud, contrôler l'accès aux ressources et définir des quotas d'utilisation. Pour contrôler l'accès aux ressources de chaque compartiment, vous définissez des stratégies qui indiquent qui peut accéder aux ressources et quelles actions elles peuvent effectuer.

  • Réseau cloud virtuel (VCN) et sous-réseaux

    Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région OCI. Comme les réseaux de centres de données traditionnels, les réseaux cloud virtuels vous donnent un contrôle total sur votre environnement réseau. Un VCN peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être ciblés vers une région ou un domaine de disponibilité. Chaque sous-réseau se compose d'une plage contiguë d'adresses qui ne chevauchent pas les autres sous-réseaux du VCN. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.

  • Instances de calcul

    OCI Compute vous permet de provisionner et de gérer des hôtes de calcul. Vous pouvez lancer des instances de calcul avec des formes qui répondent à vos besoins en ressources (UC, mémoire, bande passante réseau et stockage). Une fois qu'une instance de calcul a été créée, vous pouvez y accéder en toute sécurité, la redémarrer, associer et dissocier des volumes, et l'arrêter lorsque vous n'en avez pas besoin.

  • Fonctions

    Oracle Functions est une plate-forme Functions-as-a-Service (FaaS) entièrement gérée, colocative, hautement évolutive et à la demande. Il est optimisé par le moteur open source du projet Fn. Les fonctions vous permettent de déployer votre code et de l'appeler directement ou de le déclencher en réponse à des événements. Oracle Functions utilise des conteneurs Docker hébergés dans OCI Registry.

  • Registre du conteneur

    OCI Registry est un registre géré par Oracle qui vous permet de simplifier votre workflow du développement jusqu'à la production. Le registre facilite le stockage, le partage et la gestion des artefacts de développement, tels que les images Docker. L'architecture hautement disponible et évolutive d'OCI garantit un déploiement et une gestion fiables de vos applications.

  • Container Engine for Kubernetes

    OCI Container Engine for Kubernetes est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications en conteneur vers le cloud. Indiquez les ressources de calcul requises par vos applications et Container Engine for Kubernetes les provisionne sur OCI dans une location existante. Container Engine for Kubernetes utilise Kubernetes pour automatiser le déploiement, le redimensionnement et la gestion des applications en conteneur sur des clusters d'hôtes.

  • API Gateway

    Oracle API Gateway vous permet de publier des API avec des adresses afin de gérer la visibilité de fonctionnalités telles que Functions, Microservices et d'autres interfaces d'application. Les adresses fournissent des contrôles de sécurité affinés pour les solutions back-end, ainsi que l'abstraction de la manière dont une API peut être implémentée.

  • File d'attente

    La file d'attente est un mécanisme de communication asynchrone hautement évolutif sans serveur. Il est idéal pour permettre le découplage des services et la distribution des messages.

Remarques

Lors du déploiement d'un microservice dans Kubernetes pour traiter les messages de la file d'attente OCI, tenez compte des points suivants :

  • Remarques concernant les stratégies pour les files d'attente

    Les stratégies de contrôle et de configuration des files d'attente OCI et des stratégies de création et d'utilisation des messages sont séparées. Vous disposez ainsi d'un contrôle affiné des opérations disponibles via les API. Cela signifie que vous devez tenir compte des exigences et des besoins de sécurité de votre application. Pour la production, des contrôles stricts sont recommandés ; cette implémentation utilise des paramètres de configuration allégés, ce qui minimise les risques d'erreur de configuration empêchant le fonctionnement de la démonstration.

  • Remarques concernant les limites de redimensionnement de Kubernetes

    Vous devez tenir compte du taux et des limites de redimensionnement du back-end. Vous devez traiter des facteurs, tels que la profondeur de la file d'attente avant le démarrage d'instances supplémentaires du microservice. Le nombre maximal d'instances supplémentaires d'un microservice doit être en cours d'exécution. Bien qu'il soit tentant de ne pas lier cela, dans le monde réel, des termes pratiques, si quelqu'un (de manière délibérée ou accidentelle) commence à inonder votre file d'attente avec des messages erronés, vous ne voulez pas absorber les coûts de la puissance de calcul supplémentaire nécessaire pour s'éteindre. Vous devez également examiner la vitesse à laquelle vous réduisez les instances supplémentaires de votre microservice. Réduisez trop rapidement et votre environnement démarre et arrêtez constamment les services. Quelle que soit l'efficacité du microservice, le coût de démarrage et d'arrêt des instances de service entraîne toujours des frais généraux.

  • Remarques concernant le contrôle de mise à l'échelle

    Le dernier aspect du contrôle de la mise à l'échelle est de savoir si vous souhaitez appliquer la mise à l'échelle et comment la contrôler. Ce scénario s'appuie sur un projet CNCF appelé KEDA (Kubernetes Event Driven Autoscaler). Outre l'exécution du redimensionnement back-end, vous devez examiner la façon dont l'API est appelée. Dans ce cas, vous pouvez configurer un travail programmé Kubernetes (car le travail est exécuté par un noeud de processus actif, le diagramme reflète ce flux) pour appeler l'API.

Prérequis

Avant de commencer, vous devez préparer votre environnement en répondant aux prérequis décrits ici.

  • Pour la génération des messages, vous avez besoin de Java 8 ou version ultérieure (Java 8 installé avec Apache Maven).
  • L'interaction avec la file d'attente OCI nécessite des utilisateurs et des informations d'identification associées pour autoriser l'accès. Définissez les stratégies suivantes :
    • Définissez cette stratégie pour identifier le compartiment à utiliser (compartment-name) : 
      allow any-user to manage queues in compartment compartment-name
    • Pour limiter les utilisateurs à la lecture ou à l'écriture dans la file d'attente OCI, créez des groupes OCI nommés MessageConsumers et MessageProducers et allouez les utilisateurs appropriés à ces groupes. Utilisez les stratégies suivantes : 
      allow group MessageConsumers to use queues in compartment compartment-name 
allow group MessageProducers to use queues in compartment compartment-name
    • Fournissez au client producteur les attributs de configuration OCI standard afin qu'il puisse s'authentifier auprès d'OCI et utiliser l'API.
    • Vous devez définir des stratégies pour prendre en charge le comportement dynamique car de nouvelles ressources vont et vont devoir accéder à la file d'attente. Définissez ces stratégies en créant un groupe dynamique avec les ressources que vous aurez besoin de contrôler de manière élastique. Comme ce contrôle se produit dans OCI, utilisez un principal d'instance. Appelez ce groupe queue_dg. Utilisez les instructions de stratégie suivantes : 
      ALL {instance.compartment.id='instance Compartment id (OCID)'} 
allow dynamic-group queue_dg to use queues in compartment queue_parent_compartment
      Où instance Compartment id (OCID) est le compartiment contenant les noeuds de processus actif.

Découvrir le kit SDK Java

Les trois éléments de code (producteur, consommateur et fonction) utilisent tous les API OCI. Le moyen le plus simple d'interagir avec les API est le SDK Java. Les kits SDK fournis par OCI fournissent une série de fonctions de convaincre qui extraient les informations nécessaires pour que vous puissiez authentifier et autoriser les appels des services OCI. Les SDK adoptent la variante du modèle Builder de Joshua Bloch. Vous trouverez plus d'informations sur le kit SDK dans le kit SDK Java. Le référentiel Oracle DevRel GitHub contient d'autres exemples de kits SDK utilisés ici, par exemple, à l'adresse https://github.com/oracle-devrel/oci-arch-queue-demo.