Recommandations pour l’optimisation de la mise à l’échelle et du partitionnement
S’applique à cette recommandation de liste de vérification de l’efficacité des performances d’Azure Well-Architected Framework :
| PE :05 | Optimisez la mise à l’échelle et le partitionnement. Incorporez une mise à l’échelle et un partitionnement fiables et contrôlés. La conception de l’unité d’échelle de la charge de travail est la base de la stratégie de mise à l’échelle et de partitionnement. |
|---|
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 se met pas à l’échelle ou ne partitionne pas peut rencontrer des performances médiocres dans les périodes de forte demande et une capacité sous-utilisée dans les périodes de faible demande.
Définitions
| Terme | Définition |
|---|---|
| Mise à l’échelle automatique | Fonctionnalité qui ajuste automatiquement les limites de capacité d’un service en fonction de configurations prédéfinies, ce qui lui permet d’effectuer un scale-up ou un scale-down en fonction des besoins. |
| Capacité | Limite supérieure ou capacité maximale d’un service ou d’une fonctionnalité donné. |
| Affinité client (affinité de session) | Le routage intentionnel des requêtes d’un client unique vers un serveur unique instance pour garantir une gestion cohérente des sessions. |
| Cohérence (base de données distribuée) | L’uniformité des données sur plusieurs nœuds d’une base de données distribuée, garantissant que tous les réplicas ont les mêmes données à un moment donné dans le temps. |
| Cohérence (base de données relationnelle) | Propriété d’une transaction faisant passer une base de données d’un état valide à un autre, en conservant l’intégrité des données. |
| Niveau de cohérence | Configuration qui définit comment et quand les données sont répliquées dans un système de base de données distribuée, déterminant le compromis entre cohérence et performances. |
| Verrouillage des données | Mécanisme utilisé pour empêcher les mises à jour simultanées des mêmes données. |
| Scalabilité horizontale | Approche de mise à l’échelle qui ajoute des instances d’un type de ressource donné. |
| Accès concurrentiel optimiste | Approche de mise à jour des bases de données qui utilise des instantanés pour effectuer des mises à jour au lieu des mécanismes de verrouillage traditionnels. |
| Partitionnement | Processus de division physique des données en magasins de données distincts. |
| Scalabilité | Capacité d’une charge de travail à modifier dynamiquement ses limites de capacité pour répondre à différents niveaux de demande. |
| Unité d'échelle | Groupe de ressources qui sont mises à l’échelle proportionnellement ensemble. |
| Affinité d’état | Stockage des données de session client sur un serveur unique afin que le même serveur gère les requêtes suivantes du même client. |
| Scalabilité verticale | Une approche de mise à l’échelle qui ajoute de la capacité de calcul aux ressources existantes. |
Stratégies de conception
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 à l’évolution des demandes. La mise à l’échelle vous permet d’étendre la capacité de charge de travail pour répondre aux 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 de l’unité d’échelle de la charge de travail. Il détermine la façon dont votre charge de travail doit croître et distribuer les tâches. En incorporant une approche fiable et contrôlée de la mise à l’échelle et du partitionnement, vous pouvez contourner les inefficacités potentielles de la charge 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. Il garantit que la charge de travail peut gérer l’augmentation du trafic ou des demandes 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 choisir entre des 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 ou gaspillage. Pour choisir la stratégie de mise à l’échelle appropriée, vous devez comprendre les cas d’utilisation de la mise à l’échelle verticale et horizontale et la façon dont ils 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 ressource unique, telle que la mise à niveau vers un serveur plus grand ou instance taille. La mise à l’échelle verticale est utile lorsque la charge de travail peut bénéficier d’une puissance de traitement, d’une mémoire ou d’autres ressources accrues au sein d’une seule instance. La mise à l’échelle verticale convient aux charges de travail qui ne sont pas facilement divisées en parties plus petites ou lorsque l’architecture de l’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 des instances ou des ressources supplémentaires pour répartir la charge de travail sur plusieurs serveurs. La mise à l’échelle horizontale offre des avantages tels qu’une meilleure résilience, une capacité accrue et la capacité à gérer l’augmentation du trafic ou des demandes 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. La pertinence de la mise à l’échelle verticale ou horizontale dépend des caractéristiques et des exigences spécifiques de la charge de travail. La surveillance et les tests réguliers des performances dans les domaines suivants peuvent aider à optimiser la stratégie de mise à l’échelle au fil du temps :
Exigences : comprenez les exigences spécifiques de la charge de travail en prenant en compte des facteurs tels que les demandes de ressources, les besoins d’extensibilité 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 100 machines virtuelles, deux files d’attente et trois comptes de stockage. Vous devez mettre à l’échelle de manière indépendante tous les composants qui subissent une fluctuation de l’utilisation de la capacité.
Architecture : évaluez la conception de l’architecture de l’application. Certaines applications peuvent être conçues par nature pour être mises à l’échelle horizontalement, avec des composants sans état qui peuvent être facilement distribués sur 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 de scalabilité et d’élasticité de la charge de travail.
Concevoir l’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 les demandes et la charge de travail croissantes en ajoutant ou en ajustant des ressources en fonction des besoins. Elle implique la planification et l’implémentation de solutions pouvant être mises à l’échelle horizontalement ou verticalement pour répondre à la croissance. Les stratégies incluent d’éviter les singletons qui peuvent devenir des goulots d’étranglement et de découpler les composants d’application pour garantir une scalabilité indépendante. Lorsque vous concevez une charge de travail pour qu’elle soit évolutive, elle peut répartir efficacement la charge de travail sur plusieurs ressources, ce qui évite les goulots d’étranglement et optimise l’utilisation des ressources.
Évitez les singletons. Vous devez éviter d’utiliser une seule ressource centralisée pour l’ensemble de la charge de travail. Au lieu de cela, répartissez votre charge de travail sur plusieurs ressources pour améliorer la scalabilité, la tolérance de panne et les performances. Explorez quelques exemples spécifiques et considérations de conception pour éviter les singletons dans les ressources de charge de travail :
Nivellement de charge basé sur la file d’attente : au lieu de compter sur une seule file d’attente pour traiter les messages, envisagez de partitionner la charge de travail sur plusieurs files d’attente pour répartir 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 mieux mises à l’échelle pour répartir la charge de travail sur 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 Filters peuvent aider à éviter les singletons dans les workflows. Ces modèles permettent la distribution des tâches de traitement sur 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 la scalabilité. Cela 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 les composants, vous pouvez isoler les défaillances et réduire l’effet sur l’ensemble de l’application. 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 d’un composant peuvent être apportées sans affecter les autres, car elles sont indépendantes. Suivez ces instructions pour dissocier les composants d’application pour la scalabilité :
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 souple : concevez les composants pour communiquer entre eux via des interfaces et des protocoles bien définis. Cette conception réduit les dépendances entre les composants et facilite le remplacement ou la mise à l’échelle de 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 découpler davantage les composants. Ces modèles permettent aux composants de traiter des tâches indépendamment à leur propre rythme, ce qui améliore la scalabilité 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, ce qui offre une plus grande flexibilité et scalabilité.
Concevoir une application à l’échelle
Lorsque vous mettez à l’échelle une charge de travail, vous devez concevoir l’application pour distribuer la charge. Ce n’est pas parce que vous pouvez ajouter d’autres réplicas au niveau de l’infrastructure que votre application peut utiliser les réplicas. La conception d’une application à l’échelle consiste à structurer une application afin qu’elle puisse gérer les demandes accrues en répartissant sa charge de travail entre les ressources. Évitez les solutions qui nécessitent une affinité client, un verrouillage des données ou une affinité d’état pour une seule instance si possible. Vous souhaitez acheminer un client ou un processus vers une ressource dont la capacité est disponible. Pour concevoir la scalabilité des applications, tenez compte des stratégies suivantes :
Éliminer l’état de session côté serveur. Vous devez concevoir des applications sans état dans la cas où cela est possible. Pour les applications avec état, vous devez utiliser un magasin d’état externe à votre serveur. L’extériorisation de l’état de session consiste à stocker des données de session en dehors du serveur d’applications ou du conteneur. Vous pouvez externaliser l’état de session pour distribuer les données de session sur plusieurs serveurs ou services, ce qui permet une gestion transparente des sessions dans un environnement distribué. Tenez compte des éléments suivants lors de l’extériorisation de l’état de session :
Évaluez vos exigences de session. Comprendre les données de session qui doivent être stockées et gérées. Tenez compte des attributs de session, des délais d’expiration de session et des exigences spécifiques en matière de réplication ou de 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. Tenez compte de facteurs tels que la cohérence, la latence et la scalabilité des données lors de votre choix.
Configurer 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é client. L’affinité client est également appelée affinité de session ou sessions collantes. Lorsque vous éliminez l’affinité client, vous répartissez uniformément les requêtes client sur plusieurs réplicas ou serveurs, sans router 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 à tous les réplica disponibles de traiter les demandes.
Passez en revue votre algorithme d’équilibrage de charge. Un algorithme d’équilibrage de charge peut provoquer l’épinglage involontaire et artificiel du client lorsque trop de requêtes sont envoyées à un instance principal. L’épinglage peut se produire si l’algorithme est configuré pour toujours envoyer des requêtes du même utilisateur au même instance. Cela peut également se produire si les requêtes 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 en matière de 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 la concurrence optimiste. Les bases de données non relationnelles doivent utiliser un 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 concurrence.
Utilisez la découverte de service dynamique. La découverte de service dynamique 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 dépendre directement d’un instance spécifique dans la charge de travail. Pour éviter ces dépendances, vous devez utiliser un proxy pour distribuer et redistribuer les connexions clientes. Le proxy agit comme un intermédiaire entre les clients et les services, fournissant une couche d’abstraction qui permet d’ajouter ou de supprimer des services 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. Le déchargement des tâches intensives en tant que tâches en arrière-plan permet à l’application main de gérer les requêtes utilisateur sans que des opérations nécessitant beaucoup de ressources ne l’accablent. Suivez ces étapes pour décharger les tâches en tant que tâches en arrière-plan :
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 lourds ou des interactions avec des ressources externes telles que des bases de données ou des opérations réseau.
Concevez votre application pour prendre en charge les tâches en arrière-plan. Dissociez les tâches intensives de la logique d’application main et fournissez un mécanisme pour démarrer et gérer les tâches en arrière-plan.
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 ou plateforme de programmation, telles que la programmation asynchrone, le threading ou les files d’attente de tâches. Contenant 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 à des intervalles spécifiques.
Distribuez les tâches en arrière-plan si elles sont nombreuses ou si elles nécessitent beaucoup de temps ou de ressources. Le modèle des Consommateurs concurrents offre une solution possible.
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 des fonctionnalités de mise à l’échelle automatique, la compréhension des limites de mise à l’échelle des services 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 maximisant l’efficacité. Lorsque vous configurez la mise à l’échelle, tenez compte des stratégies suivantes :
Utilisez des services avec 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, la mise à l’échelle des machines virtuelles nécessite un équilibreur de charge distinct, une gestion des demandes clientes et un état stocké en externe. Les offres PaaS gèrent la plupart de ces tâches.
Limitez la mise à l’échelle automatique. Définissez des limites de mise à l’échelle automatique pour réduire la mise à l’échelle excessive qui pourrait entraîner des coûts inutiles. Parfois, vous ne pouvez pas définir de limites de mise à l’échelle. Dans ce cas, vous devez définir des alertes pour vous avertir lorsque le composant atteint la limite de mise à l’échelle maximale et est surdimensionné.
Comprendre les limites de mise à l’échelle des services. Lorsque vous comprenez les limites, les incréments et les restrictions de mise à l’échelle du service, 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 le service choisi peut gérer la charge de travail attendue, effectuer une mise à l’échelle efficace 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 garantir 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 aller au-delà des limites de mise à l’échelle, vous devez partitionner votre charge de travail.
Incréments de mise à l’échelle : les services sont mis à l’échelle à des 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 limitent votre capacité à inverser automatiquement la mise à l’échelle. Vous êtes obligé de mettre à l’échelle manuellement ou vous devrez peut-être redéployer une nouvelle ressource. Ces limitations visent souvent à protéger la charge de travail. La mise à l’échelle ou la mise à l’échelle peut avoir des implications sur la disponibilité et les performances de la charge de travail. Un service peut appliquer certaines limitations ou contraintes pour garantir que la charge de travail dispose de suffisamment de ressources 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 lors d’un scale-up ou d’un scale-out, mais il peut ne pas fournir le même niveau de prise en charge pour la mise à l’échelle ou la mise à l’échelle.
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, comme le processeur ou la mémoire. Elles incluent également des métriques plus avancées, telles que la profondeur de la file d’attente, les requêtes SQL, les requêtes de métriques personnalisées et la longueur de la 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. Une charge de travail bien conçue planifie les pics inattendus de charge de travail. Vous devez ajouter une mémoire tampon pour gérer les pics de mise à l’échelle horizontale et verticale.
Empêchez les battements. Le flapping est une condition de boucle qui se produit lorsqu’un événement de mise à l’échelle déclenche un événement de mise à l’échelle opposé, créant ainsi une action de mise à l’échelle continue. Par exemple, si la mise à l’échelle dans réduit le nombre d’instances, cela peut entraîner une 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 du processeur, 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 fournissent une différence significative dans l’utilisation du processeur.
Utilisez les empreintes de déploiement. Il existe des techniques qui facilitent la mise à l’échelle d’une charge de travail. Vous pouvez utiliser le modèle Empreintes de déploiement pour mettre à l’échelle facilement une charge de travail en ajoutant une ou plusieurs unités de mise à l’é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. Il permet de garantir une mise à l’échelle efficace de la charge de travail, ce qui optimise l’efficacité des performances lors de 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 les stratégies de mise à l’échelle verticale et horizontale et de déterminer celle qui optimise le plus efficacement les performances. Voici une approche recommandée pour tester la mise à l’échelle :
Définissez des scénarios de charge de travail. Identifiez les scénarios de charge de travail clés 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 un 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 des 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, ainsi que les taux d’erreur.
Développer 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 supervisez des tests. Exécutez les tests à l’aide des cas de test définis et collectez des 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 à améliorer. Optimisez la configuration, l’infrastructure ou le code pour améliorer la scalabilité et les performances. La mise à l’échelle prend du temps. Testez donc les effets des retards de mise à l’échelle.
Dépendances d’adresse. Recherchez les 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 de dépendance. 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 davantage de débit à la base de données.
Retestez après les ajustements. Répétez les tests de scalabilité après avoir implémenté des 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 de rentabilité de votre charge de travail. La mise à l’échelle verticale peut entraîner 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 consistant à diviser un jeu de données ou 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 active 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, ce qui réduit la charge sur les appareils individuels et améliore les performances globales.
Comprendre le partitionnement
L’approche de partitionnement spécifique que vous utilisez dépend du type de données ou de charge de travail dont vous disposez et de la technologie que vous utilisez. Voici quelques stratégies courantes de 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 de colonnes ou d’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 à effectuer. Chaque partition contient les données ou les composants nécessaires pour une fonction spécifique, ce qui permet d’optimiser le traitement et les performances.
Planifier le partitionnement
Il est important de prendre en compte des facteurs tels que la distribution des 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 envisagez le partitionnement après coup, il est plus difficile, car vous avez déjà 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, les modèles d’accès, les exigences en matière d’accès concurrentiel et les objectifs de scalabilité lors du choix du type de partitionnement à utiliser. Chaque type de partitionnement a 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 sur plusieurs ressources ou serveurs pour une meilleure scalabilité et des performances. Elle est effective 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 au jeu de données ou de les mettre à jour 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 des données inutile.
Le partitionnement fonctionnel est approprié lorsque différentes fonctions nécessitent différents sous-ensembles de données et peuvent être traitées indépendamment. Le partitionnement fonctionnel peut optimiser les performances en permettant à chaque partition de concentrer des 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 la scalabilité. Comparez les résultats aux objectifs de performances et identifiez les goulots d’étranglement ou problèmes éventuels. En fonction de l’analyse, identifiez les opportunités d’optimisation potentielles. Vous devrez peut-être redistribuer les données entre les partitions, ajuster les tailles de partition ou modifier les critères de partitionnement.
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 augmentation de la contention sur des partitions spécifiques.
Performances des requêtes : des 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 nécessaire 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 de mettre à 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 des métriques avancées ou des 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ées des modifications.
Azure Monitor vous permet de surveiller diverses 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 des clusters. Grâce aux fonctionnalités de supervision et d’alerte de Monitor, vous pouvez efficacement faciliter la mise à l’échelle dans Azure et vous assurer 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 Surveiller 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 des métriques et peuvent effectuer des actions à l’aide de Azure Automation. Automation fournit une plateforme pour l’hébergement et l’exécution de 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 et la journalisation des exécutions, 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 base de données, vous pouvez activer le verrouillage optimisé pour améliorer les performances des 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 les données ?
- Bonnes 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’applications
Liste de contrôle d’efficacité des performances
Reportez-vous à l’ensemble complet de recommandations.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour