W jax-2011-web klein
0 gefällt mir301 aufrufe
Das Dokument behandelt skalierbare Architekturen für Web 2.0-Start-ups und nennt Anforderungen an moderne Web-Anwendungen wie Skalierbarkeit, Hochverfügbarkeit und Performance. Es werden wichtige Konzepte und Patterns vorgestellt, darunter der richtige Einsatz von Teams, einfache Designprinzipien und Caching-Strategien, um eine effektive Anwendung zu gewährleisten. Abschließend werden Tipps und Links für weitere Informationen zur Skalierung und Performance-Optimierung bereitgestellt.
W jax-2011-web klein
- 1. Ready to start(up)? Skalierende Architekturen für Web-2.0- Start-ups 10.11.2011 | 15:15 - 16:15 Uhr | Calgary
- 2. Speaker Tobias Joch – inovex GmbH – Head of Solution Development – leichtgewichtige und hochskalierende (Web-)Anwendungen – CCD
- 3. Anforderungen an moderne Web-Anwendungen
- 4. Anforderungen an moderne Web-Anwendungen • Skalierbarkeit • Hochverfügbarkeit • Performance • Wartbarkeit • Features, Features, Features • Geringe Kosten • Hohe Rendite / Umsatz
- 5. Anforderungen an moderne Web-Anwendungen • Skalierbarkeit • Hochverfügbarkeit • Performance • Wartbarkeit • Features, Features, Features • Geringe Kosten • Hohe Rendite / Umsatz
- 6. When do you start thinking about scalability? • Knuth wrote that in the pre-Web era. It's never too early to think about scalability. • You should think about it some, but not too much, as early as the planning stages of an application. • You shouldn't start thinking about scalability until you have a working prototype. • Once you start to see performance issues, you should start trying to fix them.You can't anticipate what will need optimization. • Scalability is overrated. Thanks to the cloud, you can always throw more servers at the problem.http://www.readwriteweb.com/hack/2011/04/hacker-poll-how-much-do-you-co.php
- 7. When do you start thinking about scalability? • Knuth wrote that in the pre-Web era. It's never too early to think 19.71% about scalability. • You should think about it some, but not too much, as early as the 35.77% planning stages of an application. • You shouldn't start thinking about scalability until you have a working 22.63% prototype. • Once you start to see performance 17.52% issues, you should start trying to fix them.You can't anticipate what will need optimization. 4.38% • Scalability is overrated. Thanks to the cloud, you can always throw more servers at the problem.http://www.readwriteweb.com/hack/2011/04/hacker-poll-how-much-do-you-co.php
- 8. Was versteht man unter Skalierbarkeit?
- 10. Performance
- 11. vertikale Skalierbarkeit http://de.autoblog.com/photos/elektro-bus-mit-16-t-ren-530-ps-and-250-km-h/4041119/
- 13. Performance http://gulfstream.vo.llnwd.net/o36/assets/pdf/brochures/G650_ProductBrochure_English.pdf
- 14. vertikale Skalierbarkeit http://www.flickr.com/photos/gasheadsteve/975790972/sizes/o/in/photostream/
- 15. horizontale Skalierbarkeit http://www.flickr.com/photos/flissphil/5651491911/sizes/o/in/photostream/
- 16. horizontale Skalierbarkeit http://www.flickr.com/photos/flissphil/5651491911/sizes/o/in/photostream/
- 17. geographische Skalierung http://johomaps.com/world/worldairports.html
- 18. Performance ist sehr wichtig! • Ladezeit > 3 Sekunden – 40% verlassen bereits die Seite • Erwartete Ladezeiten < 2 Sekunden! http://www.getelastic.com/performance/
- 19. Einflüsse auf die Performance Größe der Webseiten – verdreifacht in den letzten 5 Jahren – Internet Latenz stark vom Standort abhängig http://www.getelastic.com/performance/
- 20. Nun aber endlich zu den „Patterns“, Tipps und Tricks ;) oder auch – „Regeln“ – „Ratschläge“ – „Erfahrungen aus der Praxis“, ...
- 21. Public IP range ha-lb-fehttp HTTP/HTTPS lb01 xx.xx.xx.xx lb02 lb-web eth1: eth1: xx.xx.xx.xx xx.xx.xx.xx Port(s): 80/(443) Public IP's: xx.xx.xx.xx/26 fe01 fe02 fe03 fe04 fe05 fe06 fe07 fe08 fe09 fe11 fe12 fe13 fe14 Private IP range Cache ha-lb-inthttp mc01 mc02 lb05 lb06 mc03 mc04 Cache mw01 mw02 mw03 mw04 mw05 ha-lb-intdbs mw06 mw07 mw08 mw09 mw10 lb05 lb06 mw11 mw12 mw13 mw14 SQL Lookup store01 store02 store03 store04 store05 store06 store07 store08 store09 store10 store11 store12 store13 store14 store15 store16 SQL Writes store17 store18 store19 store20 store21 store22 store23 store24 store25 store26 store27 store28 store29 store30 store31 store32 SQL Writes SQL Read Writes BinLog Sync Reads mgmt01 PXE mgmt02 test01 MySQL MySQL MySQL MySQL MySQL MySQL SSH zabbix logstore01 DEV/TEST Master. Master. Repl Slave Slave Slave Slave puppet dbm01 dbm02 dbb01 dbb02 Repl dbs02 dbs01 NTP MySQL MySQL mgmt02 shard0 shard1 Slave Slave PXE mgmt02 test02 dbs03 dbs04 SSH zabbix logstore02 DEV/TEST MySQL MySQL MySQL MySQL puppet Master. Master. Master. Master. NTP dbm01 dbm02 dbm01 dbm02
- 22. Pattern #1: Das richtige Team
- 24. Pattern #1: Das richtige Team • OPS – Bare Metal Deployments – Automatisierung, Config-Management – Erfahrung im Troubleshooting und Analyse von Problemen – Netzwerk KnowHow – Standard-Komponenten – Linux – Dynamische Programmiersprache – Staging / Rollout Prozesse
- 25. Pattern #1: Das richtige Team • Middleware – Skalierbare, lose gekoppelte Services – Datenhaltung – Such-Technologien – Remoting / Standard-Protokolle – Integration von Fremdsystemen – TDD / CCD – Logging – Erfahrung im Troubleshooting
- 26. Pattern #1: Das richtige Team • Frontend – HTML(5) (Haml) – CSS(3) / CSS-Compiler (SASS, Less) – JavaScript (CoffeeScript) – Dynamische Sprachen – REST • QA – BDD, explorative Tests – CI, automatisierte Tests
- 27. Pattern #2: KISS
- 28. Pattern #2: KISS • Keep it simple, stupid • Keep it small and simple • Keep it sweet and simple • Keep it simple and straightforward • Keep it short and simple • Keep it simple and smart • Keep it strictly simple • Keep it speckless and sane • Keep it sober and significant • Keep it simple and stupid • Keep it safe and sound
- 29. Pattern #2: KISS • Anforderungen hinterfragen – und genau verstehen – effiziente Lösungen forcieren • „Golden Hammer“-Methode vermeiden • Rad nicht neu erfinden • OSS einsetzen wenn möglich • DRY • Klare Schichten – Design / Architektur
- 31. Pattern #3: Stateless • State wenn möglich – vermeiden – oder auslagern • Vorteile – einfacheres Loadbalancing – unkompliziertes Failover / HA – Deployment / Update Prozess – Scale out – weniger Ressourcen
- 32. Pattern #3: Stateless am Beispiel Session Handling • Server side – einfach realisierbar – OOTB bei vielen Frameworks, Specs – sticky Loadbalancing (aufwändiger) – HA – SPoF – Replikation / Session Server – komplexere Rollout-Strategien – komplexere Prozesse
- 33. Pattern #3: Stateless am Beispiel Session Handling • Client side – Stateful auf dem Client (Cookie) – Stateless auf dem Server – Client Sessions überleben einen Server-Crash (HA) – einfaches Loadbalancing / Failover – bessere, dynamischere Lastverteilung – einfachere Rollout-Strategien – SPoF = Client = Single User
- 34. Pattern #3: Stateless am Beispiel Session Handling • Zu beachten! – keine volatilen Werte – potentiell mehrere Cookies / alte Werte – Cookies sind (laut Spec) limitiert auf 4kB – Security – TLS/SSL und Kryptographie verwenden (HMAC/SHA1) – vertraulich – Daten Integrität – Echtheit – Timeout / Invalidierung – Bandbreite
- 35. Pattern #4: Dynamische Anpassbarkeit
- 36. Pattern #4: Dynamische Anpassbarkeit zur Laufzeit! • Scale out (Horizontal) – Commodity Hardware – Data Center – Cloud – Geo-Redundanz • Gewichtete Verteilung – FE, MW, DB, Cache, ... • zur Laufzeit erweiterbar – Shards, Service-Instanzen aller Schichten
- 37. Pattern #4: Dynamische Anpassbarkeit zur Laufzeit! • Zuordnung von User zu Service – pro Request (Stateless) – pro Session (z.B. Cache) – längerfristig, aber nicht zwangsläufig für immer (z.B. Shard)
- 38. Pattern #5: Content Delivery
- 39. Pattern #5: Content Delivery Static Content • Header – Date – Cache-Control – ETag – Expires • Conditional Get – If-None-Match – If-Modified-Since • YSlow
- 40. Pattern #5: Content Delivery Static Content • sendfile / X-Sendfile – Optimierung wie Caching Header, Resume, etc. direkt vom Server – static.foo.bar • Zugriffe minimieren – Sprites – CSS und JS packing • Compression • Content Delivery Networks – Geo-Scaling / Geo-DNS
- 41. Pattern #5: Content Delivery Dynamic Content • Cache-Control – private vs. public • Berechnungen wiederverwenden • Nur neu berechnen, wenn sich Parameter geändert haben • Architektur – volatile Aspekte in separate Schichten – geeignete / billige Indikatoren ob geändert
- 43. Pattern #6: Caching • „Caching ist wie Aspirin gegen Kopfschmerzen“ – Facebook muss große Kopfschmerzen gehabt haben – 805 memcached Server bei – 10k Web Server und – 1.800 MySQL Server – 99% Cache hit rate! http://highscalability.com/strategy-break-memcache-dog-pile
- 44. Pattern #6: Caching • In allen Schichten cachen – Client, Proxy, Server, Services, ... – Page,View, Action, Object, Entity, ... • Intelligentes Cache Management – Partial updates – Pre-fetch – Lazy initializing – „Dog Pile“-Effekt vermeiden – No Expire – Stale Date vs. Expiration Date
- 45. Pattern #6: Caching • Beispiele für den Client – Browser Cache – Cookie als Cache – User Profil – User Privilegien – häufig benötigte Daten vom Backend – Page-Flow Zustand • Beispiele für den Proxy – Cache-Control: public
- 46. Pattern #6: Caching • Beispiele für den Server – Page – View – Action – Objekte (z.B. Hibernate 1st und 2nd Level Cache) • z.B. in – Filesystem – Memory (z.B. memcached) – DB, ...
- 48. Pattern #7: Datamanagement • File-Storage – HA Storage (z.B. DRBD) – Cluster Filesysteme (z.B. GlusterFS) – ..., aber kein NFS • SQL – RDBMS • NoSQL – MongoDB, Casandra, CouchDB, ... • NewSQL – NimbusDB, ScaleBase, ... – Transparent Sharding
- 50. Pattern #8: Evented • Hollywood-Prinzip – Don’t call us, we’ll call you – Polling vermeiden • Event Erzeugung an der Quelle • Bus / Queue für Interessenten • Non-Blocking • Asynchron
- 51. Pattern #9: Monitoring & Profiling
- 52. Pattern #9: Monitoring & Profiling • Monitoring != Monitoring – Availability Monitoring (z.B. Zabbix, Nagios) – Performance Monitoring (z.B. Cacti, Zabbix) • Netzwerk – IO, Anzahl Verbindungen • System – CPU, Memory, Prozesse • Applikationen – KPI‘s
- 53. Pattern #9: Monitoring & Profiling • Profiling / Performance Messung – Bottlenecks • Langzeit Archivierung – Vergleichsmöglichkeiten – post mortem Analysen
- 54. Beispiel aus der Praxis Diskussion der „Patterns“ anhand einer konkreten System-Architektur
- 55. Public IP range ha-lb-fehttp HTTP/HTTPS lb01 xx.xx.xx.xx lb02 lb-web eth1: eth1: xx.xx.xx.xx xx.xx.xx.xx Port(s): 80/(443) Public IP's: xx.xx.xx.xx/26 fe01 fe02 fe03 fe04 fe05 fe06 fe07 fe08 fe09 fe11 fe12 fe13 fe14 Private IP range Cache ha-lb-inthttp mc01 mc02 lb05 lb06 mc03 mc04 Cache
- 56. mw01 mw02 mw03 mw04 mw05 ha-lb-intdbs mw06 mw07 mw08 mw09 mw10 lb05 lb06 mw11 mw12 mw13 mw14 SQL Lookup store01 store02 store03 store04 store05 store06 store07 store08 store09 store10 store11 store12 store13 store14 store15 store16 SQL Writes store17 store18 store19 store20 store21 store22 store23 store24 store25 store26 store27 store28 store29 store30 store31 store32 SQL Writes SQL Read
- 57. Writes BinLog Sync Reads MySQL MySQL MySQL MySQL MySQL MySQL Master. Master. Repl Slave Slave Slave Slave dbm01 dbm02 dbb01 dbb02 Repl dbs02 dbs01 MySQL MySQL shard0 shard1 Slave Slave dbs03 dbs04 MySQL MySQL MySQL MySQL Master. Master. Master. Master. dbm01 dbm02 dbm01 dbm02 mgmt01 PXE mgmt02 test01 SSH zabbix logstore01 DEV/TEST puppet NTP mgmt02 PXE mgmt02 test02 SSH zabbix logstore02 DEV/TEST puppet NTP
- 58. Literatur-Tipps und Links • SCALABILITY RULES – 50 Principles for Scaling Web Sites • http://highscalability.com/ • 6 Ways Not To Scale That Will Make You Hip, Popular And Loved By VC – http://highscalability.com/blog/2011/4/18/6-ways-not-to- scale-that-will-make-you-hip-popular-and-loved.html
- 59. Vielen Dank!