1© OCTO 2012
Escalando Aplicações Java
com In Memory Data Grids
Wagner Roberto dos Santos
2
Apresentação
Agile Coach / Arquiteto
(Metodologia, Arquitetura, Java)
Wagner Santos
3
Escalabilidade 101
4
Performance X Escalabilidade
5
Requisito de Performance é um indicador de que a resposta do sistema em
frente a ações específicas em um dado intervalo ...
6
O Requisito de escalabilidade é a habilidade de suportar o requisito de
qualidade de serviço, conforme a carga do sistem...
7
Separar a Arquitetura em diferente Tiers facilita a compreensão dos limites da
aplicação.
Performance
8
Escalabilidade
Vertical (Scaling Up) Horizontal (Scaling Out)
9
10
Master Slave Replication
Escalando o Banco de Dados
11
Active / Passive
Escalando o Banco de Dados
12
Database Clustering
Shared Everything Architecture
Escalando o Banco de Dados
13
Database Sharding
Shared Nothing
Escalando o Banco de Dados
14
Shared Everything vs Shared Nothing
Escalando o Banco de Dados
15
BASE e o Teorema CAP
16
Banco de Dados Tradicional - ACID
Atomicity
Consistency
Isolation
Durability
Transação Distribuída
17
Apresentado pelo Dr. Eric A. Brewer (2000), no contexto de web services
Provado por Seth Gilbert e Nancy Lynch na MIT e...
18
Se ACID é desejado em sistemas de banco de dados tradicionais (RDBMS) e
provê a escolha de consistência para banco de d...
19
ACID vs BASE
20
Case Ticket Monster
21
É um sistema de venda de tickets online, parte do JBoss Developer Framework
(JDF)
JDF é um hub que concentra toda a doc...
22
Arquitetura Tradicional
23
Novos Requisitos relacionados a Performance
High concurrency
Dependendo do show, os tickets podem ser vendidos em 5 min...
24
25
Client Session State
Server Session State
Database Session State
Patterns to Store Session State
26
Mas qual pattern desses utilizar?
27
No Client Session State
28
Web Sessions
Sticky Session (ou affinity)
Conexão fica dedicada a um servidor.
Outros servidores não tem nenhum conheci...
29
Web Sessions armazenando o estado em uma base de dados
Para garantir integridade dos dados, é preciso um mecanismo de l...
30
IN MEMORY DATA GRIDS…
Então vamos utilizar??
31
Várias Soluções no Mercado
32
Várias Soluções no Mercado
33
In Memory Data Grids (IMDG) tem o objetivo de prover acesso de baixo latência
e alta disponibilidade dos dados de uma a...
34
Cluster
Podemos distribuir nosso cache em cluster com apenas algumas configurações;
Eviction
Mecanismo automático de ev...
35
JSR 107
Java Temporary Caching API
API baseada em Map
Controlar quando a informação expira no cache
Suporte a anotações...
36
Arquitetura com Data Grid
37
Dados Operacionais
Dados que mudam frequentamente (dinâmico)
Alta concorrência
Ex.: Locação de Assentos
Dados Master
Da...
38
Embedded Mode (P2P)
Cache e o client que irá acessar o cache residem na mesma JVM
Anatomia de um cache Infinispan
39
Client Server Mode
Acessar Infinispan de ambientes != Java
Infinispan dispõe de vários módulos. (REST, Memcached, Hot R...
40
Named Cache
Garante Multitenancy
Named Cache
41
Configuração - Exemplo
@Produces
@ApplicationScoped
public EmbeddedCacheManager getCacheContainer() {
GlobalConfigurati...
42
Clustering Modes
43
Local Cache
Cache tradicional, apenas para a instância onde está sendo executado.
Local Cache
44
Modo de Replicação
Cache para ambiente de Cluster.
Fácil de configurar
Nodes descobrem uns aos outros
Clustering
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 o...
46
Modo de Distribuição
Permite que o Infinispan escale de maneira linear
Conforme a necessidade, podemos adicionar mais n...
47
Modo de Distribuição + L1 Caching
Perfeito para prevenir muitas chamadas remotas
Ao detectar muitas chamadas remotas, I...
48
Patterns
49
ORM L2
Infinispan como Cache de 2nd Nível
Pode ser configurado para distribuir os dados remotamente.
CUIDADO: Pois isto...
50
Cache Aside
Formato mais comum de cache.
Ex.:
Antes de acessar uma base de dados, pergunto ao cache se o elemento exist...
51
Read / Write Through Pattern
Neste modo, o cache store é alterado ao mesmo tempo em que o cache
Como consequência, o ca...
52
Write Behind Pattern
Clássico na engenharia computacional
Toda alteração é feita no cache, quando o cache estiver cheio...
53
Próximos SlideShares
Carregando em…5
×

TDC2013 Escalando Aplicações Java com In Memory Datagrids

839 visualizações

Publicada em

Palestra realizada no evento TDC 2013 - São Paulo.
Trilha Arquitetura Java - Escalando Aplicações Java com In Memory Datagrids

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

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

Nenhuma nota no slide
  • 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.
  • 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.-
  • 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
  • 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.
  • 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.
  • 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.
  • TDC2013 Escalando Aplicações Java com In Memory Datagrids

    1. 1. 1© OCTO 2012 Escalando Aplicações Java com In Memory Data Grids Wagner Roberto dos Santos
    2. 2. 2 Apresentação Agile Coach / Arquiteto (Metodologia, Arquitetura, Java) Wagner Santos
    3. 3. 3 Escalabilidade 101
    4. 4. 4 Performance X Escalabilidade
    5. 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. 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. 7 Separar a Arquitetura em diferente Tiers facilita a compreensão dos limites da aplicação. Performance
    8. 8. 8 Escalabilidade Vertical (Scaling Up) Horizontal (Scaling Out)
    9. 9. 9
    10. 10. 10 Master Slave Replication Escalando o Banco de Dados
    11. 11. 11 Active / Passive Escalando o Banco de Dados
    12. 12. 12 Database Clustering Shared Everything Architecture Escalando o Banco de Dados
    13. 13. 13 Database Sharding Shared Nothing Escalando o Banco de Dados
    14. 14. 14 Shared Everything vs Shared Nothing Escalando o Banco de Dados
    15. 15. 15 BASE e o Teorema CAP
    16. 16. 16 Banco de Dados Tradicional - ACID Atomicity Consistency Isolation Durability Transação Distribuída
    17. 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. 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. 19 ACID vs BASE
    20. 20. 20 Case Ticket Monster
    21. 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
    22. 22. 22 Arquitetura Tradicional
    23. 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. 24
    25. 25. 25 Client Session State Server Session State Database Session State Patterns to Store Session State
    26. 26. 26 Mas qual pattern desses utilizar?
    27. 27. 27 No Client Session State
    28. 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. 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. 30 IN MEMORY DATA GRIDS… Então vamos utilizar??
    31. 31. 31 Várias Soluções no Mercado
    32. 32. 32 Várias Soluções no Mercado
    33. 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. 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. 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. 36 Arquitetura com Data Grid
    37. 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. 38 Embedded Mode (P2P) Cache e o client que irá acessar o cache residem na mesma JVM Anatomia de um cache Infinispan
    39. 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
    40. 40. 40 Named Cache Garante Multitenancy Named Cache
    41. 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); }
    42. 42. 42 Clustering Modes
    43. 43. 43 Local Cache Cache tradicional, apenas para a instância onde está sendo executado. Local Cache
    44. 44. 44 Modo de Replicação Cache para ambiente de Cluster. Fácil de configurar Nodes descobrem uns aos outros Clustering
    45. 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. 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. 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. 48 Patterns
    49. 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. 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. 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. 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. 53

    ×