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

AWS Meetup - Processando dados em alta escala c...

AWS Meetup - Processando dados em alta escala com Node.js e AWS Lambda

Esta apresentação discute como processar grandes volumes de dados do Twitter em tempo real usando AWS Lambda e Kinesis. A solução proposta usa Lambda para ler dados do Kinesis e indexá-los no ElasticSearch para permitir checagens em tempo real, resolvendo problemas de escalabilidade do ElasticSearch. Isso fornece elasticidade, tolerância a erros e capacidade de lidar com picos de tráfego.

Daniel Baptista Dias

May 15, 2018
Tweet

More Decks by Daniel Baptista Dias

Other Decks in Programming

Transcript

  1. O desafio - Como sincronizar dados com o Twitter? •

    Por que sincronizar? ◦ #arrependimento (#ou #não?)
  2. O problema é... Em um dia não podemos sincronizar a

    base de um mês com a API do Twitter !
  3. O problema é... • Captura de dados (na época): ◦

    ~ 18 milhões de tweets/mês ◦ ~ 300 milhões de registros/mês • Checagem de tweets (via Twitter API /statuses/lookup): ◦ 8 milhões de tweets/dia
  4. É possível... É só ter capacidade para checar este volume

    de dados via a API de real-time do Twitter: 50 mil registros / minuto ~ 834 registros / segundo 72 M registros / dia
  5. É possível… será? Como fazer isso com uma base histórica

    de mais de 4 TB e mais de 300 bilhões de registros?
  6. Listener (Node.js) Scup Core Read Replica DB Escrita Compliance (Node.js)

    Indexador (Elastic Search) Uma primeira solução !
  7. Uma primeira solução! • Listener: ◦ ter uma máquina "parruda"

    para suportar a conexão do Twitter ◦ utilizar o PM2 para gerenciar o app em Node.js
  8. Uma primeira solução! • Listener: ◦ ter uma máquina "parruda"

    para suportar a conexão do Twitter ◦ utilizar o PM2 para gerenciar o app em Node.js • Compliance: ◦ uma api em Node.js usando Express ◦ utilizar um Elastic Search pré-existente com os dados necessários indexados para aliviar a carga no Scup Core (e no banco)
  9. Listener (Node.js) Scup Core Read Replica DB Escrita Compliance (Node.js)

    Indexador (Elastic Search) Momento de pico: 500 mil registros / minuto Uma primeira solução ! #sqn ("Ué o ES não segurava?") x 10
  10. Listener (Node.js) Scup Core Read Replica DB Escrita Compliance (Node.js)

    Indexador (Elastic Search) Momento de pico: 500 mil registros / minuto Uma primeira solução ! #sqn ("Ué o ES não segurava?") x 10
  11. Características necessárias • Escalabilidade ◦ devemos suportar o volume de

    dados • Tolerância a erros ◦ • Elasticidade (+) ◦
  12. Características necessárias • Escalabilidade ◦ devemos suportar o volume de

    dados • Tolerância a erros ◦ erros ocasionais não devem impactar o todo • Elasticidade (+) ◦
  13. Características necessárias • Escalabilidade ◦ devemos suportar o volume de

    dados • Tolerância a erros ◦ erros ocasionais não devem impactar o todo • Elasticidade (+) ◦ queremos utilizar os recursos certos na hora certa
  14. Listener (Node.js) Scup Core Read Replica DB Escrita Compliance (Node.js)

    Indexador (Elastic Search) Onde elas não estão ok?
  15. AWS SQS (Simple Queue Service) • Engine de filas da

    Amazon • Permite que cada leitor "reserve" os dados lidos por um período de tempo • Possui mecanismo de "dead letter" caso algum erro de leitura ocorra com frequência Produtor SQS Consumidor
  16. AWS Kinesis Streams • Engine de processamento de Streams em

    Tempo Real • Semelhante ao Apache Kafka, uma "fila" que pode ter múltiplos leitores • Leitura de dados rápida (cerca de 300 ms) Produtor Kinesis Stream Shard 1 Shard 2 ... AWS Lambda KCL Apps Outros consumidores
  17. AWS Lambda • Executa funções sem servidores ("Serverless", "Function as

    a Service") • Acionamento através de eventos, escalando a medida que eles são disparados • Atualmente suporta Node.js (4.3, 6.10 e 8.10), Python (3.6 e 2.7), Java 8, C# (.Net Core 1.0.1 e 2.0) e Go 1.x Evento Função Resultado
  18. AWS Lambda e AWS Kinesis É possível definir o número

    de registros a ser lido por um único lambda Caso haja erro na leitura, o ponteiro do Kinesis congelará nos registros com erro até os dados serem lidos corretamente ou expirarem (1 ou 7 dias) Produtor Kinesis Stream Shard 1 Shard 2 ... AWS Lambda 1 AWS Lambda 2 AWS Lambda ...
  19. Características da solução • Escalabilidade e Elasticidade ◦ ajustamos a

    capacidade de leitura em função dos shards do Kinesis ◦ mais ativação de Lambdas em razão ao volume de dados • Tolerância a erros ◦ o Lambda tem mecanismos de retries em caso de erro (por exemplo, timeouts de queries)
  20. Listener (Node.js) SQS Scup Core Read Replica DB Escrita Kinesis

    Compliance (Node.js) Indexador (Elastic Search) Solução final
  21. Listener (Node.js) SQS Scup Core Read Replica DB Escrita Kinesis

    Compliance (Node.js) Indexador (Elastic Search) Momento de pico ? 500 mil registros / minuto Solução final
  22. Quem sou? #Senior Product Engineer at Sprinklr #MSc em IA

    pela USP #Artista marcial há 10 anos #Pai coruja / Zumbi