Ready to start(up)?Skalierende Architekturen für Web-2.0-               Start-ups   10.11.2011 | 15:15 - 16:15 Uhr | Calgary
SpeakerTobias Joch – inovex GmbH – Head of Solution   Development – leichtgewichtige und   hochskalierende   (Web-)Anwendu...
Anforderungen an moderne   Web-Anwendungen
Anforderungen an moderne      Web-Anwendungen• Skalierbarkeit• Hochverfügbarkeit• Performance• Wartbarkeit• Features, Feat...
Anforderungen an moderne      Web-Anwendungen• Skalierbarkeit• Hochverfügbarkeit• Performance• Wartbarkeit• Features, Feat...
When do you start thinking            about scalability?• Knuth wrote that in the pre-Web era.  Its never too early to thi...
When do you start thinking            about scalability?• Knuth wrote that in the pre-Web era.  Its never too early to thi...
Was versteht man unter    Skalierbarkeit?
Skalierbarkeit und Performance
Performance
vertikale Skalierbarkeit              http://de.autoblog.com/photos/elektro-bus-mit-16-t-ren-530-ps-and-250-km-h/4041119/
horizontale Skalierbarkeit
Performance       http://gulfstream.vo.llnwd.net/o36/assets/pdf/brochures/G650_ProductBrochure_English.pdf
vertikale Skalierbarkeit               http://www.flickr.com/photos/gasheadsteve/975790972/sizes/o/in/photostream/
horizontale Skalierbarkeit                 http://www.flickr.com/photos/flissphil/5651491911/sizes/o/in/photostream/
horizontale Skalierbarkeit                 http://www.flickr.com/photos/flissphil/5651491911/sizes/o/in/photostream/
geographische Skalierung                    http://johomaps.com/world/worldairports.html
Performance ist sehr wichtig!• Ladezeit > 3 Sekunden   – 40% verlassen bereits die Seite• Erwartete Ladezeiten < 2 Sekunde...
Einflüsse auf die PerformanceGröße der Webseiten  – verdreifacht in den letzten 5 Jahren  – Internet Latenz stark vom Stand...
Nun aber endlich zu den  „Patterns“, Tipps und Tricks ;)oder auch  – „Regeln“  – „Ratschläge“  – „Erfahrungen aus der Prax...
Public IP range                                                                     ha-lb-fehttp                          ...
Pattern #1: Das richtige Team
Pattern #1: Das richtige Team• OPS  – Bare Metal Deployments  – Automatisierung, Config-Management  – Erfahrung im Troubles...
Pattern #1: Das richtige Team• Middleware  – Skalierbare, lose gekoppelte Services  – Datenhaltung  – Such-Technologien  –...
Pattern #1: Das richtige Team• Frontend   – HTML(5) (Haml)   – CSS(3) / CSS-Compiler (SASS, Less)   – JavaScript (CoffeeSc...
Pattern #2: KISS
Pattern #2: KISS•   Keep it simple, stupid•   Keep it small and simple•   Keep it sweet and simple•   Keep it simple and s...
Pattern #2: KISS• Anforderungen hinterfragen   – und genau verstehen   – effiziente Lösungen forcieren• „Golden Hammer“-Met...
Pattern #3: Stateless
Pattern #3: Stateless• State wenn möglich   – vermeiden   – oder auslagern• Vorteile   – einfacheres Loadbalancing   – unk...
Pattern #3: Stateless   am Beispiel Session Handling• Server side   – einfach realisierbar   – OOTB bei vielen Frameworks,...
Pattern #3: Stateless   am Beispiel Session Handling• Client side  – Stateful auf dem Client (Cookie)  – Stateless auf dem...
Pattern #3: Stateless   am Beispiel Session Handling• Zu beachten!  – keine volatilen Werte  – potentiell mehrere Cookies ...
Pattern #4: Dynamische     Anpassbarkeit
Pattern #4: Dynamische         Anpassbarkeit               zur Laufzeit!• Scale out (Horizontal)   – Commodity Hardware   ...
Pattern #4: Dynamische       Anpassbarkeit         zur Laufzeit!• Zuordnung von User zu Service  – pro Request (Stateless)...
Pattern #5: Content Delivery
Pattern #5: Content Delivery         Static Content• Header  – Date  – Cache-Control  – ETag  – Expires• Conditional Get  ...
Pattern #5: Content Delivery         Static Content• sendfile / X-Sendfile   – Optimierung wie Caching Header,     Resume, e...
Pattern #5: Content Delivery        Dynamic Content• Cache-Control   – private vs. public• Berechnungen wiederverwenden• N...
Pattern #6: Caching
Pattern #6: Caching• „Caching ist wie Aspirin gegen  Kopfschmerzen“  – Facebook muss große Kopfschmerzen    gehabt haben  ...
Pattern #6: Caching• In allen Schichten cachen   – Client, Proxy, Server, Services, ...   – Page,View, Action, Object, Ent...
Pattern #6: Caching• Beispiele für den Client  – Browser Cache  – Cookie als Cache  – User Profil  – User Privilegien  – hä...
Pattern #6: Caching• Beispiele für den Server   – Page   – View   – Action   – Objekte (z.B. Hibernate 1st und 2nd Level C...
Pattern #7: Datamanagement
Pattern #7: Datamanagement• File-Storage   – HA Storage (z.B. DRBD)   – Cluster Filesysteme (z.B. GlusterFS)   – ..., aber...
Pattern #8: Evented
Pattern #8: Evented• Hollywood-Prinzip  – Don’t call us, we’ll call you  – Polling vermeiden• Event Erzeugung an der Quell...
Pattern #9: Monitoring &        Profiling
Pattern #9: Monitoring &              Profiling• Monitoring != Monitoring   – Availability Monitoring (z.B. Zabbix, Nagios)...
Pattern #9: Monitoring &             Profiling• Profiling / Performance Messung  – Bottlenecks• Langzeit Archivierung  – Ver...
Beispiel aus der PraxisDiskussion der „Patterns“ anhand einerkonkreten System-Architektur
Public IP range                                                     ha-lb-fehttp                                          ...
mw01        mw02     mw03        mw04       mw05                                                                          ...
Writes                        BinLog Sync                       ReadsMySQL         MySQL                MySQL       MySQL ...
Literatur-Tipps und Links• SCALABILITY RULES   – 50 Principles for Scaling Web Sites• http://highscalability.com/• 6 Ways ...
Vielen Dank!
W jax-2011-web klein
Upcoming SlideShare
Loading in...5
×

W jax-2011-web klein

606
-1

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
606
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

W jax-2011-web klein

  1. 1. Ready to start(up)?Skalierende Architekturen für Web-2.0- Start-ups 10.11.2011 | 15:15 - 16:15 Uhr | Calgary
  2. 2. SpeakerTobias Joch – inovex GmbH – Head of Solution Development – leichtgewichtige und hochskalierende (Web-)Anwendungen – CCD
  3. 3. Anforderungen an moderne Web-Anwendungen
  4. 4. Anforderungen an moderne Web-Anwendungen• Skalierbarkeit• Hochverfügbarkeit• Performance• Wartbarkeit• Features, Features, Features• Geringe Kosten• Hohe Rendite / Umsatz
  5. 5. Anforderungen an moderne Web-Anwendungen• Skalierbarkeit• Hochverfügbarkeit• Performance• Wartbarkeit• Features, Features, Features• Geringe Kosten• Hohe Rendite / Umsatz
  6. 6. When do you start thinking about scalability?• Knuth wrote that in the pre-Web era. Its 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 shouldnt 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 cant 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. 7. When do you start thinking about scalability?• Knuth wrote that in the pre-Web era. Its 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 shouldnt 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 cant 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. 8. Was versteht man unter Skalierbarkeit?
  9. 9. Skalierbarkeit und Performance
  10. 10. Performance
  11. 11. vertikale Skalierbarkeit http://de.autoblog.com/photos/elektro-bus-mit-16-t-ren-530-ps-and-250-km-h/4041119/
  12. 12. horizontale Skalierbarkeit
  13. 13. Performance http://gulfstream.vo.llnwd.net/o36/assets/pdf/brochures/G650_ProductBrochure_English.pdf
  14. 14. vertikale Skalierbarkeit http://www.flickr.com/photos/gasheadsteve/975790972/sizes/o/in/photostream/
  15. 15. horizontale Skalierbarkeit http://www.flickr.com/photos/flissphil/5651491911/sizes/o/in/photostream/
  16. 16. horizontale Skalierbarkeit http://www.flickr.com/photos/flissphil/5651491911/sizes/o/in/photostream/
  17. 17. geographische Skalierung http://johomaps.com/world/worldairports.html
  18. 18. Performance ist sehr wichtig!• Ladezeit > 3 Sekunden – 40% verlassen bereits die Seite• Erwartete Ladezeiten < 2 Sekunden! http://www.getelastic.com/performance/
  19. 19. Einflüsse auf die PerformanceGröße der Webseiten – verdreifacht in den letzten 5 Jahren – Internet Latenz stark vom Standort abhängig http://www.getelastic.com/performance/
  20. 20. Nun aber endlich zu den „Patterns“, Tipps und Tricks ;)oder auch – „Regeln“ – „Ratschläge“ – „Erfahrungen aus der Praxis“, ...
  21. 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 IPs: xx.xx.xx.xx/26 fe01 fe02 fe03 fe04 fe05 fe06 fe07 fe08 fe09 fe11 fe12 fe13 fe14Private 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. 22. Pattern #1: Das richtige Team
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. Pattern #2: KISS
  27. 27. 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
  28. 28. 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
  29. 29. Pattern #3: Stateless
  30. 30. Pattern #3: Stateless• State wenn möglich – vermeiden – oder auslagern• Vorteile – einfacheres Loadbalancing – unkompliziertes Failover / HA – Deployment / Update Prozess – Scale out – weniger Ressourcen
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. Pattern #4: Dynamische Anpassbarkeit
  35. 35. 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
  36. 36. 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)
  37. 37. Pattern #5: Content Delivery
  38. 38. Pattern #5: Content Delivery Static Content• Header – Date – Cache-Control – ETag – Expires• Conditional Get – If-None-Match – If-Modified-Since• YSlow
  39. 39. 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
  40. 40. 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
  41. 41. Pattern #6: Caching
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 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, ...
  46. 46. Pattern #7: Datamanagement
  47. 47. 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
  48. 48. Pattern #8: Evented
  49. 49. 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
  50. 50. Pattern #9: Monitoring & Profiling
  51. 51. 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
  52. 52. Pattern #9: Monitoring & Profiling• Profiling / Performance Messung – Bottlenecks• Langzeit Archivierung – Vergleichsmöglichkeiten – post mortem Analysen
  53. 53. Beispiel aus der PraxisDiskussion der „Patterns“ anhand einerkonkreten System-Architektur
  54. 54. 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 IPs: xx.xx.xx.xx/26 fe01 fe02 fe03 fe04 fe05 fe06 fe07 fe08 fe09 fe11 fe12 fe13 fe14Private IP range Cache ha-lb-inthttp mc01 mc02 lb05 lb06 mc03 mc04 Cache
  55. 55. 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 store16SQL Writes store17 store18 store19 store20 store21 store22 store23 store24 store25 store26 store27 store28 store29 store30 store31 store32 SQL Writes SQL Read
  56. 56. Writes BinLog Sync ReadsMySQL MySQL MySQL MySQL MySQL MySQLMaster. Master. Repl Slave Slave Slave Slavedbm01 dbm02 dbb01 dbb02 Repl dbs02 dbs01 MySQL MySQL shard0 shard1 Slave Slave dbs03 dbs04MySQL MySQL MySQL MySQLMaster. 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
  57. 57. 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
  58. 58. Vielen Dank!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×