Nicolas Fonrose présente des solutions pour optimiser les coûts liés au cloud lors de l'événement Teevity Cloud Costs Analytics. Il aborde des stratégies d'architecture logicielle, d'automatisation, et de bonnes pratiques d'achat, en mettant l'accent sur l'importance du feedback continu et des ajustements pour éviter les dérives de coûts. Le document souligne également les défis liés à l'estimation des coûts et à la gestion des performances dans un environnement cloud dynamique.

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)

5. AVEC LE CLOUD, ESTIMER LES
COÛTS, C’EST COMPLIQUÉ !

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

8. War stories
QUELQUES HISTOIRES DE COÛTS

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

15. Categories
• « Software architecture » tips
• « Automation » tips (devops et scripting)
• « Buying strategies »
• « Right-sizing » (allocated vs consumed)

16. SOFTWARE ARCHITECTURES
COST DRIVEN DESIGN

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 !

22. Architecture logicielle et coûts cloud
Exemple 1
Site Web sans serveurs

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

25. Architecture logicielle et coûts cloud
Exemple 2
Une application SaaS au régime

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

33. Architecture logicielle et coûts cloud
Exemple 3
Communication B2B au régime

34. Ex 3 - Application SaaS et upload
Application SaaS avec gros
volume de données en upload
Classique en scénario B2B

35. Ex 3 - Application SaaS et upload

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

37. Ex 3 - Application SaaS et upload

38. Ex 3 - Intégration Amazon / IMDB

39. Architecture logicielle et coûts cloud
Exemple 4
Application avec des traitements asynchrones
lourds

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)

41. Ex 4 – Traitements asynchrones

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) !

45. Ex 5 – « Web-cache/CDN » frontal

46. Indispensables pour pouvoir expérimenter les différentes stratégies
AUTOMATION, SCRIPTING
DEVOPS

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

51. RIGHT-SIZING

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

54. Les stratégies d’achats de resources Cloud
BUYING STRATEGIES

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

57. Instances réservées – break even
6 mois 16 mois
(light)
9 mois
(heavy)
(medium)

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

59. Spot instances

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

71. GET /costs – AWS Programmatic Billing

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

75. Schéma global

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.

81. Schéma global

82. Conclusion

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

84. Teevity Cloud Costs
Analytics

85. d

86. d

87. d