Étude de cas : Pourquoi j'utilise AWS Cloud Infrastructure pour mes produits

En tant que plate-forme d'exécution d'un produit logiciel complexe et exigeant, AWS offre une flexibilité en utilisant les ressources en cas de besoin, à l'échelle requise. C'est à la demande et instantané, permettant un contrôle total sur l'environnement d'exécution. Lors de la proposition d'une telle solution d'architecture cloud à un client, l'infrastructure provisionnée et son prix dépendent fortement des exigences qui doivent être définies en amont.

Cet article présentera une telle architecture d'infrastructure cloud AWS, proposée et mise en œuvre pour LEVELS, un réseau social avec une fonction de paiement facial intégrée qui trouve et applique tous les avantages que les utilisateurs pourraient obtenir pour les programmes de cartes dans lesquels ils se trouvent, les choses qu'ils possèdent ou les lieux. ils vivent dans.

Conditions

Le client avait deux exigences principales auxquelles la solution proposée devait répondre :

1. Sécurité
2. Évolutivité

L' exigence de sécurité consistait à protéger les données des utilisateurs d'un accès non autorisé de l'extérieur, mais aussi de l'intérieur. L' exigence d'évolutivité concernait la capacité de l'infrastructure à prendre en charge la croissance des produits, en s'adaptant automatiquement à l'augmentation du trafic et aux pics occasionnels, ainsi qu'au basculement et à la récupération automatiques en cas de panne des serveurs, minimisant ainsi les temps d'arrêt potentiels.

Présentation des concepts de sécurité AWS

L'un des principaux avantages de la configuration de votre propre infrastructure AWS Cloud est l'isolation complète du réseau et le contrôle total de votre cloud. C'est la principale raison pour laquelle vous choisiriez la route Infrastructure en tant que service (IaaS), plutôt que d'exécuter des environnements de plate-forme en tant que service (PaaS) un peu plus simples, qui offrent des valeurs par défaut de sécurité solides mais manquent du contrôle complet et précis que vous obtenez par configurer votre propre cloud avec AWS.

Bien que LEVELS était un jeune produit lorsqu'ils ont approché Toptal pour les services de conseil AWS, ils étaient prêts à s'engager envers AWS et savaient qu'ils voulaient une sécurité de pointe avec leur infrastructure, car ils sont très préoccupés par les données des utilisateurs et la confidentialité. En plus de cela, ils prévoient de prendre en charge le traitement des cartes de crédit à l'avenir, ils savaient donc qu'ils devraient assurer la conformité PCI-DSS à un moment donné.

Cloud privé virtuel (VPC)

La sécurité sur AWS commence par la création de votre propre Amazon Virtual Private Cloud (VPC) - un réseau virtuel dédié qui héberge vos ressources AWS et est logiquement isolé des autres réseaux virtuels dans le Cloud AWS. Le VPC obtient sa propre plage d'adresses IP, des sous-réseaux entièrement configurables, des tables de routage, des listes de contrôle d'accès au réseau et des groupes de sécurité (en fait, un pare-feu).

Avec LEVELS, nous avons commencé par isoler notre environnement de production des environnements de développement, de test et d'assurance qualité. La première idée était d'exécuter chacun d'eux comme leur propre VPC entièrement isolé, chacun exécutant tous les services requis par l'application. Après réflexion, il s'est avéré que nous pouvions autoriser un certain partage des ressources entre les trois environnements de non-production, ce qui réduisait les coûts dans une certaine mesure.

Ainsi, nous avons choisi l'environnement de production comme un seul VPC, avec les environnements de développement, de test et d'assurance qualité comme un autre VPC.

Isolement des accès au niveau du VPC

La configuration à deux VPC isole l'environnement de production des trois environnements restants au niveau du réseau, garantissant qu'une mauvaise configuration accidentelle de l'application ne peut pas franchir cette limite. Même si la configuration de l'environnement de non-production pointe par erreur vers des ressources de l'environnement de production, comme une base de données ou des files d'attente de messages, il n'y a aucun moyen d'y accéder.

Avec des environnements de développement, de test et d'assurance qualité partageant le même VPC, un accès transfrontalier est possible en cas de mauvaise configuration, mais, comme ces environnements utilisent des données de test, aucun problème de sécurité réel n'existe avec le manque d'isolement.

Modèle de sécurité du magasin d'actifs

Les actifs sont stockés dans le stockage d'objets Amazon Simple Storage Service (S3) . L'infrastructure de stockage S3 est totalement indépendante des VPC et son modèle de sécurité est différent. Le stockage est organisé en compartiments S3 distincts pour chaque environnement et/ou classe d'actifs, protégeant chaque compartiment avec les droits d'accès appropriés.

Avec LEVELS, plusieurs classes d'actifs ont été identifiées : les téléchargements d'utilisateurs, le contenu produit par LEVELS (vidéos promotionnelles et contenus similaires), les actifs d'application Web et d'interface utilisateur (code JS, icônes, polices), la configuration d'application et d'infrastructure et les ensembles de déploiements côté serveur.

Chacun d'entre eux obtient un compartiment S3 distinct.

Gestion des secrets d'application

Avec AWS, il existe un AWS Systems Manager Parameter Store chiffré ou AWS Secrets Manager , qui sont des services clé-valeur gérés conçus pour protéger les secrets (vous pouvez en savoir plus sur Linux Academy et 1Strategy).

AWS gère les clés de chiffrement sous-jacentes et gère le chiffrement/déchiffrement. Les secrets eux-mêmes peuvent avoir des politiques d'autorisations de lecture et d'écriture appliquées en fonction des préfixes de clé, à la fois pour l'infrastructure et les utilisateurs (serveurs et développeurs, respectivement).

Accès SSH au serveur

L'accès SSH aux serveurs dans un environnement entièrement automatisé et immuable ne devrait pas du tout être nécessaire. Les journaux peuvent être extraits et envoyés à des services de journalisation dédiés, la surveillance est également déchargée vers un service de surveillance dédié. Néanmoins, un accès SSH occasionnel peut être nécessaire pour l'inspection et le débogage de la configuration.

Pour limiter la surface d'attaque des serveurs, le port SSH n'est pas exposé au réseau public. Les serveurs sont accessibles via un hôte bastion, une machine dédiée permettant un accès SSH externe, en outre protégé par la mise en liste blanche uniquement de la plage d'adresses IP autorisées au niveau du pare-feu. L'accès est contrôlé en déployant les clés SSH publiques des utilisateurs dans les boîtes appropriées (les connexions par mot de passe sont désactivées). Une telle configuration offre une porte assez résistante pour que les attaquants malveillants puissent passer.

Accès à la base de données

Les mêmes principes décrits ci-dessus s'appliquent aux serveurs de base de données. Il peut également être nécessaire occasionnellement de se connecter et de manipuler les données directement dans la base de données, bien que ce ne soit certainement pas une pratique recommandée, et cet accès doit être protégé de la même manière que l'accès SSH des serveurs est protégé.

Une approche similaire peut être utilisée, utilisant la même infrastructure d'hôte bastion avec tunnel SSH. Un double tunnel SSH est nécessaire, un vers l'hôte bastion, et à travers celui-ci, un autre vers le serveur ayant accès à la base de données (l'hôte bastion n'a pas d'accès au serveur de base de données). Grâce à ce deuxième tunnel, une connexion entre la machine cliente de l'utilisateur et le serveur de base de données est désormais disponible.

Présentation des concepts d'évolutivité AWS

Lorsque nous parlons uniquement de serveurs, l'évolutivité est assez facilement obtenue avec des plates-formes plus simples qu'AWS. Le principal inconvénient est que certaines exigences peuvent devoir être couvertes par les services externes de la plate-forme, ce qui signifie que les données voyagent sur le réseau public et brisent les limites de sécurité. En restant avec AWS, toutes les données restent privées, tandis que l'évolutivité doit être conçue pour obtenir une infrastructure évolutive, résiliente et tolérante aux pannes.

Avec AWS, la meilleure approche de l'évolutivité consiste à tirer parti des services AWS gérés avec une surveillance et une automatisation testées sur des milliers de clients utilisant la plate-forme. Ajoutez des sauvegardes de données et des mécanismes de récupération dans le mélange, et vous éliminez beaucoup de problèmes en vous fiant uniquement à la plate-forme elle-même.

Le déchargement de tout cela permet une équipe d'exploitation plus petite, ce qui compense quelque peu le coût plus élevé des services gérés de la plateforme. L'équipe LEVELS était heureuse de choisir cette voie dans la mesure du possible.

Cloud de calcul élastique Amazon (EC2)

S'appuyer sur un environnement éprouvé exécutant des instances EC2 reste une approche plutôt raisonnable, par rapport à la surcharge et à la complexité supplémentaires de l'exécution de conteneurs ou aux concepts architecturaux encore très jeunes et en évolution rapide de l'informatique sans serveur.

Le provisionnement des instances EC2 doit être entièrement automatisé. L'automatisation est réalisée via des AMI personnalisées pour différentes classes de serveurs et des groupes Auto Scaling prenant en charge l'exécution de flottes de serveurs dynamiques en conservant le nombre approprié d'instances de serveurs en cours d'exécution dans la flotte en fonction du trafic actuel.

De plus, la fonction de mise à l'échelle automatique permet de définir les limites inférieure et supérieure du nombre d'instances EC2 à exécuter. La limite inférieure facilite la tolérance aux pannes, éliminant potentiellement les temps d'arrêt en cas de défaillance des instances. La limite supérieure maintient les coûts sous contrôle, ce qui permet un certain risque de temps d'arrêt en cas de conditions extrêmes imprévues. La mise à l'échelle automatique adapte ensuite dynamiquement le nombre d'instances dans ces limites.

Service de base de données relationnelle Amazon (RDS)

L'équipe utilisait déjà Amazon RDS pour MySQL , mais la stratégie de sauvegarde, de tolérance aux pannes et de sécurité appropriée n'avait pas encore été développée. Lors de la première itération, l'instance de base de données a été mise à niveau vers un cluster à deux instances dans chaque VPC, configuré en tant que maître et réplica en lecture, prenant en charge le basculement automatique.

Lors de la prochaine itération, avec la disponibilité du moteur MySQL version 5.7, l'infrastructure a été mise à niveau vers le service Amazon Aurora MySQL . Bien qu'entièrement géré, Aurora n'est pas une solution automatiquement mise à l'échelle. Il offre une mise à l'échelle automatique du stockage, évitant le problème de la planification des capacités. Mais un architecte de solution doit toujours choisir la taille de l'instance informatique.

Le temps d'arrêt dû à la mise à l'échelle ne peut être évité mais peut être réduit au minimum à l'aide de la capacité d'auto-guérison. Grâce à de meilleures capacités de réplication, Aurora offre une fonctionnalité de basculement transparente. La mise à l'échelle est exécutée en créant un réplica en lecture avec la puissance de calcul souhaitée, puis en exécutant le basculement vers cette instance. Tous les autres réplicas en lecture sont ensuite également retirés du cluster, redimensionnés et ramenés dans le cluster. Cela nécessite un peu de jonglage manuel mais c'est plus que faisable.

La nouvelle offre Aurora Serverless permet également un certain niveau de mise à l'échelle automatique des ressources informatiques, une fonctionnalité qui mérite certainement d'être étudiée à l'avenir.

Services AWS gérés

Outre ces deux composants, le reste du système bénéficie des mécanismes de mise à l'échelle automatique des services AWS entièrement gérés. Il s'agit d'Elastic Load Balancing (ELB), d'Amazon Simple Queue Service (SQS), du stockage d'objets Amazon S3, des fonctions AWS Lambda et d'Amazon Simple Notification Service (SNS), où aucun effort de mise à l'échelle particulier n'est nécessaire de la part de l'architecte.

Infrastructure mutable ou immuable

Nous reconnaissons deux approches pour gérer l'infrastructure des serveurs - une infrastructure mutable où les serveurs sont installés et continuellement mis à jour et modifiés sur place ; et une infrastructure immuable où les serveurs ne sont jamais modifiés après le provisionnement, et toutes les modifications de configuration ou mises à jour de serveur sont gérées en provisionnant de nouveaux serveurs à partir d'une image commune ou d'un script d'installation, remplaçant les anciens.

Avec LEVELS, le choix est d'exécuter une infrastructure immuable sans mises à niveau sur place, modifications de configuration ou actions de gestion. La seule exception concerne les déploiements d'applications, qui se produisent sur place.

Pour en savoir plus sur l'infrastructure mutable ou immuable, consultez le blog de HashiCorp.

Présentation de l'architecture

Techniquement, LEVELS est une application mobile et une application Web avec le backend de l'API REST et quelques services d'arrière-plan - une application plutôt typique de nos jours. À cet égard, l'infrastructure suivante a été proposée et configurée :

Isolation de réseau virtuel - Amazon VPC

Le diagramme visualise une structure d'un environnement dans son VPC. D'autres environnements suivent la même structure (avec l'équilibreur de charge d'application (ALB) et le cluster Amazon Aurora partagés entre les environnements de non-production dans leur VPC, mais la configuration de la mise en réseau est exactement la même).

Le VPC est configuré sur quatre zones de disponibilité au sein d'une région AWS pour la tolérance aux pannes. Les sous-réseaux et les groupes de sécurité avec des listes de contrôle d'accès au réseau permettent de satisfaire aux exigences de sécurité et de contrôle d'accès.

Étendre l'infrastructure sur plusieurs régions AWS pour une tolérance aux pannes supplémentaire aurait été trop complexe et inutile à un stade précoce de l'entreprise et de son produit, mais c'est une option à l'avenir.

L'informatique

LEVELS exécute une API REST traditionnelle avec des travailleurs en arrière-plan pour la logique d'application qui se déroule en arrière-plan. Ces deux éléments fonctionnent comme des flottes dynamiques d'instances EC2 simples, entièrement automatisées via les groupes Auto Scaling. Le service géré Amazon SQS est utilisé pour la distribution des tâches en arrière-plan (tâches), ce qui évite d'avoir à exécuter, maintenir et mettre à l'échelle votre propre serveur MQ.

Il existe également certaines tâches utilitaires n'ayant aucune logique métier partagée avec le reste de l'application, comme le traitement d'image. Ces types de tâches s'exécutent extrêmement bien sur AWS Lambda , car les Lambda sont indéfiniment évolutifs horizontalement et offrent un traitement parallèle inégalé par rapport aux serveurs-travailleurs.

Équilibrage de charge, mise à l'échelle automatique et tolérance aux pannes

L'équilibrage de charge peut être réalisé manuellement via Nginx ou HAProxy, mais le choix d' Amazon Elastic Load Balancing (ELB) ajoute l'avantage d'avoir une infrastructure d'équilibrage de charge intrinsèquement automatiquement évolutive, hautement disponible et tolérante aux pannes.

La variante Application Load Balancer (ALB) de l'ELB est utilisée, en utilisant le routage de la couche HTTP disponible au niveau de l'équilibreur de charge. Les nouvelles instances ajoutées à la flotte sont automatiquement enregistrées auprès de l'ALB via les mécanismes de la plateforme AWS. L'ALB surveille également la disponibilité des instances à tout moment. Il a le pouvoir de désenregistrer et de résilier les instances défectueuses, déclenchant l'Auto Scaling pour les remplacer par de nouvelles. Grâce à cette interaction entre les deux, l'auto-guérison de la flotte EC2 est réalisée.

Magasin de données d'application

Le magasin de données d'application est un cluster Amazon Aurora MySQL , composé d'une instance principale et d'un certain nombre d'instances de réplica en lecture. En cas d'échec de l'instance maître, l'un des réplicas en lecture est automatiquement promu dans une nouvelle instance maître. Configuré comme tel, il répond à l'exigence de tolérance aux pannes demandée.

Les réplicas en lecture, comme leur nom l'indique, peuvent également être utilisés pour répartir la charge du cluster de bases de données pour les opérations de lecture de données.

Le stockage de la base de données est automatiquement mis à l'échelle par incréments de 10 Go avec Aurora, et les sauvegardes sont également entièrement gérées par AWS, offrant une restauration ponctuelle par défaut. Tout cela réduit la charge d'administration de la base de données à pratiquement rien, à l'exception de l'augmentation de la puissance de calcul de la base de données lorsque le besoin s'en fait sentir - un service qui vaut la peine d'être payé pour fonctionner sans souci.

Stockage et diffusion des ressources

LEVELS accepte le contenu téléchargé par les utilisateurs qui doit être stocké. Le stockage d'objets Amazon S3 est, de manière assez prévisible, le service qui s'occupera de cette tâche. Il existe également des actifs d'application (éléments d'interface utilisateur - images, icônes, polices) qui doivent être mis à la disposition de l'application cliente, afin qu'ils soient également stockés dans le S3. Offrant des sauvegardes automatisées des données téléchargées via leur réplication de stockage interne, S3 assure la durabilité des données par défaut.

Les images téléchargées par les utilisateurs sont de tailles et de poids variés, souvent inutilement volumineuses pour être diffusées directement et en surpoids, ce qui alourdit les connexions mobiles. Produire plusieurs variantes dans différentes tailles permettra de proposer un contenu plus optimisé pour chaque cas d'utilisation. AWS Lambda est utilisé pour cette tâche, ainsi que pour faire une copie des originaux des images téléchargées dans un compartiment de sauvegarde séparé, juste au cas où.

Enfin, une application Web exécutée par un navigateur est également un ensemble d'actifs statiques - l'infrastructure de build d'intégration continue compile le code JavaScript et stocke également chaque build dans le S3.

Une fois que tous ces actifs sont stockés en toute sécurité dans S3, ils peuvent être servis directement, car S3 fournit une interface HTTP publique, ou via le CDN Amazon CloudFront . CloudFront distribue les ressources géographiquement, ce qui réduit la latence pour les utilisateurs finaux et active également la prise en charge HTTPS pour servir les ressources statiques.

Provisionnement et gestion de l'infrastructure

Le provisionnement de l'infrastructure AWS est une combinaison de la mise en réseau, des ressources et services gérés AWS et des ressources informatiques EC2 nues. Les services AWS gérés sont bien gérés. Il n'y a pas grand-chose à faire avec eux, à part le provisionnement et l'application de la sécurité appropriée, tandis qu'avec les ressources informatiques EC2, nous devons nous occuper de la configuration et de l'automatisation par nous-mêmes.

Outillage

La console AWS basée sur le Web rend la gestion de l'infrastructure AWS "de type lego-bricks" tout sauf triviale et, comme tout travail manuel, plutôt sujette aux erreurs. C'est pourquoi l'utilisation d'un outil dédié pour automatiser ce travail est fortement souhaitée.

L'un de ces outils est AWS CloudFormation , développé et maintenu par AWS. Un autre est le Terraform de HashiCorp - un choix légèrement plus flexible en offrant plusieurs fournisseurs de plates-formes, mais intéressant ici principalement en raison de la philosophie d'approche d'infrastructure immuable de Terraform. Aligné sur la façon dont l'infrastructure LEVELS est exécutée, Terraform, en collaboration avec Packer pour fournir les images AMI de base, s'est avéré être un excellent choix.

Documentation sur les infrastructures

Un avantage supplémentaire d'un outil d'automatisation est qu'il ne nécessite aucune documentation détaillée de l'infrastructure, qui devient obsolète tôt ou tard. Le paradigme « Infrastructure as Code » (IaC) de l'outil de provisionnement sert de documentation, avec l'avantage d'être toujours à jour avec l'infrastructure réelle. Avoir une vue d'ensemble de haut niveau, moins susceptible d'être modifiée et relativement facile à maintenir avec les changements éventuels, documentés à côté est alors suffisant.

Dernières pensées

L'infrastructure AWS Cloud proposée est une solution évolutive capable de s'adapter à la croissance future des produits principalement de manière automatique. Après presque deux ans, il parvient à maintenir les coûts d'exploitation à un niveau bas, en s'appuyant sur l'automatisation du cloud sans avoir une équipe d'exploitation des systèmes dédiée en service 24h/24 et 7j/7.

En ce qui concerne la sécurité, AWS Cloud conserve toutes les données et toutes les ressources au sein d'un réseau privé à l'intérieur du même cloud. Aucune donnée confidentielle n'est jamais nécessaire pour voyager sur le réseau public. L'accès externe est accordé avec des autorisations granulaires fines aux systèmes de support de confiance (CI/CD, surveillance externe ou alerte), limitant la portée de l'accès uniquement aux ressources requises pour leur rôle dans l'ensemble du système.

Architecturer et configurer correctement, un tel système est flexible, résilient, sécurisé et prêt à répondre à toutes les exigences futures concernant la mise à l'échelle de la croissance du produit ou la mise en œuvre d'une sécurité avancée comme la conformité PCI-DSS.

Ce n'est pas nécessairement moins cher que les offres productisées d'Heroku ou de plates-formes similaires, qui fonctionnent bien tant que vous vous adaptez aux modèles d'utilisation courants couverts par leurs offres. En choisissant AWS, vous gagnez plus de contrôle sur votre infrastructure, un niveau supplémentaire de flexibilité avec la gamme de services AWS proposés et une configuration personnalisée avec la capacité de réglage fin de l'ensemble de l'infrastructure.

Lectures complémentaires sur le blog Toptal Engineering :

• Faites vos devoirs : 7 conseils pour l'examen AWS Certified Solutions Architect
• Terraform vs CloudFormation : le guide définitif
• Journalisation SSH et gestion des sessions à l'aide d'AWS SSM
• Utilisation de TypeScript et de la prise en charge de Jest : un didacticiel AWS SAM