Aller au contenu principal

Stratégies – La journalisation en environnement IaaS, un mélange entre technique et justification économique

9 août 2014

Arnaud Alcabez

Dans les architectures de type Cloud Computing, à la différence de l’informatique traditionnelle, stocker des journaux de transaction (ou logs an anglais) doit être vu comme une ligne budgétaire. Si vous considérez que chaque traitement en Cloud Computing consomme des ressources et donc est un centre de coût pour votre modèle, il est nécessaire de penser « quelle valeur financière à le log en tant que ligne de service ? ».

L’informatique dans les nuages diffère de l’hébergement traditionnel par de nombreux aspects. Concentrons-nous sur deux éléments fondamentaux de ce type d’environnement :

  • La facturation à la consommation. Contrairement aux architectures classiques, il n’existe que de rares limites techniques, comme par exemple en termes de capacité disque. Néanmoins, chaque traitement doit être considéré comme une somme de consommation de ressources : Volume de transaction réalisé, puissance de calcul nécessaire pour réaliser cette transaction, et enfin, le stockage utilisé pour mémoriser cette transaction.
  • L’élasticité. Dans une architecture traditionnelle, on pense à l’unité, c’est-à-dire au niveau d’un serveur. Ainsi, nous avons tous appris à gérer notre infrastructure en donnant des nomenclatures précises à des serveurs pour leur nom, mais aussi de gérer des plans d’adressage IP où chaque machine est connue sur le réseau et identifiée par un certain nombre de références. Dans les architectures de type Cloud Computing, nous sommes amenés à penser en termes de flotte (ou fleet en anglais) d’instances afin de réaliser une opération. Par exemple, pour une fonction telle que un serveur Web frontal, nous définissons une valeur minimum d’instances, une valeur maximum d’instances et une valeur privilégiée d’instances. En fonction de la charge ou des instances endommagées, le service d’élasticité adaptera automatiquement le nombre d’instances afin qu’elle soit cohérente par rapport à l’activité. Ce principe fait qu’il devient inutile de réfléchir à donner des noms précis à chaque serveur, ou même d’attacher une importance particulière à savoir quelle adresse IP est actuellement utilisée par quelle instance à un instant T du traitement.

Dans des architectures de type Cloud Computing, on considère que chaque instance peut être jetable, en particulier lorsqu’on construit des services applicatifs, soit pour des raisons de montée ou de réduction de charge, soit parce que l’instance peut être corrompue et ne plus fonctionner de manière opérationnelle. Cependant, les données des journaux de transactions du système ou de l’application doivent généralement être conservés, même après que l’instance soit supprimée automatiquement ou manuellement, soit pour des questions d’analyse, soit pour des raisons de conformité. Pour cela, les données des journaux de transactions doivent être stockées en dehors des instances elles-mêmes.

Trois architectures principales permettent de concevoir un modèle de gestion des journaux dans une architecture de type Cloud Computing.

1ère possibilité : Rotation individuelle des journaux de transactions sur un espace de stockage

etape1Le principe de ce premier modèle est des plus simples : chaque instance écrit régulièrement ses transactions dans un espace de stockage commun et partagé pour les valider et les considérer comme réalisées.

Ce modèle est particulièrement avantageux car son coût de mise en œuvre est simple. Toutefois, si une instance s’arrête de manière non programmée, les dernières transactions de l’instance seront perdues, ce qui peut être un risque acceptable dans certaines circonstances, mais pas dans d’autres. D’autre part, il n’y a pas particulièrement d’agrégation des journaux entre les instances, ce qui risque d’être compliqué pour avoir une lecture simplifiée des journaux de transaction en cas de recherche ultérieure.

2ème possibilité : Centralisation des journaux avec une rotation sur un espace de stockage

etape 2Ce deuxième scénario permet de pouvoir envoyer les journaux sur une instance, qui effectuera les opérations de consolidation avant de stocker les données résultantes sur un espace de stockage réservé à cet effet. Le problème de ce modèle est qu’il n’est pas élastique au sens où il est très dépendant du nombre d’instances exécutées. Ces dernières pourraient engendrer une contrainte de charge sur l’instance de consolidation que ce soit en ce qui concerne la bande passante, la puissance de calcul nécessaire ou l’espace disque utilisé pour travailler sur les journaux. Enfin pour terminer, si l’instance supplémentaire est défaillante, la perte d’une partie des journaux aura plus d’impact que dans le schéma précédent, à partir du moment où ce sont l’ensemble des journaux de toutes les instances en attente d’écriture qui sera perdu d’un seul coup.

3ème possibilité : Architecture distribuée de collecte et de gestion des journaux

etape3Pour avoir une architecture de gestion des journaux en conformité avec une application élastique, nous nous devons de la construire à l’image de l’application elle-même. Dans le schéma ci-dessus, plusieurs changements ont été apportés.

Le premier consiste à utiliser un service de gestion de queue pour les messages et d’éviter les appels directs entre les serveurs. Bien connu des développeurs, cette technologie permet à des applications exécutées à des moments différents de communiquer à travers des réseaux et des systèmes hétérogènes, même s’ils sont temporairement déconnectés. Elle fournit une livraison des messages garantie, un routage efficace, une sécurité et une messagerie basée sur la priorité. Ainsi, elle garantit que les transactions seront correctement expédiées dans la queue pour traitement, même si l’instance n’est plus en ligne.

Le second consiste à séparer les services pour que les instances soient toujours dédiées à une tâche simple et unique. Ainsi, la collecte des journaux ne demande pas faire recours à des unités de calcul. Les collecteurs sont donc très simples, redondants et peuvent être exécutés sur des machines à faible consommation. Le collecteur se charge de récolter l’ensemble des journaux émis par les instances, puis de les transférer pour consolidation dans une autre queue prévue à cet effet.

Enfin, les instances de calcul pour consolider les journaux peuvent faire l’usage de leur puissance pour agglomérer et indexer les événements récoltés par les collecteurs avant de les enregistrer sur un espace de stockage consolidé. Notez que les instances de calcul sont elles-mêmes dans un groupe de montée en charge dynamique afin que leur nombre soit adapté automatiquement en fonction du nombre de transactions à traiter.

4ème possibilité : Dénicher l’outil tiers magique

Bien entendu, il existe certainement de nombreux outils tiers permettant de collecter et de consolider des journaux pour des architectures de type Cloud Computing. Toutefois, vous retomberez sur plusieurs problématiques : le surcoût de la solution, le fait que ces technologies fonctionnent généralement sur la base d’un couplage fort avec les instances qu’elles gèrent (le couplage fort des composants étant antinomique avec la notion même du Cloud Computing) et tous les problèmes que vous pourriez rencontrer sur le fait d’exécuter du code d’un tiers sur votre application ou l’aptitude de la solution à perdurer dans le temps avec votre application.

En résumé

Les architectures de type Cloud Computing diffèrent des architectures traditionnelles. La facturation à la consommation des services et l’aspect élastique des solutions font que la conservation des journaux de transactions, soit pour des raisons de contrôle, soit pour des raisons de conformité, doit faire l’objet d’une étude économique.

Ainsi, il est important tout d’abord de comprendre la valeur financière d’un journal des transactions : Quelle charge de travail et de stockage pour quel intérêt business ? Enregistrer des centaines de transactions par seconde n’a pas de réelle utilité si ce n’est pas pour les exploiter ultérieurement, soit au titre de la preuve, soit au titre de l’analyse post-traitement.

C’est la valorisation des journaux de transactions qui permettra de déterminer l’architecture la plus adéquate (d’un service simple et à faible coût supplémentaire à un service hautement disponible, fiable et flexible, et géo-redondant). Une application pouvant très bien faire appel à plusieurs architectures selon la nature de la transaction : Un journal d’opérations techniques  par rapport à un journal des commandes passées par des clients n’aura sans doute pas droit à la même attention.

Une fois votre architecture construite, il ne vous restera plus qu’à appliquer le coût du service de journalisation comme une quote-part du coût global du service à vos clients, et voilà…

Pour IT Pro Magazine, 2014

Les commentaires sont fermés.

%d blogueurs aiment cette page :