Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cloud Native Banking

Cloud Native Banking

Presented at DevOps Days Floripa 2019 (and earlier versions on TDC SP and TDC BH), with Diogo Beato

Alexandre Cisneiros

July 27, 2019
Tweet

More Decks by Alexandre Cisneiros

Other Decks in Programming

Transcript

  1. Cloud Native Banking Alexandre Cisneiros Software Engineer Diogo Beato Software

    Engineer Como o Nubank usa imutabilidade na nuvem para atender milhões de clientes
  2. Internacional, sem taxas e controle total pelo app. Eleito o

    cartão de crédito favorito dos brasileiros pela PNCC Cartão de Crédito
  3. um programa de pontos totalmente diferente de outras experiências no

    mercado brasileiro. 100% digital, simples e intuitivo. Rewards
  4. nossa visão de uma conta de banco simples e inteligente.

    Seu dinheiro rendendo sempre Nuconta
  5. Autonomia Times empoderados para executar independentemente Cloud Native Banking Velocidade

    Sistemas evoluindo rapidamente e de forma incremental Segurança Bancos precisam de reputação Estratégia Baixo custo inicial e time to market
  6. Crescimento acelerado em um domínio crítico 1B+ requisições http/dia 270+

    microsserviços 260+ engenheiro(a)s 700M+ mensagens kafka consumidas/dia 50+ deploys/dia
  7. Message System Lags de mensageria impactando a UX Database Limite

    no throughput de escrita do banco Problemas de escalabilidade
  8. DIVIDIR O TRABALHO Era preciso dividir a carga entre os

    micro-serviços e a infra INTERAÇÃO ENTRE CLIENTES No nosso domínio a interação entre os clientes é baixa PADRÕES DE DADOS Cada micro serviço é responsável por salvar um tipo de dado dos clientes DIVIDIR POR CLIENTE O melhor caminho foi separar a infra por grupos de clientes Plano de escalabilidade
  9. GARGALO NO BANCO DE DADOS Vazão de escrita no banco

    são os piores gargalos CAMADA DE ROTEAMENTO Os serviços teriam que saber rotear queries e escritas pro banco certo DIVIDIR O BANCO DE DADOS Cada micro-serviço teria que se conectar com N bancos Database Shards? db shard 1 microservice db shard 0 db shard 2
  10. MUITO ESFORÇO Teria que ter um enorme esforço para mudar

    todos microsserviços ALTO RISCO Migração com alto risco de introduzir bugs e acoplar código de negócio com código de infraestrutura RESOLVE APENAS 1 PROBLEMA Resolve apenas o problema de gargalo do banco mas não resolve os problemas de mensageria Database Shards? db shard 1 micro-service db shard 0 db shard 2 problemas com essa solução
  11. CÓPIAS DA INFRA TODA Ao invés de fazer sharding apenas

    do banco de dados MAIS ESCALABILIDADE Unidades de infraestrutura idênticas e facilmente criadas ISOLAMENTO DE RISCOS Mais difícil uma falha afetar o Nubank inteiramente Infrastructure Shards! service 1 service 2 service 3 shard 03 service 1 service 2 service 3 shard 02 service 1 service 2 service 3 shard 01
  12. Infrastructure Shards! service 1 service 2 service 3 shard 03

    service 1 service 2 service 3 shard 02 service 1 service 2 service 3 shard 01 auth compras boletos global Nubank Cloud
  13. Fácil de Escalar shard 03 shard 02 shard 01 global

    routing layer Nubank Cloud shard 04
  14. Reduz o Blast Radius shard 03 shard 02 shard 01

    global routing layer Nubank Cloud shard 04 X
  15. JVM LISP É uma linguagem lisp que roda em cima

    da JVM. PRODUCTIVE Simples e fácil de aprender e possui um workflow focado em produtividade usando REPL FUNCIONAL Enforça o paradigma funcional. Possui estrutura de dados imutáveis Clojure
  16. GIT PARA DADOS Mantém todo o histórico de alteração de

    dados STORAGE DESACOPLADO Roda em cima da camada de storage o que nos permite usar diferentes tipos de storage para diferentes environments QUERIES NO PASSADO Essa característica permite que a gente consulte como o dado estava meses atrás Datomic
  17. CANAL DE COMUNICAÇÃO Kafka é o canal de comunicação entre

    os serviços do Nubank. Praticamente toda interação crítica entre serviços é via kafka RESILIÊNCIA Kafka trás muita resiliência para nossos sistemas. Além de algumas implementações como Deadletters & Circuit-breakers MENSAGENS PERSISTENTES As mensagens são persistidas em disco e ficam lá mesmo após serem consumidas. A mesmas mensagem pode ser consumida várias vezes Kafka
  18. PORTS & ADAPTERS Aplicação é a parte central do código

    e todo IO fica isolado ADAPTERS Transforma os dados para adaptá-los do mundo externo para o mundo interno e vice-versa PORTS Por onde os dados entram e saem da aplicação Arquitetura de Microserviço
  19. Mas e se ...? VULNERABILIDADE ZERO-DAY sai uma CVE do

    kubernetes e precisamos atualizar todos os clusters? ALTERAR SYSTEM UNITS A gente precisa mudar a forma como os serviços enviam logs pro nosso centralizador de logs? ATUALIZAR VERSÕES A gente precisa atualizar a versão de algum componente crítico na nossa infra? (Docker, CoreOS, Kafka...)
  20. Engenharia triste :( SSH PRA CADA MÁQUINA? Simples e resolve

    quando o volume de máquinas que a empresa tem é baixo. Porém pode dar muito errado caso for feito sem cuidado. SCRIPTS DE AUTOMAÇÃO? Pode gerar estados inconsistentes. Gerando crashes que precisam de solução imediata e que serão difíceis de debugar.
  21. Imutabilidade Dar um passo a frente com a possibilidade de

    dar um passo atrás caso as coisas deem errado É como um save-as… button
  22. Infraestrutura imutável RÁPIDOS FEEDBACKS podemos testar e com segurança e

    ter feedbacks rápidos sobre as mudanças SEGURO PARA GRANDES MUDANÇAS ter feedbacks rápidos e ser fácil de se recuperar traz segurança para fazermos grandes mudanças com confiança FÁCIL DE SE RECUPERAR quando as coisas saem errado é fácil de se recuperar e reduzir o impacto para os clientes
  23. Infraestrutura como código {:name :staging :shards {:global [:global] :sharded [:s0

    :s1] :defaults {:workload [:burst :small]}} {:name :prod :shards {:global [:global] :sharded [:s0 :s1 :s2 :s3 :s4 :s5 :s6] :defaults {:workload [:generic :large] :scaling {:min-size 2} :jvm {:flags [“-Xfuture"]}}} Definição declarativa dos environments
  24. Infraestrutura como código {:name :billing :squad :bills :envs {:prod :sharded

    :staging :sharded} :jvm {:strategy :g1} :scaling {:min-size 8}} {:name :auth :squad :infosec :envs {:prod :global :staging :global} :workload [:nitro :2x-large] :scaling-policies [:cpu_high_alarm :cpu_low_alarm]} Definição declarativa dos microsserviços
  25. Kubernetes Orquestrador de containers Autoscaling rápido e dinâmico Pronto para

    microserviços Direciona para infraestrutura imutável Iterações curtas Capacidades de autorremediação
  26. EC2s Cloud Formation Provisionamento deploy Internal Clojure project wrapping cloud

    APIs definition Internal Clojure project with all declarative infra
  27. Cloud Formation Provisionamento deploy Internal Clojure project wrapping cloud APIs

    definition Internal Clojure project with all declarative infra Kubernetes
  28. Escalabilidade A nuvem é tão escalável quanto nossa arquitetura Lições

    Aprendidas Velocidade Nós somos tão rápidos quanto nossa automação Autonomia Infraestrutura como código para empoderar as pessoas Resiliência Arquitetura planejada para falhas parciais