Por que uma corporação como a MegaFon precisaria do Tarantool na cobrança? À primeira vista, parece que um fornecedor chega, traz uma grande caixa, conecta o plugue na tomada — e está feita a cobrança! Antigamente era assim, mas agora isso é obsoleto, e esses dinossauros já estão extintos ou em processo de extinção. Inicialmente, a cobrança era um sistema para emissão de faturas — uma contagem ou calculadora. No telecomunicações moderna, é um sistema de automação de todo o ciclo de vida de interação com o assinante, desde a assinatura do contrato até a rescisão, incluindo tarifação em tempo real, aceitação de pagamentos e muito mais. A cobrança em empresas de telecomunicações se assemelha a um robô de combate — grande, poderoso e armado até os dentes.
E qual é a relação com o Tarantool? Sobre isso falam Oleg Ivlev e Andrei Knyazyev. Oleg é o arquiteto-chefe da empresa com vasta experiência em empresas estrangeiras, e Andrei é o diretor de sistemas de negócios. A partir da transcrição de sua apresentação na , você entenderá por que o R&D é necessário nas corporações, o que é o Tarantool, como o impasse da escalabilidade vertical e a globalização criaram as condições para o surgimento deste banco de dados na empresa, os desafios tecnológicos, a transformação da arquitetura e como a pilha tecnológica da MegaFon se assemelha à da Netflix, Google e Amazon.
O projeto "Cobrança Única"
O projeto do qual vamos falar se chama "Cobrança Única". É nele que o Tarantool demonstrou suas melhores qualidades.
O crescimento da performance do equipamento Hi-End não acompanhou o aumento da base de assinantes e do número de serviços, e esperava-se um crescimento adicional do número de assinantes e serviços devido ao M2M, IoT, além disso, peculiaridades regionais levaram a um aumento no tempo de colocação no mercado. A empresa decidiu criar um sistema de negócios único com uma arquitetura modular exclusiva de nível mundial, em substituição a 8 sistemas de cobrança diferentes.
MegaFon é oito empresas em uma. Em 2009, concluiu-se a reorganização: filiais em toda a Rússia se uniram em uma única empresa, a OAO "MegaFon" (atualmente PАО). Assim, a empresa passou a contar com 8 sistemas de cobrança com suas próprias soluções "personalizadas", peculiaridades regionais e estruturas organizacionais, TI e marketing variadas.
Tudo estava bem até que tivemos que lançar um produto federal comum. Aqui surgiram muitas dificuldades: alguns têm tarifação arredondada para cima, outros para baixo, e alguns - pela média aritmética. São milhares de situações como essas.
Apesar de a versão do sistema de billing ser única, com um único fornecedor, as configurações divergem de tal forma que é complicado unificá-las. Tentamos reduzir o número delas e nos deparamos com um segundo problema, que é familiar para muitas corporações.
Escalonamento vertical. Mesmo o hardware mais avançado na época não atendia às necessidades. Usávamos equipamentos da Hewlett-Packard, da linha Superdome Hi-End, mas não suportavam nem as demandas de duas filiais. Precisávamos de escalonamento horizontal sem grandes custos operacionais ou investimentos de capital.
Expectativa de crescimento no número de assinantes e serviços. Os consultores já trouxeram para o mundo telecom relatos sobre IoT e M2M: chegará o tempo em que cada telefone e ferro de passar terá um cartão SIM, e cada geladeira terá dois. Hoje temos um certo número de assinantes, e no futuro próximo, haverá uma ordem de magnitude a mais.
Desafios tecnológicos
Essas quatro razões nos levaram a mudanças sérias. Havia uma escolha entre modernizar o sistema e projetar do zero. Pensamos muito, tomamos decisões sérias e realizamos concorrências. No final, decidimos projetar desde o início e nos deparamos com desafios interessantes - desafios tecnológicos.
Escalabilidade
Se antes tínhamos, digamos, 8 billings com 15 milhões de assinantes, agora deveríamos ter 100 milhões de assinantes ou mais — a carga seria significativamente maior.
Nos tornamos comparáveis em escala a grandes players da internet, como Mail.ru ou Netflix.
Mas o avanço na carga e na base de assinantes nos colocou diante de desafios sérios.
A geografia do nosso imenso país
Entre Kaliningrado e Vladivostok 7500 km e 10 fusos horários. A velocidade da luz é finita e, em tais distâncias, os delays já são significativos. 150 ms nos canais ópticos mais avançados é demais para tarifação em tempo real, especialmente como é atualmente no telecom na Rússia. Além disso, é necessário atualizá-lo em um dia útil, e com diferentes fusos horários, isso se torna um problema.
Nós não apenas oferecemos serviços por assinatura, mas temos tarifas complexas, pacotes e diferentes modificadores. Precisamos não apenas permitir ou proibir que o assinante faça chamadas, mas lhe dar uma cota específica — calcular chamadas e ações em tempo real de modo que ele não perceba.
Resiliência
Esse é o reverso da centralização.
Se reunimos todos os assinantes em um único sistema, qualquer evento de emergência e catástrofes será desastroso para os negócios. Portanto, projetamos o sistema para eliminar a influência de falhas sobre toda a base de assinantes.
Isso é, novamente, uma consequência da renúncia ao escalonamento vertical. Quando adotamos o escalonamento horizontal, aumentamos o número de servidores de centenas para milhares. Precisamos gerenciá-los e estabelecer intercambiabilidade, automatizar a reserva da infraestrutura de TI e restaurar o sistema distribuído.
Desafios interessantes estavam diante de nós. Projetamos o sistema e, nesse momento, tentamos encontrar práticas de ponta mundiais para verificar quão atualizados estamos, quão em conformidade estamos com as tecnologias avançadas.
Experiência mundial
Surpreendentemente, na telecomunicação global, não encontramos nenhuma referência.
A Europa ficou de fora em termos de quantidade de assinantes e escala, os EUA em termos de estrutura de suas tarifas. Olhamos algo na China e encontramos um pouco na Índia, trazendo especialistas da Vodafone Índia.
Para analisar a arquitetura, reunimos uma Dream Team liderada pela IBM — arquitetos de várias áreas. Essas pessoas foram capazes de avaliar adequadamente o que estamos fazendo e trazer certos conhecimentos para a nossa arquitetura.
Escala
Alguns números para ilustrar.
Estamos projetando o sistema para 80 milhões de assinantes, com uma margem para um bilhão. Assim, eliminamos futuros limites. Não é porque planejamos conquistar a China, mas devido à pressão do IoT e M2M.
300 milhões de documentos são processados em tempo real. Embora tenhamos 80 milhões de assinantes, estamos também lidando com clientes potenciais e aqueles que nos deixaram, se necessário, para recuperar dívida. Portanto, os volumes reais são significativamente maiores.
2 bilhões de transações mudam diariamente o saldo — isso inclui pagamentos, lançamentos, chamadas e outros eventos. 200 TB de dados mudam ativamente, mudam um pouco mais lentamente 8 PB de dados, e isso não é um arquivo, mas dados ao vivo em uma única cobrança. A escala por centros de dados é 5 mil servidores em 14 locais.
Pilha tecnológica
Quando planejamos a arquitetura e começamos a construir o sistema, importamos as tecnologias mais interessantes e avançadas. O resultado foi uma pilha tecnológica familiar para qualquer jogador da internet e corporações que desenvolvem sistemas de alto desempenho.
A pilha é semelhante às pilhas de outros grandes players: Netflix, Twitter, Viber. Consiste em 6 componentes, mas queremos reduzi-la e unificá-la.
Flexibilidade é boa, mas em uma grande corporação a unificação é essencial.
Não estamos planejando trocar o mesmo Oracle pelo Tarantool. Na realidade de grandes empresas, isso é uma utopia, ou uma cruzada que pode levar de 5 a 10 anos, com um desfecho incerto. Mas o Cassandra e o Couchbase podem ser facilmente substituídos pelo Tarantool, e estamos avançando nesse sentido.
Por que Tarantool?
Existem 4 critérios simples que nos levaram a escolher esse banco de dados.
Velocidade. Realizamos testes de carga em sistemas industriais da MegaFon. O Tarantool venceu, mostrando o melhor desempenho.
Não se pode dizer que outros sistemas não atendem às necessidades da MegaFon. As soluções atuais em memória são tão eficientes que essa margem é mais do que suficiente para a empresa. Mas estamos interessados em lidar com um líder, e não com quem fica atrás, inclusive no teste de carga.
O Tarantool atende às necessidades da empresa mesmo a longo prazo.
Custo total de propriedade (TCO). O suporte ao Couchbase em volumes da MegaFon custa uma fortuna, enquanto a situação com o Tarantool é muito mais agradável, sendo que em funcionalidade eles são semelhantes.
Outra característica agradável que influenciou nossa escolha é que o Tarantool trabalha melhor com a memória do que os outros bancos. Ele demonstra máxima eficiência.
Confiabilidade. A MegaFon investe em confiabilidade, talvez mais do que qualquer outra. Portanto, ao analisarmos o Tarantool, percebemos que precisamos garantir que ele atenda às nossas exigências.
Investimos nosso tempo e finanças, e junto com a Mail.ru criamos uma versão enterprise, que agora já está sendo utilizada em várias outras empresas.
O Tarantool-enterprise atendeu totalmente nossas necessidades em termos de segurança, confiabilidade e registro de logs.
Parceria
O mais importante para mim é o contato direto com o desenvolvedor. Isso é exatamente o que os caras do Tarantool conquistaram.
Se você chega até um jogador, especialmente um que trabalha com um cliente âncora, e diz que precisa que o banco de dados faça isso, isso e aquilo, geralmente ele responde:
— Tudo bem, coloque os requisitos na parte inferior daquela pilha — talvez um dia consigamos chegar até eles.
Muitos têm um roadmap para os próximos 2-3 anos, e é praticamente impossível se integrar a isso, enquanto os desenvolvedores do Tarantool encantam pela abertura, não apenas com a Megafon, e adaptam seu sistema às necessidades do cliente. Isso é incrível, e gostamos muito.
Onde aplicamos o Tarantool
Usamos o Tarantool em vários elementos. O primeiro — no piloto, que fizemos no sistema de catálogo de endereços. Na época, queríamos que fosse um sistema semelhante ao Yandex.Maps e Google Maps, mas acabou saindo um pouco diferente.
Por exemplo, o catálogo de endereços na interface de vendas. No Oracle, a busca pelo endereço correto leva de 12 a 13 segundos — números desconfortáveis. Quando mudamos para o Tarantool, substituímos o Oracle por outro banco de dados no console e realizamos a mesma busca, obtendo 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 a primeira. No entanto, a velocidade de resposta é completamente diferente — já são milissegundos em vez de segundos.
A segunda aplicação — um tema corrente, chamado de TI de dupla velocidade. Tudo porque consultores de várias fontes dizem que as corporações deveriam seguir nessa direção.
Aqui há uma camada de infraestrutura, acima da qual estão os domínios, por exemplo, um sistema de faturamento, como no setor de telecomunicações, sistemas corporativos, relatórios corporativos. Este é o núcleo, que não deve ser tocado. Ou seja, claro que pode, mas é preciso garantir a qualidade de forma quase paranoica, porque isso traz dinheiro para a corporação.
Em seguida, vem a camada de microsserviços — o que diferencia o operador ou outro jogador. Os microsserviços podem ser rapidamente criados com base em determinados caches, obtendo dados de diferentes domínios. Aqui existe espaço para experimentos — se algo não deu certo, fechei um microsserviço, abri outro. Isso realmente proporciona um aumento significativo no time-to-market e melhora a confiabilidade e a velocidade da empresa.
Os microsserviços são, sem dúvida, o papel principal do Tarantool na Megafon.
Onde planejamos aplicar o Tarantool
Comparando nosso projeto de faturamento bem-sucedido com os programas de transformação da Deutsche Telekom, Svjaznoy e Vodafone Índia, ele é surpreendentemente dinâmico e criativo. No processo de implementação desse projeto, não apenas a MegaFon e sua estrutura foram transformadas, mas também surgiu o Tarantool-enterprise na Mail.ru, e nosso fornecedor Nexign (anteriormente 'Peter-Service') lançou o BSS Box (solução de faturamento de caixa).
Este é, de certa forma, um projeto histórico para o mercado russo. Pode ser comparado ao que está descrito no livro de Frederick Brooks 'O Mythical Man-Month'. Naquela época, nos anos 60, para desenvolver um novo sistema operacional OS/360 para mainframes, a IBM recrutou 5.000 pessoas. Temos menos – 1.800, mas estamos à altura, e considerando o uso de código aberto e novas abordagens, somos mais produtivos.
Abaixo estão os domínios de faturamento ou, se falarmos de forma mais ampla, – sistemas de negócios. As pessoas da área de enterprise conhecem bem o CRM. Outras sistemas devem ser comuns a todos: Open API, API Gateway.
Open API
Vamos novamente olhar os números e como o Open API está funcionando agora. Sua carga é de 10.000 transações por segundo. Como planejamos desenvolver ativamente a camada de microsserviços e construir a API pública da MegaFon, esperamos um crescimento ainda maior no futuro exatamente nesta parte. 100.000 transações com certeza será..
Não sei se conseguiremos nos igualar à Mail.ru em SSO – eles têm, aparentemente, 1.000.000 transações por segundo. A solução deles nos interessa muito e planejamos absorver sua experiência – por exemplo, criando uma reserva funcional de SSO com o Tarantool. Atualmente, os desenvolvedores da Mail.ru estão trabalhando nisso conosco.
CRM
CRM é a mesma base de 80 milhões de assinantes que queremos levar a um bilhão, pois já temos 300 milhões de documentos que incluem três anos de histórico. Estamos realmente esperando novos serviços, e aqui o ponto de crescimento são os serviços conectados. Este é um domínio que vai crescer, porque haverá cada vez mais serviços. Portanto, precisaremos de um histórico, e não queremos tropeçar nisso.
O faturamento, na parte de emissão de faturas e gerenciamento de contas a receber dos clientes transformou-se em um domínio separado. Para ampliar a produtividade, um padrão arquitetônico de arquitetura de domínio foi aplicado..
O sistema é dividido em domínios, a carga é distribuída e a tolerância a falhas é garantida. Além disso, foi realizado trabalho com arquitetura distribuída.
Tudo o mais são soluções de nível enterprise. No armazenamento de chamadas – 2 bilhões por dia, 60 bilhões por mês. Às vezes é necessário recalcular por mês, e o melhor é fazer isso rapidamente. Monitoramento financeiro é exatamente os 300 milhões que continuam a crescer: os assinantes costumam trocar de operadoras, aumentando essa parte.
O componente mais telecom de comunicação móvel é a tarifação online. São sistemas que permitem que você faça chamadas ou não, tomando decisões em tempo real. Aqui a carga é de 30.000 transações por segundo, mas considerando o crescimento na transmissão de dados, planejamos 250.000 transações, e por isso estamos muito interessados no Tarantool.
A imagem anterior mostra os domínios onde pretendemos aplicar o Tarantool. O CRM em si é,当然, mais abrangente e planejamos aplicá-lo no núcleo.
O número calculado de características técnicas de 100 milhões de assinantes me preocupa como arquiteto - e se 101 milhões? Teremos que refazer tudo? Para evitar isso, aplicamos caches, além de aumentar a disponibilidade.
Existem basicamente duas abordagens para aplicar o Tarantool. A primeira é construir todos os caches no nível de microsserviços.Pelo que entendo, essa é a direção em que o VimpelCom está indo, criando um cache de clientes.
Nós, por outro lado, dependemos menos dos fornecedores, mudamos o núcleo BSS, portanto já temos um registro unificado de clientes pronto. Mas queremos expandi-lo. Por isso aplicamos uma abordagem um pouco diferente - fazemos caches dentro dos sistemas..
Assim há menos dessincronização - um sistema responde tanto pelo cache quanto pela fonte mestre principal.
Esse método se encaixa bem na abordagem do Tarantool com esqueleto transacional, onde apenas as partes relacionadas a atualizações, ou seja, mudanças de dados, são atualizadas. Todo o resto pode ser armazenado em outro lugar. Não há um enorme data lake, um cache global não gerenciado. Os caches são projetados para o sistema, seja para produtos, seja para clientes, ou, para facilitar a vida da manutenção. Quando um assinante insatisfeito com a qualidade liga, queremos atendê-lo bem.
RTO e RPO
Na TI existem dois termos - RTO e RPO.
Objetivo de tempo de recuperação — é o tempo de recuperação do serviço após uma falha. RTO = 0 significa que, mesmo que algo falhe, o serviço continua funcionando.
Objetivo do ponto de recuperação — é o tempo de recuperação dos dados, quanto dado podemos perder em um determinado período de tempo. RPO = 0 significa que não perdemos dados.
Tarefa para Tarantool
Vamos tentar resolver a tarefa para Tarantool.
Dado: um carrinho de pedidos compreensível por todos, por exemplo, na Amazon ou em outro lugar qualquer. É necessário para que o carrinho funcione 24 horas por dia, 7 dias por semana, ou 99,99% do tempo. Os pedidos que nos chegam devem manter a ordem, pois não podemos ativar ou desativar a conexão do assinante de forma caótica – tudo deve ser rigorosamente sequencial. A assinatura anterior influencia a próxima, portanto, os dados são importantes – nada deve se perder.
Solução. Pode-se tentar resolver diretamente e perguntar aos desenvolvedores do banco de dados, mas a tarefa não é matematicamente resolvível. Pode-se lembrar teoremas, leis de conservação, física quântica, mas para quê – isso não pode ser resolvido no nível do banco de dados.
Aqui aplica-se a boa e velha abordagem arquitetônica – é necessário conhecer bem o domínio e, a partir disso, resolver esse quebra-cabeça.
Nossa solução: criamos um registro distribuído de pedidos no Tarantool – um cluster geograficamente distribuído. No esquema, são três diferentes centros de dados – dois antes dos Urais, um além dos Urais, e distribuímos todos os pedidos entre esses centros.
A Netflix, que agora é considerada uma das líderes em TI, até 2012 tinha apenas um DC. Na véspera do Natal católico, 24 de dezembro, esse DC caiu. Os usuários no Canadá e nos EUA ficaram sem seus filmes favoritos, ficaram muito chateados e escreveram sobre isso nas redes sociais. Agora a Netflix tem três DCS na costa leste-oeste e um na Europa Ocidental.
Estamos inicialmente construindo uma solução geograficamente distribuída – a resiliência é importante para nós.
Então, temos um cluster, mas como lidar com RPO = 0 e RTO = 0? A solução é simples e depende do domínio.
O que é importante nas solicitações? Duas partes: coletar o carrinho ANTES da decisão de compra, e DEPOIS. A parte ANTES no telecom geralmente é chamada de captura de pedidos ou negociação de pedidos. No setor de telecomunicações, isso pode ser muito mais complicado do que em uma loja online, pois é necessário atender o cliente, oferecer 5 opções, e tudo isso acontece por um tempo, mas o carrinho vai sendo preenchido. Neste momento, uma falha pode ocorrer, mas isso não é preocupante, pois acontece em modo interativo sob a supervisão de um ser humano.
Se o Data Center de Moscovo falhar repentinamente, ao mudar automaticamente para outro Data Center, continuaremos a operação. Teoricamente, pode-se perder um produto no carrinho, mas você o vê, complementa novamente o carrinho e continua a trabalhar. Neste caso, o RTO = 0.
Ao mesmo tempo, existe uma segunda opção: quando clicamos em "enviar", queremos que os dados não se percam. A partir desse momento, a automação começa a operar — isso já é RPO = 0. A aplicação desses dois padrões diferentes em um caso pode ser apenas um cluster geograficamente distribuído com um mestre alternável, no outro caso, algum tipo de registro com quórum. Os padrões podem variar, mas resolvemos o problema.
Além disso, possuindo um registro de solicitações distribuído, podemos também escalar tudo — ter vários gerentes e executores que acessam esse registro.
Cassandra e Tarantool juntos
Há mais um caso — "vitrine de saldos". Aqui está um caso interessante de aplicação conjunta de Cassandra e Tarantool.
Utilizamos Cassandra porque 2 bilhões de chamadas por dia não é o limite, e esse número só tende a aumentar. Os profissionais de marketing gostam de segmentar o tráfego por fontes, surgem cada vez mais detalhes das redes sociais, por exemplo. Tudo isso aumenta o histórico.
Cassandra permite escalabilidade horizontal para qualquer volume.
Nos sentimos confortáveis com Cassandra, mas ela tem um problema — não é boa em leitura. Na gravação, tudo está OK, 30.000 por segundo não é problema — o problema está na leitura..
Por isso, surgiu o tema do cache, e decidimos resolver outro problema ao mesmo tempo: existe um antigo caso tradicional, onde o equipamento do switch de tarifação online gera arquivos que carregamos no Cassandra. Lutamos com o problema do carregamento confiável desses arquivos, até mesmo utilizando, a conselho do gerente da IBM, soluções de transferência de arquivos – existem soluções que gerenciam a transferência de arquivos de forma eficiente, utilizando protocolo UDP, por exemplo, ao invés de TCP. Isso é bom, mas ainda leva minutos, e enquanto não carregamos tudo, o operador no call center não pode informar ao cliente o que aconteceu com seu saldo – é preciso esperar.
Para que isso não aconteça, nós aplicamos reserva funcional paralela. Quando enviamos um evento via Kafka para o Tarantool, recalculando agregados em tempo real, por exemplo, do dia de hoje, obtemos um cache de saldos, que pode fornecer saldos a qualquer velocidade, como 100 mil transações por segundo e os mesmos 2 segundos.
O objetivo é que, após fazer uma chamada, já após 2 segundos, no painel pessoal, não apenas o saldo seja alterado, mas também a informação sobre por que ele foi alterado.
Conclusão
Esses foram exemplos de uso do Tarantool. Gostamos muito da transparência da Mail.ru e da sua disposição em considerar diferentes casos.
Para consultores da BCG ou McKinsey, Accenture ou IBM, já é difícil nos surpreender com algo novo – muito do que eles oferecem, nós já fazemos, já fizemos ou planejamos fazer. Acho que o Tarantool terá um lugar digno em nossa pilha tecnológica e substituirá muitas tecnologias já existentes. Estamos em fase ativa de desenvolvimento desse projeto.
A apresentação de Oleg e Andrey foi uma das melhores na Tarantool Conference do ano passado, e em 17 de junho, Oleg Ivlev se apresentará na com a palestra . Também da MegaFon, Alexander Deulin apresentará com a palestra . Vamos descobrir o que mudou, quais planos foram realizados. Junte-se a nós – a conferência é gratuita, apenas é necessário . Todas e o programa da conferência foi formado: novos casos, nova experiência de uso do Tarantool, arquitetura, enterprise, tutoriais e microsserviços.
Fonte: habr.com
