Nous entendons beaucoup parler de scalabilité, de résilience et de tolérance aux pannes des plateformes cloud, mais cela n’a pas de sens si les applications sous-jacentes ne sont pas conçues en ayant les pannes à l'esprit.
Cet article dresse la liste des erreurs les plus fréquemment commises lors de la conception d'une application évolutive et tolérante aux pannes, et propose quelques conseils simples pour éviter ces écueils.
S'appuyer sur les ressources locales
Sauvegarder localement l'état d'une application, les données de session ainsi que d'autres éléments est assez facile mais ne fonctionne pas à grande échelle. Même lorsque d'autres serveurs peuvent accéder à ces ressources, si l'instance principale s'éteint, vous perdrez tout, y compris vos fichiers et bases de données.
Conseil : des solutions de stockage à objets répartis comme Amazon S3 ou des systèmes de gestion de bases de données comme Amazon RDS ou SimpleDB peuvent vous aider à consolider vos infrastructures de stockage sans vous préoccuper de leur gestion.
S'appuyer sur une structure partagée
Les services ne doivent pas dépendre d'autres services si ceux-ci ne sont pas vitaux. Si nous perdons la connexion à la base de données centrale et que nous pouvons servir des pages à partir du cache, la vérification de connexion de notre code ne doit pas en empêcher l'affichage, mais simplement prévenir l'équipe de DevOps.
Conseil : construisez chaque élément de votre architecture/application en contrôlant la santé de vos services et en utilisant des délais d'attente suffisants.
Utilisez toujours les RDBMS (bases de données relationnelles)
Parce que chaque type de données est différent, nos systèmes de bases de données et notre approche des structures de ces données doivent également être différents. Nous ne devrions pas adopter le système de gestion de bases de données relationnelles sans prendre en compte les types de données. Une base de données NoSQL donnerait peut-être de meilleurs résultats si nous avons besoin de stocker des paires clé/valeur. Et, en prime, si nous avons besoin d'y accéder plus rapidement, nous pourrons envisager une base de données en mémoire, dont les données seraient ensuite consolidées à l'aide de processus indépendants, ou un système de bases de données plus sophistiqué, comme Redis.
Conseil : il existe de nombreux systèmes de bases de données fiables. Ce qu'il faut, c'est trouver celui qui vous convient le mieux. Amazon possède son propre NoSQL, DynamoDB, et propose également sa propre version de Redis à réplication ininterrompue, qui utilise Amazon ElastiCache.
Les réseaux de diffusion de contenu (CDN) sont inutiles
« Nous avons suffisamment de serveurs et de bande passante. Pourquoi utiliser un CDN ? » Réponse courte : un CDN est une flotte de serveurs répartis dans le monde entier et contenant des copies de votre contenu. Les utilisateurs qui visitent votre site y accèdent à partir du serveur le plus proche de leur emplacement géographique. Plus les serveurs seront proches des utilisateurs, plus vite le contenu sera téléchargé et les utilisateurs percevront une vitesse plus élevée.
Conseil : les CDN sont utiles pour alléger la charge de travail des serveurs et pour accélérer l'expérience utilisateur. Sur AWS, le service correspondant est CloudFront.
Cache : l'option du tout ou rien
Quand on évoque le cache, il n'y a pas de demi-mesure. Il est inutile pour les uns, essentiel pour les autres. En fait, le cache peut aussi bien masquer les problèmes de performance d'une application pendant le développement, qu'accélérer le système tout entier une fois la production lancée. Le cache peut aussi donner de mauvais résultats s'il n'est pas correctement configuré. Par exemple, mettre en cache les appels de votre API au niveau du serveur web avec une mauvaise URL/requête peut entraîner des réponses incorrectes.
Conseil : avec le cache, ce n'est pas tout ou rien : il est nécessaire de bien comprendre le logiciel utilisé et le comportement de la couche d'application lors de son utilisation. Jetez donc un coup d'œil aux options proposées par le service Amazon ElastiCache : Redis et Memcached.
La réplication des données est inutile
« Pourquoi répliquer des données sur des instances multiples ? Mon serveur de base de données est suffisant pour traiter 100 000 requêtes par seconde et il peut contenir 1 To de données... » Mais qu'en sera-t-il lorsque vous atteindrez 200 000 requêtes par seconde ou 2 To de données ? Est-il plus facile d'arrêter le service pour augmenter les capacités du serveur ou de le développer avec un cluster de bases de données, en ajoutant d'autres serveurs sans pour autant arrêter le serveur actuel ?
Conseil : les systèmes de bases de données modernes peuvent exécuter des réplicas en lecture afin de déléguer des lectures et d'assurer un RTO (objectif de temps de récupération) court. Le sharding est un autre terme auquel vous devrez vous familiariser. Sur AWS, Amazon RDS est le service qui nous fournira les outils les plus simples pour créer des réplicas en lecture. Le sharding, quant à lui, doit être résolu au niveau de l'application.
Nous pouvons simplement passer à l'échelle supérieure
Vraiment ? Passer à l'échelle supérieure implique en général d'arrêter le serveur pour mettre à niveau le hardware. Pouvez-vous vraiment vous permettre ce temps d'immobilisation à l'ère du cloud ? Les architectures multi-sites ou même multiserveurs comme celles proposées dans notre post « Disaster Recovery in AWS: High Availability Architectures » (Reprise après sinistre sur AWS : architectures haute disponibilité) peuvent vous aider à éviter des interruptions de votre service pendant le redimensionnement.
Conseil : des services AWS comme Auto Scaling, Elastic Beanstalk ou juste un simple équilibreur de charge comme Elastic Load Balancer constituent des outils appropriés pour ce travail.
Un point unique de défaillance (SPOF) est un risque que nous pouvons prendre
Comment une interruption du service peut-elle affecter vos activités ? Après avoir planifié une plateforme entièrement auto-modulable, complétée par une application d'auto-réparation codée par des gourous de la Silicon Valley, est-il vraiment nécessaire de dépendre d'une instance de base de données unique pour économiser quelques sous ?
Conseil : on l'appelle « point unique de défaillance » parce qu'il A DES DÉFAILLANCES. Comme disait Werner, « Toute chose a des défaillances, tout le temps. » Gardez cela à l'esprit.
« Stateless » et « decoupling » ne sont que des mots bizarres, tout comme « ReST »
Ce sont en fait des concepts fondamentaux dans la construction et la distribution de systèmes modulables.
Petite révision...
L'architecture ReST est basée sur le concept de stateless (sans état en français). C'est-à-dire qu’un objet ne garde aucune information liée à l'utilisateur ou au contexte de l'application entre des appels multiples vers le même objet. Chaque appel est indépendant du précédent et ne fera pas partie d'une « conversation continue ». Ainsi, chaque objet est découplé de l'infrastructure ou de l'application et n'affecte pas la structure dans son ensemble. Si un objet (serveur ou appel) plante avant la fin de sa tâche, un autre objet redémarre la même action.
D'autres concepts utiles qui font partie de l'architecture ReST :
Séparation client-serveur : par une interface uniforme (appelons-la API , dans un souci de clarté).
Mise en cache : les réponses doivent être définies comme « cachables » ou « non cachables », pour éviter une mise en cache non désirée du côté du client (sur le navigateur de l'utilisateur) et le téléchargement inutile d'objets ou la réémission de requêtes.
Couches : normalement, un client ne sait pas s'il est connecté directement au serveur final ou s'il passe par un serveur intermédiaire. Le(s) serveur(s) intermédiaire(s) peut (peuvent) contribuer à la scalabilité de l'application, en fournissant un équilibre de la charge ou des caches partagés.
Pour plus d'informations, rendez-vous sur Wikipédia : https://fr.wikipedia.org/wiki/Representational_State_Transfer
Conseil : penser aux défaillances lors de la construction en utilisant une architecture ReST ou une autre architecture « stateless » aide à améliorer la fiabilité de l'application. Amazon propose pratiquement tous les outils nécessaires, depuis les files d'attente de messagerie aux structures auto-modulables et de déploiement continu du style DevOps.
CONSEIL FINAL :
Voici quelques conseils pour éviter les erreurs les plus fréquentes lorsque l'on « construit pour le cloud », qu’il s’agisse d’une plateforme entière ou « juste d’un logiciel ». Planifier la résilience et les performances requiert une bonne compréhension de toutes les « pièces » du puzzle. En cas de doute, il est plus simple (et parfois moins cher) de suivre les conseils d’un expert pendant la phase de planification plutôt que de rencontrer des goulets d'étranglement ou des inefficacités plus tard, après le déploiement de la structure entière.
Source : http://blog.celingest.com/en/2014/10/14/architecture-101-scalability-donts/