O documento discute a arquitetura de sharding para escalar o sistema Tine 2.0 para um milhão de usuários. Ele propõe dividir os dados entre vários bancos de dados e domínios, mapeando usuários para shards de forma balanceada. Também aborda desafios como queries distribuídas, replicação de dados e resharding.

1. Líder em soluções de TI para governo
Escalabilidade via
Software no
Expresso V3
Palestrante: Flávio Gomes da Silva Lisboa

2. Quem sou eu?

3. Argentina e Uruguai

4. O que é o Tine 2.0?
É uma suíte de comunicação e colaboração e um CRM.
Possui módulos de Recursos Humanos, Inventário, Vendas, Cursos,
Projetos, Rastreabilidade de Tempo de Atendimento e VOIP.

5. Arquitetura do Software

6. Arquitetura do Software

7. Arquitetura do Software

8. Cooperação
Cassiano
Bruno
Funchal
RommelLagesMário
CarlosLavoisier
Antonio

9. Cooperação

10. Cooperação

11. Desafio Sustentar um milhão... de usuários

12. Quantidade de Usuários

13. Desafio Atender mais usuários sem degradar a performance

14. Restrição
Banco de dados relacional não escalável no ambiente considerado

15. Restrição
Não impedir mudanças de backend no futuro

16. Solução Filme de Terror

17. Mudanças de Arquitetura
1) Separar domínios
2) Dividir o banco de dados

18. Multidomínio
● Implementação para distribuir carga de
serviços entre domínios.
● O domínio, neste caso, refere-se à conta
de e-mail do usuário.
● Existe uma única instância de aplicação
para vários clientes, cada um com seus
serviços.

19. Configuration
Arquitetura de Multidomínio
Backend
Frontend
Single
Application
Domain 1
DB LDAP IMAP SMTP
Domain n
DB LDAP IMAP SMTP
Domain 2
DB LDAP IMAP SMTP

20. Mudança na Estrutura de Pastas

21. Impactos do Multidomínio
1)Não é mais realizada nenhuma consulta ao banco de dados para o
carregamento da página de login.
2)Todas as consultas a banco de dados para recuperação de dados de
configuração foram substituídas por consultas ao arquivo config.inc.php
(do domínio em uso). Para a recuperação de dados de configuração eram
feitas duas consultas para cada item de configuração, uma para a tabela
applications e outra para a tabela config.
3)Foi eliminada a dupla tentativa de autenticação via LDAP. Se não
autenticar, lança exceção.

22. Tamanho da Mudança

23. Depois do Multidomínio...
… vem o Sharding!

24. O que é Shard?
● Linhas de uma tabela distribuídas em
dois ou mais BDs;
● Tabelas ficam com menos registros;
● Distribuição da carga entre vários
SGBDs;
● Consultas paralelas;
● Consultas com JOINS entre BDs podem
ser ineficientes;

25. Sharding é Tetris, mas ao contrário

26. I HATE JOINS!

27. Premissas do Projeto:
a) Usar shard é opcional:
Ambientes pequenos não necessitam da complexidade do shard;
A ausência de shard será o caso particular de uso de um único shard.
Dados globais serão replicados para cada shard.
b) Serão utilizados virtual shards
Virtual shards usarão tabelas de mapeamento.
c) Granularidade a nível de usuário/domínio:
A chave do shard deve ser por usuário/domínio;
d) Domínio geograficamente distribuído:
A infraestrutura de um domínio pode estar distribuída em várias regiões
geográficas, interligadas via redes WAN;

28. Premissas do Projeto:
e) Implementar inicialmente shard apenas para BD:
f) Não criar obstáculos para mudanças de backends:
Deve ser abstrato para não gerar obstáculos que impeçam sua extensão
para operar com Sistemas de Arquivos, IMAP, LDAP, etc...
g) Minimizar o uso de JOINS entre shards:
Essa é uma operação que pode ser muito custosa. Deve ser evitada;
h) Não criar um fork da comunidade:
i) Os convidados de eventos de calendário são sempre tratados como
externos.

29. Admin
Addressbook
Setup
Tinebase
ActiveSync
Calendar
Não criar um fork da comunidade:
Expressomail Felamimail
Webconference
Messenger

30. Esquema – Visão Geral

31. Desafios:
● Direcionamento de usuário para seu frontend Web;
● Como implementar?
● Escolha da chave de shard;
● Quais campos usar?
● Estratégia de distribuição;
● Mapeamento de usuário x backends? Função matemática?
● Usar Virtual Shard?
● Gerenciamento de auto incremento;
● Implementar ou Remover?
● Queries distribuídas;
● Estender SQL? Implementações específicas do domínio da aplicação?

32. Estratégia de mapeamento: Como distribuir os
usuários/domínio de forma balanceada entre os shards.
● Virtual Shard
● Usuário/Domínio X Virtual Shard X BD;
● No de Shards >= No Máx de BDs;
● Objetivo é evitar ter que reorganizar um grande volume de informações
ao fazer um resharding.
● Estratégia de Mapeamento de usuário x backends
● Usando Virtual Shard:
● Mapear no LDAP usuário/domínio x Virtual Shard;
● Mapear Virtual Shard x BD;
● Sem usar Virtual Shard:
● Mapear no LDAP usuário/domínio x BD;
● Granularidade de resharding a nível de usuário/domínio;
● Problema de Gargalo de ponto central (LDAP);

33. Estratégia de mapeamento:
● Estratégia de Função matemática
● Usando Virtual Shard:
● Mod(Hash(CHAVE_SHARD)) → Virtual Shard;
● Mapear Virtual Shard x BD;
● Granularidade de resharding a nível de Virtual Shard;
● Mantém duas versões do Mapeamento durante o resharding;
● Sem usar Virtual Shard:
● Mod(Hash(CHAVE_SHARD)) →BD;
● O resharding se torna muito complexo;
● Vantagem de não precisar buscar informações de associação em
LDAP;

34. Queries distribuídas – Banco de Dados:
● Estender SQL
● WHERE determina roteamento de consultas para vários shards;
● JOINS
● Entre shards, executados localmente (baixo desempenho);
● Com tabelas replicadas, executados remotamente (custo de replicação);
● GROUP BY, Funções de Agregação e ORDER BY executados localmente;
● Gerenciamento de memória (Resultados grandes);
● Gerenciamento de timeout: LAN, WAN;
● Transporte de consultas em Web Services para requisições através de Rede
WAN;
● Vantagens:
● Evita/Minimiza alteração da implementação da aplicação Tine20;
● Desvantages:
● Específico para BD. Não suporta backends LDAP, IMAP, Arquivo;
● Implementação complexa;
● Menor desempenho e maior uso de rede por não reduzir, de forma
distribuída, as consultas (não usa Map/Reduce);

35. Queries distribuídas:
● Implementar consultas específicas:
● Criar Web Services para tratar consultas específicas do Tine20;
● Gerenciamento de Timeout: LAN, WAN;
● Agrupamento distribuído e local (Map/Reduce);
● Map/Reduce: Implementar ou usar solução de terceiro?
● Ordenação executada localmente;
● Gerenciamento de memória (Resultados grandes);
● Vantagens:
● Mais fácil de adaptar para outros backends (Arquivo, LDAP, IMAP);
● Mais simples de implementar que um parser SQL;
● Map/Reduce pode melhorar desempenho;
● Map/Reduce pode diminuir tráfego de rede;
● Web Service suporta nativamente consultas geograficamente distribuídas;
● Desvantages:
● Precisa alterar a implementação da aplicação Tine20;
● Para cada nova consulta, requer um novo esforço de implementação;

36. I HATE JOINS!

37. Integridade Referencial:
● Implementar na aplicação:
● Transferir para a aplicação Tine20 a responsabilidade por garantir a
Integridade Referencial entre shards;
● Vantagem:
● A aplicação não cria inconsistências no BD;
● Desvantagens:
● Necessidade de alterar o código fonte do Tine20;
● Processamento extra prejudica desempenho;
● Acessos diretos ao BD não garantem integridade;
● Remover do BD:
● Remover a verificação de Integridade Referencial entre shards;
● Vantagens:
● Maior desempenho;
● Não necessita nenhuma implementação;
● Desvantages:
● A Integridade não é garantida. Um erro pode levar o BD a inconsistência;

38. Resharding usando Virtual Shard :
● Adição de novo backend:
● Mover linhas (amarelas) da tabela para o novo BD e apontar o Virtual Shard
(amarelo) para o novo BD;
● Função Matemática Mod(Hash(Chave_Shard)) decide, de forma automática,
para qual Virtual Shard cada requisição da aplicação deve ser encaminhada;

39. Resharding usando Virtual Shard :
● Adição de novo backend:
● Mover linhas (amarelas) da tabela para o novo BD e apontar o Virtual Shard
(amarelo) para o novo BD;
● Atualizar, no LDAP, associação de Usuário/Domínio X Virtual Shard;

40. Resharding sem Virtual Shard:
● Adição de novo backend:
● Mover linhas (amarelas) para o novo BD e atualiza o LDAP para
apontar os dois usuários/domínio para o novo BD;

41. Replicação de Informações Globais:
● Replicar todas informações globais:
● Frequência de replicação de cada informação;
● Como implementar a replicação de informações globais que estão
atualmente em tabelas que também possuem informações de
shard?

42. Replicação de Informações Globais – Banco de Dados:
● Replicação de todas informações Globais em todos Shards:
● Aumenta necessidade de espaço de armazenamento;
● Minimiza JOINS entre Shards;
● Alto custo de replicação;

43. Replicação de Informações Globais – Banco de Dados:
● Replicação de informações Globais entre WANs (em cinza):
● Maior quantidade de JOINS entre Shards;
● Custo de replicação via WAN;

44. Alta Disponibilidade – Banco de Dados:
● Organizar os BDs em arquitetura de Cluster;
● Links de rede redundantes (LANs e WANs);
● Backup individual de cada shard;

45. Escopo do Projeto – Macro Atividades:
1) Permitir vários bancos de dados
2) Criar camada de abstração para banco de dados
3) Criar backend separado para ACL
4) Criar backend separado para containers
5) Modificar consultas para ambiente distribuído
6) Reduzir acesso ao banco de dados
7) Tratar conteúdo compartilhado
8) Direcionamento de usuário para seu frontend Web
9) Implementar script de resharding
10) Revisar arquitetura e implementação de sharding

46. ESCOPO DO PROJETO
Planejamento de execução e dependências entre tarefas
1
2
3
4
5
6
7
8
9
10
5 6 7 88 9 10 11
1
2
3 4
5
6
7
8
9
10

47. flavio.lisboa@serpro.gov.br
www.serpro.gov.br
http://comunidadeexpresso.serpro.gov.br
flavio.lisboa@serpro.gov.brflavio.lisboa@serpro.gov.br