1

Buildfrei skalieren für Big Data mit Z2

Henning Blohm

ZFabrik Software KG5.6.2013

2

Teil 1:

Buildfrei entwickeln und skalieren

Teil 2:

Big Data, Cloud, und wie es zusammenpasst

3

BUILDFREI ENTWICKELN UND SKALIEREN

1. Teil

4

Masterfrage:Warum braucht man mehr als das?

Source code andconfiguration

Execution Environment

5

Bzw. wäre es nicht schön… wenn große Projekte so einfach zu ändern wären wie kleine? wenn Hotfixes ohne Build & Deployment gingen? keinen lokalen Build haben zu müssen? wenn Integration auf Knopfdruck ginge? keinen Appserver installieren zu müssen? nicht mehr deployen zu müssen? wenn Java mit den Roundtripzeiten von Skripten ginge?

6

So funktioniert Z2

Z2-Environment: ■ Pull von verschiedenen Quellen■ Tut was nötig ist (inkl. Kompilation)

7

Entwickeln mit Z2

8

Ausskalieren mit Z2

Siehe auch http://www.z2-environment.net/blog/2013/01/z2-deployment-potpourri/

9

Vorteile

■ Kein build engineeringKeine lokale build config, schnelles setupKeine Build-Infrastruktur!

■ Kleine Checkouts, kein DeploymentWeniger re-compiling, schnelle roundtrips

■ System-zentrischImmer aktuell, immer integriert

■ Pull-AnsatzEinfacher Scale-out

Cost effective

Productive

Scalable

10

Einsparungen*

Pro Entwickler:

* geschätzt

Kleines Entwicklungsteam<=10

Grosses Entwicklungsteam > 10

Lokale Buildkonfiguration 2% 1%

Integration mit Änderungen (sync,. build, re-deployment) 5% 10%

Kommunikation mit Build-Engineer, Anpassen von zentralem Build

2% 4%

Summe 9% 15%

11

Weitere Zutaten

■ Add-On Repositories erweitern FähigkeitenSpring, Hadoop, Vaadin, …

■ Klares, einfaches ModularisierungskonzeptTrennung von API und Implementierung

■ Erprobte ArchitekturFür z. B. modularisierte Spring/Hibernate Anwendungen

12

ERSTE DEMOUpdate einer Web Anwendung

13

Welches Problem wird denn hier eigentlich gelöst?

14

Wenn es größer und modular wird:

Projekt- und Repositorystruktur

≠Ausführungs- & Deploymentmodell

=>

15

Mit anderen Worten:Die beiden verstehen sich nicht.

Deshalb die ganze Maschinerie!

16

BIG DATA MACHT SINN, WENN…2.1. Teil

17

Entscheidungswege NoSQL*

Kein RDBMS, weil…

Nicht-relationale Daten

“Zuviele” Daten

Dokumenten-artig

Graphen Tabellenartig (Big Table)

Dokumente / Blobs

* brutal simplifiziert

18

Zuviele Daten?

Problem ist hierbei in der Regel nicht primär die Ablage, sondern die effiziente Analyse.Hier gilt:

■ Parallelisierung ausnutzen, um O(1) zu bleiben■ Lokales streamen > verteilter Query

=> Der Klassiker: Map/Reduce

19

Problemstellung:

Wie kommt der Code zum Knoten?

Was kann der Code dort machen?

20

Alternativen:

■ Nativ: Map/Reduce API, jar bauen, deploy

Sehr bare-metal. Kein Container-support

■ Vielleich andere Sprache benutzen - Z. B. Pig oder JavaScript M/R?

Gut weil einfacher – aber eingeschränkt!

21

Mit z2@hadoop

Hadoop wird natürlicher Teil der Lösung:■ Ausführung von Z2 in embedded mode als Hadoop task

■ M/R Job „lebt“ im gleichen Modulraum wie der Rest der Lösung

■ Einfachstes Job scheduling: Ohne build und programmatisch

22

ZWEITE DEMOUpdate und Ausführung eines Map/Reduce Jobs

23

UND JETZT ALLE ZUSAMMEN2.2. Teil

24

Cloud-Provisionierungs-Rezept

■ Knotentypen definierenFrontend, Datenknoten, Masterknoten, RDBMS,…Diese müssen vollautomatisch am Leben gehalten werden

■ Welche sind Skalierungsrelevant?Frontend, DatenknotenDiese müssen vollautomatisch installierbar sein

■ Konfiguration mit Policies:■ Alle Konfiguration zentral im SCM■ Alle paar Minuten überprüfung der Knotenpolicy

25

Provisionierung mit CfEngine+Z2

Bemerke: Der Pull Ansatz zieht immer alles gerade!

26

DRITTE DEMOPush der Änderungen ins Produktivsystem

27

Z2 ist Open Source Software!

Interessiert? Ideen?

Wir zeigen gerne mehr Details vor Ort

Bitte einfach bei contact@zfabrik.de melden

28

Hier geht’s weiter:

Wiki:

redmine.z2-environment.netBlog:

www.z2-environment.net/blogSite:

www.z2-environment.eu

Die wachsende Komplexität von Geschäfts- und Internetanwendungen und gestiegenen Erwartungen an die Agilität der Entwicklung haben in den letzten Jahren zu einer beeindruckenden Entwicklung im Bereich der Build- und Integrationswerkzeuge geführt.

Mit Ansätzen wie Continuous Delivery über eine Tool Chain aus Continuous Integration Servern, Artefact Repositories und Build-Werkzeugen wie Maven gelingt es, vollständige Build- und Testautomatisierung für Java-basierte Software-Lösungen zu erreichen.

Mit den Anforderungen an massive und flexible Skalierung in Cloud und Big Data Szenarien hat sich ein weiteres Problemfeld aufgetan: Automatische Verteilung und Konfiguration von Software im Großen. Hier finden Configuration Management Werkzeuge wie Apache Puppet und CFEngine ihre Anwendung.

Die Automatisierung hat allerdings ihren Preis: Je mehr Komplexität in die Werkzeuge wandert, desto Fehleranfälliger wird der Prozess, desto schwieriger wird es, strukturelle Änderungen der Software vorzunehmen.

Dies trifft insbesondere auf den traditionellen „Push“-Deploymentansatz in der Java Entwicklung zu. Ändert sich die Menge der Deployables, so ergeben sich häufig auch nicht-triviale Änderungen entlang der gesamten Prozesskette – vom Entwickler bis zur Konfiguration der Produktivsysteme. Kann die Laufzeitumgebung sich aber selber an Änderungen von Quellen und Konfiguration seiner Systemdefinition anpassen, so entfällt nicht nur ein Großteil der Produktionsinfrastruktur, es werden auch Entwicklungszyklen beschleunigt und frühe Integration gefördert.

Die Open-Source Umgebung z2-Environment implementiert einen solchen “Systemzentrischen” Ansatz, der keine Build-Infrastruktur benötigt, Entwicklersetup minimiert und gleichzeitig Deployment-Updates dramatisch vereinfacht und beschleunigt.

Ein solcher Pull-Deployment Ansatz bewährt sich auch bei der Entwicklung und Ausführung von verteilten Map-Reduce Algorithmen, da kein gesondertes Deployment mehr vonnöten ist und JobImplementierungen mit anderen Anwendungskomponenten gleichgestellt sind. Da keine Applikationskomponenten zu verteilen sind wird auch die automatische Konfiguration mit Hilfe von Configuration Management Werkzeugen einfacher und robuster.

Der Vortrag enthält eine Live-Demonstration auf Basis von CFEngine, Z2 und Apache Hadoop.

Abstract