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.

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

3. 3
Escalabilidade 101

4. 4
Performance X Escalabilidade

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

20. 20
Case Ticket Monster

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
Arquitetura Tradicional

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

40. 40
Named Cache
Garante Multitenancy
Named Cache

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
Clustering Modes

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