Pourquoi une entreprise comme MegaFon a-t-elle besoin de Tarantool pour la facturation ? De l'extérieur, il semble que le vendeur vient généralement, apporte une sorte de grande boîte, branche la fiche dans la prise - et c'est la facturation ! C'était autrefois le cas, mais c'est désormais archaïque et ces dinosaures ont déjà disparu ou sont en train de disparaître. Initialement, la facturation est un système d'émission de factures - une machine à compter ou une calculatrice. Dans les télécommunications modernes, c'est système d'automatisation pour tout le cycle de vie de l'interaction avec un abonné, de la conclusion d'un contrat à la résiliation, y compris la facturation en temps réel, l'acceptation des paiements et bien plus encore. La facturation dans les entreprises de télécommunications est comme un robot de combat : grand, puissant et chargé d'armes.
Qu’est-ce que Tarantool a à voir avec ça ? Ils en parleront Oleg Ivlev и Andrey Knyazev. Oleg est l'architecte en chef de l'entreprise Fort d'une vaste expérience de travail dans des entreprises étrangères, Andrey est directeur des systèmes d'entreprise. D'après la transcription de leur rapport sur vous apprendrez pourquoi la R&D est nécessaire dans les entreprises, ce qu'est Tarantool, comment l'impasse de la mise à l'échelle verticale et de la mondialisation est devenue la condition préalable à l'apparition de cette base de données dans l'entreprise, les défis technologiques, la transformation architecturale et en quoi la technostack de MegaFon est similaire à Netflix , Google et Amazon.
Projet "Facturation Unifiée"
Le projet en question s’appelle « Unified Billing ». C'est ici que Tarantool a montré ses meilleures qualités.
La croissance de la productivité des équipements Hi-End n'a pas suivi le rythme de la croissance de la base d'abonnés et de la croissance du nombre de services ; une nouvelle croissance du nombre d'abonnés et de services était attendue en raison du M2M, de l'IoT et des fonctionnalités des succursales. à une détérioration du time-to-market. L'entreprise a décidé de créer un système commercial unifié doté d'une architecture modulaire unique de classe mondiale, au lieu des 8 systèmes de facturation différents actuels.
MegaFon, c'est huit entreprises en une. En 2009, la réorganisation a été achevée : les succursales dans toute la Russie ont fusionné en une seule société, MegaFon OJSC (aujourd'hui PJSC). Ainsi, l'entreprise dispose de 8 systèmes de facturation avec leurs propres solutions « sur mesure », leurs caractéristiques en succursale et différentes structures organisationnelles, informatiques et marketing.
Tout allait bien jusqu'à ce que nous devions lancer un produit fédéral commun. De nombreuses difficultés sont apparues ici : pour certains, les tarifs sont arrondis à l'unité supérieure, pour d'autres, à l'unité inférieure, et pour d'autres encore, ils sont basés sur la moyenne arithmétique. Il existe des milliers de tels moments.
Malgré le fait qu'il n'existait qu'une seule version du système de facturation, un seul fournisseur, les paramètres divergeaient tellement qu'il a fallu beaucoup de temps pour les mettre en place. Nous avons essayé de réduire leur nombre et avons été confrontés à un deuxième problème familier à de nombreuses entreprises.
Mise à l'échelle verticale. Même le matériel le plus cool de l’époque ne répondait pas aux besoins. Nous avons utilisé du matériel Hewlett-Packard de la gamme Superdome Hi-End, mais il ne répondait même pas aux besoins de deux succursales. Je souhaitais une mise à l'échelle horizontale sans coûts d'exploitation ni investissements en capital importants.
Attente de croissance du nombre d'abonnés et de services. Les consultants rapportent depuis longtemps des histoires sur l'IoT et le M2M dans le monde des télécommunications : le temps viendra où chaque téléphone et chaque fer auront une carte SIM, et deux dans le réfrigérateur. Aujourd’hui, nous avons un seul nombre d’abonnés, mais dans un avenir proche, il y en aura bien d’autres.
Défis technologiques
Ces quatre raisons nous ont motivés à opérer de sérieux changements. Il y avait le choix entre mettre à niveau le système ou le concevoir à partir de zéro. Nous avons longuement réfléchi, pris des décisions sérieuses, joué des appels d'offres. En conséquence, nous avons décidé de concevoir dès le début et avons relevé des défis intéressants : des défis technologiques.
Évolutivité
Si c'était avant, disons, disons 8 facturations pour 15 millions d'abonnés, et maintenant ça aurait dû marcher 100 millions d'abonnés et plus - la charge est d'un ordre de grandeur plus élevée.
Nous sommes devenus comparables en taille aux grands acteurs Internet comme Mail.ru ou Netflix.
Mais la poursuite du mouvement visant à augmenter la charge et la base d’abonnés nous pose de sérieux défis.
Géographie de notre vaste pays
Entre Kaliningrad et Vladivostok 7500 km et 10 fuseaux horaires. La vitesse de la lumière est limitée et à de telles distances, les retards sont déjà importants. 150 ms sur les canaux optiques modernes les plus cool, c'est trop pour une facturation en temps réel, d'autant plus que c'est désormais le cas dans les télécommunications en Russie. De plus, vous devez mettre à jour en un jour ouvrable, et avec des fuseaux horaires différents, c'est un problème.
Nous ne fournissons pas seulement des services moyennant des frais d'abonnement, nous proposons des tarifs, des forfaits et divers modificateurs complexes. Nous devons non seulement autoriser ou interdire à l'abonné de parler, mais lui donner un certain quota - calculer les appels et les actions en temps réel afin qu'il ne s'en aperçoive pas.
tolérance aux pannes
C’est l’autre côté de la centralisation.
Si nous rassemblons tous les abonnés dans un seul système, alors tout événement d'urgence ou catastrophe est désastreux pour les entreprises. Par conséquent, nous concevons le système de manière à éliminer l'impact des accidents sur l'ensemble de la base d'abonnés.
C’est là encore une conséquence du refus d’évoluer verticalement. Lorsque nous avons évolué horizontalement, nous avons augmenté le nombre de serveurs de centaines à des milliers. Ils doivent être gérés et interchangeables, sauvegarder automatiquement l'infrastructure informatique et restaurer le système distribué.
Nous avons été confrontés à des défis tellement intéressants. Nous avons conçu le système et, à ce moment-là, nous avons essayé de trouver les meilleures pratiques mondiales pour vérifier à quel point nous sommes dans la tendance et dans quelle mesure nous suivons les technologies avancées.
Expérience mondiale
Étonnamment, nous n’avons pas trouvé une seule référence dans le domaine des télécommunications mondiales.
L'Europe a reculé en termes de nombre d'abonnés et d'échelle, les États-Unis en termes de planéité de leurs tarifs. Nous en avons examiné quelques-uns en Chine, en avons trouvé en Inde et avons embauché des spécialistes de Vodafone India.
Pour analyser l'architecture, nous avons constitué une Dream Team dirigée par IBM - des architectes de différents domaines. Ces personnes pouvaient évaluer adéquatement ce que nous faisions et apporter certaines connaissances à notre architecture.
Échelle
Quelques chiffres à titre d'illustration.
Nous concevons le système pour 80 millions d'abonnés avec une réserve d'un milliard. C’est ainsi que nous supprimons les futurs seuils. Ce n’est pas parce que nous allons conquérir la Chine, mais à cause de l’assaut de l’IoT et du M2M.
300 millions de documents traités en temps réel. Bien que nous ayons 80 millions d'abonnés, nous travaillons aussi bien avec des clients potentiels qu'avec ceux qui nous ont quittés si nous avons besoin de recouvrer des créances. Les volumes réels sont donc sensiblement plus importants.
2 milliards de transactions Le solde change quotidiennement - il s'agit des paiements, des frais, des appels et d'autres événements. 200 To de données évoluent activement, change un peu plus lentement 8 Po de données, et ce n'est pas une archive, mais des données en direct dans une seule facturation. Échelle par centre de données - 5 mille serveurs sur 14 sites.
Pile technologique
Lorsque nous avons planifié l'architecture et commencé à assembler le système, nous avons importé les technologies les plus intéressantes et les plus avancées. Le résultat est une pile technologique familière à tous les acteurs Internet et aux entreprises qui fabriquent des systèmes à forte charge.
La stack est similaire aux stacks d’autres acteurs majeurs : Netflix, Twitter, Viber. Il se compose de 6 éléments, mais nous souhaitons le raccourcir et l’unifier.
La flexibilité, c’est bien, mais dans une grande entreprise, il n’y a pas de solution sans unification.
Nous n'allons pas changer le même Oracle en Tarantool. Dans la réalité des grandes entreprises, il s’agit d’une utopie, ou d’une croisade de 5 à 10 ans dont l’issue est incertaine. Mais Cassandra et Couchbase peuvent facilement être remplacés par Tarantool, et c’est ce que nous recherchons.
Pourquoi Tarantool ?
Il y a 4 critères simples pour lesquels nous avons choisi cette base de données.
vitesse. Nous avons effectué des tests de charge sur les systèmes industriels MegaFon. Tarantool a gagné - il a montré la meilleure performance.
Cela ne veut pas dire que les autres systèmes ne répondent pas aux besoins de MegaFon. Les solutions de mémoire actuelles sont si productives que les réserves de l'entreprise sont largement suffisantes. Mais nous souhaitons avoir affaire à un leader, et non à quelqu'un qui est à la traîne, y compris dans le test de charge.
Tarantool couvre les besoins de l'entreprise même sur le long terme.
Coût total de possession. La prise en charge de Couchbase sur les volumes MegaFon coûte des sommes astronomiques, mais avec Tarantool, la situation est beaucoup plus agréable et leurs fonctionnalités sont similaires.
Une autre fonctionnalité intéressante qui a légèrement influencé notre choix est que Tarantool fonctionne mieux avec la mémoire que les autres bases de données. Il montre efficacité maximale.
Fiabilité. MegaFon investit dans la fiabilité, probablement plus que quiconque. Ainsi, lorsque nous avons examiné Tarantool, nous avons réalisé que nous devions l'adapter à nos exigences.
Nous avons investi notre temps et nos finances et, avec Mail.ru, nous avons créé une version entreprise, qui est maintenant utilisée dans plusieurs autres entreprises.
Tarantool-enterprise nous a entièrement satisfait en termes de sécurité, de fiabilité et de journalisation.
Association
La chose la plus importante pour moi est contact direct avec le développeur. C'est exactement avec quoi les gars de Tarantool ont soudoyé.
Si vous vous adressez à un joueur, notamment celui qui travaille avec un client phare, et lui dites que vous avez besoin de la base de données pour pouvoir faire ceci, ceci et cela, il répond généralement :
- D'accord, mettez les exigences au bas de cette pile - un jour, nous y parviendrons probablement.
Beaucoup ont une feuille de route pour les 2-3 prochaines années, et il est presque impossible de s'y intégrer, mais les développeurs de Tarantool séduisent par leur ouverture, et pas seulement de MegaFon, et adaptent leur système au client. C'est cool et on aime vraiment ça.
Où nous avons utilisé Tarantool
Nous utilisons Tarantool dans plusieurs éléments. Le premier est dans le pilote, que nous avons réalisé sur le système d'annuaire d'adresses. À un moment donné, je voulais que ce soit un système similaire à Yandex.Maps et Google Maps, mais cela s'est avéré un peu différent.
Par exemple, le catalogue d'adresses dans l'interface de vente. Sur Oracle, la recherche de l'adresse souhaitée prend 12 à 13 secondes. - des chiffres inconfortables. Lorsque nous passons à Tarantool, remplaçons Oracle par une autre base de données dans la console et effectuons la même recherche, nous obtenons une accélération de 200x ! La ville apparaît après la troisième lettre. Nous adaptons maintenant l'interface pour que cela se produise après la première. Cependant, la vitesse de réponse est complètement différente : des millisecondes au lieu de secondes.
La deuxième application est un thème tendance appelé informatique à deux vitesses.. C’est parce que les consultants de tous les coins disent que les entreprises devraient s’y rendre.
Il y a une couche d'infrastructure, au-dessus se trouvent des domaines, par exemple un système de facturation comme une entreprise de télécommunications, des systèmes d'entreprise, des rapports d'entreprise. C’est le noyau auquel il n’est pas nécessaire de toucher. Bien sûr, c'est possible, mais en garantissant la qualité de manière paranoïaque, car cela rapporte de l'argent à l'entreprise.
Vient ensuite la couche de microservices, ce qui différencie l'opérateur ou l'autre acteur. Des microservices peuvent être rapidement créés sur la base de certains caches, y apportant des données de différents domaines. Ici terrain d'expérimentation — si quelque chose ne fonctionnait pas, je fermais un microservice et j'en ouvrais un autre. Cela permet d'augmenter considérablement les délais de mise sur le marché et d'augmenter la fiabilité et la rapidité de l'entreprise.
Les microservices sont peut-être le rôle principal de Tarantool chez MegaFon.
Où nous prévoyons d'utiliser Tarantool
Si nous comparons notre projet de facturation réussi avec les programmes de transformation de Deutsche Telekom, Svyazcom, Vodafone India, il est étonnamment dynamique et créatif. Au cours du processus de mise en œuvre de ce projet, non seulement MegaFon et sa structure ont été transformés, mais également Tarantool-enterprise sur Mail.ru et notre fournisseur Nexign (anciennement Peter-Service) - BSS Box (une solution de facturation en boîte).
Il s’agit en quelque sorte d’un projet historique pour le marché russe. Cela peut être comparé à ce qui est décrit dans le livre « The Mythical Man-Month » de Frederick Brooks. Puis, dans les années 60, IBM embauche 360 5 personnes pour développer le nouveau système d'exploitation OS/000 pour les mainframes. Nous en avons moins - 1 800, mais les nôtres sont en gilets, et compte tenu de l'utilisation de l'open source et des nouvelles approches, nous travaillons de manière plus productive.
Vous trouverez ci-dessous les domaines de la facturation ou, plus largement, des systèmes d'entreprise. Les gens d'entreprise connaissent très bien le CRM. Tout le monde devrait déjà disposer d’autres systèmes : Open API, API Gateway.
Open API
Examinons à nouveau les chiffres et le fonctionnement actuel de l'Open API. Sa charge est 10 000 transactions par seconde. Puisque nous prévoyons de développer activement la couche de microservices et de construire l'API publique MegaFon, nous prévoyons une plus grande croissance à l'avenir dans cette partie. Il y aura certainement 100 000 transactions.
Je ne sais pas si nous pouvons comparer avec Mail.ru en SSO - les gars semblent avoir 1 000 0000 de transactions par seconde. Leur solution nous semble extrêmement intéressante et nous prévoyons d'adopter leur expérience - par exemple, réaliser une sauvegarde SSO fonctionnelle à l'aide de Tarantool. Maintenant, les développeurs de Mail.ru le font pour nous.
CRM
Le CRM, c'est les mêmes 80 millions d'abonnés que nous souhaitons augmenter jusqu'à un milliard, car il existe déjà 300 millions de documents qui incluent un historique de trois ans. Nous attendons vraiment avec impatience de nouveaux services et ici le point de croissance est celui des services connectés. C’est un boulet qui va grandir, car il y aura de plus en plus de services. En conséquence, nous aurons besoin d’une histoire ; nous ne voulons pas tomber dessus.
Se facturer en termes d'émission de factures, travailler avec les comptes clients transformé en un domaine distinct. Pour améliorer les performances, modèle architectural d'architecture de domaine appliqué.
Le système est divisé en domaines, la charge est répartie et la tolérance aux pannes est assurée. De plus, nous avons travaillé avec une architecture distribuée.
Tout le reste est constitué de solutions au niveau de l'entreprise. Dans la mémoire des appels - 2 milliards par jour, 60 milliards par mois. Parfois il faut les compter dans un mois, et c'est mieux vite. Suivi financier - ce sont exactement les mêmes 300 millions qui ne cessent de croître : les abonnés circulent souvent entre opérateurs, augmentant cette part.
La composante la plus télécom des communications mobiles est facturation en ligne. Ce sont ces systèmes qui permettent d'appeler ou de ne pas appeler, de prendre des décisions en temps réel. Ici, la charge est de 30 000 transactions par seconde, mais compte tenu de la croissance du transfert de données, nous prévoyons 250 000 transactions, et c'est pourquoi nous sommes très intéressés par Tarantool.
L'image précédente représente les domaines dans lesquels nous allons utiliser Tarantool. Le CRM lui-même, bien sûr, est plus large et nous allons l'utiliser dans le noyau lui-même.
Notre chiffre TTX estimé à 100 millions d'abonnés me laisse perplexe en tant qu'architecte - et si 101 millions ? Faut-il tout refaire ? Pour éviter que cela ne se produise, nous utilisons des caches, tout en augmentant l'accessibilité.
En général, il existe deux approches pour utiliser Tarantool. D'abord - créer tous les caches au niveau du microservice. D'après ce que je comprends, VimpelCom suit cette voie en créant un cache de clients.
Nous sommes moins dépendants des fournisseurs, nous changeons le noyau BSS, nous avons donc un seul fichier client prêt à l'emploi. Mais nous souhaitons l'élargir. Par conséquent, nous adoptons une approche légèrement différente : créer des caches à l'intérieur des systèmes.
De cette façon, il y a moins de synchronisation : un système est responsable à la fois du cache et de la source principale principale.
La méthode s'intègre bien avec l'approche Tarantool avec un squelette transactionnel, où seules les parties liées aux mises à jour, c'est-à-dire les modifications de données, sont mises à jour. Tout le reste peut être stocké ailleurs. Il n’existe pas d’énorme lac de données ni de cache global non géré. Les caches sont conçus pour le système, ou pour les produits, ou pour les clients, ou pour faciliter la maintenance. Lorsqu'un abonné appelle et est mécontent de la qualité de votre service, vous souhaitez lui fournir un service de qualité.
RTO et RPO
Il y a deux termes en informatique : RTO и RPO.
Objectif de temps de récupération est le temps nécessaire pour restaurer le service après une panne. RTO = 0 signifie que même en cas d'échec, le service continue de fonctionner.
Objectif du point de récupération - c'est le temps de récupération des données, la quantité de données que nous pouvons perdre sur une certaine période de temps. RPO = 0 signifie que nous ne perdons pas de données.
Tâche Tarantool
Essayons de résoudre un problème pour Tarantool.
Étant donné: un panier d'applications que tout le monde comprend, par exemple sur Amazon ou ailleurs. Requis pour que le panier fonctionne 24 heures sur 7, 99,99 jours sur XNUMX, soit XNUMX% du temps. Les commandes qui nous parviennent doivent rester en ordre, car nous ne pouvons pas activer ou désactiver au hasard la connexion de l'abonné - tout doit être strictement cohérent. L'abonnement précédent affecte le suivant, les données sont donc importantes : rien ne doit manquer.
décision. Vous pouvez essayer de le résoudre de front et demander aux développeurs de bases de données, mais le problème ne peut pas être résolu mathématiquement. Vous vous souvenez des théorèmes, des lois de conservation, de la physique quantique, mais pourquoi : cela ne peut pas être résolu au niveau de la base de données.
La bonne vieille approche architecturale fonctionne ici : vous devez bien connaître le domaine et l'utiliser pour résoudre ce casse-tête.
Notre solution : créer un registre distribué d'applications sur Tarantool - un cluster géo-distribué. Dans le diagramme, il s'agit de trois centres de traitement de données différents - deux avant l'Oural, un au-delà de l'Oural, et nous répartissons toutes les demandes entre ces centres.
Netflix, aujourd’hui considéré comme l’un des leaders de l’informatique, ne disposait que d’un seul centre de données jusqu’en 2012. A la veille du Noël catholique, le 24 décembre, ce centre de données est tombé en panne. Les utilisateurs au Canada et aux États-Unis se sont retrouvés sans leurs films préférés, ont été très contrariés et en ont parlé sur les réseaux sociaux. Netflix dispose désormais de trois centres de données sur la côte ouest-est et d'un en Europe occidentale.
Nous construisons dans un premier temps une solution géodistribuée - la tolérance aux pannes est importante pour nous.
Nous avons donc un cluster, mais qu'en est-il de RPO = 0 et RTO = 0 ? La solution est simple, selon le sujet.
Qu'est-ce qui est important dans les candidatures ? Deux parties : lancer de panier D' prendre une décision d'achat, et APRÈS. La partie DO dans les télécoms est généralement appelée capture de commande ou négociation de commande. Dans les télécoms, cela peut être beaucoup plus difficile que dans une boutique en ligne, car là-bas, le client doit être servi, proposé 5 options, et tout cela dure un certain temps, mais le panier est rempli. À ce moment-là, un échec est possible, mais il n’est pas effrayant, car il se produit de manière interactive sous surveillance humaine.
Si le centre de données de Moscou tombe soudainement en panne, nous continuerons à travailler en passant automatiquement à un autre centre de données. Théoriquement, un produit peut être perdu dans le panier, mais vous le voyez, l'ajoutez à nouveau au panier et continuez à travailler. Dans ce cas RTO = 0.
En même temps, il existe une deuxième option : lorsque nous cliquons sur « soumettre », nous voulons que les données ne soient pas perdues. À partir de ce moment, l'automatisation commence à fonctionner - c'est RPO = 0. En utilisant ces deux modèles différents, dans un cas, il pourrait s'agir simplement d'un cluster géo-distribué avec un maître commutable, dans un autre cas, d'une sorte d'enregistrement de quorum. Les modèles peuvent varier, mais nous résolvons le problème.
De plus, en disposant d'un registre distribué d'applications, nous pouvons également tout faire évoluer - avoir de nombreux répartiteurs et exécuteurs qui accèdent à ce registre.
Cassandra et Tarantool ensemble
Il y a un autre cas - "vitrine des soldes". Voici un cas intéressant d'utilisation conjointe de Cassandra et Tarantool.
Nous utilisons Cassandra car 2 milliards d'appels par jour ne sont pas la limite, et il y en aura davantage. Les marketeurs adorent coloriser le trafic par source ; de plus en plus de détails apparaissent sur les réseaux sociaux par exemple. Tout cela ajoute à l'histoire.
Cassandra vous permet d'évoluer horizontalement à n'importe quelle taille.
Nous nous sentons à l'aise avec Cassandra, mais elle a un problème : elle n'est pas bonne en lecture. Tout va bien sur l'enregistrement, 30 000 par seconde n'est pas un problème - problème de lecture.
Par conséquent, un sujet avec un cache est apparu, et en même temps nous avons résolu le problème suivant : il existe un vieux cas traditionnel où l'équipement d'un passage de la facturation en ligne entre dans les fichiers que nous chargeons dans Cassandra. Nous avons eu du mal à résoudre le problème du téléchargement fiable de ces fichiers, même en utilisant les conseils du gestionnaire de transfert de fichiers IBM - il existe des solutions qui gèrent efficacement le transfert de fichiers, en utilisant le protocole UDP, par exemple, plutôt que TCP. C'est bien, mais cela ne prend que quelques minutes, et nous n'avons pas encore tout chargé, l'opérateur du centre d'appels ne peut pas répondre au client sur ce qui est arrivé à son solde - nous devons attendre.
Pour éviter que cela ne se produise, nous nous utilisons une réserve fonctionnelle parallèle. Lorsque nous envoyons un événement via Kafka à Tarantool, en recalculant les agrégats en temps réel, par exemple, pour aujourd'hui, nous obtenons soldes de trésorerie, qui peut transférer des soldes à n'importe quelle vitesse, par exemple 100 2 transactions par seconde et ces mêmes XNUMX secondes.
L'objectif est qu'après avoir passé un appel, dans les 2 secondes, dans votre compte personnel, il y aura non seulement le solde modifié, mais également des informations sur les raisons pour lesquelles il a changé.
Conclusion
Ce sont des exemples d’utilisation de Tarantool. Nous avons vraiment apprécié l'ouverture de Mail.ru et sa volonté d'examiner différents cas.
Il est déjà difficile pour les consultants du BCG ou de McKinsey, d'Accenture ou d'IBM de nous surprendre avec quelque chose de nouveau : une grande partie de ce qu'ils proposent, soit nous le faisons déjà, l'avons fait ou prévoyons de le faire. Je pense que Tarantool prendra la place qui lui revient dans notre pile technologique et remplacera de nombreuses technologies existantes. Nous sommes dans la phase active de développement de ce projet.
Le rapport d'Oleg et Andrey est l'un des meilleurs de la conférence de Tarantool l'année dernière et le 17 juin, Oleg Ivlev prendra la parole à avec un rapport . Alexander Deulin fera également une présentation de MegaFon . Découvrons ce qui a changé, quels plans ont été mis en œuvre. Rejoignez-nous - la conférence est gratuite, il vous suffit de . tous et le programme de la conférence a été constitué : nouveaux cas, nouvelles expériences d'utilisation de Tarantool, architecture, entreprise, tutoriels et microservices.
Source: habr.com