AWS Community Day Brasil 2021 - Distribuindo Dados Globalmente com Aurora, DynamoDB e EslatiCache.

Palestra feita no evento AWS Community Day Brasil 2021: https://www.awscommunityday.com.br/

Transcript

1. BRASIL
2. Distribuindo Dados Globalmente com Aurora, DynamoDB e ElastiCache William Lino Oliveira | DBRE @ C6 Bank, Principal Cloud Architect @ Data Tuning e Flapper
3. Agenda • Bancos de dados Distribuidos • Desafios na distribuição de dados de forma continental • Aurora • DynamoDB • ElastiCache • Casos de Uso
4. William Lino Oliveira • Engenheiro da Computação • Espec. Eng. e Adm. Banco de Dados • 5x AWS Certified • 4x Azure Certified • Canal Youtube: Data Tuning • Blog: datatuning.com.br/blog • Blog Pessoal: codedataops.com • Database Reliability Engineer @ C6 Bank • Principal CSA @ Data Tuning e Flapper • Marido, pai da Nala e Kira
5. Bancos de Dados Distribuidos
6. Bancos de Dados Distribuidos Sistemas Distribuidos vem cada vez mais ganhando espaço em meio a grandes organizações que precisam escalar seus serviços para atender uma massa de usuarios cada vez maior e que estão espalhados por todas as regiões do planeta. Os Bancos de Dados Distribuidos vem para aumentar a resiliencia e performance destes sistemas, entregando dados de forma intercontinental com baixa latencia, alta disponibilidade e elasticidade.
7. Desafios na distribuição de dados de forma continental
8. Desafios • Latencia • Volume de Dados • Arquitetura Sistemica correta • Particionamento • Segurança • Custo • Time Capacitado • Consistencia
9. (1) Find your path in a Death-star Microservices architecture using BPM | LinkedIn
10. Aurora Global Database
11. Aurora • Compatível com MySQL e PostgreSQL • Mais barato (muito) em comparação à opções Enterprise (MSSQL e Oracle) • Provisionamento facilitado, principalmente via Console • Performático • Altamente Disponível • Escalabilidade Horizontal • Multi-Write Clusters • Alta Capacidade de Armazenamento
12. https://media.amazonwebservices.com/blog/2018/aurora_model_1.png
16. Write Fowarding
18. Aurora Global Database - Limitações • MySQL 5.6 e 5.7 e PostgreSQL 10 a 13 • 128 TB de Storage Maximo • 64 TB por tabela no MySQL ou 32 TB por tabela no PostgreSQL
19. Aurora Global Database • < 1 Segundo de latencia de replicacaovvvvvv • Alto Throughput: Até 200k escritas/seg • Multi-Region Failover • ~1 minuto para chaveamento total do DNS • Disponível em Todas as Regiões • Níveis de consistência: Eventual, Sessão ou Global
20. DynamoDB Global Table
21. DynamoDB • Milhões de requests por Segundo • Latência < 10 milisegundos por execução • Suporte a Streaming de dados com Kinesis Data Streams • Auto Scaling • Livre de manutenção • On-Demand mode • CDC • ACID • Criptografia em repouso, PITR Backups, etc..
22. Single Region • Dado replicado em 3 Azs • Disponibilidade de 99,99% • Acessível Globalmente via API • Altamente Escalável • Alta latência para usuários em outras regiões • Risco de indisponibilidade de uma região • Alguns reguladores exigem multi-region para Disaster Recovery
23. Global Tables • Replicação totalmente automática entre regiões • Conexão entre infras facilitada • Redundância (HA) e Disponibilidade • Disponibilidade de 99.999% • Escritas locais são síncronas e entre regiões assíncronas • Todas as regiões recebem escritas • Custo de Storage e Escrita crescem para cada réplica adicionada
27. Tabelas idênticas para replicação • Write capacity precisa ser idêntica • Read capacity pode variar • Redundância (HA) e Disponibilidade • Regiões com menos tráfico de leitura podem ter policys de AutoScaling diferentes
28. Throughput de Leitura e Escrita no DynamoDB Capacity Unit Sizes (for Provisioned Tables) • One read capacity unit = one strongly consistent read per second, or two eventually consistent reads per second, for items up to 4 KB in size. • One write capacity unit = one write per second, for items up to 1 KB in size. • Transactional read requests require two read capacity units to perform one read per second for items up to 4 KB. • Transactional write requests require two write capacity units to perform one write per second for items up to 1 KB. Request Unit Sizes (for On-Demand Tables) • One read request unit = one strongly consistent read, or two eventually consistent reads, for items up to 4 KB in size. • One write request unit = one write, for items up to 1 KB in size. • Transactional read requests require two read request units to perform one read for items up to 4 KB. • Transactional write requests require two write request units to perform one write for items up to 1 KB.
29. Limitações • Não há suporte a transações (Teorema CAP) • Quotas de Throughput On-Demand Provisioned Per table 40,000 read request units and 40,000 write request units 40,000 read capacity units and 40,000 write capacity units Per account Not applicable 80,000 read capacity units and 80,000 write capacity units Global Tables Per table 40,000 read request units and 40,000 write request units 40,000 read capacity units and 40,000 write capacity units Per table, per day 10 TB for all source tables to which a replica was added 10 TB for all source tables to which a replica was added Service, Account, and Table Quotas in Amazon DynamoDB - Amazon DynamoDB
30. ElastiCache Global Datastore
31. ElastiCache • Escalável • Performance Extrema com submilisegundo de resposta • Totalmente gerenciado • Totalmente compátivel com as engines Redis e Memcached • Simples • Altamente Disponível e fácil de escalar • Geo Espacial, Pub/Sub • Seguro e Confiável • 170 TB de dados em um cluster totalmente in-memory
32. Global Datastore • Arquitetura Ativo-Passivo • Até 3 clusters participantes, em regões diferentes • Baixa-Latencia e DR entre regiões • < 1 Segundo de replicação • ~1 minuto para promover um cluster para primário • Disponível para Redis 5.0.6 • Replicação assíncrona • Configuração identica entre os clusters
33. Escalabilidade Escrita • Suporta ambos os modos cluster Redis – Sharded e non-cluster • 250 Nós por cluster regional • Escalabilidade Horizontal e Vertical • Necessidade de todos os nós do cluster serem idênticos em tipo e número de nós master Leitura • Réplicas de leitura são indepentes para cada região podendo ser adicionadas e removidas
34. Limitações • Global datastores don’t available in all regions. • To use global datastores, use Redis engine version 5.0.6 or higher and R5 or M5 node types or higher. • All clusters—primary and secondary—in your global datastore should have the same number of primary nodes, node type, engine version, and number of shards (in case of cluster-mode enabled). Each cluster in your global datastore can have a different number of read replicas to accommodate the read traffic local to that cluster. • You can set up replication for a primary cluster from one AWS Region to a secondary cluster in up to two other AWS Regions. • You can work with global datastores only in VPC clusters. • ElastiCache doesn't support autofailover from one AWS Region to another. • To bootstrap from existing data, use an existing cluster as primary to create a global datastore. We don't support adding an existing cluster as secondary. The process of adding the cluster as secondary wipes data, which may result in data loss. • Parameter updates are applied to all clusters when you modify a local parameter group of a cluster belonging to a global datastore.
35. Casos de Uso
36. Amazon Aurora Customer Testimonials | MySQL PostgreSQL Relational Database | Amazon Web Services
37. AWS re:Invent 2020: How Disney+ scales globally on Amazon DynamoDB - YouTube
39. Alt title + content 1
40. Referências 1. Amazon Aurora: Deep Dive - SRV308 - Chicago AWS Summit (slideshare.net) 2. AWS Fireside Chat: Optimize Your Business Continuity Strategy with Aurora Global Database - YouTube 3. Quotas and constraints for Amazon Aurora - Amazon Aurora 4. Deep Dive on Multi-Region Architectures with Amazon DynamoDB - AWS Online Tech Talks – YouTube 5. Service, Account, and Table Quotas in Amazon DynamoDB - Amazon DynamoDB 6. ElastiCache - Global Datastore :: Disaster Recovery on AWS (workshop.aws) 7. Prerequisites and limitations - Amazon ElastiCache for Redis
41. Muito Obrigado! william@datatuning.com.br https://datatuning.com.br https://codedataops.com Twitter: @WilloniL LinkedIn: williamlinooliveira