App Scalability Talk at Treatabit

App Scalability, dal codice al management.

Transcript

2. Luca Cipriani presenta
3. - App Scalability - Pensare, progettare e implementare un’app da 10 ad 1 milione di utenti al giorno
4. 1. Sai davvero cos'è il cloud? 2. Above the Clouds: A Berkeley View of Cloud Computing 3. Mille server per un’ora o un server per mille ore hannno lo stesso prezzo 4. Scalabilità? 5. Iaas Pass Saas Nass, what?! *as a service* 6. Cosa mi serve? Analisi dei requisiti 7. Perché scalare presto è sbagliato 8. Non-sense optimization 9. Una questione di design 10. L’importanza della cache 11. Trovare i colli di bottiglia 12. Cloud9 - Case History (presente) 13. Cloud9 - Case History (futuro) 14. Il mondo asincrono 15. Kred - Case history (1) 16. Kred - Case history (2) 17. Cosa vuole il cliente? 18. Q/A
5. 19. Creare un team scalabile 20. Code review 21. Meeting 22. Test test test 23. Monitoraggio attivo 24. Prevenire è meglio che curare 25. Datadog demo 26. Data Driven Business Rules 27. AWS Demo 28. Q/A 29. Discussione aperta 30. Ringraziamenti
6. 1/30 Sai davvero cos’è il cloud?
7. Caratteristiche essenziali: Paga solo quello che usi, no overhead per gestire i picchi di carico Aggiunta di risorse a caldo API Migrazione fra server fisici Decentralizzazione High Availability Provisioning Facilità di manutenzione Sai davvero cos'è il cloud?
8. 2/30 Above the Clouds: A Berkeley View of Cloud Computing
9. http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf The illusion of infinite computing resources available on demand • The elimination of an up-front commitment by Cloud users • The ability to pay for use of computing resources ona short-term basis as needed Above the Clouds: A Berkeley View of Cloud Computing
10. 3/30 1000 server x un’ora o un server x 1000 ore hanno lo stesso prezzo
11. UserHourscloud * (revenue - Costcloud) > = UserHoursdatacenter x (revenue - Costdatacenter/Utilization) Mille server per un’ora o un server per mille ora hannno lo stesso prezzo
12. 4/30 Scalabilità?
13. Un sistema è scalabile se all’aumentare degli utenti i COSTI aumentano linearmente o meglio che linearmente Scalabilità?
14. 5/30 Iaas Pass Saas Nass, what?! *as a service*
15. Iass: Infrastructure (Ec2, Google Compute Engine, Rackspace) Paas: Platform (Heroku, Google App Engine, Openshift) Saas: Software (Google Apps) Naas: Network (Softlayer) Iaas Pass Saas Nass, what?! *as a service*
16. 6/30 Cosa mi serve? Analisi dei requisiti
17. Atomicity Consistency Isolation Durability ? Cosa mi serve? Analisi dei requisiti
18. Teorema CAP (Brewer 2000) a cosa possiamo rinunciare ? Consistency • Availabity • Partition Failure Un sistema distribuito può soddisfarne solo 2/3 Cosa mi serve? Analisi dei requisiti
19. Quanti utenti prevedo? Quali tecnologie userò? map/reduce vs process scalability Cosa mi serve? Analisi dei requisiti
20. 7/30 Perché scalare presto è sbagliato
21. Rispettate il business plan, quanti utenti sono prospettati ogni mese? • Non è importante il numero di utenti che avete, ma il numero contemporaneo degli stessi. 100k utenti al giorno se ben distribuiti sono solo 666 utenti/s (bastano 2/3 server) • 100k utenti in 1s richiedono circa 300 server... Perché scalare presto è sbagliato
22. 8/30 Non-sense optimization
23. Devi davvero ottimizzare il tuo server SQL? Un disco SSD può migliorare le performance del 40-50% Non usare le join, davvero, non usare le join Non-sense optimization
24. 9/30 Una questione di design
25. Separazione di ogni layer, prevedete ogni stack come possibilmente eseguibile su un server separato Es. “apache + mod_proxy_balancer + mod_php” Vs “haproxy + nginx + phpfpm” Separazione dei layer applicativi • Creazione delle code • Distribuzione del carico Una questione di design
26. 10/30 L’importanza della cache
27. Cache contenuti statici (CDN, Varnish, etc.) Cache db Cache applicativa (oggetti) Usate TUTTA la RAM (ramdisk) Il 90% degli utenti accede al 10% dei contenuti L’importanza della cache
28. 11/30 Trovare i colli di bottiglia
29. Database e I/O • Rete • App Trovare i colli di bottiglia
30. 12/30 - Case History (presente)
31. Da 5 hops a 2, da 700ms a ~ 100ms ELB Proxy Redis NAT IDE Openshift Utenti -> Redis Cloud9 - Case History (presente)
32. 13/30 - Case History (futuro)
33. HAproxy IDE Openshift Utenti -> MongoDB Cloud9 - Case History (futuro)
34. 14/30 Il mondo asincrono
35. Il mondo asincrono Librerie asyncrone, threading ecc. La vera via: map/reduce, queue
36. 15/30 Kred - Case history
37. Twitter firehose ~2TB di dati al giorno • Streaming dei dati twitter • 1 milione di accessi al giorno • ~5 milioni di api requests al giorno Kred - Case history
38. 16/30 Kred - Case history
39. Filtraggio dati • Ramdisk (512 GB di Ram ogni server) • Rete gigabit • SSD disk • RAID su dischi “normali” • Backup dei dati interessanti • RabbitMQ per processare i dati (20 server di backend) • KVM Kred - Case history
40. 17/30 Cosa vuole il cliente?
41. Stabilità • Velocità • Sicurezza • Funzionalità Trovare i colli di bottiglia
42. 18/30 Q/A
43. - coffee break -
44. 19/30 Creare un team scalabile
45. Assumere personale in grado di imparare in fretta • Preferire l’eclettismo alla specializzazione • Pair programming • Sharding delle conoscenze • Knowledge sharing sessions Creare un team scalabile
46. 20/30 Code review
47. Il workflow di Github Pair programming • Divisione fra team di sviluppo e team di test • Zero bug development Code review Pull Request Branch Review Merge
48. 21/30 Meeting
49. 1 meeting giornaliero (ogni microteam) 1 settimanale (tutti i team) 1 mensile (piani a lungo termine) 1 ogni QT Meeting
50. 22/30 Test test test
51. TTD Test Driven Development • Continous Integration • Integration test • A/B testing Test test test
52. 23/30 Monitoraggio attivo
53. Datadog, Graphite, Pingdom, il monitoraggio diventa semplice • Non c’è monitoring senza alert • Non c’è alert senza intervento (manuale o automatizzato) • Se ignori un alert esso è sbagliato (evitate il rumore) Monitoraggio attivo
54. 24/30 Prevenire è meglio che curare
55. AWS Autoscale • Provisioning • AWS OpsWorks Prevenire è meglio che curare
56. 25/50 Datadog demo
57. 26/30 Data Driven Business Rules
58. Acquisizione • Attivazione • Retention • Referral • Revenue Data Driven Business Rules
59. 27/30 AWS Demo aws.amazon.com
60. Calcolo dei costi con http://calculator.s3.amazonaws.com/calc5.html AWS Demo
61. 28/30 Q/A
62. 29/30 Discussione aperta
63. 30/30 Un sentito ringraziamento a
64. e grazie per l’attenzione !
65. Luca Cipriani contatti: luca@sysapparchitect.com @mastrolinux