Face aux risques de pannes ou d'interruptions de services (comme le montre les récentes perturbations impactant Google), les entreprises veulent renforcer la résilience de leurs applications. Mais cela a un coût. Et celui-ci peut vite grimper en atteignant 111 % du prix initial comme l'indique une étude menée par Uptime Institute. Le surcoût peut se traduire par des temps de récupération plus rapides, une meilleure compensation sur les SLA et une amélioration de la « disponibilité implicite » (souvent basé sur un taux au-dessus de 99%). L'étude est basée sur les tarifs d'Amazon Web Services, cependant, « d'autres services de cloud public ont des modèles de tarification, des services et des principes architecturaux similaires. L'analyse de base s'applique donc à d'autres fournisseurs de cloud », précise Uptime.

Ce dernier a modélisé trois scénarios pour évaluer la résilience d'un simple site WordPress qui devait, lorsqu'il était au maximum de ses capacités, fournir des pages Web dans les trois secondes suivant les requêtes. Les analystes ont généré une simulation Python afin de varier les demandes de bande passante et de machines virtuelles dans le but d'analyser leurs effets sur les coûts.

Trois scénarios ont été testés

L'institut a donc examiné l'amélioration de la résilience de l'application WordPress dans trois architectures différentes : en fournissant une sauvegarde de la seule VM qui l'héberge dans la même zone de disponibilité. En fournissant une sauvegarde de la machine virtuelle dans une zone de disponibilité cloud distincte mais située dans la même région. Et enfin en proposant une sauvegarde dans des régions distinctes du fournisseur cloud. « Des ressources uniques, telles qu'une VM, sont susceptibles de ne plus répondre de temps en temps », indique le Uptime. « Il est également probable que des zones de disponibilité entières tombent en panne occasionnellement, rendant de nombreuses ressources non-réactives. Une panne régionale est plus rare, mais elle mettra hors service plusieurs zones de disponibilité. »

Le coût du service basique étudié, sans mesure de protection, comprenait les frais d'utilisation de la VM plus ceux de la bande passante sortante, soit 217,38 $ par mois. Si la machine virtuelle devait tomber en panne, sans sauvegarde, la durée de récupération serait déterminée par le temps qu'il faudrait au client pour la remplacer. « Bien qu'AWS affirme que son plan de contrôle des données pour cette architecture est conçu pour offrir une disponibilité de 99,95 %, il ne compensera que si elle tombe en dessous », précise l'enquête. Selon le calcul d'Uptime, l'indemnité pour une panne de plus d'un jour et demi serait de 29 % du coût mensuel de l'application.

Sauvegarde active d'une VM dans la même zone

L'utilisation d'une fonction de load balancing et la sauvegarde de la VM avec une autre machine virtuelle active et distincte dans la même zone de disponibilité donneraient la possibilité d'éviter toute interruption de service en cas de défaillance et d'obtenir la même disponibilité implicite de 99,95 %. La compensation pour les pannes qui durent plus d'un jour et demi passerait à 44 % du coût mensuel. Cependant, étant donné que cette architecture nécessite une VM supplémentaire et un équilibreur de charge, elle coûte également plus cher, 311 $, soit 43 % de plus que la solution initiale.

Sauvegarde active dans deux zones de la même région

Le backup de la machine virtuelle avec une autre VM active dans une zone de disponibilité différente au sein de la même région revient également 311 $ par mois. Cela ne coûte rien de plus de mettre la deuxième VM dans une zone séparée, mais la disponibilité implicite s'améliore à 99,99 %. Le temps de récupération ne diffère pas et le taux de compensation de 44 % demeure le même.

Sauvegarde active dans des régions distinctes

La mise en place de l'application dans deux régions différentes, hébergeant chacune deux instances actives de l'application, offre « sans doute la méthode la plus résiliente », selon l'étude. Dans ce modèle, il y aurait quatre machines virtuelles actives hébergeant l'application, réparties équitablement dans chaque région et accompagnées d'un équilibreur de charge dirigeant le trafic. « Ils assurent un équilibrage et une résilience simples en cas de panne d'une machine virtuelle ou d'une zone de disponibilité », précise l'enquête, « en externe, la panne ne serait même pas remarquée par un utilisateur ou ne devrait pas être gérée par ses équipements ». Le trafic géré par le load balancing serait dirigé par le DNS (Domain Name System). Ce dernier pourrait être configuré pour choisir le meilleur équilibrage de charge en fonction de sa proximité physique, du délai d'acheminement ou des politiques de pondération. Le DNS pourrait également effectuer des vérifications de santé pour détecter l'indisponibilité d'un équilibreur de charge et, dans ce cas, diriger le trafic vers un autre.

Bien que cette option soit la plus résiliente, elle a des inconvénients. « Le DNS en tant que système d'équilibrage est imparfait car les terminaux des utilisateurs qui accèdent à l'application web auront un enregistrement stocké de l'adresse IP de l'application. Si cette adresse devient indisponible, ces équipements seront incapables d'accéder à l'application jusqu'à ce qu'ils aient mis à jour leur cache local avec l'adresse IP du système DNS. » Les utilisateurs pourraient donc connaître une indisponibilité de durée incertaine en cas de panne. Dans ce scénario, la disponibilité implicite passe à 99,9999 %, et les coûts augmentent de 111 % par rapport à ceux de référence, pour atteindre 457,80 $. Selon Uptime, si l'une des régions tombe en panne, cela signifie qu'un équilibreur de charge et deux machines virtuelles sont indisponibles, ce qui donne droit au client à une compensation s'élevant à 62 % du coût du service si la situation persiste au-delà d'1,5 jour.

À noter, que les fournisseurs de services cloud offrent souvent la résilience à travers les zones de disponibilité comme une composante standard de beaucoup de leurs services, et celle-ci fournit une plus grande disponibilité à un coût relativement faible. Cependant, l'étude prévient, « les utilisateurs doivent être conscients que les designs qui semblent plus résilients peuvent offrir peu de garanties significatives concernant la disponibilité ou la compensation des pannes. ».