Architecture de facturation de nouvelle génération: transition vers Tarantool

Pourquoi une société comme MegaFon, Tarantool dans la facturation? De l'extérieur, il semble que le vendeur vienne habituellement, apporte une grosse boîte, branche la prise dans la prise - voici la facturation! C'était le cas, mais maintenant c'est un archaïque, et de tels dinosaures ont déjà disparu ou sont en train de disparaître. Au départ, la facturation est un système de facturation - un lecteur ou une calculatrice. Dans les télécommunications modernes, il s'agit d' un système d'automatisation pour l'ensemble du cycle de vie de l'interaction avec l'abonné, de la conclusion du contrat à la résiliation , en passant par la facturation en temps réel, l'acceptation des paiements et bien plus encore. La facturation dans les entreprises de télécommunications est similaire à un robot de combat - grand, puissant et accroché avec des armes.



Et voici Tarantool? Oleg Ivlev et Andrey Knyazev en parleront. Oleg est l'architecte en chef de MegaFon avec une vaste expérience de travail dans des sociétés étrangères, Andrey est le directeur des systèmes commerciaux. À partir de la transcription de leur rapport à la conférence Tarantool 2018, vous apprendrez pourquoi la R&D est nécessaire dans les entreprises, ce qu'est Tarantool, comment l'impasse pour la mise à l'échelle verticale et la mondialisation est devenue les conditions préalables à l'émergence de cette base de données dans l'entreprise, sur les défis technologiques, la transformation de l'architecture et comment le technostek de MegaFon ressemble à Netflix, Google et Amazon.

Projet de facturation unique

Le projet qui sera discuté est appelé "facturation unique". C'est en lui que Tarantool a montré ses meilleures qualités.



La croissance des performances des équipements Hi-End n'a pas suivi la croissance de la base d'abonnés et l'augmentation du nombre de services, une nouvelle croissance du nombre d'abonnés et de services due au M2M, l'IoT était attendue et les caractéristiques des succursales ont entraîné une détérioration du délai de mise sur le marché. L'entreprise a décidé de créer un système d'entreprise unique avec une architecture modulaire unique de classe mondiale, au lieu de 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 de 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 ses propres solutions «sur mesure», des fonctionnalités d'agence et une structure organisationnelle différente, informatique et marketing.

Tout allait bien jusqu'à ce que je doive lancer un produit fédéral commun. Beaucoup de difficultés sont apparues ici: pour certains, tarification avec arrondi, pour d'autres dans une moindre mesure, et pour d'autres - selon la moyenne arithmétique. Il y a des milliers de tels moments.

Malgré le fait que la version du système de facturation soit la même, un seul fournisseur, les réglages ont divergé de sorte que la colle depuis longtemps. Nous avons essayé de réduire leur nombre et sommes tombés sur un deuxième problème qui est familier à de nombreuses sociétés.

Mise à l'échelle verticale . Même le fer le plus frais de l'époque ne répondait pas aux besoins. Nous avons utilisé de l'équipement Hewlett-Packard, la ligne Superdome Hi-End, mais cela n'a pas attiré le besoin de deux branches. Je voulais une mise à l'échelle horizontale sans grands coûts de transaction et investissements en capital.

Attente de croissance du nombre d'abonnés et de services . Les consultants ont depuis longtemps apporté des histoires sur l'IoT et le M2M dans le monde des télécommunications: il arrivera un moment où chaque téléphone et fer aura une carte SIM et deux dans le réfrigérateur. Aujourd'hui, nous avons un certain nombre d'abonnés, et dans un proche avenir, il y aura un ordre de grandeur de plus.

Défis technologiques

Ces quatre raisons nous ont conduits à des changements majeurs. Il y avait le choix entre la mise à niveau du système et la conception à partir de zéro. Ils ont réfléchi longtemps, pris des décisions sérieuses, joué des appels d'offres. En conséquence, ils ont décidé de concevoir dès le début et ont relevé des défis intéressants - des défis technologiques.

Évolutivité

S'il y avait auparavant, disons, 8 comptes de facturation pour 15 millions d'abonnés , et maintenant 100 millions d'abonnés et plus auraient dû se produire - la charge est d'un ordre de grandeur plus élevé.

Notre échelle est devenue comparable à celle des principaux acteurs Internet comme Mail.ru ou Netflix.

Mais de nouveaux mouvements pour augmenter la charge et la base d'abonnés nous ont posé de sérieux défis.

La géographie de notre vaste pays

Entre Kaliningrad et Vladivostok 7500 km et 10 fuseaux horaires . La vitesse de la lumière est finie et à de tels délais, les distances sont déjà importantes. 150 ms sur les canaux optiques modernes les plus cool est un peu trop pour la facturation en temps réel, en particulier comme c'est le cas actuellement dans les télécommunications en Russie. De plus, vous devez effectuer la mise à 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 mensuels, nous avons des tarifs complexes, des forfaits, divers modificateurs. Nous devons non seulement autoriser ou interdire à l'abonné de parler, mais lui donner un certain quota - pour calculer les appels et les actions en temps réel afin qu'il ne le remarque pas.

Tolérance aux pannes

C'est le revers de la centralisation.

Si nous rassemblons tous les abonnés dans un seul système, les événements d'urgence et les catastrophes sont désastreux pour les entreprises. Par conséquent, nous concevons le système de manière à exclure l'effet des accidents sur l'ensemble de la base d'abonnés.

C'est là encore une conséquence du rejet de la mise à l'échelle verticale. Lorsque nous sommes passés à une mise à l'échelle horizontale, nous avons augmenté le nombre de serveurs de centaines à des milliers. Ils doivent être gérés et interchangeables, une infrastructure informatique sauvegardée automatiquement et un système distribué restauré.

Ces défis intéressants nous ont confrontés. Nous avons conçu le système, et à ce moment-là, nous avons essayé de trouver les meilleures pratiques mondiales afin de vérifier à quel point nous sommes en tendance, à quel point nous suivons des technologies avancées.

Expérience mondiale

Étonnamment, dans le monde des télécommunications, nous n'avons trouvé aucune référence.

L'Europe a chuté par le nombre d'abonnés et l'échelle, les États-Unis - par le plan de ses tarifs. Nous avons regardé quelque chose en Chine, mais avons trouvé quelque chose en Inde et avons pris des spécialistes de Vodafone India.

Pour analyser l'architecture, la Dream Team a été constituée, dirigée par IBM, des architectes de divers domaines. Ces personnes pourraient évaluer adéquatement ce que nous faisons et apporter certaines connaissances à notre architecture.

Echelle

Quelques chiffres pour illustrer.

Nous concevons un système pour 80 millions d'abonnés avec une réserve d'un milliard . Nous supprimons donc les futurs seuils. Ce n'est pas parce que nous allons prendre le contrôle de la Chine, mais à cause de la pression de l'IoT et du M2M.

300 millions de documents sont traités en temps réel . Bien que nous ayons 80 millions d'abonnés, nous travaillons avec des clients potentiels et ceux qui nous ont quittés si nous avons besoin de recouvrer des créances. Par conséquent, les volumes réels sont beaucoup plus importants.

2 milliards de transactions changent quotidiennement l'équilibre - ce sont les paiements, les frais, les appels et autres événements. 200 To de données changent activement , 8 PB de données changent un peu plus lentement, et ce n'est pas une archive, mais des données en direct dans une seule facturation. L'échelle du centre de données est de 5 000 serveurs répartis 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 a été une pile technologique familière à tout joueur Internet et à toutes les sociétés qui fabriquent des systèmes très chargés.



La pile est similaire aux piles des autres acteurs majeurs: Netflix, Twitter, Viber. Il se compose de 6 composants, mais nous voulons le réduire et l'unifier.

La flexibilité est bonne, mais dans une grande entreprise, il n'y a aucun moyen sans l'unification.

Nous n'allons pas changer le même Oracle en Tarantool. Dans la réalité des grandes entreprises, c'est de l'utopie, ou une croisade de 5 à 10 ans avec un dénouement incompréhensible. Mais Cassandra et Couchbase peuvent être remplacés par Tarantool, et nous nous y engageons.

Pourquoi Tarantool?

Il y a 4 critères simples pour lesquels nous avons choisi cette base de données.

La vitesse . Nous avons effectué des tests de résistance sur les systèmes industriels MegaFon. Tarantool a gagné - il a montré la meilleure performance.

Cela ne veut pas dire que d'autres systèmes ne répondent pas aux besoins de MegaFon. Les solutions de mémoire actuelles sont si productives que ce stock de l'entreprise est plus que suffisant. Mais nous sommes intéressés à traiter avec le leader, et non avec celui qui tisse dans la queue, y compris le test de charge.

Tarantool couvre les besoins de l'entreprise même à long terme.

Coût du TCO . La prise en charge de Couchbase sur les volumes MegaFon coûte de l'argent, avec Tarantool, la situation est beaucoup plus agréable et en termes de fonctionnalités, ils sont proches.

Une autre fonctionnalité intéressante qui a légèrement influencé notre choix - Tarantool fonctionne mieux que les autres bases de données avec mémoire. Il montre une efficacité maximale .

Fiabilité MegaFon est investi dans la fiabilité, probablement pas comme les autres. Par conséquent, lorsque nous avons examiné Tarantool, nous avons réalisé ce qui devait être fait pour qu'il réponde à nos exigences.

Nous avons investi notre temps et nos finances, et avec Mail.ru, nous avons créé une version d'entreprise, qui est maintenant utilisée par plusieurs autres sociétés.

Tarantool-enterprise nous a pleinement satisfaits de la sécurité, de la fiabilité et de la journalisation.

Partenariat

La chose la plus importante pour moi est le contact direct avec le développeur . C'est exactement ce que les gars de Tarantool ont corrompu.

Si vous venez à un joueur, en particulier celui qui travaille avec un client d'ancrage, et dites que vous avez besoin de la base de données pour pouvoir faire ceci, ceci et cela, cela répond généralement:

- Eh bien, mettez les exigences sous le bas de cette pile - un jour, probablement, nous y arriverons.

Beaucoup ont une feuille de route pour les 2-3 prochaines années, et il est presque impossible de s'y intégrer, et les développeurs de Tarantool soudoient avec ouverture, et pas seulement avec MegaFon, et adaptent leur système au client. C'est cool et nous l'aimons vraiment.

Où avons-nous appliqué Tarantool

Chez nous, Tarantool est utilisé dans plusieurs éléments. Le premier est dans le pilote , que nous avons fait 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 répertoire d'adresses dans l'interface de vente. Sur Oracle, trouver l'adresse dont vous avez besoin prend 12-13 s. - numéros 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 200 fois! 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 - déjà quelques millisecondes au lieu de secondes.

La deuxième application est un sujet à la mode appelé l'informatique à deux vitesses . C'est parce que les consultants de chaque fer disent que les sociétés devraient y aller.



Il existe une couche d'infrastructure, des domaines au-dessus, par exemple, un système de facturation, comme les télécommunications, les systèmes d'entreprise, les rapports d'entreprise. C'est le noyau qui n'a pas besoin d'être touché. C'est bien sûr possible, mais paranoïaque en fournissant de la qualité, car cela apporte de l'argent à la société.

Vient ensuite la couche de microservices - celle qui différencie l'opérateur ou un autre acteur. Des microservices peuvent être rapidement créés sur la base de certains caches, y soulevant des données de différents domaines. Voici un champ d'expériences - si quelque chose ne fonctionne pas, fermez un microservice, ouvrez-en un autre. Cela offre un délai de mise sur le marché vraiment amélioré et augmente la fiabilité et la vitesse de l'entreprise.

Les microservices sont peut-être le rôle principal de Tarantool dans MegaFon.

Où nous prévoyons d'appliquer Tarantool

Si nous comparons notre projet de facturation réussi avec les programmes de transformation de Deutsche Telekom, Svyazkome, Vodafone India, il est étonnamment dynamique et créatif. Dans le processus de mise en œuvre de ce projet, non seulement MegaFon et sa structure ont été transformées, mais Tarantool-enterprise est également apparu sur Mail.ru, et notre fournisseur Nexign (anciennement Peter-Service) avait une BSS Box (solution de facturation en boîte).

Dans un sens, il s'agit d'un projet historique pour le marché russe. Il peut être comparé à ce qui est décrit dans le livre de Frederick Brooks «Mythical Man-Month». Puis, dans les années 60, IBM a attiré 5 000 personnes pour développer un nouveau système d'exploitation OS / 360 pour les mainframes. Nous en avons moins - 1 800, mais les nôtres sont dans des gilets, et compte tenu de l'utilisation de l'open source et des nouvelles approches, nous travaillons de manière plus productive.

Les domaines de facturation ou, plus largement, les systèmes d'entreprise sont affichés ci-dessous. Les gens en entreprise connaissent très bien le CRM. Tout le monde devrait déjà avoir d'autres systèmes: Open API, Gateway API.

API ouverte

Examinons à nouveau les chiffres et le fonctionnement de l'API ouverte maintenant. Sa charge est de 10 000 transactions par seconde . Étant donné que nous prévoyons de développer activement la couche de microservices et de créer l'API publique MegaFon, nous nous attendons à plus de croissance à l'avenir dans cette partie particulière. 100 000 transactions seront certainement .

Je ne sais pas si le SSO est comparable à Mail.ru - les gars, comme, ont 1 000 000 de transactions par seconde. Nous sommes extrêmement intéressés par leur solution et nous prévoyons de tirer parti de leur expérience - par exemple, pour créer une réserve SSO fonctionnelle à l'aide de Tarantool. Maintenant, les développeurs de Mail.ru le font avec nous.

CRM

CRM - ce sont les 80 millions d'abonnés que nous voulons porter à un milliard, car il y a déjà 300 millions de documents qui incluent une histoire de trois ans. Nous attendons vraiment avec impatience de nouveaux services, et ici le point de croissance est les services connectés . C'est une balle qui va grandir, car il y aura de plus en plus de services. En conséquence, une histoire sera nécessaire, nous ne voulons pas trébucher là-dessus.

La facturation elle-même en termes de facturation, la collaboration avec les créances clients a été transformée en un domaine distinct . Pour maximiser les performances, le modèle d'architecture d'architecture de domaine est appliqué .

Le système est divisé en domaines, la charge est répartie et une tolérance aux pannes est fournie. De plus, nous avons travaillé avec une architecture distribuée.

Tout le reste est constitué de solutions au niveau de l'entreprise. Dans le magasin d'appels - 2 milliards par jour , 60 milliards par mois. Parfois, il faut les raconter pendant un mois, et mieux vite. Le suivi financier, c'est précisément les 300 millions qui ne cessent de croître et de plus en plus: les abonnés courent souvent entre opérateurs, ce qui augmente cette part.

La composante la plus télécom des communications mobiles est la facturation en ligne . Ce sont les systèmes qui vous permettent d'appeler ou non, de prendre une décision 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 nous sommes donc très intéressés par Tarantool.

L'image précédente est les domaines où nous allons utiliser Tarantool. Le CRM lui-même, bien sûr, est plus large et nous allons l'appliquer au cœur même.

Notre TTX estimé à 100 millions d'abonnés me confond en tant qu'architecte - et si 101 millions? Pour tout refaire? Pour éviter cela, nous utilisons des caches, tout en augmentant l'accessibilité.



En général, il existe deux approches pour utiliser Tarantool. La première consiste à créer tous les caches au niveau du microservice . Si je comprends bien, VimpelCom suit ce chemin, créant un cache client.

Nous sommes moins dépendants des fournisseurs, nous changeons le cœur de BSS, nous avons donc un seul index de carte client prêt à l'emploi. Mais nous voulons la broder. Par conséquent, nous utilisons une approche légèrement différente - nous créons des caches à l'intérieur des systèmes .

Il y a donc moins qu'un rassynchronisme - un système est responsable à la fois d'un cache et de la source principale principale.

La méthode cadre bien avec l'approche du squelette transactionnel Tarantool, lorsque 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'y a pas d'énorme lac de données, de cache global non géré. Les caches sont conçues pour le système, soit pour les produits, soit pour les clients, soit pour faciliter la vie du service. Lorsqu'un abonné appelle bouleversé par la qualité, je veux le servir qualitativement.

RTO et RPO

Il y a deux termes en informatique - RTO et RPO .

L'objectif de temps de récupération est le temps de récupération d'un service après une panne. RTO = 0 signifie que même si quelque chose tombe, le service continue de fonctionner.

L'objectif du point de récupération est le temps de récupération des données, la quantité de données que nous pouvons perdre sur une période de temps. RPO = 0 signifie que nous ne perdons pas de données.

Défi Tarantool

Essayons de résoudre le problème pour Tarantool.

Étant donné : tout le monde comprend le panier d'applications, par exemple, sur Amazon ou ailleurs. Le panier doit fonctionner 24h / 24 et 7j / 7, soit 99,99% du temps. Les commandes qui nous parviennent doivent maintenir l'ordre, car nous ne pouvons pas activer ou désactiver la communication au hasard pour l'abonné - tout doit être strictement cohérent. L'abonnement précédent affecte le suivant, donc les données sont importantes - rien ne doit être perdu.

Solution . Vous pouvez essayer de le résoudre de front et demander aux développeurs de la base de données, mais le problème n'est pas résolu mathématiquement. On peut rappeler les théorèmes, les lois de conservation, la physique quantique, mais pourquoi - cela ne peut pas être résolu au niveau DB.

La bonne vieille approche architecturale fonctionne ici - vous devez bien connaître le sujet et à ses frais résoudre ce rébus.



Notre solution: créer un registre distribué d'applications pour Tarantool - un cluster géo-distribué . Dans le diagramme, il s'agit de trois centres de données différents - deux pour l'Oural, un au-delà de l'Oural, et nous distribuons toutes les applications à ces centres.

Netflix, qui est maintenant considéré comme l'un des leaders de l'informatique, n'avait qu'un seul centre de données jusqu'en 2012. À la veille du Noël catholique du 24 décembre, ce centre de données est tombé en panne. Les utilisateurs du Canada et des États-Unis se sont retrouvés sans leurs films préférés, très contrariés et ont écrit à ce sujet dans les réseaux sociaux. Netflix possède désormais trois centres de données sur la côte ouest-est et un en Europe occidentale.

Nous construisons initialement une solution géo-distribuée - la tolérance aux pannes est importante pour nous.

Donc, nous avons un cluster, mais qu'en est-il de RPO = 0 et RTO = 0? La solution est simple, cela dépend du sujet.

Qu'est-ce qui est important dans les applications? Deux parties: lancer le panier AVANT de prendre une décision d'achat et APRÈS . Une partie de l'OD dans les télécommunications est généralement appelée capture ou négociation d'ordres . Dans les télécommunications, cela peut être beaucoup plus compliqué que dans la boutique en ligne, car là, vous devez servir le client, offrir 5 options, et cela se produit pendant un certain temps, mais le panier est plein. À ce stade, un échec est possible, mais ce n'est pas effrayant, car il se produit en mode interactif sous la supervision d'une personne.

Si le centre de données de Moscou tombe subitement en panne, puis en basculant automatiquement vers un autre centre de données, nous continuerons à travailler. Théoriquement, un produit dans un panier peut être perdu, mais vous voyez cela, complétez à nouveau le panier et continuez à travailler. Dans ce cas, RTO = 0.

Au même moment, il y a une deuxième option: lorsque nous avons cliqué sur «soumettre», nous voulons que les données ne soient pas perdues. À partir de ce moment, l'automatisation commence à fonctionner - c'est déjà RPO = 0. L'application de ces deux modèles différents dans un cas peut être juste un cluster géo-distribué avec un maître commutable, dans l'autre cas une sorte d'entrée de quorum. Les modèles peuvent varier, mais nous résolvons le problème.

De plus, en ayant un registre des demandes distribué, nous pouvons également tout mettre à l'échelle - pour avoir de nombreux répartiteurs et entrepreneurs qui accèdent à ce registre.

Cassandra et Tarantool ensemble

Il y a un autre cas - la «vitrine des soldes» . Voici juste 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 plus. Les marketeurs adorent coloriser le trafic par source, il y a de plus en plus de détails sur les réseaux sociaux, par exemple. Tout cela augmente l'histoire.

Cassandra vous permet de mettre à l'échelle horizontalement n'importe quel volume.

Nous nous sentons à l'aise avec Cassandra, mais elle a un problème - elle n'est pas bonne en lecture. , 30 000 — .

, : , - , Cassandra. , IBM manager file transfer — , , UDP, , TCP. , , , - , — .

, . Kafka Tarantool, , , , , , , 100 2 .

, 2 , , .

Conclusion

Tarantool. Mail.ru, .

BCG McKinsey, Accenture IBM - — , , , , . , Tarantool . .

— Tarantool Conference , 17 T+ Conference 2019 « Tarantool Enterprise» . « Tarantool Oracle» . , , . — , . : , Tarantool, , , .