App Scalability Talk at Treatabit

App Scalability Talk at Treatabit

App Scalability, dal codice al management.

65b2289e168cb9b6a90078190f82e1cc?s=128

Luca Cipriani

March 15, 2013
Tweet

Transcript

  1. None
  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

  66. None