Analyse approfondie de la solution: création d’une application Web hautement disponible dotée de capacités de traitement et de stockage Web à l’aide de MongoDB et d’Elk Stack

Une configuration d’application Web à haute disponibilité offre des avantages aux développeurs qui cherchent à éliminer les points de défaillance uniques et à minimiser les temps d’arrêt. Dans ce cadre général, cependant, un certain nombre de variations sont possibles. Les développeurs choisiront en fonction des besoins spécifiques de leur application et de leurs objectifs de performance.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/full-diagram.png [Schéma complet de l’application Web hautement disponible]

Cette configuration d’application à haute disponibilité a été conçue comme une solution hypothétique offrant potentiellement:

Dans cet article, nous passerons en revue les caractéristiques spécifiques de cette configuration et discuterons de ses composants à un niveau plus général. À la fin de chaque section, nous vous proposerons des ressources supplémentaires sur le sujet pour vous aider à évaluer les méthodologies et les meilleures pratiques.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-1.png [Schéma de l’étape 1: serveurs frontaux]

Une configuration à plusieurs niveaux typique sépare la couche de présentation de notre logique d’application. La séparation des fonctions de l’application en couches facilite les processus de dépannage et de mise à l’échelle à long terme.

Lorsque nous sélectionnons des serveurs et des ressources, nous pouvons prendre en compte les facteurs suivants:

Nos outils de surveillance nous aideront à adapter notre application et à constituer des ressources à ce niveau et à d’autres. Une mesure supplémentaire que nous pouvons prendre pour des mesures de réduction des coûts et de sécurité consiste à affecter les ressources de notre application, y compris nos serveurs frontaux, à un réseau privé partagé. Les données peuvent ensuite être transférées entre les serveurs sans entraîner de coûts supplémentaires en bande passante ni en laissant un seul centre de données.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-2.png [Schéma de l’étape 2: équilibreurs de charge]

Pour nous assurer que les ressources de nos applications restent hautement disponibles et performantes, nous pouvons créer des équilibreurs de charge pour gérer notre charge de travail initiale. Ces équilibreurs de charge redirigeront le trafic entrant en utilisant des contrôles d’intégrité réguliers et des mécanismes de basculement pour gérer les défaillances ou les dysfonctionnements du serveur. Ils équilibreront également le trafic de manière plus générale, en veillant à ce que les serveurs individuels ne soient pas surchargés.

Pour optimiser leur configuration, nous pouvons considérer les facteurs suivants:

Ces facteurs nous permettront de sélectionner l’algorithme optimal pour notre configuration. Le travail des équilibreurs de charge comporte également un élément de sécurité supplémentaire: nous pouvons les configurer pour écouter sur des ports spécifiques et pour rediriger le trafic entre les ports. Il est également possible de les utiliser pour décrypter les messages de nos serveurs principaux.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-3.png [Schéma de l’étape 3: Serveurs d’arrière-plan]

Créer le backend de notre application implique un autre ensemble de calculs de ressources. Là encore, la nature du travail de notre application déterminera la taille et les ressources de nos serveurs. Les facteurs à prendre en compte incluent le type et le volume de traitement que nos serveurs effectueront à ce niveau. C’est là que les distinctions entre types de données et tâches de traitement entreront en jeu. Si, par exemple, nous travaillons avec des ressources d’image et des données de consommation, nous pouvons prendre en compte les exigences de charge et de latence applicables à chacune d’elles.

La surveillance sera également importante à ce niveau pour résoudre des problèmes tels que:

Nous pouvons placer les ressources à ce niveau dans notre réseau privé partagé pour prendre en compte les éventuels frais de bande passante.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-4.png [Schéma de l’étape 4: HAProxy]

De la même manière que nos équilibreurs de charge traitent les requêtes externes, HAProxy gère le flux de communication entre nos couches frontale et applicative. Dans sa fonction d’équilibreur de charge, HAProxy peut être configuré pour écouter et rediriger le trafic provenant de ports particuliers. Cela peut ajouter une couche de sécurité supplémentaire aux opérations internes de notre application. Lorsque nous devons évoluer, nous pouvons configurer HAProxy pour ajouter et supprimer des nœuds automatiquement.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-5.png [Schéma de l’étape 5: bases de données SQL]

Pour un certain segment de nos données d’application, nous utiliserons une base de données SQL. Ceci concerne les données qui doivent être actuelles, précises et cohérentes. Des éléments tels que les transactions de vente, les informations de connexion / déconnexion et les modifications de mot de passe, qui ont une structure uniforme et doivent être sécurisées, constituent un argument raisonnable pour l’utilisation d’une base de données SQL.

Encore une fois, nous voudrons examiner nos métriques: combien de demandes transactionnelles ou sécurisées traitons-nous? Si notre charge de travail est élevée, nous pourrions envisager d’utiliser des outils tels que ProxySQL pour équilibrer les demandes entrantes. Nous pouvons prendre une mesure supplémentaire pour améliorer les performances et assurer une haute disponibilité si nous configurons la réplication entre nos bases de données SQL. Cela s’avérera également utile si nous devons redimensionner notre traitement de données.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-6.png [Schéma de l’étape 6: Bases de données NoSQL]

Avec des données moins uniformes ou moins schématiques, nous pouvons utiliser une base de données NoSQL. Pour les images, les vidéos ou les articles de blog, par exemple, une base de données NoSQL offre la possibilité de stocker des métadonnées d’élément de manière non schématique. Lors de l’utilisation de ce type de solution, nos données seront hautement disponibles et leur cohérence sera éventuelle. Lorsque nous pensons aux performances, nous souhaitons prendre en compte le type et le volume de demandes que nous prévoyons pour ces bases de données.

Les facteurs susceptibles d’optimiser les performances, en fonction de la charge et du type de demande, incluent: l’utilisation d’une solution d’équilibrage de la charge pour gérer le trafic entre bases de données, la distribution de données entre bases de données et solutions de stockage et l’ajout ou la destruction de bases de données (plutôt que leur réplication).

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-7.png [Schéma de l’étape 7: Stockage en bloc]

Notre configuration sépare la fonctionnalité de stockage de base de données des autres opérations de notre application. L’objectif est d’améliorer la sécurité de nos données et la performance globale de notre application. Dans le cadre de ce processus d’isolation, nous pouvons créer une solution de sauvegarde pour nos fichiers de base de données SQL. Les solutions de stockage en blocs telles que les volumes de stockage en bloc de DigitalOcean peuvent effectuer ce travail correctement, grâce à leurs E / S à faible temps de latence et à leur structure de système de fichiers schématique. Ils offrent également des options de redimensionnement, car ils peuvent être facilement détruits, redimensionnés ou multipliés.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-8.png [Schéma de l’étape 8: pile ELK]

Le suivi des performances de notre application permettra d’informer les décisions que nous prendrons lorsque nous adapterons et perfectionnerons notre configuration. Pour ce faire, nous pouvons utiliser une solution de journalisation centralisée telle qu’une pile Elastic / ELK. Notre pile comprend des composants qui collectent et visualisent les journaux: Logstash, qui traite les journaux; Elasticsearch, qui les stocke; et Kibana, ce qui permet de les rechercher et de les organiser visuellement. Si nous situons cette pile derrière une adresse IP flottante, nous pourrons y accéder à distance avec une adresse IP statique. De plus, si nous incluons notre pile dans notre réseau privé partagé, nous aurons un autre avantage en matière de sécurité: nos agents de génération de rapports n’auront pas besoin de transférer des informations vers la pile via Internet.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-9.png [Schéma de l’étape 9: Stockage des objets]

Lors du stockage des actifs statiques de nos applications, nous souhaitons garantir leur disponibilité tout en maintenant des performances élevées. Les solutions de stockage d’objets telles que DigitalOcean Spaces peuvent répondre à ce besoin. En particulier, si nous décidons de stocker des objets volumineux dans nos bases de données, ils risquent de rencontrer des problèmes de performances lors de l’afflux de données, rendant nos sauvegardes très volumineuses. Dans ce scénario, nous pourrions déplacer nos données vers le stockage d’objets. En stockant une URL dans notre base de données, nous pouvons pointer sur nos ressources à partir de la base de données sans affecter sa capacité de stockage. Il s’agit d’une solution optimale pour les données dont nous prévoyons qu’elles resteront statiques et qui offre des options supplémentaires pour la mise à l’échelle.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-10.png [Schéma de l’étape 10: enregistrements DNS]

Une fois notre configuration de haute disponibilité mise en place, nous pouvons indiquer le nom de domaine de notre application à nos équilibreurs de charge utilisant DNS. Avec un algorithme alternatif, nous pouvons équilibrer les réponses aux requêtes entre les ressources distribuées de notre application. Cela maximisera la disponibilité de ces ressources, tout en répartissant les charges de travail sur des clusters de ressources. De plus, nous pouvons utiliser le routage géographique pour faire correspondre les demandes aux ressources proches.

Notre stratégie de récupération comprendra des outils et des fonctions permettant de sauvegarder et de restaurer nos données en cas de défaillance administrative ou autre. Pour chacune de nos gouttelettes, nous pouvons exploiter et automatiser des instantanés DigitalOcean pour copier et stocker des images de gouttelettes sur des serveurs DigitalOcean. De plus, nous pouvons utiliser des outils et des services dédiés tels que Percona, Restic ou Bacula, ainsi que des périphériques de stockage tels que DigitalOcean Backups and Spaces pour copier nos données. Au fur et à mesure de l’évaluation de ces outils et de la création de notre stratégie, nous réfléchirons aux données de chaque couche de notre application et à la fréquence à laquelle elles devront être sauvegardées pour disposer d’un point raisonnable à partir duquel nous pourrons restaurer les fonctionnalités de notre application.

Dans cet article, nous avons présenté une configuration potentielle pour une application Web hautement disponible qui repose sur des composants d’infrastructure tels que des gouttelettes, des équilibreurs de charge, des espaces et du stockage de blocs afin d’offrir un niveau élevé de performances opérationnelles. Cette configuration pourrait prendre en charge une solution de traitement des images et d’autres supports, axée sur le stockage et la récupération, ainsi que sur les fonctionnalités d’achat, de tenue de score ou de blogage pouvant être intégrées aux solutions de commerce électronique.

En fin de compte, les développeurs peuvent choisir entre de nombreuses solutions pour répondre à des besoins et à des cas d’utilisation particuliers tout en maintenant une haute disponibilité, et chaque configuration d’application reflète ces différences dans la spécificité de son architecture.