Open MQ Jerome Moliere

2 121 vues

Publié le

Retour sur la mise en production de OpenMQ dans un environnement bancaire+telco. Intervenant: Jérôme Molière

Publié dans : Technologie
1 commentaire
0 j’aime
Statistiques
Remarques
  • Briser les dépendances inutiles (Spring JMS par exemple)
    Oh my god, this men don't like Spring. Perhaps don't know it.
    Perhaps like OSGi DS and Spring-DM.
    Or the Plain old legacy OSGI : ServiceTracker.
    Let's go to Spring MasterClass.
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
2 121
Sur SlideShare
0
Issues des intégrations
0
Intégrations
26
Actions
Partages
0
Téléchargements
0
Commentaires
1
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Open MQ Jerome Moliere

  1. 1. OpenMQ – Retour d'expérience J.MOLIERE – Mentor/J jerome@javaxpert.com jerome.moliere@gmail.com
  2. 2. Sommaire Contexte ● Métier – Technique – Solution technique mise en oeuvre ● Maquette réalisée – Configuration MQ – Résultats obtenus – Problèmes rencontrés –
  3. 3. Contexte Intervention en clientèle ● Start-up montpelliéraine – Middleware dans le monde bancaire, – déclenchement de transactions bancaires à partir de traitements métier suite à des opérations télécom –
  4. 4. Contexte technique (1) JMS acteur central ● Déclenche les traitements métier – Garant de la fiabilité du système – Pas de perte de messages ==> €!!! ● Un message n'est nullement correlé à un autre – Toute information perdue l ' est définitivement – 1 message perdu implique perte de chiffre pour le – client Doit etre à meme de supporter une évolution de ● la charge Sans remettre en cause l'architecture technique – Par simple mise à disposition de nouvelles – machines Réalisme entre matériel et ressources CPU/disque –
  5. 5. Contexte technique(2) Avant intervention: ● Utilisation du Spring Template JMS – Trop intrusif – gestion des pools de ● ressources par le framework plutot que déléguée au moteur JMS Architecture JMS – Utilisant ActiveMQ (Apache) ● Perte de messages – Aucune redondance (HA) – Aucun lissage de charge (load balancing) – Fonctionnalités déjà présentes dans ActiveMQ – mais relevant du stade de l'incubation et pas de la production!!!
  6. 6. Contexte technique(3) Après intervention: ● Recentrage architectural – Briser les dépendances inutiles (Spring JMS par ● exemple) Réalisation d'une réelle encapsulation de la ● couche de gestion des messages Robustesse de la solution – Plus de perte de messages ● Objectif principal atteint vis à vis du client!!! – Mais : – Pas de réel load balancing (bug dans la 4.2 ● OpenMQ)
  7. 7. Solution technique mise en oeuvre Mise en place d'un environnement de test dédié ● Virtualisation avec Virtualbox – Simplicité de mise en oeuvre ● Donc peu de temps alloué pour cette mise ne – oeuvre et donc peu de budget pour le client!! Création d'un réseau virtuel dans mon laptop ● dédié à cette maquette Aspect performance peu impactant, priorité mise ● sur la robustesse donc les gains de performance de solutions comme (KVM ou XEN) étaient peu intéressants....
  8. 8. Solution technique mise en oeuvre(2) Schéma architectural de la maquette ● –
  9. 9. Solution technique mise en oeuvre (3) Configuration OpenMQ 4.2 en mode HA ● Utilisation d'un serveur de base de données – dédié dans le cas de la démonstration: javadb aka derby Mode HA: – Pas de réel noeud maitre en théorie ● Stockage des messages en base dans un ● schéma dédié Heartbeat entre les noeuds pour découverte à ● chaud des noeuds vivants dans la grappe (cluster).
  10. 10. Solution technique mise en oeuvre (4) Gestion des acquittements coté client ● Divers choix cf specs JMS – NONE ● AUTO ● CLIENT ● Adoption d'un acquittement client – systématique Permet maitrise des traitements des ● messages Messages non acquittés sont naturellement ● délivrés de nouveau (TTL)
  11. 11. Solution technique mise en oeuvre (5) Acquittement des messages ● Utilise une API propriétaire au MQ pour éviter – un bug comportemental provenant de la méthode acknowledge() Cast du javax.jms.Message en la classe – d'implémentation de Sun pour pouvoir appeler la méthode acknowledgeThisMessage() Évite l'acquittement de tous les messages y – compris de celui-ci!!! On ne veut en acquitter qu'un seul!!! –
  12. 12. Solution technique mise en oeuvre(6) Configuration du broker en détail ● Principe mis en oeuvre: – Faciliter l'ajout de noeuds dans la grappe ● Avoir des configurations similaires d'un broker ● à l'autre Noeuds iso-fonctionnels – Utilisation d'un fichier commun à tous les ● brokers et ajout des seules différences dans le fichier de config de chaque broker Utilisation d'un montage NFS/Samba ou – comme ici d'une zone d'échange VirtualBox
  13. 13. Solution technique mise en oeuvre(7) Configuration des brokers en détail ● Fichier d'un noeud de la grappe réduit au – strict minimum (ici noeud dénommé broker2) imq . b r o k e r i d=b r o k e r 2 – imq . i n s t a n c e c o n f i g . v e r s i o n =300 – imq . c l u s t e r . u r l= f i l e : / / / r o o t /mq_common . p r o p e r t i e s – –
  14. 14. Solution technique mise en oeuvre (8) Configuration du broker en détail ● Fichier commun – Fichier référencé depuis les brokers mis à – disposition sur un filesystem partagé Beaucoup de propriétés pas toutes – commentées.... Ici on va segmenter en blocs pour la lisibilité ●
  15. 15. Solution technique mise en oeuvre(9) Configuration du broker en détail ● Définition d'un seul et meme cluster – –
  16. 16. Solution technique mise en oeuvre(10) Configuration du broker en détail ● Définition du type de persistance – Ici utilisation d'une base de données Derby ● sur une machine virtuelle Virtuelle (Debian etch) nommée derbyserver et proposant un schéma de base nommé hadb imq . p e r s i s t . s t o r e=j d b c ● imq . p e r s i s t . j d b c . dbVendor=derby ● imq . p e r s i s t . j d b c . derby . d r i v e r=o r g . apache . derby . j d b c . C l i e n t D r i v e ● r imq . p e r s i s t . j d b c . derby . o p e n d b u r l=j d b c : derby : / / d b s e r v e r : 1 5 2 7 / ● hadb ; c r e a t e=t r u e ● ● –
  17. 17. Résultats obtenus Robustesse des brokers ● Aucun message perdu sur des tirs d'une dizaine – d'heure (centaine de milliers de messages) sur de petites configurations Image virtuelle simulant un proc 1Ghz avec ● 512Mo RAM dédiés Performance : environ 30 messages traités / ● seconde en pic Seule alerte : cas de passages répétés du GC en ● mode full Tuning de la JVM – Ou augmentation des ressources dédiées à la JVM –
  18. 18. Résultats obtenus(2) Robustesse: ● Pas eu le loisir de voir basculer les – indicateurs d'état de santé des brokers 3 niveaux implémentés dans OpenMQ ● Vert – Orange – Rouge – Censés définir des politiques de ● comportement des brokers Pas validé!!!! –
  19. 19. Résultats obtenus(3) Suite aux tests ● contact/mail avec l'équipe OpenMQ – Suivi d'un entretien avec Linda Schneider à – Paris Remarques prises en compte par l'équipe – OpenMQ et intégrées dans la roadmap du produit Bug empechant le load balancer fixé en 4.3 ● Gros travail en 4.3 sur le schéma de base ● Amélioration de la console d'administration en ● 4.5 (surtout pour le mode cluster)
  20. 20. Résultats obtenus(4) Avec la refonte architecturale induite par ● cette mission Création d'une réelle couche d'isolation vis à – vis du broker Injection de la configuration du broker au – démarrage du produit Création des destinations … ● Point souvent négligé !!!! – JMS n'a pas d'API normalisée dédiée à ● l'administration
  21. 21. Problèmes rencontrés Techniques: ● Non intégration en production avec Hermes – JMS (souci dans le nommage des propriétés des classes) Schéma de base et accesseurs aux bases – introduisant des locks !!! Fonctionnement en mode stress avec une – petite JVM Load balancer –
  22. 22. Problèmes rencontrés(2) Documentation du produit ● Quelques soucis d'alignement de version – Richesse des propriétés accessibles sur ce – produit 14 pages de properties!!!! ● Trouver les bonnes!!! ●
  23. 23. Conclusion Client satisfait ● Produit Open Source parfait pour les tests – Support pour passage en production possible – Robustesse est au rendez vous – OpenMQ ● Remontées techniques prises en compte et – accessibilité de l'équipe OpenMQ Produit fiable et maturité... – Roadmap avec une release tous les 3 mois!!! –
  24. 24. Conclusion(2) Bugs ● Assez peu – Pris en compte dans les versions ultérieures – ou fix packs si choix de rester en 4.2 Performance ● Nouveaux tests nécessaires à faire en 4.3 – car quelques soucis réglés avec cette version
  25. 25. Pointeurs https://mq.dev.java.net ● http://activemq.apache.org ● http://developers.sun.com/javadb/ ● http://java.sun.com/products/jms/docs.html ●
  26. 26. Annexes Extrait de code de la méthode onMessage() ● d'un client.... Initialisation du schéma de base de données ● et démarrage de Derby(aka javadb)
  27. 27. Extrait du code d'un client ● i f ( ! ( a r g 0 instanceof MessageObject ) ) { logger . error ( ● quot; Unable t o e x t r a c t MessageObject from message ! ! ! quot; ● ); ● } ● else { ● MessageObject o b j = ( MessageObject ) a r g 0 ; ● MessageTreatment t r e a t m e n t = ● this . b u s i n e s s P r o c e s s o r . createMessageTreatment ( obj ) ; ● treatment . treatMessage ( ) ; ● try { ● // HACK ! ! ! ●
  28. 28. Extrait du code d'un client ● // j u s t send ack t o t h e e x t r a c t e d message and not a l l // u n p r e v i o u s l y unACKNOWLEDGED ● // NEED a bad c a s t t o do t h a t ● com . sun . m e s s a g i n g . jms . Message msg= ● ( com . sun . m e ss a g i n g . jms . Message ) a r g 0 ; ● msg . acknowledgeThisMessage ( ) ; ● ● i f ( logger . isInfoEnabled ()){ l o g g e r . i n f o ( quot;Ok − acknowledge s e n t t o b r o k e r quot; + ● quot; − message w i l l be s u p p r e s s e d ! ! quot; ) ; } ● } catch ( JMSException ex ) { ● logger . error ( ● quot; something went wrong w h i l e s e n d i n g ACKquot; , ex ) ; ● } ● } // onMessage ( ) ●
  29. 29. Initialisation du schéma de la base de données Utilisation d'un outil dédié fourni par ● OpenMQ Opération réalisée depuis n'importe lequel – d'entre vos brokers (iso-fonctionnels) >imqdbmgr c r e a t e t b l – Va créer le schéma utilisé pour la persistance des messages et la – HA!!! Nécessite une base fonctionnant en réseau (cf doc Derby) – s t a r t N e t w o r k S e r v e r −h d b s e r v e r ●
  30. 30. Initialisation du schéma de la base de données(2) Modification du classpath des brokers pour contenir la ● librairie derbyclient.jar permettant de communiquer avec Derby!!! –
  31. 31. Questions? Elles sont bienvenues ● Mais vite on est en retard et Alexis va raler!!! – ● ● ● Merci de votre attention ●

×