Bonjour, je m'appelle Victoria et je suis responsable du marketing chez CROC Cloud Services. Désormais, nous hébergeons régulièrement des mitaps cloud. J'ai récemment obtenu la performance la plus cool de Dmitry Anoshin, qui travaille maintenant chez Amazon, et je veux la partager.
J'avais le fort sentiment que les grandes entreprises commerciales décidaient de collecter de manière générale toutes les données possibles dans le monde qu'elles pouvaient atteindre. D'une part, cela se traduit par des analyses avancées, une augmentation des ventes et l'attractivité des produits. D'un autre côté, les données sont devenues si audacieuses et complètes que les blagues sur les camions équipés de CD-ROM sont depuis longtemps monnaie courante.
Voyons pourquoi vous pourriez avoir besoin de migrer vers le cloud, et ce qu'Amazon a retiré du déplacement de l'infrastructure interne vers Redshift et NoSQL DynamoDB. Analysons la différence entre les concepts de SMP et MPP, ETL et ELT et essayons de comprendre pourquoi les nuages ​​sont nécessaires pour les mégadonnées.
Eh bien, si vous êtes au courant de ce qui s'est passé dans l'industrie ces dernières années, accédez immédiatement à un cas spécifique. Sous la coupe, j'ai préparé un résumé des principaux points de la performance.
Télémétrie de chaque ampoule
Les grandes entreprises ont une tendance très sensible à la formation d'écosystèmes intégrés autour de leurs utilisateurs. Autrement dit, vous vous êtes réveillé, êtes allé vous brosser les dents et en même temps vous regardez les nouvelles dans un miroir multimédia. La colonne Alexa comprend de la musique énergique le matin et rappelle les réunions d'aujourd'hui. Ici, vous commandez du café frais avec livraison à domicile, car l'ancien est déjà épuisé. Vous montez dans la voiture, puis à nouveau Alexa, qui est intégré au système multimédia de la voiture et continue à accompagner sur la route. Plus un bracelet intelligent, des écouteurs, des applications dans le téléphone et des milliers d'autres sources d'informations.
Il s'agit en même temps d'un avenir légèrement effrayant qui vient rapidement de toutes les directions, une tentative de création de valeur ajoutée pour le consommateur final des entreprises. Vous devez accepter que ce soit cool quand, par exemple, selon le programme Amazon Key In-Car, vos achats seront livrés directement dans le coffre du parking. Je vis maintenant au Canada et de telles intégrations rendent la vie beaucoup plus confortable. Pour l'entreprise, il s'agit également de données très précieuses en termes de ciblage des ventes, de prévision de la demande, d'optimisation logistique, etc. Gagnant-gagnant.
Un problème. Comme je l'ai déjà dit, le sentiment est fort que les entreprises collectent souvent des données à une échelle excessive dans l'espoir de les monétiser à l'avenir. Et ce sont des téraoctets. En fait, des téraoctets d'informations mal structurées qui circulent en continu sur les serveurs de l'entreprise, dévorant le réseau, les ressources informatiques et de stockage. C'est pourquoi le problème de l'utilisation optimale des ressources et de la rapidité de calcul est si important. Et vous devez également donner aux analystes d'entreprise une interface normale qui ne nécessite pas qu'ils aient des connaissances spécialisées dans la construction d'une infrastructure cloud. Par conséquent, de nombreuses grandes entreprises se sont dirigées vers les nuages.
Il n'y a pas de nuage
La technologie cloud est le mot à la mode qui a à peu près tout le monde. Non, sans aucun doute, il a l'air solide dans les états financiers de l'entreprise et lors des présentations officielles. Néanmoins, au niveau du fer, ce sont tous les mêmes bons vieux serveurs situés dans les centres de données du monde entier. Cependant, le cloud computing a besoin de plus qu'une simple console de virtualisation pratique. La principale caractéristique des nuages ​​est la gestion entièrement dynamique des ressources et leur mise à l'échelle automatique si nécessaire:
- Le calcul.
- Stockage.
- Ressources réseau et transport.
- La base de données.
Lorsque vous disposez d'une telle infrastructure, vous utiliserez vos ressources beaucoup plus pleinement, ce qui, avec des analyses de rentabilité à grande échelle, peut entraîner des économies importantes.
Pour les petites entreprises, cette approche peut également être très attractive. Imaginez que vous envisagez d'acheter du fer neuf pour votre infrastructure l'année prochaine. Dans le même temps, il est très difficile pour vous de prédire la charge exacte, qui peut varier de nombreux facteurs. Par exemple, votre produit devient tout à coup très populaire grâce à une publication réussie sur Habré, toute une foule de clients se précipite vers vous et déçue car vous n'avez pas prévu de telles charges de pointe. Et il peut y avoir une situation inverse lorsque vous surestimez la demande, achetez une capacité excédentaire et, par conséquent, obtenez un équipement inactif, ce qui supprime en fait l'argent dont vous avez tant besoin du chiffre d'affaires de l'entreprise. Un pari uniquement sur l'achat de capacités en fer est presque toujours un processus extrêmement inerte, et il perd certainement en adaptabilité dans un marché en évolution rapide.
Une migration particulière ou complète vers le cloud convient à de telles situations, qui sert de sorte de condensateur qui atténue les pics de consommation de pointe. Ou même vous fournit complètement une infrastructure.
Types de nuages
En fait, selon leur modèle commercial, les entreprises proposent généralement l'une des trois formes de construction de systèmes cloud. Une petite entreprise utilise généralement des clouds publics et économise sur les spécialistes appropriés, en se concentrant sur son produit. Les grandes entreprises en elles-mêmes sont similaires à de nombreuses sociétés distinctes reliées par un objectif et une marque communs. Par conséquent, ils créent souvent des clouds privés, atteignant une utilisation optimale des ressources. La partie utilise des modèles hybrides, qui vous permettent de traiter localement des données particulièrement sensibles et protégées par la loi et de transférer des tâches mineures vers des clouds externes. La pizza en tant que service:
J'ai toujours beaucoup aimé cette illustration, qui montre bien le degré de délégation des tâches d'infrastructure de votre entreprise au fournisseur.
L'option traditionnelle sur place consiste à acheter de la nourriture, à préchauffer le four et à cuisiner vous-même la pizza. Parfait! Mais vous devez avoir tout l'équipement, les ingrédients et plus encore.
L'IaaS est une option de location d'infrastructure. Vous avez loué une cuisine avec tout le matériel, apporté vos produits et préparé une excellente pizza. Des personnes spécialement formées laveront le four de la graisse et vous n'avez pas à vous soucier de la netteté des couteaux et autres bagatelles.
PaaS est une plateforme en tant que service. Le service vous offre quelques goodies supplémentaires en plus de l'infrastructure nue. Par exemple, Amazon Redshift - en tant qu'entrepôt de données, ce qui vous permet d'économiser sur DBA et de vous concentrer sur le produit. Dans notre exemple de pizza, il peut s'agir, par exemple, d'une pâte en forme prête à l'emploi qui ne peut être décongelée, étalée avec une sauce aromatique, saupoudrée de champignons, des tranches de bacon tendre et du parmesan râpé.
La dernière option est SaaS. Dans ce cas, vous obtenez le produit le plus fini sur la base duquel vous construisez votre entreprise. Par exemple, exécutez un blog basé sur la plate-forme publique de quelqu'un d'autre. Dans notre exemple, ce sera l'option la plus chère mais la plus simple pour commander une pizza toute prête à la maison.
Données sur les camions. Mobile neige
Il y a une vieille anecdote barbu de l'époque du «zéro»: «Une équipe de chauffeurs de camion a pu livrer 100 000 CD d'Odessa à Kiev pendant la nuit. Ainsi, ils ont atteint un taux de transfert de données de 2,43 téraoctets par seconde sur une distance de plus de 500 km sans l'utilisation de câbles coûteux. "
À l'époque, ce n'était qu'une blague. Cependant, avec les volumes modernes d'un flux continu de photos de chaque téléphone mobile, audio, vidéo et autres télémétrie, cela devient complètement imbattable et devient un vrai problème. Lorsque vous n'avez pas de lien optique épais loué directement vers le centre de données, le déplacement de grandes quantités de données vers le cloud peut être un énorme problème. Des services tels que Snowball d'Amazon viennent à la rescousse.
Ils vous apportent un boîtier protégé si brutal rempli de 50 téraoctets de disques haute vitesse et d'interfaces réseau de 10 gigabits. Ensuite, vous le connectez directement à votre magasin et fusionnez toutes les données à vitesse maximale. En cas de vol ou d'autres problèmes, les données ne quittent votre salle de serveurs que sous forme cryptée. Le boîtier contient un module TPM et les clés de chiffrement sont gérées à l'aide du service de gestion des clés AWS (KMS). Les clés de chiffrement ne sont pas stockées sur l'appareil lui-même.
Dans les cas particulièrement avancés, vous pouvez appeler Snowball Truck - un centre de données mobile d'une capacité de 100 pétaoctets. Lorsque les échelles de données approchent des exaoctets, une connexion typique de 10 gigabits nécessitera 26 ans pour le transfert de données. Et ces camions blancs pourront glisser-déposer des données pendant six mois.
Amazon Migration d'Oracle vers Redshift
Ce que nous avionsJe vais vous parler un peu de l'affaire avec laquelle j'ai travaillé chez Amazon. Les principales plateformes de trading comme Amazon ont un travail très pénible - Prime Days. Ce sont les ventes de pointe du Black Friday et les ventes de Noël. À ce stade, les serveurs fondent sous la charge, les entrepôts sont remplis de chargeurs et la logistique s'étouffe sous un flux continu de marchandises. C'est un moment très important du point de vue des ventes, et chaque heure d'indisponibilité ou d'inaccessibilité du service coûte énormément de pertes.
Le problème venait d'Oracle DB. La base de données a simplement cessé d'exporter un tel volume de requêtes simultanées, rencontrant des problèmes de mise à l'échelle. Le site s'est presque développé sous l'assaut des clients, et la base de données est devenue un problème en termes de mise à l'échelle.
Après une analyse minutieuse, ils sont arrivés à la conclusion que les bases de données SQL traditionnelles ne conviennent pas comme backend pour une plateforme de trading de cette ampleur. De plus, Oracle est également extrêmement coûteux en termes de licences et de support. En conséquence, il a été décidé de migrer vers leur plateforme cloud, basée sur Redshift et NoSQL DynamoDB.
DynamoDB était un développement interne avec réplication synchrone entre les centres de données et un mécanisme extrêmement efficace pour réduire la redondance des données, ce qui a permis d'économiser considérablement sur leur stockage. Une fonction très importante était la mise à l'échelle automatique - mise à l'échelle dynamique de la base de données pour la quantité de données requise. Une grande intégration avec Hadoop a également été mise au point.
Quel est le principal problème d'une base de données traditionnelle?
Le problème est que l'ancienne version avec Oracle fait référence à l'architecture SMP, qui n'implique qu'une mise à l'échelle verticale. Autrement dit, vous avez une machine puissante avec une certaine mémoire, un tas de stockage rapide, et toutes les demandes y sont acheminées d'une manière ou d'une autre. Il s'agit d'un modèle Oracle classique qui se concentre sur la fourniture de ses puissants serveurs autonomes. Dans le même temps, l'entreprise ne croyait pas particulièrement au cloud et le calcul parallèle n'était pas considéré comme une solution prometteuse. Et nous avions besoin de MPP - une architecture parallèle qui vous permet de traiter une demande pour de nombreuses machines distinctes et de traiter les données plus rapidement.
Il y a un autre point important - l'approche ETL vs ELT pour entrer des données dans la base de données.
ETL - Extraire -> Transformer -> Charger. C'est-à -dire que nous recevons d'abord les données de nos sources, les structurons soigneusement, puis les remplissons ensuite dans notre entrepôt. L'approche ELT implique le remplissage de données bruyantes brutes dans le stockage et le traitement est déjà de son côté. En principe, RedShift prend en charge les deux approches, mais ETL a un avantage: l'accès aux données filtrées est plus rapide et plus facile à manipuler. Bien que, dans le même temps, davantage de ressources soient consacrées à l'analyse initiale des informations brutes. Il y a encore un moment non évident. ETL réduit les risques en termes de RGPD en droit européen en filtrant à l'avance les informations sensibles avant qu'elles n'atteignent le référentiel général. Cela réduit le risque d'accès non autorisé aux données. Le principal outil de traitement des données primaires dans la nouvelle architecture était Matillion. Il y a déjà une belle interface graphique, elle est hautement configurable et vient déjà dans une option adaptée à Amazon RedShift. Grâce à lui, il s'est avéré abaisser le seuil d'entrée. Désormais, les chefs de produit peuvent configurer les flux de données entrants sous la forme d'un concepteur visuel sans l'aide de nos ingénieurs de données.
En conséquence, nous avons obtenu la flexibilité, la mise à l'échelle et le lissage des charges de pointe dont nous avions besoin. Par exemple, ils ont pu résoudre le problème de ratisser 50 Go de journaux de serveur Web par jour pour prédire le comportement des visiteurs.
Nous avons également introduit Tableau, qui nous a permis de passer de tableaux mal connectés dans Excel à des tableaux de bord simples, pratiques pour la gestion.
Et je vais vous expliquer au cas où: il y a un Oracle OLTP (backend) dans le magasin, il y a Oracle DW - un entrepôt de données analytiques. Le projet visait les deux choses, mais je parle spécifiquement d'Oracle DW! Autrement dit, le schéma et la description donnés sont locaux, ils ne concernent que l'équipe Amazon. Il en va de même pour Tableau. Quand je dis «nous avons mis en place le tableau de bord», je veux dire le projet local, car sur Amazon, tout est divisé en équipes, et chacun choisit quoi faire et quoi mettre en œuvre et utiliser.
Les nuages, malgré le battage médiatique quelque peu malsain qui les entoure, sont déjà la réalité actuelle. Il est fort probable que la plupart des projets commerciaux seront en quelque sorte construits autour de ces infrastructures. Oui, toutes les entreprises n'auront peut-être pas de telles solutions. Mais cela vaut la peine de planifier un développement supplémentaire maintenant, sinon il sera difficile de réagir rapidement à l'évolution rapide des paramètres du marché et à une concurrence féroce.
Si quelqu'un s'intéresse au sujet de l'analyse du cloud et des solutions modernes,
rendez-vous ici . J'y laisse du contenu utile.
Venez à notre réunion
CROC Cloud Services a déjà prononcé une série de discours d'excellents conférenciers, par exemple, le sujet d'un mitap était l'utilisation pratique des services AWS dans la vie. L'année prochaine, nous avons prévu plusieurs autres événements, nous en parlerons en détail. Suivez les événements.