CME Group accélère sa migration vers le cloud avec AWS Storage Gateway

Dans cet article, Craig Bona, directeur principal du Platform Engineering chez CME Group nous explique comment ils ont utilisé AWS Storage Gateway pour accélérer leur migration vers AWS. CME Group est un leader mondial dans la finance qui offre le plus grand éventail de produits dérivés. Ils proposent des contrats à terme et des options parmi diverses catégories d’actifs, du maïs au Bitcoin. Cette envergure implique que leurs marchés en ligne sont provisionnés par de la donnée…Et en grande quantité. S’assurer que leurs clients ont accès aux données du marché pour aviser leur gestion des risques et leur décision de trading est une priorité cruciale pour CME Group. Comme leurs anciennes technologies devenaient obsolètes et chères à maintenir, ils ont commencé à considerer des solutions cloud-native pour ces priorités et répondre à une grande question (qui est toujours pertinente) : Comment CME Group allait gérer ce volume de données ?

Pour répondre à cette question et sur leurs autres interrogations concernant la migration vers le cloud, CME Group a créé une équipe dédiée, responsable du Platform Engineering. Leur équipe de direction leur a confié l’objectif de créer une architecture robuste, sécurisée et tolérante aux pannes qui permettrait à l’organisation de faire sa transition des infrastructures on-premises vers le cloud tout en minimisant l’impact sur les projets existants des autres équipes. Dans cet article, nous aborderons comment CME Group utilise AWS Storage Gateway pour répondre à ses besoins. Nous évoquerons également l’évolution de leur architecture au fil du temps en utilisant AWS Storage Gateway.

Phase 1 : Les innovateurs

Puisque CME Group exploite déjà des datacenters, leur premier objectif était de déterminer s’ils avaient un fort besoin ou une forte demande pour des solutions cloud-native. La mise à disposition mondiale des données de marché de CME Group via leur site web public leur a donné une première opportunité pour répondre à ces interrogations. Les anciennes technologies qui étaient le socle de leur système existant ont fait face à des mises à jour coûteuses et sont devenues excessivement complexes au fil du temps. Cela a donc fait sens de les remplacer par un nouveau système plus simple. Ils doivent distribuer le traffic que ce soit du contenu statique ou de la donnée en temps réel aux utilisateurs partout dans le monde. Une solution cloud-native semblait être exactement ce qu’ils cherchaient tout en leur permettant de réduire significativement leurs coûts.

Le premier défi à relever était d’identifier et cataloguer tous les workflows vers leur site web que les équipes CME ont construits au cours des deux dernières décennies. Identifier et demander à chaque équipe de faire des changements d’outils et de procédures allaient être difficile et cela ne répondrait pas à leur objectif de ne pas impacter les autres équipes. Ils ont donc contacté leur équipe de compte AWS qui leur a présenté le service AWS Storage Gateway comme solution pour leur besoin. Storage Gateway est un service cloud hybride qui vous donne un accès on-premises à un stockage dans le cloud pratiquement illimité. Au fur et à mesure qu’ils apprenaient sur Storage Gateway, ils ont réalisé que cela résoudrait certains de leurs premières préoccupations et défis :

• Faciliter les workflows de transfert des données statiques vers leur site web. Durant le transfert de données, leur solution actuelle mettait les fichiers dans un partage de fichiers, dans un NAS (Network Attached Storage, serveur de stockage en réseau). Grâce à ce processus optimisé, ils ont rapidement mis à jour ce workflow en déplaçant leur partage de fichiers sur une File Gateway. File Gateway, un type de passerelle de AWS Storage Gateway, leur a permis de stocker et d’accéder à leurs objets dans Amazon S3 à partir d’une application NFS (Network File System, système de fichier en réseau) ou SMB (Server Message Block, partage de fichiers pour les environnements Microsoft) avec du cache en local. Leurs processus existants ont continué de fonctionner sans aucun changement dans leur application, et les fichiers étaient chargés en même temps désormais sur Amazon S3.
• Maintenir les identifiants AWS IAM de leurs utilisateurs pour autoriser les applications à écrire dans Amazon S3. Puisque Storage Gateway utilise un rôle IAM, ils n’ont plus besoin de s’occuper de façon régulière de la sécurité et de la rotation des identifiants IAM pour chaque application.
• Centraliser la gestion de nombreux contrôles de sécurité et de configurations qu’ils voulaient implémenter pour ce workflow. Plus précisément, ils ont pu configurer le bon chiffrement, la classe de stockage S3 et forcer l’application à utiliser AWS Direct Connect pour limiter l’accès uniquement au point de terminaison VPC pour S3.

Une fois ces préoccupations traitées, ils ont déployé Storage Gateway en s’appuyant sur l’architecture suivante, permettant des tests parallèles et une éventuelle migration vers leur nouveau site web.

Avec cette architecture, utiliser l’accès entre des comptes pour Amazon S3 leur a permis d’isoler davantage les éléments web des autres éléments. Le partage de la donnée a été simplifié sans pour autant avoir besoin d’un accès réseau direct à leur compte de transfert AWS. L’utilisation d’Amazon EFS comme stockage pour exposer les données à leurs utilisateurs a permis d’augmenter la vitesse et la réactivité de leur site web. Puisque Amazon EFS est élastique, il peut automatiquement se mettre à l’échelle proportionnellement à son utilisation et il respecte la structure du répertoire du système de fichiers mais également les conventions de noms de fichiers et les permissions. Il est donc facile à intégrer et se met à l’echelle en fonction des besoins du site web.

Phase 2 : Les premiers adeptes

Après le succès du premier projet, d’autres équipes chez CME sont venues avec des exigences similaires. Grâce aux premiers investissements qu’ils avaient fait sur l’automatisation et la sécurité, il était plus facile et plus rapide de travailler sur de nouvelles implémentations pour leur solution. Ils ont mis en place AWS Storage Gateway rapidement en l’automatisant sur des jeux de données spécifiques et en utilisant les permissions AWS IAM, pour ainsi les rendre accessible aux utilisateurs de ses applications en quelques minutes.

Migrer un plus grand volume de données

Le prochain cas d’usage est un bon exemple pour migrer vers le cloud en utilisant une solution de traitement de données qui dépasse les capacités disponibles on-premises. Pour satisfaire les exigences métier, ils devaient migrer des données historiques qui supportent des chargements de données quotidiens et où l’entièreté du jeu de données peut être requêté. Les jeux de données ont deux structures distinctes. Pour la première structure, il était nécessaire de transférer un petit nombre de fichiers volumineux quotidiennement et pour l’autre structure, il était nécessaire de transférer un nombre important de petits fichiers quotidiennement. Pour les fichiers volumineux, leur solution déployée avec AWS Storage Gateway a bien fonctionné pendant les tests et ils ont été capables de mettre rapidement la solution en production. Cependant, pour le grand nombre de petits fichiers (environ 1 million par jour), cela n’a pas répondu à la performance attendue due au nombre important d’appels API fait sur AWS. C’était jusqu’au lancement de AWS DataSync en Novembre 2018. DataSync est un service de transfert de données en ligne qui simplifie, automatise et accélère le déplacement de données entre des systèmes de stockage on-premises et des services de stockage AWS, mais aussi entre les services de stockage AWS. Ils se sont appuyés sur les ressources techniques AWS pour valider leur solution en utilisant DataSync, ce qui leur a permis d’accélérer significativement les écritures de ce grand nombre de fichiers. Tout comme Storage Gateway, DataSync leur a aussi permis de choisir la classe de stockage S3 où écrire la donnée et de transférer la donnée on-premises vers leur VPC sans passer par Internet.

En migrant ces jeux de données avec AWS Storage Gateway et AWS DataSync, ils ont migré leurs données historiques sans interrompre leurs applications en production et en utilisant AWS Direct Connect pour la réplication de leurs données en temps réel. Pour s’assurer qu’il n’y ait pas d’impact sur ces flux, ils ont utilisé leur connexion de reprise après sinistre Direct Connect qui est redondante et qui est inactive la plupart du temps pour la migration, laissant la connexion principale pour les applications en production et en temps réel. Cette configuration leur a permis de migrer environ 1 pétaoctet de données sans affecter leurs applications en production.

Utilisation de leurs données

A côté des jeux de données statiques qu’ils migrent quotidiennement, ils ont aussi implémenté une solution de streaming de données en temps réel qui utilise Kafka MirrorMaker comme principal mécanisme de transport. En plus des fonctionnalités de transformations offertes par Amazon EMR, leurs équipes de Data Science et leurs équipes de développement ont eu accès à de la puissance de calcul à la demande sans limite. Cela signifie plus de données et plus d’analyses sur leurs données. Cependant, ils cherchaient une solution pour migrer les résultats et les jeux de données de nouveau vers leur datacenter pour un usage plus facile par les utilisateurs.

Par rapport à leurs précédents efforts d’automatisation avec AWS Storage Gateway, renvoyer les données vers leur datacenter était facile et la solution a été implémentée rapidement. C’était un simple changement dans leurs applications existantes. Ils ont monté les partages de fichiers de leurs passerelles de stockage sur les nouveaux serveurs et c’était terminé…Enfin c’est ce que CME Group pensait. Un dernier obstacle identifié pendant les tests était de s’assurer que les passerelles de stockage AWS pouvaient être actualisées à la bonne fréquence. Cela était important parce qu’ils avaient besoin de mises à jour sur Amazon S3 (d’une tâche Amazon EMR) afin qu’elles arrivent sur les montages NFS (Network File System, système de fichier en réseau) des machines situées dans leur datacenter. Pour cela, ils ont implémenté une fonction AWS Lambda, déclenchée par une notification du bucket (compartiment en français) S3 sur un préfixe spécifique. Plus récemment, grâce au travail de l’équipe du service AWS Storage Gateway, ils ont commencé à migrer vers la fonctionnalité d’actualisation automatique qui est disponible directement sur les passerelles.

Pour leur communauté Data Science, il y avait un besoin d’avoir les rapports et les jeux de données présents maintenant sur Amazon S3, sur leurs postes de travail Windows pour les partager avec d’autres utilisateurs métier. Pour cela, ils ont implémenté AWS Storage Gateway avec un partage de fichiers SMB (Server Message Block) ce qui leur a permis d’intégrer Active Directory pour donner l’accès des jeux de données aux bons utilisateurs. Avec l’intégration Active Directory, leurs outils d’identification existants sont utilisés pour l’accès fichier de chaque département. Ainsi, ils ont donné l’accès aux résultats des analyses à leurs utilisateurs métier sans avoir besoin de contacter les équipes techniques à chaque fois pour récupérer la donnée. Les utilisateurs peuvent donner ces rapports et ces métriques à leurs collègues et leur management sans avoir besoin de comprendre les mécanismes internes de la solution.

Phase 3 : La majorité précoce

Après avoir implémenté les précédentes solutions, CME Group a de nouveau identifié de nouveaux besoins métier pour lesquels les solutions cloud-native pouvaient répondre à ces besoins. Bien que certains de ces besoins demandaient de mettre en place de nouveaux services, les fonctionnalités principales du stockage de données et du transfert de données continuaient d’être des éléments clés pour diminuer l’écart entre leurs datacenters et AWS. Comme de plus en plus d’équipes chez CME Group avaient adopté AWS Storage Gateway, ils ont continué leur processus d’automatisation pour supporter de nouvelles fonctionnalités en plus d’avoir le déploiement plus rapide de nouvelles passerelles et de partages de fichiers. Comme AWS a continué de faire évoluer Storage Gateway en apportant de nouvelles fonctionnalités, ils ont adapté leur offre interne pour tirer parti de ces nouvelles fonctionnalités. Par exemple, les partages de fichiers basés sur des préfixes leur ont permis de n’utiliser qu’une seule passerelle pour plusieurs applications partageant un même bucket S3 tout en leur permettant de mettre à chaque passerelle un préfixe unique (Et ainsi, créer un jeu de donnée unique).

Conclusion

AWS Storage Gateway, AWS DataSync et l’ensemble des solutions de stockage AWS ont été une clé du succès de leurs premières migrations vers le cloud. Ces services managés leur ont permis de réaliser la migration de leurs applications d’une façon sécurisée, de façon fiable tout en minimisant l’impact sur les autres équipes de leur entreprise. Sans ces offres, mettre à jour des douzaines d’applications aurait ralenti et augmenté la complexité de nos migrations.

Ce succès a été également possible avec le soutien des équipes de support de AWS, et les équipes d’ingénieurs derrière ces services. Ces équipes AWS ont écouté leurs retours et leur ont donné des solutions qui ont réduit leurs frais et augmenté leur capacité à délivrer pour le métier.

Le contenu et les opinions de cet article sont ceux de l’auteur tiers et AWS n’est pas responsable du contenu ou de l’exactitude de cet article.

Article original par Craig Bona. Adapté en français par Lydia Khalfoun, Associate Solutions Architect accompagnant les clients français dans leur transformation et leur adoption du cloud.