AWS Re:Invent 2022 - Jour J-5
AWS Re:Invent 2022 - Jour J-5

AWS Re:Invent 2022 - Jour J-5

Ça y est… Le AWS Re:Invent 2022 ça se termine ce midi… 😌 5 jours intenses de sessions, keynotes, workshops, rencontres. On rentre la tête remplie de nouveautés qu’il nous restera à considérer et implémenter sur nos travaux dès notre retour. 🙂

Jour 5

Journée allégée puisque que seul la matinée est encore ouverte sur le Re:Invent. Il n’y avait pas un choix phénoménal de sessions sur cette demi-journée. Nous avons choisi de suivre Building modern data architectures on AWS ainsi que la session Building containers for AWS.

Ces 2 sessions sont des Breakout Sessions de niveau 300. Donc pas trop violent, mais tout de même intéressant et plein de bons rappels sur les bonnes pratiques des sujets évoqués.

Sessions

Building modern data architectures on AWS. Cette session permet de voir le paysage des technologies AWS qui se concentre sur la donnée. Elle permet aussi d’appréhender les architectures Data autant que de voir les bonnes pratiques y afférentes.

Les 6 couches, pour efficacement utiliser la donnée, qui sont proposées par AWS (et pas seulement AWS) sont :

Ingestion
Storage
Cataloging
Processing
Consumption
Security & Governance

Chacune de ces couches doit être indépendante des autres en termes de ressource consommée sur AWS afin de pouvoir les faire évoluer indépendamment.

Par la suite, des architectures type Data sont présentées :

  • Un modèle d’architecture AWS générale qui met en avant de couplage lâche (pas seulement pour la Data) (APIGateway, StepFunctions, Lambda, RDS, DynamoDB, OpenSearch).
  • Un modèle d’architecture AWS pour l’Analytic basé sur DMS, DataSync, Kinesis, MSK, AppFlow, S3, Lake Formation, Glue, EMR, QuickSight, Redshift, Athena, SageMaker et les services de AI/ML.
  • Un modèle d’architecture AWS pour la Data Streamée basé sur IoT Core, Kinesis Agent, SDK, MSK Connect, DMS, Kinesis Data Stream, MSK, Kinesis Analytic, EMR, Lambda, Glue, Kinesis Firehose, S3, Redshift, OpenSearch avec en termes de finalité des processus automatisé de la donnée afin de monitorer, prendre des décisions, alerter.
  • Un modèle d’architecture pour l’Analytic Opérationnel basé des producteurs de logs de toute sorte, de collecteurs tels que Kinesis Agent, Cloudwatch Agent, Beats, fluentbit, fluentd, OpenTelemetry, des Aggrégateurs tels que Kinesis Data Firehose, MSK, S3, Logstash, Data Prepper, OpenSearch, OpenSearch Dashboards.
  • Un modèle d’architecture BI basé sur S3, Lake Formation, DMS, Redshift, Athena, EMR, QucikSight.
  • Un modèle bout-en-bout de ML via SageMaker qui embarque des services tels que APIGateway, Cognito, Fargate, ECS, S3, EvenBridge, SageMaker, StepFunctions, CodeDeploy, CodeBuild.
  • Un modèle d’architecture de recommandation en temps-réel basé sur APIGateway, Lambda, Kinesis Data Streams, Kinesis Data Firehose, S3, Personalize.
  • Un modèle de Détection de Fraude basé sur EventBridge, Lambda, MSK, Kinesis Data Analytics, Fraud Detector, MSK, SNS, OpenSearch.
  • Un modèle d’architecture event-driven pour des sondes d’IoT basé sur IoT Core, IoT SiteWise, Kinesis Data Streams, Kinesis Data Analytic, Redshift, S3, Lambda, SageMaker, OpenSearch.

Suite à la présentation de ces modèles, un ensemble de bonnes pratiques et points clés sont évoqués.

  1. Il faut se concentrer sur la Data Discovery en première étape.
  2. Il faut définir la valeur business de la donnée et identifié les personnes en charge d’en retirer un bénéfice.
  3. Migré et moderniser ses bases de données.
  4. Mettre en place un Data Tiering (Raw zone, Transformed Zone et Curated Zone).
  5. Jouer avec les classes de stockage S3 suivant les usages.
  6. Utiliser le service IAM sur les services AWS de manière la plus fine possible. De préférence, utiliser une fédération d’identité d’entreprise telle qu'Active Directory.
  7. Chiffrer les données at-rest et in-transit.
  8. Utiliser les contrôles d’accès fournis par Lake Formation.
  9. Stocker les données au bon format.
    10. image
  10. Ajuster la taille des fichiers. Moins de fichiers entraine moins de requête et donc moins de coût. Penser à faire des Batch de concaténation de petit fichier en plus gros fichier.
  11. Automatiser (StepFunctions, Glue, Managed Workflows) et Superviser (CloudWatch) vos pipelines de données.
  12. Utiliser les services de processing de données à bon escient.
    13. image
  13. Utiliser le bon service de Streaming.
    14. image
  14. Choisir le moteur de requête adéquat.
    15. image
  15. Savoir si un Data Mesh est bon pour vous ou si c’est overkill.
  16. Savoir si un service ML peut ou non résoudre une problématique Business.
  17. Bien évidemment, utiliser le bon outil pour faire le bon travail.

Building containers for AWS. Une excellente session de bonnes pratiques autour des Containers. De leur création, à leur déploiement, en passant par leur configuration et les outils nécessaires au bon fonctionnement des Containers. On y retrouve les concepts tels que :

  • Le Runtime qui sert d’interface entre le système et les containers.
  • Ce qu’est un Container (image index, config, layers).
  • Les Dockerfiles (fichier de configuration déterminant de manière séquentielle (top-bottom) la manière avec laquelle doit être fait le Container.
  • Les outils de fabrication des Containers (comme BuildKit).
  • Concept avancé du Layer (couches immuables de donnée référencées dans le manifest de l’image - sauf pour la couche haute en Read/Write ajoutée lors du lancement du Container).
    • image
  • L’approche Multiplatform qui permet d’entretenir un index qui référence les différentes architectures processeur des images générées. Ce processus est natif sur le client Docker.
  • Containerd qui est un superviseur de Container. Il permet d’effectuer toutes les tâches inhérentes à la gestion de Container (Build des Containers, Run des Containers, Pull images from registries…)
  • La découverte de Finch, un projet initié par AWS à la demande de ses clients qui cherchaient une solution intégrée côté client pour le lifecycle des Containers et des Images.
    • image
  • Rappel des bonnes pratiques Containers:
    • Small Images → Surface d’attaque moins importante, Déploiement plus rapide.
    • Fast Build → Go to Prod accéléré.
    • Limit Scope → Orienté “Do one thing well” qui permettra d’éviter de ramener un monolith dans son univers conteneurisé.
    • Si n’y pas de raison s’y opposant, toujours prendre des images -slim pour base du FROM dans Dockerfile.
    • Si vous utilisez des Images Container pour AWS Lambda, utilisez celles fournies par AWS (curated) si vous n’avez pas une bonne raison de ne pas le faire.
    • Héberger les images FROM dans vos propres registries (+ Docker Pull Through Cache).
    • latest images ne signifie rien et n’a pas de valeur (surtout si on n’est pas propriétaire de l’image) ! 🙂 Utilisez un tag de versionning dont une release note pourra nous dire exactement de quoi il s’agit. 
    • Utiliser du Multistage builds (pas besoin d’embarquer des tools liés au code dans l’image réceptionnant l’artefact de ce build applicatif) pour avoir des images plus petites + gagner du temps sur les Multistages parallèles…
    • Utiliser massivement des images Scratch pour des binaires statiques (Golang par exemple).
    • Combiner les instructions qui sont en relations pour réduire le nombre de layers (via &&). Moins de layer → Gestion accélérée.
    • Faire attention à l’ordonnancement des commandes dans Dockerfiles pour profiter au maximum des caches layers lors des builds subséquents. Une commande d’update d’OS change moins fréquemment que le build d’un static applicatif.
    • Utiliser l’ ENTRYPOINT plutôt que CMD pour les soucis d’overwriting.
    • Utiliser EXEC plutôt que SHELL si il n’y a pas d’obligation d’utiliser SHELL.
    • Ne pas fournir des secrets via —build-arg. Passer par BuildKit secret (ou d’autres produits intégrables).
    • Limiter le scope d’action du Container 🙂 (pas de monolithe 😛)

Liens associés :

Data Architecture : https://www.youtube.com/watch?v=vtXKSTNHCXQ Container on AWS : https://www.youtube.com/watch?v=S7JwFFZ-7_Q

https://aws.amazon.com/blogs/opensource/introducing-finch-an-open-source-client-for-container-development/

Merci pour votre lecture. Si cet article vous a plu, merci de le partager sur vos réseaux 😉

Philippe Vidal - @December 2, 2022

image

Timothée Taron - @December 2, 2022

image