Apresentaremos o projeto ExpressoV3, suas funcionalidades, arquitetura e comunidade, mostraremos o cenário de expansão de usuários e detalharemos as soluções arquiteturais projetadas para escalar a aplicação, que podem servir para outras aplicações PHP.

1. Escalabilidade
via Software no
Expresso

2. Quem sou eu?
● Chefe do setor de adequação do ExpressoV3 em Curitiba

3. Quem sou eu?

4. FISL LATINOWARE
Quem sou eu?
● Fui palestrante e instrutor em vários eventos

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. Quem sou eu?
● Sou autor dos livros:

7. VAMOS COMEÇAR!

8. O que é o Expresso?
● O Expresso (ou mais precisamente, Expresso Livre) é
um groupware, um software para comunicação e
colaboração entre equipes. Sua primeira versão,
derivada do E-Groupware, foi criada pela CELEPAR,
Companhia de Informática do Paraná. A versão mais
recente, a 3, é baseada no Tine 2.0, um projeto mais
evoluído, com arquitetura orientada a serviço e
modular, baseado em Zend Framework.
● A versão mais recente do Tine 2.0 usa as versões 1 e 2
do Zend Framework (95% - 5%)

9. https://comunidadeexpresso.serpro.gov.br/expressov3/

10. https://comunidadeexpresso.serpro.gov.br/expressov3/

11. Por que o Expresso?
● A aquisição de solução semelhante ao Expresso Livre
teria um custo muito mais elevado que o investimento
nas equipes que o desenvolvem.
● Cada licença de cliente Microsoft Exchange, por
exemplo custa cerca de R$ 170,00, e provavelmente
geraria muita demanda interna de customização.
● Isso não é uma hipótese. Temos vários casos de
esforço de adequação de ferramentas de código-fechado.
Às vezes é necessário criar sistemas
complementares para suprir a carência de
funcionalidades.

12. Por que o Expresso?
● O Expresso é um software livre e aberto, não tem
backdoors que permitam espionagem.
● O Expresso é extensível por módulos.
● Existem vários módulos disponíveis.
● O Expresso é orientado a serviços. Qualquer um pode
fazer um cliente em qualquer linguagem que consuma
um servidor Expresso usando JSON-RPC.
● O Expresso é parte de uma vibrante comunidade de
software livre internacional, a do projeto Tine 2.0.

13. Desafio do Expresso
Escalar a aplicação para suportar centenas de
milhares de usuários, podendo em situações
extremas alcançar um milhão de usuários (ou
mais).
Motivo: atender a demanda por uma solução
auditável de comunicação para toda a
administração pública federal

14. Escalabilidade
Escalabilidade não significa melhoria de
desempenho, significa sobrevivência.

15. Desafio Técnico
Fazer com que um sistema gerenciador de
banco de dados livre possa suportar de
centenas de milhares a um milhão de conexões
com banco de dados.
WHERE'S WALLY?

17. 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 just buy bigger hardware”
Cal Henderson

18. Realidade
Nem sempre é possível comprar mais
hardware.
Nem sempre mais hardware implica em
melhoria de desempenho.

19. Caminho
Elaborar estratégias para escalar o banco de
dados (PostgreSQL no caso) para a
expectativa de demanda exposta
anteriormente.

20. Frase marcante
“Se for possível ter um
banco de dados por
usuário, não haverá limites
para a infraestrutura”
?!?!?!?!

21. Traduzindo
“Como seria maravilhoso se
o banco de dados relacional
pudesse ser fragmentado.”
?!?!?!?!

22. Dividir para conquistar

23. Dividir para conquistar

24. Dividir para conquistar

25. Dividir para conquistar
Conseguimos suportar de 60 a 70 mil usuários
por domínio, aproximadamente.
Isso significa que com 10 domínios, podemos
ter 700 mil usuários, cada um com sua
infraestrutura, mas compartilhando a mesma
instância de aplicação.

26. Atualização distribuída
● Algumas operações tem de ser feitas em
todos os domínios.
● A instalação, atualização e remoção de
módulos são algumas delas.
● A criação de filtros compartilhados é outra.

27. Atualização distribuída
● Foco em resultados: a aplicação precisa
funcionar.
● Se um banco de dados pode apresentar
falhas, n bancos de dados também podem.
● Não se pode evitar falhas, podemos tolerá-las.
O que se precisa definir é o nível, a
medida de tolerância.

28. Atualização distribuída
● Se durante uma atualização, a operação em
um banco de dados falhar, a aplicação já tem
condições de informar qual banco falhou e
produzir um script para atualizar o banco.
● A aplicação não vai recuperar o banco de
dados se o servidor estiver indisponível (sem
conexão, máquina física desligada, etc).
● A aplicação pode notificar o sistema de
monitoração sobre a falha na atualização
também, embora já avise o administrador
sobre falhas no processo.

29. Atualização distribuída
● Suponha que haja 10 domínios, e um módulo tenha
de ser atualizado. A aplicação irá fazer um loop,
gravando nos 10 bancos de dados.
● Se a operação falhar em 1 banco de dados, o
problema não é proveniente da aplicação, pois a
operação funcionou em 9 bancos.
● Reverter 90% do processo de atualização é menos
custoso do que executar um script para 1 banco de
dados?
● Dotar a aplicação de controle transacional sobre
vários bancos significa aumentar a complexidade
da aplicação para atender um estado transitório.

30. Atualização distribuída
6 bancos para atualizar
Banco 1 Banco 2 Banco 3 Banco 4 Banco 5 Banco 6
5 são atualizados
Banco 1 Banco 2 Banco 3 Banco 4 Banco 5 Banco 6
Revertemos 5 por causa de 1?
Banco 1 Banco 2 Banco 3 Banco 4 Banco 5 Banco 6

31. Atualização distribuída
● Atualizações de estrutura de tabelas não são
tarefas frequentes.
● Assim com a aplicação pode notificar a
monitoração para alertar sobre falhas na
atualização, agentes podem automatizar a
execução dos scripts, desde que saibamos
para onde os scripts precisam ser enviados
para serem executados.

32. Modus Operandi da atualização distribuída
Instância única do ExpressoV3
Tenta atualizar todos Reporta quais não foram
atualizados e gera script
Banco 1 Banco 2 Banco 3 Banco n

33. Modus Operandi da atualização distribuída
● Importante: a atualização é feita pelo Gerenciador de
Aplicações, que tem uma interface que mostra o que está
atualizado, desatualizado e se houve erros.

34. Status de entrega
● Configuração de multidomínio
pronta.
● Release em homologação.
● Setup com interface gráfica para
atualização distribuída em fase
final de desenvolvimento.

35. Limites
Mas se houver mais de 70 mil usuários em um
domínio?
Para esses casos extremos, precisaremos de
uma solução mais agressiva.

36. 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]

37. O que o mercado faz

38. O que o mercado faz
MySQL tem uma solução para sharding de
banco de dados proprietária e paga, o MySQL
Cluster.

39. 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]

40. 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]

41. Fato
Diante do cenário de restrição para aumento de
infraestrutura e limitações para introdução de
novas soluções de software, o sharding é a
solução mais viável de ser implementada para
casos extremos, o que não implica que seja a
mais fácil de ser administrada.

42. Hoje
Instância da
aplicação
Banco de Dados

43. Com o Sharding
Instância da
aplicação
SShhaarrdd 11 Shard 2 Shard 3 Shard n

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

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

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

47. Realidade
Desenvolvemos uma camada para fazer sharding,
desconectada do banco de dados.
EnterpriseDB

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

49. Os shards no ExpressoV3 serã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.

50. 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!

51. A configuração de múltiplos bancos de dados está
pronta
● Já é possível usar o ExpressoV3 com sharding
para novas instalações.
● Para migrar instalações existentes, é necessário
aguardar a finalização do 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.
● O sharding será um plugin que terá de ser
habilitado.

52. Status de entrega
● Suporte a sharding para novas
instalações pronta.
● Script de resharding em fase final
de desenvolvimento.

53. Sharding é uma solução extrema

54. Outros ajustes para reduzir acesso ao banco
● Uso exclusivo de LDAP para autenticação e
controle de usuários e grupos sem
sincronização com o banco.
● Redução de tabelas ( eliminaçao quando
possviel).
● O uso da sessão será ampliado para evitar o
uso do banco de dados, armazenando ACL e
containers.
● Podemos usar cache compartilhado para os
dados globais dos vários frontends do
serviço.

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

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