Windows Azure : Architecture des coûts pour Windows Azure
La conception d'applications et de solutions pour l'informatique en nuage et Windows Azure nécessite une manière complètement différente de considérer les coûts d'exploitation.
Maarten Balliauw
L'informatique en nuage et les plateformes comme Windows Azure représentent le « prochain tournant » de l'informatique. Et cela est sûrement vrai quand on réfléchit à la myriade d'avantages présentés par l'informatique en nuage.
L'informatique et le stockage deviennent une question de besoin utilisable à tout moment, en payant uniquement ce que vous utilisez effectivement. Cela pose cependant un problème. Si une application en nuage est conçue comme une application normale, il est fort probable que les perspectives de coût de l'application ne soient pas celles attendues.
Des mesures différentes
Dans l'informatique traditionnelle, l'utilisateur achète un ensemble de matériels (infrastructure réseau, serveurs, etc.), l'installe, le configure et le connecte à Internet. Il s'agit d'un investissement unique, avec un employé qui tourne les boutons et les boulons et c'est fini.
Avec l'informatique en nuage, ce modèle d'investissement est remplacé par un modèle de coûts. Vous payez des ressources comme la puissance des serveurs et le stockage en fonction de leur utilisation effective. Avec une plateforme en nuage comme Windows Azure, ce sont les mesures suivantes qui vont calculer votre facture mensuelle :
- Le nombre d'heures où vous avez réservé une machine virtuelle (VM), ce qui signifie que vous payez une application déployée, même si celle-ci n'est pas en cours d'exécution
- Le nombre de processeurs dans une VM
- La bande passante, mesurée par Go entrant/sortant
- La quantité de Go de stockage utilisés
- Le nombre de transactions en stockage
- La taille de base de données sur SQL Azure
- Le nombre de connexions sur la plateforme Windows Azure AppFabric
Vous trouverez tous les détails de tarification sur le site Web de Windows Azure à l'adresse microsoft.com/windowsazure/offers. Comme vous pouvez le voir dans cette liste, il y a beaucoup d'éléments à prendre en compte.
Limitation des machines virtuelles
D'un point de vue pratique, voici comment la division s'opère. Même si limiter la quantité de VM en cours d'exécution est un bon moyen de réduire les coûts, pour les rôles Web, il est bon de disposer d'au moins deux VM disponibles pour l'équilibrage des charges. L'API Windows Azure Diagnostics permet de mesurer l'utilisation des processeurs, le nombre de requêtes HTTP et l'utilisation de la mémoire dans ces instances. Elle permet également de réduire votre application si approprié.
Chaque instance d'un rôle, quel qu'il soit, s'exécutant sur Windows Azure mensuellement, double le nombre d'heures de la facture. Par exemple, l'exécution de trois instances de rôle en moyenne (parfois deux, parfois quatre) sera 25 % moins chère que d'exécuter quatre instances en permanence avec une charge de travail pratiquement nulle.
Pour les rôles de travail, il est également bon de disposer d'au moins deux instances de rôle pour effectuer le traitement en arrière-plan. Vous pouvez ainsi garantir que l'application reste disponible si une instance est arrêtée pour être mise à jour ou si un redémarrage de rôle se produit. À l'aide de l'outillage disponible pour Windows Azure, vous pouvez configurer un rôle de travail prêt à l'emploi destiné à une seule tâche.
Si par exemple, vous exécutez un site Web de partage de photos, vous aurez besoin d'un rôle de travail pour redimensionner les images et d'un autre pour l'envoi des notifications par courrier électronique. La règle « au moins deux instances » signifie l'exécution de quatre instances de rôle de travail, avec pour résultat une facture pouvant être dimensionnée. Le redimensionnement d'images et l'envoi d'e-mails ne nécessitent pas vraiment une telle puissance de processeur, deux rôles de travail pour ces deux tâches devraient donc suffire. Il s'agit d'une économie de 50 % sur la facture mensuelle d'exécution de Windows Azure. Il est aussi assez simple d'implémenter un mécanisme de threading dans un rôle de travail où chaque thread effectue sa part de travail dédiée.
Windows Azure propose quatre tailles de VM : petite, moyenne, grande et très grande. Les différences entre chaque taille résident dans le nombre de processeurs disponibles, la quantité de mémoire et de stockage local disponibles, ainsi que dans les performances E/S. Avant de passer au déploiement réel sur Windows Azure, mieux vaut réfléchir à la taille appropriée de la VM. Une fois l'application en cours d'exécution, vous ne pouvez pas la modifier.
Lorsque vous recevez votre relevé mensuel, vous remarquez que toutes les heures de calcul sont converties en heures de petites instances. Par exemple, une heure d'instance de calcul moyenne serait présentée sous la forme de deux heures de petite instance de calcul, au prix de la petite instance. Si vous exécutez deux instances moyennes, vous serez facturé 720 heures x 2 x 2.
Cet élément est à prendre en compte lors du dimensionnement de vos VM. Vous pouvez obtenir pratiquement la même puissance de calcul à l'aide des petites instances. Imaginons que vous en ayez quatre, facturées 720 heures x 4. Le prix est le même. Vous pouvez réduire à deux instances si nécessaire, ce qui vous ramène à 720 heures x 2. Si vous n'avez pas besoin de plus de processeurs, de mémoire ou de stockage, utilisez seulement des petites instances car leur évolutivité est plus précise que les instances de plus grande taille.
La facturation des services Windows Azure débute dès lors que vous avez déployé une application et elle se produit, que les instances de rôle soient actives ou non. Vous pouvez facilement consulter ces informations sur le portail Windows Azure. Vous y trouverez une grande image d'une boîte. « When the box is gray, you’re OK. When the box is blue, a bill is due. » (Quand la boîte est grise, ce n'est que partie remise. Quand la boîte est bleue, un paiement a lieu.) (et merci à Brian H. Prince pour cette trouvaille.)
Lorsque vous déployez des applications pour les tester ou les produire et que vous les désactivez après utilisation, n'oubliez pas d'annuler également le déploiement de l'application. Vous ne voulez pas payer des applications inactives. Pensez également à réduire l'application lorsque cela est approprié. Cela a un effet direct sur les coûts opérationnels mensuels.
Lorsque vous augmentez ou réduisez votre application, le mieux est d'exécuter une instance de rôle pendant au moins une heure, puisque vous payez à l'heure. Faites tourner plusieurs thread de travail d'un rôle de travail. De cette manière, ce rôle de travail peut effectuer plusieurs tâches au lieu de simplement une seule. Si vous n'avez pas besoin de plus de processeurs, de mémoire ou de stockage, utilisez seulement de petites instances. Mais, une nouvelle fois, pensez à annuler le déploiement de vos applications quand vous ne les utilisez pas.
Bande passante, stockage et transactions
La bande passante et les transactions sont deux mesures difficiles. Il n'existe actuellement pas de manière efficace de les mesurer, sauf en regardant sa facture mensuelle. Il n'existe pas de surveillance en temps réel à consulter et utiliser pour adapter votre application. De ces deux éléments, la bande passante est la plus facile à mesurer. Plus vous réduisez le trafic sur le système, plus le coût sera faible. C'est aussi simple que cela.
Les choses se compliquent lorsque vous déployez des applications sur plusieurs régions Windows Azure. Imaginons que vous ayez un rôle Web exécuté dans la région « Amérique du Nord » et un compte de stockage dans la région « Europe de l'Ouest ». Dans ce case, la bande passante de communication entre le rôle Web et le stockage sera facturée.
Si ce rôle Web et le stockage étaient situés dans la même région (par exemple, tous les deux en « Amérique du Nord »), il n'y aurait pas de facture de bande passante de communication à émettre. Gardez bien à l'esprit qu'il est bon de garder des services couplés dans la même région Windows Azure lorsque vous concevez des applications réparties géographiquement.
Lorsque vous utilisez le réseau de distribution de contenu Windows Azure (Content Delivery Network, CDN), vous pouvez profiter d'une mesure supplémentaire et intéressante de réduction des coûts. Le CDN est mesuré de la même façon qu'un stockage BLOB, c'est-à-dire par Go stockés par mois. Une fois une requête initiée vers le CDN, celui-ci prend le contenu d'origine sur le stockage BLOB (notamment la consommation en bande passante, facturée donc) et le met dans une mémoire cache locale.
Si vous définissez des en-têtes d'expiration de cache trop courts, ils consommeront plus de bande passante car le cache du CDN se mettra à jour plus souvent. Lorsque l'expiration du cache est trop longue, Windows Azure stocke du contenu dans le CDN plus longtemps. Or la facture est par Go stockés par mois. Pensez-y pour chaque application afin de déterminer le meilleur temps d'expiration du cache.
Windows Azure Diagnostics Monitor utilise également le stockage BLOB pour les données de diagnostic tels que les compteurs de performance, les journaux de suivi, d'événements, etc. Il écrit ces données sur votre application à un intervalle prédéfini. Une écriture toutes les minutes va augmenter le nombre de transactions à stocker et entraîner des coûts supplémentaires. Définissez-le à un intervalle (toutes les 15 minutes, par exemple) pour obtenir moins de transactions de stockage. L'inconvénient, cela dit, est que les données de diagnostic sont toujours au moins vieilles de 15 minutes.
De plus, Windows Azure Diagnostics Monitor ne nettoie pas ses données. Si vous ne le faites pas vous-même, il se peut que soyez facturé pour du stockage dont la majeure partie ne serait constituée que de données de diagnostic anciennes et expirées.
Les transactions sont facturées par 10 000. Cela peut vous sembler élevé mais vous constaterez que, dans la réalité, vous les atteindrez. Chaque opération d'un compte de stockage est une transaction. Créer un conteneur BLOB, dresser la liste des contenus d'un conteneur BLOB, stocker des données dans une table sur un stockage de tables, consulter les messages d'une file d'attente. Tous ces éléments sont des transactions. Lorsque vous effectuez une opération telle que du stockage BLOB, par exemple, vous commencez par vérifier que le conteneur BLOB existe. S'il n'existe pas, vous devez le créer puis stocker un BLOB. Ceci représente au moins deux, voire trois, transactions.
La même chose vaut pour l'hébergement de contenu statique sur le stockage BLOB. Si votre site Web héberge 40 petites images sur une page, cela signifie 40 transactions. Elles peuvent s'accumuler rapidement sur les applications à grand trafic. Pour réduire le nombre de transactions de pratiquement 50 %, il suffit de s'assurer qu'un conteneur BLOB existe au démarrage de l'application puis de ne plus effectuer cette vérification à chaque opération suivante. En faisant attention à cela, vous pourrez réduire votre facture.
Les index peuvent être coûteux
SQL Azure est un produit intéressant. Vous pouvez disposer d'une base de données de 1 Go, 5 Go, 10 Go, 20 Go, 30 Go, 40 Go ou 50 Go à un prix mensuel extrêmement bas. Opter tout d'abord pour une base de données SQL Azure de 5 Go est sûr et suffisant. Cela dit, si vous n'utilisez que 2 Go de cette capacité, il ne s'agit plus vraiment d'un modèle de paiement à l'utilisation, n'est-ce pas ?
Dans certaines situations, il peut être plus rentable de répartir vos données sur diverses bases de données SQL Azure plutôt que sur une grande base de données. Par exemple, vous pouvez avoir une base de données de 5 Go et une de 10 Go, plutôt qu'une base de données de 20 Go dont 5 Go sont inutilisés. Ce type de stockage stratégique aura un impact sur votre facture si vous vous en servez intelligemment et si cela fonctionne avec votre type de données.
Chaque objet occupe de l'espace de stockage. Les index et les tables peuvent en consommer une grande partie, sur une base de données. Des tables de grande taille peuvent occuper 10 % d'une base de données et certains index peuvent en consommer 0,5 %.
Si vous divisez le coût mensuel de votre abonnement SQL Azure par la taille de la base de données, vous obtiendrez une unité de coût par stockage. Pensez aux objets qui composent votre base de données. Si l'index X vous coûte 50 cents par mois et qu'il ne vous permet pas d'obtenir un gain de performances vraiment important, ne le conservez pas. La moitié d'un dollar, ce n'est pas grand-chose, mais si vous éliminez certaines tables et certains index, cela peut finir par représenter une certaine somme. Sur le blog de l'équipe SQL Azure, vous trouverez un exemple intéressant sur la publication « The Real Cost of Indexes » (Le véritable coût des index) à l'adresse blogs.msdn.com/b/sqlazure/archive/2010/08/19/10051969.aspx.
Dans le monde du développement d'applications, il existe un mouvement fort pour ne plus utiliser de procédures stockées dans une base de données. La tendance vise au contraire à utiliser les mappeurs relationnels objets et à effectuer de nombreux calculs sur les données de la logique d'application.
Il n'y a aucun mal à cela, mais cela devient intéressant lorsque vous pensez à Windows Azure et SQL Azure. Réaliser des calculs de données dans l'application peut nécessiter des instances supplémentaires de rôles Web ou de rôles de travail. Si vous déplacez ces calculs sur SQL Azure, vous faites l'économie d'une instance de rôle, dans cette situation. Les mesures SQL Azure étant effectuées sur le stockage et non sur l'utilisation des processeurs, vous obtenez véritablement des cycles de processeurs gratuits dans votre base de données.
L'impact du développeur
Le développeur qui rédige le code peut avoir un impact direct sur les coûts. Par exemple, lorsqu'il crée un site Web ASP.NET hébergé par Windows Azure, il peut faire sa répartition sur les instances de rôles à l'aide du fournisseur d'état de session soutenu par le stockage de Windows Azure. Ce fournisseur stocke les données de session dans le service de tables Windows Azure où la quantité de stockage, de bande passante utilisée et le décompte des transactions sont mesurés pour être facturés. Examinons l'extrait de code suivant, utilisé pour connaître la langue d'un utilisateur sur chaque requête :
if (Session["culture"].ToString() == "en-US") {
// .. set to English ...
}
if (Session["culture"].ToString() == "nl-BE") {
// .. set to Dutch ...
}
Rien ne vous choque ? Techniquement, c'est normal. Mais vous pouvez l'optimiser de 50 % d'un point de vue des coûts :
string culture = Session["culture"].ToString();
if (culture == "en-US") {
// .. set to English ...
}
if (culture == "nl-BE") {
// .. set to Dutch ...
}
Les deux extraits font exactement la même chose. Le premier lit les données de la session deux fois, tandis que le second ne les lit qu'une seule fois. Cela se traduit par une économie de 50 % sur les coûts dans le décompte de la bande passante et des transactions. Il en va de même pour les files d'attente. La lecture d'un message à la fois à 20 reprises sera plus chère que la lecture de 20 messages à la fois.
Comme vous pouvez le voir, l'informatique en nuage introduit des détails différents en termes d'économie et de tarification pour l'hébergement d'une application. Même si l'informatique en nuage peut représenter une grande amélioration en termes de coûts d'exploitation vis-à-vis d'un centre de données traditionnel, vous devez faire attention à certaines considérations dans l'architecture de l'application lorsque vous concevez pour le nuage.
.jpg)
Maarten Balliauwest consultant technique pour les technologies Web chez RealDolmen, une des plus importantes entreprises ICT de Belgique. Il s'intéresse au MVC ASP.NET, PHP et Windows Azure. C'est un spécialiste ASP.NET de Microsoft qui a publié de nombreux articles à la fois pour la littérature PHP et .NET, comme MSDN Magazine, Belgium et PHP Architect. M. Balliauw intervient fréquemment dans les conférences d'événements divers, nationaux comme internationaux. Vous pouvez consulter son blog à l'adresse suivante : blog.maartenballiauw.be.