Haute-Disponibilite

Après avoir analysé les avantages de la communication par message pour l’envoi d’email massif et pour décharger le nombre de thread sur un serveur web, nous allons aujourd’hui nous intéresser à la répartition de charge.

Dans les cas ou plusieurs clients peuvent demander un traitement particulier la communication par message est souvent intéressante. En effet elle permet de découpler les demandes des clients et les traitements par les serveurs. Les services web peuvent être répartis facilement grâce à un load balancer HTTP, mais dans certains cas les traitements à effectuer sont plus importants que le simple calcul d’une page. Il est alors beaucoup plus intéressant de passer par une liste de tâches partagées par les clients et les serveurs.

Cette méthode permet en plus de mettre en place une gestion de priorité en donnant une importance particulière à certaines tâches, ou à certains clients. De la même manière en qualifiant correctement les traitements il sera facile de mettre en place des serveurs dédiés à certains processus.

Cette isolation entre les demandes et les traitements permet de gérer les traitements d’une manière beaucoup plus fine, en outre l’ajout de serveur dans la boucle pourra se faire de manière totalement dynamique sans aucun changement dans le code. Et contrairement aux architectures nécessitant un load balancer physique, une communication par file peut être mise en place dès le début de l’implémentation, elle se révélera par la suite une excellente solution pour partitionner votre architecture.

La plupart des des architectures proposent des solutions de ce type, Amazon propose par exemple depuis longtemps une solutions de ‘messaging on demand‘  spécialement dédiée à ce type de tache.

Voilà, j’espère que ces trois petits articles sur les architectures asynchrones vous permettrons de mettre en place ce type de solution de façon adéquate. Et croyez moi, les intégrer dès le début de votre implémentation vous facilitera grandement la tâche lorsque vous serez en train de gérer la croissance de votre service.

Comme d’habitude vos retours et questions, par mail ou commentaires sont les bienvenus.

Sources :

• http://middlewares.wordpress.com/2008/02/01/messaging-and-queuing-the-mom-middleware/
• http://gojko.net/2009/01/06/messaging-is-not-just-for-investment-banks/
• http://docs.sun.com/app/docs/doc/819-7759/aerap?a=view

Sur le même thème :

• No more servers et la progression du Cloud chez Amazon
• Communiquer via une file d’attente de message [2/3]
• Communiquer via une file d’attente de message [1/3]

This entry was posted on January 31, 2009 at 12:15 am and is filed under Architecture, Développement, optimisation. Tagged: Amazon SQS, MOM, Queue Service. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.