Télécharger pour lire hors ligne
Téléchargé parCédrick Lunven
Xebicon2019 m icroservices
Ce document présente comment utiliser Apache Cassandra pour scaler des micro-services, en abordant les cas d'usage, l'architecture, et les techniques d'implémentation. Il met en avant la capacité de Cassandra à gérer des données volumineuses et à offrir une haute disponibilité grâce à sa nature distribuée. Des exemples concrets et des ressources sont également fournis pour aider à la mise en œuvre.
Xebicon2019 m icroservices
- 1. Scaler vos Micro- Servicesavec Apache Cassandra™ 28 NOVEMBRE 2019 Cedrick Lunven- Developer Advocate DataStax
- 2. A propos demoi @clunven @clun
- 3. Agenda 1 Les cas d’usagepour 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 unescalabilité 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 estdistribué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 estdistribuée (2)
- 8. La donnée estuniformé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.
- 11. Fonctionnement de l’anneau(3/3) 0 50 33 1783 6759 (data) Replica node
- 12. Réplication de ladonnée (1/2) 59 (data) RF = 2 0 50 33 1783 67
- 13. Réplication de ladonnée (1/2) RF = 2 0 50 33 1783 67 59 (data)59 (data)
- 14. Réplication de ladonnée (1/2) RF = 2 0 50 33 1783 67 59 (data) 59 (data)
- 15. Réplication de ladonnée (2/2) 59 (data) RF = 3 0 50 33 1783 67
- 16. Réplication de ladonnée (2/2) RF = 3 0 50 33 1783 67 59 (data)59 (data)
- 17. Réplication de ladonnée (2/2) RF = 3 0 50 33 1783 67 59 (data) 59 (data) 59 (data)
- 18. Tolérance à lapanne RF = 3 0 50 33 1783 67 59 (data)59 (data)
- 19. Tolérance à lapanne RF = 3 0 50 33 1783 67 59 (data) 59 (data) 59 (data) Hint
- 20. Tolérance à lapanne RF = 3 0 50 33 1783 67 59 (data) 59 (data) 59 (data) Hint
- 21. Tolérance à lapanne RF = 3 0 50 33 1783 67 59 (data) 59 (data) 59 (data)
- 22. Rappels sur ThéorèmeCAP 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éographiquementHybrid et Multi-Cloud On- premise
- 27. Cas d’usages High Throughput HighVolume 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 1TBwith 3000tx/s/core Distributed AlwaysON = replicated Real Time = oltp requests C.A.R.D.S
- 29. Agenda 1 Les casd’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 UIMobile 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.
- 32. Principes des ArchitecturesMicroServices 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 desMicroservices ? 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 oupasser 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éespensé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 casd’usage Cassandra 2 Architecture Micro Services Cassandra & DataStax 3 Techniques d’implémentation 4 Exemples et Ressources
- 40. DataStax Drivers DataStax CassandraDrivers (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.
- 43. Parameters PreparedStatement & Parameters Bind Parameters BoundStatement AsyncResultSet AsyncResultSet Result CompletionStage CallbackHell 🔥l CLIENT Automatisation DRIVERAPI RequêtesAsynchrones
- 44. Parameters PreparedStatement & Parameters Bind Parameters Row ReactiveRow FluxReactiveResultSet Subscribe BoundStatement Subscriber.onNext Query execution onComplete() CLIENT Automatisation DRIVERAPI RequêtesRéactives
- 45. Bonne pratiques etconfiguration 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 lesdé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 casd’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. SERVICEREGISTRY 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-serviceGRPC 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.
- 52. Apollo.datastax.com 1-BUTTON CLICK FROMCLOUD CONSOLE TO WEB-HOSTED INTEGRATED DEVELOPER ENVIRONMENT (DATASTAX STUDIO) 52
- 53.
- 54.