Architecture

Bus d’entreprise – Architecture de production

Publié le : Auteur: Emmanuel Lesne Laisser un commentaire
bus d’entreprise

Un bus d’entreprise est maintenant un élément commun des systèmes d’information. Il permet de véhiculer les messages, les données et les commandes d’un système moderne. La conception et la réalisation de tels outils ne sont pas anodines et leurs indisponibilités ont un coût qu’il convient d’anticiper. Cet article liste les éléments clés à prendre en compte pour une exploitation sereine et maitrisée.

Les différents points abordés sont:

  • la sécurité. Que sécuriser et pourquoi ?
  • la disponibilité. Comment définir la disponibilité de l’ESB ?
  • la robustesse. Pourquoi et pour qui ?
  • l’analyse après incident. Que faut-il analyser ? que chercher ? comment trouver ?
  • le suivi des usages.

La sécurité et le bus d’entreprise

Le contrôle de l’intégrité des messages et l’identification des systèmes communiquant sont essentiels. La confiance doit régner entre les différents systèmes pour que les échanges soient efficaces. – Ceci dit, c’est aussi valable avec les hommes 😉 –

Il est donc indispensable :

  1. d’identifier les zones de confiance avec lesquelles le bus envoie et reçoit des messages. Les systèmes appartenant à ces zones sont à sécuriser de manière cohérente et uniformes.
  2. De définir des contrats de confiance avec les systèmes: Qui communique ? Quel type de message ? Comment le vérifier ?

Ces zones de confiances peuvent être des DMZ. L’organisation du réseau assure ainsi leurs étanchéités.

L’ESB est un élément qui manipule des messages et adapte les protocoles en fonction des contraintes et des capacités des communicants. Il porte la responsabilité d’ajouter la sécurité au niveau protocolaire comme le HTTP sécurisé, le JMS sécurisé, le S-FTP, etc.

Son fonctionnement en point d’accès unique le positionne comme un candidat idéal comme intermédiaire entre 2 zones de confiances internes et/ou externes. Il connait les interlocuteurs et les identifie par des mécanismes précis (IP autorisées, certificats SSL, login/mots de passe, etc).

L’addition de ces caractéristiques donne:

Diapositive1

La disponibilité de l’ESB

Pour évaluer la disponibilité, on utilise communément le taux de disponibilité. Il est exprimé en pourcentage de la forme 99.99… cf Wikipedia.

Personnellement, je n’apprécie pas cette évaluation par une moyenne. Qui souhaite que le métro s’arrête en pleine heure de sortie des bureaux ? Tout le monde a compris que l’impact n’est pas le même pour un arrêt à 5h du matin ou 17h30… même si la moyenne ne fait aucune différence 🙁 !

Bref, la disponibilité d’un système doit être mouvante et s’adapter aux usages.

Pour déterminer le niveau de disponibilité nécessaire pour l’ESB, il faut considérer la plus grande disponibilité parmi les participants (consommateurs et producteurs de services). Exemple:Diapositive2Il existe plusieurs moyens d’augmenter la disponibilité d’un système. Je distinguerais 2 grandes solutions pour la plage 6h/22 6j/7:

  1. Sans tolérance de coupure de services
  2. Avec tolérance de coupure de services < 5 min.

La plage horaire citée est déterminante car au-delà de celle proposée, les contraintes humaines pour la maintenance sont majeures. La taille de l’équipe explose pour gérer le support, les astreintes, les interventions les week-ends, etc.

D’autre part, mon expérience m’a démontrée que les clusters ne sont pas obligatoires lorsque l’on tolère une coupure de service minime. La duplication d’ESB en instances redondées et distribuées par des Load-Balancer (LB) suffit amplement.

Diapositive3Lorsque aucune coupure n’est tolérée, il faut sortir l’artillerie lourde avec des clusters applicatifs. La distribution des états, des files de messages et des caches garantit la non perte de messages lors de l’arrêt d’un des nœuds du système.

Malheureusement, l’utilisation de clusters engendre un impact majeure sur la maintenabilité: il se complexifie. Cependant, tôt ou tard il est nécessaire de l’arrêter pour appliquer des patchs ou des montées de versions. Je vous conseille donc de le dupliquer dans un 2nd cluster. La solution proposée est proche de la célèbre « bascule actif/actif ».

Diapositive4

Robustesse de l’ESB

Le bus d’entreprise doit servir toute l’entreprise, y compris les systèmes batchs, les sites institutionnels, les vitrines, les e-commerces, les gros systèmes, etc. Tous ces systèmes ont des rythmes très différents et ne peuvent pas être à l’unisson. Le rythme et la quantité des messages varient alors fortement.

La robustesse d’un ESB peut se résumer en quelques questions:

  1. Que doit faire le bus lors de la survenue d’une vague de messages (i.e. tsunami) ?
  2. Que doit faire le bus lorsqu’il produit lui-même une vague ? Par une agrégation de messages par exemple.
  3. Comment adapter le bus aux capacités de traitement des communicants ?
  4. Le bus peut-il survivre à une vague de message ?

Diapositive5Pour répondre à ces problématiques, 2 fonctionnalités majeures sont indispensables: la limitation des threads et le goulet d’étranglement (i.e. throttling). Leur association:

  • empêche les vagues de messages de submerger le bus
  • limite les envois du bus vers des fournisseurs de services
  • garantit que les ressources utilisées par les services ne superposent pas dans le bus

Au final, elles protègent le bus contre les comportements incontrôlables des interlocuteurs du bus. Le bus devient par là-même un élément stabilisateur et régulateur de la qualité de service des échanges du SI !

Diapositive6Pour information, certains Load-Balancer possèdent des fonctionnalités de paliers maximums. Cependant, les « bons » ESB 😀 ont la capacité de paramétrer cela pour chaque route en identifiant même des priorités différentes en cas de pointe.

 

Hôpital de messages

Je rappelle une évidence qui disparait trop souvent de la vue des architectes et des responsables techniques lors de la construction d’un middleware d’entreprise: « Le bus a pour objectif de véhiculer un message entre plusieurs interlocuteurs ». Au delà de l’adhérence et du couplage faibles, il facilite leurs échanges … qui ne sont pas toujours conformes. Les messages tombent alors en erreurs. Ces cas de figure arrivent toujours ! Alors s’il vous plait, pensez à vos équipes qui doivent ramasser les messages un à un, utilisez un hôpital de messages !

Un hôpital doit permettre:

  • de stocker les messages en erreur
  • la redirection des messages et des A/R à l’émetteur pour reprise ou prise en compte
  • la modification par lot et/ou manuelles des messages
  • la re-injection programmée

Diapositive7L’ « hôpital de messages » est essentiel dans la gestion des erreurs de traitement et de routage des messages.

 

Analyse des usages

Pour finir cet article, j’insisterai sur l’analyse des données manipulées par le bus. Il est important d’offrir des visions complémentaires aux acteurs du middleware: les équipes d’exploitation, les gestionnaires de projets et les responsables des contrats de service.

Plus précisément, ces acteurs doivent être en mesure de consulter et d’analyser:

  • les rapports de performance des services
  • les consommations de services pour leur facturation
  • les SLA contractualisés.

Pour cela un puits de données est idéal. Le stockage brut avec le contexte d’appel doit être réalisé. La granularité des informations est réduite au fil du temps afin de limiter la volumétrie (et supprimer les détails uniquement utiles pour les exploitants).

Les outils de reporting exploitent ensuite cette source de données pour les différents rapports des acteurs. Quant aux équipes de supports, elles manipulent les informations plus fines.

Diapositive8Le puit du middleware offre une réelle plus-value à l’exploitation des données transitées. La visibilité produite favorise la maitrise des échanges au sein du Système d’Information.

 

Synthèse

Voici en quelques phrases et schémas les bases d’une bonne architecture de production pour un bus d’entreprise. Vous éviterez ainsi des erreurs grossières lorsque vous porterez ce type de projets dans la « vie réelle ». Toutefois, si vous souhaitez être épaulé, les consultants d’Antéo-Consulting se feront un plaisir de vous y aider 😉 !