aws web hosting best practices 05252010 · 2010-12-22 ·...

Amazon Web Services – Hébergement d'Application Web sur le Nuage AWS: Les Meilleures Solutions Mai 2010

sur 13

Hébergement d'Application Web sur le Nuage AWS Les Meilleures Solutions

Mai 2010

Matt Tavis


sur 13

Résumé Proposer un hébergement web haute disponibilité et évolutif peut s'avérer être une tâche complexe et coûteuse. Les architectures web évolutives traditionnelles ont non seulement nécessité l'implémentation de solutions complexes pour assurer un grand niveau de fiabilité, mais requièrent aussi un prévision efficace du trafic afin de fournir un service client de grande qualité. Les périodes de grands pics et la grande variabilité du trafic conduisent à une faible utilisation de hardware coûteux, générant des coûts d'opération élevés pour un hardware à l'arrêt, ainsi qu'un investissement inefficace de capitaux dans du hardware sous utilisé. Amazon Web Services fournit l'infrastructure fiable, scalable, évolutive, sécurisée et très performante requise pour la majorité des applications web – tout en permettant un modèle d'infrastructure élastique, à scalabilité horizontale et à échelle variable, afin de faire correspondre en temps réel le coût des TIC aux flux de trafic du client.

Public ciblé Ce livre blanc est destiné aux Administrateurs réseau et aux Architectes systèmes qui cherchent à s'aider du nuage pour leur scalabilité et leurs besoins informatiques variables.


sur 13

Une Vue d'Ensemble de l'Hébergement Web Traditionnel La scalabilité de l'hébergement web est un problème d'espace bien connu et cette section n'apprendra pas grand chose à ceux qui sont déjà familiers des modèles d'hébergement web traditionnels . Cependant, cette section va présenter un exemple d'une architecture d'hébergement web standard qui sera utilisée ensuite en comparaison lorsque l'on envisagera comment cette architecture peut être implémentée dans le nuage.

Un Exemple d'Architecture d'Hébergement d'Application Web Traditionnelle

Ci-‐dessous est présentée l'illustration classique d'une architecture scalable d'hébergement web utilisant un modèle d'hébergement web traditionnel.

Figure 1 -‐ Une Architecture d'Application Web Traditionnelle

Cette architecture d'hébergement web traditionnelle est construite autour d'un modèle d'application web en trois-‐tiers, divisant l'architecture en trois couches: présentation, application et persistance. Cette architecture a déjà été conçue pour être scalable horizontalement par l'ajout d'hôtes pour les couches présentation, persistance ou application, et


sur 13

intègre la performance, le fail-‐over et une haute disponibilité. Les sections suivantes s'attarderont sur le pourquoi et le comment une telle architecture peut et devrait être migrée sur le nuage Amazon Web Services.

L'hébergement d'Application Web sur le Nuage en utilisant Amazon Web Services L'architecture d'hébergement web traditionnelle (figure 1) est facilement portable vers les services du nuage proposé par les produits AWS, et ne nécessitent que peu de modifications pour se faire, mais la première question qu'il faut se poser est de savoir s'il y a un intérêt à migrer cette application sur le nuage:

Quel est l'intérêt de porter une solution d'hébergement d'application web classique sur le nuage AWS?

Comment AWS Peur Résoudre Les Problèmes Habituels d'Hébergement d'Application Web

Si vous êtes en charge d'un application web, alors vous devez faire face à toute une variété de problèmes d'infrastructure et d'architecture pour lesquels AWS peut vous apporter des solutions simples, intégrées et économiques. Les points suivants sont juste quelques uns des avantages à utiliser AWS plutôt qu'un modèle d'hébergement traditionnel:

Une Alternative Economique aux Parcs Surdimensionnés que Nécessitent Les Pics de Trafic

Dans le modèle d'hébergement traditionnel, des serveurs doivent être mis à disposition pour gérer les pics de trafic, et les cycles non utilisés sont perdus en dehors de ces périodes de pics. Les applications web hébergées sur AWS peuvent mettre à disposition des serveurs supplémentaires en fonction des besoins, ce qui permet une haute disponibilité et adaptent les coûts en fonction du trafic.

Par exemple, les graphiques suivants montrent une application web avec un pic entre 9h et 15h, et une moins grande utilisation le reste de la journée. Dans cet exemple, une approche auto-‐scalable basée sur les tendances réelles du trafic et la mise à disposition de ressources seulement quand nécessaire augmenterait la disponibilité et réduirait les coûts de plus de 50%.

Figure 2 -‐ Un Exemple de Capacité Gâchée dans un Modèle d'Hébergement Classique


sur 13

Une Solution Scalable pour Gérer Les Pics Inattendus de Trafic

Une des conséquences encore plus terrible que la lenteur de mobilisation associée à un modèle d'hébergement traditionnel est l'incapacité à répondre à temps aux pics de trafic inattendus. Il existe beaucoup d'exemples d'applications web victimes d'un crash à cause d'un pic de trafic inattendu provoqué par la mention de cette application dans un média populaire. La même capacité de variabilité qui aide les applications web à scaler pour s'adapter aux pics de trafic peut aussi être utilisée pour gérer une charge inattendue, car des nouveaux hôtes peuvent être lancés et opérationnels en seulement quelques minutes.

Une Solution Variable pour un Environnement de Test, Load, Beta, et Pré-‐Production

Les coûts du hardware associés à la construction d'un environnement d'hébergement traditionnel pour la production d'un application web ne s'arrêtent pas à ceux du parc de production. Bien souvent, les parcs de pré production, de beta et de tests doivent être crées indépendamment afin d'assurer la qualité de l'application web à toutes les phases du développement avant qu'elle ne soit lancée sur le parc de production. Même si l'on peut procéder à différentes optimisations pour obtenir la plus grande utilisation possible du hardware de test, ces parcs parallèles ne sont souvent pas utilisés optimalement. Beaucoup de hardware très coûteux dorment pendant longtemps, sans être utilisés. Lorsque vous utilisez le nuage AWS, des parcs de test peuvent être mis à disposition selon vos besoins afin de s'assurer que ces parcs soient disponibles seulement lorsque nécessaires. De plus, le nuage AWS peut être utilisé pour simuler un flux de trafic afin d'effectuer un test de charge sur une application candidate au lancement. Ces parcs parallèles peuvent aussi être utilisés comme un environnement de pré-‐production pour le lancement d'une nouvelle production, ce qui permet un switch over rapide entre la production actuelle et une nouvelle version de l'application, avec peu ou pas d'arrêt de fonctionnement.


sur 13

L'architecture du Nuage AWS pour l'Hébergement Web

Ci-‐dessous est présentée une autre vue d'une architecture classique d'application web et comment elle peut tirer profit de l'infrastructure informatique du nuage AWS:

Figure 3 -‐ Un Exemple d'une Architecture d'Hébergement Web sur AWS

Les Composants Clés d'une Architecture d'Hébergement Web AWS

Les sections suivantes mettent en évidence certains composants clés d'une architecture d'hébergement web AWS et en quoi ils sont différents d'une architecture traditionnelle d'hébergement web.

Diffusion de Contenu

La mise en mémoire cache reste pertinente lors de l'utilisation de l'infrastructure informatique du nuage Amazon Web Service. Toutes les solutions existantes dans votre infrastructure d'application web devrait fonctionner tout à fait normalement avec le nuage AWS. Cependant, en utilisant AWS, une autre option est rendue possible, celle d'utiliser le


sur 13

service Amazon CouldFront1 pour la mise en mémoire cache des actifs de votre application stockés sur Amazon Simple Storage Service 2(Amazon S3) Le principal avantage à utiliser une solution de mise en mémoire cache avec Amazon EC2 est la capacité à accélérer les performances de votre application pour vos clients grâce à point de présence (POP) local de mise en mémoire cache, qui accélère beaucoup la vitesse de chargement de streaming ou le téléchargement de contenu statique (e.g., Vidéos Flash ou images) en diffusant ce contenu depuis un emplacement plus proche. Un autre avantage de la mise en mémoire cache de CloudFront est qu'elle est suit le modèle d'AWS sans engagement, sans minimum et sans contrat, ce qui vous permet de n'utiliser que ce dont vous avez besoin et seulement le temps que nécessite la mise en mémoire cache.

Gérer un DNS Public en utilisant des CNAME et Elastic IP

Migrer une application web vers le nuage AWS nécessitent quelques changements de DNS. AWS ne fournit pas un service de gestion de DNS, donc la redirection de votre trafic internet vers l'application sur le nuage AWS nécessitera de changer de DNS publique, afin de pointer vers un Elastic Load Balancing CNAME ou vers une adresse Elastic IP. Le DNS limite cependant l'utilisation de CNAMES aux sous domaines donc le domaine racine (e.g., exemple.com) ne peut pas pointer vers un Elastic Load Balancer CNAME. Notez bien que les adresses IP derrière l'Elastic Load Balancer peuvent changer avec le temps, donc il n'est pas possible pour l'instant de faire pointer votre DNS racine A-‐Record vers les adresses IP derrière l'Elastic Load Balancer CNAME. Une manière simple de contourner ce problème est d'assigner des Elastic IPs, qui sont des adresses IPs statiques assignées de manière dynamique à deux, ou plus, serveurs web EC2 dans votre application, et de faire rediriger le trafic de ces serveurs vers le sous domaine qui route vers l'Elastic Load Balancer CNAME (e.g., www.exemple.com) Le registraire de nom de domaine utilisé lors de l'achat de votre nom de domaine publique devrait fournir un mécanisme simple pour appliquer l'Elastic Load Balancer CNAME au sous domaine approprié (e.g. www.exemple.com) et pour établir la liste des adresses Elastic IP pour le domaine racine A-‐Records (e.g., exemple.com).

Sécurité de l'Hôte

Contrairement à un modèle d'hébergement web traditionnel, le filtrage du trafic entrant n'est pas limité à la périphérie du réseau, mais est appliqué au niveau de l'hôte. Amazon EC2 fournit une solution nommée security groups, qui est analogue à un firewall du trafic réseau entrant, qui vous permet de spécifier les protocoles, les ports et les plages d'adresses IP source autorisées à atteindre vos instances EC2. Chaque instance EC2 peut être se voir assigner un ou plusieurs groupes de sécurité, qui dirige chaque trafic vers l'instance appropriée. Les groupes de sécurité peuvent être configurés de manière à ce que seuls des sous réseaux ou des adresses IP spécifiques aient accès à l'instance EC2, ou référencer d'autres groupes de sécurité qui limitent l'accès aux instances EC2 qui sont dans des groupes spécifiques. Dans l'exemple d'architecture d'hébergement web AWS (ci-‐dessus), le groupe de sécurité pour la grappe de serveurs peut restreindre l'accès à tous les hôtes over TCP sur les ports 80 et 443 (HTTP et HTTPS) et depuis les instances dans le groupe de sécurité du serveur d'application sur le port 22 (SSH) pour une gestion directe de l'hôte. D'autre part, le groupe de sécurité de la grappe de serveurs d'application peut autoriser l'accès depuis le groupe de sécurité du Serveur Web afin de gérer les requêtes web et depuis votre sous réseau particulier over TCP sur le port 22 (SSH) pour une gestion directe de l'hôte. Dans ce modèle, vos ingénieurs peuvent se connecter directement aux serveurs de

1 Amazon CloudFront -‐ http://aws.amazon.com/cloudfront/ 2 Amazon S3 – http://aws.amazon.com/s3


sur 13

l'application depuis le réseau particulier, et ensuite avoir accès aux autres grappes depuis les serveurs d'application. Vous pourrez trouver une explication plus détaillée sur la sécurité sur AWS Security Center3. Ce site contient des bulletins de sécurité, des informations de certification et des livres blancs sur la sécurité qui expliquent les capacités de sécurité d'AWS.

Quel est le but de l'illustration suivante ?

Figure 4: Groupes de Sécurité dans une Application Web

Répartition de charge entre les grappes

Un hardware permettant la répartition de charge est un composant commun du réseau utilisé dans les architectures traditionnelles d'hébergement web. AWS permet la même chose grâce à son service Elastic Load Balancing4, qui est une solution de répartition des charges configurable qui supporte le bilan de santé des hôtes, la diffusion du trafic sur les instances EC2 à travers plusieurs zones de disponibilité et l'addition ou soustraction dynamique d'hôtes EC2 de la rotation de répartition de charge. L'Elastic Load Balancing permet aussi d'augmenter ou de réduire dynamiquement la capacité de répartition de charge afin de coller aux fluctuations du trafic, tout en fournissant un point d'entrée prévisible via un CNAME persistant. Le service Elastic Load Balancing supporte aussi les sessions persistantes afin de gérer les besoins de routage plus élaborés. Si votre application nécessite des capacités plus élaborées de répartition de charge, alors il faudra prendre une approche alternative et utiliser un logiciel de répartition de charge sur les instances EC2 (e.g Zeus, HAProxy, nginx) et assignez des Elastic IP à ces instances EC2 spécifiques pour minimiser les changements de DNS.

3 AWS Security Center – http://aws.amazon.com/security 4 Amazon Elastic Load Balancing -‐ http://aws.amazon.com/elasticloadbalancing


sur 13

Trouver d'autres hôtes et services

Un autre changement par rapport à l'architecture d'hébergement web traditionnelle est que la plupart de vos hôtes auront des adresses IP dynamiques. Bien que toutes les instances EC2 puissent avoir à la fois des entrées DNS privé ou publique, et seront adressables sur Internet, les entrées DNS et les adresses IP seront assignées dynamiquement au lancement de l'instance et ne peuvent pas être assignées manuellement. Les IP statiques (Elastic IP selon la terminologie d'AWS) peuvent être assignées à des instances en cours d'exécution une fois qu'elles sont lancées, mais seuls les hôtes du nuage AWS avec une Elastic IP auront des points de terminaisons persistants pour les communications réseaux. Les Elastic IP devraient être utilisées pour les instances et les services que nécessitent des points de terminaison persistants, telles que la base de données master, le serveur central ou les répartiteurs de charge hébergés sur EC2. Les types d'instances facilement scalables, comme les serveurs web, doivent être rendues localisables à leurs points de terminaison dynamiques grâce aux services plus persistants mentionnés plus haut. Une solution simple pour se faire est de maintenir une configuration centralisée des instances et des points de terminaison du réseau nécessaires, qui peuvent ensuite être accessibles à volonté depuis des points de terminaison persistants à Elastic IP, qui peuvent être utilisés au lancement d'une instance via un script bootstrap. Puisque la plupart des architectures d'application web comprennent un serveur de base de données, qui est toujours en fonction, il est communément utilisé pour ce genre d'informations de configuration. Il faut noté que pour encore réduire vos coûts, vous devriez envisager les Reserved Instances5 pour tous les services persistants dans votre infrastructure EC2. En utilisant ce modèle, les hôtes récemment ajoutés peuvent demander la liste des points de terminaison nécessaires pour les communications depuis la base de données dans le cadre de la phase de bootstrap. La localisation de la base de données peut être fournie en tant que données utilisateur 6 passées dans chaque instance au moment du lancement de l'instance. Sinon, le service SimpleDB peut être utilisé pour stocker et maintenir les informations de configuration nécessaires puisque c'est un service à haute disponibilité qui est disponible à un point de terminaison bien défini.

Mise en mémoire cache dans l'application web

Les solutions software de mise en mémoire cache à l'intérieur de votre architecture d'application web existante peuvent très probablement être utilisées en l'état dans le nuage AWS. La simple élaboration d'une instance contenant votre solution software suffit à permettre la mise en mémoire cache sur le nuage AWS. La mise en mémoire cache des couches web et application peut se faire de cette manière, et la configuration centralisée dans la base de donnée peut aider les serveurs web et d'application à trouver les serveurs cache appropriés.

Configuration de base de donnée, backup et failover

Beaucoup d'applications web contiennent des formes de persistance et habituellement sous la forme d'une base de données. AWS offre deux solutions principales pour les bases de données sur le nuage; héberger une base de donnée relationnelle (RDBMS) sur une instance Amazon EC2 ou utiliser Amazon Relational Database Service (RDS) pour une solution de RDBMS hébergée. AWS supporte un grand nombre de solutions pour base de données sur EC2 incluant MySQL, Oracle, SQLServer et DB2. Utiliser RDS permet la connectivité (e.g., ODBC ou JDBC) familières aux développeurs, mais offre une gestion simplifiée rendue possible via API. Les tâches basiques, comme l'ajout de stockage, le back up

5 Reserved Instances -‐ http://aws.amazon.com/ec2/reserved-‐instances/ 6 User Data -‐ http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/index.html?ApiReference-‐ItemType-‐RunInstancesType.html


sur 13

des données et la migration de la base de données sur une instance EC2 plus grande peuvent être automatisées via de simples appels API. Tout comme dans le modèle d'hébergement traditionnel, les solutions de base de données sur le nuage doivent posséder à la fois les instances master et slave pour supporter le backup et le failover. Les clients d'AWS hébergeant une base de données sur EC2 ont utilisé avec succès une variété de modèles de master/slave et de modèles de réplication sur les instances EC2, incluant le mirroring pour des copies en lecture seule et l'envoi de logs pour des slaves passifs always-‐ready. Les applications web utilisent souvent une base de donnée backup et un modèle de défaillance spécifiques et il est très probable que la majorité de ces modèles soient facilement réplicables sur le nuage AWS. Les clients d'AWS utilisant RDS reçoivent des mécanismes de backup et de failover intégrés via de simples appels API. Il est recommandé de déployer un RDBMS sur plusieurs Availability Zones en utilisant plusieurs slaves dans le but d'un failover afin de maximiser la disponibilité de la base de donnée. Utiliser une deuxième Availability Zone revient à mettre en place un centre de données backup car chaque Availability Zone est complètement séparée des autres zones de la même région afin d'assurer une disponibilité maximale de la région. Les clients d'AWS utilisant RDS peuvent tirer avantage de la fonctionnalité de Mutli-‐AZ qui déploiera automatiquement une instance slave de secours automatique dans une Availability Zone différente.

Une autre considération à prendre lors de l'exécution de base de données directement sur EC2 (i.e., sans utiliser RDS) est la disponibilité d'espace de stockage persistant et insensible aux pannes. Dans ce but, il est recommandé d'utiliser les volumes Amazon Elastic Block Storage (Amazon EBS) pour les bases de données exécutées sur Amazon EC2, qui sont l'équivalent de stockage attaché au réseau pour exécuter les instances EC2. Pour les instances EC2 exécutant une base de donnée, toutes les données et les logs de la base de données doivent être placés sur les volumes Amazon EBS, qui resteront disponibles même en cas de défaillance de l'hôte de la base de donnée. Cela permet un scénario de failover simplifié où une nouvelle instance EC2 peut être lancée en cas de défaillance de l'hôte et les volumes Amazon EBS existants peuvent être attachés simplement à la nouvelle instance pour permettre à la base de donnée de reprendre où elle s'était arrêtée. De plus, les volumes Amazon EBS fournissent automatiquement une redondance dans l'Availability Zone, ce qui augmente leur disponibilité par rapport aux disques simples. Si la performance d'un seul volume Amazon EBS n'est pas suffisante pour les besoins de votre base de données alors des volumes agrégés par bande peuvent augmenter la performance IOPS pour votre base de données. Lorsque vous utilisez RDS, la gestion des volumes Amazon EBS est opérée par le service RDS.

En plus du support pour les base de données relationnelles sur EC2, AWS propose aussi le service SimpleDB, qui peut apporter un service central de base de données non relationnelle léger, à haute disponibilité et insensible aux défaillances offrant l'interrogation et l'indexation des données sans avoir besoin d'un schéma fixé. SimpleDB peut s'avérer un substitut très efficace pour les bases de données dans les scénarios d'accès de données qui nécessitent un grand schéma très indexé et flexible. Des exemples d'utilisation pour SimpleDB sont la gestion des données de configuration, la production de catalogues et les données de session. De plus, EC2 supporte l'hébergement de plusieurs autres technologies émergeantes dans la lignée de NoSQL, comme Cassandra, CouchDB et MemcacheDB.

Stockage et backup de données et de ressources

Il existe dans le nuage AWS de nombreuses options de stockage, d'accès et de backup des données et des actifs de votre application web. L'Amazon Simple Storage Service (Amazon S3) fournit un stockage à haute disponibilité et redondant des objets. C'est une très bonne solution de stockage pour les objets relativement statiques et peu changeant comme les images, les vidéos et les autres médias statiques. Amazon S3 supporte aussi la mise en mémoire cache et le


sur 13

streaming en périphérie de ces ressources via le service CloudFront. Pour le système de fichier attaché comme le stockage, des volumes Amazon Elastic Block Storage peuvent être attachés aux instances EC2, qui peuvent opérer comme des disques montables pour l'exécution des instances EC2. Amazon EBS est parfaitement adapté pour les données qui nécessitent d'être accessibles en mode bloc et qui nécessitent une persistance en dehors de la vie d'exécution de l'instance, comme par exemple les partitions d'une base de données et les logs de l'application. En plus d'être persistants en dehors de l'instance EC2, il est possible de prendre des instantanés des volumes Amazon EBS et des les stocker dans Amazon S3, pouvant être utilisés pour un backup des données d'instance en cours d'exécution. Les instantanés EBS sont complémentaires en termes de backup des données et effectuer des instantanés plus souvent peut réduire le temps que prend chaque instantané. Les volumes Amazon EBS peuvent avoir une taille jusqu'à 1 TB et plusieurs volumes Amazon EBS peuvent être agrégés par bande pour encore augmenter la taille du volume ou améliorer la performance I/O. Une autre fonctionnalité utile des instantanés Amazon EBS est qu'ils peuvent servir de référence pour la réplication des données à travers plusieurs volumes Amazon EBS et être attachées à d'autres instances en cours d'exécution.

Scalage Automatique du parc

L'une des différences majeures entre l'architecture web AWS et le modèle d'hébergement traditionnel est la capacité de scaler dynamiquement à la demande le parc de l'application web afin de gérer les hausses ou les baisses de trafic. Dans le modèle d'hébergement traditionnel, on utilise généralement les prévisions de trafic pour mettre à disposition des hôtes à l'avance. Dans une architecture de nuage AWS, les instances peuvent être mises à disposition sur le vif en fonction d'une série de déclencheurs afin d'effectuer un scale out et scale in du parc. Amazon Auto Scaling peut être utilisé pour créer une capacité de groupes de serveurs pouvant croître ou réduire à la demande. Auto Scaling fonctionne aussi directement avec CloudWatch pour les indicateurs et l'Elastic Load Balancing service pour l'ajout ou la suppression d'hôtes pour la diffusion de charge. Par exemple, si les serveurs web indiquent un utilisation du CPU de plus de 80% sur une certaine période de temps alors un serveur web supplémentaire peut rapidement être déployé, et être ensuite ajouté automatiquement à l'Elastic Load Balancer pour une inclusion immédiate dans la rotation de répartition de charge. Comme montré dans le modèle d'architecture d'hébergement web AWS, plusieurs groupes auto scalables peuvent être créés pour différentes couches de l'architecture afin de permettre à chaque couche d'être scalée indépendamment. Par exemple, le groupe de serveurs web auto scalable peut déclencher un scale out et un scale in sur l'I/O du réseau alors que le groupe de serveurs d'application auto scalable est peut-‐être en train de scale out et scale in sur l'utilisation du CPU. Vous pouvez aussi déterminer les minimums et les maximums, afin de vous aider à assurer une disponibilité 24/7 et à limiter l'utilisation dans un groupe. Les déclencheurs de l'Auto Scaling peuvent être déterminés à la fois pour augmenter ou pour diminuer le parc total d'une couche particulière afin de faire correspondre l'utilisation des ressources avec les besoins réels du trafic. En plus du service Auto Scaling, les parcs EC2 peuvent facilement scaler directement à travers des API EC2, ce qui permet d'exécuter, d'arrêter et d'inspecter des instances.

Le Failover avec AWS

Un autre avantage majeur à utiliser AWS plutôt qu'un hébergement web traditionnel est que les Availability Zones donnent au développeur de l'application web un accès facile à plusieurs emplacements pour le déploiement d'instance. Les Availability Zones sont des emplacements distincts conçus pour être isolés des défaillances dans d'autres Availability Zones et pour fournir une connectivité réseau économique avec peu de latence aux autres Availability Zones dans la même Region. Comme vous pouvez le voir dans l'architecture d'hébergement web AWS, il est recommandé de diffuser


sur 13

les hôtes EC2 au travers de multiples Availability Zones puisque c'est une solution facile pour rendre votre application web insensible aux défaillances. Il faut faire bien attention à ce qu'il y ait des dispositions pour migrer des points d'accès simples au travers des Availability Zones en cas de défaillance. Par exemple, il est recommandé d'installer une base de données slave sur une 2nde Availability Zone afin d'assurer que la persistance des données reste constante et hautement disponible même pendant un scénario de défaillance improbable.

Même si migrer une application web existante sur le nuage AWS requiert certains changements architecturaux, l'amélioration significative de la scalabilité, de la fiabilité et de la rentabilité font que cette solution est largement valable.

Considérations Importantes lors de l'utilisation de AWS pour l'Hébergement Web Lorsque vous migrez sur le nuage AWS, il existe des différences fondamentales avec un modèle d'hébergement traditionnel. La section précédente a mis en relief beaucoup des domaines de considérations lors du déploiement d'une application web sur le nuage. La section suivante met en avant les changements architecturaux majeurs qui doivent être considérés lors de l'apport de n'importe quelle application sur le nuage.

Plus aucun matériel réseau physique

Les matériels réseau physique ne peuvent plus être déployés sur AWS. Par exemple, les firewalls, les routeurs et les répartiteurs de charge de vos applications AWS ne devront plus prendre la forme d'un matériel physique et devront être remplacés par des solutions software. Il existe une grande variété de solutions qualitatives d'entreprise pour tous ces problèmes, qu'il s'agisse de la répartition de charge (e.g., Zeus, HAProxy, nginx, Pound, ...) ou de l'établissement d'une connexion VPN (e.g., OpenVPN, OpenSwan, Vyatta, ...) Ce n'est pas pas une limitation à ce qui peut être exécuté sur le nuage AWS, mais si vous utilisiez ces matériels cela constituera un changement architectural dans votre application.

Firewalls omniprésents

Là où dans un modèle d'hébergement traditionnel vous n'aviez précédemment qu'un simple DMZ et des communications ouvertes entre vos hôtes, AWS adopte un modèle plus sécurisé où chaque hôte est fermé. L'une des étapes dans la préparation d'un déploiement sur AWS sera l'analyse du trafic entre les hôtes, ce qui permettra de décider quels ports précis doivent être ouverts. Des Groupes de Sécurité peuvent être crées dans EC2 pour chaque type d'hôte dans votre architecture et une large variété de modèles de sécurité simple et à plusieurs niveaux peuvent être créés pour activer un accès minimum entre les hôtes de votre architecture.

Disponibilité de centres de données multiple

Les Availability Zones dans EC2 doivent être considérées comme autant de centres de données multiples. Ils sont à la fois logiquement et physiquement séparés et fournissent un modèle facile d'utilisation pour déployer votre application au travers de centres de données à la fois pour une haute disponibilité et une grande fiabilité.


sur 13

Traitement éphémère et dynamique des hôtes

C'est probablement le changement les plus important dans la façon dont vous allez peut-‐être concevoir votre architecture d'application AWS, il faut considérer les hôtes d'EC2 comme éphémères et dynamiques. Toute application construite pour le nuage AWS ne doit pas se baser sur la supposition que les hôtes seront toujours disponibles et devrait savoir que toutes les données locales (i.e., non présentes sur un volume Amazon EBS) seront perdues en cas de défaillance. De plus, quand un nouvel hôte est introduit, il ne faut faire aucune supposition sur son adresse IP et sur son emplacement dans une Availability Zone. Cela force la mise en place d'un modèle de configuration plus flexible et une approche solide du bootstrap d'un hôte, mais ces mêmes techniques sont critiques pour la construction et l'exécution d'une application hautement scalable et insensible aux défaillances.

Conclusion Beaucoup de considérations architecturales et conceptuelles se posent lorsque l'on s'intéresse à la migration d'une application web sur le nuage AWS, mais les bénéfices d'une infrastructure économique, à grande scalabilité et insensible aux défaillances qui croît en même temps que votre activité dépassent de loin les inconvénients d'une migration sur le nuage AWS.

aws web hosting best practices 05252010 · 2010-12-22 ·...

Documents