La présentation se concentre sur Gigaspaces, une plateforme de cache distribué qui améliore la scalabilité et la performance des applications transactionnelles. Elle couvre son histoire, ses fonctionnalités principales, des cas d'utilisation, ainsi que la gestion de la performance et de la scalabilité du datagrid. Des démonstrations et des exemples d'architecture sont également inclus pour illustrer son intégration et son fonctionnement dans divers contextes.

1. NOSQL User Group Paris
21 Juin 2011
www.fastconnect.fr

2. Agenda
 Introduc0on
 GigaSpaces
 Historique
d’un
cache
distribué
à
une
plate-­‐forme
transac<onnelle
scalable
 Fonc<onnalités
principales
 Cas
d’u<lisa<on
 Le
DataGrid
main<ent
la
performance
et
gère
la
scalabilité
du
Grid
Compu<ng
 Référen<el
de
données
 Plate-­‐forme
de
routage
d’ordres
interna<onale
 Résumé
 Démo

3. Qui
sommes
nous
?
> SELECT * FROM nosqlparis.speakers WHERE
company = ‘FastConnect’
+-------------------------------------------------------------------------------+
| Name | Company | Role |
+-------------------------------------------------------------------------------+
| Gauvain Girault | FastConnect | Resp. Dpt Conseil & Solutions, CTO fondateur |
| Luc Boutier | FastConnect | Resp. Pôle Grid/DataGrid & SOA Open Source |
+-------------------------------------------------------------------------------+
> nosqlparis.speakers.find({name:“Gauvain Girault”})
{
name:“Gauvain Girault”,
company: {
name:“FastConnect”,
domains:[“SOA” “EAI/ESB” “Grid”,“DataGrid”,“Cloud/PaaS” “Optimisation”]
expertise:“Architectures Distribuées”
}
role:“CTO”,
}

4. Agenda
 Introduc<on
 GigaSpaces
 Historique
d’un
cache
distribué
à
une
plate-­‐forme
transac0onnelle
scalable
 Fonc<onnalités
principales
 Cas
d’u<lisa<on
 Le
DataGrid
main<ent
la
performance
et
gère
la
scalabilité
du
Grid
Compu<ng
 Référen<el
de
données
 Plate-­‐forme
de
routage
d’ordres
interna<onale
 Résumé
 Démo

5. Historique
Applica<ons

6. Au
commencement,
il
y
avait
Jini
…
API Jini/JavaSpaces
• Write – écrit un objet
Applica<ons
Jini Write • Read – lit un objet
• Entry • Take – lit un objet et
• Discovery & join l’efface (atomique !)
• Distributed Leasing • Notify – génère une
(lease management & notification sur le
renewal) Read, T changement d’état d’un
• Distributed Event ake, objet
programming model Notify
Read, Take,
• Transaction model &
Write
Notify
semantics

7. Et
son
modèle
tuple
• Base de l’interopérabilité entre
Applica<ons
langages
• Le tuple porte les méta
données : répliqué, persisté,
indexé, relations, etc…

8. Et
GigaSpaces
clusterisa
JavaSpaces
In-­‐Memory
Clustering
par00oned/replicated
,
sync/async,
with
or
w/o
backups
Clustering
Réplication
Fail-Over
Répartition de charge
Fournit: • Découplage code – déploiement
Scalabilité • Objectif : rendre flexible le
Haute Disponibilité déploiement par configuration de
Performance l’infrastructure GigaSpaces sans
changer le code

9. Evolu0on
vers
un
Cache
Distribué
• Optimisation des temps d’accès en lecture
• Déchargement de la base de données Applica<ons
• Multi langages : Java, C++, .Net
serveurs
d’applications cache distribué
sources
de données

10. Le
cache
distribué
 Qu’est
ce
que
c’est
?
 Hashmap distribuée, clusterise la mémoire d’un ensemble de machines
 A
quoi
çà
sert
?
 Op<mise
les
temps
d’accès
en
lecture
(et
écriture)
:
en
millisecondes
 Mais
la
base
de
données
reste
garante
de
l’intégrité
des
données
(System
Of
Records)
et
donc
se
trouve
sur
le
chemin
cri<que
des
données
(en
écriture)
 Technologies
phares
 Memcached, Tangosol (maintenant Oracle) Coherence, IBM eXtreme Scale,
GigaSpaces
 Diverses implémentations et fonctionnalités : hash-based, consistent hashing,
appels multiples ou non, divers langages supportés suivant les technos
 Cas
d’usage
 Sites Web : données de session, pages Web
 HPC : données de référence nécessaires au calcul

11. Puis
vers
une
grille
de
données
/
DataGrid
• Optimisation des temps d’accès en lecture et écriture
• Déchargement de la base de données
• Multi langages : Java, C++, .Net
• Transactionnel : local, distribué, XA pour certains Applica<ons
Serveurs
grille de données
sources
de données

12. La
grille
de
données
 Qu’est
ce
que
c’est
?
 Un cache distribué ++ : requêtage avancé (“SQL like”), map/reduce, multi langage et interopérabilité
( Java,C++, .Net)
 Intégration aux sources de données pilotée par le data grid
 Gestion cohérence/intégrité (locks, transactions)
 A
quoi
çà
sert
?
 Op<mise
les
temps
d’accès
en
lecture
(et
écriture)
:
en
millisecondes
 Le
back
end
(base
de
données
ou
mainframe)
n’est
plus
sur
le
chemin
cri<que
de
l’applica<on
(stockage
asynchrone)
 Technologies
phares
 Tangosol (maintenant Oracle) Coherence, IBM eXtreme Scale, GigaSpaces, Gemstone
 Cas
d’usage
 Systèmes transactionnels frontaux (devant Back Ends type mainframe)
 Finance : plates-formes de routage d’ordre
 Référentiels virtualisés (performance, scalabilité)

13. Serveur
d’applica0ons
transac0onnel
distribué

14. JEE
vs
GigaSpaces
XAP
Component
J2EE
XAP
Persistency
JPA
Hibernate,
JPA
Messaging
JMS,MDB
JMS,
Polling/No<fy
Container
,
Na<ve
Messaging
API
Security
JASS,
SSL
Spring
Security,
SSL
(incl
Data
!)
Web
Session
Management
HYpSession
HYpSession
(via
JeYy)
Transac<on
Management
JTA
Spring
Transac<on
via
Jini
Transac<on
Manager
Data
Access
JDBC
,
Session
Bean,
En<ty
Bean
JDBC,
Space,
JPA,
Document
Remo<ng
EJB,
IIOP,
RMI
Spring
remo<ng
over
LRMI
Web
Servlet,
JSP
Servlet,
JSP
(via
JeYy)
Packaging
and
deployment
ear
,
war
jar
,
war
Contexts
and
Dependency
JSR
299
Spring
IOC
Injec<on
System
Management
JMX
JMX
,
SNMP,
Na<ve
Admin
API
Java
Naming
and
Directory
Service
JNDI
Jini
Lookup
Service

15. Une
plate-­‐forme
transac0onelle
élas0que
Plusieurs
API
pour
:
•
accéder
aux
mêmes
données
(
mode
Applica<ons
tx
ou
non)
!
•
permet
d’héberger
(services)
ou
exécuter
du
code
(map/reduce)
•
déployer
ses
applis
Web
sous
Je]y
(war)
1
console
Web
et
APIs
de
supervision
et
d’administra0on
•
Contrôle
Montée
en
•
Visualisa0on
charge
•
Alertes
Elas0cité
=
dynamique
(
contrôlée
par
des
SLAs)

16. Agenda
 Introduc<on
 GigaSpaces
 Historique
d’un
cache
distribué
à
une
plate-­‐forme
transac<onnelle
scalable
 Fonc0onnalités
principales
 Cas
d’u<lisa<on
 Le
DataGrid
main<ent
la
performance
et
gère
la
scalabilité
du
Grid
Compu<ng
 Référen<el
de
données
 Plate-­‐forme
de
routage
d’ordres
interna<onale
 Résumé
 Démo

17. Au
cœur
de
GigaSpaces
:
Space
Based
Architecture
La Processing Unit Cloud de Processing
Un Space:
• Unité de scalabilité Units
• Elégance – 4 API simples
• Ensemble de : services, données, • Scalabilité à travers le
• Gère:
événementiel partitionnement
• Etat
• Colocalisation au sein du même • Virtualisation
• Messaging
espace mémoire (VM) middleware et
• Workflow
• Gestion unifiée Evénements et infrastructure
• Parallel processing Données (DataCenter, Cloud
• In-Memory + colocalisation = privé, public, …)
latence minimisée

18. Un
middleware
en
mémoire
souple
• Accès
unifié
aux
données
en
mémoire
• Topologie
flexible,
une
API
(“Write
Once
Scale
Anywhere”)
– Embarqué,
clusterisé,
quelque
soit
le
type
(par<<onné,
répliqué,
avec
ou
sans
réplicas/backups)
– Local
ou
distribué
ou
mixte
(master-­‐local
+
évic<on)
• Une
variété
d’API
clientes
– Map/Jcache,
Space,
Document,
en
Java,
.Net,
C++

19. Embarqué
/
Distribué
/
Master-­‐Local

20. Scalabilité
par
le
par00onnement
Routage contrôlé Scalabilité
(Hash % #partitions) dynamique par
=> latence optimisée
Par00on
1
la dissociation
JVM/ partitions
Load
Users
Balancer
• une JVM peut
contenir
Reader
(Proxy) Par00on
2
plusieurs
Writer
‘partitions’
(Proxy) • ajoût JVM et
rebalancing
Par00on
3
automatisé =>
scalabilité
Scalabilité : dynamique
• données Par00on
• requêtes #N

21. Résilience
à
travers
l’u0lisa0on
de
replicas/backups
Par00on
1
Replica
1
Users Load
Balancer
Reader
(Proxy) Par00on
1
Replica
1
Writer
(Proxy)
Par00on
1
Replica
1
Par00on
1
Replica
1

22. Résilience
controlée
:
placement
zones
(DR,
main)
Active/Active deployment Site failure
SITE A SITE B SITE A SITE B
Recovery after Site failure Rebalancing…
SITE A SITE B SITE A SITE B

23. Ges0on
fédéra0ons
de
clusters
mul0-­‐sites
SITE SITE
A B
Mirror
Mirror
WAN
Mirror Mirror
SITE SITE
C D
23

24. File
Based
Wan
Gateway
v1
(FastConnect)

25. Configura0on
des
paramètres
CAP
• Nombre
configurable
de
réplicas/backups
par
par<<on
• Eventual
consistency
(Réplica<on
asynchrone)
– Meilleure
performance
pour
les
opéra<ons
“destructrices”
(write/update/take/clear)
– Peut
créer
des
probèmes
de
consistance
dans
les
lectures
(pas
de
quorum
reads
par
défaut)
– Résilience
–
possibilité
de
perte
de
données
• Strong
consistency
(Réplica<on
synchrone)
– Performance
en
écriture
divisée
par
2
au
moins
(aYente
acquiYement
réplicas)
– Consistance
garan<e
• Combinaison
des
2
:
Write
behind
(GigaSpaces
Mirror)
– Synchrone
en
mémoire
– Asynchrone
vers
le
disque

26. Plusieurs
APIs
d’accès
aux
données
• Objec<fs
– Minimiser
le
“lock-­‐in”
au
niveau
code
– Faciliter
la
migra<on
d’applica<ons
existantes
– Choisir
le
meilleur
ou<l
en
fonc<on
du
besoin
– Réunir
les
mondes
SQL
et
non-­‐SQL
• Fonc<onnalités
– Mul<
langages
(Java,
.Net,
C++)
– Support
de
JPA
– API
orientée
Document
– Support
JDBC
– Memcached

27. Exemples
de
requêtes
• GigaSpaces
Object
oriented
API
• GigaSpaces
JDBC
API
• Memcached
API
• Map/Reduce

28. JPA
• GigaSpaces
JPA

29. Modèle
document
Metadata
Schema
free
Nested
documents
Query
SQL
like
approach

30. Ges0on
des
collec0ons

31. Containers
d’abstrac0on
One to One One to Many
~JMS queue ~ JMS topic

32. Map-­‐Reduce
dans
GigaSpaces
Reader
Space
Writer
Read all
Web
Reader
Space
Writer
Reader
Space
Writer
Read- Map/Reduce
Implicit Map/Reduce:
Explicit Map/Reduce:

33. Ou0ls
d’exploita0on
• Objec<fs
– Simplifier
la
transi<on
du
développement
à
la
produc<on
– Automa<sa<on
sans
perte
de
contrôle
• Fonc<onnalités
– Mode
de
packaging
GigaSpaces
PU
(services
+
données,
ou
services,
ou
données)=
jar,
Web
PU
=
war
– Elas<c
middleware
• Simplifica<on
des
déploiements
à
grande
échelle
• Support
na<f
de
SLAs
pour
la
montée
en
charge
(et
la
redescente)
• Support
Mul<
cloud
– Console
de
supervision
et
contrôle
Web
– Dev
Ops
API
pour
la
customisa<on
• Intégrer
finement
l’applica<on
à
l’environnement
(infastructure,
custom
SLA)
• Automa<sa<on

34. Simplifica0on
et
centralisa0on
déploiement
Caractéris<ques
• Déploiement
centralisé
– Provisionnement
en
1
click
• Mul<-­‐tenant
– U<lise
des
ressources
partagées
(ges<on
sécurité
à
tous
les
Déploie un Data Grid Déploie un Data Grid niveaux)
Min (10G), Max (100G) Min (10G), Max (200G) • Montée
en
charge
automa<sée
– Alloca<on
de
ressources
en
Chargement
fonc<on
de
SLAs
Chargement
données
– Désalloue
les
ressources
si
données
nécessaire
(en
fonc<on
des
SLAs)
• Résilient
– Ges<on
automa<que
des
pannes
:
réalloca<on
PU,
redémarrage
containers/VMs
– Le
DataGrid
gère
la
résilence
des
données
Ressources matérielles partagées –
interac<on
avec
infrastructures
virtuelles
:
VMWare,
Xen,
AmazonEC2,
…

35. Elas0c
Management
API
Gestion déclarative
• Autres
op<ons:
– Permet
d’arrêter
ou
démarrer
des
machines
– Security
35

36. Console
d’administra0on
• Permet
le
contrôle
de
tous
les
aspects
d’une
applica<on
distribuée:
– Déploiement
/
Retrait
– Alloca0on
et
ges0on
des
ressources
– Arrêt
/
Redémarrage
de
tout
ou
par0e
• Supervision
proac<ve
de
l’applica<on
et
de
l’infrastructure
sous
jacente:
– Alertes
– Indicateurs
visuels

37. APIs
«
DevOps
»
• Visibilité
opéra<onnelle
sur
l’applica<on
déployée
à
travers
des
APIs
• Intégra<on
à
systèmes
<ers
• Ou<ls
d’administra<on
:
– Informa<ons
sur
le
comportement
de
l’applica<on
– Réac<ons
face
aux
événements
de
panne
ou
montée
en
charge
– Trouble
shoo<ng
– S’assurer
que
le
SLA
applica<f
est
respecté

38. Agenda
 Introduc<on
 GigaSpaces
 Historique
d’un
cache
distribué
à
une
plate-­‐forme
transac<onnelle
scalable
 Fonc<onnalités
principales
 Cas
d’u0lisa0on
 Le
DataGrid
main0ent
la
performance
et
gère
la
scalabilité
du
Grid
Compu0ng
 Référen<el
de
données
 Plate-­‐forme
de
routage
d’ordres
interna<onale
 Résumé
 Démo

39. Exemple
d’architecture
HPC

40. DataGrid
dans
architecture
HPC
 Généralement
calculs
de
risques
:
historical
VaR,
Stress
Var
 Ges0on
de
temps
de
réponse
très
faibles
en
lecture
 En
millisecondes
 (Ges0on
d’un
proxy
de
connexion)
 Requêtes
semi
complexes
-­‐
type
SQL
(where)
 Le
DataGrid
Supporte
de
quelques
centaines
à
quelques
milliers
de
nœuds
Grid
Compu0ng
en
produc0on
 Ges0on
de
plusieurs
centaines
de
milliers
de
requêtes
par
seconde
en
pic
 Ges0on
de
plusieurs
centaines
de
Giga
Octets
en
mémoire

41. Agenda
 Introduc<on
 GigaSpaces
 Historique
d’un
cache
distribué
à
une
plate-­‐forme
transac<onnelle
scalable
 Fonc<onnalités
principales
 Cas
d’u0lisa0on
 Le
DataGrid
main<ent
la
performance
et
gère
la
scalabilité
du
Grid
Compu<ng
 Référen0el
de
données
 Plate-­‐forme
de
routage
d’ordres
interna<onale
 Résumé
 Démo

42. Référen0el
de
données
virtualisé
 Architecture
 Clients
en
.Net
&
Java
 Font
du
Request/reply
 S’abonnent
en
No0fica0ons
 A
des
données
de
référen0el
marché
et
sta0ques
(XML
compressé)
 Back-end GigaSpaces + connecteurs d’intégration aux référentiels amonts
 GigaSpaces
adopté
en
2008
 Usage
:
 DataGrid
 par00oned-­‐sync2backup_32,1
=
32
par00ons
(1
backup/par00on)
x
6GB
 Event
container
colocalisé,
publisher/subscriber
no0fica0on
 Caractéris0ques
 DataGrid
(ALL_IN_CACHE
mode)
 Intégra0on
na0ve
à
une
base
de
données
sous-­‐jacente
 Requêtes
complexes
 Services
d’accès
aux
données
 Ges0on
transac0onnelle
 Mul0-­‐sites
gateway
(en
cours)
 Ges0on
des
SLA
(par
configura0on)
 Système
de
no0fica0ons
scalable

43. Référen0el
de
données
virtualisé
 En
produc0on
depuis
2008
 Sert
60
à
80
applica0ons
clientes
 Tourne
sur
8
machines
:
 CPU
Bi-­‐pro
8
cores
 OS
RedHat
5.5
 RAM
48
Go
 JVM
:
Sun
JDK
1.6.24
–
64bits
 GigaSpaces
6.6.6
build
3333
(JVM
size
:
6
Go/container)
;
en
migra0on
vers
GigaSpaces
8
 Oracle
DB
10g
 Sta0s0ques
journalières
 1.7
millions
d’objets
mé0ers
stockés
en
mémoire
 14
Milliards
de
lecture
en
Mai
2011
(
contre
4
Milliards
en
Janvier
2011)
 3.7
millions
d’inser0ons
/
mises
à
jour
 56
millions
de
no0fica0ons
en
Mai
2011
(contre
2.2
millions
en
Janvier
2011)
 1
million
d’effacements
(purge)
 Temps
de
réponse
en
ms
 Supervision
&
repor0ng
 Solu0on
maison

44. Agenda
 Introduc<on
 GigaSpaces
 Historique
d’un
cache
distribué
à
une
plate-­‐forme
transac<onnelle
scalable
 Fonc<onnalités
principales
 Cas
d’u0lisa0on
 Le
DataGrid
main<ent
la
performance
et
gère
la
scalabilité
du
Grid
Compu<ng
 Référen<el
de
données
 Plate-­‐forme
de
routage
d’ordres
interna0onale
 Résumé
 Démo

45. Plate-­‐forme
de
routage
d’ordres
 Architecture
haut-­‐niveau
Stats journalières
 Différents
type
de
clients
 Web,
clients
lourds,
console
d’administra0on,
jBPM
• 5 millions objets
 Services
applica0fs
WebLogic
métiers + 100k static
 DAO
layer
access
to
the
space
objects
 GigaSpaces
• 36 millions reads
 DataGrid devant une base de données
 Fournisseur d’événements sur les changements d’états des
données (pas de middleware type JMS) • 5 millions writes/
 Fonc0onnalités
u0lisées
updates
 DataGrid
(ALL_IN_CACHE
mode),
scalabilité
mé0er
 Intégra0on
à
la
base
de
données
(Hibernate)
• 800K notifications
 Queries
complexes
 Ges0on
transac0onnelle
(cri0que
et
indispensable)
 Gateway
WAN
mul0-­‐site
en
cours
de
déploiement,
ges0on
• 7K takes
intégrité
des
données
remontée
à
l’applica0on
!
 SLA
management
 No0fica0ons
vers
les
consoles
u0lisateurs
• Temps de réponse
en ms

46. Agenda
 Introduc<on
 GigaSpaces
 Historique
d’un
cache
distribué
à
une
plate-­‐forme
transac<onnelle
scalable
 Fonc<onnalités
principales
 Cas
d’u<lisa<on
 Le
DataGrid
main<ent
la
performance
et
gère
la
scalabilité
du
Grid
Compu<ng
 Référen<el
de
données
 Plate-­‐forme
de
routage
d’ordres
interna<onale
 Résumé
 Démo

47. GigaSpaces
:
entre
SGBD
en
mémoire
et
système
NoSQL
 Beaucoup
de
concepts
communs
entre
GigaSpaces
(DataGrid
en
général)
et
les
approches
NoSQL
et
similarités
avec
les
bases
de
données
 Fonc<onnalités
d’entreprise
:
transac<ons,
intégra<on
sources
de
données
externes,
WAN,
supervision
et
administra<on
 Fonc<onnalités
permeYant
la
migra<on
plus
aisée
d’applica<ons
existantes
vers
les
concepts
distribués
/
NoSQL
 Prouvé
et
opérable
(avec
la
forma<on
nécessaire)
 Flexibilité
laissée
à
l’architecte/développeur
sur
le
choix
de
l’API
à
u<liser
en
fonc<on
du
besoin
:
très
puissant
 Nécessité
de
bonnes
connaissances
d’architecture
distribuées
comme
sur
les
plates-­‐formes
NoSQL

48. SGDB,
DataGrid
ou
NoSQL,
comment
choisir
?
Attention cette grille a été réalisée en 2010 dans un contexte particulier. Elle est présente à titre informatif, et ne doit pas servir à
effectuer des choix non raisonnés ;-)

49. Doit
on
vraiment
choisir
?
• GigaSpaces
+
NoSQL
=
plate-­‐forme
tx
Big
Data
In
Memory
Data
Grid
/
App
Server
• Temps-­‐réel
Sources • Evénemen<el
• Exécu<on
de
code
au
plus
proche
des
données
Write
Behind
(async)
Combien d’erreurs aujourd’hui ?
NoSQL
(stockage
fichier)
• Stockage
à
coût
modéré
Quels sont les erreurs (rapport
prix/perfs
linéaire)
qui se produisent en
• Scalabilité
Write/Read
même temps ?
Application Analytique • Montée
en
charge
dynamique

50. Agenda
 Introduc<on
 GigaSpaces
 Historique
d’un
cache
distribué
à
une
plate-­‐forme
transac<onnelle
scalable
 Fonc<onnalités
principales
 Cas
d’u<lisa<on
 Le
DataGrid
main<ent
la
performance
et
gère
la
scalabilité
du
Grid
Compu<ng
 Référen<el
de
données
 Plate-­‐forme
de
routage
d’ordres
interna<onale
 Résumé
 Démo

51. Démo
 Intégra<on
de
GigaSpaces
serveur
d’applica<ons
distribués
et
cluster
de
données
scalable
en
mémoire
et
Cassandra
comme
stockage
persistant
et
scalable
hYp://www.gigaspaces.com/wiki/display/SBP/Cassandra+Mirror+Service

53. FastConnect
CREE EN 2004
80 CONSULTANTS
 CONSEIL  IMPLEMENTATION
 EXPERTISE  FORMATION
Sites  SUPPORT
• Paris
• Rennes (2011)
• Toulouse (2011)
Nos consultants apportent leur expertise dans les domaines suivants
 Architecture Orientée Services (SOA) et Événements (EDA)
 Conception, implémentation et optimisation d’architectures Java/EE et .Net (et clients C++ parfois)
 Intégration d’Applications et d’Informations (EAI, ESB)
 Présentation de l’information : Rich Internet-based Applications (RIA), Rich Desktop Applications (RDA)
 eXtrem Transaction Processing (XTP), Grid Computing et Data Grid
 Virtualisation applicative – Cloud Computing Fabric (PaaS)
 Gestion de processus et d’activités (BPM – BAM), gestion de règles (BRMS)
 Gestion complexe d’événements (CEP)
 Business Transaction Monitoring (BTM)

54. Nos
Partenaires
et
leurs
Posi0onnements
Nos
partenariats
éditeurs
représentent
une
part
importante
dans
notre
stratégie,
ils
nous
perme]ent
de
développer
une
exper0se
technique
«
éditeur
»
et
d’offrir
une
forte
valeur
ajoutée
à
nos
clients.
SaaS = Software As A Service
iPaaS
Supervision transaction
PaaS
Development
(Legacy
technologies)
de bout en bout
aPaaS
PaaS
:
Private
Cloud
Fabric
IaaS = Infrastructure As A Service
Private
Data
Virtualised
/
Public
Data
Center
HodtedPrivate
Center
Data
Center