Por que uma empresa como a MegaFon precisa do Tarantool no faturamento? Do lado de fora parece que normalmente o vendedor vem, traz uma espécie de caixa grande, conecta o plugue na tomada - e isso é cobrança! Já foi assim, mas agora é arcaico, e esses dinossauros já foram extintos ou estão sendo extintos. Inicialmente, o faturamento é um sistema de emissão de notas fiscais - uma máquina de contagem ou calculadora. Nas telecomunicações modernas isto é sistema de automação para todo o ciclo de vida de interação com um assinante, desde a celebração de um contrato até a rescisão, incluindo faturamento em tempo real, aceitação de pagamento e muito mais. O faturamento nas empresas de telecomunicações é como um robô de combate – grande, poderoso e carregado de armas.
O que o Tarantool tem a ver com isso? Eles vão falar sobre isso Oleg Ivlev и Andrey Knyazev. Oleg é o arquiteto-chefe da empresa com ampla experiência trabalhando em empresas estrangeiras, Andrey é diretor de sistemas de negócios. Da transcrição do seu relatório sobre você aprenderá por que P&D é necessário nas corporações, o que é Tarantool, como o impasse da escala vertical e da globalização se tornou os pré-requisitos para o surgimento desse banco de dados na empresa, sobre os desafios tecnológicos, a transformação arquitetônica e como o technostack da MegaFon é semelhante ao Netflix , Google e Amazon.
Projeto "Faturamento Unificado"
O projeto em questão chama-se “Faturamento Unificado”. Foi aqui que a Tarantool mostrou as suas melhores qualidades.
O crescimento da produtividade dos equipamentos Hi-End não acompanhou o crescimento da base de assinantes e o crescimento do número de serviços; era esperado um maior crescimento no número de assinantes e serviços devido ao M2M, IoT e recursos de agências liderados a uma deterioração no time-to-market. A empresa decidiu criar um sistema de negócios unificado com uma arquitetura modular única de classe mundial, em vez dos 8 sistemas de faturamento diferentes atuais.
MegaFon são oito empresas em uma. Em 2009, a reorganização foi concluída: filiais em toda a Rússia foram fundidas em uma única empresa, MegaFon OJSC (agora PJSC). Assim, a empresa conta com 8 sistemas de faturamento com soluções “customizadas” próprias, funcionalidades de filiais e diferentes estruturas organizacionais, de TI e de marketing.
Tudo estava bem até que tivemos que lançar um produto federal comum. Aqui surgiram muitas dificuldades: para alguns as tarifas são arredondadas para cima, para outros arredondadas para baixo e para outros - com base na média aritmética. Existem milhares de momentos assim.
Apesar de existir apenas uma versão do sistema de faturamento, um fornecedor, as configurações divergiam tanto que demorava muito para serem montadas. Tentamos reduzir seu número e nos deparamos com um segundo problema que é familiar para muitas empresas.
Escala vertical. Mesmo o hardware mais legal da época não atendia às necessidades. Utilizamos equipamentos Hewlett-Packard da linha Superdome Hi-End, mas não atendiam nem a duas filiais. Eu queria uma expansão horizontal sem grandes custos operacionais 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 tempo em que cada telefone e ferro de passar roupa terá um cartão SIM e dois na geladeira. Hoje temos um número de assinantes, mas num futuro próximo haverá muitos mais.
Desafios tecnológicos
Estas quatro razões motivaram-nos a fazer mudanças sérias. Houve uma escolha entre atualizar o sistema e projetá-lo do zero. Pensamos muito, tomamos decisões sérias, fizemos licitações. Como resultado, decidimos projetar desde o início e assumimos desafios interessantes – desafios tecnológicos.
Escalabilidade
Se fosse antes, digamos, digamos 8 cobranças para 15 milhões de assinantes, e agora deveria ter funcionado 100 milhões de assinantes e mais - a carga é uma ordem de grandeza maior.
Tornámo-nos comparáveis em escala a grandes players da Internet como Mail.ru ou Netflix.
Mas o movimento adicional para aumentar a carga e a base de assinantes colocou sérios desafios para nós.
Geografia do nosso vasto país
Entre Kaliningrado e Vladivostok 7500 km e 10 fusos horários. A velocidade da luz é finita e nessas distâncias os atrasos já são significativos. 150 ms nos canais ópticos modernos mais legais é demais para o faturamento em tempo real, especialmente como acontece 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 prestamos serviços apenas mediante pagamento de assinatura, temos tarifas, pacotes e vários modificadores complexos. Precisamos não apenas permitir ou negar a comunicação do assinante, mas também dar-lhe uma certa cota - calcular chamadas e ações em tempo real para que ele não perceba.
tolerância ao erro
Este é o outro lado da centralização.
Se reunirmos todos os assinantes em um sistema, quaisquer eventos de emergência e desastres serão desastrosos para os negócios. Por isso, projetamos o sistema de forma a eliminar o impacto de acidentes em toda a base de assinantes.
Isto é novamente uma consequência da recusa de escalar verticalmente. Quando escalamos horizontalmente, aumentamos o número de servidores de centenas para milhares. Eles precisam ser gerenciados e intercambiáveis, fazer backup automático da infraestrutura de TI e restaurar o sistema distribuído.
Enfrentamos desafios muito interessantes. Projetamos o sistema e, naquele momento, procuramos encontrar as melhores práticas globais para verificar o quanto estamos na moda, o quanto acompanhamos as tecnologias avançadas.
Experiência mundial
Surpreendentemente, não encontramos uma única referência em telecomunicações globais.
A Europa caiu em termos de número de assinantes e escala, os EUA - em termos de uniformidade das suas tarifas. Analisamos alguns na China e encontramos alguns na Índia e contratamos especialistas da Vodafone Índia.
Para analisar a arquitetura, montamos um Dream Team liderado pela IBM - arquitetos de diversas áreas. Essas pessoas puderam avaliar adequadamente o que estávamos fazendo e trazer certo conhecimento para nossa arquitetura.
Escala
Alguns números para ilustração.
Projetamos o sistema para 80 milhões de assinantes com reserva de um bilhão. É assim que removemos limites futuros. Isto não acontece porque vamos dominar a China, mas por causa do ataque da IoT e do M2M.
300 milhões de documentos processados em tempo real. Embora tenhamos 80 milhões de assinantes, trabalhamos tanto com clientes potenciais quanto com aqueles que nos deixaram, caso precisemos cobrar contas a receber. Portanto, os volumes reais são visivelmente maiores.
2 bilhões de transações O saldo muda diariamente - são pagamentos, cobranças, ligações e outros eventos. 200 TB de dados estão mudando ativamente, mude um pouco mais devagar 8 PB de dados, e isso não é um arquivo, mas dados ativos em um único faturamento. Dimensionar por data center - 5 mil servidores em 14 sites.
Pilha de tecnologia
Quando planejamos a arquitetura e começamos a montar o sistema, importamos as tecnologias mais interessantes e avançadas. O resultado é uma pilha de tecnologia familiar a qualquer player da Internet e corporações que fabricam sistemas de alta carga.
A pilha é semelhante às pilhas de outros grandes players: Netflix, Twitter, Viber. É composto por 6 componentes, mas queremos encurtá-lo e unificá-lo.
A flexibilidade é boa, mas em uma grande corporação não há como não haver unificação.
Não vamos mudar o mesmo Oracle para Tarantool. Na realidade das grandes empresas, isto é uma utopia, ou uma cruzada de 5 a 10 anos com um resultado incerto. Mas Cassandra e Couchbase podem ser facilmente substituídos pelo Tarantool, e é isso que estamos buscando.
Por que Tarantool?
Existem 4 critérios simples pelos quais escolhemos este banco de dados.
velocidade. Realizamos testes de carga em sistemas industriais MegaFon. Tarantool venceu - apresentou o melhor desempenho.
Isso não quer dizer que outros sistemas não atendam às necessidades do MegaFon. As soluções de memória atuais são tão produtivas que as reservas da empresa são mais que suficientes. Mas temos interesse em lidar com um líder, e não com alguém que está atrasado, inclusive no teste de carga.
Tarantool cobre as necessidades da empresa mesmo a longo prazo.
Custo TCO. O suporte para Couchbase em volumes MegaFon custa quantias astronômicas de dinheiro, mas com o Tarantool a situação é muito mais agradável e eles são semelhantes em funcionalidade.
Outro recurso interessante que influenciou um pouco nossa escolha é que o Tarantool funciona melhor com memória do que outros bancos de dados. Ele mostra eficiência máxima.
Confiança. A MegaFon investe em confiabilidade, provavelmente mais do que qualquer outra pessoa. Então, quando analisamos o Tarantool, percebemos que precisávamos fazer com que ele atendesse aos nossos requisitos.
Investimos nosso tempo e dinheiro e junto com Mail.ru criamos uma versão empresarial, que hoje é utilizada em diversas outras empresas.
A Tarantool-enterprise nos satisfez completamente em termos de segurança, confiabilidade e registro.
parceria
O mais importante para mim é contato direto com o desenvolvedor. Foi exatamente com isso que os caras da Tarantool subornaram.
Se você chega em um jogador, principalmente aquele que trabalha com cliente âncora, e diz que precisa do banco de dados para poder fazer isso, isso e aquilo, ele geralmente responde:
- Ok, coloque os requisitos no final da pilha - algum dia, provavelmente chegaremos a eles.
Muitos têm um roteiro para os próximos 2 a 3 anos, e é quase impossível integrá-lo, mas os desenvolvedores do Tarantool cativam com sua abertura, e não apenas do MegaFon, e adaptam seu sistema ao cliente. É legal e gostamos muito.
Onde usamos Tarantool
Usamos Tarantool 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 acabou sendo um pouco diferente.
Por exemplo, o catálogo de endereços na interface de vendas. No Oracle, a busca pelo endereço desejado 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 pesquisa, obtemos uma aceleração de 200x! A cidade aparece após a terceira letra. Agora estamos adaptando a interface para que isso aconteça depois da primeira. No entanto, a velocidade de resposta é completamente diferente – milissegundos em vez de segundos.
A segunda aplicação é um tema moderno chamado TI de duas velocidades. Isso ocorre porque consultores de todos os cantos dizem que as empresas deveriam ir para lá.
Existe uma camada de infraestrutura, acima dela existem domínios, 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 garantir a qualidade, porque traz dinheiro para a corporação.
Em seguida vem a camada de microsserviços – o que diferencia a operadora ou outro player. Microsserviços podem ser criados rapidamente com base em determinados caches, trazendo para lá dados de diferentes domínios. Aqui campo para experimentos — se algo não desse certo, fechei um microsserviço e abri outro. Isso proporciona um tempo de lançamento no mercado verdadeiramente maior e aumenta a confiabilidade e a velocidade da empresa.
Os microsserviços são talvez a função principal do Tarantool na MegaFon.
Onde planejamos usar o Tarantool
Se compararmos o nosso bem sucedido projecto de facturação com os programas de transformação da Deutsche Telekom, Svyazcom, Vodafone India, é surpreendentemente dinâmico e criativo. No processo de implementação deste projeto, não apenas o MegaFon e sua estrutura foram transformados, mas também a Tarantool-enterprise apareceu em Mail.ru, e nosso fornecedor Nexign (anteriormente Peter-Service) - BSS Box (uma solução de faturamento em caixa).
Este é, de certa forma, um projeto histórico para o mercado russo. Pode ser comparado ao que é descrito no livro “The Mythical Man-Month” de Frederick Brooks. Então, na década de 60, a IBM contratou 360 mil pessoas para desenvolver o novo sistema operacional OS/5 para mainframes. Temos menos - 000, mas os nossos estão em coletes e, levando em consideração o uso de código aberto e novas abordagens, trabalhamos de forma mais produtiva.
Abaixo estão os domínios de faturamento ou, mais amplamente, sistemas de negócios. Pessoas empresariais conhecem muito bem o CRM. Todos já deveriam ter outros sistemas: Open API, API Gateway.
API aberta
Vejamos novamente os números e como a Open API funciona atualmente. Sua carga é 10 transações por segundo. Como planejamos desenvolver ativamente a camada de microsserviços e construir a API pública MegaFon, esperamos um maior crescimento nesta parte no futuro. Definitivamente haverá 100 transações.
Não sei se podemos comparar com Mail.ru em SSO - os caras parecem ter 1 de transações por segundo. A solução deles é extremamente interessante para nós e planejamos adotar sua experiência - por exemplo, fazer um backup funcional de SSO usando Tarantool. Agora os desenvolvedores do Mail.ru estão fazendo isso por nós.
CRM
CRM são os mesmos 80 milhões de assinantes que queremos aumentar para um bilhão, porque já existem 300 milhões de documentos que incluem um histórico de três anos. Estamos realmente ansiosos por novos serviços e aqui ponto de crescimento são os serviços conectados. Essa é uma bola que vai crescer, porque vai haver cada vez mais serviços. Conseqüentemente, precisaremos de uma história; não queremos tropeçar nisso.
Faturar-se em termos de emissão de notas fiscais, trabalhando com contas a receber de clientes transformado em um domínio separado. Para melhorar o desempenho, padrão arquitetônico de arquitetura de domínio aplicado.
O sistema é dividido em domínios, a carga é distribuída e a tolerância a falhas é garantida. Além disso, trabalhamos com arquitetura distribuída.
Todo o resto são soluções de nível empresarial. No armazenamento de chamadas - 2 bilhões por dia, 60 bilhões por mês. Às vezes você tem que contá-los em um mês, e é melhor rapidamente. Acompanhamento financeiro - são exatamente os mesmos 300 milhões que estão em constante crescimento e crescimento: os assinantes muitas vezes circulam entre operadoras, aumentando essa parte.
O componente mais telecomunicações das comunicações móveis é faturamento on-line. São esses sistemas que permitem ligar ou não ligar, tomar decisões em tempo real. Aqui a carga é de 30 transações por segundo, mas levando em consideração o crescimento da transferência de dados, planejamos 250 transações, e por isso estamos muito interessados no Tarantool.
A imagem anterior mostra os domínios onde usaremos o Tarantool. O CRM em si, claro, é mais amplo e vamos utilizá-lo no próprio core.
Nosso valor estimado de TTX de 100 milhões de assinantes me confunde como arquiteto - e se 101 milhões? Você tem que refazer tudo de novo? Para evitar que isso aconteça, utilizamos caches, ao mesmo tempo que aumentamos a acessibilidade.
Em geral, existem duas abordagens para usar o Tarantool. Primeiro - construir todos os caches no nível do microsserviço. Pelo que entendi, a VimpelCom está seguindo esse caminho, criando um cache de clientes.
Somos menos dependentes de fornecedores, estamos mudando o núcleo do BSS, então temos um único arquivo de cliente pronto para uso. Mas queremos expandi-lo. Portanto, adotamos uma abordagem um pouco diferente - faça caches dentro de sistemas.
Dessa forma, há menos sincronização - um sistema é responsável pelo cache e pela fonte mestre principal.
O método se adapta bem à abordagem Tarantool com esqueleto transacional, 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 existe um grande data lake ou cache global não gerenciado. Os caches são projetados para o sistema, ou para produtos, ou para clientes, ou para facilitar a vida da manutenção. Quando um assinante liga e fica chateado com a qualidade do seu serviço, você deseja fornecer um serviço de qualidade.
RTO e RPO
Existem dois termos em TI - RTO и RPO.
Objetivo do tempo de recuperação é o tempo necessário para restaurar o 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 - este é o tempo de recuperação de dados, quantos dados podemos perder durante um determinado período de tempo. RPO = 0 significa que não estamos perdendo dados.
Tarefa Tarantool
Vamos tentar resolver um problema do Tarantool.
Dado: uma cesta de aplicativos que todos entendem, por exemplo, na Amazon ou em outro lugar. Necessário para que o carrinho de compras funcione 24 horas, 7 dias por semana, ou 99,99% do tempo. Os pedidos que chegam até nós devem permanecer em ordem, pois não podemos ligar ou desligar aleatoriamente a conexão do assinante - tudo deve ser estritamente consistente. A assinatura anterior afeta a próxima, por isso os dados são importantes – nada deve faltar.
Solução. Você pode tentar resolver isso de frente e perguntar aos desenvolvedores do banco de dados, mas o problema não pode ser resolvido matematicamente. Você pode se lembrar de teoremas, leis de conservação, física quântica, mas por quê - isso não pode ser resolvido no nível do banco de dados.
A boa e velha abordagem arquitetônica funciona aqui - você precisa conhecer bem a área de assunto e usá-la para resolver esse quebra-cabeça.
Nossa solução: criando um registro distribuído de aplicativos no Tarantool - um cluster distribuído geograficamente. No diagrama, são três centros de processamento de dados diferentes - dois antes dos Urais, um além dos Urais, e distribuímos todas as solicitações entre esses centros.
A Netflix, que hoje é considerada uma das líderes em TI, tinha apenas um data center até 2012. Na véspera do Natal católico, 24 de dezembro, este data center caiu. Usuários no Canadá e nos EUA ficaram sem seus filmes favoritos, ficaram muito chateados e escreveram sobre isso nas redes sociais. A Netflix tem agora três data centers na costa oeste-leste e um na Europa Ocidental.
Estamos inicialmente construindo uma solução geodistribuída – a tolerância a falhas é importante para nós.
Então 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: lançamento de cesta ANTES tomar uma decisão de compra e DEPOIS. A parte DO em telecomunicações é geralmente chamada captura de pedidos ou negociação de pedidos. Em telecom isso pode ser muito mais difícil do que em uma loja online, porque lá o cliente deve ser atendido, são oferecidas 5 opções, e isso tudo acontece por algum tempo, mas a cesta fica cheia. Neste momento uma falha é possível, mas não assusta, pois acontece de forma interativa sob supervisão humana.
Se o data center de Moscou falhar repentinamente, ao mudarmos automaticamente para outro data center, continuaremos trabalhando. Teoricamente, um produto pode se perder no carrinho, mas você vê, adiciona novamente ao carrinho e continua trabalhando. Neste caso RTO = 0.
Ao mesmo tempo, existe uma segunda opção: ao clicarmos em “enviar”, queremos que os dados não se percam. A partir deste momento, a automação começa a funcionar - isto é RPO = 0. Usando esses dois padrões diferentes, em um caso poderia ser simplesmente um cluster distribuído geograficamente com um mestre comutável, em outro caso, algum tipo de registro de quorum. Os padrões podem variar, mas nós resolvemos o problema.
Além disso, tendo um registro distribuído de aplicações, também podemos escalar tudo - temos muitos despachantes e executores que acessam esse registro.
Cassandra e Tarantool juntos
Há outro caso - "vitrine de saldos". Aqui está um caso interessante de uso conjunto de Cassandra e Tarantool.
Usamos Cassandra porque 2 bilhões de ligações por dia não é o limite e haverá mais. Os profissionais de marketing adoram colorir o tráfego por origem; cada vez mais detalhes aparecem nas redes sociais, por exemplo. Tudo isso contribui para a história.
Cassandra permite dimensionar horizontalmente para qualquer tamanho.
Nos sentimos confortáveis com Cassandra, mas ela tem um problema: ela não é boa em leitura. Está tudo bem na gravação, 30 por segundo não é problema - problema de leitura.
Portanto, surgiu um tópico com cache, e ao mesmo tempo resolvemos o seguinte problema: existe um caso antigo e tradicional em que o equipamento de uma mudança do faturamento online entra nos arquivos que carregamos no Cassandra. Lutamos com o problema de download confiável desses arquivos, mesmo seguindo o conselho do gerente de transferência de arquivos da IBM - existem soluções que gerenciam a transferência de arquivos de forma eficiente, usando o protocolo UDP, por exemplo, em vez de TCP. Isso é bom, mas ainda faltam minutos, e ainda não carregamos tudo, a operadora da central de atendimento não consegue responder ao cliente o que aconteceu com o saldo dele - temos que esperar.
Para evitar que isso aconteça, nós usamos reserva funcional paralela. Quando enviamos um evento via Kafka para o Tarantool, recalculando agregados em tempo real, por exemplo, para hoje, obtemos saldos de caixa, que pode transferir saldos em qualquer velocidade, por exemplo, 100 mil transações por segundo e esses mesmos 2 segundos.
O objetivo é que após fazer uma ligação, em até 2 segundos na sua conta pessoal haja não apenas o saldo alterado, mas informações sobre o motivo da alteração.
Conclusão
Estes foram exemplos de uso do Tarantool. Gostamos muito da abertura do Mail.ru e de sua disposição em considerar diferentes casos.
Já é difícil para consultores do BCG ou McKinsey, Accenture ou IBM nos surpreenderem com algo novo - muito do que eles oferecem, ou nós já fazemos, fizemos ou estamos planejando fazer. Acredito que o Tarantool ocupará o seu devido lugar em nossa pilha de tecnologia e substituirá muitas tecnologias existentes. Estamos na fase ativa de desenvolvimento deste projeto.
O relatório de Oleg e Andrey é um dos melhores da Conferência Tarantool do ano passado, e no dia 17 de junho Oleg Ivlev falará no com um relatório . Alexander Deulin também fará uma apresentação da MegaFon . Vamos descobrir o que mudou, quais planos foram implementados. Participe - a conferência é gratuita, tudo que você precisa fazer é . tudo e o programa da conferência está formado: novos cases, novas experiências no uso do Tarantool, arquitetura, empreendimento, tutoriais e microsserviços.
Fonte: habr.com