Archives de
Auteur : corexpert

Conjuguer les services Run Command et Auto Scaling Group

Conjuguer les services Run Command et Auto Scaling Group

Une commande à lancer sur la centaine de machines de votre Auto-Scaling Group ? Rien de plus facile avec le « Systems Manager Run Command » !

Configuration des droits

Les instances cibles doivent avoir un rôle contenant la policy AmazonEC2RoleforSSM.

iam-policy-ssm

L’utilisateur lançant les commandes doit avoir la policy AmazonSSMFullAccess.

 

Installation de l’agent sur les instances

L’agent est responsable de l’exécution de la commande. Sur les instances Windows, il est déjà installé. Pour Linux, il faut l’installer manuellement : soit en se connectant à l’instance et en lançant les commandes, soit via les user data (à utiliser pour l’Auto-Scaling Group).

Toutes les commandes d’installation de l’agent sont disponibles dans la page de documentation « Installing SSM Agent ».

Exemple de launch configuration avec une instance Amazon Linux AMI:

launch-configuration

 

Identification des instances

Les instances de l’Auto-Scaling Group doivent être identifiables par un tag dont la key/value est spécifique à celui-ci.

autoscalinggroup-tag

 

Lancement d’une commande depuis la console

Dans le menu de l’interface EC2, aller dans « Systems Manager Services » -> « Run command » et cliquer sur le bouton « Run command ».

goto-runcommand

Remplir le formulaire avec les informations suivantes :

  • Command document : sélectionner « AWS-RunShellScript »
  • Select targets by : sélectionner « Specifiying a Tag » et entrer le tag de l’auto scaling group

select-targets-by-tag

  • Commands : entrer « ps -aux »

Appuyer sur le bouton « Run » en bas à droite.

Vous pouvez alors suivre l’état d’avancement de la commande :

run-command-table

Le résultat de la commande est accessible via l’onglet « Output »:

run-command-output

 

Lancement d’une commande depuis AWS CLI

A la fin du formulaire précédent, un cadre donne la commande AWS CLI équivalente :

cli-from-form

 

Il est alors possible d’intégrer cette commande dans un scheduler afin de lancer des commandes de maintenance telles qu’un vidage de cache.

 


Sources :

AWS & COREXPERT organisent le 1er AWS DevDay en France

AWS & COREXPERT organisent le 1er AWS DevDay en France

Le 27 avril prochain et pour la première fois en France, Amazon Web Services en partenariat avec COREXPERT, organise un événement incontournable du Cloud à Lyon :

L’ AWS DevDay


Après San Francisco, Austin, Munich, il s’agira du lieu parfait pour les profils techniques souhaitant perfectionner leurs connaissances sur le Cloud AWS.

Evénement gratuit et situé à La Tour du Web, vous pourrez en apprendre plus sur les annonces récentes du Cloud Computing grâce à l’intervention de deux Solutions Architects AWS, et celle de Julien Simon, AWS Principal Technical Evangelist.

COREXPERT est un partenaire privilégié du Cloud Public Amazon Web Services. A travers ses deux business units : Cloud Native Apps & Cloud Infrastructure, l’équipe d’architectes et développeurs certifiés AWS joue un rôle essentiel dans la transformation digitale cloud de la PME aux Multinationales.

awsome-day-event

Vous pourrez compléter vos connaissances avec l’équipe technique de AWS et celle de Corexpert, qui auront le plaisir de vous conseiller sur les bonnes pratiques et les outils incontournables de la plateforme.

sinscrire-gratuitement

La journée


Celle-ci sera rythmée par des démonstrations en live, et des temps d’échanges dédiés à vos questions, sur vos problématiques.

La journée débutera avec La bataille des Big Data, une session où nous verrons comment Redshift, Athena, Spark et Hive se comportent face à un gros dataset. Qui sera le plus rapide ? Le plus efficace en terme de coûts ? Le plus simple d’utilisation ? Assistez à cette session, votez en direct pour votre favori et découvrez les résultats avec nous !

Next up : A 60 minutes tour of AWS ComputeAvec plus de 10 familles d’instances, Elastic Beanstalk, ECS et Lambda, le choix peut vite s’avérer difficile. Dans cette session, nous verrons donc en une heure quelle solution convient le mieux à chaque cas de figure.

L’après-midi, nous nous répartirons en 3 groupes, chacun abordant un sujet différent. Rejoignez un groupe, puis un autre, libre à vous de composer votre après-midi telle que vous la concevez ! Vous pourrez également proposer des sujets pendant la pause déjeuner.

Voir l’agenda de la journée ]

Cet événement AWS à l’initiative et sponsorisé par COREXPERT

aws-advanced

COREXPERT : AWS Advanced Consulting Partner

COREXPERT profite d’une expertise de plus de 7 ans dans l’exploitation des services managés AWS, à la fois dans le développement applicatif (Web, SaaS, etc.) et la gestion de la croissance d’infrastructures.

L’équipe comptabilise plus d’une dizaine de certifications AWS, qui ont validé l’expérience acquise et les nombreux projets déployés sur la plateforme Cloud leader mondial.
Partenaire depuis 2014, l’un des premiers en région, COREXPERT a rejoint peu de temps après le réseau de distribution AWS Channel Reseller et reçu le label Consulting Partner. Le réseau de partenaires AWS (Amazon Partner Network) est un programme de partenariat proposé par AWS qui évalue la capacité de ses partenaires à accompagner les clients vers les bonnes pratiques et la meilleure exploitation de la plateforme Cloud. De plus, il confirme les compétences (certifications, accréditations) des équipes techniques.

En développant son expertise des services AWS et son engagement, COREXPERT a accédé début février au niveau APN supérieur : Advanced Consulting Partner, une étape importante dans sa croissance et son partenariat.

Ce niveau de partenariat avec Amazon Web Services est le fruit du travail de nos architectes et développeurs qui accompagnent nos clients, vos projets, dans la conception, le déploiement ou la migration et l’exploitation des infrastructures & applications sur AWS.

Acteur incontournable des quarts sud-est et sud-ouest, COREXPERT accompagne également ses clients sur toute la métropole et à l’international.

Partenariat : ORINOX choisit COREXPERT et Amazon Web Services pour propulser OCWS

Partenariat : ORINOX choisit COREXPERT et Amazon Web Services pour propulser OCWS

Dans le cadre du développement de sa plateforme cloud de services dédiée à la digitalisation de site industriel nommée OCWS (Orinox Cloud Web Services), ORINOX s’appuie sur COREXPERT, afin de s’assurer que sa solution répondra aux exigences les plus élevées en termes de sécurité, contrôle et scalabilité.

logo-orinox-xs

AWS Consulting Partner, COREXPERT est un partenaire privilégié du Cloud Public Amazon Web Services. Au travers de ses deux business units Cloud Native Apps et Cloud Infrastructure, ses architectes et développeurs certifiés AWS apportent leur expertise à tous types de projets IT s’appuyant sur le cloud AWS.

COREXPERT profite d’une expertise de plus de 6 ans dans l’exploitation des services managés AWS, à la fois dans le développement applicatif (Web, SaaS, 3D, etc.) et la gestion de la croissance d’infrastructures.

Il s’agit d’une étape nécessaire pour la migration d’OCWS sur la plateforme AWS afin de répondre au besoin de clients industriels globaux.

aws_logo_advanced_consulting_partner

En travaillant avec COREXPERT et AWS, ORINOX bénéficie pour la mise en place de cette offre de l’expérience et de la présence à l’échelle mondiale de spécialistes des services Cloud.

A son terme, le but de cette opération est de faire bénéficier chaque industriel et chaque ingénierie de l’expertise d’ORINOX pour assurer la digitalisation d’installation complexe, avec la facilité des solutions Cloud en terme de déploiement et de maintenance du Digital Asset, ainsi que l’accès à l’ensemble du portfolio des solutions AVEVA & LFM. Pour nos clients, cette solution permettra un accès à l’information transformée et simplifiée, tout en renforçant la sécurité de ces données très sensibles.

Cette offre complètera l’offre globale d’Orinox qui accompagne depuis déjà plus de 8 ans les industriels dans leur transition numérique via le déploiement des solutions AVEVA à l’échelle mondiale.

min_orinox_-_aveva_global_registered_services_partner

En effet, ORINOX est depuis 2016 l’un des tout premier AVEVA Registered Services Partner.

Nous nous engageons, par la digitalisation, à :

  • Réduire les temps de conception, d’achat et de réalisation de projet ;
  • Simplifier la transmission de dossier d’ouvrage exécuté ;
  • Assurer l’accès à l’information technique des projets ;
  • Améliorer la formation des opérateurs ainsi que l’accès et la flexibilité des formations ;
  • Limiter le risque industriel ;
  • Réduire les couts de production et maintenance des installations.

ORINOX est à votre écoute pour parler de vos projets et pour tout diagnostic. Vous pouvez les contacter ici : contact@orinox.com.

http://www.orinox.com/fr/societe/actualites-orinox/755-01-2017-partenariat-ocws-corexpert-amazon-aws

http://www.orinox.com/en/company/orinox-news/756-01-2017-partnership-ocws-corexpert-amazon-aws

Des statistiques en temps réel grâce à Corexpert et AWS

Des statistiques en temps réel grâce à Corexpert et AWS

Startup spécialisée dans l’advertising mobile, la plateforme en ligne de Vidcoin gère chaque jour plusieurs centaines de millions d’appels sur ses infrastructures cloud, en mettant en relation des utilisateurs d’applications et des annonceurs. Jeune et dynamique, la startup française à toujours su se démarquer par sa réactivité.

Le besoin

Pour devenir la référence en réactivité de leur secteur, Vidcoin a pu s’appuyer sur différentes statistiques de diffusion avec des délais de disponibilité réduits (moins d’une heure). Avec l’évolution de leur activité et l’accroissement de la concurrence, il a fallu mettre en place de nouveaux outils, avec l’objectif du temps réel. La multiplication du nombre de valeurs à mesurer (métrique), combinée aux nombreuses dimensions possibles a obligé Corexpert à imaginer une solution générique, et suffisamment flexible pour évoluer facilement avec les besoins métier de Vidcoin.

L’existant

Des millions d’événements sont envoyés par les applications clientes et les partenaires publicitaires. Un outil simplifié de statistiques en temps réel est déjà en place, qui permet de suivre quatre combinaisons définies de métrique x dimension.

Le défi

Le challenge de Corexpert est de mettre en place un système capable de supporter la forte volumétrie de Vidcoin, tout en permettant de faire évoluer les différentes visualisations en fonction des besoins métier. La flexibilité et la capacité de montée en charge sont essentielles afin de suivre l’évolution permanente de la startup.

La solution

Après une étude des outils existants, Amazon Elasticsearch Service est apparu comme l’outil idéal. La simplicité de mise en place et de sécurisation du service sont ses principaux atouts. Les objectifs principaux lors de la création de l’infrastructure sont d’assurer une montée en charge élevée, tout en minimisant les temps de maintenance nécessaires et en conservant un niveau de sécurité élevé. Il a été décidé de s’appuyer sur les services Amazon Kinesis et AWS Lambda pour récolter et envoyer les évènements collectés dans ElasticSearch. Ces services permettent de faire transiter les différents événements au sein de la plateforme AWS, tout en conservant une infrastructure découplée et orientée micro-services : donc très flexible.

Le plugin Kibana permet une visualisation par le biais de tableaux de bords simplifiés. Il est installé par défaut, ce qui réduit le volume de développements ou temps de mise en place nécessaires.

vidcoin-use-case-aws-lambda-elasticsearch

Pourquoi ElasticSearch

AWS permet l’utilisation de la solution open-source ElasticSearch de manière managée. Grâce à ce service, il est possible d’administrer, augmenter la taille du cluster et sécuriser la solution ElasticSearch de manière simplifiée et efficace. Plutôt qu’une infrastructure qui aurait demandé un investissement important en administration pour assurer un haut niveau de disponibilité et de sécurité, il n’a fallu que quelques heures pour mettre en place en production la solution ElasticSearch, sans aucun risque pour le client car totalement découplée du reste de l’infrastructure technique.

Le résultat

Grâce à cette solution, Vidcoin peut visualiser l’ensemble de ses statistiques détaillées en temps réel et à tout moment. Les tableaux de bord évoluent au fur et à mesure de leurs besoins sans développement additionnel.

Les tableaux de bord Kibana, intégrés au back-office interne de Vidcoin, sont très rapidement devenus des outils incontournables, utilisés quotidiennement dans le pilotage de l’activité opérationnelle de la start-up.

aymeric_roffe_photo

Dans notre industrie, il faut en moyenne plusieurs heures pour pouvoir détecter un problème et le résoudre.
Grâce à ces dashboards, nous sommes en mesure de réagir en temps réel à n’importe quelle situation, sans contrainte, et apporter des solutions à nos clients.
Aymeric Roffe – Co-founder & CTO @Vidcoin

realtime-analytics-aws-corexpert

Le cloud public n’est pas infaillible, vous en doutiez ?

Le cloud public n’est pas infaillible, vous en doutiez ?

Cette douce nuit du 28 février au 1er mars 2017 a tenu éveillés beaucoup d’européens, le service S3 de Amazon Web Services a connu une indisponibilité de plusieurs heures dans la région historique us-east-1 situé en Virginie (USA). Mais pourquoi de grands noms du web se trouvent autant impactés ? Ces grands du web, Trello, Slack, etc. valorisés à plusieurs millions voire milliards auraient-ils un bad-design d’infrastructure ?

Lire la suite Lire la suite

Le SLA chez Amazon Web Services #AWS

Le SLA chez Amazon Web Services #AWS

Cet article a été mis à jour en janvier 2019 avec les modifications du SLA fourni par AWS. Les compléments d’information ont été intégrés directement dans l’article d’origine.

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 a été étendu à Amazon Elastic Container Service (ECS) et AWS Fargate (deux services ayant traits aux conteneurs Docker) depuis 2018].

Le SLA des 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. [La période d’indisponibilité est maintenant de 90.0% à 99.99% depuis 2018 pour la remise de 10% de crédit AWS.]

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’indisponibilité de EBS est avérée lorsque les volumes de stockage ne génèrent plus d’I/O avec une file d’attente non 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 pour RDS et remboursement en crédits au 10 janvier 2019

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.

[Depuis janvier 2019, ces règles ont été étendues à Amazon Elastic File System (EFS) avec les mêmes engagements que pour S3. Amazon EFS est un système de stockage de fichiers simple managé (AWS gère l’infrastructure pour vous).]

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ées 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

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.

Amazon API Gateway, SLA sur la gestion des API

Depuis janvier 2019, AWS s’engage à assurer une disponibilité de 99.95% mensuel du service Amazon API Gateway. Ce service entièrement managé facilite la gestion, la surveillance et la sécurité des API de n’importe quelle taille. En cas de rupture du service, le crédit alloué est identique à ceux de RDS : 10% de remise entre 99.0% et 99.95% et 25% de remise pour une disponibilité mensuelle moindre à 99.0%.

Amazon EMR, SLA sur les frameworks Big Data

En janvier 2019, Amazon EMR bénéfice d’un engagement en terme de disponibilité de la part d’AWS. Les frameworks Big Data gérés par le service possède un SLA de 99.9% mensuel.

emr_sla.Engagement de AWS pour EMR et remboursement en crédits au 10 janvier 2019

Amazon Kinesis, SLA sur la gestion des données en streaming

Amazon Kinesis traite de la collecte, du traitement et de l’analse de données en streaming en temps réel. Le SLA sur lequel s’engage AWS depuis janvier 2019 touche trois composants principaux de Kinesis : Videos Streams, Data Streams et Data Firehose. L’engagement de disponibilité des services est de 99.9% mensuel avec une remise de 10% à 25% en cas d’indisponibilité.

Synthèse des SLA chez AWS

Service AWS SLA mensuel SLA minutes/mois
Amazon Route 53 100.00 % 0 seconde
Amazon EC2 99.99 % 4 minutes 30 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
AWS API Gateway
99.95 % 21 minutes et 36 secondes
Amazon EMR
99.90 % 43 minutes et 12 secondes
Amazon Kinesis
(Data / Videos Stream /
Data Firehose
99.90 % 43 minutes et 12 secondes

 

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.

Jenkins CI – Identifiants AWS

Jenkins CI – Identifiants AWS

Aujourd’hui, un petit article concernant l’automatisation et l’utilisation des services AWS depuis une instance Jenkins. AWS fournit de nombreux outils permettant l’automatisation de votre infrastructure, de vos déploiements, de vos backups, et j’en passe. On pense notamment au AWS CLI, AWS SDK et AWS CloudFormation. Cependant, il est nécessaire de contrôler la façon dont vous vous identifiez pour utiliser ces outils, par exemple vous pouvez avoir besoin de vous identifier sur plusieurs comptes AWS ou encore gérer différents droits en fonction du type d’environnement.

Tout d’abord, il faut vous munir d’identifiants AWS, liés à un utilisateur qu’il faudra créer :

add_user

Ensuite, rendez-vous sur votre instance Jenkins (si vous n’en avez pas encore, je vous conseille de suivre ce tutoriel). Jenkins permet de centraliser tous vos identifiants nécessaires pour les appels à tous les services externes dont vous avez besoin (Git, SSH, AWS, etc). Afin d’ajouter des identifiants AWS dans ce « Credentials Manager », il faut au préalable installer le CloudBees AWS Credentials Plugin. Il est maintenant possible d’ajouter les identifiants de notre utilisateur AWS :aws_credentials

Vous avez enfin vos identifiants AWS managés par Jenkins. Il ne reste plus qu’à les utiliser dans vos jobs. Pour cela, il faut se rendre dans la section « Build Environment » de votre job et sélectionner l’option « Use secret text(s) or file(s) ». Ajoutez un binding « AWS access key and secret » et choisissez les identifiants de votre choix :

job_aws_credentials

Par défaut, le plugin va ajouter les variables d’environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY au runtime de votre job. Ces variables sont reconnues automatiquement par les outils AWS (CLI et SDK) et vous permettront de réaliser les actions de votre choix sur votre compte AWS (ex : aws s3api list-buckets).

Si cette article vous a été utile, n’hésitez pas à commenter, le partager ou nous contacter. Plus d’articles à venir sur l’automatisation…

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.