ExpressoBR para Um Milhão (de Usuários)

474 visualizações

Publicada em

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,

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

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

Nenhuma nota no slide

ExpressoBR para Um Milhão (de Usuários)

  1. 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. 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. 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. 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. 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. 6. Quem sou eu? ● Chefe do setor de adequação do ExpressoV3 em Curitiba
  7. 7. Quem sou eu? CIÊNCIA DA COMPUTAÇÃO
  8. 8. FISL LATINOWARE Quem sou eu? ● Fui palestrante e instrutor em vários eventos
  9. 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. 10. Quem sou eu? ● Sou autor dos livros:
  11. 11. VAMOS COMEÇAR!
  12. 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. 13. Um Expresso ajustável
  14. 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. 15. Mágica? Aladdin is part of oriental culture although Disney has made an animation aboit him
  16. 16. Como injetar funcionalidades nas camadas? A resposta foi criar uma arquitetura de plugins que permitisse a injeção de dependências.
  17. 17. Tinebase_Pluggable Uma classe mãe torna três camadas plugáveis. Pluggable_Abstract Frontend_Abstract Controller_Abstract Backend_Abstract
  18. 18. Injetando dependências Um script, init_plugins.php concentra as injeções de dependências.
  19. 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. 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. 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. 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. 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. 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. 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. 26. Um Expresso escalável ● Configuração de multidomínio ● Configuração de sharding
  27. 27. Escalabilidade Escalabilidade não significa melhoria de desempenho, significa sobrevivência.
  28. 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. 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. 30. Escalabilidade Mudança na Estrutura de Pastas
  31. 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. 32. Escalabilidade Tamanho da Mudança
  33. 33. Muitas mudanças competindo MULTIDOMÍNIO
  34. 34. Configuração de Multidomínio Pronta para produção!
  35. 35. Depois do Multidomínio... … vem o Sharding!
  36. 36. 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
  37. 37. Realidade É necessário trabalhar com os recursos existentes. Não podemos adicionar mais serviços.
  38. 38. Realidade Precisamos de um porta-aviões
  39. 39. Realidade Mas temos de usar uma fragata
  40. 40. Realidade COMO OS AVIÕES VÃO POUSAR NA FRAGATA?
  41. 41. Solução ideal Substituir o banco de dados PostgreSQL por outro banco de dados escalável.
  42. 42. 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.
  43. 43. 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.
  44. 44. Frase marcante “Se for possível ter um banco de dados por usuário, não haverá limites para a infraestrutura” ?!?!?!?!
  45. 45. 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]
  46. 46. O que o mercado faz
  47. 47. O que o mercado faz MySQL tem uma solução para sharding de banco de dados proprietária e paga, o MySQL Cluster.
  48. 48. Problemas Solução proprietária. Obriga a reescrita de consultas.
  49. 49. 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]
  50. 50. 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.
  51. 51. 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]
  52. 52. Realidade Não é possível replicar tabelas de forma assíncrona em nosso ambiente.
  53. 53. 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.
  54. 54. Hoje Instância da aplicação Banco de Dados
  55. 55. Com o Sharding Instância da aplicação SShhaarrdd 11 Shard 2 Shard 3 Shard n
  56. 56. 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.
  57. 57. 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.
  58. 58. 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
  59. 59. Realidade Desenvolvemos uma camada para fazer sharding, desconectada do banco de dados. EnterpriseDB
  60. 60. 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
  61. 61. 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!
  62. 62. 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.
  63. 63. 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
  64. 64. 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
  65. 65. 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
  66. 66. 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
  67. 67. Consequência ● Para cada usuário, duas conexões, não simultâneas: Aplicação Virtual Shard Shard Banco Global
  68. 68. Retorno ao passado O NÚMERO DE CONEXÕES COM BANCO NÃO SERÁ REDUZIDA PARA O BANCO GLOBAL! E AÍ?
  69. 69. 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).
  70. 70. Banco Global Log de acessos Tarefas assíncronas Agendamento de tarefas ACL Containers
  71. 71. 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.
  72. 72. 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
  73. 73. 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
  74. 74. A extensão está funcional, mas precisa ser amplamente testada.
  75. 75. 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.
  76. 76. Compartilhamentos Instância da aplicação Shard 1 Shard 2 Shard 3 Shard n Banco de metadados
  77. 77. 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
  78. 78. 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
  79. 79. 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
  80. 80. 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.
  81. 81. 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.
  82. 82. 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.
  83. 83. 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?
  84. 84. Rumo à nuvem
  85. 85. 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.
  86. 86. 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
  87. 87. 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
  88. 88. 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.
  89. 89. 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
  90. 90. 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.
  91. 91. 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.
  92. 92. 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.
  93. 93. Refatoração de Tinebase_Backend Módulo Tinebase Modulo_Backend_Sql Tinebase_Backend_Sql
  94. 94. Refatoração de Tinebase_Backend Módulo Tinebase Modulo_Backend_Database Tinebase_Backend_Database
  95. 95. Refatoração de Tinebase_Backend Tinebase Tinebase_Backend_Database Tinebase_Backend_Database_Nosql Tinebase_Backend_Database_Sql fabrica usa fabrica usa
  96. 96. 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
  97. 97. 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
  98. 98. 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.
  99. 99. 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
  100. 100. 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

×