Tirando água
da rocha:
escalabilidade via
software no
ExpressoV3
Quem sou eu?
● Chefe do setor de adequação do ExpressoV3 em Curitiba
Quem sou eu?
000`000000
FISL LATINOWARE
Quem sou eu?
● Fui palestrante e instrutor em vários eventos
Quem sou eu?
● Leciono a disciplina Programação PHP Orientada a Objetos com Testes
Unitários no curso de especialização em...
Quem sou eu?
● Sou autor dos livros:
O que é o ExpressoV3?
É uma suíte de comunicação e colaboração
inteiramente desenvolvida em software
livre.
Seu objetivo m...
Argentina e Uruguai
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, Ven...
Arquitetura do Software
Arquitetura do Software
Arquitetura do Software
Escalabilidade
Escalabilidade não significa melhoria de
desempenho, significa sobrevivência.
Cache
● Cache local, por frontend
● Cache configurável (1 hora atualmente)
● O cache compartilhado é rejeitado pela equipe...
Sessão
● Permissões e preferências armazenadas em sessão
● Sessão de longa duração
FRONTEND
SESSÃO
FRONTEND
SESSÃO
FRONTEN...
Fato
“Unless we're doing a lot of file serving, the
database is the toughest part to scale.
If we can, best to avoid the i...
O que o mercado faz
Facebook tem
800 milhões de usuários sendo que 500 milhões
visitam diariamente o site.
350 milhões de ...
O que o mercado faz
O que o mercado faz
MySQL tem uma solução para sharding de
banco de dados proprietária e paga, o MySQL
Cluster.
O que o mercado faz
Foursquare tem
45 milhões de usuários (19/12/2013)
5 bilhões de check-ins (19/12/2013)
Banco de dados ...
O que o mercado faz
Instagram tem
●14 milhões de usuários
●Amazon Elastic Load Balander com 3 instâncias de
NGINX
●Amazon ...
Expresso antes
Instância da
aplicação
Banco de Dados
Multidomínio
● Implementação para distribuir carga de
serviços entre domínios.
● O domínio, neste caso, refere-se à conta
...
Configuration
Arquitetura de Multidomínio
Backend
Frontend
Single
Application
Domain 1
DB LDAP IMAP SMTP
Domain n
DB LDAP ...
Mudança na Estrutura de Pastas
Impactos do Multidomínio
1)Não é mais realizada nenhuma consulta ao banco de dados para o
carregamento da página de login....
Tamanho da Mudança
Database Sharding
Instância da
aplicação
Shard 1Shard 1 Shard 2 Shard 3 Shard n
Como fazer sharding para o ExpressoV3
Sem dispor de uma solução que faça o
sharding de forma transparente para a
aplicação...
Como fazer sharding para o ExpressoV3
Por que não usamos EnterpriseDB? Bem, ele é
proprietário. A solução alternativa aber...
Mundo ideal
Delegaríamos o sharding para o EnterpriseDB e não
precisaríamos desenvolver uma camada para
administrar a segm...
EnterpriseDB
Realidade
Desenvolvemos uma camada para fazer sharding,
desconectada do banco de dados.
Arquitetura da solução de sharding para o
ExpressoV3
Aplicação
Virtual Shard Virtual Shard Virtual Shard Virtual Shard Vir...
Os shards no ExpressoV3 são virtuais
● Do ponto de vista da aplicação, os usuários estarão
segmentados em N shards, defini...
Não há mágica!
Virtual Shard Virtual Shard Virtual Shard Virtual Shard Virtual Shard Virtual Shard
Banco de
Dados
Banco de...
A configuração de múltiplos bancos de dados está
pronta
● Nas próximas releases já estará disponível a
implementação de sh...
Fato
● Se cada usuário tivesse de ter acesso somente a seus
dados, então cada shard teria as mesmas tabelas, mas
apenas co...
Fato
● Mas existem tabelas globais, que precisam ser replicadas
em cada shard. E essa replicação deve ser síncrona.
Shard ...
Rumo à nuvem: o futuro
ExpressoV3
Banco relacional com
única instância
ExpressoV3
Várias instâncias de
banco relacional,
d...
Rumo à nuvem
Referências:
[1] http://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate-worse-than-death/
[2] https://www.facebook.co...
flavio.lisboa@serpro.gov.br
www.serpro.gov.br
http://comunidadeexpresso.serpro.gov.br/
Tirando água da rocha: escalabilidade via software no ExpressoV3
Tirando água da rocha: escalabilidade via software no ExpressoV3
Tirando água da rocha: escalabilidade via software no ExpressoV3
Tirando água da rocha: escalabilidade via software no ExpressoV3
Tirando água da rocha: escalabilidade via software no ExpressoV3
Tirando água da rocha: escalabilidade via software no ExpressoV3
Próximos SlideShares
Carregando em…5
×

Tirando água da rocha: escalabilidade via software no ExpressoV3

280 visualizações

Publicada em

Esta palestra visa compartilhar a experiência do projeto ExpressoV3 em implementar soluções para escalar um software para um número de usuário dez vezes maior do que o suportado pela aplicação original. Abordaremos uso de cache, uso de sessão, mudança de armazenamento de dados de banco para arquivo, configuração de múltiplos domínios e sharding de banco de dados.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
280
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Tirando água da rocha: escalabilidade via software no ExpressoV3

  1. 1. Tirando água da rocha: escalabilidade via software no ExpressoV3
  2. 2. Quem sou eu? ● Chefe do setor de adequação do ExpressoV3 em Curitiba
  3. 3. Quem sou eu? 000`000000
  4. 4. FISL LATINOWARE Quem sou eu? ● Fui palestrante e instrutor em vários eventos
  5. 5. Quem sou eu? ● Leciono a disciplina Programação PHP Orientada a Objetos com Testes Unitários no curso de especialização em Desenvolvimento de Aplicações Web na UniCesumar.
  6. 6. Quem sou eu? ● Sou autor dos livros:
  7. 7. O que é o ExpressoV3? É uma suíte de comunicação e colaboração inteiramente desenvolvida em software livre. Seu objetivo maior é fornecer uma ferramenta economicamente viável, com grande domínio e autossuficiência do conhecimento e difusão para corporações, dentro e fora do Brasil. Possui módulos de Catálogo de Endereços, Calendário, E-mail, Tarefas, Webconference, Messenger e ActiveSync.
  8. 8. Argentina e Uruguai
  9. 9. 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.
  10. 10. Arquitetura do Software
  11. 11. Arquitetura do Software
  12. 12. Arquitetura do Software
  13. 13. Escalabilidade Escalabilidade não significa melhoria de desempenho, significa sobrevivência.
  14. 14. Cache ● Cache local, por frontend ● Cache configurável (1 hora atualmente) ● O cache compartilhado é rejeitado pela equipe de infraestrutura por alegação de redução de desempenho pela adição de tráfego de rede FRONTEND CACHE FRONTEND CACHE FRONTEND CACHE
  15. 15. Sessão ● Permissões e preferências armazenadas em sessão ● Sessão de longa duração FRONTEND SESSÃO FRONTEND SESSÃO FRONTEND SESSÃO
  16. 16. Fato “Unless we're doing a lot of file serving, the database is the toughest part to scale. If we can, best to avoid the issue altogether and jut buy bigger hardware” Cal Henderson
  17. 17. O que o mercado faz Facebook tem 800 milhões de usuários sendo que 500 milhões visitam diariamente o site. 350 milhões de usuários mobile atualizando constantemente seus status. 7 milhões de aplicações e Web sites integrados com a plataforma Facebook. >60 milhões de queries por segundo Banco de dados MySQL dividido em 4000 shards 9000 instâncias de Memcached 1800 servidores para MySQL (2008) 805 servidores dedicados para Memcached * Dados de 2011 [1],[2],[3]
  18. 18. O que o mercado faz
  19. 19. O que o mercado faz MySQL tem uma solução para sharding de banco de dados proprietária e paga, o MySQL Cluster.
  20. 20. O que o mercado faz Foursquare tem 45 milhões de usuários (19/12/2013) 5 bilhões de check-ins (19/12/2013) Banco de dados MongoDB com auto-sharding. Hive e Hadoop. Houve um caso de indisponibilidade de 7 horas em 2010. * [4],[5],[6],[7]
  21. 21. O que o mercado faz Instagram tem ●14 milhões de usuários ●Amazon Elastic Load Balander com 3 instâncias de NGINX ●Amazon Route53 para DNS ●Django sobre Apache com mod_wsgi ●PostgreSQL com sharding em cluster com 12 instâncias de memória extra-grandes quádruplas e 12 réplicas em uma zona diferente. Usa Streaming Replication e Pgbouncer. ●Várias instâncias de Redis usadas extensivamente. ●Gearman para processamento paralelo com 200 threads. * [8],[9]
  22. 22. Expresso antes Instância da aplicação Banco de Dados
  23. 23. 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.
  24. 24. 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
  25. 25. Mudança na Estrutura de Pastas
  26. 26. 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.
  27. 27. Tamanho da Mudança
  28. 28. Database Sharding Instância da aplicação Shard 1Shard 1 Shard 2 Shard 3 Shard n
  29. 29. Como fazer sharding para o ExpressoV3 Sem dispor de uma solução que faça o sharding de forma transparente para a aplicação, como o EnterpriseDB [12], temos de fazer sharding com a aplicação ciente disso. A aplicação está assumindo uma tarefa que o banco de dados não consegue realizar.
  30. 30. Como fazer sharding para o ExpressoV3 Por que não usamos EnterpriseDB? Bem, ele é proprietário. A solução alternativa aberta é o Postgres-XC-Cluster [11, p. 27], mas ele não faz compartilhamento entre shards. Além de não ter domínio do código, ainda teríamos de desenvolver a parte de compartilhamento na aplicação.
  31. 31. Mundo ideal Delegaríamos o sharding para o EnterpriseDB e não precisaríamos desenvolver uma camada para administrar a segmentação de usuários. EnterpriseDB
  32. 32. EnterpriseDB Realidade Desenvolvemos uma camada para fazer sharding, desconectada do banco de dados.
  33. 33. Arquitetura da solução de sharding para o ExpressoV3 Aplicação Virtual Shard Virtual Shard Virtual Shard Virtual Shard Virtual Shard Virtual Shard Banco de Dados Banco de Dados Banco de Dados Banco de Dados Estratégia de Sharding
  34. 34. Os shards no ExpressoV3 são virtuais ● Do ponto de vista da aplicação, os usuários estarão segmentados em N shards, definidos em um arquivo de configuração de shards (shard.inc.php). ● Mas fisicamente, dois ou mais shards podem apontar para o mesmo banco de dados. ● A aplicação não precisa ser modificada para que um banco seja incluído ou removido. ● O método de resharding move os dados de um usuário ou de todos usuários de associados a um virtual shard para outro banco de dados.
  35. 35. Não há mágica! Virtual Shard Virtual Shard Virtual Shard Virtual Shard Virtual Shard Virtual Shard Banco de Dados Banco de Dados Banco de Dados Banco de Dados ● É preciso monitorar os shards!
  36. 36. A configuração de múltiplos bancos de dados está pronta ● Nas próximas releases já estará disponível a implementação de sharding. ● Para migrar instalações existentes, é necessário executar o script de resharding. ● Os dados compartilhados não estão disponíveis. Cada usuário compartilha somente dentro do seu shard. Usuários de shards diferentes são como usuários de instâncias diferentes de ExpressoV3. ● O uso de sharding é dependente da replicação dos dados globais entre os shards.
  37. 37. Fato ● Se cada usuário tivesse de ter acesso somente a seus dados, então cada shard teria as mesmas tabelas, mas apenas com os registros dos usuários daquele shard. Shard 1 Tabela 1 Tabela 2 Tabela 3 Tabela 4 Shard 2 Tabela 1 Tabela 2 Tabela 3 Tabela 4
  38. 38. Fato ● Mas existem tabelas globais, que precisam ser replicadas em cada shard. E essa replicação deve ser síncrona. Shard 1 Tabela 1 Tabela 2 Tabela 3 Tabela Global Shard 2 Tabela 1 Tabela 2 Tabela 3 Tabela Global
  39. 39. Rumo à nuvem: o futuro ExpressoV3 Banco relacional com única instância ExpressoV3 Várias instâncias de banco relacional, distribuídas com distribuição gerenciada pela aplicação. ExpressoV3 Banco de dados não relacional, distribuído e auto-gerenciado.
  40. 40. Rumo à nuvem
  41. 41. Referências: [1] http://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate-worse-than-death/ [2] https://www.facebook.com/MySQLatFacebook [3] http://yoshinorimatsunobu.blogspot.com.br/2014/04/semi-synchronous-replication-at- facebook.html [4] http://pt.scribd.com/doc/51466747/Foursquare-ML-Presentation [5] http://www.mongodb.com/customers/foursquare [6] http://expandedramblings.com/index.php/by-the-numbers-interesting-foursquare-user- [7] stats/#.U9kwAZZVOCg [8] http://www.infoq.com/news/2010/10/4square_mongodb_outage [9] http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram- hundreds-of-instances-dozens-of [10] http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram [11] http://pt.slideshare.net/denishpatel/scaling-postgres [12] https://wiki.postgresql.org/wiki/Postgres-XC
  42. 42. flavio.lisboa@serpro.gov.br www.serpro.gov.br http://comunidadeexpresso.serpro.gov.br/

×