Résilience cloud et coûts

Une architecture cloud hyper robuste coûte deux fois plus cher

Mettre en place une architecture cloud capable de résister à toutes sortes de pannes peut s'avérer coûteux. Dans une nouvelle étude, l'Uptime Institute compare plusieurs configurations permettant de renforcer la résilience d'une application cloud.

(Source: Jakub Jirsák - Fotolia)
(Source: Jakub Jirsák - Fotolia)

Les principaux fournisseurs cloud ont beau mettre en avant la robustesse de leurs infrastructures, ils ne sont toutefois pas totalement à l'abri des pannes. On se souvient par exemple de la panne technique de cinq heures qui avait touché AWS en décembre 2021, faisant flancher des milliers de sites et services web. L’incident remettait sur le devant de la scène la question des capacités de résilience des hyperscalers qui, selon les analyses de l'Uptime Institute, restent souvent obscures aux yeux des entreprises. Dans ce contexte, une nouvelle étude du consortium se penche sur le coût de la mise en place d’architectures cloud visant à réduire l’impact d’éventuelles pannes.

L'étude de l'Uptime Institute compare plusieurs architectures courantes (sur le cloud d’AWS) permettant de renforcer la résilience d'une application cloud (l’analyse concerne une application «stateless»), par rapport au scénario le moins robuste: une application tournant sur une seule machine virtuelle (VM).

VM dupliquée dans une même zone

Dans le cas où l’entreprise utilisatrice décide de répliquer ses charges de travail à l’aide d’une VM supplémentaire, dans une même zone, le coût augmente de 43% par rapport au scénario de base. Les frais supplémentaires viennent de la deuxième VM et de l’ajout d’un load balancer pour changer de VM en cas de défaillance de l’autre. A noter que la bande passante entre les ressources d'une même région est gratuite. Cette configuration apporte une résilience limitée si les deux VM sont hébergées par un serveur unique, notent les analystes de l'Uptime Institute.

Cette architecture peut comme les autres faire l’objet de compensation financière, mais modestes: si une VM tombe en panne, l'utilisateur ne sera remboursé que pour la défaillance de cette VM.

Plusieurs zones disponibilités

Il n'est pas plus coûteux de répartir le trafic sur plusieurs zones disponibilités plutôt que sur une seule, notent les analystes. En tant que PaaS, le load balancer est situé à travers les zones (standard dans AWS). Cette configuration, pour laquelle l'augmentation est donc à nouveau de 43% par rapport au scénario de base, présente l’avantage d’assurer une continuité de service en cas de défaillance de toute une zone.

Côté compensation, l'utilisateur peut être remboursé pour la défaillance de la machine virtuelle hébergée dans la zone touchée par une panne.

Répartir les charges entre plusieurs régions

L’architecture la plus résiliente consiste à mettre en place une protection à l’échelle de plusieurs régions cloud. Mais cette méthode est coûteuse, la plupart des fournisseurs ne proposant pas cette résilience nativement, leurs infrastructures n'étant pas prévues pour fonctionner entre différentes régions, souligne l'Uptime Institute. Par exemple, un load balancer est hébergé dans une région et est réparti sur plusieurs zones. Si une région tombe en panne, il devient indisponible. Il est dans ce cas nécessaire de reposer sur le système DNS pour acheminer les données entre les régions. Cette résilience de niveau élevé coûte plus de deux fois plus (+111%) qu'avec la configuration de base.

Les compensations financières potentielles sont en outre plus élevées que pour les autres configurations. Car si une région tombe en panne, l'équilibreur de charge et les deux VM sont indisponibles et sujets à compensation.

A noter que pour chaque configuration, l’augmentation de coûts mentionnée s'applique à une configuration avec deux VM actives. Il est possible de faire des économies en augmentant le temps de relance, en éteignant l’une des VM.

L’étude complète est disponible en téléchargement via cette page.

Webcode
DPF8_271055