As mais recentes alterações do projeto Expresso, feitas para torná-lo um software de comunicação ajustável para qualquer empresa ou país e para escalar a aplicação para milhares de usuários,

1. ExpressoBR
para Um Milhão
(de Usuários)
Flávio Gomes da Silva Lisboa
Líder em soluções de TI para governo

2. O que é o ExpressoBR?
O ExpressoBR é um software de colaboração de
grupos, que inclui catálogo de endereços, agenda de
compromissos, e-mail, controle de tarefas,
webconferência e mensageria instantânea.
Em 2002 o Serpro administrava aproximadamente
10.000 caixas de correio eletrônico.
Em 2014, com o Expresso, já são 53.000 caixas
postais em 31 órgãos, incluindo o Serpro. Estão
previstos mais 6 órgãos (clientes) em fase de
contratação, com aproximadamente 11.250 caixas.

3. O que é o ExpressoBR?
O ExpressoBR é um software livre, implementado
com PHP e Javascript, linguagens livres, baseado em
um projeto aberto, o Tine 2.0, utilizado em vários
países de quatro continentes, sendo que o núcleo do
desenvolvimento encontra-se na Alemanha.

4. O que é o ExpressoBR?
O ExpressoBR é um software produzido pelo
SERPRO em colaboração com uma vibrante
comunidade formada por várias empresas, em pelo
menos 4 países.
SERPRO é o Serviço Federal de Processamento de
Dados, que mantém desde os dados de registro de
veículos de condutores no Brasil até as transações
financeiras entre todos os órgãos de governo,
passando pela arrecadação de tributos e controle do
comércio exterior e comunicação eletrônica de todo o
governo federal.

5. Para saber mais sobre o ExpressoBR
Dia 15/10/2014
Espaço Equador
17h - ExpressoBr - Parabéns comunidade! 10 anos
de evolução - Walter "Zapa" Zapalowski
18h - Migrando Dados para o Expresso V3 -
Gildomiro Bairros e Fabio Link
19h - Correio de bolso: mobilidade no ExpressoBR
- Rodrigo Dias

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

7. Quem sou eu?
CIÊNCIA DA COMPUTAÇÃO

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

9. Quem sou eu?
● Lecionei 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.

10. Quem sou eu?
● Sou autor dos livros:

11. VAMOS COMEÇAR!

12. Expresso para um milhão de usuários...
Abordaremos duas perspectivas com relação a essa
frase:
1ª Perspectiva: um Expresso que se ajuste às
necessidades de um milhão de usuários.
Muitos interesses.
2ª Perspectiva: um Expresso que seja escalável
para um milhão de usuários.
Muitas pessoas.

13. Um Expresso ajustável

14. Problema arquitetural
Eu dependo de uma funcionalidade, mas não posso
acoplá-la ao meu software, pois nem todos irão fazer
uso dela, pois não é genérica.
Eu preciso fazer uma chamada a um método que não
pode estar estaticamente definido.
Ou seja, eu preciso fazer uma chamada a algo que deve
estar disponível somente quando eu precisar.

15. Mágica?
Aladdin is part of oriental culture although Disney has made an animation aboit him

16. Como injetar funcionalidades nas camadas?
A resposta foi criar uma arquitetura de plugins que
permitisse a injeção de dependências.

17. Tinebase_Pluggable
Uma classe mãe torna três camadas plugáveis.
Pluggable_Abstract
Frontend_Abstract Controller_Abstract Backend_Abstract

18. Injetando dependências
Um script, init_plugins.php concentra as injeções de
dependências.

19. Criando um plugin de camada
Para criar um plugin de camada você deve:
Criar uma classe em uma biblioteca que siga o padrão
Zend Framework 1, dentro da pasta library.
Registrar o plugin na camada que deve receber a
funcionalidade, acrescentando uma linha como uma das
seguintes:
Tinebase_Frontend_Abstract::attachPlugin('nomeDoMétodo', 'NomeDaClasse');
Tinebase_Controller_Abstract::attachPlugin('nomeDoMétodo', 'NomeDaClasse');
Tinebase_Backend_Abstract::attachPlugin('nomeDoMétodo', 'NomeDaClasse');

20. Plugin de camada
Um plugin de camada é uma classe cujo método é
invocado de forma indireta por um objeto das camadas de
frontend, controller e backend.
Você pode criar e adicionar quantos plugins forem
necessários usando o método addPlugin() da classe
abstrata da camada.
Todas as suas herdeiras terão acesso aos métodos de
plugins.

21. Dependências ficam na pasta library
Plugins são classes que fazem
parte de bibliotecas, que são
dependências da aplicação.
Se você quer adicionar uma
funcionalidade específica a uma
camada, crie sua própria biblioteca
e dentro dela crie seus plugins.

22. E não é só isso!
É possível injetar outras dependências em,
init_plugins.php além das que afetam as camadas.
É possível, por exemplo, alterar a regra de validação de
endereçamento IP e a estratégia de armazenamento do
AccessLog.
Isso é tornar o ExpressoV3 configurável.

23. Plugins para o sistema de usuários e grupos
Tinebase_User::addPlugin('Tinebase_User_Plugin_Samba');
Tinebase_Group::addPlugin('Tinebase_Group_Plugin_Samba');

24. Mais plugins estão a caminho!
Nos próximos releases do ExpressoV3, serão
disponibilizados plugins para:
●Inicialização da aplicação
●Filtros de consultas

25. Escreva o seu!
Se precisar de alguma customização, não espere que
sua necessidade se torne genérica.
ESCREVA O SEU PLUGIN E USE!

26. Um Expresso escalável
● Configuração de multidomínio
● Configuração de sharding

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

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

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

30. Escalabilidade
Mudança na Estrutura de Pastas

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

32. Escalabilidade
Tamanho da Mudança

33. Muitas mudanças competindo
MULTIDOMÍNIO

34. Configuração de Multidomínio
Pronta para produção!

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

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

38. Realidade
É necessário trabalhar com os recursos
existentes.
Não podemos adicionar mais serviços.

39. Realidade
Precisamos de um porta-aviões

40. Realidade
Mas temos de usar uma fragata

41. Realidade
COMO OS
AVIÕES VÃO
POUSAR NA
FRAGATA?

42. Solução ideal
Substituir o banco de dados PostgreSQL por
outro banco de dados escalável.

43. Restrições
Dificuldade de introduzir novas tecnologias, por
causa de:
● Necessidade de testes;
● Capacitação;
● Recursos para administrar novos serviços;
● Falta de automação da infraestrutura;
● Risco de indisponibilidade na substituição de
um produto por outro para realizar o mesmo
serviço.

44. Caminho
Dar sobrevida ao PostgreSQL, escalando a
aplicação com os recursos disponíveis e
permitindo a construção lenta, gradual e segura
para a solução definitiva.

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

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

47. O que o mercado faz

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

49. Problemas
Solução proprietária.
Obriga a reescrita de consultas.

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

51. Problemas
Para adaptar-se a bancos não relacionais é
necessário escrever adaptadores específicos e
ajustar as consultas para um nível mais alto
que SQL.

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

53. Realidade
Não é possível replicar tabelas de forma
assíncrona em nosso ambiente.

54. 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, o
que não implica que seja a mais fácil de ser
administrada.

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

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

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

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

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

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

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

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

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

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

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

66. Restrição
● Não é possível replicar tabelas globais com PostgreSQL em
nosso ambiente.
Shard 1
Tabela 1 Tabela 2
Tabela 3 Tabela
Global
Shard 2
Tabela 1 Tabela 2
Tabela 3 Tabela
Global
X

67. Caminho
● Desacoplar os dados globais dos shards.
Shard 1
Tabela 1 Tabela 2
Tabela 3
Shard 2
Tabela 1 Tabela 2
Tabela 3
Banco Global
Tabela
Global

68. Consequência
● Para cada usuário, duas conexões, não simultâneas:
Aplicação
Virtual Shard
Shard Banco
Global

69. Retorno ao passado
O NÚMERO DE
CONEXÕES
COM BANCO
NÃO SERÁ
REDUZIDA PARA
O BANCO
GLOBAL! E AÍ?

70. Ajustes para reduzir o uso do banco de dados
● A autenticação e controle de usuários e grupos usará
exclusivamente LDAP sem sincronização com o banco.
● O banco global terá menos tabelas.
● As tabelas do banco global não farão junções com outras.
● O uso da sessão será ampliado para evitar o uso do banco
de dados, armazenando ACL e containers.
● Podemos usar cache para os dados globais.
● Essa é a forma de replicar dados sem replicá-los (Como
fazer o avião pousar na fragata? Simples, ele não pousa).

71. Banco Global
Log de acessos Tarefas
assíncronas
Agendamento
de tarefas
ACL Containers

72. Fatos
● É necessário um banco global, já que não pode ser feita
replicação. Se ele será repartido em dois, é uma questão
que pode ser tratada mais adiante.
● Com a sobrevida dada pelo sharding, vale mais a pena
investir na adaptação da aplicação a um banco NoSQL com
auto-sharding e auto-replicação do que tentar delegar a
replicação para a aplicação.
● A mutabilidade do banco global em relação aos shards é
baixa.
● Com uso de sessão e cache, o acesso ao banco do global
será reduzido.

73. Mundo ideal
● Se o banco de dados fizesse o sharding, ele também
trataria as consultas de forma distribuída. Assim, não seria
necessário alterar as consultas na aplicação, pois o
gerenciador de sharding iria executar os consultas em todos
os shards e retornar os resultados combinados.
Instância da
aplicação
Sharding
Manager
Shard 1 Shard 2 Shard 3 Shard n

74. Realidade
● A aplicação tem que gerenciar as consultas distribuídas.
Para diminuir o impacto da mudança na aplicação, foi
desenvolvida uma extensão para fazer consultas
distribuídas, cuja interface é compatível com a atual
extensão usada para PostgreSQL.
Instância da aplicação
Extensão para
consultas
distribuídas
Shard 1 Shard 2 Shard 3 Shard n

75. A extensão está funcional, mas precisa ser
amplamente testada.

76. Compartilhamentos
● O sharding implementado pela aplicação, com banco global
e consultas distribuídas, não garante compartilhamento de
dados ENTRE SHARDS.
● Só é possível, a princípio compartilhar com usuários do
mesmo sharding.
● Os compartilhamentos deverão ser tratados como serviços,
e a visualização deles deve ocorrer somente por demanda.
● Para controlar os mapeamentos de compartilhamentos, será
necessário criar um banco de dados de metadados, que
pode inicialmente ser um banco PostgreSQL, mas sem
utilizar as características intrínsecas a bancos relacionais.

77. Compartilhamentos
Instância da aplicação
Shard 1 Shard 2 Shard 3 Shard n
Banco de
metadados

78. Compartilhamentos
● O banco de metadados armazena as conexões entre os
shards.
● Quando um usuário de um shard1 compartilhar o seu
calendário com o o usuário do shard2, será criado um
registro no banco de metadados, para associar a conexão
de banco do usuário do shard1 com o usuário do shard2.
Banco de metadados
Usuário1 → Login do Usuário 2
Usuário3 → Login do usuário 5

79. Compartilhamentos
● O usuário que recebeu o compartilhamento, só precisa
saber do login do usuário que forneceu o compartilhamento.
A partir do login, a implementação de shard sabe em qual
banco de dados o usuário se encontra.
Banco de metadados
Usuário1 → Login do Usuário 2
Usuário3 → Login do usuário 5

80. Compartilhamentos
● Em um resharding (redistribuição dos usuários entre os
bancos), os registros do banco de metadados não terão de
ser alterados, pois quem recebeu o compartilhamento
precisa apenas do login de quem compartilhou.
Banco de metadados
Usuário1 → Login do Usuário 2
Usuário3 → Login do usuário 5

81. Atualização distribuída
● Embora alguns dados sejam globais, algumas operações
tem de ser feitas em todos os shards.
● A instalação, atualização e remoção de módulos é uma
delas.
● A criação de filtros compartilhados é outra.

82. Fatos
● A aplicação ExpressoV3 não é um sistema gerenciador de
banco de dados. Ela USA um SGBD.
● Dotar o ExpressoV3 das funcionalidades um sistema
gerenciador de banco de dados implica em aumentar a sua
complexidade e manutenção.
● O sharding via aplicação é um passo intermediário para a
adoção de um banco de dados que faça auto-sharding e
não a solução definitiva.

83. Rumo à nuvem
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.

84. Rumo à nuvem
ExpressoV3
Banco relacional com
única instância
ExpressoV3
Banco de dados não
relacional, distribuído e
auto-gerenciado.
PASSAR DIRETO DE UM
CENÁRIO PARA OUTRO
COM AS
RESTRIÇÕES
EXISTENTES?

85. Rumo à nuvem

86. Fatos
● Repetindo: O sharding via aplicação é um passo
intermediário para a adoção de um banco de dados que
faça auto-sharding e não a solução definitiva.
● 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.

87. Fatos
6 shards para atualizar
Shard 1 Shard 2 Shard 3 Shard 4 Shard 5 Shard 6
5 são atualizados
Shard 1 Shard 2 Shard 3 Shard 4 Shard 5 Shard 6
Revertemos 5 por causa de 1?
Shard 1 Shard 2 Shard 3 Shard 4 Shard 5 Shard 6

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

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

90. Monitoração
● O monitor (Zabbix) pode verificar se existem scripts de
atualização, notificando falhas de atualização, embora ela já
esteja sendo acompanhada por um administrador.
Zabbix
ExpressoV3
Cria
Scripts de atualização
Monitora

91. Fatos
● O sharding via aplicação encarrega a aplicação de se
preocupar de onde vem e para onde vão os dados.
● Se a aplicação tiver que exercer controle transacional entre
bancos de dados, ou fazer controle de versão de DDL entre
bancos, irá estar assumindo uma tarefa que não é dela.
● Estamos preparando o caminho para um banco de dados
que faça o que o PostgreSQL não faz hoje.
● Se tiver de ser criado um pseudo banco de dados, ele irá se
tornar um filho indesejado, mas que terá de ser criado e
mantido.
● Nesse caso, a solução adequada à nuvem nunca será
alcançada, a menos que se jogue tudo fora.

92. Fatos
● Não podemos jogar tudo
fora.
● Diante das restrições
apresentadas, as
mudanças tem de ser
graduais.
● A solução transitória é
para sobrevivência.

93. Abstração da camada de banco de dados
● A refatoração da abstração da camada de banco de dados
foi finalizada e entrou em processo de revisão.
● Essa revisão deverá passar por TODOS os
desenvolvedores, pois o impacto é bem grande.
● É necessário escrever adaptadores para NoSQL.
● É necessário ter ambiente para testar NoSQL.
● É necessário monitoração dos testes desde o início para
adequação aos requisitos de infraestrutura.
● É necessário testar vários bancos.

94. Refatoração de Tinebase_Backend
Módulo Tinebase
Modulo_Backend_Sql Tinebase_Backend_Sql

95. Refatoração de Tinebase_Backend
Módulo Tinebase
Modulo_Backend_Database Tinebase_Backend_Database

96. Refatoração de Tinebase_Backend
Tinebase
Tinebase_Backend_Database
Tinebase_Backend_Database_Nosql
Tinebase_Backend_Database_Sql
fabrica
usa
fabrica
usa

97. Refatoração de Tinebase_Backend
Antes
Módulo Backend SQL
Banco de
dados
SQL
Depois
Módulo
Backend
SQL
Banco de
dados
SQL
Backend Proxy
Backend
NoSQL
Banco de
dados
NoSQL

98. Adaptação para manutenção de comportamento
Antes
Módulo Backend SQL
Banco de
dados
SQL
Herança
Depois
Módulo
Backend
SQL
Banco de
dados
SQL
Backend Proxy
Herança
Backend
NoSQL
Banco de
dados
NoSQL

99. Resultados até agora
● Configuração de multidomínio disponível.
● Diminuição de uso do banco de dados relacional.
● Configuração para múltiplos bancos disponível. Um
novo ambiente com replicação síncrona de tabelas já
poderia utilizar o Expresso com sharding.
● Conhecimento mais profundo sobre a estrutura do
banco de dados e das tabelas. Sabemos o que é global e
o que é particular, o que é mais usado, o que é menos
usado, o que tem relacionamento e o que não tem.

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

101. Serviço Federal de Processamento de Dados - Serpro
Edifício Sede: SGAN 601 - Módulo V - CEP 70836-900
Fone: (61) 2021-8000 - Brasília DF
www.serpro.gov.br