Arquiteturas escaláveis utilizando ferramentas Shared Nothing. Victor Canô

Transcrição

1 Arquiteturas escaláveis utilizando ferramentas Shared Nothing Victor Canô

2 Victor Canô - Founder / Cazamba - Troz.io /victoracano

3 Conteúdo O que esperamos de uma aplicação? Cloud, benefícios e cuidados Escalando aplicações Caso Cazamba Arquitetura Shared Nothing Utilização de algumas ferramentas para escalar em todo nível da aplicação

4 Aplicação WEB O que é esperado? Escalável Performance Alta Disponibilidade Custo baixo Constantes atualizações

5 Aplicação WEB O que é esperado? Elas estejam sempre funcionando Sem lentidão Sem custos excessivos Não se tornem obsoletas mesmo quando sua utilização cresce

6 Cloud for the rescue! Elasticidade Custo baseado em uso Serviços e recursos de todo tipo

7 Cloud for the rescue! Warning! Cloud pode nos dar a ilusão de escala sem grandes problemas Aplicação deve estar preparada para escalar. Especialmente se você planeja escalar para usar milhões ou bilhões de dados

8 Cloud for the rescue! Warning! Não se planejar para utilizar esses recursos pode te levar à direção contrária Gargalos, planejamento de custos ineficaz, falhas em serviços, pode trazer grandes problemas

9 Um caso real

10 Um caso real Exemplos de formatos oferecidos. Formatos diferenciados HTML5 + Javascript

11 Um caso real Exemplos de formatos oferecidos. Formatos diferenciados HTML5 + Javascript

12 AdServer Segmentações por Cookie O Cookie guarda as informações de acesso Histórico Perfil Segmentos

13 AdServer Segmentações por Cookie Idade SEXO Educação Interesses

14 Um caso real Aplicação Cazamba 1 AdServer 1. Cada acesso faz uma chamada ao AdServer (500ms max!) 2 CDN 2. O AdServer retorna o anúncio, e a CDN entrega o conteúdo estático 3 AdTrackers 3. Todo evento (Impressão, Click, Interação, etc.) é registrada pelo AdTracker

15 Métricas de Tracking Utilizadas no inicio da Cazamba CTR% Clicks / Impressões ER% Expansões / Impressões UV Unique Viewers

16 Um caso real Cenário atual 900 sites na rede 300MM pageviews mensais 80% 60MM de usuários únicos 12MM de escritas diárias em nossos bancos Picos de até 70k TPS

17 Arquitetura tradicional de uma aplicação APP

18 Arquitetura tradicional de uma aplicação APP APP APP

19 Escalando a aplicação APP APP APP

20 Escalando a aplicação APP APP APP

21 Escalando a aplicação APP APP APP +

22 Replicando o banco de dados APP APP APP

23 Divindo o Banco de dados APP APP APP

24 Points of failure!! APP APP APP

25 Limitações deste modelo Custos mais elevados (escala Vertical) Grande número de configurações de servidores Maior tempo gasto em infra, menor em códigos Disponibilidade Escala limitada Vulnerável à falhas!

26 Alternativas Cloud Content Delivery Database as a Service Load Balancers Cache Queue Etc

27 Escala da aplicação Não levar em conta apenas aumento de clientes Novas funcionalidades utilizam mais recursos BI é um diferencial competitivo O mercado pode demandar novos features

28 Escala da aplicação Mercados competitivos Cada vez mais dados, em menos tempo Desenvolvimento contínuo Demandas não previstas Como?

29 Início APP APP APP

30 Escalando Cada vez mais Sites Cada site Gera dezenas de vezes mais dados Mais Banners Mais usuários únicos Picos de acesso Novos segmentos

31 Novas Métricas Tempo de exibição de vídeo CPV = Visualização de vídeo contada a partir de X segundos Viewability Tempo de expansão da peça

32 Processamento assíncrono APP APP APP APP APP

33 Evolução APP APP APP APP APP

34 Novos recursos Banners mais flexíveis e customizáveis Necessidade interna de BI Oferta de audiência não supre demanda

35 Necessário armazenar os dados agregados Anterior: ID Time Segmento Publish er Count 1 xxxxx Sexo:H xxxxx Interesse:Tech xxxxx Interesse:Musica Hoje: 4 xxxxx Sexo: M Homem- Interesse em Tecnologia- Interesse em Música- Sao Paulo++

36 Necessário armazenar os dados agregados Anterior: N Segmentos x N Sites por dia 30 segmentos x 100 sites = linhas/dia Hoje: Todos os acessos (300MM/mês)

37 O que percebemos? Cada recurso processa muito mais dados O mercado evolui as métricas muito rápido Necessidades internas de otimização Necessário escalar múltiplas vezes!

38 Complexidades na escala Não conseguíamos escalar facilmente Para manter o sistema funcionando, muito tempo gasto gerenciando os serviços Vimos que era necessário repensar a arquitetura E além disso Os pontos de falha!

39 Limitadores de escala e Pontos de falha APP APP APP APP APP

40 Solução: Shared Nothing Cada nó do cluster é independente Os dados podem ser replicados e divididos A falha de uma instância não compromete o os dados e serviço

41 Solução: Shared Nothing Requisições podem ser divididas no cluster Configuração padronizada das instâncias Escala horizontal!

42 Armazenamento de dados SN Exemplo: Cluster com nós 5 nós Fator de replicação 1 Chave primária define o nó master

43 Armazenamento de dados Exemplo: Cluster com nós 5 nós Fator de replicação = 3!

44 Armazenamento de dados Exemplo: Query em um cluster Fator de replicação = 3!

45 SOA + SN = Escala em todo nível da aplicação Arquitetura orientada ao serviço (SOA) + Shared Nothing = Escalabilidade + No SPOFs!

46 Empresas que utilizam este modelo

47 Transição de Bancos de dados Bancos relacionais tradicionais!= Shared Nothing Alternativa: Bancos NoSQL

48 Por que NoSQL? Baixa latência Dados não relacionais Escritas rápidas Quantidade massiva de dados Schema- less

49 Bancos de dados NoSQL SQL para NoSQL - É uma transição complexa Cada aplicação tem necessidades específicas Quatro tipos principais: Key- Value, Column, Document e Graph Cada ferramenta possui deployments e características específicas

50 Bancos de dados NoSQL

51 O que esperávamos do DB? Baixa complexidade em distribuição Escala Linear Maior disponibilidade Sem risco de falha

52 Novas ferramentas Cassandra ElasticSearch Aerospike

53 ACID :( Atomicidade Consistência Isolamento Durabilidade Principais diferenças teóricas

54 Fonte: É necessário escolher dois!

55

56 Transição para o Cassandra Armazenar os dados de eventos ++ hora0 hora1 hora2 horan campanha:evento X X X X hora0 hora1 hora2 horan campanha:evento:site X X X x timeuuid1 timeuuid2 timeuuid3 timeuuidn log:dia data data data data Dados armazenados sequencialmente!

57 Transição para o NoSQL Ainda assim, como agregar os dados rapidamente? Dezenas de milhões de dados? Cassandra não era uma opção

58

59 Transição para o ElasticSearch Uma ferramenta de busca Indexa todas as colunas Distribui as queries Analiza e agrega os dados Aceita vários tipos de dados (string, int, geo,..) API REST

60 Transição para o ElasticSearch Inserção dos formatos por JSON Não é necessário schema, tipo do dado é descoberto automaticamente Indexação muito rápida Cassandra River!

61 ElasticSearch + Kibana :O

62 Desafios do AdServer A quantidade de requisições feitas no banco ainda era muito grande, em tempo real Para atender a latência máxima de 500ms - Bancos em memória O gerenciamento do cache era complexo

63 Desafios do AdServer Bancos em memória não estavam suprindo a quantidade de dados Redis é single threaded Memória RAM era o limite 10M de usuários 60M de usuários 10Kb 10Kb 10Gb 60Gb

64 Desafios do AdServer + Replicação + Novos dados a serem guardados? 10M de usuários 60M de usuários 10Kb 10Kb 10Gb 60Gb 60M de usuários 30Kb 180Gb

65

66 Aerospike NoSQL - Segunda geração Armazenamento híbrido em memória e SSD Velocidade de memória, com capacidade de SSD Queries distribuídas Scripts em LUA para agregação

67 AEROSPIKE Indexação em RAM HYBRID MEMORY SYSTEM Dados em SSD Indexes secundários Clientes Inteligentes Transações <1ms BLOCK INTERFACE OPEN NVM SSD SSD SSD

68 Aerospike Aplicação inicial em caching Alta velocidade nas operações com menos Decisão de migrar do C*

69 Transição para o NoSQL Aerospike para registro dos dados e Caching ElasticSearch para busca e agregação rápida Caching otimizado, compartilhado entre Apps Redução de custos! 3 intâncias Redis + 8 Cassandra = 3 Aerospike menor custo fixo (escala Horizontal)

70 Benefícios obtidos :D o/ Escala = Adição de nós Sem pontos de falha Mesmo código para milhares ou milhões de operações Configurações padronizadas nas instâncias Pouca manutenção = Foco na aplicação!

71 Arquitetura final Cazamba </> </> </> APLICAÇÃO SERVIÇOS

72 Resumo Levar em conta não apenas a escala linear da aplicação, contar com demandas imprevistas Instâncias e serviços podem falhar, sua aplicação não (No Single Points of Failure!) Contar apenas com a escala vertical pode limitar sua escala e aumentar seus custos

73 Alguns links interessantes

74 Perguntas?

75 Obrigado! Victor Canô /victoracano