Arquitetura de um sistema crítico de alta disponibilidade com soluções open source

7,841 views

Published on

A plataforma Java revolucionou o panorama do desenvolvimento com a sua comunidade ativa, de onde originaram muitos projetos e iniciativas de soluções open source. Diversas soluções nasceram e são utilizadas com frequência, mas podem apresentar problemas comuns se não tomarmos o devido cuidado. Será apresentada uma abordagem de como utilizar software livre, como os populares Spring, Hibernate, Netty e Jetty com clusterização e virtualização, em uma arquitetura focada em um sistema crítico (24x7) de alta disponibilidade que atende milhares de dezenas de solicitações diariamente, no mercado de 300 mil cientes e 430 mil usuários do SPC. Veremos problemas enfrentados e as medidas tomadas em situações diversas, debatendo detalhes técnicos e gargalos comuns que podem aparecer.

Published in: Technology

Arquitetura de um sistema crítico de alta disponibilidade com soluções open source

  1. 1.
  2. 2. QCon São Paulo 2011<br />Arquitetura de um sistema crítico de alta disponibilidade com soluções open source<br />
  3. 3. Palestrante<br />Daniel Destro do Carmo<br />Ciências da Computação (PUC/SP – 97/2000)<br />MBA em TI (IPT/USP)<br />12 anosatuandoem TI (certificado SCJP, SCEA)<br />Desenvolvimento, consultoria e treinamento<br />Artigospublicados: GUJ e Java Magazine<br />Palestras: Conexão Java e Just Java<br />Atualmente no SPC Brasil<br />Arquiteto de soluções / Infraestrutura<br />
  4. 4. SPC Brasil<br />ConfederaçãoNacional dos DirigentesLojistas<br />FormadapelasCâmaras de DirigentesLojistas (CDL)<br />SPC Brasil<br />Sistema de informação das CDLs (+ de 2.200)<br />Todas as capitais e principaiscidades<br />Informação de crédito de PF e PJ<br />Produtospara o mercado de crédito<br />
  5. 5. SPC Brasil<br />Brevehistórico<br />Sistemaantigoescritoem Oracle Web Toolkit(PL/SQL)<br />Muitosproblemas<br />Trabalhoso, ruim de manter e escalar<br />Novo sistemaescritoem Java 6<br />Feito a partir do zero<br />Nova especificação de negócio<br />
  6. 6. SPC Brasil<br />
  7. 7. SPC Brasil<br />Emnúmeros<br />300.000 clientesemtodoBrasil<br />+ de 200.000 logins diários (48.000 operadores)<br />300.000 consultaspordia (pico de + 500 mil)<br />Média de 15 e pico de 30 consultasporsegundo<br />Horárioscríticos das 9h-11h e das 15-17h<br />
  8. 8. SPC Brasil<br />Maisnúmeros<br />Banco de dados com 150 milhões de CPFs<br />e 18 milhões de CNPJs<br />Log de consultaschega a 1 bilhão de registros<br />2 Terabytes de dados emstoragerápido (FC)<br />
  9. 9. SPC Brasil<br />Outrasnecessidades<br />Intensatroca de informações com parceiros<br />Carregamento e tratamento de muitasinformações<br />Processamentooffline (emlote) – consulta, relatório, …<br />Sistemacrítico 24x7 com baixo tempo de resposta<br />
  10. 10. Solução Adotada<br />
  11. 11. SoluçãoAdotada<br />Aplicação<br />Baseadaemsoluçõeslivres (open source)<br />Escolhagerencialpararedução de custos<br />Soluções de mercadoaltamenteutilizadas e confiáveis<br />Banco de dados<br />Oracle 10g RAC (cluster)<br />
  12. 12. SoluçãoAdotada<br />Oracle 10g RAC<br />3 nós no cluster<br />Crescimento de 50 gigaspormês<br />Rodandosobre AIX<br />Monitoração com Grid Control<br />Replicação dos dados com Data Guard (físico)<br />Datacenters separadadosgeograficamente<br />
  13. 13. SoluçãoAdotada<br />Plataforma de desenvolvimento e runtime<br />Tecnologia Java (versão 6) / JEE<br />Frameworks: Spring e Hibernate (ejbless)<br />Lucene, Quartz, JBossNetty,<br /> Apache Commons, XStream,<br /> Display Tag, Sitemesh, JAX-WS, etc<br />Servidores Web: Apache + Jetty<br />Testes: JUnit, JMeter<br />
  14. 14. SoluçãoAdotada<br />Plataforma de desenvolvimento e runtime<br />Cache: EhCache, Memcached<br />Load balancer: HAProxy<br />JMS: Apache ActiveMQ<br />SO: Red Hat Linux (server)<br />Desenvolvimento: Eclipse + Git + Ubuntu Linux<br />
  15. 15. Servidores Web<br />Apache HTTP Server<br />Precisa de motivos? Alguémsugere outro?<br />Jetty<br />Container web Java<br />Simples, leve e eficiente<br />Customizável e extensível<br />Fazuso de IO assíncrono (NIO)<br />Baixoconsumo de memória e CPU<br />Usado no Google App Engine (GAE)<br />
  16. 16. Frameworks<br />Spring + Hibernate<br />Dupla é ótimaalternativaao EJB<br />Simples de usar, poderoso e flexível<br />Ótimosuporte a IoC / DI, transações, etc<br />Gerenciamento do ciclo de vida dos beans<br />Integraçãocom outros frameworks<br />Controle de segurançaextensível com Spring Security<br />Permiteuso de aspectos (AOP)<br />
  17. 17. Cache<br />EhCache<br />Dados poucovoláteis, mas muitoacessados<br />Reduziracessoao BD e melhorar tempo de resposta<br />Memcached<br />Cache distribuido de objetosemmemória<br />Voltadoparaaceleraraplicações web dinâmicas<br />Guarda pares de chave/valor de dados arbitrários<br />Tempo de acesso O(1)<br />Expiração dos dados armazenados<br />
  18. 18. Load Balancer<br />Appliance<br />Hardware, emgeralcaro – cuida da porta de entrada<br />Faz o load balance entre servidoresfísicos<br />HAProxy<br />Software de load balance<br />Leve, rápido e configurável<br />Estatísticas de uso<br />
  19. 19. Comunicação<br />JBossNetty<br />Framework paracomunicação via rede (socket)<br />Modelobaseadoemeventosassíncronos<br />Alta performance e escalabilidade<br />Fácildesenvolvimento (handlers)<br />Controle no número de workers<br />
  20. 20. Mensageria<br />Apache ActiveMQ<br />UsaprotocoloOpenWirepara Java (rápido)<br />Suportepara Spring Framework<br />Persistência com alto desempenhousandojournal<br />Suportaclusterização (modomaster-slave)<br />Oferece interface via API REST<br />
  21. 21. Indexação<br />Apache Lucene<br />Usadoparaindexar e pesquisar dados de consumidores<br /> 150 milhões de CPFs e 18 milhões de CNPJs<br />Quartz<br />Agendamento de processos<br />Integração com Spring<br />Facilidade de uso<br />
  22. 22. Infraestrutura<br />e Arquitetura<br />
  23. 23. Alta disponibilidade<br />Maiorespreocupações<br />Baixo tempo de resposta<br />Minimizarconsumo de recursos<br />Reduzirdowntime (programadoounão)<br />Atualização de versãoem plena operação (semparada)<br />Escalávelparaatendercrescimento da demanda<br />Estruturafoi de 2 para 4 servers (8 para 32 Gb RAM)<br />Terredundância de serviços (contingenciamento)<br />Monitorartodososserviços<br />
  24. 24. Infraestrutura<br />Sistema de consultas<br />Atendediretamenteosclientes (coreda empresa)<br />4 servers Dell (2 x Quad Core 2.33GHz, 32Gb RAM)<br />Outros sistemas<br />3 servers Dell virtualizados (VMWare)<br />Banco de dados Oracle RAC<br />3 servers IBM Power PC Risc (4 x 1.648MHz, 32 Gb RAM)<br />
  25. 25. Sistema de consultas<br />Infraestrutura<br />
  26. 26. Infraestrutura<br />Sistema de consultas – porservidor<br />
  27. 27. Infraestrutura<br />Monitoração dos serviços<br />
  28. 28. Infraestrutura<br />Monitoração do pool de conexões<br />
  29. 29. Arquitetura da Aplicação<br />Spring<br />Spring Security<br />JSP<br />Socket<br />SOAP<br />Domain<br />Controller<br />Remoting Handler<br />Web Service<br />Façade<br />Service<br />DAO<br />Hibernate<br />Jetty<br />
  30. 30. Arquitetura da Aplicação<br />Sistema de consultas<br /> Tempo de respostaempoucomais de 1 segundo<br /> Alta utilização de agentesparalelos (threads)<br />Fontes de dados internas e externas<br />Algunsprocessamentosvãoparafila JMS<br />Consulta<br />Agente 1<br />BD<br />Agente 2<br />Serviço<br />Agente N<br />Serviço<br />
  31. 31. Arquitetura da Aplicação<br />Comm Broker<br />Comunicação com bases exernas<br />Fornecedor 1<br />SPC<br />Comm<br />Broker<br />SPC<br />Comm<br />Broker<br />Client<br />Sistemas<br />Fornecedor 2<br />OUTROS<br />LOGs<br />
  32. 32. Arquitetura da Aplicação<br />Comm Broker<br />Utilização do Netty<br />Netty<br />Handler<br />#1<br />Handler<br />#2<br />Handler<br />#N<br />Comm<br />Broker<br />Service<br />Handler<br />Service 1<br />Socket<br />Service 2<br />Socket<br />Service N<br />Socket<br />
  33. 33. Algumasconsiderações<br />Baremetal x Virtualização<br />Nossocoreficaem servers exclusivos<br />Serviçosofflineestãovirtualizados<br />Tenharedundância de TUDO<br />Sistemas (e pessoas) falham!<br />
  34. 34. Melhorias<br />
  35. 35. Tuning<br />Banco de dados<br />DBA deveefetivamentemonitorar e cuidar do BD<br />Usaríndices e queries otimizadas<br />Ativar cache de sequence<br />Segmentar dados de tabelasgrandes e críticas (partição)<br />Criartabelashistóricaspara dados nãoimportantes<br />Cuidado com locks (podegerarcontenção)<br />
  36. 36. Tuning<br />Memória<br />-Xms1536m -Xmx1536m -Xmn128m -XX:MaxPermSize=256m<br />Memória do SO<br />Memória da JVM<br />Eden<br />Tenured<br />Permanent<br />Other<br />heap<br />restante<br />
  37. 37. Tuning<br />Garbage Collector<br /> -XX:+UseConcMarkSweepGC-XX:+UseParNewGC<br />-XX:+CMSPermGenSweepingEnabled<br />-XX:+CMSClassUnloadingEnabled<br />-Dsun.rmi.dgc.client.gcInterval=3600000<br />-Dsun.rmi.dgc.server.gcInterval=3600000<br />[GC [ParNew: 110843K->4118K(118016K), 0.0102440 secs] 615483K->508855K(1035520K), 0.0105290 secs][GC [ParNew: 109078K->3158K(118016K), 0.0073700 secs] 613815K->508124K(1035520K), 0.0075610 secs][GC [ParNew: 108228K->4378K(118016K), 0.0103470 secs] 613195K->509817K(1035520K), 0.0105690 secs][GC [ParNew: 109338K->3851K(118016K), 0.0078400 secs] 614777K->509450K(1035520K), 0.0080830 secs]<br />
  38. 38. Tuning<br />Testes<br />Realizartestes de carga e de estresse (JMeter)<br />Medirosresultados e achar o ponto ideal<br />
  39. 39. Perguntas e Respostas<br />
  40. 40. Obrigado!<br />java.danieldestro.com.br<br /> danieldestro@gmail.com<br /> about.me/danieldestro<br /> @danieldestro<br />

×