Google App Engine. Zwei Jahre im Produktiveinsatz

2 Jahre mit Google App EngineErfahrungen und Probleme, Stärken und Schwächen. Ein Praxisbericht.

Per Fragemann, Java User Group Berlin, Dezember 2012

Mittwoch, 19. Dezember 12

Tagesordnung1. Motivation2. Technischer Überblick3. Datenbank4. Services5. Betrieb & Lessons learned6. Bewertung & Diskussion


Software as a Service

Erster Prototyp 2010, direkt auf GAE

5 Mitarbeiter

Über uns


Unsere Kunden


Tools


2: ÜBERBLICKMittwoch, 19. Dezember 12

GAE ist performant

• Innerhalb eines SDKs programmieren, JAR hochladen, fertig

• Automatische Skalierung: Manche haben 1 Server-Instanz, andere haben 2000

• Kein Admin notwendig


GAE ist PAAS

• Jetty, Datastore, Services & APIs• Sehr mächtige Admin Console• Kein direkter Zugriff auf Server oder

VMs!

PAAS != IAAS


Prinzipieller AufbauApplication

Version A (default)

Fi A1 Fi A2 ... Fi An

Version CVersion B

ApplicationApplication


Instances: Frontends• Optimiert für Web Requests• 3 Leistungsstufen F1, F2, F4• Automatisches Skalieren:

• Keine Sticky Sessions• 30-Sekunden-Limit• Gemeinsamer Zugriff auf DB & Services


Instances: Backends

• Optimiert für längere Aufgaben• 4 Leistungsstufen B1 - B4• Extern adressierbar• Skalieren nicht, man bucht sie nach

Bedarf


Unser Setup Demo time!


3: DATENBANKMittwoch, 19. Dezember 12

Datastore

• NoSQL:• Perfekt für große Datenmengen• Sehr einfach änderbar

• Bis vor kurzem einzige Persistenz-Lösung


It’s not SQL!• Keine Joins• Stark begrenzte Queries

• kein OR, kein NOT, ineffizientes IN • keine functions wie count oder avg()

• Transaktionen nur auf sog. Entity-Groups


Beispiel• Alle Nerd-Shirts von “Per”, sortiert nach

Firmenname


Beispiel• Alle Nerd-Shirts von “Per”, sortiert nach

Firmenname

Nerd-ShirtID

userID companyIDuserName

companyName

UserID

namecoding skills

CompanyID

namecountry


Eventual Consistency

• Objekt wird gespeichert.• Objekt wird aber erst nach einigen

Sekunden lesbar• Problem: Denormalisierung vs Eventual

Consistency


Datastore (2)• Eigentlich ist Datastore für uns zu groß• Latenzzeit höher als bei typischer DB• Vorteil: Programmierung für Datastore

sehr gut abschätzbar. • Keine Überraschungen wie Deadlocks,

Performance Degradation etc


Low Level API

ARGH!


JDO/JPA

ARGH!


Objectify

Objectify ofy = ObjectifyService.begin();Query<User> userQuery = ofy.query(User.class)

.filter("boss", viewedUser)

.filter("isActive",true);List<User> teamMembers = userQuery.list();

Easy! And has caching!


4: SERVICESMittwoch, 19. Dezember 12

Push Queue

• Web Hooks: URL verzögert aufrufen• Queues haben Durchsatz-Limits, Retry-

Regeln• Man umgeht 30-Sekunden Limit• Last-Steuerung• Gut kombinierbar mit Cron Jobs


Pull Queue

• Eigene Applikation muss sich um Abarbeitung kümmern

• Feinere Steuerung möglich• Queue kann auch mit REST abgefragt

werden


Memcache• Zugriff auf DB ist langsam• Je weniger Zugriffe pro Request desto

besser• Alles wichtige immer in Memcache

speichern• Memcache ist Instanz-übergreifend


Data Caching

Data Store

Memcache

2 n3 ...1Instance-cache &Request-cache


PageSpeed Service

• Optimiert vollautomatisch das Frontend• JS minification & combination• Image optimization• CSS inlining

• Regeln frei wählbar

https://developers.google.com/speed/docs/mod_pagespeed/config_filters




MapReduce• Parallele Bearbeitung großer

Datenmengen• Nicht auf GAE beschränkt• Aber GAE sehr gut geeignet• Terabytes von Daten, Hunderte von

Servern? Kein Problem.

http://www.youtube.com/watch?v=EIxelKcyCC0




Easy deployment

• “ant update”


Appstats


5. BETRIEB


Unerklärliche Fehler• Es können auch jederzeit einfach so

Fehler auftreten, z.B. “bei 5% aller Requests”

• Man kann dies im Forum und im Issue Tracker melden. Und dann beten.

• Meistens werden sie innerhalb einiger Stunden bis Tage gelöst.


Uptime

• Komplettausfälle sind extrem selten. 2 Mal in den letzten zwei Jahren• 3 Stunden Ende Oktober• 20 Minuten Mitte November


Latenzzeit

• Keine Garantien!


Startup Time• Kein Request darf mehr als 30

Sekunden dauern• Oft genug drückt App Engine ein Auge

zu• Aber nicht immer! • Manchmal ist 10s das Limit!


Startup Time (2)• Application Startup muss schnell

gehen! • besser kein Spring benutzen..• Abhängigkeiten gering halten• Classloading verschieben• Lazy Initialisation (“is

loadingRequest?”)• .. und allgemeines Performance Tuning


Drum prüfe wer sich ewig bindet...

• Nicht alle Libraries/Tools unterstützt• Teilweise vorher klar, teilweise aber

auch nicht• z.B. starke Verschlüsselung


Fortschritte in 2012• HTTPS on custom domains

• Cloud SQL

• Starke Verschlüsselung (z.B. BouncyCastle)

• Eigene Threads

• Volltextsuche

• Backup/Restore

• Traffic Splitting

• Page SpeedMittwoch, 19. Dezember 12

6: Bewertung


Insgesamt sehr positiv

• Sehr robuste Administration • Sehr hohe Verfügbarkeit• Gute Performance• Skalierbarkeit


Kosten• Pro Lese & Schreibzugriff• Pro gespeichterten Daten• Pro CPU Time• In 2011 überraschend stark gestiegen• Google’s Kommunikation nicht ideal• Aber man spart immer noch deutlich

Personalkosten


• Startups in B2B

• “Dev-Startups”

• Prototypen

• Risikoaverse Firmen

• Sehr komplexe Applikationen

• Sehr langfristige Projekte

Perfekt für: Finger weg:

Geeignet für: Kritisch evaluieren• Startups in B2C (Kosten

bedenken)

• Nicht-kritische Projekte, auch in traditionelleren Firmen

• Kernprodukt einer bestehenden Firma

• >99.9 Uptime


Habe fertig!

We’re hiring.500€ Refer-a-friend Bonus!


Google App Engine. Zwei Jahre im Produktiveinsatz

Technology

Transcript of Google App Engine. Zwei Jahre im Produktiveinsatz