Archives de
Catégorie : Présentation des services

Bien débuter avec Amazon EC2 Container Service (101) – ECR

Bien débuter avec Amazon EC2 Container Service (101) – ECR

Docker est une technologie qui fait grand bruit depuis plusieurs années maintenant dans le domaine de l’IT.

docker-vs-aws
AWS vs docker in google search

Tous les grands cloud publics (Amazon Web Service, Google Cloud, Microsoft Azure) proposent une solution plus ou moins intégrée pour la gestion des containers. Dans ces articles nous allons vous expliquer comment débuter avec succès sur le service managé Amazon EC2 Container Service.

Cette série d’articles suppose que vous avez créé un VPC où seront créé les instances hôtes pour les containers docker, que la CLI AWS est installée sur votre poste et nous utiliserons une image “Hello-world” (dockercloud/hello-world) disponible sur le docker hub.

1 – Création du dépôt Docker Privé (ECR)

Pour être déployé, une image de container doit être mis à disposition dans un dépôt docker.
Plusieurs solutions sont disponibles, Amazon Web services (AWS) nous propose un dépôt privé managé (ECR) à un tarif intéressant (0,1$/Go/mois au 01/08/2017).

Pour déployer notre image sur ECR ( Amazon EC2 Container Registry ) nous allons tout d’abord récupérer cette image sur le docker hub.

Maintenant que nous avons notre image, nous allons la déposer sur ECR
Nous allons nous connecter à la console web aws pour ecs.

1a – Si vous n’avez pas encore utilisé le service

  • vous allez tomber sur la page “get Started”, il vous suffira alors de cliquer sur le bouton bleu “getStarted” au milieu de la page.
  • Sur l’écran suivant (Getting Started with Amazon EC2 Container Service), décocher la case pour ne pas déployer la demo ECS (sample)
Getting Started with ECS
Getting Started with ECS

1b – Si vous avez déjà utilisé ECS

Il suffit de cliquer sur “Repositories” puis sur “Create Repository”

2 – Sur la page suivante

vous allez pouvoir donner un nom à votre dépôt, helloworld dans notre cas. Puis l’on passe à l’étape suivante (Next step)

ecr-name

3 – La dernière page

elle nous donne toutes les indications pour utiliser le dépôt qui vient d’être créé.

2 – Ajout d’une image sur ECR

Nous allons déposer notre image HelloWorld sur le dépôt. Pour cela nous allons nous connecter sur ECR à partir de notre machine (notre dépôt est en ireland)

Nous obtenons une ligne de commande qui va nous permettre de nous connecter à ECR

Nous sommes maintenant connectés, nous pouvons pousser l’image locale

Si vous vous connectez sur la console web AWS, vous pourrez voir votre image dans le dépôt

Docker Image in ECR repository
Docker Image in ECR repository

Dans le prochain article nous allons utiliser cette image pour lancer un container docker sur ECS.

@ Très bientôt

Le SLA chez Amazon Web Services #AWS

Le SLA chez Amazon Web Services #AWS

Chez Corexpert, nos clients nous posent souvent cette question :

« On nous parle toujours de Haute Disponibilité et Très Haute Disponibilité chez AWS, mais s’engagent-ils vraiment ? Existe-t-il un SLA ? »

 

Qu’est ce que le SLA ?

Le SLA, ou Service Level Agreement, est le niveau de qualité et de performance contractuel d’un service ou d’une infrastructure technique. Dans le cas de AWS, fournisseur Cloud, on parlera donc bien d’un service, vue qu’on évolue dans le monde IaaS – Infrastructure as a Service !

Le SLA doit cadrer en premier lieu de quelle fourniture nous parlons, et les critères de performances sur lesquels le fournisseur va s’engager. On pourra donc parler de temps de réponse, de fonctionnalité assurée, de disponibilité complète du service etc.

SLA chez AWS

Nous allons parcourir ci-dessous les principaux services, ou services majeurs de l’offre AWS, qui possèdent un SLA à la date de rédaction de cet article. Bien évidemment la liste est non exhaustive.

Amazon Route 53 : SLA du DNS AWS

Le service DNS de AWS, Amazon Route 53, possède un SLA de disponibilité du service du niveau le plus haut possible. En effet on a ici un engagement de disponibilité de 100% sur le service, ce qui est explicité par « Amazon Route 53 n’échouera pas pour répondre à vos requêtes DNS dans le cycle de facturation d’un mois ». Pourquoi parler d’un mois ? Car AWS, s’engage, en cas d’éventuelle défaillance avérée, de vous rembourser sous forme de crédits sur ce cycle de facturation.

sla-amazon-route-53

Extrait de la page SLA – Amazon Route 53 au 29 décembre 2016

Amazon EC2 ou Elastic Cloud Compute : SLA des VM AWS

Service principal de AWS, Amazon EC2 et Amazon EBS fournissent respectivement l’hyperviseur managé pour executer vos Machines Virtuelles, aka instances EC2 et le stockage virtualisé Amazon Elastic Block Store.

Le SLA de ces services, avec l’engagement de Amazon Web Services, est d’au moins 99.95% mensuel. Soient moins de 22 minutes.

Si une indisponibilité était avérée entre 99.95 et 99.0%, AWS s’engage à effectuer une remise de 10% en crédits AWS sur le service EC2, en deça de 99.0% de disponibilité AWS proposera une remise de 30% en crédits.

Il est important de noter que le SLA est lié à l’état « Region Unavailable« . Si vous ne le savez pas déjà, une région est l’ensemble de plusieurs zones (2+) de disponibilités, mais dans le cadre du SLA, AWS précise que l’état « Région indisponible » vous concerne si plus d’une zone de disponibilité où vous exécutez des instances EC2 est indisponible, comprendre les instances n’ont plus accès à Internet.

L’insdisponibilité de EBS, est si vos volumes de stockage ne génèrent plus d’I/O alors que la file d’attente n’est pas vide.

Amazon RDS, SLA des bases de données managées AWS

Amazon RDS est le service de Base de données managée par AWS, il supporte à ce jour MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, AuroraDB. Mais le SLA proposé par AWS, concerne uniquement les instances Multi-AZ (c’est à dire avec un serveur en Stand-By mode dans une autre zone de disponibilité) des moteurs SQL : Oracle, MariaDB, MySQL & PostgreSQL. Ce SLA est de 99.95% de disponibilité du service. L’indisponibilité est avérée quand toutes les requêtes de connection échouent pendant une minute sur l’instance RDS
multi-AZ.

sla-amazon-rds

Engagement de AWS et remboursement en crédits au 29 décembre 2016

Amazon S3, SLA du stockage AWS

Amazon S3 est le service de stockage d’objets, il est l’un des plus anciens services de AWS, et possède une durabilité des données de 99.999999999% en mode de stockage standard. Toutefois le SLA, concerne la disponibilité d’accès à la données stockée via l’API AWS. Le SLA de Amazon S3 est donc calculé sur le comptage d’erreurs ou d’indisponibilité de l’API sur 5 minutes.

L’engagement de AWS est de conserver une disponibilité au-delà de 99.9% mensuel, ce qui représente moins de 43 minutes 36 secondes.

Si AWS ne peut assurer cette disponibilité sur la région où est stocké votre bucket S3, alors 10% de remise sur le coût de stockage S3 seront reversés en crédits, et en deça de 99.0%, alors la remise en crédit s’élèvera à 25% du coût du service Amazon S3.

Amazon CloudFront, SLA du CDN AWS

Amazon Cloudfront est le service CDN de AWS, avec plusieurs dizaines de « Edge Locations », ce service met en cache les requêtes web selon vos comportements et pattern d’URLs choisis. Il permet des diffusions et donc des chargements de données accélérés sur les sites web et applications mobile, notamment lorsque du contenu media transite.

AWS s’engage à maintenir une disponibilité globale du service au-dessus de 99.9% mensuel (identique à Amazon S3). Les remises effectués sur le service, en cas de défaillance avérée, également basé sur la fréquence des erreurs d’accès aux données sont identiques à celles de Amazon S3.

AWS Shield, SLA du service de protection anti-DDoS

Récemment lancé lors du re:Invent 2016, AWS Shield est l’officialisation de la protection anti DDoS de AWS. Le service utilise et protège les autres services Amazon CloudFront et Amazon Route 53, et son SLA, ramené sur des périodes de 24 heures, est lié directement aux SLA des produits cités précédemment. On pourra donc traduire ce SLA, par un simple rappel que l’utilisation du service AWS Shield devant Amazon CloudFront ou Amazon Route 53 ne modifie pas leur SLA.

Synthèse des SLA chez AWS

 

Service AWS SLA mensuel SLA minutes/mois
Amazon Route 53 100.00 % 0 seconde
Amazon EC2 99.95 % 21 minutes et 36 secondes
Amazon RDS 99.95 % 21 minutes et 36 secondes
Amazon S3 99.90 % 43 minutes et 12 secondes
Amazon CloudFront 99.90 % 43 minutes et 12 secondes
AWS Shield Cf. CloudFront ou Route 53 Cf. CloudFront ou Route 53

 

Calcul du SLA d’une infrastructure AWS

Partons d’une infrastructure Web App, relativement classique. Elle est composée de plusieurs serveurs applicatifs frontaux, ici EC2 C4.Large, le code exécuté est le même sur chaque instance, et nous avons une redondance multi-zone de disponibilités. La base de données est un MySQL sur RDS en Multi-AZ (Stand-By Instance). Les éléments statiques du sites sont stockés sur S3. CloudFront, est placé devant le Load Balancer, il met en cache les éléments statiques de S3 et reroute les autres requêtes sur le LoadBalancer. Route53 gère le nom de domaine du site.

cloudcraft-web-app

Infrastructure Web : Amazon Route 53, CloudFront, S3, EC2 et RDS

Voici comment nous pouvons calculer le SLA de cette infrastructure, bien entendu celui-ci est dans le cas d’une défaillance de tous les services AWS utilisés sur une région, et dans le cadre du SLA de chacun de ses services. Dans ce cas l’infrastructure ne peut prétendre à un SLA supérieur sans redondance supplémentaire.

  • RDS Multi-AZ MySQL : SLA de 99,95 %
  • EC2 : SLA de 99.95 %
  • CloudFront : SLA de 99.9 %
  • S3 : SLA de 99.9%
  • Route 53 : 100.0 %

Le SLA de l’infrastructure brute sera de :

99.95% x 99.95% x 99.9% x 99.9% x 100% = 99,70 %

Si l’on considère que l’indisponibilité S3 n’est pas critique pour la conservation de la disponibilité de l’infrastructure web (par exemple une API) et qu’on gère via Route 53 l’éventuel downtime de CloudFront en pointant vers le Load Balancer en secours, nous gagnerons 0,2% de SLA juste par modification et optimisation du Design de l’infrastructure :

99.95% x 99.95% x 100% = 99,90 %

N’hésitez pas à poser vos questions ou nous contacter pour plus d’informations.

Amazon S3 – Vue détaillée du service de stockage de données d’AWS

Amazon S3 – Vue détaillée du service de stockage de données d’AWS

Pour l’ouverture de son blog, Corexpert vous propose d’analyser en détails l’ensemble des fonctionnalités du service Amazon S3 ou Simple Storage Service. Sorti en 2006 aux États-Unis (2007 en Europe), deux ans après le tout premier service SQS (Simple Queue Service), S3 est maintenant un des services les plus avancés et utilisés sur AWS.

Fonctionnalités de base

Amazon S3 va vous permettre de stocker des données sur le Cloud de manière simple et sécurisée. S3 est organisé en compartiments appelés « buckets » contenant des objets, équivalents aux fichiers et dossiers sur un système de stockage classique. S3 vient avec tous les avantages du Cloud et de l’expertise AWS en mettant l’accent sur :

  • La durabilité : les données sont stockées de manière redondante dans plusieurs data centers et sur plusieurs disques afin d’assurer une durabilité allant de 99,99% à 99,999999999% (« eleven nines ») sur une période d’un an.
  • La disponibilité : l’infrastructure mise en place derrière le service permet d’assurer une disponibilité des données allant de 99,9% à 99,99% (hors Glacier) sur une période d’un an.
  • La sécurité : le service offre par défaut des mécanismes de sécurité flexibles permettant de protéger vos données en fonction de vos besoins.
  • La latence : en plus de sa haute disponibilité, le service permet d’accéder aux données avec la latence le plus faible et stable possible.

Afin de lire ou écrire sur S3, un panel de commandes est mis à disposition pour réaliser des opérations sur les objets. On peut notamment citer les plus connues :

  • GET, pour la récupération
  • PUT, pour la création et la modification
  • DELETE, pour la suppression

Pour les opérations de création de nouveaux objets, le service assure la lecture de la donnée après son écriture. Par contre pour les opérations de modification et suppression, la cohérence des données est assurée à terme (quelques secondes), contrainte dû à la redondance des données. Les interactions avec S3 se font à partir de l’interface Web (site principal d’AWS), le CLI (interface de commandes) et le SDK (intégré dans un programme).

Fonctionnalités avancées

Classes de stockage

S3 offre plusieurs types de stockage (appelés « classes ») en fonction de la taille et de l’utilisation des données qui vont permettre d’optimiser vos coûts drastiquement.

  • La classe « Standard » est attribuée par défaut lors de la création d’un objet. Elle répond aux 99,999999999% de durabilité et 99,99% de disponibilité sur les données et est adéquat pour une utilisation fréquente des données stockées sur S3.
  • La classe « Standard – Infrequent Access » est destinée au stockage des données dites « froides » c’est-à-dire moins utilisées. Les coûts de stockage seront réduis par contre les coûts d’accès se verront augmentés. La disponibilité des données est 99,9% pour cette classe.
  • La classe « Reduced Redundancy » est optimale pour des données non cruciales et/ou reproductibles. Le service réduit la redondance des données pour des coûts plus bas les utilisateurs. La durabilité se voit donc réduite à 99,99%.
  • La classe « Glacier » est parfaite pour l’archivage des données. Le coût de stockage est très faible au dépend de la disponibilité des données. Il faudra attendre plusieurs heures avant de pouvoir accéder aux données.

Sécurité

S3 fournit de nombreux outils afin d’assurer la sécurité des données à tout moment :

  • La communication avec S3 utilise le protocole sécurisé HTTPS.
  • L’accès aux données est restreint par défaut. Il existe plusieurs moyens de gérer ces accès :
    • IAM (Identity and Access Management) : le service AWS qui permet de gérer des utilisateurs et rôles attribuables à des ressources (machine EC2, fonction Lambda, etc).
    • ACL (Access Control List) : des règles d’accès aux buckets et objets S3 au format XML.
    • Chaînes de requête (« token ») : droits d’accès temporaires à un bucket ou objet S3 sous la forme d’un token qu’il faudra ajouter à la requête.
    • Politiques de buckets : règles définis au niveau du bucket permettant de partager simplement le contenu du bucket.
  • Le chiffrement des données peut se faire de différentes manières :
    • Au moment du chargement ou sur les objets stockés sur S3, il est possible de spécifier une option de chiffrage « managé » où AWS va chiffrer vos données avant de les stocker dans leur data centers et les déchiffrer à la volée lors de l’accès à la donnée. De plus, AWS s’occupe de la génération et du stockage des clés de chiffrage pour vous.
    • Il est aussi possible de spécifier l’option de chiffrage et de fournir ses propres clés de chiffrage. Vous pouvez spécifier des clés que vous avez générées vous-même et il est désormais de votre responsabilité de stocker les clés de manière sécurisée. Ou alors vous pouvez obtenir des clés via le service AWS KMS (Key Management Service) qui vous offre la possibilité de gérer vos clés sur le Cloud et de les utiliser avec d’autres services AWS.
    • Bien évidemment, vous pouvez toujours chiffrer vos données avant de les charger sur S3 en utilisant des clés que vous avez générées ou des clés provenant de KMS.
  • La protection de la suppression par MFA (Multi-Factor Authentication) est un outil pratique et efficace pour éviter la perte de données due à une fausse manipulation ou à des droits d’accès pas assez restrictifs.
  • Le contrôle de version permet d’ajouter un niveau supplémentaire de sécurité. En effet cette option, une fois activée, va permettre de garder toutes les versions d’un objet et donc de protéger vos données contre la suppression involontaire. Les accès aux fichiers répondront avec la dernière version de l’objet et le coût de stockage s’appliquera à toutes les versions stockées.

Les cycles de vie des objets S3

Imaginez que vous avez un site Web de partage de vidéos entre amis et que ce dernier fait un carton. Vous allez donc stocker toutes ces vidéos sur S3 et grâce à son caractère hautement évolutif, vous ne rencontrerai pas de problèmes en terme de limite de stockage. Toutes les vidéos seront stockées dans la classe de stockage Standard répondant aux besoins de l’application. Vos coûts de stockage seront donc linéaires au nombre de vidéos chargées. Est-ce qu’il n’y aurait pas la possibilité d’optimiser ces coûts de manière automatisée ?

S3 permet de migrer automatiquement les objets dans d’autres classes de stockage en fonction de l’ancienneté des données. En effet, vous remarquerez que les utilisateurs de votre application de partage de vidéos en ajoutent fréquemment et en général uniquement les dernières vidéos partagées sont visionnées par vos amis ou font le « buzz ».

En quelques clics vous pouvez appliquer à votre bucket S3 des règles de cycles de vie de vos objets afin de :

  • Migrer les objets vers une classe moins onéreuse en stockage pour les données vieillissantes (quelques mois)
  • Migrer les objets vers un archivage long terme pour les données anciennes (plusieurs années ou considérées comme supprimées)
  • Prévoir une suppression automatique pour le très long terme
  • Gérer l’archivage des versions (si activée) de vos objets pour réduire leur coût

Voici un exemple d’activation de règles de cycle de vie sur un bucket à travers l’interface Web d’AWS :

Les notifications d’événements

S3 propose une fonctionnalité très intéressante pour les développeurs : les notifications d’événements. Lorsqu’une opération est réalisée sur un objet (chargement, suppression, etc) S3 est capable de notifier cette opération vers d’autres services AWS :

  • Amazon SNS (Simple Notification Service) : le service permettant d’envoyer des notifications « push » rapidement et de manière évolutive. En intégrant avec les notifications de suppression de S3, on peut par exemple recevoir par email un détail des fichiers importants supprimés.
  • Amazon SQS (Simple Queue Service) : le service de file d’attente permettant de stocker des messages de manière centralisée et de les lire par d’autres applications. On peut imaginer une application de conversion d’images, qui, au chargement de nouvelles images dans S3, insère le nom des objets S3 dans la file d’attente. Cette dernière est ensuite consommée par des machines responsables de la conversion des images.
  • AWS Lambda : le service permettant d’exécuter du code « sans serveur », l’infrastructure derrière est gérée par AWS. Très pratique pour des prototypes ou des micro services.

Et plus encore

En plus des fonctionnalités citées précédemment, S3 offre d’autres possibilités répondant à des problématiques plus précises, on peut notamment citer :

  • Hébergement de sites Web statiques
  • Point de terminaison VPC (Virtual Private Cloud)
  • Journaux d’audit
  • Réplication entre régions
  • Surveillance et contrôle des coûts
  • Transfert de grandes quantités de données
  • Chargement sur S3 en plusieurs parties
  • Accélération du transfert des données

Tarification

Comme pour la majorité des services proposés par AWS, la tarification d’Amazon S3 est basée sur la taille des données stockées, le nombre d’opérations et la taille des données en transit. Le détail des tarifs est disponible sur le site d’AWS. Nous vous proposons une petite exploration des tarifs à titre indicatif.

Prenons pour exemple la région Oregon, les coûts du stockage dépendra des classes utilisées (premier 1 To/mois) :

  • Standard : $0.03 par Go
  • Standard – Infrequent Access : $0.0125 par Go
  • Glacier : $0.007 par Go

Les coûts pour les opérations sur les objets S3 dépendent aussi de la classe des objets :

  • Standard
    • Créations, modifications : $0.005 par tranche de 1 000 opérations
    • Récupérations : $0.004 par tranche de 10 000 opérations
  • Standard – IA
    • Créations, modifications : $0.01 par tranche de 1 000 opérations
    • Récupérations : $0.01 par tranche de 10 000 opérations
  • Glacier
    • Archivages, restaurations : $0.05 par tranche de 1 000 demandes
    • Attention aux restaurations : 5% du stockage Glacier total gratuit par mois et $0.01 par Go au delà

Les transferts de données font aussi partie des coûts S3. Par exemple les transferts de S3 vers Internet vous couteront $0.09 par Go (premiers 10 To/mois).

Limites

Le service Amazon S3 comprend certaines limites imposées par l’infrastructure managée derrière :

  • Chaque compte est limité à 100 buckets. Il est possible d’augmenter cette limite, uniquement depuis Août 2015, en contactant le support AWS.
  • Le nom d’un bucket est unique pour tous. Il peut être judicieux de préfixer certains noms de bucket afin d’empêcher des erreurs lors de la création automatique de buckets via une application.
  • La taille maximale d’un chargement sur S3 est 5 Go.
  • La taille maximale d’un object est 5 To. Il faudra donc utiliser la fonctionnalité de chargement en plusieurs parties pour arriver à la taille maximale d’un objet.
  • Il n’y a pas de limite sur le nombre maximum d’objets que peut contenir un bucket.

Quelques astuces

Amazon S3 fait partie du niveau d’utilisation gratuit d’AWS (« Free Tier« ) en offrant à chaque nouveau compte pendant un an (par mois) :

  • 5 Go de stockage
  • 20 000 opérations GET
  • 2 000 opérations PUT
  • 15 Go transfert de données entrantes
  • 15 Go transfert de données sortantes

Concernant le chargement des objets sur S3, il est recommandé d’utiliser le chargement en plusieurs parties pour les fichiers dépassant les 100 Mo. Cette méthode comprend plusieurs avantages :

  • La parallélisation du chargement, pour une exploitation maximale de la bande passante de votre connexion Internet.
  • La mise en pause du chargement, en chargeant uniquement les parties manquantes.

Dernière astuce si vous avez de nombreuses opérations de récupération sur S3. Le service stocke les objets sous le format « clé/valeur » et répartit tous les objets sur plusieurs disques et machines. Pour optimiser la répartition des objets et donc la répartition de la charge serveur lorsque le trafic est important (au delà de 100 requêtes par seconde), il est conseillé d’ajouter une partie aléatoire au début de la clé de l’objet. Cette partie aléatoire peut être un « hash » (quelques caractères générés aléatoirement) ou, pour les clés contenant une valeur temporelle, une inversion de cette valeur temporelle (secondes puis minutes puis heures, etc).

Cas d’utilisation

Pour finir cet article, nous allons présenter quelques cas d’utilisation basés sur la puissance d’Amazon S3.

Archivage à faible coût

Aujourd’hui, les entreprises produisent beaucoup de données et il est nécessaire de pouvoir les stocker avec la meilleure durabilité et le coût le plus faible possible. S3 permet, via la gestion des cycles de vie des objets, d’archiver facilement les données non-utilisées mais qui ne doivent pas être supprimées. Pour rappel la classe de stockage Glacier propose un stockage à la hauteur de $0.007 par Go, pour une réduction des coûts maximale. À garder en tête que la récupération des données de Glacier peut être coûteuse si une grande partie des données est récupérée rapidement.

Site vitrine

S3 offre la possibilité d’héberger son site Web statique avec tous les avantages du service :

  • Durabilité des données
  • Gestion de trafic important
  • Gestion des hausses de trafic soudaines

Pour améliorer les performances du site en terme de latence, il est même possible d’utiliser le service Amazon CloudFront afin de distribuer le contenu du site dans plusieurs pays (appelé CDN, Content Delivery Network), au plus proche des utilisateurs.

Stockage de fichiers sur le Cloud

À la manière de Google Drive ou Dropbox, on pourrait créer une application grand public destinée au stockage de fichiers. Cette application serait composée des éléments suivants :

  • Une interface qui permet aux utilisateurs de se connecter et de gérer leurs fichiers : cette interface peut être un site statique hébergé sur S3 qui pourra gérer un grand nombre d’utilisateurs et des hausses de trafic soudaines.
  • Une flotte de serveurs pour gérer la logique applicative : AWS offre plusieurs services permettant d’exécuter cette logique (EC2, Lambda/API Gateway, ECS, etc).
  • Un espace de stockage pour stocker les données chiffrées : S3 est parfait pour cela, le stockage est illimité, le chiffrage des données est disponible en fonction des besoins.

Reprise de sinistre

Lorsque votre site Web est lancé et que vous avez du trafic constant, il est important de mettre en place des mécanismes pour se rapprocher du 100% de disponibilité (ou « zero downtime »). Ces mécanismes doivent comprendre une gestion des sinistres afin de pouvoir fournir le meilleur service possible à vos utilisateurs en cas de panne plus ou moins générale tout en prenant en compte les coûts.

Une stratégie peut être de dupliquer toute l’infrastructure permettant le fonctionnement du site Web (serveurs, bases de données, données statiques, etc) dans un autre data center à l’autre bout du monde (une autre région AWS). Lorsqu’une panne générale intervient sur un data center, vous pouvez rediriger tout le trafic sur l’autre. Cette stratégie (aussi appelée « multi-régions ») assure la meilleure disponibilité mais est très onéreuse (coûts d’infrastructure multipliés, synchronisation des bases de données, réplication des données S3 dans une autre région, etc).

Une autre solution plus simple, faiblement coûteuse consiste à créer une version statique du site Web, de le mettre sur S3 dans une (ou plusieurs) autre région AWS. Ainsi, lors d’une panne générale il sera possible de rediriger vos utilisateurs sur cette version simplifiée du site Web. Bien que ce mécanisme ne permet pas de maintenir toutes les fonctionnalités du site Web, celui-ci reste toujours accessible et les utilisateurs ne paniqueront pas comparé à l’affichage d’une page blanche.

Gestion des logs applicatifs

Beaucoup de services AWS permettent de rediriger leur sortie ou leurs résultats vers S3. Ce principe est notamment utilisé pour les logs applicatifs qui, toutes les 20 minutes par exemple, sont envoyés sur S3 dans le but d’y avoir accès pour analyse ou sauvegarde en cas de défaillance de serveurs.

On va pouvoir utiliser les notifications d’événements pour réaliser notre exploitation des logs et ainsi identifier et comprendre les différents problèmes que notre application pourrait avoir. En définissant une fonction AWS Lambda sur les notifications d’écriture sur S3, il sera possible de mettre en place le processus suivant :

  • Écriture du log sur S3
    • Déclenchement de la notification
  • Appel d’une fonction Lambda
    • Lecture du fichier S3
    • Insertion des lignes de logs dans une base de données
  • Exploitation des données par le développeur en agrégeant les lignes de logs

Traitements gourmands

Une autre exploitation des notifications d’événements est le traitement de gros fichiers, de vidéos, d’images qui nécessite d’exécuter en arrière-plan des tâches de conversion, d’analyse, etc. Au chargement de ces fichiers sur S3, il est possible d’enregistrer ces notifications dans une file d’attente SQS et de les traiter ensuite. Sur des opérations d’analyse d’image ou d’agrégation de données, on va pouvoir créer une flotte de serveurs capable de consommer cette file d’attente, de réaliser les traitements nécessaires et de gérer la taille de la flotte en fonction de la taille de la file d’attente (toujours d’en l’optique d’optimiser les coûts en fonction des besoins).

En espérant vous avoir donné envie de réaliser votre prochaine application avec Amazon S3 et d’autres services AWS. Pour plus d’informations et discuter autour d’AWS, nous serons au AWSome Day à Lyon le 11 octobre : un jour de formation gratuite sur le Cloud AWS et la possibilité de rencontrer des AWS Solutions Architects certifiés.