TDC2013 Escalando Aplicações Java com In Memory Datagrids
5 gostaram1,142 visualizações
O documento discute o uso de In Memory Data Grids (IMDGs) para escalar aplicações Java. Aborda conceitos como performance vs escalabilidade, arquiteturas de banco de dados, o teorema CAP e padrões ACID e BASE. Também apresenta o caso Ticket Monster, discutindo como utilizar IMDGs para atender novos requisitos de desempenho e escalabilidade do sistema.
TDC2013 Escalando Aplicações Java com In Memory Datagrids
- 1. 1© OCTO 2012 Escalando Aplicações Java com In Memory Data Grids Wagner Roberto dos Santos
- 2. 2 Apresentação Agile Coach / Arquiteto (Metodologia, Arquitetura, Java) Wagner Santos
- 5. 5 Requisito de Performance é um indicador de que a resposta do sistema em frente a ações específicas em um dado intervalo de tempo. Refere-se a experiência do usuário. Performance Fonte Imagem: Toronto Sun http://bit.ly/131JPjy
- 6. 6 O Requisito de escalabilidade é a habilidade de suportar o requisito de qualidade de serviço, conforme a carga do sistema aumenta, sem alterar o sistema. Um sistema pode ser considerado escalável se, conforme a carga aumenta, o sistema continue respondendo em um limite aceitável. Escalabilidade
- 7. 7 Separar a Arquitetura em diferente Tiers facilita a compreensão dos limites da aplicação. Performance
- 8. 8 Escalabilidade Vertical (Scaling Up) Horizontal (Scaling Out)
- 9. 9
- 10. 10 Master Slave Replication Escalando o Banco de Dados
- 11. 11 Active / Passive Escalando o Banco de Dados
- 12. 12 Database Clustering Shared Everything Architecture Escalando o Banco de Dados
- 13. 13 Database Sharding Shared Nothing Escalando o Banco de Dados
- 14. 14 Shared Everything vs Shared Nothing Escalando o Banco de Dados
- 15. 15 BASE e o Teorema CAP
- 16. 16 Banco de Dados Tradicional - ACID Atomicity Consistency Isolation Durability Transação Distribuída
- 17. 17 Apresentado pelo Dr. Eric A. Brewer (2000), no contexto de web services Provado por Seth Gilbert e Nancy Lynch na MIT em 2002 Teorema descreve que estratégias diferentes para distribuir a lógica da aplicação pela rede, apresenta um trade-off entre consistency (consistência), availability (disponibilidade), e partition tolerance (tolerância a partição). Só posso garantir 2 destes 3 estados. Teorema CAP
- 18. 18 Se ACID é desejado em sistemas de banco de dados tradicionais (RDBMS) e provê a escolha de consistência para banco de dados particionados. BASE é o oposto de ACID, porquê promove disponibilidade sobre consistência. BASE quer dizer Basic Available, Soft State, Eventual Consistency;e parte do princípio que consistência não pode ser atendida. Basically Available O sistema irá responder, mesmo com dados desatualizados. Soft State Estado não pode ser consistente e deve ser corrigido. Eventually Consistent Consistência Eventual permite um delay antes de qualquer dado pessoal propague as mudanças ao sistema. BASE
- 19. 19 ACID vs BASE
- 21. 21 É um sistema de venda de tickets online, parte do JBoss Developer Framework (JDF) JDF é um hub que concentra toda a documentação, ferramentas e exemplos para desenvolvedores e a quem possa interessar, criar aplicações utilizando tecnologias relacionados a JBoss e JBoss AS. Ticket Monster
- 23. 23 Novos Requisitos relacionados a Performance High concurrency Dependendo do show, os tickets podem ser vendidos em 5 minutes; High volume Podemos ter milhares de shows com milhares de tickets para vender; Location awareness shows podem acontecer em qualquer lugar do mundo, e gostaríamos que os dados estivessem disponíveis na mesma região que o show vai rola. Ticket Monster
- 24. 24
- 25. 25 Client Session State Server Session State Database Session State Patterns to Store Session State
- 26. 26 Mas qual pattern desses utilizar?
- 27. 27 No Client Session State
- 28. 28 Web Sessions Sticky Session (ou affinity) Conexão fica dedicada a um servidor. Outros servidores não tem nenhum conhecimento do estado da sessão no servidor com a conexão. Replicated Session Estado da Sessõa Dados são replicados para todos os outras sessions Server Session State
- 29. 29 Web Sessions armazenando o estado em uma base de dados Para garantir integridade dos dados, é preciso um mecanismo de locking pessimista Database Session State Web Server A Web Server B Web Server C Database HTTP Request HTTP Request HTTP Request
- 30. 30 IN MEMORY DATA GRIDS… Então vamos utilizar??
- 31. 31 Várias Soluções no Mercado
- 32. 32 Várias Soluções no Mercado
- 33. 33 In Memory Data Grids (IMDG) tem o objetivo de prover acesso de baixo latência e alta disponibilidade dos dados de uma aplicação, a uma área da memória. Evolução do cache distribuído Carregar terabytes de dados na memória Um IMDG é capaz de suportar requisitos para processamento de Big Data. Data Grids In Memory Data Grid ! Database
- 34. 34 Cluster Podemos distribuir nosso cache em cluster com apenas algumas configurações; Eviction Mecanismo automático de eviction para evitar erros de out-of-memory e controle do melhor uso da memória; Cache Loader É possível configurar cache loaders (ver tópico “Cache Loader”) para persistir o estado dos objetos em um banco de dados ou em um arquivo no disco; Suporte a JTA e compatibilidade com XA Gerenciamento de transação com qualquer aplicação compatível com JTA; Gerenciamento e Monitoração É possível gerenciar e monitorar os objetos de uma instância do grid de dados através de componentes JMX ou utilizar um console gráfico com RHQ. Características
- 35. 35 JSR 107 Java Temporary Caching API API baseada em Map Controlar quando a informação expira no cache Suporte a anotações JSR 307 Data Grids para a Plataforma Java Spec Leader é o criador do Infinispan API para interagir com datagrids baseados em memória e disco Features: Synchronous and asynchronous Transports An Asynchronous API Distributed code execution and Map Reduce Grouping API An Eventually consistent API JSR 107 e JSR 307
- 36. 36 Arquitetura com Data Grid
- 37. 37 Dados Operacionais Dados que mudam frequentamente (dinâmico) Alta concorrência Ex.: Locação de Assentos Dados Master Dados que dificilmente mudam: Eventos, Locais, Shows, Performances Quais dados incluir?
- 38. 38 Embedded Mode (P2P) Cache e o client que irá acessar o cache residem na mesma JVM Anatomia de um cache Infinispan
- 39. 39 Client Server Mode Acessar Infinispan de ambientes != Java Infinispan dispõe de vários módulos. (REST, Memcached, Hot Rod, Web Socket) Anatomia de um cache Infinispan
- 41. 41 Configuração - Exemplo @Produces @ApplicationScoped public EmbeddedCacheManager getCacheContainer() { GlobalConfiguration glob = new GlobalConfigurationBuilder() .nonClusteredDefault() .globalJmxStatistics().enable() .build(); //Builds the GlobalConfiguration object Configuration loc = new ConfigurationBuilder() .jmxStatistics().enable() .clustering().cacheMode(CacheMode.LOCAL) .transaction() .transactionMode(TransactionMode.TRANSACTIONAL) .transactionManagerLookup(new GenericTransactionManagerLookup()) .lockingMode(LockingMode.PESSIMISTIC) .locking() .isolationLevel(IsolationLevel.REPEATABLE_READ) .eviction() .maxEntries(4) .strategy(EvictionStrategy.LIRS) .loaders() .passivation(false) .addFileCacheStore() .location(dataDir + File.separator + "TicketMonster-CacheStore”).purgeOnStartup(true) .build(); return new DefaultCacheManager(glob, loc, true); }
- 43. 43 Local Cache Cache tradicional, apenas para a instância onde está sendo executado. Local Cache
- 44. 44 Modo de Replicação Cache para ambiente de Cluster. Fácil de configurar Nodes descobrem uns aos outros Clustering
- 45. 45 Modo de Invalidação Conjunto de caches standalone Se comunicam após cada alteração Após uma alteração em um objeto, o objeto se torna inválido nos outros nós. Uso indicado para sistemas que necessitem fazer muita leitura de banco de dados Clustering
- 46. 46 Modo de Distribuição Permite que o Infinispan escale de maneira linear Conforme a necessidade, podemos adicionar mais nós ao nosso Grid. Clustering
- 47. 47 Modo de Distribuição + L1 Caching Perfeito para prevenir muitas chamadas remotas Ao detectar muitas chamadas remotas, Infinispan disponibiliza o objeto no nós solicitado por um período de tempo configurável. Clustering
- 48. 48 Patterns
- 49. 49 ORM L2 Infinispan como Cache de 2nd Nível Pode ser configurado para distribuir os dados remotamente. CUIDADO: Pois isto vai contra o objetivo primário d caches de segundo nível. Padrões de Acesso ao Cache
- 50. 50 Cache Aside Formato mais comum de cache. Ex.: Antes de acessar uma base de dados, pergunto ao cache se o elemento existe no cache? Se sim, retorno o elemento do cache. Se não, retorno a informação do banco de dados e armazeno no cache para acesso posterior. Padrões de Acesso ao Cache
- 51. 51 Read / Write Through Pattern Neste modo, o cache store é alterado ao mesmo tempo em que o cache Como consequência, o cache store é consistente com o conteúdo do cache. Padrões de Acesso ao Cache
- 52. 52 Write Behind Pattern Clássico na engenharia computacional Toda alteração é feita no cache, quando o cache estiver cheio e os elementos forem removidos, então serão escritos no data store (se necessário). Padrões de Acesso ao Cache
- 53. 53
Notas do Editor
- #17: AtomicityA transaction must function as a single indivisible unit of work so that the entire transaction is either applied or rolled back. When transactions are atomic, all changes are made (commit), or none (rollback).ConsistencyStates that only valid data will be written to the database. If a transaction is executed that violates the database’s consistency rules, the entire transaction will be rolled back and the database will be restored to a state consistent with those rules. On the other hand, if a transaction successfully executes, it will take the database from one state that is consistent with the rules to another state that is also consistent with the rules.IsolationIsolation keeps transactions separated from each other until they're finished, ensures that transactions are securely and independently processed at the same time without interference, but it does not ensure the order of transactions. DurabilityOnce committed, a transaction’s changes are permanent. Durability guarantees that the database will keep track of pending changes in such a way that the server can recover from an abnormal termination.
- #18: ConsistencyA fully consistent system is one where all database clients see the same data, even with concurrent updates all read and write operations yield a global consistent stateAvailabilityAll requests must have a response about whether it was successful or failed.Partition ToleranceRefers to the underlying system and not to the service. States that operations will complete, even if individual components are unavailable.-
- #19: If ACID is desirable in traditional database systems (RDBMS) and provides the consistency choice for partitioned databases, BASE is diametrically opposed to ACID, because promotes availability over consistency. BASE stands for Basic Available, Soft State, Eventual Consistency; and embraces the fact that consistency cannot be achieved.Basically AvailableThe system will respond even with stale data.Soft StateState might not be consistent and might be corrected.Eventually ConsistentWe allow for a delay before any individual data change completely propagates through the system. A system providing eventual consistency guarantees that replicas would
- #28: Client Session State –Session data is stored on the client side. This can be made in some different ways, you can use HTTP cookies to store information about a session, encoding data in an URL, appending some extra data on the end of each URL (URL Rewriting) or serializing the data into hidden fields on a Web form.
- #29: Server Session State – Session data is stored on the server in a serialized form. The developer just enables server sessions and creates a session for each user to stores all the transient data. The data is typically stored in server memory and looked up on each web request via a session key.In Java, they are some well know implementations, such as Stateful Session Beans and Servlet Sessions (HttpSession)Database Session State is also server-side storage, the session state is stored in a relational database and the server retrieves session information from the database.
- #30: Database Session State is also server-side storage, the session state is stored in a relational database and the server retrieves session information from the database. so in order to ensure availability our code will have to generate multiple round trips to the database. As a consequence, Distributed Transactions (XA) with Pessimistic locking in a high concurrency environment, generating multiple round trips to the database sure will surely slow data access and cause a number of scalability problems and led to an exponential increase in the network traffic and latency as well.