W jax-2011-web klein

Ready to start(up)?

Skalierende Architekturen für Web-2.0-Start-ups

10.11.2011 | 15:15 - 16:15 Uhr | Calgary

Speaker

Tobias Joch– inovex GmbH– Head of Solution

Development– leichtgewichtige und

hochskalierende (Web-)Anwendungen

– CCD

Anforderungen an moderne Web-Anwendungen


• Skalierbarkeit• Hochverfügbarkeit• Performance• Wartbarkeit• Features, Features, Features• Geringe Kosten• Hohe Rendite / Umsatz


• Skalierbarkeit• Hochverfügbarkeit• Performance• Wartbarkeit• Features, Features, Features• Geringe Kosten• Hohe Rendite / Umsatz

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

http://www.readwriteweb.com/hack/2011/04/hacker-poll-how-much-do-you-co.php


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

35.77%

19.71%

22.63%

17.52%

4.38%



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/




http://www.flickr.com/photos/flissphil/5651491911/sizes/o/in/photostream/







geographische Skalierung

http://johomaps.com/world/worldairports.html



• Ladezeit > 3 Sekunden – 40% verlassen bereits die Seite

• Erwartete Ladezeiten < 2 Sekunden!

Performance ist sehr wichtig!

http://www.getelastic.com/performance/



Einflüsse auf die PerformanceGröße der Webseiten

– verdreifacht in den letzten 5 Jahren

– Internet Latenz stark vom Standort abhängig




Nun aber endlich zu den „Patterns“, Tipps und Tricks ;)

oder auch – „Regeln“–„Ratschläge“–„Erfahrungen aus der Praxis“, ...

mw01

mw09

mw02

mw07

mw03

mw08

mw04

mw06

fe01 fe02 fe03 fe04

fe09

Public IP range

Private IP range

ha-lb-inthttp

lb05 lb06

ha-lb-fehttplb01

xx.xx.xx.xxlb-webeth1:

xx.xx.xx.xx

lb02eth1:

xx.xx.xx.xx

Port(s): 80/(443)

mgmt01PXESSH

puppetNTP

mgmt02zabbix

ha-lb-intdbslb05 lb06

mc01 mc02

SQL Writes

HTTP/HTTPS

Cache

Cache

SQL Read

SQL Lookup

fe08 fe11

Public IP's:xx.xx.xx.xx/26

test01DEV/TEST

fe12 fe13 fe14

fe05 fe06 fe07

mw10

mw05

mw14mw12 mw13mw11

test02DEV/TEST

mgmt02zabbix

mgmt02PXESSH

puppetNTP

logstore01

logstore02

store02store01 store04store03




store06store05

store14store13

store22store21

store30store29

store08store07

store16store15

store24store23

store32store31

Reads

MySQLSlavedbs02

MySQLSlavedbs03

MySQLSlavedbs01

MySQLSlavedbs04

WritesMySQLMaster.dbm01

MySQLMaster.dbm02

BinLog Sync

MySQLSlavedbb01

MySQLSlavedbb02

Repl

Repl

shard0MySQLMaster.dbm01

MySQLMaster.dbm02


MySQLMaster.dbm02

mc04mc03

SQL Writes

Pattern #1: Das richtige Team

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

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

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

Pattern #2: KISS

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

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

Pattern #3: Stateless

Pattern #3: Stateless• State wenn möglich

– vermeiden– oder auslagern

• Vorteile– einfacheres Loadbalancing– unkompliziertes Failover / HA– Deployment / Update Prozess– Scale out– weniger Ressourcen

Pattern #3: Statelessam 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


• 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


• 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

Pattern #4: Dynamische Anpassbarkeit

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

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)

Pattern #5: Content Delivery

Pattern #5: Content DeliveryStatic Content

• Header– Date– Cache-Control– ETag– Expires

• Conditional Get– If-None-Match– If-Modified-Since

• YSlow

Pattern #5: Content DeliveryStatic 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

Pattern #5: Content DeliveryDynamic 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

Pattern #6: Caching

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



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

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

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

Pattern #7: Datamanagement

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

Pattern #8: Evented

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

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


• Profiling / Performance Messung–Bottlenecks

• Langzeit Archivierung–Vergleichsmöglichkeiten–post mortem Analysen

http://de.wikipedia.org/wiki/Post_mortem

http://de.wikipedia.org/wiki/Post_mortem

Beispiel aus der Praxis

Diskussion der „Patterns“ anhand einer konkreten System-Architektur

fe01 fe02 fe03 fe04

fe09

Public IP range

Private IP range

ha-lb-inthttp

lb05 lb06

ha-lb-fehttplb01

xx.xx.xx.xxlb-webeth1:

xx.xx.xx.xx

lb02eth1:

xx.xx.xx.xx

Port(s): 80/(443)

mc01 mc02

HTTP/HTTPS

Cache

Cache

fe08 fe11

Public IP's:xx.xx.xx.xx/26

fe12 fe13 fe14

fe05 fe06 fe07

mc04mc03

mw01

mw09

mw02

mw07

mw03

mw08

mw04

mw06

ha-lb-intdbslb05 lb06

SQL Writes

SQL Read

SQL Lookup

mw10

mw05

mw14mw12 mw13mw11





store06store05

store14store13

store22store21

store30store29

store08store07

store16store15

store24store23

store32store31

SQL Writes

Reads

MySQLSlavedbs02

MySQLSlavedbs03

MySQLSlavedbs01

MySQLSlavedbs04

WritesMySQLMaster.dbm01

MySQLMaster.dbm02

BinLog Sync

MySQLSlavedbb01

MySQLSlavedbb02

Repl

Repl


MySQLMaster.dbm02


MySQLMaster.dbm02

mgmt01PXESSHpuppetNTP

mgmt02zabbix

test01DEV/TEST

test02DEV/TEST

mgmt02zabbix

mgmt02PXESSHpuppetNTP

logstore01

logstore02

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

http://highscalability.com

http://highscalability.com

http://highscalability.com/blog/2011/4/18/6-ways-not-to-scale-that-will-make-you-hip-popular-and-loved.html








Vielen Dank!

Technology

W jax-2011-web klein