Cet article rassemble quelques modèles communs pour aider les ingénieurs à travailler avec des services à grande échelle qui sont demandés par des millions d'utilisateurs.
D'après l'expérience de l'auteur, ce n'est pas une liste exhaustive, mais des conseilsvraiment efficaces . Alors, commençons.
Traduit avec le soutien de Mail.ru Cloud Solutions .
Premier niveau
Les mesures énumérées ci-dessous sont relativement faciles à mettre en œuvre, mais produisent des rendements élevés. Si vous ne les avez pas essayés auparavant, vous serez surpris par les améliorations significatives.
Infrastructure en tant que code
Le premier conseil est d'implémenter l'infrastructure sous forme de code. Cela signifie que vous devez disposer d'un moyen programmatique pour déployer l'ensemble de votre infrastructure. Cela semble délicat, mais nous parlons en fait du code suivant:
Déployer 100 machines virtuelles
- avec Ubuntu
- 2 Go de RAM chacun
- ils auront le code suivant
- avec de tels paramètres
Vous pouvez suivre et revenir rapidement aux modifications de l'infrastructure à l'aide du contrôle de code source.
Le moderniste en moi dit que vous pouvez utiliser Kubernetes / Docker pour faire tout ce qui précède, et il a raison.
Vous pouvez également fournir une automatisation avec Chef, Puppet ou Terraform.
Intégration et livraison continues
Pour créer un service évolutif, il est important de disposer d'un pipeline de génération et de test pour chaque pull request. Même si le test est le plus simple, il garantira au moins que le code que vous déployez se compile.
A chaque fois à ce stade, vous répondez à la question: mon assemblage va-t-il compiler et passer des tests, est-il valide? Cela peut sembler une barre basse, mais cela résout beaucoup de problèmes.
Il n'y a rien de plus beau que de voir ces cases à cocher.
Pour cette technologie, vous pouvez consulter Github, CircleCI ou Jenkins.
Équilibreurs de charge
Nous souhaitons donc démarrer un équilibreur de charge pour rediriger le trafic et nous assurer que la charge sur tous les nœuds est égale ou que le service fonctionne en cas de panne:
Un équilibreur de charge est généralement efficace pour aider à répartir le trafic. La meilleure pratique consiste à déséquilibrer afin de ne pas avoir un seul point de défaillance.
En règle générale, les équilibreurs de charge sont configurés dans le cloud que vous utilisez.
RayID, ID de corrélation ou UUID pour les demandes
Avez-vous déjà rencontré une erreur dans une application avec un message comme celui-ci: «Une erreur s'est produite. Enregistrez cet identifiant et envoyez-le à notre équipe d'assistance » ?
L'identifiant unique, l'ID de corrélation, le RayID ou l'une des variantes est un identifiant unique qui vous permet de suivre une demande tout au long de son cycle de vie. Cela vous permet de suivre le chemin complet de la demande dans les journaux.
L'utilisateur fait une demande au système A, puis A contacte B, qui contacte C, enregistre dans X, puis la demande retourne à A
Si vous deviez vous connecter à distance à des machines virtuelles et essayer de tracer le chemin de la demande (et corréler manuellement les appels en cours), tu deviendrais fou. Avoir un identifiant unique rend la vie beaucoup plus facile. C'est l'une des choses les plus faciles à faire pour gagner du temps à mesure que votre service se développe.
Niveau moyen
Les conseils ici sont plus complexes que les précédents, mais les bons outils facilitent la tâche, offrant un retour sur investissement même pour les petites et moyennes entreprises.
Journalisation centralisée
Toutes nos félicitations! Vous avez déployé 100 machines virtuelles. Le lendemain, le PDG entre et se plaint d'une erreur qu'il a reçue lors du test du service. Il rapporte l'ID correspondant dont nous avons parlé ci-dessus, mais vous devrez parcourir les journaux de 100 machines pour trouver celui qui a causé le crash. Et elle a besoin d'être trouvée avant la présentation de demain.
Bien que cela ressemble à une aventure amusante, il est préférable de vous assurer que vous avez la possibilité de rechercher tous les magazines à partir d'un seul endroit. J'ai résolu le problème de la centralisation des journaux avec la fonctionnalité intégrée de la pile ELK: la collecte de journaux consultable est prise en charge ici. Cela aidera vraiment à résoudre le problème de trouver un journal spécifique. En prime, vous pouvez créer des diagrammes et d'autres choses amusantes comme ça.
Fonctionnalité de pile ELK
Agents de surveillance
Maintenant que votre service est opérationnel, vous devez vous assurer qu'il fonctionne correctement. La meilleure façon de procéder est d'exécuter plusieurs agents qui s'exécutent en parallèle et de vérifier qu'ils sont en cours d'exécution et que les opérations de base sont effectuées.
À ce stade, vous vérifiez que l' assemblage en cours d'exécution fonctionne correctement et fonctionne correctement .
Pour les petits et moyens projets, je recommande Postman pour la surveillance et la documentation des API. Mais en général, vous devez simplement vous assurer que vous avez un moyen de savoir quand une panne s'est produite et de recevoir des alertes en temps opportun.
Autoscaling basé sur la charge
C'est très simple. Si vous disposez d'une machine virtuelle traitant des demandes et qu'elle utilise près de 80% de la mémoire, vous pouvez augmenter ses ressources ou ajouter d'autres machines virtuelles au cluster. L'exécution automatique de ces opérations est excellente pour les changements de puissance élastique sous charge. Mais vous devez toujours faire attention au montant que vous dépensez et fixez des limites raisonnables.
Dans la plupart des services cloud, vous pouvez configurer la mise à l'échelle automatique avec plus de serveurs ou des serveurs plus puissants.
Système d'expérimentation
Un bon moyen de déployer des mises à jour en toute sécurité est de pouvoir tester quelque chose pour 1% des utilisateurs en une heure. Vous avez certainement vu de tels mécanismes en action. Par exemple, Facebook montre à certaines parties du public une couleur différente ou modifie la taille de la police pour voir comment les utilisateurs perçoivent le changement. C'est ce qu'on appelle les tests A / B.
Même la publication d'une nouvelle fonctionnalité peut être exécutée en tant qu'expérience, puis comprendre comment la publier. Vous avez également la possibilité de "mémoriser" ou de modifier la configuration à la volée, en tenant compte de la fonction qui provoque la dégradation de votre service.
Niveau avancé
Voici quelques conseils assez difficiles à mettre en œuvre. Vous aurez probablement besoin d'un peu plus de ressources, il sera donc difficile pour une petite ou moyenne entreprise de gérer cela.
Déploiements bleu-vert
C'est ce que j'appelle la méthode de déploiement «Erlang». Erlang était largement utilisé lorsque les compagnies de téléphone sont arrivées. Des commutateurs logiciels ont été utilisés pour acheminer les appels téléphoniques. L'objectif principal du logiciel sur ces commutateurs était de ne pas interrompre les appels lors d'une mise à niveau du système. Erlang a un excellent moyen de charger un nouveau module sans planter le précédent.
Cette étape dépend de la présence d'un équilibreur de charge. Disons que vous avez la version N de votre logiciel et que vous souhaitez ensuite déployer la version N + 1.
Vous pouvez simplement arrêter le service et déployer la prochaine version à un moment qui convient à vos utilisateurs et obtenir des temps d'arrêt. Mais supposons que vous ayeztermes SLA vraiment stricts. Ainsi, SLA 99,99% signifie que vous ne pouvez vous déconnecter que 52 minutes par an.
Si vous voulez vraiment y parvenir, vous avez besoin de deux déploiements en même temps:
- celui qui est en ce moment (N);
- version suivante (N + 1).
Vous dites à l'équilibreur de charge de rediriger un pourcentage de votre trafic vers la nouvelle version (N + 1) pendant que vous suivez activement les régressions vous-même.
Ici, nous avons un déploiement N vert qui fonctionne très bien. Nous essayons de passer à la prochaine version de ce déploiement
Tout d'abord, nous envoyons un très petit test pour voir si notre déploiement N + 1 fonctionne avec peu de trafic:
Enfin, nous avons un ensemble de contrôles automatisés que nous finissons par exécuter jusqu'à ce que notre déploiement soit terminé. Si vous êtes vraiment, vraiment prudent, vous pouvez également conserver votre déploiement N pour toujours pour une restauration rapide en cas de mauvaise régression:
Si vous souhaitez passer à un niveau encore plus avancé, laissez tout se faire automatiquement dans le déploiement bleu-vert.
Détection d'anomalies et atténuation automatique
Étant donné que vous disposez d'une journalisation centralisée et d'une bonne collecte de journaux, vous pouvez déjà définir des objectifs plus élevés. Par exemple, prédire les pannes de manière proactive. Sur les moniteurs et dans les journaux, les fonctions sont suivies et divers diagrammes sont construits - et vous pouvez prédire à l'avance ce qui ne va pas:
Avec la découverte d'anomalies, vous commencez à étudier certains des indices que le service pose problème. Par exemple, un pic d'utilisation du processeur peut suggérer qu'un disque dur est en panne, tandis qu'un pic dans les demandes signifie que vous devez évoluer. Ce type de statistiques nous permet de rendre le service proactif.
Grâce à ces informations, vous pouvez évoluer dans n'importe quelle dimension, modifier de manière proactive et réactive les caractéristiques des machines, bases de données, connexions et autres ressources.
C'est tout!
Cette liste de priorités vous évitera beaucoup de problèmes si vous mettez en place un service cloud.
L'auteur de l'article original invite les lecteurs à laisser leurs commentaires et à apporter des modifications. L'article est distribué en open source, l'auteur accepte les pull requests sur Github .
Que lire d'autre sur le sujet: