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?

9. Skalierbarkeit und Performance

10. Performance

11. vertikale Skalierbarkeit
http://de.autoblog.com/photos/elektro-bus-mit-16-t-ren-530-ps-and-250-km-h/4041119/

12. horizontale Skalierbarkeit

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

30. Pattern #3: Stateless

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

42. Pattern #6: Caching

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

47. Pattern #7: Datamanagement

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

49. Pattern #8: Evented

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!