Segredos da tolerância a falhas do nosso escritório

Como é organizado um banco moderno? Há um back office onde várias operações são realizadas, contas e relatórios são mantidos. Há um escritório intermediário onde as decisões são tomadas e os riscos são avaliados, onde os riscos de crédito são avaliados e os fraudadores são neutralizados. E existe um escritório na frente onde eles atendem aos clientes e são responsáveis ​​por sua interação com o banco por meio de vários canais.



O Sberbank possui centenas de sistemas com disponibilidade e confiabilidade variadas. Ele tem seu próprio desenvolvimento e soluções in a box com diferentes graus de customização, diferentes SLAs. Todos os sistemas são integrados entre si de várias maneiras. Neste post, mostraremos como todo esse formigueiro front-end é construído de maneira a fornecer um atendimento contínuo ao cliente.

Vamos começar com a teoria. Os principais princípios pelos quais um sistema à prova de falhas é construído podem ser emprestados de um submarino:

1. O submarino é dividido em compartimentos independentes. Se um compartimento é inundado, o restante ainda sobrevive.
   
2. Todos os componentes críticos são reservados. Motores, tanques de oxigênio. E os Beatles também reservavam periscópios com vigias.
   
3. O submarino é protegido de condições críticas na superfície - se necessário, pode ir mais fundo e trabalhar lá como se nada tivesse acontecido.
   

Ilustramos o primeiro princípio com um exemplo de nossa prática. Tínhamos um sistema de cache distribuído. E uma vez carregado, um dos nós de dados do cache falhou. Não há problema: para manter a replicação adequada, o controlador redistribuiu os dados para os nós restantes. Mas como resultado da redistribuição, o tráfego de rede saltou e os pacotes começaram a ser perdidos - incluindo sobrecarga de cache. Em um ponto, o controlador decidiu que outro nó de dados falhou, redistribuiu os dados novamente, o tráfego aumentou ... Como resultado, em menos de um minuto o sistema caiu completamente. Felizmente, foi um circuito de carga e ninguém ficou ferido. Mas passamos muito tempo procurando a causa.

Pode-se argumentar que isso não acontece com bancos de dados em cluster e servidores de última geração - há redundância embutida no nível do hardware. Para citar Werner Vogels, CTO Amazon: "Tudo falha o tempo todo." Nós caímos e clusters de banco de dados e servidor high-end. Caiu devido a erros de configuração, devido a problemas no software de gerenciamento. Com a solução de cada problema, nossa confiança nessas soluções diminuiu. Como resultado, chegamos à conclusão: apenas os sistemas que são divididos em partes independentes um do outro - principalmente independentes em gerenciamento - não recusam.

Arquitetura multi-bloco

A solução para nossos problemas foi a arquitetura com vários blocos. Nele, todos os componentes de hardware, incluindo bancos de dados, são divididos em blocos fracamente acoplados, quase independentes. Cada bloco serve parte dos clientes, como ao compartilhar em bancos de dados. Os nós em cada bloco são reservados em todos os níveis, incluindo redundância geográfica. Qualquer problema em um bloco não afeta os outros. Com um aumento no número de clientes, podemos adicionar facilmente novos blocos e continuar trabalhando normalmente.


Arquitetura geral de blocos. Todos os blocos são reservados de acordo com o esquema 2N. Cada data center possui um poderoso balanceador de carga de hardware. Os data centers são conectados por 2 a 3 canais de comunicação independentes.

Os servidores são distribuídos em blocos de cinco tipos:

• Router - uma unidade de controle que distribui clientes para o restante das unidades
  
• Bloco de clientes - o bloco principal que atende até 10 milhões de clientes
  
• Bloco piloto - aqui testamos novas versões de aplicativos em clientes fiéis (aproximadamente 300 mil pessoas, principalmente funcionários do Sberbank)
  
• Unidade de convidado - usuários não autenticados são atendidos por ela; aqueles, por exemplo, que acessam o site
  
• Bloco de reserva - um bloco de segurança poderoso o suficiente para substituir dois blocos de clientes ao mesmo tempo
  

Dentro de cada bloco, o servidor de aplicativos e o servidor da web são separados por canais de serviço, mas os bancos de dados são comuns. Assim, podemos isolar os cenários de falha mais comuns para que eles não ultrapassem os limites do nosso canal.

Como isso funciona?

Primeiro, o usuário entra na unidade do roteador. Este bloco verifica a qual cliente o cliente pertence e o envia para lá (ou para o convidado). Além disso, uma pessoa trabalha calmamente dentro de seu quarteirão. Se ocorrer uma falha na unidade nativa, a pessoa retornará ao roteador e receberá automaticamente uma direção da unidade de backup para trabalho adicional.

O que acontece com os dados durante a operação? As informações sobre a interação do cliente com o banco são replicadas continuamente dos blocos do cliente para o banco de dados de arquivamento. Tendo encontrado o usuário, a unidade de backup extrai as informações necessárias sobre ele do banco de dados de arquivamento e, se necessário, fornece dados - para que o usuário não congele quando surgem problemas de nossa parte.

As operações que são conduzidas na unidade de backup são armazenadas nela. Quando o bloco do cliente nativo do usuário é restaurado, ele volta. As operações acumuladas no bloco de backup são transferidas de forma assíncrona para os blocos de cliente necessários. Enquanto os dados são reduzidos à consistência, o cliente vê uma mensagem informando que todas as operações foram aceitas e salvas, mas devido ao trabalho técnico, as operações mais recentes podem não ser exibidas.


Esquema geral do sistema

Em alguns casos, a mudança para o bloco de backup é planejada com antecedência - por exemplo, ao atualizar no bloco do cliente. Em seguida, a unidade de backup não seleciona as sessões do cliente, mas em um determinado momento ela simplesmente inicia todas as novas operações. Se você precisar mudar urgentemente para a unidade de backup, o administrador poderá desativar todas as sessões. Nesse caso, a sessão do usuário será interrompida e ele iniciará uma nova na unidade de backup. A unidade do roteador, a propósito, possui sua própria unidade de backup dedicada. Portanto, ninguém fica sem uma roda sobressalente.

Atualização de sistemas

Novas versões de software são implantadas primeiro no bloco piloto e são mostradas a um público limitado. Então gradualmente nos blocos de clientes, e já no final - nos de reserva. Portanto, se houver problemas no bloco do cliente com a nova versão do software, podemos transferir clientes para o bloco de backup da versão anterior.

Quando uma nova funcionalidade rola para um bloco, ela não liga automaticamente. Os administradores fazem isso usando as caixas de seleção - alternar entre recursos. Você pode mudar os clientes para a nova versão por grupos - é assim que verificamos a reação das atualizações ao crescimento do público.

Autonomia

Nosso sistema em si é confiável, mas ainda depende do back-end usado para operações. Como se proteger de problemas? Nós usamos três ferramentas.

1. Pedidos pendentes . O cliente solicita que a operação seja concluída. Nós o salvamos em nosso banco de dados e tentamos executá-lo no back-end. Se o back-end não responder, mostramos ao cliente uma mensagem de que a operação foi aceita e está sendo processada. Quando o back-end aumenta, uma "janela de encaixe" separada lê operações incompletas do banco de dados e as "empurra" em lotes no sistema de back-end. Para não sobrecarregar a tabela principal com operações com um grande número de consultas de baixa eficiência, também usamos a chamada tabela de token - uma lista de identificadores de operações incompletas. Para não eliminar o back-end que acabou de aumentar em centenas de milhares de operações, usamos lotes - eliminamos duzentas operações e esperamos, por exemplo, por alguns segundos.
   
   
   
   Mas e se ocorrerem alterações importantes entre a solicitação do usuário e a recuperação de back-end? Por exemplo, as taxas de câmbio mudaram? Nesse caso, a verificação dupla é acionada. Essas operações são salvas na entrada e depois verificadas na execução. Se algo não convergir, a operação será ajustada ou rejeitada.
   
2. Armazenamento em cache de dados . Quando um usuário entra, por exemplo, no Sberbank Online, todas as informações necessárias sobre ele já são visíveis - contas, cartões, empréstimos etc. Esses dados são solicitados através de um barramento de serviço de uma dúzia de sistemas. Se a resposta foi coletada rapidamente, em alguns segundos, mostramos os dados para o cliente e salvamos no cache do sistema de nosso banco de dados. Caso contrário, procuramos no banco de dados dados armazenados em cache anteriormente e mostramos ao cliente. Obviamente, para isso, o cache não deve ter mais que uma certa idade. No entanto, quando o barramento de serviço coleta os dados necessários sob demanda, ele é atualizado no cache do banco de dados e enviado ao cliente em vez dos antigos.
   
   Ao usar o aplicativo, isso significa que uma pessoa verá o status de sua conta alguns segundos depois de entrar. Embora os dados possam estar um pouco desatualizados. Se isso acontecer, depois de alguns segundos, os dados geralmente serão substituídos pelos dados reais - o que significa que o barramento de serviço coletou tudo o que você precisa.
   
   Além disso, temos pré-armazenamento em cache usando replicação. Principalmente para diferentes dados de referência. Nós pré-carregamos esses dados no back-end, o cliente calmamente faz uma solicitação para a operação e os enviamos. Mesmo se os sistemas responsáveis ​​pela manutenção dos dados não funcionarem, o usuário não precisará esperar mais uma vez.
   
3. Pausas técnicas . Se o sistema de back-end falhar ou estiver em manutenção, nós o sinalizamos. E então as operações que passam por ele são imediatamente atendidas pela recusa. Portanto, evitamos que o servidor de aplicativos fique cheio de solicitações aguardando uma resposta por tempo limite. Nesse modo, o armazenamento em cache de operações e dados que descrevemos anteriormente pode ser usado. As quebras técnicas são definidas para cada cenário de integração, manualmente pelo administrador ou automaticamente, com base no número de solicitações.
   

De qualquer forma, procuramos minimizar a expectativa do usuário - se houver problemas, ele receberá imediatamente uma mensagem sobre a impossibilidade da operação. Tentamos minimizar o número dessas mensagens e, portanto, aumentamos o tempo de vida de alguns dados em cache - isso nos permite estender a interação normal com os serviços do banco.

Em alguns cenários, o armazenamento em cache não deve ser descartado - por exemplo, ao emitir dinheiro. É possível fraude por parte do cliente. Tais operações em caixas eletrônicos e agências não são armazenadas em cache. No banco da Internet, isso é mais fácil - aceitamos o aplicativo, processamos ou rejeitamos.

Como resultado, observando os princípios descritos no artigo, você pode obter sistemas com uma disponibilidade de 99,99% e superior.

Nossos planos

Agora, os planos são minimizar o tempo de colocação no mercado de nosso sistema único, garantir a omnichannelity, levando em consideração os recursos técnicos e de negócios dos canais. E também migre sistemas legados, mantendo sua operacionalidade durante a mudança.

Agradecemos a Roman Shekhovtsov pela assistência ativa na preparação do post