Continuous	   (Cloud) Costs Testing                       	10h40 - 11h30 - Salle E. Fitzgerald & L. Armstrong             ...
Continuous Cloud Costs Testing	             Nicolas Fonrose	 Teevity Cloud Costs Analytics – Founder / CEO	               ...
Nicolas Fonrose	 •  Cloud geek, Startuper 	  •  Pas mal d’années employé d’une boîte de conseil IT. Deux petites        bo...
(Petit) lexique du cloud	 •  Instance (une VM)	 •  Zone (approx. == datacenter)	 •  Region (1 ensemble de 2 à 5 zones dans...
AVEC LE CLOUD, ESTIMER LESCOÛTS, C’EST COMPLIQUÉ !
Les grilles de prix sont publiques	     Une grille de prix Cloud, ça         ressemble à quoi ? 	      Pas assez de place ...
Estimation	    Tout bouge. Et tout le temps 	                                 !         La grille de prix varie (très souv...
War stories	QUELQUES HISTOIRES DE COÛTS
Quand la théorie devient réalité …	     Violent changement de prix      pour AppEngine en 2011 	       Largement expliqué ...
Des fois, de très bonnes nouvelles	  AWS S3 price change (-15%, merci Google)	   AWS Glacier (10* moins cher; enfin presque...
D’autre fois, des moins bonnes	     Une région AWS, ça crache                             	           Et en entier (toutes...
Des services qui changent	       Le DataStore AppEngine           passe en HDR 	    Hello « eventual consistency » on read...
Des « non-conformités »	          Heroku / RapGenius                           	     Class action lancée contre Heroku 	  ...
Cloud Costs Savings TipsLES 4 CATÉGORIES	Architectes, Développeurs, Devops, vos actions ontun impact important sur le coût...
Categories	 •  « Software architecture » tips	 •  « Automation » tips (devops et scripting)	 •  « Buying strategies »	 •  ...
SOFTWARE ARCHITECTURESCOST DRIVEN DESIGN
Architecture logicielle	     L’élément le plus important !	      Impossible de profiter des options qui    rendent « cost-e...
Les clés du « cost driven » - 1/2	    Modularité	    Séparer les problématiques	    Pour pouvoir allouer les différents tr...
Les clés du « cost driven » - 2/2	    Elastic-driven	    Instances == Resources (!= Serveurs)	    Compatibilité de l’archi...
Et le « hardware »	     Le choix du « Hardware » (virtuel)     est bien sûr toujours important	  Mais c’est le software qu...
Cost-driven architectures (et auto-scaling driven architectures)	ARCHITECTURES CLOUD-COSTSEFFICIENTS : DES EXEMPLES !
Architecture logicielle et coûts cloud	 Exemple 1	 Site Web sans serveurs
Ex 1 - Site Web sans aucun serveur !	   Site Web entièrement hébergés         sur un Web-Storage	                         ...
Ex 1 - Site Web sans aucun serveur !	  Le DNS masque totalement le Web storage	         Compatible avec les CDN	          ...
Architecture logicielle et coûts cloud	 Exemple 2	 Une application SaaS au régime
Ex 2 - Application SaaS au régime	      Une application SaaS avec      beaucoup de requêtes en         lecture par les cli...
Ex 2 - Application SaaS au régime	                Régime minceur	      On pousse des copies des données         statiques ...
Ex 2 - Application SaaS au régime	                     Compute                     Instances                              ...
Ex 2 - Application SaaS au régime	         Ça marche aussi pas mal pour     tout ou partie d’applications « métier »      ...
Ex 2 - Et la sécurité ?	        Comment on gère les       autorisations d’accès ?         S3 Bucket Policy / adresse IP cl...
Ex 2 - Et la sécurité ?	               Auth                +               GET signed URL   Compute                       ...
Ex 2 – Cadeau «bonux» orienté Média	    Amazon S3 supporte Bittorrent !         Permet de fortement réduire la facture si ...
Architecture logicielle et coûts cloud	 Exemple 3	 Communication B2B au régime
Ex 3 - Application SaaS et upload	      Application SaaS avec gros    volume de données en upload	         Classique en sc...
Ex 3 - Application SaaS et upload
Ex 3 - Application SaaS et upload	    Donc là aussi, zéro serveur (ou presque),  c’est possible. Et c’est même mieux (sécu...
Ex 3 - Application SaaS et upload
Ex 3 - Intégration Amazon / IMDB
Architecture logicielle et coûts cloud	 Exemple 4	 Application avec des traitements asynchrones lourds
Ex 4 – Traitements asynchrones	      Beaucoup de traitements        asynchrones lourds ?	               Des batchs classiq...
Ex 4 – Traitements asynchrones
Ex 4 – Traitements asynchrones	              Actions périodiques ?	    Même pas besoin de laisser tourner une         inst...
Architecture logicielle et coûts cloud	 Un contre-exemple maintenant !	 Malgré l’architecture, dans certains cas, on peut ...
Ex 5 – Le contre-exemple	  « Web-cache / CDN » en frontal	        Fonctionne aussi pour les applications           (quelqu...
Ex 5 – « Web-cache/CDN » frontal
Indispensables pour pouvoir expérimenter les différentes stratégies	AUTOMATION, SCRIPTINGDEVOPS
Ne pas « pétrifier » son infrastructure	  Création infra cloud « à la main »       == infra cloud statique	       Ça prend ...
Fluide comme du code	  Scripting == infrastructure fluide	             Infrastructure As Code	                        	    ...
Facilite le changement de CSP	 Important y compris pour pouvoir    changer/tester d’autres CSP	      Scripting avec une me...
Corrélations « action-to-cost »	      Intégration des actions sur  l’infrastructure dans la boucle de             cost-fee...
RIGHT-SIZING
« Right-sizer »	             Ne pas allouer plus que              ce dont on a besoin	                         Ça paraît é...
« Right-sizer » avec les PaaS	       Normalement transparent           avec les PaaS	  Finalement pas si trivial que ça mê...
Les stratégies d’achats de resources Cloud	BUYING STRATEGIES
Pas encore très développé	 Disponible pour AWS uniquement	              Pour l’instant
AWS Reserved Instances (RI)	        « Acheter les soldes »	       Pour 150€, vous avez -30% sur les     « t-shirts noirs t...
Instances réservées – break even	           6 mois                  16 mois	           (light)	   9 mois	     (heavy)	    ...
AWS Spot instances	            « Acheter aux enchères »	                                 Spot Instances	                  ...
Spot instances
Qui se charge des stratégies d’achat ?	       Pas vraiment un truc de     développeur et d’architecte	                    ...
Comme pour les performances, la qualité, c’est la seule manière de s’améliorer	COST FEEDBACK
Cost feedback	    On ne peut améliorer que ce           qu’on mesure	     Les Dev/Architectes ont rarement le nez sur la f...
Cost feedback loop	   Netflix pousse vers ses équipes   de Dev leur « consommé de la       semaine précédente »	     Pas fo...
Cost feedback loop	   Naturel d’avoir la même chose     en prod/integration/qualif/…	                Surveillance de la ma...
Le feedback, en continue et de manière industrielle	CONTINUOUS COST TESTING
Objectif	   Donner aux équipes du feedback en    continu sur « l’efficacité coût » du    système qu’elles créent/déploient	...
Exemple de dérive – true story	      Un développeur déplace quelques lignes          de code qui implique des boucles	 è ...
« Last run » vs « Previous run »	 Je veux ça dans mon inbox tous les matins !	  En bleu : Last run  En rose : Previous run...
Comment on fait ça ?	       De quelles informations            a-t-on-besoin ?
Le coût du dernier « tir »	   Données sur le coûts et l’usage	                     Evidemment !         Comment on les réc...
GET /costs – AWS Programmatic Billing
GET /costs – AppEngine ‘HTTP headers cost/req’	 X-AppEngine-Resource-Usage: ms=293 cpu_ms=500 api_cpu_ms=236 X-AppEngine-E...
GET /costs – Teevity API – ‘cost snapshot’	 	 	 PUT	     	http://api.teevity.com/	     	 	cloudcost/	     	 	costAndUsageS...
GET /costs – Teevity API – ‘cost snapshot diff’	 	 	 GET	     	http://api.teevity.com/	     	 	cloudcost/	     	 	costAndU...
Schéma global
Difficulté	       Décalage temporel entre     exécution et disponibilité des          données de coûts 	               Vous...
Difficulté – le contournement	   On fait tourner les tests sur des   périodes de temps bien définies	         En isolation d...
Le coût ok. Mais la qualité ?	            Ça ne suffit pas !	   C’est la « cost efficiency » qui nous      intéresse, pas l...
Mesure de cost-efficiency	 Informations de perf (nb trans/sec)	    Combien de transactions ont été      réalisées par unité...
Mesure de cost-efficiency (suite)	                Informations de QoS	                    Latence notamment   Point importa...
Schéma global
Conclusion
Dans le cloud …	         Vos décisions ont un        impact réel sur les coûts  	    Un nouveau challenge pour les techos ...
Teevity Cloud Costs     Analytics
d
d
d
Prochain SlideShare
Chargement dans…5
×

Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03

942 vues

Publié le

Advices on how to optimize your software architectures and how to ensure they stay optimized on the long run.

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
942
Sur SlideShare
0
Issues des intégrations
0
Intégrations
9
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03

  1. 1. Continuous (Cloud) Costs Testing 10h40 - 11h30 - Salle E. Fitzgerald & L. Armstrong
  2. 2. Continuous Cloud Costs Testing Nicolas Fonrose Teevity Cloud Costs Analytics – Founder / CEO @nfonrose / @teevity 27 au 29 mars 2013
  3. 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. 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. 5. AVEC LE CLOUD, ESTIMER LESCOÛTS, C’EST COMPLIQUÉ !
  6. 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. 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. 8. War stories QUELQUES HISTOIRES DE COÛTS
  9. 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. 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. 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. 12. Des services qui changent Le DataStore AppEngine passe en HDR Hello « eventual consistency » on reads Impact sur l’architecture de certaines applications
  13. 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. 14. Cloud Costs Savings TipsLES 4 CATÉGORIES Architectes, Développeurs, Devops, vos actions ontun impact important sur le coût ! 27 au 29 mars 2013
  15. 15. Categories •  « Software architecture » tips •  « Automation » tips (devops et scripting) •  « Buying strategies » •  « Right-sizing » (allocated vs consumed)
  16. 16. SOFTWARE ARCHITECTURESCOST DRIVEN DESIGN
  17. 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. 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. 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. 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. 21. Cost-driven architectures (et auto-scaling driven architectures) ARCHITECTURES CLOUD-COSTSEFFICIENTS : DES EXEMPLES !
  22. 22. Architecture logicielle et coûts cloud Exemple 1 Site Web sans serveurs
  23. 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. 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. 25. Architecture logicielle et coûts cloud Exemple 2 Une application SaaS au régime
  26. 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. 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. 28. Ex 2 - Application SaaS au régime Compute Instances on update Web Storage Integrated web servers
  29. 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. 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. 31. Ex 2 - Et la sécurité ? Auth + GET signed URL Compute Instances on update Web Storage Integrated web servers
  32. 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. 33. Architecture logicielle et coûts cloud Exemple 3 Communication B2B au régime
  34. 34. Ex 3 - Application SaaS et upload Application SaaS avec gros volume de données en upload Classique en scénario B2B
  35. 35. Ex 3 - Application SaaS et upload
  36. 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. 37. Ex 3 - Application SaaS et upload
  38. 38. Ex 3 - Intégration Amazon / IMDB
  39. 39. Architecture logicielle et coûts cloud Exemple 4 Application avec des traitements asynchrones lourds
  40. 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. 41. Ex 4 – Traitements asynchrones
  42. 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. 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. 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. 45. Ex 5 – « Web-cache/CDN » frontal
  46. 46. Indispensables pour pouvoir expérimenter les différentes stratégies AUTOMATION, SCRIPTINGDEVOPS
  47. 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. 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. 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. 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. 51. RIGHT-SIZING
  52. 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. 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. 54. Les stratégies d’achats de resources Cloud BUYING STRATEGIES
  55. 55. Pas encore très développé Disponible pour AWS uniquement Pour l’instant
  56. 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. 57. Instances réservées – break even 6 mois 16 mois (light) 9 mois (heavy) (medium)
  58. 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. 59. Spot instances
  60. 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. 61. Comme pour les performances, la qualité, c’est la seule manière de s’améliorer COST FEEDBACK
  62. 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. 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. 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. 65. Le feedback, en continue et de manière industrielle CONTINUOUS COST TESTING
  66. 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. 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. 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. 69. Comment on fait ça ? De quelles informations a-t-on-besoin ?
  70. 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. 71. GET /costs – AWS Programmatic Billing
  72. 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. 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. 74. GET /costs – Teevity API – ‘cost snapshot diff’ GET http://api.teevity.com/ cloudcost/ costAndUsageSnapshotDifference/ withInitial/582452432342234/ and/5915536323421748
  75. 75. Schéma global
  76. 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. 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. 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. 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. 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. 81. Schéma global
  82. 82. Conclusion
  83. 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. 84. Teevity Cloud Costs Analytics
  85. 85. d
  86. 86. d
  87. 87. d

×