Blueprints e Padrões de Arquitetura para Sistemas que Escalam Linearmente

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
TDC 2014, HPC
Blueprints & Patterns de Arquitetura
Para Sistemas que Escalam Linearmente
Ricardo Ferreira
Principal Solutions Architect
Oracle FMW Architects Team (The A-Team)
08 de Agosto, 2014
The Developers Conference 2014, Trilha HPC

• Ricardo Ferreira
– Principal Solutions Architect, Oracle
Sobre o Palestrante
The Developers Conference 2014, Trilha HPC 2
@jricardoferreir
https://blogs.oracle.com/middlewareplace
www.linkedin.com/profile/view?id=13126927
www.ateam-oracle.com/a-team-chronicles

“Possuo um sistema que atualmente
suporta 500 TPS, executando numa
infra-estrutura de dois servidores de
última geração.
Visando dobrar a escalabilidade,
adicionei mais outros dois
servidores com a mesma
configuração, mas ao invés de
atingir 1000 TPS, o sistema fica em
torno de ~750 TPS...”

“Meu sistema precisa executar
suas transações em uma latência
máxima de 250ms devido a
questões de SLA com o cliente.
Devido a um aumento da carga, vi
que mesmo depois de investir em
mais hardware, não consigo ter
uma latência previsível. A carga
aumenta e o SLA quebra...”

“Meu negócio depende de uma
aplicação transacional crítica. Fazer
mais transações significa obter um
faturamento maior.
Não sei mais o que faço. Já dobrei a
infraestrutura atual, a equipe de
desenvolvimento otimizou o código
mas o throughput não melhora.”

• Escalabilidade
– Comportamento de um sistema quando a
carga total suportada aumenta a medida que
os recursos de hardware também
aumentam.
• Escalabilidade Linear
– Cenário onde a carga suportada aumenta e o
throughput também aumenta
proporcionalmente, porém mantendo
sempre a latência de cada transação.
• Escalabilidade Limite
– O limite no qual o sistema pára de escalar,
em decorrência do aumento da carga, com
ou sem aumento dos recursos de hardware.
Gargalo puro!
Alinhando os Conceitos sobre Escalabilidade

Anatomia de uma Aplicação Transacional Típica
Visão Lógica de uma Arquitetura de Software Projetada para OLTP
Camada de Lógica
& de Negócio
Camada de
Apresentação
Camada de Dados
& de Persistência
Model-View-Controller, Front
Controller, Composite View,
Intercepting Filter, Service
Locator, Transfer Object, View
Helper, Business Delegate
JavaServer Faces, Tapestry,
Spring MVC, ADF, Seam, UI,
Struts, Wicket, Play, GWT
Session Facade, Application
Service, Transfer Object, Value
List Handler, Composite Entity,
Business Object, Data Access
Object, Domain Store, Broker
Enterprise JavaBeans, POJO,
Spring, Message Driven-Bean,
RMI, Web Services, REST
Data Access Object, Transfer
Object, Domain Store, Web
Service Broker, Decorator,
Proxy, Flyweight, Command,
Memento, Adapter, Bridge
Java Persistence API, Toplink,
EclipseLink, Hibernate, Kodo,
iBatis, OJB, Prevayler,
Speedo

Anatomia de uma Aplicação Transacional Típica
Visão Física de uma Arquitetura de Software Projetada para OLTP
AppServer Cluster “A”
AppServer Cluster “B”
DBMS
Cluster
I/O I/O
LoadBalancer

Técnicas de Escalabilidade em Aplicações Transacionais
Escalabilidade Vertical: Mais Hardware significa Mais Processamento
1 Gb/s Ethernet | 96 GB de RAM
16 Cores (2x Intel Xeon 8 Cores)
3 Gb/s Ethernet | 256 GB de RAM
16 Cores (2x Intel Xeon 8 Cores)
Upgrade

Curiosidade: Serialização versus Throughput
• Servidor com 04 cores Intel Xeon
– 1 GB/s Ethernet = ~128MB/s
– Na teoria: ~645K Objetos / Seg
– Na prática: ~600 Objetos / Seg
• CPU se torna o principal gargalo
– Serialização consume vários clocks
– Threads precisam estar dedicados
– Solução: colocar vários servidores em
cluster para distribuir a carga
public class Customer
implements Serializable {
private UUID custId;
private String name;
private Date birthDate;
private long lastUsage;
}
~208 Bytes

Escalabilidade Horizontal: Mais Servidores para Distribuição da Carga
DBMS
Cluster
I/O I/O
LoadBalancer

Curiosidade: Transações versus Threading
• Atomicidade
• Consistência
• Isolamento
• Durabilidade
 DBMS é confiável devido ao ACID
– Confiabilidade vem sempre antes de performance.
– Este é um trade-off arquitetural clássico.
 Isolamento é o principal atributo
– Sem ele os demais atributos não fazem sentido.
– Para isolar as transações é necessário serializar.
– Serialização limita throughput e causa contenção de
I/O no pool de threads das aplicações.

Arquiteturas baseadas
em DBMS funcionaram
bem durante anos. Que
espécie de palhaçada é
essa agora ???

#1 Pattern
Escalando as Aplicações Junto com o Volume de Dados

Contexto: Dados Atualmente Residem no DBMS
Por quê as Aplicações precisam do DBMS para Manipular os Dados?
Switch de Rede
I/O
I/O
I/O
I/O
BasesBases
de Dadosde Dados

Problema: Canal de Rede não Acompanha Crescimento
Distância entre as Aplicações e os Dados Provoca Perda de Throughput
Switch de Rede
I/O
I/O
I/O
I/O
BasesBases
de Dadosde Dados

Solução: In-Memory Data Grid Conectado às Aplicações
Dados devem Residir no In-Memory Data Grid e Dormir no DBMS/Storage
Escalar Escalar

#2 Pattern
Remoção do I/O do Caminho Crítico das Transações

Contexto: Sincronização entre Aplicações e o DBMS
Por quê precisamos do DBMS para obter Consistência de Dados?
BasesBases
de Dadosde Dados
BasesBases
de Dadosde Dados
2PC 2PC
Sincronismo de Dados através de Replicação

Problema: Muito Sincronismo Cria Contenção de I/O
Pool de Threads da Aplicação em Espera pela Confirmação do DBMS
TX 1
TX 2
TX 3
TX 4
TX 5
TX 6
TX 7
TX 8
TX 9
BasesBases
de Dadosde Dados
I/O

Solução: Transações Efetuadas de Forma Assíncrona
Pool de Threads mais Eficiente sem as Contenções de I/O do DBMS
BasesBases
de Dadosde Dados
AsyncWrite
Queueing
AsyncWrite
Queueing
AplicaçãoAplicação In-MemoryIn-Memory
Data GridData Grid
Pool de
Threads
Pool de
Threads
Pool de
Threads
Pool de
Threads
Pool de
Threads
Pool de
Threads
Pool de
Threads
Pool de
Threads
Pool de
Threads

#3 Pattern
Maior Controle sobre as Pausas de GC da VM

Contexto: Plataformas baseadas em VM usam GC
Por quê uma VM fica em Pausa Utilizando a CPU somente para GC?

Problema: Pausas Frequentes de GC Aumenta Latência
Escalabilidade Linear Comprometida devido a Latências Muito Altas
348ms
125ms 187ms 31ms 5ms
696ms
304ms 331ms 54ms 7ms
232ms
87ms 102ms 38ms 5ms
Exemplos de SLA para a Transação
Abaixo ou Até 250ms Acima de 250ms

Solução: Offloading de Objetos da Memória Heap
Redução do Footprint da VM através de Objetos Alocados Off-Heap
Off-Heap da Sessão HTTPOff-Heap da Sessão HTTP Off-Heap de Dados do IMDGOff-Heap de Dados do IMDG
In-MemoryIn-Memory
Data GridData Grid
Heap
Média de 8GB
RAM
Mais de 64GB
SSD/HD
Mais de 1TB
Storage
AplicaçãoAplicação Sessão
HTTP
In-Memory Data GridIn-Memory Data Grid
~65% de Offload *
-Xms768m -Xmx768m
* Aplicação Java EE baseada em JSF, CDI, MyFaces, Tomahawk & RestEasy

Solução: Usando G1 do Oracle JDK 1.7.4+
Tempo de GC mais Previsível usando o Algoritmo Garbage First
java -server –d64 –Xms8g –Xmx8g
–XX:UseConcMarkSweepGC –XX:UseTLAB
-XX:+AggressiveOpts –XX:NewRatio=2
-XX:SurvivorRatio=8 –XX:NewSize=4m
–XX:MaxNewSize=4 –XX:MaxPermSize=8
-XX:UseAltSigns -XX:+UseLargePages
-XX:LargePageSizeInBytes=8192m
java –Xms8g –Xmx8g –XX:+UseG1GC
-XX:MaxGCPauseMillis=250ms
GC Tradicional (Ex: CMS) GC usando G1

#4 Pattern
Processamento Analítico Concomitante com as Transações

Contexto: Análise de Dados hoje é feita Post-Mortem
Por quê a Análise é feita Somente Depois da Gravação dos Dados?
BasesBases
de Dadosde Dados
SELECT * FROM BID
WHERE ID = 1 AND...

Problema: Volume de Dados Inviabiliza OLAP Tradicional
Terabytes/Petabytes de Dados já não Cabem em Simples Janelas Batch
ETL
ETL
ETL
ETL
ExtractExtract
Tabelas deTabelas de
StagingStaging
BI & AnalyticsBI & Analytics
Captura
(~24 horas)
Agregação
(~8 horas)
SQL
SQL
SQL
SQL
SQL
SQL

Solução: Processamento Contínuo das Transações
CEP Analisando Continuamente Eventos do In-Memory Data Grid
In-Memory Data GridIn-Memory Data Grid
CEPCEP
Async
Write
Async
Event

Leitura Recomendada
Architecting Infinitely Scalable Systems
“Life Beyond Distributed Transactions: An Apostate’s Opinion”
http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf
Pat Helland | SalesForce
Distinguished Software Architect

Vídeo Recomendado
Scalability with Distributed Data Grids
“Google Talks 2007 Event: Oracle Coherence Data Grid”
http://www.youtube.com/watch?v=W3W10J3uWxY
Cameron Purdy | Oracle
VP of Java Development

Vídeo Recomendado
Solving Business Crisis with Fast Data
“Big/Fast Data World Keynote at Innovation World 2013”
http://www.youtube.com/watch?v=wALeG86puGs
Dr. John Bates | Software AG
Chief Marketing Officer

Blueprints e Padrões de Arquitetura para Sistemas que Escalam Linearmente

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Blueprints e Padrões de Arquitetura para Sistemas que Escalam Linearmente

Similaire à Blueprints e Padrões de Arquitetura para Sistemas que Escalam Linearmente (20)

Blueprints e Padrões de Arquitetura para Sistemas que Escalam Linearmente

Notes de l'éditeur