Pourquoi une entreprise comme MegaFon aurait-elle besoin de Tarantool dans la facturation ? De l'extérieur, il semble qu'un fournisseur arrive, apporte une grande boîte, la branche dans une prise – et voilà, la facturation est en place ! Cela a été le cas autrefois, mais aujourd'hui, c'est de l'archaïsme, et ces dinosaures sont déjà éteints ou en voie d'extinction. À l'origine, la facturation est un système de facturation – un calculateur. Dans les télécommunications modernes, c'est unsystème d'automatisation de tout le cycle de vie de l'interaction avec l'abonné, depuis la signature du contrat jusqu'à la rupture,
incluant la tarification en temps réel, la réception des paiements et bien d'autres choses. La facturation dans les entreprises de télécommunication ressemble à un robot de combat – grand, puissant et équipé d'armements. Mais quel est le rapport avec Tarantool ? C'est ce que vont expliquer et Oleg Ivlev. Oleg est l'architecte en chef de la société avec une grande expérience dans des entreprises à l'étranger, Andrey est le directeur des systèmes d'affaires. À partir de la transcription de leur rapport lors de la , vous découvrirez pourquoi la R&D est nécessaire dans les entreprises, ce qu'est Tarantool, comment l'impasse du scaling vertical et la globalisation ont été des conditions préalables à l'émergence de cette base de données dans l'entreprise, les défis technologiques, la transformation de l'architecture et en quoi la technologie de MegaFon ressemble à celles de Netflix, Google et Amazon.
Le projet « Facturation Unique »
Le projet dont nous allons parler s'appelle « Facturation Unique ». C'est exactement dans ce projet que Tarantool a montré ses meilleures qualités.
La hausse des performances du matériel Hi-End n'étaient pas à la hauteur de l'augmentation de la base d'abonnés et du nombre de services, une augmentation supplémentaire du nombre d'abonnés et de services était attendue grâce à M2M, IoT, et les particularités des filiales conduisaient à une détérioration du time-to-market. L'entreprise a décidé de créer un système d'affaires unique avec une architecture modulaire unique de niveau mondial, en remplacement de 8 systèmes de facturation différents existants.
MegaFon, c'est huit sociétés en une.En 2009, la réorganisation a été achevée : les filiales à travers la Russie se sont unies en une seule entreprise, OAO MegaFon (aujourd'hui, PAO). Ainsi, l'entreprise a acquis 8 systèmes de facturation avec leurs propres solutions « sur mesure », leurs particularités filiales et des structures organisationnelles, IT et marketing variées.
Tout allait bien jusqu'à ce qu'il faille lancer un produit fédéral commun. Cela a entraîné de nombreuses complications : certains avaient une tarification arrondie à l'unité supérieure, d'autres à l'inférieure, et d'autres encore selon la moyenne arithmétique. Il y a des milliers de tels cas.
Malgré le fait qu'il n'y ait qu'une seule version du système de facturation, avec un seul fournisseur, les configurations différaient suffisamment pour que cela prenne du temps. Nous avons essayé de réduire leur nombre et sommes tombés sur un deuxième problème qui est familier à de nombreuses entreprises.
Évolutivité verticale. Même le matériel le plus avancé à l'époque ne répondait pas aux besoins. Nous utilisions du matériel Hewlett-Packard, de la gamme Superdome Hi-End, mais cela ne pouvait pas supporter même deux filiales. Nous souhaitions une évolutivité horizontale sans de grands coûts opérationnels ni d'investissements en capital.
Attente de la croissance du nombre d'abonnés et de services. Les consultants ont longtemps apporté dans le monde des télécoms des récits sur l'IoT et le M2M : il viendra un moment où chaque téléphone et chaque fer à repasser aura une carte SIM, et deux dans le réfrigérateur. Aujourd'hui, nous avons un certain nombre d'abonnés, mais dans un avenir proche, cela sera multiplié par dix.
Défis technologiques
Ces quatre raisons nous ont poussés à apporter des changements significatifs. Il y avait un choix entre la modernisation du système et la conception d'un nouveau système. Nous avons longtemps réfléchi, pris des décisions sérieuses et organisé des appels d'offres. Au final, nous avons décidé de concevoir depuis le début et de relever des défis intéressants — des défis technologiques.
Scalabilité
Si auparavant il y avait, disons, 8 systèmes de facturation pour 15 millions d'abonnés, maintenant cela devait atteindre 100 millions d'abonnés et plus — la charge est beaucoup plus élevée.
Nous sommes devenus comparables en taille aux grands acteurs d'Internet, comme Mail.ru ou Netflix.
Mais le mouvement ultérieur pour augmenter la charge et le nombre d'abonnés a posé des défis sérieux.
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 telles distances, les délais sont déjà significatifs. 150 ms sur les canaux optiques modernes les plus avancés, c'est un peu trop pour une tarification en temps réel, surtout comme celle qui existe actuellement dans les télécoms en Russie. De plus, il est nécessaire de se mettre à jour en une journée de travail, ce qui est problématique avec les différents fuseaux horaires.
Nous ne nous contentons pas de fournir des services par abonnement, nous avons des forfaits complexes, des paquets et différents modificateurs. Nous ne devons pas simplement autoriser ou interdire à l'abonné de parler, mais lui donner un certain quota — comptabiliser les appels et les actions en temps réel de manière à ce qu'il ne s'en aperçoive pas.
Résilience
C'est le revers de la centralisation.
Si nous rassemblons tous les abonnés dans un seul système, toute les événements d'urgence et les catastrophes sont désastreux pour les affaires. C'est pourquoi nous concevons le système afin d'exclure l'impact des pannes sur l'ensemble de la base d'abonnés.
C'est une conséquence encore une fois de l'abandon de la mise à l'échelle verticale. Lorsque nous avons opté pour la mise à l'échelle horizontale, nous avons augmenté le nombre de serveurs de centaines à des milliers. Il faut les gérer et établir une interchangeabilité, automatiser la sauvegarde de l'infrastructure informatique et restaurer le système distribué.
De tels défis intéressants se sont posés à nous. Nous avons conçu un système, et à ce moment-là, nous avons tenté de trouver des meilleures pratiques mondiales pour vérifier dans quelle mesure nous sommes à la pointe, à quel point nous suivons les technologies avancées.
Meilleures pratiques mondiales
Étonnamment, dans le secteur des télécommunications mondial, nous n'avons trouvé aucune référence.
L'Europe a été exclue en raison du nombre d'abonnés et de l'échelle, les États-Unis par rapport à la diversité de ses tarifs. Nous avons regardé un peu en Chine, et trouvé certaines choses en Inde en prenant des spécialistes de Vodafone India.
Pour analyser l'architecture, nous avons rassemblé une Dream Team dirigée par IBM — des architectes de différents domaines. Ces personnes pouvaient évaluer de manière adéquate ce que nous faisons et apporter certaines connaissances à notre architecture.
Échelle
Quelques chiffres pour illustrer.
Nous concevons un système pour 80 millions d'abonnés avec une marge pour un milliard. Ainsi, nous éliminons les futures limites. Ce n'est pas parce que nous prévoyons de conquérir la Chine, mais à cause de l'inondation de l'IoT et de M2M.
300 millions de documents sont traités en temps réel. Bien que nous ayons 80 millions d'abonnés, nous travaillons aussi avec des clients potentiels et ceux qui nous ont quittés, si nous devons recouvrer des créances. Donc, les volumes réels sont nettement plus importants.
2 milliards de transactions modifient quotidiennement le solde — ce sont des paiements, des prélèvements, des appels et d'autres événements. 200 To de données changent activement, un peu plus lentement changent 8 Po de données, et ce n'est pas une archive, mais des données en temps réel dans une facturation unique. L'échelle par centre de données — 5 000 serveurs sur 14 sites.
Stack technologique
Lorsque nous avons planifié l'architecture et commencé à assembler le système, nous avons importé les technologies les plus intéressantes et avancées. Cela a donné un stack technologique familier à tout joueur d'internet et aux entreprises qui créent des systèmes à forte charge.
Le stack est similaire aux stacks d'autres grands acteurs : Netflix, Twitter, Viber. Il se compose de 6 composants, mais nous souhaitons le réduire et l'unifier.
La flexibilité, c'est bien, mais dans une grande entreprise, l'unification est indispensable.
Nous n'avons pas l'intention de remplacer Oracle par Tarantool. Dans les grandes entreprises, c'est une utopie, ou une croisade de 5 à 10 ans avec un résultat incertain. Mais Cassandra et Couchbase peuvent tout à fait être remplacés par Tarantool, et nous y aspirons.
Pourquoi Tarantool ?
Il y a 4 critères simples pour lesquels nous avons choisi cette base de données.
Vitesse. Nous avons réalisé des tests de charge sur des systèmes industriels de MegaFon. Tarantool a gagné — il a montré les meilleures performances.
On ne peut pas dire que d'autres systèmes ne répondent pas aux besoins de MegaFon. Les solutions mémoire actuelles sont si performantes que cette réserve est amplement suffisante pour l'entreprise. Mais nous sommes intéressés à traiter avec un leader, et non avec ceux qui traînent à la traîne, y compris lors des tests de charge.
Tarantool répond aux besoins de l'entreprise même à long terme.
Coût total de possession (TCO). Le support de Couchbase à l'échelle de MegaFon coûte des sommes astronomiques, alors que la situation avec Tarantool est bien plus agréable, et en termes de fonctionnalités, ils sont proches.
Une autre caractéristique agréable qui a un peu influencé notre choix — Tarantool fonctionne mieux que les autres bases de données avec la mémoire. Il montre une efficacité maximale.
Fiabilité. MegaFon investit dans la fiabilité, probablement comme personne d'autre. Donc, lorsque nous avons examiné Tarantool, nous avons compris qu'il fallait le rendre conforme à nos exigences.
Nous avons investi notre temps et nos finances, et avec Mail.ru, nous avons créé une version entreprise, qui est maintenant déjà utilisée dans plusieurs autres entreprises.
Tarantool-entreprise nous a totalement satisfait en matière de sécurité, fiabilité et journalisation.
Partenariat
Le plus important pour moi — le contact direct avec le développeur. C'est exactement cela qui a séduit les gars de Tarantool.
Lorsque vous vous adressez à un développeur, en particulier celui qui travaille avec des clients ancrés, et que vous lui dites que vous avez besoin que la base de données puisse faire ceci, cela et cela, il répond généralement :
— D'accord, mettez les exigences en bas de la pile — peut-être qu'un jour nous les examinerons.
Beaucoup d'entre eux ont une feuille de route pour les 2-3 prochaines années, et y intégrer des demandes est pratiquement impossible, mais les développeurs de Tarantool séduisent par leur transparence, pas seulement avec MegaFon, et adaptent leur système aux besoins des clients. C'est formidable, et nous apprécions beaucoup.
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 de catalogue d'adresses. À l'époque, nous voulions que ce soit un système ressemblant à Yandex.Maps et Google Maps, mais cela a un peu divergé.
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 peu confortables. 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 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. Cela dit, la réactivité est totalement différente — déjà des millisecondes au lieu de secondes.
La seconde application est un sujet à la mode, appelé IT à double vitesse. Tout cela parce que les consultants de chaque coin disent que les entreprises doivent aller dans cette direction.
Il y a ici une couche d'infrastructure, au-dessus il y a des domaines, par exemple, un système de facturation, comme dans les télécoms, des systèmes d'entreprise, des rapports d'entreprise. C'est le noyau que l'on ne doit pas toucher. Bien sûr, on peut, mais en s'assurant paranoïaquement de la qualité, car cela rapporte de l'argent à l'entreprise.
Ensuite, il y a une couche de microservices — ce qui différencie un opérateur ou un autre acteur. Les microservices peuvent être créés rapidement sur la base de certaines caches, en tirant des données de différents domaines. Ici il y a un terrain pour l'expérimentation — si quelque chose ne fonctionne pas, on ferme un microservice et en ouvre un autre. Cela assure vraiment un délai de mise sur le marché réduit et augmente la fiabilité et la rapidité de l'entreprise.
Les microservices sont sans doute le rôle principal de Tarantool chez MegaFon.
Où nous prévoyons d'appliquer Tarantool
Comparé à notre projet de facturation réussi, les programmes de transformation chez Deutsche Telekom, Svaztykom et Vodafone India sont étonnamment dynamiques et créatifs. Dans le processus de mise en œuvre de ce projet, non seulement MegaFon et sa structure ont été transformés, mais Tarantool-enterprise a aussi vu le jour chez Mail.ru, et chez notre fournisseur Nexign (anciennement « Peter-Service ») — BSS Box (solution de facturation prête à l'emploi).
C'est, d'une certaine manière, un projet historique pour le marché russe. On peut le comparer à ce qui est décrit dans le livre de Frederick Brooks « The Mythical Man-Month ». À l'époque, dans les années 60, pour développer le nouveau système d'exploitation OS/360 pour les mainframes, IBM faisait appel à 5 000 personnes. Nous avons moins — 1 800, mais avec nos rayures, et en tenant compte de l'utilisation de l'open source et de nouvelles approches, nous travaillons de manière plus productive.
Ci-dessous, les domaines de facturation ou, pour parler plus largement, — des systèmes d'affaires. Les gens des entreprises connaissent bien le CRM. D'autres systèmes devraient déjà être utilisés par tous : Open API, API Gateway.
Open API
Regardons à nouveau les chiffres et comment Open API fonctionne actuellement. Sa charge est 10 000 transactions par seconde. Étant donné que nous prévoyons de développer activement la couche de microservices et de construire l'API publique de MegaFon, nous attendons une plus grande croissance future précisément dans ce domaine. 100 000 transactions seront certainement atteintes.
Je ne sais pas si nous serons au même niveau que Mail.ru en SSO — ils semblent avoir 1 000 000 transactions par seconde. Leur solution nous intéresse énormément et nous prévoyons d'adopter leur expérience — par exemple, en faisant un backup fonctionnel SSO avec l'aide de Tarantool. Actuellement, les développeurs de Mail.ru s'occupent de cela chez nous.
CRM
Le CRM représente ces 80 millions d'abonnés que nous voulons porter à un milliard, car il y a déjà 300 millions de documents qui incluent trois ans d'historique. Nous attendons vraiment de nouveaux services, et ici le point de croissance est les services connectés. C'est une sphère qui va se développer, car le nombre de services ne fera qu'augmenter. Par conséquent, une histoire sera nécessaire, nous ne voulons pas trébucher là-dessus.
La facturation elle-même en ce qui concerne l'émission des factures, le travail avec les créances clients s'est transformée en un domaine distinct. Pour accroître la productivité, un modèle architectural basé sur l'architecture de domaine a été appliqué..
Le système est divisé en domaines, avec une charge répartie et une résilience assurée. De plus, des travaux ont été réalisés sur une architecture distribuée.
Tout le reste concerne des solutions de niveau entreprise. Dans le stockage des appels - 2 milliards par jour, 60 milliards par mois. Parfois, il faut les recalculer mensuellement, et c'est mieux d'agir rapidement. La surveillance financière est précisément ces 300 millions qui ne cessent de croître : les abonnés changent souvent d'opérateur, augmentant cette part.
Le composant le plus télécom dans la communication mobile est la tarification en ligne. Ce sont ces systèmes qui vous permettent de passer ou de ne pas passer d'appels, prenant des décisions en temps réel. Ici, la charge est de 30 000 transactions par seconde, mais avec 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 où nous prévoyons d'appliquer Tarantool. Le CRM lui-même, bien sûr, est plus large et nous prévoyons de l'appliquer dans le noyau même.
Mon chiffre cible de 100 millions d'abonnés me préoccupe en tant qu'architecte - que se passe-t-il si nous atteignons 101 millions ? Devons-nous tout recommencer ? Pour éviter cela, nous utilisons des caches, tout en augmentant la disponibilité.
En général, il existe deux approches pour appliquer Tarantool. La première - construire tous les caches au niveau des microservices.Il semble que cette voie soit celle qu'emprunte VimpelCom, créant un cache client.
Nous sommes moins dépendants des fournisseurs, nous modifions le noyau BSS, donc nous avons un registre client unifié déjà prêt à l'emploi. Mais nous souhaitons l'élargir. Pour cela, nous appliquons une approche légèrement différente - nous créons des caches à l'intérieur des systèmes.
Ainsi, il y a moins de désynchronisation - un système est responsable à la fois du cache et de la source principale.
Cette méthode s'adapte bien à l'approche Tarantool avec un squelette transactionnel, où seules les parties concernées par les mises à jour sont actualisées, c'est-à-dire les modifications de données. Tout le reste peut être conservé ailleurs. Il n'y a pas de grand data lake, ni de cache global non maîtrisé. Les caches sont conçus pour un système, soit pour des produits, soit pour des clients, soit pour faciliter la vie des opérations. Quand un abonné mécontent de la qualité appelle, nous voulons lui offrir un service de qualité.
RTO et RPO
Dans le domaine de l'informatique, il existe deux termes - RTO et RPO.
Objectif de temps de récupération C'est le temps de récupération du service après une panne. RTO = 0 signifie que même si quelque chose échoue, le service continue de fonctionner.
Objectif de point de récupération C'est le temps de récupération des données, combien de données nous pouvons perdre sur une certaine période. RPO = 0 signifie que nous ne perdons pas de données.
Tâche pour Tarantool
Essayons de résoudre la tâche pour Tarantool.
Donné: un panier de commandes compréhensible pour tous, par exemple sur Amazon ou ailleurs. Exigence que le panier fonctionne 24 heures sur 24, 7 jours sur 7, ou 99,99 % du temps. Les commandes qui nous parviennent doivent maintenir l'ordre, car nous ne pouvons pas désactiver ou activer le service de manière chaotique - tout doit être strictement séquentiel. L'abonnement précédent influence le suivant, donc les données sont importantes - rien ne doit disparaître.
Solution. On peut essayer de résoudre cela frontalement et demander aux développeurs de la base de données, mais la tâche ne se résout pas mathématiquement. On peut se souvenir des théorèmes, des lois de conservation, de la physique quantique, mais pourquoi - elle ne peut pas être résolue au niveau de la base de données.
Ici, le vieux bon principe architectural fonctionne - il faut bien connaître le domaine et, grâce à cela, résoudre cette énigme.
Notre solution : créer un registre distribué des demandes sur Tarantool - un cluster géodistrubué.. Sur le schéma, c'est trois centres de données différents - deux avant l'Oural, un derrière l'Oural, et nous répartissons toutes les demandes entre ces centres.
Chez Netflix, qui est maintenant considéré comme l'un des leaders de l'IT, jusqu'en 2012, il n'y avait qu'un seul centre de données. La veille de Noël catholique, le 24 décembre, ce centre a échoué. Les utilisateurs du Canada et des États-Unis ont été privés de leurs films préférés, se sont beaucoup ennuyés et en ont parlé sur les réseaux sociaux. Maintenant, Netflix a trois centres de données sur la côte ouest-est et un en Europe de l'Ouest.
Nous construisons dès le départ une solution géodistrubuée - la résilience est importante pour nous.
Donc, nous avons un cluster, mais que faire avec RPO = 0 et RTO = 0 ? La solution est simple et dépend du sujet.
Qu'est-ce qui est important dans les demandes ? Deux parties : la constitution du panier AVANT la prise de décision d'achat, et APRÈS. La partie AVANT dans les télécommunications est généralement appelée captation de commande ou négociation de commande. Dans le télécom, cela peut être beaucoup plus compliqué que dans un magasin en ligne, car il faut servir le client, proposer 5 options, et cela prend un certain temps, mais le panier se remplit. À ce moment-là, une défaillance est possible, mais ce n'est pas grave car cela se passe en mode interactif sous la supervision d'une personne.
Si le Data Center de Moscou tombait soudainement en panne, nous continuerions à travailler en basculant automatiquement vers un autre Data Center. Théoriquement, un produit peut être perdu dans le panier, mais vous pouvez le voir, compléter le panier à nouveau et continuer à travailler. Dans ce cas, RTO = 0.
En même temps, il y a une deuxième option : quand 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 motifs différents dans un cas peut être un simple cluster géo-distribué avec un maître commutable, dans un autre cas, un enregistrement basé sur le quorum. Les modèles peuvent varier, mais nous résolvons le problème.
Ensuite, en ayant un registre distribué des demandes, nous pouvons également tout mettre à l'échelle - avoir plusieurs gestionnaires et exécutants qui accèdent à ce registre.
Cassandra et Tarantool ensemble
Il y a encore un autre cas - «vitrine des soldes». Ici, c'est un cas intéressant d'application conjointe de Cassandra et Tarantool.
Nous utilisons Cassandra parce que 2 milliards d'appels par jour - ce n'est pas une limite, et il y en aura plus. Les spécialistes du marketing aiment catégoriser le trafic par sources, il y a de plus en plus de détails sur les réseaux sociaux, par exemple. Tout cela augmente l'historique.
Cassandra permet de s'échelonner horizontalement à n'importe quel volume.
Nous nous sentons à l'aise avec Cassandra, mais elle a un problème - elle n'est pas très efficace pour la lecture. L'écriture se passe bien, 30 000 par seconde n'est pas un problème - le problème réside dans la lecture..
C'est pourquoi nous avons abordé la question du cache, et nous avons également résolu le problème suivant : il existe un ancien cas traditionnel où le matériel des commutateurs pour la tarification en ligne arrive sous forme de fichiers que nous téléchargeons dans Cassandra. Nous avons résolu le problème du téléchargement fiable de ces fichiers, même en suivant les conseils d'un manager de transfert de fichiers d'IBM - il existe des solutions qui gèrent le transfert de fichiers de manière efficace en utilisant le protocole UDP, par exemple, au lieu de TCP. C'est bien, mais cela prend encore des minutes, et tant que nous n'avons pas téléchargé tout cela, l'opérateur du centre d'appel ne peut pas répondre au client sur l'état de son solde - il faut attendre.
Afin d'éviter cela, nous appliquons un réserve fonctionnelle parallèle. Lorsque nous envoyons un événement via Kafka vers Tarantool, recalculant les agrégats en temps réel, par exemple, pour aujourd'hui, nous obtenons un cache des soldes, qui peut fournir des soldes à n'importe quelle vitesse, par exemple, 100 mille transactions par seconde en 2 secondes.
L'objectif est qu'après un appel, le solde modifié apparaisse dans le cabinet personnel en seulement 2 secondes, ainsi que des informations sur pourquoi il a été modifié.
Conclusion
Voici quelques exemples d'utilisation de Tarantool. Nous avons beaucoup aimé la transparence de Mail.ru et leur volonté d'examiner différents cas.
Il est déjà difficile de surprendre les consultants de BCG ou McKinsey, Accenture ou IBM avec quelque chose de nouveau - beaucoup de ce qu'ils proposent, nous le faisons déjà ou l'avons fait, ou prévoyons de le faire. Je pense que Tarantool aura une place respectable dans notre pile technologique et remplacera de nombreuses technologies existantes. Nous sommes en phase active dans le développement de ce projet.
La présentation d'Oleg et d'Andrey est l'une des meilleures de la Tarantool Conference de l'année dernière, et le 17 juin, Oleg Ivlev présentera à la avec le discours . Alexandre Deulin de MégaFon interviendra également avec une présentation . Nous découvrirons ce qui a changé, quels plans ont été réalisés. Rejoignez-nous - la conférence est gratuite, il suffit de . Tous et le programme de la conférence a été établi : nouveaux cas, nouvelles expériences d'utilisation de Tarantool, architecture, entreprise, tutoriels et microservices.
Source : habr.com
