Egor Kovalchuk é gerente de implantação na MegaFon, uma das maiores empresas de telecomunicações da Rússia. Sua carreira em telecomunicações se estende por mais de uma década. A equipe de Egor é responsável pelo desenvolvimento, integração e monitoramento de vários sistemas e aplicativos comerciais que abrangem os onze fusos horários da Rússia.
Couchbase em telecomunicações: MegaFon, Rússia
A transformação digital é uma tendência global para empresas grandes e pequenas. É vital que as empresas se adaptem às necessidades dos clientes modernos. Os clientes estão acostumados a sistemas altamente disponíveis e em tempo real fornecidos pelos líderes do setor (Google, Amazon, Netflix) e exigem a mesma experiência de todos os participantes do mercado.
As empresas de telecomunicações russas são totalmente afetadas por essa tendência. Novos recursos amigáveis ao cliente precisam ser implementados rápido e escala facilmente. Precisamos reagir rapidamente às ações de nossos concorrentes. Tudo isso precisa ser fornecido enquanto se gerencia os custos crescentes dos gastos com TI (infraestrutura, data centers, pessoal qualificado). É aí que as novas tecnologias, como o cache na memória e os bancos de dados NoSQL, são úteis.
Descreverei a seguir dois casos de uso que utilizamos no MegaFon com bancos de dados na memória:
- Cache simplesCache: o cache é preenchido e atualizado em um cronograma, bem como por eventos do banco de dados e do aplicativo.
- Cache de gravação(por exemplo, o banco de dados Oracle recebe atualizações do fluxo DCP do Couchbase).
A primeira abordagem é usada em nosso sistema de tomada de decisões para o ciclo de vida do assinante. Um único aplicativo analisa vários fatores, toma uma decisão e envia a alteração para vários sistemas (incluindo um banco de dados Oracle). Um exemplo desse tipo de aplicativo é o bloqueio e o desbloqueio de contas de planos pré-pagos. Quando o valor pré-pago é usado, a conta é bloqueada e nenhum serviço é fornecido até que o cliente a recarregue. Depois que a conta é reabastecida, o serviço precisa ser reativado o mais rápido possível. Graças ao uso do Couchbase, reduzimos o tempo de restabelecimento do serviço de 90 para 30 segundos, mas ainda há espaço para melhorias. A única atualização enviada ao banco de dados principal é a alteração do status da conta (veja a Figura 1 abaixo).
Figura 1: Processo de atualização rápida do status da conta MegaFon
Por que escolhemos o Couchbase Server como parte de nossos esforços de transformação digital? Vamos dar uma olhada em nossos requisitos de desempenho e ver como o Couchbase se adapta a eles.
NoSQL Desempenho do banco de dados Requisitos
- Taxa de processamento: até 200.000 solicitações por segundo.
- Latência média (50%), cluster único: dentro de 5 ms.
- Latência máxima (99%), cluster único: dentro de 15 ms.
- Taxa de transferência máxima de inserção: 500 MB por segundo.
- Número máximo de operações de inserção: 100.000 por segundo.
- Taxa de transferência máxima de atualização: 500 MB por segundo.
- Número máximo de operações de atualização: 100.000 por segundo.
- Taxa de transferência máxima de leitura: 500 MB por segundo.
- Número máximo de operações de leitura: 100.000 por segundo
Acesso a dados chave-valor de alto desempenho
O Couchbase Server, em sua essência, é um banco de dados distribuído de chave-valor (KV). O armazenamento KV é uma abordagem simples de gerenciamento de dados que armazena um identificador exclusivo (chave) junto com um pedaço de informação arbitrária (valor). O valor pode ser um objeto binário (BLOB/blob) ou um documento JSON. Devido à simplicidade da implementação do KV (especialmente quando comparado aos bancos de dados relacionais), o acesso aos dados é fornecido com latência mínima. Em nossas implementações, a latência da rede costuma ser de 2 a 3 vezes maior do que o tempo para concluir uma operação de KV no cluster do Couchbase.
Formato de dados flexível (JSON)
JavaScript Object Notation (JSON) é o formato de armazenamento de dados preferido no Couchbase. O formato oferece suporte a tipos de dados primitivos (booleanos, números, cadeias de caracteres) e compostos (matrizes, listas, dicionários).
O esquema de dados de seus documentos JSON pode ser facilmente alterado com base nas mudanças de requisitos do aplicativo. Diferentes versões de esquema podem ser rastreadas por um campo de documento adicional, garantindo assim atualizações de aplicativos e compatibilidade com versões anteriores sem problemas.
Alta disponibilidade
O Couchbase Sever oferece vários recursos para dar suporte à alta disponibilidade (HA) dos dados. Intra-cluster replicação de dados (distribuição de várias cópias de dados em diferentes servidores em um único cluster) mantém os dados disponíveis durante a manutenção programada do servidor ou falhas inesperadas do servidor.
Figura 2: Replicação intra-cluster do Couchbase
O DCP (Database Change Protocol) é outro componente importante de HA do Couchbase. Esse protocolo de streaming de alto desempenho comunica as alterações de dados aos consumidores internos e externos. Ele é responsável por manter os índices secundários globais (GSI) usados para consultas SQL, índices de pesquisa de texto completo (FTS), replicação entre data centers (XDCR, protocolo de replicação entre clusters) e outros serviços.
Replicação bidirecional (entre clusters)
Aplicativos e equipamentos redundantes são, há muito tempo, uma prática recomendada no setor. O ideal é que seu bancos de dados distribuídos são implantados usando a arquitetura Active-Active (AA), quando os aplicativos alternam automaticamente para um cluster diferente em caso de problemas de conectividade. O Couchbase Server oferece suporte ao XDCR bidirecional para permitir cenários AA. No entanto, a consistência eventual dos dados em implantações de vários clusters pode não ser aceitável para determinados aplicativos comerciais.
Em nosso ambiente, descobrimos que, quando os data centers estão localizados a mais de 100 km de distância, a resolução de conflitos de dados se torna um desafio. O Couchbase oferece dois mecanismos de resolução de conflitos: baseado em revisão e baseado em registro de data e hora. Devido à latência de nossa rede, nenhum deles poderia oferecer consistência de dados aceitável no cenário AA completo (quando gravações e leituras podem ocorrer em qualquer cluster). Como resultado, implementamos a arquitetura em que todas as alterações (gravações) são feitas em um único cluster que propaga as alterações para outros data centers. Os aplicativos podem ler dados de qualquer data center.
Escala horizontal
O dimensionamento horizontal (aumento dos recursos do cluster com a adição de novos servidores) é um grande argumento de venda dos bancos de dados NoSQL. O recurso importante do Couchbase Server é a capacidade de dimensionar diferentes cargas de cluster (operações KV, consultas SQL, indexação de dados etc.) de forma independente; o Couchbase chama isso de "dimensionamento multidimensional, MDS" (consulte a Figura 3 abaixo). Cada nó no cluster do Couchbase pode executar um único serviço ou vários serviços; a escolha é feita quando um nó é adicionado ao cluster existente.
Figura 3: Dimensionamento multidimensional (MDS) do Couchbase
Requisitos de segurança da informação
Os recursos de segurança do Couchbase foram outro motivo (embora não o principal) que nos levou a escolher esse sistema. Como é possível que as informações de identificação pessoal (PII) sejam armazenadas no cache, nossa empresa precisa estar em conformidade com as leis vigentes. Se a plataforma de dados não oferecer os recursos de segurança necessários, pode ser necessário adquirir hardware adicional para estar em conformidade
O Couchbase Server Enterprise Edition (EE) oferece suporte à criptografia de tráfego, criptografia de dados e controle de acesso baseado em função (RBAC). Isso potencialmente permite que você economize em hardware de segurança de rede, como o Cisco ASA.
Facilidade de atualização
O Couchbase Server oferece várias opções de atualização diferentes. A opção de atualização on-line permite que seus aplicativos continuem trabalhando com o cluster com impacto mínimo no desempenho e na funcionalidade (devido à compatibilidade com versões anteriores da API). Enquanto os nós do cluster estiverem sendo atualizados, o cluster continuará funcionando em modo de compatibilidade; os recursos da nova versão ficarão ativos quando todos os nós concluírem a atualização.
Funcionalidade adicional
Conscientização de grupos de servidores (conscientização de racks, zonas de disponibilidade)
No Couchbase, servidores individuais podem ser atribuídos a grupos de servidores específicos. Esse recurso é semelhante às zonas de disponibilidade de serviços em nuvem (AZ). Quando grupos de servidores são usados, o algoritmo de distribuição de dados ativos e réplicas garante a disponibilidade total dos dados caso todo o grupo de servidores esteja off-line.
No mundo das telecomunicações, isso nos permite manter conjuntos de dados totalmente replicados em diferentes salas de equipamentos do data center. Se toda a sala de equipamentos (mapeada para um grupo de servidores Couchbase) ficar off-line, os aplicativos continuarão trabalhando com o conjunto de dados completo na outra sala de equipamentos.
Figura 4: Grupos do servidor Couchbase
Backup e restauração
O Couchbase fornece várias ferramentas de backup e recuperação; o cbbackupmgr está disponível somente no EE. O backup pode ser feito de três maneiras diferentes: completo, diferencial e cumulativo. A combinação correta desses modos de backup permite economizar espaço em disco e otimizar o uso de recursos do sistema.
Figura 5: Combinação de backup do Couchbase
Couchbase vs. MongoDB
A escolha de um banco de dados NoSQL entre as tecnologias concorrentes disponíveis pode ser um desafio. [Pelo menos com o sistema operacional Linux é mais fácil: a melhor distribuição do Linux é aquela que seu administrador de sistemas conhece melhor]. Resumimos na tabela abaixo algumas das diferenças importantes que nos convenceram a escolher a tecnologia Couchbase em vez de outra plataforma NoSQL popular, o MongoDB.
É reconhecidamente difícil comparar dois projetos diferentes com arquiteturas e funcionalidades diferentes. Para nós, era importante ter um sistema de fácil manutenção e que pudesse ser rapidamente ajustado às necessidades comerciais em constante mudança.
| Couchbase | MongoDB | |
| Fragmentação | Automático para todo o conjunto de dados | Seleção manual de chaves por coleção |
| Distribuição de dados | Dados sempre distribuídos uniformemente em todos os nós de dados | A fragmentação de intervalos pode resultar em uma distribuição não uniforme |
| Adição/remoção de nós ou fragmentos | Simples, concluído em uma única etapa (por GUI, API REST ou CLI), seguido por um reequilíbrio | Complexo, precisa criar conjuntos de réplicas. Cada coleção é dimensionada de forma diferente |
| Conscientização sobre o rack | Integrado e fácil, por meio de grupos de servidores | Não incorporado, é necessário alocar manualmente os nós do conjunto de réplicas de diferentes racks. |
| Configuração equilibrada | O cluster é sempre equilibrado, com cada nó tendo o mesmo número de vBuckets ativos (shards). | Não balanceado. Os nós secundários não atendem a nenhum tráfego de gravação (nem mesmo tráfego de leitura, por padrão). |
| Aumento de escala do índice | Escalar índices de dados de forma independente. Pode até usar diferentes tipos de hardware para nós de índice. | O escalonamento do índice está associado ao escalonamento dos dados. É necessário adicionar capacidade ao cluster de dados para acomodar as alterações na carga de trabalho da consulta. |
| Metadados do cluster | Não são necessários nós especiais, distribuídos em todos os nós de dados. | Servidores de configuração especial precisam ser configurados, com um mínimo de 3 nós |
| Arquitetura de replicação | Cluster totalmente independente, que pode ser dimensionado e gerenciado sem nenhuma dependência. | Extensão da replicação intra-cluster, não um sistema independente. |
| Flexibilidade de replicação | Muito flexível; nível de balde, técnicas avançadas de otimização para se ajustar à necessidade. | Não é possível fazer ajustes, escolher a velocidade e a largura de banda. |
| Topologia de replicação | Suporte a topologias complexas: bidirecional, estrela, malha, cadeia, anel, etc. | Não há suporte para topologias complexas: unidirecional, estrela. O primário é um gargalo. |
| Replicação ativo-ativo | Com suporte | Não suportado |
De modo geral, o Couchbase é mais flexível e mais fácil de manter e configurar para os casos de uso da MegaFon e para a arquitetura híbrida em constante evolução.
Nossa jornada com o Couchbase até agora
Abaixo estão algumas estatísticas rápidas de nosso cluster de produção do Couchbase e sua carga:
- O cluster processa dados de mais de 80 milhões de assinantes. Esse número inclui telefones celulares, roteadores LTE, vários dispositivos de consumo com cartões SIM integrados, etc.
- 380 milhões de documentos JSON com dados de clientes
- Armazenamento em disco de 3,5 TB (conjunto de dados ativo, réplicas não incluídas)
- 3 TB DE RAM
- 50.000 operações por segundo, sustentadas (consulte a Figura 6 abaixo)
- 50 microsserviços que processam todo o fluxo de mensagens
Figura 6: Carga de produção do Couchbase
Esse projeto de transformação começou com o Couchbase Server versão 3.x. Inicialmente, todos os aplicativos funcionavam de forma estável. No entanto, quando adicionamos uma nova funcionalidade de aplicativo que dependia do uso de exibições do Couchbase, começamos a ter problemas com o comportamento imprevisível das exibições. [As visualizações são um mecanismo de indexação e consulta de mapa/redução. Ele é considerado um recurso legado no Couchbase Server 5.x-6.x. Está sendo eliminado em favor de índices secundários globais e consultas N1QL]. O processo de atualização da visualização em um nó às vezes travava, o que impedia que os aplicativos recebessem os dados da visualização desse nó. As operações de KV continuavam sendo executadas normalmente.
Esse problema poderia ser corrigido reiniciando o nó, o que afetava a disponibilidade dos dados. Como solução temporária (enquanto planejávamos atualizar para o Couchbase Server versão 4.x), o suporte técnico do Couchbase sugeriu o seguinte comando não documentado específico da versão para reiniciar apenas o processo de atualização da visualização:
|
1 2 3 |
# Esse comando só funciona com o Couchbase Server versão 3.x # Não use sem a bênção de seu administrador! enrolar -s --dados 'cb_couch_sup:restart_couch().' -u Administrador:passe http://127.0.0.1:8091/diag/eval |
|
1 2 3 |
# Esse comando só funciona com o Couchbase Server versão 4.x # Não use sem a bênção de seu administrador! enrolar -s --dados 'couch_server_sup:restart_core_server().' -u Administrador:passe http://127.0.0.1:8091/diag/eval |
Outro problema que encontramos na versão 3.x do Couchbase Server foi o encerramento periódico do processo de compactação. O processo tinha de ser reiniciado manualmente ao receber alarmes de monitoramento. Esses dois problemas de produção eram uma dor de cabeça tanto para a equipe de operações quanto para a equipe de desenvolvimento.
Seguindo a recomendação do suporte técnico do Couchbase, decidimos fazer o upgrade para a versão 4.x do Couchbase Server. O processo geral de upgrade levou cerca de duas semanas, já que tínhamos que fazer o upgrade com o mínimo de impacto nos aplicativos de produção. As etapas de upgrade são bastante simples, mas o upgrade on-line contínuo - incluindo remoção de nós, rebalanceamento, upgrade de nós, adição de nós ao cluster e outro rebalanceamento - levava mais de duas horas. Conseguimos otimizar esse processo com a introdução de um nó extra para aproveitar o rebalanceamento de swap do Couchbase. Nesse caso, os dados são copiados diretamente do nó que está sendo removido para o nó que está sendo adicionado, o que acelera bastante o rebalanceamento. Isso reduziu o tempo de upgrade por nó para 30 minutos.
Ao fazer upgrade de um cluster de produção do Couchbase, você deve ter em mente que o cluster operará no modo de compatibilidade, quando somente os recursos da versão mais antiga estarão disponíveis em todos os nós. Isso garante uma atualização tranquila e sem problemas. A desvantagem é que os novos recursos e correções da versão atualizada (índices e consultas N1QL, pesquisa de texto completo etc.) só ficarão disponíveis quando todos os nós do cluster forem atualizados.
Nossa atualização inicial para a versão 4.x corrigiu apenas o problema da compactação. O problema de visualização permaneceu, embora não tenha surgido com tanta frequência. Ele foi totalmente solucionado somente na versão 4.6.4 do Couchbase Server.
Também fomos notificados pelo suporte técnico do Couchbase de que a funcionalidade de visualizações não será mais aprimorada e está a caminho de ser descontinuada. As consultas Global Secondary Indexes (GSI) e N1QL (pronuncia-se "nickel", implementação de SQL do Couchbase) são a alternativa escalável muito melhor para as visualizações. As cargas de índices e consultas podem ser dimensionadas de forma independente, sem estarem vinculadas aos nós de dados (veja a Figura 7 abaixo):
Figura 7: Serviços do Couchbase em nós diferentes
Com a atualização para o Couchbase Sever 4.6.4, resolvemos todos os nossos problemas críticos de produção. No entanto, os novos recursos e aprimoramentos do Couchbase Server 5.1 nos obrigaram a concluir outro ciclo de atualização. Com o novo mecanismo GSI, nossos índices agora ocupam cerca de 1,5 vez menos espaço em disco e na memória, o que ajuda com nosso crescente volume de dados. Infelizmente, a versão 5.1 não oferece nenhuma melhoria no armazenamento de dados (na memória ou no disco). A compactação de dados foi adicionada na versão 5.5.
Conclusão
No geral, o Couchbase Server provou ser uma plataforma de dados madura e de alto desempenho. Como parte da arquitetura híbrida do MegaFon, o cluster do Couchbase pode ser facilmente adaptado a qualquer carga de produção sem tempo de inatividade do equipamento ou alterações extensas na configuração dos servidores. Isso geralmente resulta em redução de custos de pessoal e satisfação do cliente.
O artigo original foi publicado em um popular blog russo de TI colaborativa, o Habrahabr: https://habr.com/ru/post/436762/
