Stratégies d’architecture pour optimiser la mise à l’échelle et le partitionnement

S’applique à cette recommandation de liste de contrôle d’efficacité des performances d’Azure Well-Architected Framework :

Ce guide décrit les recommandations relatives à la mise à l’échelle et au partitionnement d’une charge de travail. La mise à l’échelle est la possibilité d’augmenter ou de diminuer les ressources allouées à une charge de travail en fonction de la demande. Le partitionnement implique de diviser la charge de travail en unités plus petites et gérables pour distribuer les données et le traitement sur plusieurs ressources. Une charge de travail qui ne met pas à l’échelle ou ne partitionne peut rencontrer des performances médiocres dans les périodes à forte demande et une capacité sous-utilisée dans les périodes à faible demande.

Définitions

La mise à l’échelle et le partitionnement contribuent à l’efficacité des performances en garantissant que les ressources sont utilisées efficacement et que la charge de travail peut gérer des charges variables. Ces pratiques sont particulièrement importantes dans les environnements cloud où les applications doivent être flexibles et adaptables aux demandes changeantes. La mise à l’échelle garantit que vous pouvez étendre la capacité de charge de travail pour répondre à des demandes croissantes. Le partitionnement vous permet de diviser efficacement les tâches ou les données pour gérer ces besoins croissants. La base de ces deux processus est la conception d’unité d’échelle de la charge de travail. Elle détermine la façon dont votre charge de travail doit croître et distribuer des tâches. En incorporant une approche fiable et contrôlée de la mise à l’échelle et du partitionnement, vous pouvez réduire les inefficacités potentielles des charges de travail.

Optimiser la mise à l’échelle

Optimiser la mise à l’échelle est le processus d’ajustement du nombre de serveurs, d’instances ou de ressources pour répondre aux demandes fluctuantes d’une charge de travail. Elle garantit que la charge de travail peut gérer un trafic ou des demandes accrus sans subir de dégradation des performances ou de temps d’arrêt.

Choisir une stratégie de mise à l’échelle

Le choix d’une stratégie de mise à l’échelle implique de décider entre les méthodes verticales ou horizontales pour améliorer la capacité d’une charge de travail en fonction de ses exigences spécifiques. La sélection de la stratégie appropriée garantit que les ressources sont ajustées efficacement pour répondre aux demandes de charge de travail sans surutilisation ni gaspillage. Pour choisir la stratégie de mise à l’échelle appropriée, vous devez comprendre les cas d’utilisation pour la mise à l’échelle verticale et horizontale et la façon dont elles répondent aux besoins de votre charge de travail.

Comprendre la mise à l’échelle verticale. À l’aide de la mise à l’échelle verticale, vous pouvez augmenter la capacité d’une seule ressource, comme la mise à niveau vers un serveur ou une taille d’instance plus grande. La mise à l’échelle verticale est utile lorsque la charge de travail peut tirer parti de l’augmentation de la puissance de traitement, de la mémoire ou d’autres ressources au sein d’une seule instance. La mise à l’échelle verticale est appropriée pour les charges de travail qui ne sont pas facilement divisées en parties plus petites ou lorsque l’architecture d’application ne prend pas en charge la mise à l’échelle horizontale.

Comprendre la mise à l’échelle horizontale. À l’aide de la mise à l’échelle horizontale, vous pouvez ajouter d’autres instances ou ressources pour distribuer la charge de travail sur plusieurs serveurs. La mise à l’échelle horizontale offre des avantages tels que la résilience améliorée, une capacité accrue et la capacité à gérer des demandes accrues de trafic ou de charge de travail. Il est efficace pour les applications natives cloud conçues pour s’exécuter sur plusieurs nœuds. La mise à l’échelle horizontale est appropriée pour les charges de travail qui peuvent être divisées en parties plus petites qui s’exécutent indépendamment.

Comprendre la charge de travail. L’adéquation de la mise à l’échelle verticale ou horizontale dépend des caractéristiques et exigences spécifiques de la charge de travail. La surveillance et les tests réguliers des performances dans les domaines suivants peuvent vous aider à optimiser la stratégie de mise à l’échelle au fil du temps :

• Exigences : comprendre les exigences spécifiques de la charge de travail en tenant compte de facteurs tels que les demandes de ressources, les besoins en scalabilité et les limitations de la charge de travail.

• Unités d’échelle : créez une conception d’unité d’échelle pour les composants censés être mis à l’échelle ensemble. Par exemple, 100 machines virtuelles peuvent nécessiter deux files d’attente et trois comptes de stockage pour gérer la charge de travail supplémentaire. L’unité d’échelle serait de 100 machines virtuelles, deux files d’attente et trois comptes de stockage. Vous devez mettre à l’échelle indépendamment tous les composants qui connaissent une fluctuation de l’utilisation de la capacité.

• Architecture : évaluez la conception de l’architecture d’application. Certaines applications peuvent être conçues de manière inhérente pour être mises à l’échelle horizontalement, avec des composants sans état qui peuvent être facilement distribués entre plusieurs instances. D’autres applications peuvent avoir des composants avec état ou des dépendances qui rendent la mise à l’échelle verticale plus appropriée. Évaluez les exigences d’extensibilité et d’élasticité de la charge de travail.

Concevoir une infrastructure à mettre à l’échelle

La conception de l’infrastructure à mettre à l’échelle est le processus de création d’une architecture capable de gérer des demandes et des charges de travail croissantes en ajoutant ou en ajustant les ressources selon les besoins. Elle implique la planification et l’implémentation de solutions qui peuvent être mises à l’échelle horizontalement ou verticalement pour prendre en charge la croissance. Les stratégies incluent l’évitement de singletons qui peuvent devenir des goulots d’étranglement et le découplage des composants d’application pour garantir une scalabilité indépendante. Lorsque vous concevez une charge de travail pour être évolutive, elle peut distribuer efficacement la charge de travail sur plusieurs ressources, ce qui empêche les goulots d’étranglement et optimise l’utilisation des ressources.

Évitez les singletons. Vous devez éviter l’utilisation d’une ressource centralisée unique pour l’ensemble de la charge de travail. Au lieu de cela, distribuez votre charge de travail sur plusieurs ressources pour améliorer la scalabilité, la tolérance de panne et les performances. Explorez quelques exemples et considérations de conception spécifiques pour éviter les singletons dans les ressources de charge de travail :

• Niveau de charge basé sur la file d’attente : au lieu de compter sur une file d’attente unique pour traiter les messages, envisagez de partitionner la charge de travail sur plusieurs files d’attente pour distribuer la charge de traitement. Il offre une meilleure scalabilité et un traitement parallèle.

• Traitement des données : les modèles Singleton apparaissent souvent dans les scénarios de traitement des données où le traitement ne se déclenche pas. Décomposez les tâches longues en tâches plus petites qui peuvent être mises à l’échelle pour répartir la charge de travail entre plusieurs ressources et tirer parti du parallélisme.

• Modèles de conception : les modèles de conception tels que fan-out/fan-in ou pipes et filtres peuvent aider à éviter les singletons dans les flux de travail. Ces modèles permettent la distribution des tâches de traitement entre plusieurs ressources et favorisent l’extensibilité et la flexibilité.

Dissocier les composants. Le découplage des composants d’application est un aspect important de la conception pour l’extensibilité. Il implique de décomposer l’application en composants plus petits et indépendants qui peuvent fonctionner et mettre à l’échelle indépendamment en fonction des exigences de charge de travail spécifiques. Par exemple, si un composant nécessite plus de ressources en raison d’une demande accrue, vous pouvez mettre à l’échelle ce composant sans affecter les autres. Cette flexibilité garantit une allocation efficace des ressources et empêche les goulots d’étranglement. En découplant des composants, vous pouvez isoler les défaillances et réduire l’effet sur l’application globale. Si un composant échoue, les autres composants peuvent continuer à fonctionner indépendamment.

Les composants découplés sont plus faciles à gérer et à mettre à jour. Les modifications ou mises à jour apportées à un composant peuvent être effectuées sans affecter les autres, car elles sont indépendantes. Suivez ces instructions pour dissocier les composants d’application pour l’extensibilité :

• Séparation des préoccupations : identifiez les responsabilités et les fonctionnalités de votre application. Divisez les responsabilités en composants distincts en fonction de leurs tâches spécifiques. Par exemple, vous pouvez avoir des composants distincts pour l’authentification utilisateur, le traitement des données et l’interface utilisateur.

• Couplage libre : concevez les composants pour communiquer entre eux par le biais d’interfaces et de protocoles bien définis. Cette conception réduit les dépendances entre les composants et permet un remplacement ou une mise à l’échelle plus facile des composants individuels.

• Communication asynchrone : utilisez des modèles de communication asynchrones tels que des files d’attente de messages ou des architectures pilotées par les événements pour dissocier les composants. Ces modèles permettent aux composants de traiter les tâches indépendamment à leur rythme, ce qui améliore l’évolutivité globale.

• Microservices : envisagez d’implémenter des microservices, qui sont de petits services indépendants qui se concentrent sur des fonctionnalités métier spécifiques. Chaque microservice peut être développé, déployé et mis à l’échelle indépendamment, offrant une plus grande flexibilité et une scalabilité accrues.

Concevoir une application à mettre à l’échelle

Lorsque vous mettez à l’échelle une charge de travail, vous devez concevoir l’application pour distribuer la charge. Simplement parce que vous pouvez ajouter d’autres réplicas au niveau de l’infrastructure ne signifie pas que votre application peut utiliser les réplicas. La conception d’une application à mettre à l’échelle consiste à structurer une application afin qu’elle puisse gérer des demandes accrues en distribuant sa charge de travail entre les ressources. Évitez les solutions qui nécessitent une affinité cliente, un verrouillage des données ou une affinité d’état pour une seule instance si possible. Vous souhaitez router un client ou un processus vers une ressource qui dispose d’une capacité disponible. Pour concevoir la scalabilité des applications, tenez compte des stratégies suivantes :

Éliminez l’état de session côté serveur. Vous devez concevoir des applications sans état dans la mesure du possible. Pour les applications avec état, vous devez utiliser un magasin d’états externe à votre serveur. La externalisation de l’état de session est la pratique du stockage des données de session en dehors du serveur d’applications ou du conteneur. Vous pouvez externaliser l’état de session pour distribuer des données de session sur plusieurs serveurs ou services, ce qui permet une gestion de session transparente dans un environnement distribué. Tenez compte des éléments suivants lors de l’externalisation de l’état de session :

• Évaluez les besoins de votre session. Comprendre les données de session qui doivent être stockées et gérées. Considérez les attributs de session, les délais d’expiration de session et toutes les exigences spécifiques pour la réplication ou la persistance de session. Déterminez la taille de votre état de session et la fréquence des opérations de lecture et d’écriture.

• Choisissez une solution. Sélectionnez une solution de stockage qui s’aligne sur vos besoins en matière de performances et d’extensibilité. Les options incluent l’utilisation d’un cache distribué, d’une base de données ou d’un service d’état de session. Prenez en compte des facteurs tels que la cohérence des données, la latence et l’extensibilité lors de votre choix.

• Configurez votre application. Mettez à jour votre application pour utiliser la solution de stockage d’état de session choisie. Vous devrez peut-être modifier les fichiers de configuration ou le code de votre application pour vous connecter au service de stockage externe.

• Mettez à jour votre logique. Modifiez la logique de gestion de session de votre application pour stocker et récupérer des données de session à partir de la solution de stockage externe. Vous devrez peut-être utiliser des API ou des bibliothèques fournies par la solution de stockage pour gérer l’état de session.

Éliminez l’affinité du client. L’affinité cliente est également appelée affinité de session ou sessions sticky. Lorsque vous éliminez l’affinité client, vous distribuez uniformément les requêtes client sur plusieurs réplicas ou serveurs, sans acheminer toutes les requêtes d’un client vers le même réplica. Cette configuration peut améliorer la scalabilité et les performances des applications en permettant à n’importe quel réplica disponible de traiter les requêtes.

Passez en revue votre algorithme d’équilibrage de charge. Un algorithme d’équilibrage de charge peut entraîner l’épinglage involontaire et artificiel du client où un trop grand nombre de requêtes sont envoyées à une instance back-end. L’épinglage peut se produire si l’algorithme est configuré pour toujours envoyer des requêtes du même utilisateur à la même instance. Cela peut également se produire si les demandes sont trop similaires les unes aux autres.

Éliminez le verrouillage des données. Le verrouillage des données garantit la cohérence, mais présente des inconvénients sur les performances. Cela peut entraîner des escalades de verrous et affecter négativement la concurrence, la latence et la disponibilité. Pour éliminer le verrouillage des données, vous devez implémenter une concurrence optimiste. Les bases de données non relationnelles doivent utiliser le contrôle d’accès concurrentiel optimiste et avoir le niveau de cohérence approprié. Votre stratégie de partitionnement des données doit également prendre en charge vos besoins en matière d’accès concurrentiel.

Utilisez la découverte de services dynamiques. La découverte de services dynamiques est le processus de détection et d’inscription automatique des services dans un système distribué. Il permet aux clients de découvrir les services disponibles sans être étroitement couplés à des instances spécifiques. Les clients ne doivent pas être en mesure de prendre une dépendance directe sur une instance spécifique dans la charge de travail. Pour éviter ces dépendances, vous devez utiliser un proxy pour distribuer et redistribuer des connexions clientes. Le proxy agit en tant qu’intermédiaire entre les clients et les services, fournissant une couche d’abstraction qui permet aux services d’être ajoutés ou supprimés sans affecter les clients.

Utilisez des tâches en arrière-plan. Lorsqu’une application est mise à l’échelle, elle peut gérer une charge de travail croissante ou un nombre plus élevé de requêtes simultanées. Décharger des tâches intensives en tant que tâches en arrière-plan permet à l’application principale de gérer les demandes des utilisateurs sans opérations gourmandes en ressources. Procédez comme suit pour décharger les tâches en arrière-plan :

1. Recherchez les tâches nécessitant beaucoup d’uc et d’E/S dans votre application que vous pouvez décharger. Ces tâches impliquent généralement des calculs ou des interactions lourds avec des ressources externes telles que des bases de données ou des opérations réseau.

2. Concevez votre application pour prendre en charge les tâches en arrière-plan. Dissociez les tâches intensives de la logique d’application principale et fournissez un mécanisme permettant de démarrer et de gérer des tâches en arrière-plan.

3. Implémentez le traitement des tâches en arrière-plan avec les technologies ou infrastructures appropriées. Incluez les fonctionnalités fournies par votre langage de programmation ou votre plateforme, telles que la programmation asynchrone, le threading ou les files d’attente de tâches. Contiennent des opérations intensives dans des tâches ou des threads distincts, ces tâches peuvent être exécutées simultanément ou planifiées pour s’exécuter à intervalles spécifiques.

4. Distribuez des tâches en arrière-plan s’il y en a beaucoup, ou si les tâches nécessitent beaucoup de temps ou de ressources. Pour une solution possible, consultez le modèle Consommateurs concurrents.

Configurer la mise à l’échelle

La configuration de la mise à l’échelle est le processus de configuration et d’ajustement des paramètres pour allouer dynamiquement des ressources en fonction des demandes de charge de travail. Il englobe des stratégies telles que l’utilisation de fonctionnalités de mise à l’échelle automatique, la compréhension des limites de mise à l’échelle du service et l’implémentation de métriques de charge significatives. Une configuration appropriée garantit qu’une application peut répondre à des demandes variables tout en optimisant l’efficacité. Lorsque vous configurez la mise à l’échelle, tenez compte des stratégies suivantes :

Utilisez des services avec la mise à l’échelle automatique. La fonctionnalité de mise à l’échelle automatique met automatiquement à l’échelle l’infrastructure pour répondre à la demande. Utilisez des offres PaaS (Platform as a Service) avec des fonctionnalités de mise à l’échelle automatique intégrées. La facilité de mise à l’échelle sur PaaS est un avantage majeur. Par exemple, le scale-out des machines virtuelles nécessite un équilibreur de charge distinct, une gestion des demandes client et un état stocké en externe. Les offres PaaS gèrent la plupart de ces tâches.

Limiter la mise à l’échelle automatique. Définissez les limites de mise à l’échelle automatique pour réduire la sur-mise à l’échelle, ce qui peut entraîner des coûts inutiles. Parfois, vous ne pouvez pas définir de limites de mise à l’échelle. Dans ces cas, vous devez définir des alertes pour vous avertir lorsque le composant atteint la limite d’échelle maximale et surdimensionné.

Comprendre les limites de mise à l’échelle du service. Lorsque vous comprenez les limites de mise à l’échelle du service, les incréments et les restrictions, vous pouvez prendre des décisions éclairées lors de la sélection d’un service. Les limites de mise à l’échelle déterminent si votre service choisi peut gérer la charge de travail attendue, mettre à l’échelle efficacement et répondre aux exigences de performances de votre application. Les limites de mise à l’échelle à prendre en compte sont les suivantes :

• Limites de mise à l’échelle : les limites de mise à l’échelle sont la capacité maximale qu’un emplacement ou un service peut gérer. Il est important de connaître ces limites pour vous assurer que le service peut prendre en charge la charge de travail attendue et gérer les pics d’utilisation sans dégradation des performances. Chaque ressource a une limite d’échelle supérieure. Si vous devez dépasser les limites de mise à l’échelle, vous devez partitionner votre charge de travail.

• Incréments de mise à l’échelle : les services sont mis à l’échelle aux incréments définis. Par exemple, les services de calcul peuvent être mis à l’échelle par instances et pods, tandis que les bases de données peuvent être mises à l’échelle par instances, unités de transaction et cœurs virtuels. Il est important de comprendre ces incréments pour optimiser l’allocation des ressources et empêcher le flapping des ressources.

• Restrictions de mise à l’échelle : certains services vous permettent d’effectuer un scale-up ou un scale-out, mais de limiter votre capacité à inverser automatiquement la mise à l’échelle. Vous devez effectuer une mise à l’échelle manuellement, ou vous devrez peut-être redéployer une nouvelle ressource. Ces limitations sont souvent pour protéger la charge de travail. Le scale-down ou la mise à l’échelle peuvent avoir des implications sur la disponibilité et les performances de la charge de travail. Un service peut appliquer certaines limitations ou contraintes pour vous assurer que la charge de travail dispose de ressources suffisantes pour fonctionner efficacement. Ces limitations peuvent affecter la cohérence et la synchronisation des données, en particulier dans les systèmes distribués. Le service peut avoir des mécanismes en place pour gérer la réplication et la cohérence des données pendant le scale-up ou le scale-out, mais peut ne pas fournir le même niveau de prise en charge pour le scale-down ou dans.

Utilisez des métriques de charge significatives. La mise à l’échelle doit utiliser des métriques de charge significatives comme déclencheurs de mise à l’échelle. Les métriques de charge significatives incluent des métriques simples, telles que le processeur ou la mémoire. Ils incluent également des métriques plus avancées, telles que la profondeur de file d’attente, les requêtes SQL, les requêtes de métriques personnalisées et la longueur de file d’attente HTTP. Envisagez d’utiliser une combinaison de métriques de charge simples et avancées comme déclencheur de mise à l’échelle.

Utilisez une mémoire tampon. Une mémoire tampon est une capacité inutilisée qui peut être utilisée pour gérer les pics de demande. Un plan de charge de travail bien conçu pour des pics inattendus dans la charge de travail. Vous devez ajouter une mémoire tampon pour gérer les pics de mise à l’échelle horizontale et verticale.

Empêcher le flapping. Flapping est une condition de bouclage qui se produit lorsqu’un événement de mise à l’échelle déclenche un événement de mise à l’échelle opposé, créant une action de mise à l’échelle continue et arrière. Par exemple, si la mise à l’échelle réduit le nombre d’instances, cela peut entraîner l’augmentation de l’utilisation du processeur dans les instances restantes, ce qui déclenche un événement de scale-out. L’événement de scale-out, à son tour, entraîne la suppression de l’utilisation de l’UC, en répétant le processus.

Il est important de choisir une marge adéquate entre les seuils de scale-out et de scale-in pour éviter le flapping. Vous pouvez empêcher les actions de scale-in et de scale-out fréquentes et inutiles en définissant des seuils qui offrent une différence significative dans l’utilisation du processeur.

Utilisez des tampons de déploiement. Il existe des techniques qui facilitent la mise à l’échelle d’une charge de travail. Vous pouvez utiliser le modèle Tampons de déploiement pour mettre facilement à l’échelle une charge de travail en ajoutant une ou plusieurs unités d’échelle.

Risque : si la mise à l’échelle permet d’optimiser les coûts en ajustant la capacité pour répondre à la demande, elle peut entraîner une augmentation globale des coûts pendant de longues périodes de forte demande.

Mise à l’échelle des tests

Le test de mise à l’échelle implique la simulation de différents scénarios de charge de travail dans un environnement contrôlé pour évaluer la façon dont une charge de travail répond à différents niveaux de demande. Elle permet de garantir l’efficacité des mises à l’échelle de la charge de travail, ce qui optimise l’efficacité des performances pendant les charges variées.

Vous devez vous assurer que votre charge de travail est mise à l’échelle efficacement dans des conditions réelles. Il est essentiel d’effectuer des tests de charge et de contrainte dans un environnement qui reflète votre configuration de production. Ces tests, effectués dans des environnements hors production, vous permettent d’évaluer à la fois les stratégies de mise à l’échelle verticale et horizontale et de déterminer celles qui optimisent les performances les plus efficacement. Voici une approche recommandée pour tester la mise à l’échelle :

• Définissez des scénarios de charge de travail. Identifiez les principaux scénarios de charge de travail que vous devez tester, tels que l’augmentation du trafic utilisateur, les demandes simultanées, le volume de données ou l’utilisation des ressources.

• Utilisez l’environnement de test de type production. Créez un environnement de test distinct qui ressemble étroitement à l’environnement de production en termes d’infrastructure, de configuration et de données.

• Définissez les métriques de performances. Définissez les métriques de performances à mesurer, telles que le temps de réponse, le débit, l’utilisation du processeur et de la mémoire et les taux d’erreur.

• Développez des cas de test. Développez des cas de test qui simulent différents scénarios de charge de travail, augmentant progressivement la charge pour évaluer les performances à différents niveaux.

• Exécutez et surveillez les tests. Exécutez les tests à l’aide des cas de test définis et collectez les données de performances à chaque niveau de charge. Surveillez le comportement de la charge de travail, la consommation des ressources et la dégradation des performances.

• Analysez et optimisez la mise à l’échelle. Analysez les résultats des tests pour identifier les goulots d’étranglement des performances, les limitations de scalabilité ou les domaines d’amélioration. Optimisez la configuration, l’infrastructure ou le code pour améliorer la scalabilité et les performances. La mise à l’échelle prend du temps, ce qui permet de tester les effets des retards de mise à l’échelle.

• Adressez les dépendances. Recherchez des problèmes de dépendance potentiels. La mise à l’échelle ou le partitionnement dans une zone d’une charge de travail peut entraîner des problèmes de performances sur une dépendance. Les parties avec état d’une charge de travail, telles que les bases de données, sont la cause la plus courante des problèmes de performances des dépendances. Les bases de données nécessitent une conception minutieuse pour effectuer une mise à l’échelle horizontale. Vous devez envisager des mesures, telles que l’accès concurrentiel optimiste ou le partitionnement des données, pour permettre un débit plus élevé à la base de données.

• Retestez après les ajustements. Répétez les tests d’extensibilité après l’implémentation d’optimisations pour valider les améliorations et vous assurer que la charge de travail peut gérer efficacement les charges de travail attendues.

Compromis : tenez compte des contraintes budgétaires et des objectifs d’efficacité des coûts de votre charge de travail. La mise à l’échelle verticale peut impliquer des coûts plus élevés en raison de la nécessité de ressources plus volumineuses et plus puissantes. La mise à l’échelle horizontale offre des économies en utilisant des instances plus petites qui peuvent être ajoutées ou supprimées en fonction de la demande.

Charge de travail de partition

Le partitionnement est le processus de division d’un jeu de données ou d’une charge de travail volumineux en parties plus petites et plus gérables appelées partitions. Chaque partition contient un sous-ensemble des données ou de la charge de travail et est généralement stockée ou traitée séparément. Le partitionnement permet le traitement parallèle et réduit la contention. La division de la charge de travail en unités plus petites permet à l’application de traiter chaque unité indépendamment. Le résultat est une meilleure utilisation des ressources et des temps de traitement plus rapides. Le partitionnement permet également de distribuer les données sur plusieurs appareils de stockage, de réduire la charge sur des appareils individuels et d’améliorer les performances globales.

Comprendre le partitionnement

L’approche de partitionnement spécifique que vous utilisez dépend du type de données ou de la charge de travail que vous avez et de la technologie que vous utilisez. Voici quelques stratégies courantes pour le partitionnement :

• Partitionnement horizontal : dans cette approche, le jeu de données ou la charge de travail est divisé en fonction de critères spécifiques, tels que des plages de valeurs ou des attributs spécifiques. Chaque partition contient un sous-ensemble des données qui répondent aux critères définis.

• Partitionnement vertical : dans cette approche, le jeu de données ou la charge de travail est divisé en fonction d’attributs ou de colonnes spécifiques. Chaque partition contient un sous-ensemble des colonnes ou attributs, ce qui permet un accès plus efficace aux données requises.

• Partitionnement fonctionnel : dans cette approche, les données ou la charge de travail sont divisées en fonction des fonctions ou opérations spécifiques qui doivent être effectuées. Chaque partition contient les données ou composants nécessaires pour une fonction spécifique, ce qui permet un traitement et des performances optimisés.

Planifier le partitionnement

Il est important de prendre en compte des facteurs tels que la distribution de données, les modèles de requête, la croissance des données et les exigences de charge de travail lors du partitionnement. Une planification et une conception appropriées sont essentielles pour garantir l’efficacité du partitionnement et optimiser l’efficacité des performances. Si vous traitez le partitionnement en tant qu’après-temps, il est plus difficile, car vous disposez déjà d’une charge de travail dynamique à gérer. Vous devrez peut-être modifier la logique d’accès aux données, distribuer de grandes quantités de données entre les partitions et prendre en charge l’utilisation continue pendant la distribution des données.

Implémenter le partitionnement

Il est important d’analyser les caractéristiques de vos données, des modèles d’accès, des exigences de concurrence et des objectifs d’extensibilité lors du choix du type de partitionnement à utiliser. Chaque type de partitionnement présente ses propres avantages et considérations. Voici quelques facteurs à prendre en compte pour chaque type de partitionnement :

• Le partitionnement horizontal est approprié lorsque vous souhaitez distribuer les données entre plusieurs ressources ou serveurs pour améliorer la scalabilité et les performances. Elle est efficace lorsque la charge de travail peut être parallélisée et traitée indépendamment sur chaque partition. Envisagez le partitionnement horizontal lorsque plusieurs utilisateurs ou processus doivent être en mesure d’accéder ou de mettre à jour le jeu de données simultanément.

• Le partitionnement vertical est approprié lorsque certains attributs ou colonnes sont fréquemment consultés, tandis que d’autres sont accessibles moins fréquemment. Le partitionnement vertical permet un accès efficace aux données requises en réduisant la récupération inutile des données.

• Le partitionnement fonctionnel est approprié lorsque différentes fonctions nécessitent différents sous-ensembles des données et peuvent être traitées indépendamment. Le partitionnement fonctionnel peut optimiser les performances en permettant à chaque partition de concentrer les opérations spécifiques.

Tester et optimiser le partitionnement

Testez le schéma de partitionnement pour vérifier l’efficacité et l’efficacité de la stratégie afin de pouvoir apporter des ajustements pour améliorer les performances. Mesurez des facteurs tels que le temps de réponse, le débit et l’extensibilité. Comparez les résultats aux objectifs de performances et identifiez les goulots d’étranglement ou problèmes. En fonction de l’analyse, identifiez les opportunités d’optimisation potentielles. Vous devrez peut-être redistribuer des données entre les partitions, ajuster les tailles de partition ou modifier les critères de partitionnement.

Compromis : le partitionnement ajoute de la complexité à la conception et au développement d’une charge de travail. Le partitionnement nécessite des conversations et une planification entre les développeurs et les administrateurs de base de données.

Risque : le partitionnement introduit des problèmes potentiels qui doivent être pris en compte et résolus, notamment :

• Asymétrie des données : le partitionnement peut entraîner une asymétrie des données, où certaines partitions reçoivent une quantité disproportionnée de données ou de charge de travail par rapport à d’autres. L’asymétrie des données peut entraîner des déséquilibres de performances et une contention accrue sur des partitions spécifiques.

• Performances des requêtes : les schémas de partitionnement mal conçus peuvent affecter négativement les performances des requêtes. Si les requêtes doivent accéder aux données sur plusieurs partitions, elles peuvent nécessiter une coordination et une communication supplémentaires entre les partitions, ce qui entraîne une latence accrue.

Facilitation Azure

Optimisation de la mise à l’échelle. Azure dispose de la capacité d’infrastructure pour prendre en charge la mise à l’échelle verticale et horizontale. Les services Azure ont différents niveaux de performances appelés références SKU. Les références SKU vous permettent d’effectuer une mise à l’échelle verticalement. De nombreuses ressources Azure prennent en charge la mise à l’échelle automatique ou d’autres options de mise à l’échelle sur place. Certaines ressources prennent en charge les métriques avancées ou les entrées personnalisées pour prendre en charge le comportement de mise à l’échelle de réglage précis. La plupart des implémentations de mise à l’échelle dans Azure peuvent définir des limites et prendre en charge l’observabilité nécessaire pour être alertée pour changer.

Azure Monitor vous permet de surveiller différentes métriques et conditions dans vos applications et votre infrastructure. Vous pouvez utiliser Monitor pour déclencher des actions de mise à l’échelle automatisées basées sur des règles prédéfinies. Par exemple, dans Azure Kubernetes Service (AKS), vous pouvez utiliser Monitor pour activer la mise à l’échelle automatique des pods horizontaux (HPA) et la mise à l’échelle automatique du cluster. À l’aide des fonctionnalités de surveillance et d’alerte de Monitor, vous pouvez faciliter efficacement la mise à l’échelle dans Azure et vous aider à garantir que vos applications et votre infrastructure peuvent s’ajuster dynamiquement pour répondre à la demande.

Vous pouvez également créer une mise à l’échelle automatique personnalisée dans Azure. Vous pouvez utiliser des alertes dans Monitor pour les ressources qui n’ont pas de fonctionnalité de mise à l’échelle automatique. Ces alertes peuvent être configurées pour être basées sur des requêtes ou basées sur des métriques et peuvent effectuer des actions à l’aide d’Azure Automation. Automation fournit une plateforme permettant d’héberger et d’exécuter du code PowerShell et Python sur Azure, le cloud et les environnements locaux. Il offre des fonctionnalités telles que le déploiement de runbooks à la demande ou selon une planification, l’historique des exécutions et la journalisation, le magasin de secrets intégré et l’intégration du contrôle de code source.

Conception d’une application à mettre à l’échelle : Voici quelques façons dont Azure facilite la conception de la mise à l’échelle des applications ;

• Élimination du verrouillage des données : dans Azure SQL Database, vous pouvez activer le verrouillage optimisé pour améliorer les performances sur les bases de données qui nécessitent une cohérence stricte.

• Utilisation de tâches en arrière-plan : Azure offre des services et des conseils pour l’implémentation de travaux en arrière-plan. Pour plus d’informations, consultez travaux en arrière-plan.

• Implémentation de l’équilibrage de charge : Azure fournit des équilibreurs de charge qui ne nécessitent pas d’affinité client. Ces équilibreurs de charge incluent Azure Front Door, Azure Application Gateway et Azure Load Balancer.

Partitionnement d’une charge de travail : Azure propose différentes stratégies de partitionnement pour différents magasins de données. Ces stratégies permettent d’améliorer les performances et la scalabilité en répartissant les données sur plusieurs partitions. Pour plus d’informations, consultez stratégies de partition de données.

Liens connexes

• Pourquoi partitionner des données ?
• Meilleures pratiques pour la mise à l’échelle automatique
• Vue d’ensemble de la fonctionnalité de mise à l’échelle automatique dans Azure
• Partitionnement horizontal, vertical et fonctionnel des données
• Considérations relatives à la conception d’application

Liste de contrôle d’efficacité des performances

Reportez-vous à l’ensemble complet de recommandations.