Plateforme de données pour charges de travail critiques sur Azure

Dans une architecture stratégique, tout état doit être stocké en dehors de la capacité de calcul autant que possible. Le choix de la technologie est basé sur ces caractéristiques architecturales clés :

Caractéristiques	Considérations
Performances	Combien de capacité de calcul est nécessaire ?
Latence	Quel impact aura la distance entre l’utilisateur et le magasin de données sur la latence ? Quel est le niveau de cohérence souhaité en tenant compte de la latence ?
Réactivité	Le magasin de données doit-il toujours être disponible ?
Scalabilité	Qu’est-ce que le schéma de partitionnement ?
Durabilité	Les données devraient-elles durer longtemps ? Qu’est-ce que la stratégie de rétention ?
Résilience	En cas de défaillance, le magasin de données peut-il basculer automatiquement ? Quelles mesures sont en place pour réduire le temps de basculement ?
Sécurité	Les données sont-elles chiffrées ? Le magasin de données est-il accessible sur un réseau public ?

Dans cette architecture, il existe deux magasins de données :

• Sauvegarde de la base de données

  Magasins liés à la charge de travail. Il est recommandé de stocker tous les états globalement dans une base de données séparée des empreintes régionales. Créez une la redondance en déployant la base de données dans plusieurs régions. Pour les charges de travail stratégiques, la synchronisation des données dans plusieurs régions devrait être la première préoccupation. En outre, en cas de défaillance, les demandes d’écriture dans la base de données doivent toujours être fonctionnelles.

  Une réplication des données dans une configuration active-active est vivement recommandée. L’application devrait être en mesure de se connecter instantanément à une autre région. Toutes les instances devraient pouvoir traiter les demandes de lecture et d’écriture.

• Agent de messages

  Le seul service avec état dans l’empreinte régionale est le répartiteur de messages qui stocke les demandes pendant une courte période. Le répartiteur répond au besoin de mise en mémoire tampon et de messagerie fiable. Les demandes traitées sont conservées dans la base de données globale.

Pour d’autres considérations concernant les données, consultez Conseils stratégiques en matière de Well-Architected Framework : Considérations relatives à la plateforme de données.

Base de données

Cette architecture utilise Azure Cosmos DB for NoSQL. Cette option est choisie, car elle fournit la plupart des fonctionnalités nécessaires dans cette conception :

• Écriture multirégions

  L’écriture multirégions est activée avec des réplicas déployés dans chaque région dans laquelle une empreinte est déployée. Chaque empreinte peut écrire localement, et Azure Cosmos DB gère la réplication et la synchronisation des données entre les empreintes. Cette fonctionnalité réduit considérablement la latence pour les utilisateurs finaux géographiquement distribués de l’application. L’implémentation de référence d’Azure Mission-Critical utilise la technologie multimaître pour offrir une résilience et une disponibilité maximales.

  La redondance de zone est également activée dans chaque région répliquée.

  Pour plus d’informations sur les écritures multirégions, consultez Configurer les fonctionnalités multirégions dans les applications qui utilisent Azure Cosmos DB.

• Gestion des conflits

  En raison de la possibilité d’effectuer des écritures dans plusieurs régions, il est nécessaire d’adopter un modèle de gestion des conflits, car les écritures simultanées peuvent introduire des conflits d’enregistrement. Le modèle par défaut Last Writer Wins est utilisé pour la conception Mission Critical. Le dernier enregistreur, tel que défini par les horodatages associés des enregistrements, remporte le conflit. Azure Cosmos DB for NoSQL permet également de définir une propriété personnalisée.

• Optimisation des requêtes

  Une recommandation générale d’efficacité des requêtes pour les conteneurs lourds en lecture avec un nombre élevé de partitions consiste à ajouter un filtre d’égalité avec l’ID d’élément identifié. Vous trouverez un examen approfondi des recommandations d’optimisation des requêtes dans la rubrique Résoudre des problèmes de requête lors de l’utilisation d’Azure Cosmos DB.

• Fonctionnalité de sauvegarde

  Il est recommandé d’utiliser la fonctionnalité de sauvegarde native d’Azure Cosmos DB pour la protection des données. La fonctionnalité de sauvegarde d’Azure Cosmos DB prend en charge les sauvegardes en ligne et la restauration des données à la demande.

Notes

La plupart des charges de travail ne sont pas purement OLTP. Il existe une demande croissante de rapports en temps réel, telles que l’exécution de rapports à partir du système d’exploitation. Cela est également appelé HTAP (Traitement transactionnel et analytique hybride). Azure Cosmos DB prend en charge cette fonctionnalité via Azure Synapse Link pour Azure Cosmos DB.

Modèle de données pour la charge de travail

Le modèle de données doit être conçu de façon à ce que les fonctionnalités offertes par les bases de données relationnelles traditionnelles ne soient pas nécessaires. Par exemple, les clés étrangères, le schéma de ligne/colonne strict, les vues, etc.

La charge de travail présente les caractéristiques d’accès aux données suivantes :

• Modèle de lecture :
  • Lectures de points : récupération (fetch) d’un seul enregistrement. L’ID d’élément et la clé de partition sont directement utilisés pour une optimisation maximale (1 RU par demande).
  • Lectures de liste - Obtention d’éléments de catalogue à afficher dans une liste. FeedIterator avec une limite sur le nombre de résultats est utilisé.
• Modèle d’écriture :
  • Petites écritures - Les demandes insèrent généralement un seul ou un petit nombre d’enregistrements dans une transaction.
• Conçu pour gérer le trafic élevé des utilisateurs finaux avec possibilité de mise à l’échelle pour gérer la demande de trafic de l’ordre de millions d’utilisateurs.
• Petite charge utile ou taille de jeu de données - Généralement de l’ordre de quelques Ko.
• Temps de réponse faible (de l’ordre de quelques millisecondes).
• Latence faible (de l’ordre de quelques millisecondes).

Configuration

Azure Cosmos DB est configuré comme suit :

• Le niveau de cohérence est défini sur la cohérence de session par défaut, car il s’agit du niveau le plus largement utilisé pour les applications distribuées dans une seule région et à l’échelle mondiale. Une cohérence plus faible avec un débit plus élevé n’est pas nécessaire en raison de la nature asynchrone du traitement des écritures et ne nécessite pas de faible latence sur l’écriture de base de données.

  Notes

  Le niveau de cohérence Session offre un compromis raisonnable en matière de latence, de disponibilité et de garanties de cohérence pour cette application spécifique. Il est important de comprendre que le niveau de cohérence forte n’est pas disponible pour les bases de données d’écriture multimaîtres.

• La clé de partition est définie sur /id pour toutes les collections. Cette décision est basée sur le modèle d’utilisation qui consiste principalement à « écrire de nouveaux documents avec le GUID comme ID » et à « lire une large gamme de documents par ID ». À condition que le code d’application conserve l’unicité de son ID, les nouvelles données sont distribuées uniformément dans les partitions par Azure Cosmos DB, d’où une mise à l’échelle infinie.

• La stratégie d’indexation est configurée sur les regroupements pour optimiser les requêtes. Pour optimiser le coût et les performances des RU, une stratégie d’indexation personnalisée est utilisée. Cette stratégie indexe uniquement les propriétés utilisées dans les prédicats de requête. Par exemple, l’application n’utilise pas le champ de texte de commentaire comme filtre dans les requêtes. Il a été exclu de la stratégie d’indexation personnalisée.

Voici un exemple de l’implémentation qui montre les paramètres de stratégie d’indexation avec Terraform :

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Pour plus d’informations sur la connexion de l’application à Azure Cosmos DB dans cette architecture, consultez les Considérations relatives à la plateforme d’applications pour les charges de travail stratégiques

Les services de messagerie

Les systèmes stratégiques utilisent souvent des services de messagerie pour le traitement des messages ou des événements. Ces services favorisent le couplage faible et agissent comme une mémoire tampon qui isole le système contre les pics inattendus de la demande.

• Azure Service Bus est recommandé pour les charges de travail basées sur les messages lors de la gestion des messages à valeur élevée.
• Azure Event Hubs est recommandé pour les systèmes basés sur des événements qui traitent des volumes élevés d’événements ou de télémétrie.

Voici quelques considérations et recommandations de conception pour Azure Service Bus premium et Azure Event Hubs dans une architecture stratégique.

Gérer la charge

Le système de messagerie doit être en mesure de gérer le débit requis (en Mo par seconde). Tenez compte des éléments suivants :

• Les exigences non fonctionnelles (NFR) du système doivent spécifier la taille moyenne des messages et le nombre maximal de messages/seconde pris en charge par chaque empreinte. Ces informations peuvent être utilisées pour calculer le nombre maximal de Mo/seconde requis par empreinte.
• L’impact d’un basculement doit être pris en compte lors du calcul du nombre maximal de Mo/seconde requis par empreinte.
• Pour Azure Service Bus, les NFR doivent spécifier toutes les fonctionnalités Service Bus avancées telles que les sessions et les messages de déduplication. Ces fonctionnalités affectent le débit de Service Bus.
• Le débit de Service Bus avec les fonctionnalités requises doit être calculé en le testant en termes de Mo/seconde par unité de messagerie. Pour plus d’informations sur ce sujet, consultez Couches messagerie Service Bus premium et standard.
• Le débit d’Azure Event Hubs doit être calculé en le testant en termes de Mo/seconde par unité de débit pour le niveau standard ou l’unité de traitement pour le niveau premium. Pour plus d’informations sur ce sujet, consultez Mise à l’échelle avec Event Hubs.
• Les calculs ci-dessus peuvent être utilisés pour vérifier que le service de messagerie peut gérer la charge requise par empreinte et le nombre requis d’unités d’échelle nécessaires pour répondre à cette charge.
• La section Opérations traite de la mise à l’échelle automatique.

Chaque message doit être traité

Azure Service Bus niveau premium est la solution recommandée pour les messages à valeur élevée pour lesquels le traitement doit être garanti. Les informations suivantes concernent cette exigence lors de l’utilisation d’Azure Service Bus premium :

• Pour garantir que les messages sont correctement transférés vers le répartiteur et acceptés par celui-ci, les producteurs de messages doivent utiliser l’un des clients d’API Service Bus pris en charge. Les API prises en charge sont retournées correctement uniquement à partir d’une opération d’envoi si le message a été conservé dans la file d’attente/rubrique.

• Pour vous assurer que les messages sur le bus sont traités, vous devez utiliser le mode de réception PeekLock. Ce mode active le traitement Au moins une fois. Voici le processus détaillé :

  • Le consommateur de messages reçoit le message à traiter.
  • Le consommateur reçoit un verrou exclusif sur le message pendant une durée donnée.
  • Si le consommateur traite correctement le message, il renvoie un accusé de réception au répartiteur et le message est supprimé de la file d’attente.
  • Si un accusé de réception n’est pas reçu par le répartiteur pendant la période allouée, ou si le gestionnaire abandonne explicitement le message, le verrou exclusif est libéré. Le message est ensuite disponible pour que d’autres consommateurs traitent le message.
  • Si un message n’est pas traité avec succès un nombre configurable de fois, ou si le gestionnaire transfère le message à la file d’attente de lettres mortes.
    • Pour vous assurer qu’une action soit effectuée sur les messages envoyés à la file d’attente de lettres mortes, la file d’attente de lettres mortes doit être surveillée et les alertes doivent être définies.
    • Le système doit disposer d’outils permettant aux opérateurs de pouvoir inspecter, corriger et soumettre à nouveau des messages.

• Étant donné que les messages peuvent potentiellement être traités plusieurs fois, les gestionnaires de messages doivent être rendus idempotents.

Traitement des messages idempotent

Dans RFC 7231, le Hypertext Transfer Protocol déclare, « Une... méthode de demande est dite idempotente si l’exécution de plusieurs requêtes identiques à l’aide de cette méthode est censée produire le même effet sur le serveur que l’exécution d’une seule de ces requêtes. »

Une technique courante de gestion des messages est de vérifier dans un magasin persistant, comme une base de données, si le message a déjà été traité. S’il a été traité, vous ne réexécutez pas la logique pour le traiter à nouveau.

• Parfois, le traitement du message inclut des opérations de base de données, en particulier l’insertion de nouveaux enregistrements avec des identificateurs générés par la base de données. Les nouveaux messages peuvent être émis au répartiteur, qui contient ces identificateurs. Étant donné qu’il n’y a pas de transactions distribuées qui englobent à la fois la base de données et le répartiteur de messages, plusieurs complications peuvent se produire si le processus qui exécute le code échoue. Regardez les exemples de situations suivants :
  • Le code qui émet les messages peut s’exécuter avant la validation de la transaction de base de données, c’est-à-dire le nombre de développeurs qui travaillent à l’aide du modèle Unit of Work. Ces messages peuvent s’échapper, si l’échec se produit entre l’appel du répartiteur et la demande de validation de la transaction de base de données. À mesure que la transaction est restaurée, ces ID générés par la base de données sont également annulés, ce qui les laisse disponibles pour d’autres codes qui peuvent s’exécuter en même temps. Cela peut amener les destinataires des messages d’échappement à traiter les mauvaises entrées de base de données, ce qui nuit à la cohérence et à l’exactitude globales de votre système.
  • Si les développeurs placent le code qui émet le message après la fin de la transaction de base de données, le processus peut toujours échouer entre ces opérations (transaction validée - message envoyé). Lorsque cela se produit, le message passe à nouveau par le traitement, mais cette fois la clause de protection idempotence voit qu’elle a déjà été traitée (en fonction des données stockées dans la base de données). La clause ignore le code émettant le message, croyant que tout a été effectué la dernière fois. Les systèmes en aval, qui s’attendaient à recevoir des notifications sur le processus terminé, ne reçoivent rien. Cette situation entraîne à nouveau un état global d’incohérence.
• La solution aux problèmes ci-dessus implique l’utilisation du modèle de boîte de réception transactionnelle, où les messages sortants sont stockés sur le côté, dans le même magasin transactionnel que les données métier. Les messages sont ensuite transmis au répartiteur de messages, lorsque le message initial a été traité avec succès.
• Étant donné que de nombreux développeurs ne connaissent pas ces problèmes ou leurs solutions, afin de garantir que ces techniques sont appliquées de manière cohérente dans un système stratégique, nous vous suggérons d’avoir les fonctionnalités de la boîte de réception et de l’interaction avec le répartiteur de messages incluses dans un wrapper dans un type de bibliothèque. Tout code traitant et envoyant des messages significatifs pour la transaction doit utiliser cette bibliothèque, plutôt que d’interagir directement avec le répartiteur de messages.
  • Les bibliothèques qui implémentent cette fonctionnalité dans .NET incluent NServiceBus et MassTransit.

Haute disponibilité et récupération d’urgence

Le répartiteur de messages doit être disponible pour que les producteurs envoient des messages et que les consommateurs puissent les recevoir. Les détails suivants concernent cette exigence :

• Pour garantir la disponibilité la plus élevée avec Service Bus, utilisez le niveau premium, qui prend en charge les zones de disponibilité dans les régions de prise en charge. Avec les zones de disponibilité, les messages et les métadonnées sont répliqués sur trois centres de données disparates dans la même région.
• Utilisez les SDK Service Bus ou Event Hubs pris en charge pour réessayer automatiquement les échecs de lecture ou d’écriture.
• Envisagez des modèles de réplication active/active ou réplication active/passive pour bénéficier d’une protection contre les sinistres régionaux.

Notes

La géo-reprise d’activité après sinistre d’Azure Service Bus réplique uniquement les métadonnées entre les régions. Cette fonctionnalité ne réplique pas les messages.

Surveillance

Le système de messagerie agit comme une mémoire tampon entre les producteurs de messages et les consommateurs. Il existe des types d’indicateurs clés que vous devez surveiller dans un système stratégique qui fournit des informations précieuses décrites ci-dessous :

• Limitation : la limitation indique que le système n’a pas les ressources nécessaires pour traiter la requête. Service Bus et Event Hubs prennent en charge la surveillance des demandes limitées. Vous devez alerter sur cet indicateur.
• Profondeur de file d’attente : une profondeur de file d’attente croissante peut indiquer que les processeurs de messages ne fonctionnent pas ou qu’il n’y a pas suffisamment de processeurs pour gérer la charge actuelle. La profondeur de file d’attente peut être utilisée pour informer la logique de mise à l’échelle automatique des gestionnaires.
  • Pour Service Bus, la profondeur de file d’attente est exposée en tant que nombre de messages
  • Pour Event Hubs, les consommateurs doivent calculer la profondeur de file d’attente par partition et envoyer (push) la métrique à votre logiciel de surveillance. Pour chaque lecture, le consommateur obtient le numéro de séquence de l’événement actuel et les propriétés d’événement du dernier événement placé en file d’attente. Le consommateur peut calculer le décalage.
• File d’attente de lettres mortes : les messages dans la file d’attente de lettres mortes représentent les messages qui n’ont pas pu être traités. Ces messages nécessitent généralement une intervention manuelle. Les alertes doivent être définies sur la file d’attente de lettres mortes.
  • Service Bus a une file d’attente de lettres mortes et une métrique DeadLetteredMessages.
  • Pour Event Hubs, cette fonctionnalité doit être une logique personnalisée intégrée au consommateur.
• Utilisation du processeur/de la mémoire : le processeur et la mémoire doivent être surveillés pour s’assurer que le système de messagerie dispose de suffisamment de ressources pour traiter la charge actuelle. Service Bus premium et Event Hubs premium exposent l’utilisation du processeur et de la mémoire.
  • Les unités de messagerie sont utilisées dans Service Bus pour isoler les ressources telles que le processeur et la mémoire d’un espace de noms. Le dépassement d’un seuil applicable au processeur et à la mémoire peut indiquer qu’il n’y a pas suffisamment d’unités de messagerie configurées, tandis que son passage au-dessous d’autres seuils peut indiquer qu’il y a trop d’unités de messagerie configurées. Ces indicateurs peuvent être utilisés pour mettre à l’échelle automatiquement les unités de messagerie.
  • Le niveau Event Hubs premium utilise des unités de traitement pour isoler les ressources, tandis que le niveau standard utilise des unités de débit. Ces niveaux ne nécessitent pas d’interaction avec le processeur/la mémoire pour augmenter automatiquement les unités de traitement ou les unités de débit.

Contrôle d’intégrité

L’intégrité du système de messagerie doit être prise en compte dans les contrôles d’intégrité d’une application stratégique. Tenez compte des facteurs suivants :

• Le système de messagerie agit comme une mémoire tampon entre les producteurs de messages et les consommateurs. L’empreinte peut être considérée comme saine si les producteurs sont en mesure d’envoyer des messages au répartiteur et si les consommateurs sont en mesure de traiter correctement les messages du répartiteur.
• Le contrôle d’intégrité doit s’assurer que les messages peuvent être envoyés au système de messages.

Étapes suivantes

Déployez l’implémentation de référence pour comprendre pleinement les ressources utilisées dans cette architecture, ainsi que leur configuration.

Implémentation : Mission-Critical Online