Devoxx – Jour 1 – Applications robustes avec Amazon EC2

Devoxx Chris Richardson EC2

Amazon Elastic Compute Cloud (aka EC2), et de manière générale les Amazon Web Services, ont attiré l’attention de nombreuses personnes pour la flexibilité de déploiement qu’ils permettent.

Cette plate-forme de Cloud Computing a recourt à la virtualisation pour créer à la demande des instances de serveurs directement utilisables. Il s’agit donc d’une approche totalement différente des hébergements traditionnels.

Lorsque l’on parle d’EC2, il est souvent question du déploiement de sites Web de type réseaux sociaux pouvant connaître de grands pics de trafic imprévisibles. On met alors en avant l’élasticité de configuration qu’apporte EC2, par définition. En revanche, il est rarement question des problématiques de haute disponibilité ou des bonnes pratiques à suivre pour les déploiements d’architectures multi-tiers classiques.
De même, au-delà de l’élasticité, les justifications du déploiement sur EC2 sont en général peu abordées.

Chris Richardson, créateur de CloudFoundry (récemment racheté par SpringSource), nous a offert une présentation très complète sur l’ensemble de ces sujets rarement abordés autour des Web Services d’Amazon.

 

Le choix d’EC2 pour le déploiement d’applications Web

Le déploiement d’une application Web sur EC2 se justifie par les avantages suivants :

  • Mises en production simplifiées et moins sujettes aux erreurs humaines,
  • Possibilité d’effectuer des snapshots de l’état d’un serveur à un instant donné, de le sauvegarder pour le restaurer plus tard en cas de défaillance,
  • Réduction des tâches de maintenances par rapport à un hébergement interne à l’entreprise (cet avantage peut être invoqué pour tout type d’hébergement externalisé),
  • Coût réduit dans certains cas.

Le système de facturation particulier d’Amazon fait que le coût total de possession peut être avantageux dans une configuration connaissant des pics de trafic importants.

La mise en production est quant à elle simplifiée par la possibilité d’effectuer un déploiement préliminaire sur un clone de l’environnement de production : on double alors le nombre d’instances utilisées. Une fois le déploiement terminé, testé, et validé, il suffit de diriger le trafic vers l’infrastructure clone puis d’éteindre l’infrastructure initiale. On reproduit ainsi le mécanisme de double buffer utilisé en programmation graphique.

En contrepartie, EC2 possède certaines limitations :

  • Coût supérieur à un hébergement classique pour les instances utilisées 24×7,
  • Impossible, actuellement de créer des instances de taille très importante (taille mémoire maximale de 68 Go, ce qui peut être limitant pour les très grosses bases de données),
  • Absence de stockage à accès rapide : on ne trouve pas sur EC2 d’équivalent à RAID SAS / SCSI,
  • EC2 ne dispose pas de la certification PCI requise pour les paiements électroniques.

Architecture haute disponibilité sur EC2

Les applications Web Java EE fonctionnant sur des middlewares comme Tomcat nécessitent un déploiement en cluster pour assurer leur haute disponibilité en cas de faille de l’un des nœuds. Pour des raisons de performance, de flexibilité de configuration, ou pour d’autres contraintes techniques (nécessité d’une gestion particulière des sticky sessions, gestion de la compression deflate/gzip, mise en cache, environnement Web hétérogène, …), il est courant de mettre en place des serveurs frontaux Apache assurant un load balancing. Ces serveurs Apache sont alors eux-même précédés d’un load balancer afin d’exposer une IP unique aux visiteurs.

Chris Richardson nous montre alors que ce type de configuration est tout à fait réalisable avec l’infrastructure d’Amazon. Il prend alors la forme suivante :

devoxx infrastructure Amazon

Sur EC2, chacun des tiers de cette architecture soulève des problématiques distinctes.

Apache et load balancing

Amazon fournit un mécanisme de load balancing clé en main : l’Elastic Load Balancing. Ce répartiteur ne propose malheureusement pas d’affinité de session. Si une telle fonctionnalité est nécessaire pour le bon fonctionnement de l’application, il sera nécessaire d’avoir des serveurs Apache sur EC2 configurés avec mod_proxy en mode balancer. Ces serveurs seront alors accédés par Elastic Load Balancer.

Si l’on souhaite augmenter ou diminuer dynamiquement le nombre d’instances Tomcat utilisées, il est nécessaire de mettre à jour le balancer en amont pour le prévenir de ce changement de topologie. Une telle synergie existe nativement entre EC2 et Elastic Load Balancing, malheureusement ce n’est pas encore le cas avec Apache (le récent JBoss mod_cluster et les prochaines versions de mod_proxy_balancer améliorent la situation).

Tomcat

La couche applicative est susceptible de rencontrer des problèmes de compatibilité avec EC2. En effet la topologie réseau particulière d’EC2 rend le multicast impossible. Par conséquent, l’ensemble des frameworks utilisant le multicast pour découvrir leurs voisins ne pourront fonctionner.

Cette limitation peut être contournée, mais nécessite des développements dédiés. Il s’agit de mettre en place un registre en se basant sur les services d’AWS pour découvrir les instances démarrées ou en utilisant JGroups over TCP.

Le provisioning dynamique des instances EC2 dédiées aux serveurs applicatifs peut se faire via le mécanisme Amazon Auto Scaling (bêta). Là encore, des limitations doivent être prises en compte :

  • Afin de déterminer si le nombre d’instances doit être augmenté ou réduit, Amazon Auto Scaling repose sur les web services Amazon CloudWatch qui retournent des métriques bas niveau sur les instances EC2 (CPU, mémoire, réseau, I/O). Il n’est pour le moment pas possible de suivre les métriques applicatives via JMX par exemple,
  • Les instances doivent être capable de s’auto-configurer au démarrage pour offrir in fine un service Tomcat fonctionnel,
  • Comme noté précédemment, les instances doivent s’enregistrer elles-même auprès des serveurs Apache.

MySQL

MySQL peut être déployé sur une instance EC2 sans difficulté. Le stockage peut se faire sur le disque local ou sur Amazon Elastic Block Storage (EBS) selon les besoins en latence ou en fiabilité avec des backups réguliers sur Amazon Simple Storage Service. Toutefois, afin de limiter les tâches d’administration qui peuvent aller à l’encontre de la logique d’externalisation, il est possible d’utiliser le très récent Amazon Relational Database Service.

Ce service offre un stockage MySQL dont l’administration est à la charge d’Amazon. Les bases de données MySQL sont alors stockées sur EBS.

Traitement de batchs

Si l’application Web déployée sur EC2 doit effectuer beaucoup de traitements lourds, il peut être souhaitable de dédier des instances à cette tâche. Ces workers recevront alors des tâches à traiter via une file SQS (Simple Queue Service).

Dans le cas où il serait intéressant de faire évoluer le nombre de workers dynamiquement, il est possible de démarrer de nouvelles instances et de les laisser consommer des tâches sur la file d’attente SQS.

Chris Richardson donnait ainsi l’exemple d’un site gérant des photos et ayant besoin de générer des aperçus après upload. Dans cette situation, il est intéressant d’adapter le nombre de workers à la charge du moment sujette à de fortes variations au cours de la journée. La figure suivante illustre cette configuration, les données d’entrée et de sortie du traitement étant ici stockées sur S3 :

Problématiques de sécurité

La sécurité est probablement la principale crainte avec le Cloud Computing. Avec AWS plusieurs solutions existent pour adresser cette problématique :

  • Définir des security group réunissant l’ensemble des instances d’une même couche ; n’autoriser les communications qu’entre les groupes susceptibles de communiquer ensemble ainsi que les communications SSH provenant des équipes d’administration
  • Renforcer au besoin cette stratégie par la mise en place de configurations IPTable locales

En outre, en raison de l’échelle mondiale d’Amazon, une difficulté supplémentaire est qu’il n’est pas possible de savoir dans quel pays sont stockées les données, ce qui peut être problématique dans certaines situations.

Un nouvel élément de l’offre Amazon pour satisfaire les besoins de sécurité de ses clients est le récent Amazon Virtual Private Cloud qui permet de connecter des serveurs Amazon EC2 directement au réseau privé d’une entreprise grâce à un VPN plutôt que de les connecter à l’Internet. On obtient alors une topologie similaire aux Wide Area Networks qui relient les différents continents dans les systèmes d’information des grandes multi-nationales.

Enfin, il est bon de noter qu’Amazon garantit que l’ensemble des données stockées sur les disques locaux seront effacées avant la ré-attribution de l’instance à un autre utilisateur.

Intégration des Amazon Web Services aux applications

Jusqu’ici il était question d’adapter EC2 aux principes d’architectures classiques. Chris Richardson insiste ensuite sur la possibilité de tirer parti des services proposés nativement par la plate-forme Amazon Web Services.

Stockage de fichiers avec S3

Les instances EC2 disposent toutes d’un stockage local. Toutefois, ce stockage est éphémère par nature puisqu’il est perdu dès que l’instance est éteinte (suite à une opération volontaire, ou à une défaillance matérielle).

Simple Storage Service (S3) fournit un service de stockage à distance dont la fiabilité est assurée par Amazon. Les opérations de création, lecture, écriture, et suppression se font par une API REST.

Dans ce contexte, les applications déployées sur Amazon EC2 ont intérêt à utiliser directement ces possibilités plutôt que de continuer à s’appuyer sur le stockage local en tablant sur sa fiabilité ou en laissant un script tiers assurer le backup régulier sur S3. On notera toutefois que S3 ne permet pas de reprendre un upload interrompu ce qui pourra se révéler gênant avec le transfert de gros fichiers.

L’API JetS3t permet d’accéder simplement à S3 depuis une application Java.

Persistance de données avec SimpleDB

Amazon Simple DB est une alternative intéressante au déploiement d’une base de données relationnelle telle que MySQL. Nous noterons que SimpleDB offre désormais le choix d’une localisation en Europe.

Il s’agit d’une base de données non relationnelle, sans schéma et adoptant les préceptes du NoSQL. Ainsi, il n’est pas possible d’effectuer des jointures, des transactions, ou de définir des verrous.

Les applications peuvent s’y intégrer en utilisant l’API SOAP ou REST. L’absence de jointure doit être comblée par une dé-normalisation et une duplication de certains éléments dans le modèle de données. Enfin, de par sa nature, il est préférable de paralléliser les lectures sur SimpleDB, afin de bénéficier d’une latence améliorée par rapport aux invocations en série.

Les applications Java peuvent utiliser Typica pour accéder à SimpleDB ou encore SimpleJPA qui propose une implémentation JPA pour SimpleDB.

Amélioration des performances avec CloudFront

CloudFront est la solution de Content Delivery Network (CDN) d’Amazon. Elle s’intègre naturellement avec S3 en permettant d’enregistrer simplement un bucket auprès de CloudFront afin que ce dernier assure la diffusion de son contenu.

CloudFront dispose de serveurs de proximité aux États-Unis, en Europe et en Asie.

La question du Platform as a Service (PaaS)

En fin de présentation, Chris Richardson aborde la question du Platform as a Service (PaaS). Google App Engine et Microsoft Azure proposent déjà des solutions intéressantes pour le déploiement d’application.

Il remarque par contre que ces systèmes ne sont pas très flexibles et imposent beaucoup de contraintes : limitation à 30 secondes pour une requête chez Google, fonctionnalités limitées rendant de nombreux frameworks incompatibles, …

En toute logique, compte tenu de son affinité à CloudFoundry, il suggère alors de le considérer comme une opportunité afin de profiter de la plus grande flexibilité qu’il offre face à la solution de Google.

Conclusion

Chris Richardson nous a présenté ici l’ensemble des problématiques liées à une utilisation professionnelle et réaliste d’EC2 et d’AWS.

On ne peut que saluer l’orientation résolument ni commerciale ni élogieuse de son discours permettant de mieux saisir les enjeux d’EC2 pour l’entreprise.

Questionné au sujet des perspectives de résolutions des différents problèmes qu’il a pu décrire, Chris Richardson nous a fait remarquer que SpringSource était dans une situation confortable pour s’y attaquer puisqu’ils comptent dans leurs rangs des commiteurs Apache et Tomcat. Ainsi, on peut se laisser aller à imaginer un ensemble d’adaptations de mod_proxy ou de Tomcat pour mieux supporter l’infrastructure dynamique particulière d’EC2.

Publié par

Publié par Michaël Figuière

Michaël est consultant chez Xebia où il intervient notamment sur des sites Web à fort trafic. A son aise tant avec les environnements JEE qu'avec les technologies de plus bas niveau, il est spécialisé dans les architectures distribuées et les technologies innovantes telles que NoSQL, les moteurs de recherche, ou encore le data mining.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.