Softwareentwicklung in der industriellen Praxisst.inf.tu-dresden.de/files/teaching/ws12/ring/121126... · 2012. 11. 27. · Softwareentwicklung in der industriellen Praxis Cloud-Systeme:

Softwareentwicklung in der industriellen Praxis

Cloud-Systeme: Besonderheiten bei Programmierung und Betrieb

Steffen Gemkow / Paul Fritsche - ObjectFab GmbH

26.11.2012

Montag, 26. November 12

• Simple is beautiful

• Don’t repeat yourself (DRY)

• Scalability >> Performance

• Design for scalability


Überblick

• Aufgabe

• Architektur

• Deployment und Betrieb

• Programmierung

• Fazit


Aufgabe

• Webanwendung

• Agile Entwicklung

• hohe zu erwartende Last

• viel dynamischer Inhalt

• geringe laufende Kosten


Webanwendung

• Integrationsplattform

• Login und Rollensystem

• Anbindung vieler externer Dienste und Datenquellen


Dynamischer Inhalt

• Webseite läd asynchron Daten nach (AJAX)

• viele kurze Requests anstatt weniger langer

• Requests an unterschiedliche Ziele

• Chat (Websockets/Longpolling)


Agile Entwicklung

• viele Details liegen noch im Dunkeln

• konkretes Layout

• Usability

• Features

• Prototyp, schnelles Feedback, kurze Iterationen


Lastverhalten


Cloud

• dynamisches Hinzufügen/Entfernen von Serverkapazitäten

• virtuelle Hardware


Cloud Anbieter

• Amazon Elastic Compute Cloud (EC2)

• JiffyBox

• Scalarium

• Heroku


Festlegungen

Technologie Ruby on Rails, Websockets, SSL

Vorgehensmodell kurze Iterationen (1-2 Wochen)KanBan / Scrum

Lastverhalten tageszeitabhängigca. 1000 parallele Nutzer

Cloudanbieter JiffyBox von DomainFactory


ArchitekturLB

WEB WEB APP APP APP CHAT

CACHE

DB


WebserverLB


CACHE

DB


Webserver

• liefert statischen Inhalt

• Bilder, CSS, JS

• führt kein Applicationcode aus

• braucht wenig CPU, wenig Speicher

• Apache, nginx


Application ServerLB


CACHE

DB


Application Server

• führt die Rails Umgebung inkl. der Anwendung aus

• jeder Request benötigt eine Rails Umgebung (= Prozess)

• Phusion Passenger:

• startet mehrere Rails Prozesse

• verteilt Requests


Chat ServerLB


CACHE

DB


Chat Server

• Chat benötigt Rückkanal für Nachrichten vom Server zum Client

• Websockets / Longpolling

• würde viele (teure) Rails Prozesse blockieren

• event-driven, non-blocking IO

• viele Requests in einem Prozess

• node.js, Evented Ruby


CacheLB


CACHE

DB


Cache

• korrekt eingesetzt bringt Caching sehr hohen Performancegewinn

• Session

• Datenbankabfragen

• komplette HTML Seite

• Teile einer HTML Seite

• memcached


Load BalancerLB


CACHE

DB


Load Balancer

Regel Aktion

Port 80 Redirect auf Port 443

wss://* chat

https://static* web0..webX (load balanced)

* app0..appY (load balanced)


Eingesetzte Software

Ruby RVM mit Ruby 1.9.2

LB haproxy mit SSL

WEB Apache 2

APP Phusion Passenger

CHAT Node.JS

CACHE memcached

DB mysql


Deployment

• Wer betreibt den Cluster?

• Wie wird die notwendige Software installiert?

• Updates?

• Wie wird die Anwendung ausgerollt?

• Neues Release?


Dokumentation

• Auflistung sämtlicher zu installierender Software, inkl. Version

• Konfigurationsdateien

• Im Idealfall 2 Dokumente:

• Installationsanweisungen für “frisches” System

• Änderungen zur Vorversion


Script

• Ausführbare Dokumentation

• Installiert Software parallel auf mehreren Servern

• Erstellt Konfigurationsdateien

• Startet/Stoppt alle Dienste

• wiederholbar, parameterisierbar


Capistrano• Führt SSH Befehle auf mehreren Rechnern parallel aus

• Rezepte:

• Ausführung vor oder nach einem anderen Rezept

• parallel auf mehreren Rechnern

• Rollen:

• Jeder Rechner hat eine oder mehrere Rollen

• Jedes Rezept gehört zu einer Rolle


Capistrano

• bietet fertige Rezepte zum Deployment einer Rails Anwendung

• zusätzliche Rezepte zum Installieren der Software

• Anbindung an JiffyBox-API


Programmierung

• Kenntnisse in vielen Programmiersprachen/Frameworks notwendig

• Ruby/Rails

• Javascript/Coffeescript, HTML/CSS

• Linux, Bash


Programmierung

• viele kurze Requests >> wenige lang laufende Requests

• Rails Prozesse sind “teuer”

• effektivere Auslastung der gesamten Cloud

• Trend zu non-blocking IO


Programmierung

• Requests werden von verschiedenen Prozessen verarbeitet

• keine Singletons im Programmcode

• DB / Cache zum Synchronisieren (z.B. Sessions)


Programmierung

• Am längsten dauert das Erzeugen des HTML in einem Request

• soviel wie möglich cachen

• Daten und Inhalte asynchron laden


Programmierung

• Externe Daten in einem Request

• asynchrone Aufrufe (non-blocking IO)

• im Hintergrund laden und zwischenspeichern (Cache oder DB)


Fazit

• komplexe Architektur

• wiederholbares Installieren/Konfigurieren aller beteiligter Systeme

• wiederholbares Deployment der eigentlichen Anwendung

• einfacher Aufbau verschiedener Test- und Stagingsysteme

• Grundlage zur dynamischen Steuerung der Cloud

• Integration in CI möglich


Fazit

0

2000

4000

6000

8000

100 200 500 1000

Ant

wor

tzei

t in

ms

Anzahl Nutzer

5x Level 1 (4P) 10x Level 1 (4P) 5x Level 2 (16P) 5x Level 3 (16P)


Vielen Dank

• http://www.objectfab.de/download/121126_vortrag.pdf

• Kontakt:

• http://www.objectfab.de

• [email protected], @ObjectFab

• [email protected], @synopia

• http://www.ruby-dresden.de, 6.12.2012 nächstes Treffen


http://www.objectfab.de/download/211126_vortrag.pdf

http://www.objectfab.de/download/211126_vortrag.pdf

http://www.objectfab.de

http://www.objectfab.de

mailto:[email protected]




http://www.ruby-dresden.de

http://www.ruby-dresden.de

Documents

Softwareentwicklung in der industriellen Praxisst.inf.tu-dresden.de/files/teaching/ws12/ring/121126... · 2012. 11. 27. · Softwareentwicklung in der industriellen Praxis Cloud-Systeme: