O documento discute como processar grandes volumes de dados do Twitter em tempo real usando AWS Lambda e Kinesis. A solução inicial usava Node.js e Elasticsearch, mas não era escalável. A nova solução usa Kinesis para streaming de dados, Lambda para processamento e Elasticsearch para indexação, fornecendo escalabilidade, tolerância a erros e elasticidade.

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

4. O desafio - Como sincronizar dados com o Twitter?
● Por que sincronizar?

5. O desafio - Como sincronizar dados com o Twitter?
● Por que sincronizar?
○ #arrependimento (#ou #não?)

6. O desafio
Não mostrar dados deletados (ou bloqueados) do
Twitter em nosso produto

7. O problema é...
Em um dia não podemos sincronizar a base de um
mês com a API do Twitter, como faremos isso em
real-time?

8. 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

9. A solução

10. A solução
Escutar todos os deletes do Twitter no mundo !

11. A solução
Escutar todos os deletes do Twitter no mundo !

12. É 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

13. É possível… será?
Como fazer isso com uma base histórica de
mais de 4 TB e mais de 300 bilhões de
registros?

14. Listener
(Node.js)
Scup Core
Read
Replica
DB
Escrita
Compliance
(Node.js)
Indexador
(Elastic Search)
Uma primeira solução !

15. 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)

16. Comentamos sobre os picos de acesso ao
Twitter?

17. 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

18. E agora?

19. Características necessárias
● Escalabilidade
○
● Tolerância a erros
○
● Elasticidade (+)
○

20. Características necessárias
● Escalabilidade
○ devemos suportar o volume de dados
● Tolerância a erros
○
● Elasticidade (+)
○

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

22. 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

23. Listener
(Node.js)
Scup Core
Read
Replica
DB
Escrita
Compliance
(Node.js)
Indexador
(Elastic Search)
Onde elas não estão ok?

24. Indexador
(Elastic Search)
Compliance
(Node.js)

25. SQS
Indexador
(Elastic Search)
Compliance
(Node.js)

26. 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

27. SQSKinesis
Indexador
(Elastic Search)
Compliance
(Node.js)

28. 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

29. SQSKinesis
Indexador
(Elastic Search)
Compliance
(Node.js)

30. 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.2 e 6.10.2), Python (3 e 2.7), Java 8 e C# (.Net Core 1.0.1)
Evento Função Resultado

31. 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 ...

32. SQS
Kinesis
Compliance
(Node.js)
Kinesis
Kinesis
Kinesis
Kinesis
Indexador
(Elastic Search)

33. 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)

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

35. 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

36. Muito obrigado !
danielbpdias@gmail.com
https://github.com/danielbdias
https://www.slideshare.net/DanielDias10
https://github.com/danielbdias/nodebr-meetup-lambda-kinesis-demo

37. Dúvidas ?
danielbpdias@gmail.com
https://github.com/danielbdias
https://www.slideshare.net/DanielDias10
https://github.com/danielbdias/nodebr-meetup-lambda-kinesis-demo

38. Open source @ Sprinklr
Conheça os nossos projetos em https://github.com/scup
● Speck - Entidades de domínio com validações reativas
● Nodebase - boilerplates de NodeJS da Sprinklr
● Speck Sequelize Repository - modelos de repositório de acesso a dados
com o Speck