Por que uma empresa como a MegaFon, Tarantool no faturamento? Do lado de fora, parece que o vendedor geralmente vem, traz uma caixa grande, conecta o plugue à tomada - aqui vem a cobrança! Antes, mas agora é um arcaico, e esses dinossauros já se extinguiram ou estão se extinguindo. Inicialmente, o faturamento é um sistema de faturamento - um leitor ou calculadora. Nas telecomunicações modernas, este é um
sistema para automatizar todo o ciclo de vida da interação com o assinante, desde a celebração do contrato até a rescisão , incluindo cobrança em tempo real, aceitação de pagamento e muito mais. O faturamento nas empresas de telecomunicações é semelhante a um robô de combate - grande, poderoso e cheio de armas.
E aqui está Tarantool?
Oleg Ivlev e
Andrey Knyazev vão falar sobre isso. Oleg é o arquiteto chefe da
MegaFon, com uma vasta experiência trabalhando em empresas estrangeiras, Andrey é o diretor de sistemas de negócios. A partir da transcrição de seu relatório na
Tarantool Conference 2018, você aprenderá por que a pesquisa e o desenvolvimento são necessários nas empresas, o que é Tarantool, como o impasse para o dimensionamento vertical e a globalização se tornou os pré-requisitos para o surgimento desse banco de dados na empresa, sobre desafios tecnológicos, a transformação da arquitetura e como o technostek da MegaFon se assemelha à Netflix, Google e Amazon.
Projeto de faturamento único
O projeto que será discutido é chamado "Faturamento único". Foi nele que Tarantool mostrou suas melhores qualidades.
O crescimento do desempenho dos equipamentos Hi-End não acompanhou o crescimento da base de assinantes e o crescimento no número de serviços, era esperado um maior crescimento no número de assinantes e serviços devido ao M2M, IoT, e os recursos das filiais levaram a uma deterioração do tempo de colocação no mercado. A empresa decidiu criar um sistema comercial unificado com uma arquitetura modular de classe mundial exclusiva, em vez de 8 sistemas de cobrança diferentes atuais.
MegaFon é oito empresas em uma . Em 2009, a reorganização foi concluída: filiais em toda a Rússia se fundiram em uma única empresa MegaFon OJSC (agora PJSC). Assim, a empresa possui 8 sistemas de cobrança com suas próprias soluções “personalizadas”, recursos de filiais e uma estrutura organizacional diferente, TI e marketing.
Tudo estava bem até que eu tive que lançar um produto federal comum. Muitas dificuldades apareceram aqui: para alguns, tarifando o arredondamento, para outros, em menor grau, e para outros, de acordo com a média aritmética. Existem milhares desses momentos.
Apesar do fato de a versão do sistema de cobrança ser a mesma, de um fornecedor, as configurações divergiram para que a cola por muito tempo. Tentamos reduzir o número deles e deparamos com um segundo problema que é familiar para muitas empresas.
Escala vertical . Mesmo o ferro mais frio da época não atendia às necessidades. Usamos o equipamento Hewlett-Packard, a linha Superdome Hi-End, mas isso não exigiu nem duas ramificações. Eu queria escala horizontal sem grandes custos de transação e investimentos de capital.
Expectativa de crescimento no número de assinantes e serviços . Os consultores há muito trazem histórias sobre IoT e M2M para o mundo das telecomunicações: chegará o momento em que cada telefone e ferro de passar terão um cartão SIM e dois na geladeira. Hoje temos um número de assinantes e, em um futuro próximo, haverá uma ordem de magnitude a mais.
Desafios tecnológicos
Esses quatro motivos nos levaram a grandes mudanças. Havia uma escolha entre atualizar o sistema e projetar do zero. Eles pensaram por um longo tempo, tomaram decisões sérias, jogaram propostas. Como resultado, eles decidiram projetar desde o início e assumiram desafios interessantes - desafios tecnológicos.
Escalabilidade
Se antes existiam, digamos,
8 contas de faturamento para 15 milhões de assinantes , e agora
100 milhões de assinantes e mais deveriam ter
saído - a carga é uma ordem de magnitude maior.
Nós nos tornamos comparáveis em escala aos principais players da Internet, como Mail.ru ou Netflix.
Porém, mais movimentos para aumentar a carga e a base de assinantes representaram sérios desafios para nós.
A geografia do nosso vasto país
Entre Kaliningrado e Vladivostok,
7500 km e 10 fusos horários . A velocidade da luz é finita e a esse atraso as distâncias já são significativas. 150 ms nos canais ópticos modernos mais legais é um pouco demais para o faturamento em tempo real, especialmente como agora nas telecomunicações na Rússia. Além disso, você precisa atualizar em um dia útil e com fusos horários diferentes - isso é um problema.
Não fornecemos apenas serviços por uma taxa mensal, temos tarifas complexas, pacotes e vários modificadores. Precisamos não apenas permitir ou proibir o assinante de falar, mas dar a ele uma certa cota - calcular chamadas e ações em tempo real para que ele não perceba.
Tolerância a falhas
Este é o outro lado da centralização.
Se coletarmos todos os assinantes em um sistema, quaisquer eventos e desastres de emergência serão desastrosos para os negócios. Portanto, projetamos o sistema de forma a excluir o efeito de acidentes em toda a base de assinantes.
Isso é novamente uma consequência da rejeição da escala vertical. Quando entramos no dimensionamento horizontal, aumentamos o número de servidores de centenas para milhares. Eles precisam ser gerenciados e intercambiáveis, com backup automático da infraestrutura de TI e sistema distribuído restaurado.
Desafios tão interessantes nos confrontaram. Projetamos o sistema e, naquele momento, tentamos encontrar as melhores práticas do mundo para verificar o quanto estamos em tendência, o quanto seguimos tecnologias avançadas.
Experiência mundial
Surpreendentemente, no mundo das telecomunicações, não encontramos uma única referência.
A Europa caiu pelo número de assinantes e escala, os Estados Unidos - pelo plano de suas tarifas. Vimos algo na China, mas encontramos algo na Índia e levamos especialistas da Vodafone India.
Para analisar a arquitetura, o Dream Team foi montado, liderado pela IBM, arquitetos de várias áreas. Essas pessoas podem avaliar adequadamente o que estamos fazendo e trazer certo conhecimento à nossa arquitetura.
Escala
Alguns números para ilustrar.
Projetamos um sistema para
80 milhões de assinantes com uma reserva de um bilhão . Portanto, removemos os limites futuros. Isso não ocorre porque vamos dominar a China, mas devido à pressão da IoT e M2M.
300 milhões de documentos são processados em tempo real . Embora tenhamos 80 milhões de assinantes, trabalhamos com clientes em potencial e aqueles que nos deixaram, se precisarmos receber recebíveis. Portanto, os volumes reais são muito maiores.
2 bilhões de transações diariamente alteram o saldo - são pagamentos, cobranças, chamadas e outros eventos.
200 TB de dados mudam ativamente ,
8 PB de dados mudam um pouco mais devagar, e isso não é um arquivo morto, mas dados ativos em um único faturamento. A escala do data
center é de
5 mil servidores em 14 sites .
Pilha de tecnologia
Quando planejamos a arquitetura e montamos o sistema, importamos as tecnologias mais interessantes e avançadas. O resultado foi uma pilha tecnológica familiar a qualquer player da Internet e empresas que fabricam sistemas altamente carregados.
A pilha é semelhante às pilhas de outros grandes players: Netflix, Twitter, Viber. É composto por 6 componentes, mas queremos reduzi-lo e unificá-lo.
A flexibilidade é boa, mas em uma grande corporação não há meio sem unificação.
Não vamos mudar o mesmo Oracle para Tarantool. Nas realidades das grandes empresas, isso é utopia ou uma cruzada por 5 a 10 anos com um resultado incompreensível. Mas Cassandra e Couchbase podem ser substituídos por Tarantool, e estamos comprometidos com isso.
Porquê Tarantool?
Existem 4 critérios simples para escolhermos esse banco de dados.
Velocidade . Realizamos testes de estresse nos sistemas industriais MegaFon. O Tarantool venceu - mostrou o melhor desempenho.
Isso não quer dizer que outros sistemas não atendam às necessidades do MegaFon. As soluções atuais de memória são tão produtivas que esse estoque da empresa é mais que suficiente. Mas estamos interessados em lidar com o líder, e não com quem tece na cauda, incluindo o teste de carga.
Tarantool cobre as necessidades da empresa, mesmo a longo prazo.
Custo de TCO . O suporte ao Couchbase nos volumes MegaFon custa muito espaço, com o Tarantool a situação é muito mais agradável e, em termos de funcionalidade, eles estão próximos.
Outro recurso interessante que influenciou levemente a nossa escolha - o Tarantool funciona melhor que outros bancos de dados com memória. Mostra
eficiência máxima .
Confiabilidade O MegaFon é investido em confiabilidade, provavelmente como nenhum outro. Portanto, quando analisamos o Tarantool, percebemos o que precisa ser feito para satisfazer nossos requisitos.
Investimos nosso tempo e finanças e, juntamente com o Mail.ru, criamos uma versão corporativa, que agora é usada por várias outras empresas.
A empresa Tarantool nos satisfez totalmente com segurança, confiabilidade e registro.
Parceria
O mais importante para mim é
o contato direto com o desenvolvedor . Isso é exatamente o que os caras do Tarantool subornaram.
Se você procura um jogador, especialmente aquele que trabalha com um cliente âncora, e diz que precisa do banco de dados para poder fazer isso, isso e aquilo, geralmente responde:
- Bem, coloque os requisitos embaixo da pilha - algum dia, provavelmente, chegaremos a eles.Muitos têm um roteiro para os próximos 2-3 anos, e é quase impossível integrá-lo, e os desenvolvedores do Tarantool subornam com abertura, e não apenas com o MegaFon, e adaptam seu sistema ao cliente. Isso é legal e nós realmente gostamos.
Onde aplicamos Tarantool
Em nós Tarantool é usado em vários elementos.
O primeiro está no piloto , que fizemos no sistema de diretório de endereços. Ao mesmo tempo, eu queria que fosse um sistema semelhante ao Yandex.Maps e ao Google Maps, mas ficou um pouco diferente.
Por exemplo, o diretório de endereço na interface de vendas. No Oracle, a localização do endereço necessário leva de 12 a 13 s. - números desconfortáveis. Quando mudamos para o Tarantool, substituímos o Oracle por outro banco de dados no console e realizamos a mesma pesquisa, obtemos uma aceleração de 200 vezes! A cidade aparece após a terceira letra. Agora estamos adaptando a interface para que isso aconteça após o primeiro. No entanto, a velocidade de resposta é completamente diferente - já milissegundos em vez de segundos.
O segundo aplicativo é um tópico moderno chamado TI de duas velocidades . Isso ocorre porque consultores de cada empresa dizem que as empresas devem ir para lá.
Há uma camada de infraestrutura, domínios acima dela, por exemplo, um sistema de cobrança, como telecomunicações, sistemas corporativos, relatórios corporativos. Este é o núcleo que não precisa ser tocado. É claro que isso é possível, mas é paranóico em fornecer qualidade, porque traz dinheiro para a corporação.
Em seguida, vem a camada de microsserviços - aquela que diferencia o operador ou outro jogador. Os microsserviços podem ser criados rapidamente com base em certos caches, levantando dados de diferentes domínios. Aqui está um
campo para experimentos - se algo não der certo, feche um microsserviço, abra outro. Isso fornece um time-to-market verdadeiramente aprimorado e aumenta a confiabilidade e a velocidade da empresa.
Microsserviços é talvez o principal papel do Tarantool no MegaFon.
Onde planejamos aplicar o Tarantool
Se compararmos nosso projeto de cobrança bem-sucedido com os programas de transformação da Deutsche Telekom, Svyazkome, Vodafone Índia, é surpreendentemente dinâmico e criativo. No processo de implementação deste projeto, não apenas o MegaFon e sua estrutura foram transformadas, mas também a empresa Tarantool apareceu no Mail.ru, e nosso fornecedor Nexign (anteriormente Peter-Service) tinha uma BSS Box (solução de cobrança em caixa).
De certa forma, este é um projeto histórico para o mercado russo. Pode ser comparado com o que é descrito no livro de Frederick Brooks "Mythical Man-Month". Então, nos anos 60, a IBM atraiu 5.000 pessoas para desenvolver um novo sistema operacional OS / 360 para mainframes. Temos menos - 1.800, mas os nossos estão em coletes e, levando em consideração o uso de código aberto e novas abordagens, trabalhamos de maneira mais produtiva.
Os domínios de cobrança ou, de forma mais ampla, os sistemas comerciais são exibidos abaixo. As pessoas da empresa conhecem muito bem o CRM. Todos já devem ter outros sistemas: API aberta, API de gateway.
API aberta
Vejamos novamente os números e como a API aberta funciona agora. Sua carga é de
10.000 transações por segundo . Como planejamos desenvolver ativamente a camada de microsserviços e criar a API pública MegaFon, esperamos mais crescimento no futuro nesta parte específica.
100.000 transações serão definitivamente .
Não sei se o SSO é comparável ao Mail.ru - os caras, tipo, têm 1.000.000 de transações por segundo. Estamos extremamente interessados em sua solução e planejamos aprender com a experiência deles - por exemplo, para fazer uma reserva de SSO funcional usando Tarantool. Agora, os desenvolvedores do Mail.ru estão fazendo isso conosco.
CRM
CRM - esses são os 80 milhões de assinantes que queremos trazer para um bilhão, porque já existem 300 milhões de documentos que incluem uma história de três anos. Estamos realmente ansiosos por novos serviços, e aqui
o ponto de crescimento são os serviços conectados . Esta é uma bola que crescerá, porque haverá mais e mais serviços. Por conseguinte, será necessária uma história, não queremos tropeçar nisso.
Faturando-se em termos de faturamento, trabalhando com contas a receber de clientes foi
transformado em um domínio separado . Para maximizar o desempenho, o
modelo de arquitetura da arquitetura de domínio é aplicado .
O sistema é dividido em domínios, a carga é distribuída e a tolerância a falhas é fornecida. Além disso, trabalhamos com arquitetura distribuída.
Tudo o resto são soluções de nível empresarial. Na loja de chamadas -
2 bilhões por dia , 60 bilhões por mês. Às vezes, é necessário recontá-las por um mês, e melhor rapidamente.
O monitoramento financeiro é precisamente os 300 milhões que crescem e crescem constantemente: os assinantes costumam correr entre as operadoras, aumentando essa parte.
O componente de telecomunicações mais importante das comunicações móveis é o
faturamento online . Estes são os sistemas que permitem ligar ou não ligar, tomar uma decisão em tempo real. Aqui, a carga é de 30.000 transações por segundo, mas, considerando o crescimento da transferência de dados, planejamos
250.000 transações e, portanto, estamos muito interessados no Tarantool.
A imagem anterior é dos domínios em que vamos usar o Tarantool. O próprio CRM, é claro, é mais amplo e vamos aplicá-lo no próprio núcleo.
Nosso TTX estimado de 100 milhões de assinantes me confunde como arquiteto - e se 101 milhões? Refazer tudo de novo? Para evitar isso, usamos caches, ao mesmo tempo aumentando a acessibilidade.
Em geral, existem duas abordagens para o uso do Tarantool. O primeiro é
criar todos os caches no nível do microsserviço . Pelo que entendi, o VimpelCom segue esse caminho, criando um cache de cliente.
Somos menos dependentes de fornecedores, estamos mudando o núcleo do BSS, por isso temos um único índice de cartão de cliente pronto para uso. Mas queremos bordar. Portanto, usamos uma abordagem um pouco diferente -
fazemos caches dentro dos sistemas .
Portanto, há menos de um rassynchron - um sistema é responsável pelo cache e pela fonte principal principal.
O método se adapta bem à abordagem do esqueleto transacional Tarantool, quando apenas as partes relacionadas às atualizações, ou seja, alterações de dados, são atualizadas. Todo o resto pode ser armazenado em outro lugar. Não há um lago de dados enorme, cache global não gerenciado. Os caches são projetados para o sistema, seja para produtos ou para clientes, ou para facilitar a vida do serviço. Quando um assinante chama chateado pela qualidade, quero atendê-lo qualitativamente.
RTO e RPO
Existem dois termos em TI -
RTO e
RPO .
O objetivo do tempo de recuperação é o tempo para recuperar um serviço após uma falha. RTO = 0 significa que, mesmo que algo caia, o serviço continuará funcionando.
O objetivo do ponto de recuperação é o tempo para recuperar dados, quantos dados podemos perder por um período de tempo. RPO = 0 significa que não estamos perdendo dados.
Desafio Tarantool
Vamos tentar resolver o problema do Tarantool.
Dado : todo mundo entende a cesta de aplicativos, por exemplo, na Amazon ou em outro lugar.
A cesta é
obrigada a funcionar 24 horas, 7 dias por semana, ou 99,99% do tempo. Os pedidos que chegam até nós devem manter a ordem, porque não podemos ativar ou desativar a comunicação aleatoriamente para o assinante - tudo deve ser estritamente consistente. A assinatura anterior afeta a próxima, portanto os dados são importantes - nada deve ser perdido.
Solução . Você pode tentar resolvê-lo e perguntar aos desenvolvedores do banco de dados, mas o problema não é matematicamente resolvido. Pode-se lembrar teoremas, leis de conservação, física quântica, mas por que - não pode ser resolvido no nível do BD.
A boa e antiga abordagem arquitetônica funciona aqui - você precisa conhecer bem a área de assunto e às suas custas resolver esse rebus.
Nossa solução: crie um registro distribuído de aplicativos para o Tarantool - um cluster distribuído geograficamente . No diagrama, são três centros de dados diferentes - dois para os Urais, um além dos Urais, e distribuímos todos os aplicativos para esses centros.
A Netflix, hoje considerada uma das líderes em TI, tinha apenas um data center até 2012. Na véspera do Natal católico em 24 de dezembro, esse data center caiu. Os usuários do Canadá e dos Estados Unidos ficaram sem seus filmes favoritos, muito chateados e escreveram sobre isso nas redes sociais. A Netflix agora tem três data centers na costa oeste-leste e um na Europa ocidental.
Inicialmente, criamos uma solução distribuída geograficamente - a tolerância a falhas é importante para nós.
Portanto, temos um cluster, mas e RPO = 0 e RTO = 0? A solução é simples, dependendo do assunto.
O que é importante nas aplicações? Duas partes: jogando a cesta
antes de tomar uma decisão de compra e depois. Uma parte do DO em uma telecom é geralmente chamada de
captura ou
negociação de pedidos . No setor de telecomunicações, isso pode ser muito mais complicado do que na loja on-line, porque é necessário atender o cliente, oferecer cinco opções e tudo isso acontece por um tempo, mas a cesta está cheia. Nesse ponto, uma falha é possível, mas não é assustadora, porque ocorre de modo interativo sob a supervisão de uma pessoa.
Se o data center de Moscou falhar repentinamente, e depois mudar automaticamente para outro data center, continuaremos trabalhando. Teoricamente, um produto em uma cesta pode ser perdido, mas você vê isso, complemente a cesta novamente e continue trabalhando. Nesse caso, RTO = 0.
No mesmo momento, existe uma segunda opção: quando clicamos em "enviar", queremos que os dados não sejam perdidos. A partir desse momento, a automação começa a funcionar - isso já é RPO = 0. A aplicação desses dois padrões diferentes em um caso pode ser apenas um cluster distribuído geograficamente com um mestre comutável, no outro caso, algum tipo de entrada de quorum. Os padrões podem variar, mas resolvemos o problema.
Além disso, com um registro distribuído de aplicativos, também podemos dimensionar tudo - para ter muitos despachantes e contratados que acessam esse registro.
Cassandra e Tarantool juntos
Há outro caso - a
"vitrine de saldos" . Aqui está apenas um caso interessante do uso conjunto de Cassandra e Tarantool.
Usamos o Cassandra, porque 2 bilhões de chamadas por dia não é o limite e haverá mais. Os profissionais de marketing gostam de colorir o tráfego por fonte; há mais e mais detalhes nas redes sociais, por exemplo. Isso tudo aumenta a história.
Cassandra permite que você dimensione horizontalmente para qualquer volume.
Nos sentimos confortáveis com Cassandra, mas ela tem um problema - ela não é boa em ler. , 30 000 —
.
, : , - , Cassandra. , IBM manager file transfer — , , UDP, , TCP. , , , - , — .
,
. Kafka Tarantool, , , ,
, , , 100 2 .
, 2 , , .
Conclusão
Tarantool. Mail.ru, .
BCG McKinsey, Accenture IBM - — , , , , . , Tarantool . .
— Tarantool Conference , 17 T+ Conference 2019 « Tarantool Enterprise» . « Tarantool Oracle» . , , . — , . : , Tarantool, , , .