Couchbase on Telecom

A transformação digital é uma tendência global para grandes empresas e é vital para adaptar uma empresa às necessidades modernas dos clientes. Além dos problemas habituais de centralizar sistemas para grandes empresas e combinar sistemas de cobrança e bancos de dados de assinantes, são adicionados requisitos de alta disponibilidade e um modo de operação em tempo real aos quais os clientes já estão acostumados pelos líderes do setor (Google, Amazon, Netflix).

Novos desafios exigem novas tecnologias e abordagens necessárias para reduzir o tempo de introdução de funções convenientes para o cliente, ofertas comerciais personalizadas, resposta rápida às ofertas dos concorrentes, além de controlar os custos de sistemas, infraestrutura de TI, data centers e pessoal qualificado. Essas tendências também são um grande ponto negativo: a complexidade da arquitetura e os bancos de dados transacionais inchados que não conseguem lidar com o fluxo e o processamento de informações. As tecnologias da geração anterior têm um teto de escala vertical. Por exemplo, uma instância do Oracle DBMS é executada no limite do servidor mais poderoso em processadores x86 com uma carga de um bilhão de transações por dia.

Para suportar uma carga semelhante que a indústria da Internet enfrenta há muito tempo, uma nova pilha de tecnologias é usada, como caches na memória e bancos de dados NoSQL. Portanto, a Apple usa Cassandra, Sberbank - Ignite (GridGain), no MegaFon usamos Couchbase e Tarantool.

O MegaFon usa diferentes padrões arquiteturais para o DBMS na memória:

1. Cache simples, atualizado na programação ou por evento do banco de dados e aplicativos
2. Todas as alterações no banco de dados são feitas através do cache (script de gravação), por exemplo, conectando um cliente Oracle ao DCP Couchbase

Para um de nossos sistemas de tomada de decisão para o ciclo de vida do assinante, usamos o primeiro modelo, pois apenas um aplicativo na totalidade dos dados toma uma decisão e a envia para todos os sistemas, incluindo o banco de dados Oracle. Um dos casos mais brilhantes de uso do ciclo de vida de um assinante é o bloqueio e desbloqueio em um saldo negativo. Afinal, todos os assinantes de operadoras de celular após reabastecer a balança desejam entrar em contato imediatamente e fazer chamadas. Graças a um aplicativo separado e ao Couchbase, conseguimos reduzir o tempo para sair da trava de 90 segundos para 30, e esse não é o limite. Somente o registro sobre a alteração no status do assinante entrará no banco de dados principal (Fig. 1)

Com o uso de novas tecnologias, conseguimos reduzir três vezes o tempo para sair do bloqueio financeiro. Mas, para obter os resultados atuais, percorremos um longo caminho na transformação arquitetural do circuito de cobrança e na escolha do banco de dados NoSQL.

Por que escolhemos o Couchbase? Existem várias razões para isso.

Requisito de desempenho

1. Processando até 200.000 solicitações por segundo.
2. O tempo médio de resposta (50%) é de até 5 ms (em um único data center).
3. O tempo máximo de resposta (99%) é de até 15 ms (dentro de um data center).
4. Desempenho máximo de inserção 500 MB / s
5. Número máximo de operações de inserção 100.000 / s
6. Número máximo de operações de alteração (atualizações de documentos) 100.000 / s
7. Desempenho máximo de alterações (atualizações de documentos) 500 MB / s
8. Número máximo de operações de leitura 100.000 / s
9. Velocidade máxima de leitura 500 MB / s

Pesquisa de chave de alto desempenho e acesso a dados

O núcleo do Couchbase é o Cofre de Chave Distribuído (KV). O repositório KV é uma abordagem de gerenciamento de dados extremamente simples que armazena um identificador exclusivo (chave) junto com uma informação arbitrária. O próprio repositório KV pode aceitar qualquer dado, seja um blob binário ou um documento JSON. Devido à simplicidade da implementação do KV, o acesso aos dados é garantido com um atraso mínimo. Como mostra nossa experiência, mais frequentemente a latência da rede é 2-3 vezes maior do que o fornecimento de dados importantes no lado do Couchbase.

Esquema de armazenamento dinâmico ( JSON)

Os documentos são armazenados no servidor Couchbase no formato JSON. O formato suporta dois tipos de dados básicos, como números, seqüências de caracteres e tipos complexos, além de dicionários e matrizes internos.

O esquema de dados no Couchbase é uma construção lógica definida pelo aplicativo e pelo desenvolvedor. Devido à sua flexibilidade e capacidade de usar várias opções, podemos usar uma tag no documento, por exemplo, com informações sobre a versão. Isso permite que o aplicativo determine em qual modo o documento deve ser processado, além de garantir uma migração suave do banco de dados para o novo esquema de dados.

Alta disponibilidade

Um dos parâmetros constituintes de um sistema de informação é sua disponibilidade. O Couchbase fornece alta disponibilidade de dados com muitos recursos diferentes. Uma delas é a replicação de dados (a distribuição de várias cópias de dados em diferentes servidores do cluster), que permite fornecer um serviço durante a manutenção de rotina ou a falha de alguns servidores.

O segundo recurso importante para alta disponibilidade é o DCP (Protocolo de alteração de banco de dados) interno. Ele fornece transferência de alterações em alta velocidade para todas as cópias de dados, índices secundários (GSI), replicação de cluster cruzado (XDCR) e consumidores externos.

Replicação bidirecional

A boa prática nas empresas é usar a redundância para todos os processos e equipamentos de negócios. Idealmente, esse é um backup no modo Ativo-Ativo, quando a alternância entre nós problemáticos ocorre automaticamente. A replicação bidirecional no Couchbase ativa o modo AA. Mas testar a replicação mostrou que ela é eficaz apenas em data centers próximos. Com um espaçamento de mais de 100 km, aparecem conflitos. O Couchbase possui mecanismos de resolução de conflitos: com base no carimbo de data e hora e no número de sequência. No entanto, devido ao atraso de tempo na rede, dados desatualizados entram no banco de dados. Abandonamos o uso de replicação bidirecional (consistência de cluster cruzado). Todas as alterações são realizadas em apenas um cluster. A disponibilidade de dados no modo de leitura é fornecida em todos os data centers (AA).

Escala horizontal

Uma das características importantes da maioria dos bancos de dados NoSQL é a escala horizontal (Fig. 3). A principal diferença do Couchbase é o suporte à escala multidimensional, quando nós no cluster só podemos aumentar o desempenho do serviço desejado. Por exemplo, o jogo Pokemon GO usa uma arquitetura dividida. No início do projeto, foram utilizados 5 servidores com serviços combinados. Depois de aumentar a carga, eles usaram uma arquitetura diversificada: 5 servidores de dados e 55 servidores para processar consultas e índices. Uma das desvantagens da escala com o Couchbase é que o orquestrador tem problemas quando há mais de 50 nós de data no cluster.

Figura 3 MDS

Requisitos de SI

Os requisitos de segurança da informação influenciaram nossa escolha em menor grau, mas a presença deles no sistema apresentou um argumento adicional a favor de um ou outro banco de dados. Como o cache pode conter dados pessoais, devemos seguir os requisitos do regulador sem falhas. Vale a pena decidir: usaremos equipamento adicional ou podemos fornecer isso com o próprio banco de dados ?!

Na versão corporativa, o Couchbase suporta criptografia de tráfego, criptografia de dados e acesso personalizado. Isso economiza dinheiro em equipamentos como o Cisco ASA.

Atualização fácil

Um dos pontos fortes do Couchbase é seu mecanismo de atualização transparente e suporte para versões mais antigas da API. Durante a atualização do cluster, ele funciona no modo de compatibilidade. Novos mecanismos só funcionarão após uma atualização completa do cluster. Os efeitos nos aplicativos em execução são mínimos devido ao suporte para a API antiga.

PS: atualização / downgrade é permitido apenas nas principais versões vizinhas

Funcionalidade adicional

Distribuição lógica

Outro recurso interessante é a combinação de servidores em um cluster em grupos lógicos, com réplicas anexadas a eles. Isso permite distribuir cópias completas de réplicas do mesmo cluster para diferentes autogates. Isso permite que uma das concessionárias não tenha uma cópia completa dos dados no segundo

Backup e restauração

O Couchbase contém ferramentas de backup e recuperação prontas. O processo de backup pode funcionar em três modos: completo, diferencial e cumulativo. Isso permite, em alguns casos, economizar espaço em disco e recursos do processador.

Couchbase vs mongo

É difícil responder à questão de escolher bancos de dados NoSQL alternativos e, frequentemente, o melhor Unix é aquele que o seu administrador conhece. Vamos tentar formular por que preferimos o Couchbase, e não outra plataforma muito popular - o MongoDB.

É bastante difícil comparar dois projetos diferentes com arquitetura e funcionalidade diferentes. Um dos parâmetros aos quais prestamos atenção é a facilidade de manutenção e a capacidade de reconfigurar rapidamente o sistema para atender às necessidades dos negócios.

Tabela 1 Comparação

Tabela 2 Comparação de replicação

No geral, o Couchbase é mais flexível e mais simples nas configurações necessárias para nossas tarefas e na arquitetura híbrida que muda rapidamente.

Experiência operacional

Para começar, gostaríamos de fornecer os números com os quais o sistema e o cluster estão operando no Couchbase.

1. Mais de 80 milhões de assinantes [i]
2. 380 milhões de documentos de informações do cliente JSON
3. Disco rígido de 3,5 TB (usamos memcached, as informações no disco são armazenadas para um início rápido)
4. 3 TB de RAM
5. 50 mil operações por segundo (Fig. 5)
6. 50 microsserviços que processam todo o fluxo de mensagens

Os primeiros marcos da transformação que começamos com a terceira versão do Couchbase. No primeiro estágio, no início do projeto, todos os aplicativos funcionavam de maneira estável. Mas, ao traduzir lógica adicional para um novo mecanismo, fomos confrontados com o fato de que o mecanismo View começou a funcionar de maneira imprevisível. I.e. em algum momento, o processo congela e essas visualizações desse nó param de retornar. Ao mesmo tempo, o acesso aos dados e seu processamento não foram interrompidos. O problema foi resolvido com bastante facilidade - reiniciando o nó, o que geralmente reduzia a disponibilidade do serviço. Durante a comunicação com o suporte técnico do Couchbase, foi-nos oferecido um comando não documentado que reinicia apenas o processo de visualização

curl -s --data 'cb_couch_sup: restart_couch ().' -u Administrador: passe http://127.0.0.1:8091/diag/eval [ii]

O comando é válido apenas nas versões 3.x.

curl -s --data 'couch_server_sup: restart_core_server ().' -u Administrator: Administrator http://127.0.0.1:8091/diag/eval

O comando é válido apenas nas versões 4.x.

Outro problema da terceira versão foi o mecanismo de compactação de dados (compactação). Ele teve que ser iniciado manualmente de acordo com as métricas de monitoramento acionadas. Ambos os problemas mantiveram-se em tensão, não apenas na troca de tarefas, mas também nos engenheiros funcionais.

Nesse sentido, decidimos migrar para a quarta versão. A migração com impacto mínimo no serviço levou cerca de duas semanas. O processo de atualização em si não requer ações e controle complexos, mas ao adicionar ou remover um nó, um reequilíbrio é iniciado, o que leva pelo menos duas horas. No processo, encontramos uma maneira de acelerar o processo de atualização por meio de um servidor de buffer: nesse caso, ele inicia não um processo de reequilíbrio limpo, mas transferindo dados de um nó para outro. Isso reduziu o processo de atualização para 30 minutos.

Ao atualizar um cluster industrial, as seguintes nuances devem ser levadas em consideração: trabalhar no modo de compatibilidade, quando o cluster operar no modo da versão mais jovem do software. No lado positivo, o processo de atualização ocorre sem problemas e sem problemas, mas você não poderá usar novas funções, como o novo mecanismo de compactação, N1QL, até que todo o cluster esteja totalmente atualizado.

Após a atualização, conseguimos corrigir apenas um problema - a compactação. Começou a funcionar corretamente. Com o mecanismo View, o problema ainda permanecia, embora fosse repetido com muito menos frequência. Foi possível corrigi-lo apenas pelas forças dos desenvolvedores do Couchbase na versão 4.6.4.

Como parte da resolução de problemas de suporte técnico, ficou claro que o mecanismo de exibição não será mais atualizado. Isso foi feito com base no fato de que a maioria dos clientes do Couchbase não usa visualizações para os fins para os quais foram criados, e o Couchbase criou um novo mecanismo N1QL. Ele é executado por um serviço separado e agora não depende de nós de dados (Fig. 7)

Fechamos todos os problemas críticos com a versão 4.6.4. Porém, devido ao aumento na quantidade de dados, eles decidiram migrar para a quinta versão, onde adicionaram um novo banco de dados para os índices e, em nossos dados, a quantidade de memória e discos diminuiu uma vez e meia. Infelizmente, porém, não vimos uma diminuição na quantidade de dados nos nós de dados.

Conclusões

Em geral, o Couchbase provou ser um sistema maduro que suporta uma carga alta, mesmo em casos inespecíficos (Viber - usado como banco de dados). Na arquitetura híbrida MegaFon, o cluster pode ser facilmente adaptado para qualquer finalidade, sem tempo de inatividade do equipamento e sem reconfiguração séria do servidor, o que geralmente permite à empresa reduzir os custos com pessoal e tornar o serviço para o assinante o mais conveniente possível.

PAO MegaFon

2018 Kovalchuk Egor

[i] O sistema processa não apenas assinantes, mas também dispositivos com cartões SIM, modems, etc.

[ii] Consulte um especialista antes de usar