Das Dokument behandelt die Skalierung und Performance von Web-Applikationen und beschreibt, wie diese zu hohen Verfügbarkeiten und Benutzerzufriedenheit führen können. Es wird betont, dass Skalierung von Anfang an geplant werden muss und dass verschiedene technische Aspekte wie Caching und Datenbankreplikation entscheidend sind. Best Practices werden vorgestellt, um die Effizienz der IT-Operations zu verbessern und Wachstum bei gleichzeitigem Management zu ermöglichen.

1. Raus aus der Garage, rein in den Markt: Skalierung und Performance von Web-Applikationen René-Chr. Glembotzky CommunityCamp Berlin

2. Zur Person René-Chr. Glembotzky 32 Jahre Gründer und Entwickler von free-sms.de mit 1.8 Mio Mitgliedern IT Leiter von goolive.de Community mit 130 Mio. Seitenaufrufen pro Monat

3. Wunschzettel für unsere Webanwendung Hohe Verfügbarkeit Skalierbarkeit Performance Einfache Verwaltung Low Cost Viele Features €€€

4. High Availability... sorgt dafür, dass im Falle eines Ausfalls unsere Website erreichbar bleibt, unsere Nutzer und Kunden zufrieden sind und weiterhin Revenues generiert werden.

5. High Availability... sorgt dafür, dass im Falle eines Ausfalls unsere Website erreichbar bleibt, unsere Nutzer und Kunden zufrieden sind und weiterhin Revenues generiert werden. IT-Leitung behält ihren Job ;-)‏

6. High Availability Redundanz der Systeme 2 Firewalls 2 Webserver 2 Datenbankserver usw...

7. Skalierung Skalierung ist die Eigenschaft einer Plattform oder Anwendung, wachsenden Anforderungen gerecht zu werden und dahingehend vorbereitet zu sein, dass die Systeme bei Bedarf flexibel erweitert werden können.

8. Skalierung Beispiel: Kurzfristig steigender Bedarf an Web- oder Datenbankkapazitäten

9. Was Skalierung NICHT bedeutet Reine Speed-Performance (2 Ghz vs. 3 Ghz)‏ Betriebssystems (Linux vs. Solaris)‏ Technologie (PHP vs. Python vs. Rails)‏ Hardware (AMD vs. Intel)‏ Code Optimierung (10 vs. 10.000 Zeilen Quelltext)‏ Storage Technologie (SAN vs. NAS)‏

10. Skalierung und Performance sind nicht das gleiche

11. Skalierung und Performance sind nicht das gleiche

12. FAKT 1 Eine Anwendung lässt sich nicht skalieren, wenn sie nicht von vornherein dafür konzipiert wurde.

13. FAKT 2 Selbst wenn eine Anwendung für die Skalierung entwickelt wurde, lässt die Entwickler wahnsinnig werden, sobald es erforderlich ist.

14. Unsere neue Website :-)‏ Ein Server Anwendung, Datenbank und Media auf einem System Einfach zu verwalten Keine Ausfallsicherheit

15. Der Programmierer wird unzufrieden Anwendungs- und Datenbankebene werden auf getrennte Server verlagert.

16. Hurra: 1.000 Nutzer Media Files werden auch ausgelagert, um die Webserve mit weniger unnützen Prozessen zu belasten...

17. Das typische Startup-Setup Firewall/Load-Balancer Mehrere Webserver Datenbankserver Internes Storage Leicht zu verwalten Keine Redundanz Günstiger Betrieb

18. Das Startup wird erfolgreicher Redundante Firewall Redundante Load Balancer Mehr Webserver für mehr Performance Datenbank Storage zieht um -> SAN Aus Anwendungssicht relativ simpel...

19. Immenser Gewinn an Popularität Nennung des Startups z.B. bei Digg oder Techcrunch Caching: Reverse Proxy (Squid/Varnish)‏ Mehr Webserver Replikation der Datenbank Applikation überarbeiten :-)‏

20. Immenser Gewinn an Popularität

21. Point of no return... Caching mit Memcached Datenbankreplikation „gibt auf“ Datenbankpartitionierung macht Sinn Mediacluster für Content Neustrukturierung der Applikation und Datenbank erforderlich

22. Point of no return...-

23. Wir erinnern uns....

24. PANIK! Überdenken des Geschäftsmodells Überarbeitung der gesamten Applikation Datenbankstrukturierung anhand von „weichen“ Features Partitionierung nach Herkunft, Nutzer ID, Themengebiet Einsatz eines „Finde-Mechanismus“, um herauszufinden, welcher Nutzer in welchem Cluster beheimatet ist

25. Zurücklehnen... Applikation und Datenbank sind skalierbar Performance ist „in Ordnung“ Neue Features werden wieder entwickelt Code wird teilweise optimiert Wachstum, aber managebares Wachstum

26. Best Practices Trennung des IT-Bereichs in Development & Operations Das Rad nicht zweimal erfinden. Vorhandene Lösungen nutzen. Einfaches soll so einfach wie möglich gemacht werden (aber nicht einfacher *g*)‏ Gutes Equipment verwenden (Sun, Dell)‏ Dienste trennen, „sanfte Updates“ -> Troubleshooting

27. Best Practices Keine Über-Optimierung der Software -> bei Bedarf step-by-step anpassen Last-Tests der Applikation -> bevor es live zu Problemen führt Caching! Caching! Caching! Memory! Memory! Memory! (64 bit)‏ Nice to have vs. have to have -> Performance Analyse neuer Features

28. Best Practices Software-Dokumentation Release Management -> Entwickeln, Testen, Releasen Source Control

29. Schönes Wochenende :-)‏ [email_address]