Modèle Geode

Le modèle Geode implique le déploiement d’une collection de services back-end dans un ensemble de nœuds géographiques, chacun pouvant traiter une demande client dans n’importe quelle région. Ce modèle permet le traitement des requêtes dans un style actif-actif, l’amélioration de la latence et l’augmentation de la disponibilité en répartissant le traitement des requêtes à travers le monde.

Contexte et problème

De nombreux services à grande échelle présentent des difficultés particulières en matière de disponibilité géographique et de mise à l’échelle. Les conceptions classiques transmettent les données au calcul en stockant les données dans un serveur SQL distant, qui sert de niveau de calcul pour ces données, en misant sur la montée en puissance pour la croissance.

La conception classique peut présenter une série de difficultés :

• Des problèmes de latence du réseau pour les utilisateurs qui se connectent au point de terminaison d’hébergement depuis l’autre côté du globe
• La gestion du trafic pour les rafales de la demande qui peuvent submerger les services d’une seule région
• Le coût prohibitif de la complexité du déploiement de copies de l’infrastructure d’applications dans plusieurs régions pour un service 24 h/24 et 7 j/7

L’infrastructure cloud moderne a évolué afin d’équilibrer la charge géographique des services frontaux, tout en permettant une réplication géographique des services back-end. Pour des raisons de disponibilité et de niveau de performance, il est préférable que les données soient rapprochées de l’utilisateur. Lorsque les données sont géodistribuées dans une base utilisateur reculée, les magasins de données géodistribués devraient être situés au même endroit que la ressource de calcul qui traite les données. Le modèle Geode transmet le calcul aux données.

Solution

Déployer le service en plusieurs déploiements par satellite répartis dans le monde entier, dont chacun porte le nom de géode. Le modèle Geode exploite des fonctionnalités clés d’Azure pour acheminer le trafic par le chemin le plus rapide vers une géode proche, ce qui améliore la latence et les performances. Chaque géode se trouve derrière un équilibreur de charge global et utilise un service de lecture/écriture géo-répliqué comme Azure Cosmos DB pour héberger le plan de données et garantir ainsi la cohérence des données entre les géodes. Les services de réplication de données garantissent des magasins de données identiques d’une géode à une autre, de manière à pouvoir servir toutes les requêtes à partir de toutes les géodes.

La principale différence entre un tampon de déploiement et une géode est que les géodes n’existent jamais isolément. Il doit toujours y avoir plusieurs géodes sur une plateforme de production.

Les géodes présentent les caractéristiques suivantes :

• Elles se composent d’une collection de différents types de ressources, souvent définis dans un modèle.
• Elles sont autonomes et n’ont aucune dépendance en dehors de l’empreinte de la géode. Aucune géode ne dépend d’une autre pour fonctionner, si l’une d’elle s’éteint, les autres continuent de fonctionner.
• Elles sont couplées de manière flexible via un réseau de périmètre et un fond de panier de réplication. Par exemple, vous pouvez utiliser Azure Traffic Manager ou Azure Front Door pour les géodes, tandis qu’Azure Cosmos DB peut servir de fond de panier de réplication. Les géodes ne sont pas comme des clusters, car elles partagent un fond de panier de réplication de manière à ce que la plateforme gère les problèmes de quorum.

Le modèle Geode est présent dans les architectures de Big Data qui utilisent le matériel de base pour le traitement des données sur une même machine et MapReduce pour le regroupement des résultats sur toutes les machines. Il est également utilisé pour le calcul en périphérie à proximité, ce qui rapproche le calcul de la périphérie intelligente du réseau en vue de réduire le temps de réponse.

Les services peuvent utiliser ce modèle sur des dizaines, voire des centaines de géodes. En outre, la résilience de la solution globale s’améliore à chaque fois qu’une géode est ajoutée, puisqu’une géode peut prendre le relais en cas de déconnexion d’une ou plusieurs géodes suite à une panne régionale.

Il est également possible d’améliorer les techniques de disponibilité locale, telles que des zones de disponibilité ou des régions associées, avec le modèle Geode pour une disponibilité globale. Cela accroît la complexité, mais est utile si votre architecture est soutenue par un moteur de stockage, tel que le stockage Blob, qui ne peut répliquer que dans une région associée. Vous pouvez déployer des géodes dans une empreinte intra-zone, zonale ou régionale, en gardant à l’esprit les contraintes de latence et de réglementation de l’emplacement.

Problèmes et considérations

Utilisez les techniques et technologies suivantes pour l’implémentation de ce modèle :

• Pratiques et outils DevOps modernes pour la production et le déploiement rapide de géodes identiques dans un grand nombre de régions ou d’instances.
• Mise à l’échelle automatique pour effectuer un scale-out des instances de débit de calcul et de base de données dans une géode. Chaque géode effectue un scale-out individuellement, dans les limites des contraintes communes de fond de panier.
• Un service frontal, tel qu’Azure Front Door, qui effectue l’accélération de contenu dynamique, le fractionnement du protocole TCP et le routage Anycast.
• Un magasin de données de réplication, tel qu’Azure Cosmos DB, pour contrôler la cohérence des données.
• Des technologies serverless avec lesquelles il est possible de réduire le coût du déploiement toujours activé, en particulier lorsque la charge est fréquemment rééquilibrée dans le monde. Cette stratégie permet le déploiement de nombreuses géodes avec un investissement supplémentaire minime. Les technologies de facturation serverless et fondées sur la consommation permet une réduction du gaspillage et du coût de la duplication des déploiements géodistribués.
• Le service Gestion des API n’est pas nécessaire pour implémenter le modèle de conception, mais peut être ajouté à chaque Géode en tête de l’application de fonction Azure de la région pour fournir une couche API plus robuste, permettant ainsi l’implémentation de fonctionnalités supplémentaires telle la limitation de débit.

Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :

• Choisissez de traiter les données localement dans chaque région, ou de distribuer des agrégations dans une seule géode et de répliquer le résultat dans le monde. Le processeur de flux de modification Azure Cosmos DB propose un contrôle granulaire par l’utilisation de son concept de conteneur de bail et de leasecollectionprefix dans la liaison Azure Functions correspondante. Chaque approche présente des avantages et des inconvénients distincts.
• Les géodes peuvent fonctionner en tandem, en utilisant le flux de modification Azure Cosmos DB et une plateforme de communication en temps réel, telle que SignalR. Les géodes peuvent communiquer avec les utilisateurs distants à l’aide d’autres géodes dans un modèle de maillage, sans connaître ni se préoccuper de l’emplacement de l’utilisateur distant.
• Ce modèle de conception découple tout de manière implicite, ce qui se traduit par une architecture extrêmement distribuée et découplée. Envisagez des procédures de suivi des différents composants d’une même requête, car ils pourraient s’exécuter de manière asynchrone sur des instances différentes. Une stratégie de surveillance appropriée est essentielle. Il est possible d’intégrer facilement Azure Front Door et Azure Cosmos DB intégrés avec Log Analytics, et Azure Functions devrait être déployé parallèlement à Application Insights pour fournir un système de surveillance robuste à chaque composant de l’architecture.
• Les déploiements distribués ont un plus grand nombre de secrets et de points d’entrée qui requièrent des mesures de sécurité de propriété. Key Vault fournit une couche sécurisée pour la gestion des secrets, et chaque couche au sein de l’architecture de l’API doit être correctement sécurisée afin que le seul point d’entrée pour l’API soit le service frontal, comme Azure Front Door. Le service Azure Cosmos DB doit restreindre le trafic vers les applications de fonction Azure, et de celles-ci vers Azure Front Door, en utilisant Microsoft Entra ID ou des pratiques telles que la restriction d’adresse IP.
• Les performances sont considérablement affectées par le nombre de géodes déployées et les plans App Service spécifiques appliqués à la technologie d’API dans chaque géode. Le déploiement de géodes supplémentaires ou le déplacement vers des niveaux Premium s’accompagnent d’une augmentation des coûts pour la mémoire et le calcul supplémentaires, mais pas sur la base d’une transaction. Songez à tester la charge de l’architecture de l’API une fois celle-ci déployée, et à comparer l’augmentation du nombre de géodes à l’augmentation du niveau de prix afin d’utiliser le modèle le plus rentable pour vos besoins.
• Déterminez les exigences de disponibilité de vos données. Azure Cosmos DB possède des indicateurs facultatifs pour l’activation de l’écriture multirégion, des zones de disponibilité, etc. Ceux-ci augmentent la disponibilité de l’instance Azure Cosmos DB et créent une couche données plus résiliente, mais entraînent des coûts supplémentaires.
• Azure offre un série d’équilibreurs de charge qui fournissent différentes fonctionnalités pour la distribution du trafic. Utilisez l’arbre de décision pour sélectionner l’option appropriée pour le serveur frontal de votre API.

Quand utiliser ce modèle

Utilisez ce modèle :

• Pour implémenter une plateforme à grande échelle dont les utilisateurs sont répartis sur une zone très large.
• Pour tout service nécessitant des caractéristiques de disponibilité et de résilience extrêmes, car les services fondés sur le modèle Geode peuvent résister à la perte de plusieurs régions de services en même temps.

Ce modèle peut ne pas convenir

• Aux architectures présentant des contraintes empêchant l’égalité de toutes les géodes en matière de stockage de données. Par exemple, il peut y avoir des exigences en matière de résidence des données, une application qui doit maintenir un état temporaire pour une session particulière ou une forte concentration des demandes vers une région. Dans cette situation, envisagez d’utiliser des tampons de déploiement avec un plan de routage global qui connait l’emplacement des données utilisateur, comme le composant de routage du trafic décrit dans le modèle de tampons de déploiement.
• Dans les situations où aucune distribution géographique n’est requise. Au lieu de cela, pensez aux zones de disponibilité et aux régions associées pour le clustering.
• Dans les situations où la plateforme héritée doit être modernisée. Ce modèle fonctionne uniquement pour le développement natif cloud et peut être compliqué à moderniser.
• Aux architectures et aux exigences simples, où la géoredondance et la géodistribution ne sont ni requises ni avantageuses.

Conception de la charge de travail

Un architecte doit évaluer de quelle façon le modèle Geode peut être utilisé dans la conception de leur charge de travail pour répondre aux objectifs et principes couverts par les piliers d’Azure Well-Architected Framework. Par exemple :

Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.

Exemples

• Windows Active Directory met en œuvre une première variante de ce modèle. La réplication multi-principale signifie que toutes les mises à jour et toutes les requêtes peuvent, en théorie, être servies depuis tous les nœuds utilisables, mais les rôles FSMO (Flexible Single Master Operation) impliquent que toutes les géodes ne sont pas égales.
• L’accélérateur de modèle géode sur GitHub présente l’utilisation de ce modèle de conception. Il est conçu pour aider les développeurs à l’implémenter avec des API réelles.
• Un exemple d’application QnA sur GitHub présente ce modèle de conception en pratique.