What are correct use cases for Cassandra ? When you use Microservices, is Cassandra a good fit ? HOw to implement Microservices ? Sample Code

1. Scaler vos Micro-
Services avec Apache
Cassandra™
28 NOVEMBRE 2019
Cedrick Lunven- Developer Advocate DataStax

2. A propos de moi
@clunven
@clun

3. Agenda
1
Les cas d’usage pour Apache
Cassandra™
2
Architecture MicroServices
Cassandra & DataStax
3 Techniques d’implémentation
4 Exemples et ressources

4. NOEUD
NOEUD
NOEUD
NOEUD
NOEUD NOEUD
NOEUD
Apache Cassandra™ = Base de données NoSQL
distribuée
1 Installation = 1 NOEUD
✔ Capacité: ± 1Terra-Octet
✔ Throughput: 3000 Tx/sec/core
Communication:
✔ Gossiping
DataCenter | Anneau

5. Qui offre une scalabilité horizontale linéaire
 Besoin de plus de capacité  Ajouter des nœuds
 Besoin de plus de throughput  Ajouter des nœuds

6. La donnée est distribuée
Country City Habitant
USA New York 8.000.000
USA Los Angeles 4.000.000
FR Paris 2.230.000
DE Berlin 3.350.000
UK London 9.200.000
AU Sydney 4.900.000
FR Toulouse 1.100.000
JP Tokyo 37.430.000
IN Mumbai 20.200.000
DE Nuremberg 500.000
CA Montreal 4.200.000
CA Toronto 6.200.000
Partition Key

7. Range
A-E
U-W
L-P
X-Z
H-K
Q-T
F-G
La donnée est distribuée (2)

8. La donnée est uniformément distribuée
A-E
CO City Habitant
AU Sydney 4.900.000
CA Toronto 6.200.000
CA Montreal 4.200.000
DE Berlin 3.350.000
DE Nuremberg 500.000
Partitionner
Hashing Function
CO City Habitant
59 Sydney 4.900.000
12 Toronto 6.200.000
12 Montreal 4.200.000
45 Berlin 3.350.000
45 Nuremberg 500.000
Tokens
VNode

9. Fonctionnement de l’anneau (1/3)
0
50
33
1783
67
59 (data)
Coordinator
node

10. 0
50
33
1783
67
59 (data)59 (data)
Coordinator
node
Replica
node
Fonctionnement de l’anneau (2/3)

11. Fonctionnement de l’anneau (3/3)
0
50
33
1783
6759 (data)
Replica
node

12. Réplication de la donnée (1/2)
59 (data)
RF = 2
0
50
33
1783
67

13. Réplication de la donnée (1/2)
RF = 2
0
50
33
1783
67
59 (data)59 (data)

14. Réplication de la donnée (1/2)
RF = 2
0
50
33
1783
67
59 (data)
59 (data)

15. Réplication de la donnée (2/2)
59 (data)
RF = 3
0
50
33
1783
67

16. Réplication de la donnée (2/2)
RF = 3
0
50
33
1783
67
59 (data)59 (data)

17. Réplication de la donnée (2/2)
RF = 3
0
50
33
1783
67
59 (data)
59 (data)
59 (data)

18. Tolérance à la panne
RF = 3
0
50
33
1783
67
59 (data)59 (data)

19. Tolérance à la panne
RF = 3
0
50
33
1783
67
59 (data)
59 (data)
59 (data)
Hint

20. Tolérance à la panne
RF = 3
0
50
33
1783
67
59 (data)
59 (data)
59 (data)
Hint

21. Tolérance à la panne
RF = 3
0
50
33
1783
67
59 (data)
59 (data)
59 (data)

22. Rappels sur Théorème CAP
Consistenc
y
Availability
Partition
Tolerance
Par défautPar configuration
AP

23. Niveau de consistance
Client
Coordinator
node
RF = 3 CL = ONE

24. Niveau de consistance
Client
Coordinator
node
RF = 3 CL = QUORUM
Strongly Consistent : CL read + CL write >

25. Niveau de consistance
Client
Coordinator
node
RF = 3 CL = ALL

26. Data Distribuée Globalement
Géographiquement Hybrid et Multi-Cloud
On-
premise

27. Cas d’usages
High Throughput
High Volume
Mission Critical
Availability
Realtime
Distributed
Heavy Writes
Heavy Reads
Event Streaming
Internet of Things
Log Analytics
Any TimeSeries
Caching
Market Data
Prices
No Data Loss
Reponsive System
Any CRUD
API Layer
Geograhically
Deployments
D
R
A
S
Banking
Track and Trace
Customer Apps Enterprise Data
Layer
Applications
Global Company
Retailers
Hybrid Cloud
MultiCloud
?

28. Contextual
(Know your queries)
Scalable
1TB with 3000tx/s/core
Distributed
AlwaysON
= replicated
Real Time
= oltp requests
C.A.R.D.S

29. Agenda
1 Les cas d’usage Cassandra
2
Architecture Micro Services
Cassandra & DataStax
3 Techniques d’implémentation
4 Exemples

30. Fragmentation des Architectures
30
Monolithique
Business
Logic
User
Interface
Data
Interface
Multi-Canal
UI Mobile UI Web
ESB
SOA
Specialisation
BUS
S1 S2 S3
S
n
RDBM
S
noSQ
L DataLak
e
Micro
Frontend
All Things Distributed
Web
Components
SP
A
Native
BFF (Backend for Frontend)
Micro
Services
Data Mesh
Api Gateway
Service
Discovery
RDBM
S
Grap
h
Hadoo
p
Documen
t
KV
newSQ
L
Colum
n
TSDB
Distributed
Tracing
Containerization
En couche
Business
Logic
(Services)
User
Interface
Data
Interface
(Dao)
Backend
Front-end
OLTP OLAP
RDBMS

31. Architectures MicroServices réelles

32. Principes des Architectures MicroServices
Principes
Construire autour
des modèles
métiers
Décentraliser au
possible
Déploiements
Indépendants
Isoler les
fonctionnalités
Hautement
Observable
Masquer les
détails
implémentation
Automatisation

33. Architectures Micro-Services : Pros and Cons
Réduction des couts
• Design plus simple
• Rapidité de développement
• Faire scaler uniquement le nécessaire
Réduction des risques
• Résilience, redondance
• Simplicité des développements
• Sécurité
• Monitoring, Traçabilité
Introduction de complexité
• Gestion des déploiements
• Orchestration des services
• Gestion des Transactions
Changements de culture
• Smart endpoints, dumb Pipes
• Design for failure, graceful degradation
Augmentation du footsprint au RUN
InconvénientsAvantages

34. Patterns d’implémentation des Microservices
?
Source: https://microservices.io/patterns/microservices.html
3 1
2

35. Données partagée ≠ une installation de la base de données
Apache Cassandra™ permet une isolation
 Par keyspace (DC + option de réplications)
 Par table (1 table = 1 requête + DOMAINE METIER)
 Par utilisateur (RBAC)
Apache Cassandra™ is Always-ON
 L’arrêt d’un nœud n’entraine pas d’arrêt du service
35
Database par service vs Database « partagée »
• Le couplage entre les services doit rester lâche
• Chaque service doit être responsable de ses données
• Une base de donnée partagée introduirait une forme de couplage

36. Eventual Consistency ou passer de « ACID » vers
« BASE »
Pour des opérations cross-services :
Atomicity Consistency Isolation Durability
(ACID) ne fonctionne plus.
Distributed transactions and 2 phases
commit (2PC) ne fonctionnent plus.
● BASE (Basic Availability, Soft-State,
Eventual Consistency) : Privilégier la
disponibilité sur la consistance
● Event Sourcing : Sauvegarde des
messages et non de l’état final
● Idempotence : Il doit être possible de
rejouer plusieurs fois chaque message
Order
Management
Service
Customer
Management
Service
NoSQL
Order
Database
SQL
Customer
Database
No distributed transaction
No joins

37. Local
Transaction
TX1
Local
Transaction
TX2
Local
Transaction
TX3
Saga
event event
Les « Sagas », pour assurer consistance de la donnée
• Définitions de transactions locales
• Envoi d’évènements de proche en proche
• Evènements de compensation en cas de problèmes
 Chorégraphie (Event Drivent Architecture)
 Orchestration (BPM)

38. ● Architectures distribuées pensées pour la scalabilité et la résilience le requêtage en
temps réel.
● Des modèles de données adaptés aux besoins : timeseries, requêtes CRUD sur les
entités
● Un couplage lâche et une ségrégation by design , y compris sur le même cluster
○ keyspace = domaine
○ table = requêtes
● Une même philosophie pour l’implémentation des transactions et requêtes cross-
services
○ Basic Availability, Soft-State Eventual Consistency (BASE)
○ Command Query Responsibility Segregation (CQRS)
○ Sagas
38
Cassandra™ & DataStax Micro-services

39. Agenda
1 Les cas d’usage Cassandra
2
Architecture Micro Services
Cassandra & DataStax
3 Techniques d’implémentation
4 Exemples et Ressources

40. DataStax Drivers
DataStax Cassandra Drivers (OSS)
CQL Support
Sync / Async API
Address Translation
Load Balancing Policies
Retry Policies
Reconnection Policies
- Connection Pooling
- Auto Node Discovery
- SSL
- Compression
- Query Builder
- Object Mapper
DataStax Enterprise Drivers
OSS Drivers capabilities plus Enterprise
improvements for
• Performance, Usability, Scalability,
Ecosystem
DSE Advanced Security, Unified
Authentication
DSE Graph Fluent API
DSE Geometric Types
• ODBC
• JDBC

41. Modélisation de données
41
Entités & Relations
Requêtes
Academy.datastax.com

42. Parameters
RequêtesSynchrones
PreparedStatement
& Parameters
Bind
Parameters
BoundStatement
ResultSet
ResultSet
Results
Blocked
😴
CLIENT Automatisation DRIVERAPI

43. Parameters
PreparedStatement
& Parameters Bind
Parameters
BoundStatement
AsyncResultSet
AsyncResultSet
Result
CompletionStage
Callback Hell 🔥l
CLIENT Automatisation DRIVERAPI
RequêtesAsynchrones

44. Parameters
PreparedStatement
& Parameters Bind
Parameters
Row
ReactiveRow
Flux ReactiveResultSet
Subscribe
BoundStatement
Subscriber.onNext
Query execution
onComplete()
CLIENT Automatisation DRIVERAPI
RequêtesRéactives

45. Bonne pratiques et configuration du drivers
● Activer les polices de Load Balancing | Retry |
Failover
● Définissez explicitement votre Datacenter de
travail (ou anneau) pour limiter la latence
● Les sessions ne sont pas stateless
○ L’initialisation de la connexion prend un certain
temps
○ Utiliser les fonctions cold start le serverless
○ Fermer les sessions lors de l’arrêt de vos
applications (shutdown hooks)
○ Utiliser un rollings restart des micro-services pour ne
pas rétablir toutes les connections en même temps45
datastax-java-driver {
basic {
load-balancing-policy {
# The class of the policy.
class = DefaultLoadBalancingPolicy
# The datacenter that is considered "local"
# The default policy will only include nodes from
# this datacenter in its query plans.
local-datacenter = datacenter1
# A custom filter to include/exclude nodes
// filter.class=
}
}
}
application.conf

46. Containeurs
● Pour les déploiements les
architectures à base de containeurs
sont très répandues
● Attention:
● Les bases de données sont statefuls
aussi bien penser à utiliser les
statefulsets Kubernetes ou un operator
pour les opérations de maintenance.
46 https://github.com/datastax/labs/tree/master/dse-k8s-operator

47. Agenda
1 Les cas d’usage Cassandra
2
Architecture Micro Services
Cassandra & DataStax
3 Techniques d’implémentation
4 Exemples et Ressources

48. KillrVideo Reference Application
48
● Application de référence pour
apprendre à développer avec
Apache Cassandra et DataStax
Enteprise
○ DataStax Drivers
○ Docker images
● Code source disponible ici:
○ https://github.com/killrvideo
● Version live disponible ici :
http://killrvideo.com

49. 1. WEB
Client
bootstra
p
reac
t
redu
x
falco
r
2. SERVICE REGISTRY
5. SERVICES
8. DSE
CASSANDRA
SEARCH
GRAPH
ANALYTICS
4. STUDIO
DRIVERS
3. REGISTRATOR
7. INTEGRATION TESTS
Server
falco
r
Customer
Browser
6. GENERATOR
Killrvideo-generator
Killrvideo-it
1b
1c
1d
1a
7a
7b
6a 6b
3a
5a
5b
3b
4b
4a

50. Exemples
Micro-service REST
https://bit.ly/31RL62I
Micro-service GraphQL
https://bit.ly/2MVicup
Micro-service GRPC Micro-service Kafka
Micro-service Réactif Micro-service Serverless
https://bit.ly/2pofk0b
https://bit.ly/34ePzhL
https://bit.ly/2JwsFdM
https://bit.ly/31VQz8G

51. CLIENT
Apollo.datastax.com
Client VPCLocal Desktop
51
Public IP
Endpoint

52. Apollo.datastax.com
1-BUTTON CLICK FROM CLOUD CONSOLE TO WEB-HOSTED
INTEGRATED DEVELOPER ENVIRONMENT (DATASTAX STUDIO)
52

53. community.datastax.com

54. Merci. Questions ?
@clunven