{"id":37650,"date":"2019-10-31T22:18:50","date_gmt":"2019-10-31T19:18:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool\/"},"modified":"2019-10-31T22:18:50","modified_gmt":"2019-10-31T19:18:50","slug":"arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","title":{"rendered":"Next-generation billing architecture: transformation with a transition to Tarantool","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Why does a corporation like MegaFon need Tarantool in billing? From the outside, it seems that typically a vendor comes in, brings a big box, plugs it into the socket\u2014and voil\u00e0, billing! That used to be the case, but now it's archaic, and such dinosaurs have either died out or are dying. Initially, billing was a system for invoicing\u2014a calculator or counter. In modern telecom\u2014it's a system that automates the entire lifecycle of interaction with the subscriber, from contract signing to termination<\/b>, including real-time billing, payment processing, and much more. Billing in telecom companies resembles a battle robot\u2014large, powerful, and equipped with weapons.<\/p>\n

\"Next-generation
\n
\nSo what is the role of Tarantool here? This will be explained by Oleg Ivlev<\/b> and\u00a0Andrey Knyazev<\/b>. Oleg is the chief architect of the company MegaFon<\/a><\/noindex> with extensive experience working for foreign companies, and Andrey is the director of business systems. From their presentation at the\u00a0Tarantool Conference 2018<\/a><\/noindex>\u00a0, you will learn why R&D is needed in corporations, what Tarantool is, how the dead end of vertical scaling and globalization led to the emergence of this database in the company, and about technological challenges, architectural transformation, and how MegaFon's tech stack is similar to that of Netflix, Google, and Amazon.
\n<\/a><\/noindex>
\n

\r\n \"Play\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

The \"Unified Billing\" project<\/h2>\n

\nThe project being discussed is called \u201cUnified Billing.\u201d It is in this project that Tarantool has demonstrated its best qualities. <\/p>\n

\"Next-generation
\n
\nThe growth of Hi-End equipment performance could not keep up with the growth of the subscriber base and the number of services, and a further increase in subscribers and services was expected due to M2M, IoT, and the particularities of the branches leading to a decline in time-to-market. The company decided to create a unified business system with a unique modular architecture of world level, replacing eight current different billing systems.<\/p>\n

MegaFon is eight companies in one<\/b>. In 2009, the reorganization was completed: branches across Russia merged into a single company, OJSC \"MegaFon\" (now PJSC). Thus, the company had eight billing systems with their own custom solutions, branch-specific features, and varying organizational structure, IT, and marketing.<\/p>\n

Everything was fine until we had to launch a common federal product. A lot of difficulties arose: some had billing rounded up, others rounded down, and some did it based on the arithmetic mean. There were thousands of such instances.<\/p>\n

Despite having one billing system version and one supplier, the settings diverged to the extent that it took a long time to patch them together. We tried to reduce their number and encountered a second problem familiar to many corporations.<\/p>\n

Vertical scaling<\/b>. Even the best hardware at the time did not meet our needs. We used Hewlett-Packard equipment from the Superdome Hi-End line, but it couldn't support the requirements of even two branches. We wanted horizontal scaling without significant operational costs and capital investments.<\/p>\n

Expectations of growing the number of subscribers and services<\/b>. Consultants have long been bringing stories about IoT and M2M to the telecom world: times will come when every phone and iron will have a SIM card, and every refrigerator will have two. Today we have a certain number of subscribers, but in the near future, there will be an order of magnitude more.<\/p>\n

Technological challenges<\/h2>\n

\nThese four reasons drove us to significant changes. We faced a choice between modernizing the system and designing from scratch. We thought for a long time, made serious decisions, and held tenders. Ultimately, we decided to design from the ground up and took on interesting challenges \u2014 technological challenges.<\/p>\n

Scalability<\/h3>\n

\nIf before, let's say, there were 8 billings for 15 million subscribers<\/b>, now it had to be 100 million subscribers and more<\/b>\u00a0\u2014 the load is an order of magnitude higher.<\/p>\n

We became comparable in scale to large internet players like Mail.ru or Netflix.<\/p><\/blockquote>\n

\nBut further movement towards increasing the load and subscriber base presented us with serious tasks.<\/p>\n

The geography of our vast country<\/h3>\n

\nBetween Kaliningrad and Vladivostok 7500 km and 10 time zones<\/b>. The speed of light is finite, and at such distances, delays are already significant. 150 ms on the best modern optical channels is quite a lot for real-time billing, especially as it is currently in telecom in Russia. Additionally, updates need to be made within one working day, which is problematic with different time zones.<\/p>\n

We don't just offer subscription services; we have complex plans, packages, and various modifiers. We need to not only enable or disable a subscriber's calls but also provide a specific quota \u2014 to account for calls and actions in real-time so that they do not notice.<\/p>\n

Fault tolerance<\/h3>\n

<\/p>\n

This is the flip side of centralization.<\/p><\/blockquote>\n

\nIf we gather all subscribers in one system, any emergency events and disasters can have dire consequences for the business. This is why we design the system to eliminate the impact of emergencies on the entire subscriber base.<\/p>\n

This is a consequence again of refusing vertical scaling. When we shifted to horizontal scaling, we increased the number of servers from hundreds to thousands. They need to be managed, built for interchangeability, automatically back up the IT infrastructure, and recover the distributed system.<\/p>\n

Such interesting challenges lay ahead of us. We designed the system, and at that moment we tried to find global best practices to check how on-trend we are and how closely we follow the latest technologies.<\/p>\n

Global experience<\/h2>\n

<\/p>\n

Surprisingly, we found no references in global telecom.<\/p><\/blockquote>\n

\nEurope fell short in subscriber numbers and scale, the USA due to the flatness of its tariffs. We looked at something in China and found some insights in India, recruiting specialists from Vodafone India.<\/p>\n

To analyze the architecture, we assembled a Dream Team led by IBM \u2014 architects from various fields. These individuals could adequately assess what we are doing and bring certain knowledge to our architecture.<\/p>\n

Scale<\/h2>\n

\nA few numbers for illustration.<\/p>\n

We design the system for 80 million subscribers with a buffer for one billion<\/b>. This way we eliminate future thresholds. It is not because we plan to conquer China, but due to the surge of IoT and M2M.<\/p>\n

300 million documents are processed in real time<\/b>. Although we have 80 million subscribers, we also work with potential clients and those who have left us, if we need to collect overdue debts. Therefore, the actual volumes are significantly higher.<\/p>\n

2 billion transactions<\/b> change the balance daily \u2014 these are payments, accruals, calls, and other events.\u00a0200 TB of data changes actively<\/b>, slightly slower change 8 PB of data.<\/b>, and this is not an archive, but live data in a single billing system. The scale across and data centers is 5 thousand servers at 14 locations<\/b>.<\/p>\n

Technology stack<\/h2>\n

\nWhen we planned the architecture and began to assemble the system, we imported the most interesting and advanced technologies. The result is a technology stack familiar to any player in the internet and corporations that build high-load systems. <\/p>\n

\"Next-generation
\n
\nThe stack is similar to those of other major players: Netflix, Twitter, Viber. It consists of 6 components, but we want to reduce and unify it.<\/p>\n

Flexibility is good, but in a large corporation, unification is essential.<\/p><\/blockquote>\n

\nWe are not going to replace Oracle with Tarantool. In the realities of large companies, this is utopia, or a crusade lasting 5-10 years with an uncertain outcome. However, Cassandra and Couchbase can indeed be replaced with Tarantool, and we are striving for that.<\/p>\n

Why Tarantool?<\/h2>\n

\nThere are 4 simple criteria why we chose this database.<\/p>\n

Speed<\/b>. We conducted load tests on the industrial systems of MegaFon. Tarantool won - it showed the best performance.<\/p>\n

It cannot be said that other systems do not meet the needs of MegaFon. Current memory solutions are so efficient that they provide ample capacity for the company. However, we are keen on dealing with a leader rather than one who lags behind, including in load testing.<\/p>\n

Tarantool meets the company\u2019s needs even in the long-term perspective.<\/p><\/blockquote>\n

\nTCO (Total Cost of Ownership)<\/b>. Supporting Couchbase at the volumes of MegaFon costs astronomical amounts, while the situation with Tarantool is much more favorable, and their functionality is similar.<\/p>\n

Another nice feature that slightly influenced our choice is that Tarantool works better with memory than other databases. It shows maximum efficiency<\/b>.<\/p>\n

Reliability<\/b>. MegaFon invests in reliability, perhaps like no other. Therefore, when we looked at Tarantool, we realized we needed to make it meet our requirements.<\/p>\n

We invested our time and finances and, together with Mail.ru, created an enterprise version that is now used in several other companies.<\/p>\n

Tarantool-enterprise completely satisfied us in terms of security, reliability, and logging.<\/p><\/blockquote>\n

<\/p>\n

Partnership<\/h3>\n

\nThe most important thing for me is direct contact with the developer<\/b>. This is exactly what won us over from the guys at Tarantool.<\/p>\n

When you approach a player, especially one working with an anchor client, and say that you need the database to do this, that, and the other, they usually respond:<\/p>\n

\u2014 Sure, put the requirements at the bottom of the stack \u2014 we might get to them someday.<\/i><\/p>\n

Many have a roadmap for the next 2-3 years, and it's nearly impossible to fit in, whereas the Tarantool developers are open and not just with MegaFon, adapting their system to the client. It\u2019s great, and we really like it.<\/p>\n

Where we applied Tarantool<\/h2>\n

\nWe use Tarantool in several components. The first is in the pilot<\/b>, which we created on the address catalog system. At one time, we wanted it to be a system similar to Yandex Maps and Google Maps, but it turned out somewhat differently. <\/p>\n

For example, the address catalog in the sales interface. On Oracle, finding the required address takes 12-13 seconds \u2014 uncomfortable figures. When we switch to Tarantool, replacing Oracle with another database in the console and running the same search, we achieve a 200 times speedup! The city pops up after the third letter. We are currently adapting the interface to make this happen after the first letter. Nevertheless, the response speed is completely different \u2014 now it takes milliseconds instead of seconds.<\/p>\n

The second application is the trendy topic called two-speed IT<\/b>. This is because consultants from every angle are saying that corporations should go there.<\/p>\n

\"Next-generation
\n
\nThere is a layer of infrastructure, above which are domains, for example, a billing system like in telecom, corporate systems, corporate reporting. This is the core that should not be disturbed. Of course, you can, but you should be paranoid about ensuring quality, since this brings revenue to the corporation.<\/p>\n

Next comes the microservices layer \u2014 what differentiates the operator or another player. Microservices can be quickly created based on certain caches, pulling data from various domains. Here lies the field for experimentation<\/b>\u00a0\u2014 if something doesn't work out, you shut down one microservice and open another. This truly enhances time-to-market and increases the reliability and speed of the company.<\/p>\n

Microservices are probably Tarantool's main role at MegaFon. <\/p><\/blockquote>\n

<\/p>\n

Where we plan to apply Tarantool<\/h2>\n

\nIn comparison to our successful billing project and transformation programs at Deutsche Telekom, \u0421\u0432\u044f\u0437\u044c\u043a\u043e\u043c and Vodafone India, it is remarkably dynamic and creative. During the implementation of this project, not only MegaFon and its structure underwent transformation but also Tarantool-enterprise emerged at Mail.ru, and our vendor Nexign (formerly '\u041f\u0435\u0442\u0435\u0440-\u0421\u0435\u0440\u0432\u0438\u0441') developed BSS Box (a boxed billing solution).<\/p>\n

This project is, in a sense, historic for the Russian market. It can be compared to what is described in Frederick Brooks' book 'The Mythical Man-Month'. Back in the 1960s, 5,000 people were involved in developing the new operating system OS\/360 for IBM mainframes. We have fewer\u20141,800\u2014yet our team is skilled, and with the use of open source and new approaches, we are working more efficiently.<\/p>\n

Below are the billing domains or, more broadly, the business systems. People from enterprises are well aware of CRM. Other systems should already be adopted by everyone: Open API, API Gateway.<\/p>\n

\"Next-generation
\n<\/p>\n

Open API<\/h3>\n

\nLet\u2019s take another look at the numbers and how Open API operates now. Its load is 10,000 transactions per second<\/b>. Since we plan to actively develop the microservices layer and build MegaFon\u2019s public API, we expect further growth in this area in the future.\u00a0100,000 transactions will definitely be the target.<\/b>.<\/p>\n

I don\u2019t know if we will compare in SSO with Mail.ru\u2014they seem to have 1,000,000 transactions per second. Their solution is extremely interesting to us and we plan to adopt their experience\u2014for instance, by creating a functional SSO reserve using Tarantool. Currently, developers from Mail.ru are working on this for us.<\/p>\n

CRM<\/h2>\n

\nCRM is about those 80 million subscribers we want to grow to a billion because there are already 300 million documents, which include a three-year history. We are genuinely looking forward to new services, and here the growth point is connected services<\/b>. This is a sphere that will continue to expand as services keep increasing. Therefore, we will need a history, and we do not want to stumble on that.<\/p>\n

The billing itself, regarding invoice issuance and working with the clients' accounts receivable has transformed into a separate domain<\/b>. In order to enhance performance, an architectural template of domain architecture has been applied.<\/b>.<\/p>\n

The system is divided into domains, the load is distributed, and redundancy is ensured. Additionally, work has been done on the distributed architecture.<\/p><\/blockquote>\n

\nEverything else is enterprise-level solutions. In the call storage \u2014 2 billion per day<\/b>, 60 billion per month. Sometimes we need to recount them for the month, and it's better to do it quickly. Financial monitoring<\/b>\u00a0\u2014 is exactly those 300 million that keep growing: subscribers often switch between operators, increasing this share.<\/p>\n

The most telecom-like component of mobile communication is online billing.<\/b>These are the systems that allow you to make calls or not, making decisions in real time. The load here is 30,000 transactions per second, but with the growing data transfer we plan 250,000 transactions<\/b>, and therefore we are very interested in Tarantool.<\/p>\n

The previous image shows the domains where we plan to apply Tarantool. The CRM itself, of course, is broader, and we plan to implement it at the core. <\/p>\n

My estimated figure of 100 million subscribers concerns me as an architect \u2014 what if it becomes 101 million? Will we have to redo everything again? To prevent this, we use caches, thereby increasing availability.<\/p>\n

\"Next-generation
\n
\nIn general, there are two approaches to using Tarantool. The first is to build all caches at the microservices level.<\/b>As far as I understand, this is the path VimpelCom is taking, creating a client cache.<\/p>\n

We are less dependent on vendors, changing the BSS core, so we already have a single customer database out of the box. But we want to expand it. Therefore, we apply a slightly different approach \u2014 we make caches within the systems.<\/b>.<\/p>\n

This reduces desynchronization \u2014 one system is responsible for both the cache and the main master source.<\/p><\/blockquote>\n

\nThis method fits well with Tarantool's transactional skeleton, where only the parts related to updates, that is, data changes, are refreshed. Everything else can be stored somewhere else. There is no huge data lake or unmanaged global cache. Caches are designed for the system, or for products, or for clients, or to make life easier for maintenance. When a subscriber upset with quality calls, you want to provide quality service.<\/p>\n

RTO and RPO<\/h2>\n

\nIn IT, there are two terms \u2014 RTO<\/b> and\u00a0RPO<\/b>. <\/p>\n

Recovery time objective<\/b>\u00a0\u2014 this is the service recovery time after a failure. RTO = 0 means that even if something goes down, the service continues to operate.<\/p>\n

Recovery Point Objective<\/b>\u00a0\u2014 this is the data recovery time, how much data we can lose over a specific period. RPO = 0 means that we do not lose data.<\/p>\n

Task for Tarantool<\/h2>\n

\nLet's try to solve a task for Tarantool.<\/p>\n

Given<\/b>: a commonly understood shopping cart, for example, on Amazon or elsewhere. Requirement<\/b> is for the cart to work 24 hours a day, 7 days a week, or 99.99% of the time. Orders coming to us must maintain order, because we cannot chaotically connect or disconnect communication for the subscriber \u2014 everything must be strictly sequential. The previous subscription affects the next one, so data is important \u2014 nothing should be lost.<\/p>\n

Solution<\/b>. One could try to tackle it directly and ask the database developers, but the task is mathematically unsolvable. One might recall theorems, laws of conservation, quantum physics, but why \u2014 it cannot be solved at the database level.<\/p>\n

Here, the good old architectural approach works \u2014 it is necessary to have a good understanding of the subject area to resolve this puzzle.<\/p>\n

\"Next-generation
\n
\nOur solution: we create a distributed registry of applications on Tarantool \u2014 a geo-distributed cluster<\/b>. In the diagram, this shows three different data centers \u2014 two before the Ural Mountains, one behind the Ural Mountains, and we distribute all applications among these centers.<\/p>\n

At Netflix, which is now considered one of the leaders in IT, there was only one data center until 2012. On the eve of Christmas, December 24th, this data center went down. Users in Canada and the US were left without their favorite movies, got quite upset, and wrote about it on social media. Now Netflix has three data centers on the west-east coast and one in Western Europe. <\/p>\n

We are initially building a geo-distributed solution \u2014 fault tolerance is important to us. <\/p><\/blockquote>\n

\nSo, we have a cluster, but how do we deal with RPO = 0 and RTO = 0? The solution is simple, depending on the subject area.<\/p>\n

What is important in applications? Two parts: creating the cart\u00a0BEFORE<\/b> the decision to purchase, and\u00a0AFTER<\/b>. The BEFORE part in telecom is usually referred to as order capturing<\/b> or order negotiation<\/b>In telecommunications, this can be much more complex than in an online store, because you need to serve the customer, offer 5 options, and this all takes some time, but the cart is being filled. At this moment, a failure may occur, but that\u2019s not a big deal because it happens interactively under human supervision. <\/p>\n

If the Moscow data center suddenly goes down, we will continue to operate by switching automatically to another data center. Theoretically, one item in the cart may get lost, but you can see that and refill the cart to continue working. In this case, RTO = 0.<\/p>\n

At the same time, there\u2019s a second option: when we hit 'submit', we want to ensure the data is not lost. From this point, automation kicks in \u2014 this is already RPO = 0. The application of these two different patterns in one case could be a geo-distributed cluster with one switchable master, and in another case, some quorum-based record. The templates can vary, but we solve the problem.<\/p>\n

Furthermore, having a distributed registry of requests allows us to scale this further \u2014 having multiple dispatchers and performers accessing this registry.<\/p>\n

\"Next-generation
\n<\/p>\n

Cassandra and Tarantool together<\/h2>\n

\nThere's another case \u2014 \"balance showcase\"<\/b>. This is precisely an interesting case of the combined use of Cassandra and Tarantool.<\/p>\n

We use Cassandra because 2 billion calls a day is not the limit, and it will only grow. Marketers love to segment traffic by sources, and more details are emerging from social networks, for example. This all increases the history.<\/p>\n

Cassandra allows horizontal scaling to any volume.<\/p><\/blockquote>\n

\nWe feel comfortable with Cassandra, but it has one problem \u2014 it's not great at reading. Writing is okay, 30,000 per second isn't an issue \u2014 the problem lies in reading.<\/b>.<\/p>\n

This is why the topic of caching has arisen, and at the same time we decided to address the following issue: there is an old traditional case where equipment from the switch from online billing comes into files that we upload to Cassandra. We tackled the problem of reliably uploading these files, even applying the advice of an IBM manager for file transfer \u2014 there are solutions that effectively manage file transfers using the UDP protocol, for example, rather than TCP. This is good, but still, we face delays, and until we load all of this, the operator in the call center cannot inform the client about what has happened with their balance \u2014 they have to wait.<\/p>\n

To prevent this from happening, we\u00a0use a parallel functional reserve<\/b>. When we send an event via Kafka to Tarantool, recalculating aggregates in real time, for example, as of today, we get a balance cache<\/b>, which can handle balances at any speed, for example, 100 thousand transactions per second and those very 2 seconds.<\/p>\n

The goal is that after making a call, the personal account shows not only the updated balance within 2 seconds but also information about why it changed.<\/p>\n

Conclusion<\/h2>\n

\nThese were examples of using Tarantool. We really appreciated Mail.ru's openness and their willingness to consider various cases. <\/p>\n

Consultants from BCG or McKinsey, Accenture or IBM are already finding it hard to surprise us with something new \u2014 much of what they offer we are either already doing, have done, or plan to do. I believe that Tarantool will occupy a worthy place in our technology stack and will replace many existing technologies. We are in the active development phase of this project.<\/p>\n

Oleg and Andrey's presentation was one of the best at the Tarantool Conference last year, and on June 17, Oleg Ivlev will present at\u00a0T+ Conference 2019<\/a><\/noindex>\u00a0with the talk \u2018Why Tarantool in Enterprise\u2019<\/a><\/noindex>. Also from MegaFon, Alexander Deulin will present a talk \u2018Tarantool Caches and Replication from Oracle\u2019<\/a><\/noindex>. We'll find out what has changed and what plans have been realized. Join us \u2014 the conference is free, just need to register<\/a><\/noindex>. All presentations are accepted<\/a><\/noindex> and the conference program has been formed: new cases, new experiences of using Tarantool, architecture, enterprise, tutorials, and microservices.<\/p><\/blockquote>\n

Source: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0417\u0430\u0447\u0435\u043c \u0442\u0430\u043a\u043e\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0446\u0438\u0438, \u043a\u0430\u043a \u041c\u0435\u0433\u0430\u0424\u043e\u043d, Tarantool \u0432\u00a0\u0431\u0438\u043b\u043b\u0438\u043d\u0433\u0435? \u0421\u043e \u0441\u0442\u043e\u0440\u043e\u043d\u044b \u043a\u0430\u0436\u0435\u0442\u0441\u044f, \u0447\u0442\u043e \u043e\u0431\u044b\u0447\u043d\u043e \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442 \u0432\u0435\u043d\u0434\u043e\u0440, \u043f\u0440\u0438\u043d\u043e\u0441\u0438\u0442 \u043a\u0430\u043a\u0443\u044e-\u0442\u043e \u0431\u043e\u043b\u044c\u0448\u0443\u044e \u043a\u043e\u0440\u043e\u0431\u043a\u0443, \u0432\u0442\u044b\u043a\u0430\u0435\u0442 \u0448\u0442\u0435\u043a\u0435\u0440 \u0432\u00a0\u0440\u043e\u0437\u0435\u0442\u043a\u0443\u00a0\u2014 \u0432\u043e\u0442 \u0438\u00a0\u0431\u0438\u043b\u043b\u0438\u043d\u0433! \u041a\u043e\u0433\u0434\u0430-\u0442\u043e \u0442\u0430\u043a \u0438\u00a0\u0431\u044b\u043b\u043e, \u043d\u043e\u00a0\u0441\u0435\u0439\u0447\u0430\u0441 \u044d\u0442\u043e \u0430\u0440\u0445\u0430\u0438\u043a\u0430, \u0438\u00a0\u0442\u0430\u043a\u0438\u0435 \u0434\u0438\u043d\u043e\u0437\u0430\u0432\u0440\u044b \u0443\u0436\u0435 \u0432\u044b\u043c\u0435\u0440\u043b\u0438 \u0438\u043b\u0438 \u0432\u044b\u043c\u0438\u0440\u0430\u044e\u0442. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u0431\u0438\u043b\u043b\u0438\u043d\u0433 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043b\u044f \u0432\u044b\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0441\u0447\u0435\u0442\u043e\u0432\u00a0\u2014 \u0441\u0447\u0438\u0442\u0430\u043b\u043a\u0430 \u0438\u043b\u0438 \u043a\u0430\u043b\u044c\u043a\u0443\u043b\u044f\u0442\u043e\u0440. \u0412\u00a0\u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u043c \u0442\u0435\u043b\u0435\u043a\u043e\u043c\u0435\u00a0\u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u0432\u0441\u0435\u0433\u043e \u0436\u0438\u0437\u043d\u0435\u043d\u043d\u043e\u0433\u043e \u0446\u0438\u043a\u043b\u0430 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0441\u00a0\u0430\u0431\u043e\u043d\u0435\u043d\u0442\u043e\u043c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28258,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37650","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Next-Generation Billing Architecture: Transformation with the Transition to Tarantool | ProHoster","description":"Why does a corporation like MegaFon need Tarantool for billing? It may seem like a vendor just brings in a big box, plugs it in, and voil\u00e0 \u2014 billing is ready!","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 \u0431\u0438\u043b\u043b\u0438\u043d\u0433\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043f\u043e\u043a\u043e\u043b\u0435\u043d\u0438\u044f: \u0442\u0440\u0430\u043d\u0441\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u0441 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u043e\u043c \u043d\u0430 Tarantool | ProHoster","og:description":"\u0417\u0430\u0447\u0435\u043c \u0442\u0430\u043a\u043e\u0439 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0446\u0438\u0438, \u043a\u0430\u043a \u041c\u0435\u0433\u0430\u0424\u043e\u043d, Tarantool \u0432 \u0431\u0438\u043b\u043b\u0438\u043d\u0433\u0435? \u0421\u043e \u0441\u0442\u043e\u0440\u043e\u043d\u044b \u043a\u0430\u0436\u0435\u0442\u0441\u044f, \u0447\u0442\u043e \u043e\u0431\u044b\u0447\u043d\u043e \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442 \u0432\u0435\u043d\u0434\u043e\u0440, \u043f\u0440\u0438\u043d\u043e\u0441\u0438\u0442 \u043a\u0430\u043a\u0443\u044e-\u0442\u043e \u0431\u043e\u043b\u044c\u0448\u0443\u044e \u043a\u043e\u0440\u043e\u0431\u043a\u0443, \u0432\u0442\u044b\u043a\u0430\u0435\u0442 \u0448\u0442\u0435\u043a\u0435\u0440 \u0432 \u0440\u043e\u0437\u0435\u0442\u043a\u0443 \u2014 \u0432\u043e\u0442 \u0438 \u0431\u0438\u043b\u043b\u0438\u043d\u0433!","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/arhitektura-billinga-novogo-pokoleniya-transformatsiya-s-perehodom-na-tarantool","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:18:50+00:00","article:modified_time":"2019-10-31T19:18:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37650","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 18:44:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:23:06","updated":"2026-01-23 18:44:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/37650","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=37650"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/37650\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/28258"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=37650"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=37650"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=37650"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}