Montée en charge horizontale ou verticale : quelle est la meilleure solution pour les API ?

La montée en charge horizontale, également appelée « évolutivité horizontale », désigne le processus de déploiement de machines virtuelles (VM) supplémentaires afin d'augmenter les capacités de l'API pour gérer une charge accrue. À l'inverse, le fait de réduire la capacité est appelé « réduction de la charge horizontale ». Lorsque les capacités ont besoin d'être augmentées, les administrateurs système peuvent ajouter davantage de machines virtuelles au cluster. Toutefois, un logiciel spécialisé de gestion des ressources est nécessaire pour gérer la charge des appels d'API et les acheminer vers l'instance de machine virtuelle appropriée dans le cluster et maintenir l'équilibre.

La montée en charge verticale est le processus d'ajout de ressources à un seul nœud. Elle s'oppose à la montée en charge horizontale, qui ajoute des nœuds. La montée en charge verticale, ou mise à l'échelle supérieure ou inférieure, consiste à ajouter des ressources telles que la capacité de l'unité centrale de traitement (CPU), la mémoire ou le stockage sur un serveur. Dans le cas des API, la montée en charge verticale implique généralement l'ajout de capacité de calcul à la machine virtuelle qui héberge l'API.

Par exemple, si une API est hébergée sur une machine virtuelle à laquelle un cœur de CPU et 512 mégaoctets de mémoire vive (RAM) ont été alloués, la montée en charge de cette API peut multiplier par deux le nombre de cœurs et la mémoire vive. L'API dispose alors de deux cœurs de CPU dédiés et de 1 024 mégaoctets de mémoire vive. Cette nouvelle configuration devrait permettre à l'API de gérer une charge environ deux fois plus élevée. Toutefois, les contraintes de la bande passante réseau, la vitesse de stockage et d'autres facteurs peuvent réduire l'impact de la montée en charge verticale. La montée en charge verticale présente également un défi en matière de gestion des ressources, mais les logiciels spécialisés peuvent généralement gérer ce problème.

Les API sont généralement conçues sans état, ce qui signifie qu'elles ne stockent pas les données de demande ou ne conservent pas les informations entre les sessions. Cela doit être absolument pris en compte lorsque vous devez choisir entre les méthodes de montée en charge. Les API sans état ne nécessitent pas de réplication des données entre les instances, ce qui rend la montée en charge horizontale plus efficace et plus facile à mettre en œuvre. Les administrateurs système peuvent ajouter ou supprimer des machines virtuelles selon les besoins sans affecter les opérations d'API, car le client API ne dépend pas d'instances de serveur spécifiques pour fonctionner.

Les applications avec état ne sont pas pour autant un problème. En effet, elles peuvent être essentielles pour le bon fonctionnement de l'application. Cependant, la montée en charge horizontale est plus difficile à mettre en place pour une application avec état. Elle nécessiterait la copie des données stockées de la version d'origine de l'application vers de nouvelles instances.

Une application ou une API sans état, en revanche, ne stocke pas les données de demande. Elle ne conserve pas les données de session en mémoire. Chaque fois qu'une session démarre, c'est comme si l'application rencontrait le client pour la première fois. Une fois la session terminée, aucun souvenir de celle-ci n'est conservé.

La montée en charge horizontale est possible pour une application sans état, car n'importe quelle machine virtuelle peut répondre aux appels d'API. Le client API peut appeler un nombre infini de machines virtuelles hébergeant l'API, et cela n'aura jamais d'importance. Les administrateurs système peuvent ajouter ou supprimer autant de machines virtuelles qu'ils le souhaitent sans affecter le fonctionnement de l'API.

Les API étant sans état, la montée en charge horizontale est la meilleure approche. L'ajout de machines virtuelles supplémentaires pour augmenter la capacité est efficace avec les API sans état. Les administrateurs peuvent créer des clusters de machines virtuelles qui évoluent à mesure que la demande d'API augmente.

De plus, bien qu'il soit possible de faire monter les API en charge verticalement, la montée en charge horizontale est préférable, car celle verticale pose des problèmes d'allocation des ressources. À l'inverse, la montée en charge horizontale automatique est facile à mettre en place avec les API. À mesure que les outils de gestion des systèmes détectent un pic de trafic d'API, ils peuvent automatiquement ajouter des machines virtuelles pour héberger davantage d'instances de l'API dans un cluster. A contrario, la montée en charge automatique ne fonctionne pas bien dans le cadre d'une montée en charge verticale, ce qui rend le processus est un peu plus complexe.

La demande d'API va inévitablement changer au fil du temps. Il faudra alors augmenter ou réduire les capacités des API. Les montées en charge horizontale et verticale sont toutes deux envisageables pour les API. Cependant, les API étant sans état et la montée en charge horizontale automatique étant plus facile, la montée en charge horizontale semble être la meilleure approche.

Dans un système distribué, où les API font partie d'une architecture de microservices, la montée en charge horizontale est particulièrement avantageuse. Chaque microservice peut être monté en charge indépendamment en fonction de sa charge et de ses exigences spécifiques. Cette approche modulaire permet une utilisation plus efficace des ressources et une meilleure tolérance aux pannes, car les défaillances d'un microservice n'affectent pas les autres.

De plus, dans une architecture de microservices, la montée en charge horizontale s'aligne sur les principes des systèmes distribués, où différents services sont déployés sur plusieurs nœuds. Cela garantit que le système peut gérer des charges variables et maintenir des performances optimales même pendant les périodes de pointe.

Les interruptions de service sont une préoccupation majeure lors de la montée en charge des API, car toute interruption de service peut entraîner une perte de revenus et le mécontentement des clients. La montée en charge horizontale réduit les temps d'arrêt en permettant aux administrateurs système d'ajouter ou de supprimer des serveurs sans affecter la disponibilité de l'API. En revanche, la montée en charge verticale peut nécessiter le redémarrage du serveur ou sa mise hors ligne temporaire, ce qui peut perturber les services.

Les fournisseurs d'API peuvent tirer parti de la montée en charge horizontale pour assurer la continuité des opérations, notamment pendant les maintenances planifiées ou les pics de trafic imprévus. En répartissant la charge entre plusieurs serveurs, la montée en charge horizontale garantit que l'API reste réactive et disponible, même lorsque des serveurs individuels doivent être mis hors ligne pour des mises à niveau ou des réparations.