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
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
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
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
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)
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, ...
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