1. Continuous
(Cloud) Costs Testing
10h40 - 11h30 - Salle E. Fitzgerald & L. Armstrong
2. Continuous Cloud Costs Testing
Nicolas Fonrose
Teevity Cloud Costs Analytics – Founder / CEO
@nfonrose / @teevity
27 au 29 mars 2013
3. Nicolas Fonrose
• Cloud geek, Startuper
• Pas mal d’années employé d’une boîte de conseil IT. Deux petites
boites de conseil, créées ensuite.
• Et ensuite, « l’aventure startup » J
• Teevity Cloud Costs Analytics
• Objectif – aider les boites à utiliser le Cloud sans avoir à se soucier des
complexités liées aux coûts (variables et complexes à optimiser)
• Fonctionne sur AWS/AppEngine/Google BigQuery
4. (Petit) lexique du cloud
• Instance (une VM)
• Zone (approx. == datacenter)
• Region (1 ensemble de 2 à 5 zones dans une partie du monde)
• Europe, Asie, US-east, US-west
• Web-storage (S3, Google Cloud Storage, Azure Blob Storage)
6. Les grilles de prix sont publiques
Une grille de prix Cloud, ça
ressemble à quoi ?
Pas assez de place sur un slide pour montrer celle d’AWS. Loin s’en faut !
Des 10k de lignes de JSON juste pour les prix AWS !
7. Estimation
Tout bouge. Et tout le temps
!
La grille de prix varie (très souvent – compétition entre CSP)
Des nouveaux services apparaissent
De nouveaux concepts tarifaires apparaissent
Le comportement du service fourni par le CSP varie
9. Quand la théorie devient réalité …
Violent changement de prix
pour AppEngine en 2011
Largement expliqué et justifié par Google, mais ça fait mal quand même !
Certains utilisateurs ont vu leur facture faire *20. Il a fallu sacrément optimiser
10. Des fois, de très bonnes nouvelles
AWS S3 price change (-15%, merci Google)
AWS Glacier (10* moins cher; enfin presque)
AWS DynamoDB price change (-85% !)
Super nouvelles ! Mais aussi des hypothèses à revoir !
11. D’autre fois, des moins bonnes
Une région AWS, ça crache
Et en entier (toutes les AZ)
On doit faire du multi-région pour avoir une très haute disponibilité
12. Des services qui changent
Le DataStore AppEngine
passe en HDR
Hello « eventual consistency » on reads
Impact sur l’architecture de certaines applications
13. Des « non-conformités »
Heroku / RapGenius
Class action lancée contre Heroku
!
Non seulement pas bon pour les porte-monnaies des clients Heroku
Mais mauvais de manière générale pour le PaaS
14. Cloud Costs Savings Tips
LES 4 CATÉGORIES
Architectes, Développeurs, Devops, vos actions ont
un impact important sur le coût !
27 au 29 mars 2013
17. Architecture logicielle
L’élément le plus important !
Impossible de profiter des options qui
rendent « cost-efficient » vos applications
sans une architecture logicielle adaptée
18. Les clés du « cost driven » - 1/2
Modularité
Séparer les problématiques
Pour pouvoir allouer les différents traitements à l’endroit le plus pertinent
19. Les clés du « cost driven » - 2/2
Elastic-driven
Instances == Resources (!= Serveurs)
Compatibilité de l’architecture avec l’apparition/disparition (violente) de hardware
20. Et le « hardware »
Le choix du « Hardware » (virtuel)
est bien sûr toujours important
Mais c’est le software qui prend le lead. Le Hardware est juste là pour servir les besoins du soft.
Et on peut maintenant changer de « Hardware » comme on change de chemise.
21. Cost-driven architectures (et auto-scaling driven architectures)
ARCHITECTURES CLOUD-COSTS
EFFICIENTS : DES EXEMPLES !
23. Ex 1 - Site Web sans aucun serveur !
Site Web entièrement hébergés
sur un Web-Storage
JS côté Client /
Des batch qui updatent le contenu (lancés
périodiquement) /
Discuss pour les commentaires
24. Ex 1 - Site Web sans aucun serveur !
Le DNS masque totalement le Web storage
Compatible avec les CDN
Aussi applicable à certaines API de ces sites Web
26. Ex 2 - Application SaaS au régime
Une application SaaS avec
beaucoup de requêtes en
lecture par les clients
Application Web/Destkop/Mobile
27. Ex 2 - Application SaaS au régime
Régime minceur
On pousse des copies des données
statiques vers un Web store
Adapter le rythme en fonction de la nature de l’application
28. Ex 2 - Application SaaS au régime
Compute
Instances
on
update
Web Storage
Integrated
web servers
29. Ex 2 - Application SaaS au régime
Ça marche aussi pas mal pour
tout ou partie d’applications « métier »
plus classiques (pas que pour les Dropbox like)
Ca dépend de leur nature transactionnelle,
et de la durée acceptable des copies de données côté client
Raisonnement applicable aux API
30. Ex 2 - Et la sécurité ?
Comment on gère les
autorisations d’accès ?
S3 Bucket Policy / adresse IP cliente ? Bof … L
S3 Bucket Policy / headers HTTP ? Mieux J
Auto-signed URLs ? Fabuleux J
31. Ex 2 - Et la sécurité ?
Auth
+
GET signed URL Compute
Instances
on
update
Web Storage
Integrated
web servers
32. Ex 2 – Cadeau «bonux» orienté Média
Amazon S3 supporte Bittorrent !
Permet de fortement réduire la facture si beaucoup
de personnes chargent les mêmes données
Streaming de musique par exemple
36. Ex 3 - Application SaaS et upload
Donc là aussi, zéro serveur (ou presque),
c’est possible. Et c’est même mieux (sécurité,
scalabilité, …) !
Il faut quand même souvent des serveurs en batch
pour traiter le contenu en asynchrone
40. Ex 4 – Traitements asynchrones
Beaucoup de traitements
asynchrones lourds ?
Des batchs classiques
Du processing de photos (vignettes)
De l’analyse de données (big data)
42. Ex 4 – Traitements asynchrones
Actions périodiques ?
Même pas besoin de laisser tourner une
instance avec un CRON !
On peut définir des « scheduled-actions » directement dans AWS (CRON interne)
43. Architecture logicielle et coûts cloud
Un contre-exemple maintenant !
Malgré l’architecture, dans certains cas, on
peut quand même arriver à tourner « cheap »
44. Ex 5 – Le contre-exemple
« Web-cache / CDN » en frontal
Fonctionne aussi pour les applications
(quelque soit leur architecture)
Evidemment pas applicable à toutes les applications (nécessite Web+REST). Ne marche que
pour les Reads, pas pour les Writes (pour l’instant)
Solution externe à l’application : le cache peut être chez un fournisseur (AWS) et
l’application chez un autre (AppEngine) !
47. Ne pas « pétrifier » son infrastructure
Création infra cloud « à la main »
== infra cloud statique
Ça prend du temps, sujet aux erreurs. Donc on la modifie rarement.
48. Fluide comme du code
Scripting == infrastructure fluide
Infrastructure As Code
Tester une nouvelle configuration d’infrastructure ==
Changer des paramètres dans des fichiers de conf / scripts
Vous êtes libre d’expérimenter car « pas risqué » et « rapide »
49. Facilite le changement de CSP
Important y compris pour pouvoir
changer/tester d’autres CSP
Scripting avec une meta API (Scalr/RightScale par exemple) pour pouvoir
porter sur un autre fournisseur très rapidement (AWS - GCE)
50. Corrélations « action-to-cost »
Intégration des actions sur
l’infrastructure dans la boucle de
cost-feedback
Systématise la traçabilité des changements de configuration d’infra
Permet de faire des corrélations entre changements
dans l’infrastructure et impact sur les coûts
52. « Right-sizer »
Ne pas allouer plus que
ce dont on a besoin
Ça paraît évident …
Et pourtant, la source d’économie la plus grosse constatée chez les utilisateurs IaaS.
Les freins au right-sizing ? Architecture non elastic-driven / Infrastructure statique
= Il faut scripter !
53. « Right-sizer » avec les PaaS
Normalement transparent
avec les PaaS
Finalement pas si trivial que ça même en PaaS
Voir les fameuses histoires de coûts du début de la présentation
55. Pas encore très développé
Disponible pour AWS uniquement
Pour l’instant
56. AWS Reserved Instances (RI)
« Acheter les soldes »
Pour 150€, vous avez -30% sur les
« t-shirts noirs tailles 38 pour femme »
pendant 1 an
Attention ! Ne s’applique pas aux t-shirts gris
58. AWS Spot instances
« Acheter aux enchères »
Spot Instances
Stratégies proches du trading : Bid, Outbid, …
Les machines peuvent être reprises à tout moment par AWS !
Pas uniquement réservé aux batchs.
Ex : Ajouter des instances derrière un load-balancer pour améliorer les perfs à faible coût
60. Qui se charge des stratégies d’achat ?
Pas vraiment un truc de
développeur et d’architecte
Pas encore clair dans les entreprises de savoir à qui revient ce rôle
Equipes DevOps / DSI / Direction financière ?
61. Comme pour les performances, la qualité, c’est la seule manière de s’améliorer
COST FEEDBACK
62. Cost feedback
On ne peut améliorer que ce
qu’on mesure
Les Dev/Architectes ont rarement le nez sur la facture (quand ils y ont accès)
Pas de feedback == on travaille dans le noir
63. Cost feedback loop
Netflix pousse vers ses équipes
de Dev leur « consommé de la
semaine précédente »
Pas forcément pour améliorer la « cost efficiency » de l’application au runtime
64. Cost feedback loop
Naturel d’avoir la même chose
en prod/integration/qualif/…
Surveillance de la marge par tenant, …
Notion de ‘cost optimization’ continue
Surveillance des changements tarifaires non anticipés
Surveillance du right-sizing
65. Le feedback, en continue et de manière industrielle
CONTINUOUS COST TESTING
66. Objectif
Donner aux équipes du feedback en
continu sur « l’efficacité coût » du
système qu’elles créent/déploient
Pour éviter les dérives liées aux évolutions du code / de l’archi
Pour éviter les dérives liées aux évolutions de l’infrastructure du fournisseur
67. Exemple de dérive – true story
Un développeur déplace quelques lignes
de code qui implique des boucles
è L’application envoie 10.000* plus de
messages dans une file pour le même
traitement. Oups !
Gros changement dans la facture en fin de mois
68. « Last run » vs « Previous run »
Je veux ça dans
mon inbox tous
les matins !
En bleu : Last run
En rose : Previous run
Unité : $ (USD)
Echelle : peu importe/
69. Comment on fait ça ?
De quelles informations
a-t-on-besoin ?
70. Le coût du dernier « tir »
Données sur le coûts et l’usage
Evidemment !
Comment on les récupère ? Ça dépend du Cloud provider ...
Pour la méthode d’accès aux données, et pour leur format
72. GET /costs – AppEngine ‘HTTP headers cost/req’
X-AppEngine-Resource-Usage: ms=293 cpu_ms=500 api_cpu_ms=236
X-AppEngine-Estimated-CPM-US-Dollars: $0.012320
Présent dans les headers HTTP de retour
Il faut naviguer sur son application en
étant connecté en admin sur la console
appengine pour les voir
73. GET /costs – Teevity API – ‘cost snapshot’
PUT
http://api.teevity.com/
cloudcost/
costAndUsageSnapshot/
forCloudServiceId/
50243203420423
⇒ { snapshotId:582452432342234 }
GET
http://api.teevity.com/
cloudcost/
costAndUsageSnapshot/
582452432342234
74. GET /costs – Teevity API – ‘cost snapshot diff’
GET
http://api.teevity.com/
cloudcost/
costAndUsageSnapshotDifference/
withInitial/582452432342234/
and/5915536323421748
76. Difficulté
Décalage temporel entre
exécution et disponibilité des
données de coûts
Vous pouvez compter plusieurs heures de décalage.
Pour l’instant, très difficile d’avoir un feedback quasi temps-réel
77. Difficulté – le contournement
On fait tourner les tests sur des
périodes de temps bien définies
En isolation d’autres activités
Sur un autre environnement Cloud (autre compte, autre appId)
78. Le coût ok. Mais la qualité ?
Ça ne suffit pas !
C’est la « cost efficiency » qui nous
intéresse, pas le coût absolu
On a besoin d’autres données
79. Mesure de cost-efficiency
Informations de perf (nb trans/sec)
Combien de transactions ont été
réalisées par unité de coût
80. Mesure de cost-efficiency (suite)
Informations de QoS
Latence notamment
Point important ! Vous pouvez économiser beaucoup en arrêtant/lançant des instances
fréquemment. Mais l’impact sur la latence est important.
83. Dans le cloud …
Vos décisions ont un
impact réel sur les coûts
Un nouveau challenge pour les techos
!
Et on commence juste à découvrir les bonnes pratiques pour le relever