Auch Entwickler brauchen Platz zum Spielen

15. Juni 2021 /

Content Delivery Network (CDN) von Google für Eigenprojekte nutzen

Mit App Engine stellt Google jedem ambitionierten Programmierer eine skalierbare Entwicklungsumgebung bereit, die sich in Punkten Performance, Speicher und Bandbreite an die wachsenden Ansprüche der Anwendungen dynamisch anpasst. Ursprünglich für Ausführungen komplexer Java- und Python-Skripte angelegt, kann auf Google App Engine gleicherweise statischer Content geparkt und in eigenen Seiten vorteilhaft eingebunden werden. Mit CDN als Turbo.

Länge, die in die Tiefe geht
Cloud Computing und CDN – nie etwas davon gehört? Im Unterschied zu den nahezu unzählig vorhandenen Beiträgen à la „Nutzen Sie CDN, um Ihre Webseiten zu beschleunigen“ bleibt der Leser nach diesem Artikel nicht unwissend im Regen stehen. Der Bericht geht gleichermaßen auf die praktische Seite der Nutzung eines CDN ein, konkretisiert die Pluspunkte solch eines Netzwerks für den Website-Entwickler und erläutert in einfachen, für Einsteiger verständlichen Schritten die Inbetriebnahme der praktischen Lösung. Legen wir mit Verständnisfragen los.

Die Flugzeug-Turbine steht für (Webseiten-)Turbo
App Engine: Die Flugzeug-Turbine steht für (Webseiten-)Turbo

Was ist ein CDN und welche Aufgabe hat es zu erledigen?
CDN steht für Content Delivery Network – ein intelligent ausgelegter Verbund aus mehreren kontinental zerstreuten Servern bzw. Server-Farmen. Die zu erfüllende Mission: Je nach geografischem Standort der Webseiten-Besucher reagiert der nächstgelegene Server auf die Browser-Anfrage und kann die angeforderten Daten prompter, also zeitsparender ausliefern als der Konkurrent auf gegenüberliegender Welthälfte. So teilen sich die Rechner im Verbund die Last und das Traffic-Aufkommen, sichern aber auch die höchste Erreichbarkeit und die niedrigste Ladezeit der dort gehosteten Webseiten oder statische Objekte. Eine „Win-Win“-Situation, sozusagen.

Ein banales Quiz zum Verständnis: Eine durchschnittliche Webseite sendet circa 20 Anfragen an den Server, um für die Darstellung notwendige Informationen zu erhalten. Wann sind die Daten schlagartiger zurück?

  • A. Wenn sich der zuständige Server „um die Ecke“ befindet
  • B. Wenn die Anfrage um den halben Globus geht

Für größere Websites mit internationalem Publikum empfiehlt sich zweifellos ein Hosting-Provider mit angelegtem CDN (z.B. Amazon CloudFront). Dank der Ortung anhand von IP-Adressen treffen statische Files wie Bilder, CSS oder JavaScript im Browser der Kunden zügiger ein. Was bringt diese Erkenntnis wiederum für den Website- bzw. Shop-Betreiber (Produktbilder sind die besten Kandidaten)?

  1. Konsumenten bedanken sich für flottes Laden der Inhalte (und kaufen nachweislich mehr, denn jede Sekunde zählt).
  2. Google als Suchmaschine lässt die technische Performance einzelner Pages ins Ranking einfliessen (wer braucht da noch Suchmaschinenmarketing).

Handeln ist angesagt!

Google mit eigenem Content Delivery Network
Wie bei der Einleitung oben bereits erwähnt, gehört auch Google App Engine zum kleinen, jedoch sehr feinen Kreis der Anbieter, die ihre Infrastruktur um das Content Delivery Network bereichert haben und gestellte Requests dementsprechend auch IP-bezogen verarbeiten.

Bedauerlicherweise kann Google mit keiner Anbindung an die lokal verfügbaren Server innerhalb Europa dienen (Amazon CloudFront dagegen in den USA, Europa und Asien „vertreten“), so dass beispielsweise Anfragen aus Deutschland von den in Amerika ansässigen Webservern entgegengenommen und abgearbeitet werden (einer der Server). Kleiner Wermutstropfen: Die Reaktionszeiten der ausländischen Google-Rechner sind beeindruckend geringfügig, kaum ein deutscher Hoster kann mit solch winzigen Millisekunden konkurrieren. Glück im Unglück, quasi.

Im Übrigen lässt Google eigene Applikationen ebenfalls auf den selben Maschinen hosten bzw. laufen wie die App Engine Anwendungen der Dritthersteller – Google Closure Compiler sei als Beispiel genannt. Das kann als Garant für ununterbrochene Stabilität und langfristige Zuverlässigkeit des CDN-Hosters aus Mountain View verstanden werden.

Zusätzlicher Nutzen des Hostings bei Google App Engine
Alleine wegen eines bereitgestellten CDNs wäre Googles App Engine für deutschsprachige Websites nicht interessant genug gewesen, wenn da im Zusammenhang nicht noch weitere, für Webworker recht spannende Instrumente dabei wären, welche „die Cloud“ attraktiv gestalten (lassen). Fassen wir weitere Vorteile von Google App Engine ausführlich zusammen:

1. Kostenlose Nutzung des Dienstes
Jede bei Google App Engine angelegte Anwendung (in unserem Fall sind es Projekte mit statischen Inhalten) verfügt über ausreichend CPU, Bandbreite und Speicher. Fünf Millionen Aufrufe pro Monat kosten keinen Cent. Darüber hinaus wird nach CPU-Stunden oder Gigabyte-weise abgerechnet, wobei sich die jeweiligen Einheiten in Cent-Bereichen befinden (dazu die Preistabelle). Keine monatlichen Bindungsverträge et cetera.

Nutzungsstatistik auch für kostenfrei verfügbares Kontingent
Nutzungsstatistik auch für kostenfrei verfügbares Kontingent

2. Gesonderte, Cookie-freie (Sub)Domain
Je nach Wunsch kann das Projekt bei App Engine mit einer eigenen Domain verknüpft werden, Anfragen an statische Daten werden z.B. auf static.domain.de umgeleitet. Verzichtet man auf die Verknüpfung der eigenen Domain mit angelegtem App Engine Project, so ist die öffentlich erreichbare Subdomain xxx.appspot.com (xxx steht dabei für den Projektnamen) das neue Zuhause der im Webseiten-Quelltext referenzierten Dateien.

Irrelevant wofür sich der Entwickler letztendlich entscheidet (eigene Domain oder doch ohne), in beiden Fällen werden beim Datenabruf – etwa die Darstellung der Bilder oder Einbindung von CSS – seitens Google keine Cookies mitgeschickt, gesetzt oder ausgelesen. Frei von jeglichen Cookies für noch weniger Bytes beim Austausch zwischen dem Server und den Clients.

Pluspunkt: Je nach Alter können diverse Browser lediglich eine begrenzte Anzahl an gleichzeitigen Anfragen pro Domain stellen. Kommt eine abweichende Domain bzw. Subdomain als eine weitere Datenquelle ins Spiel, kommt es zwangsläufig plötzlicher zur Fertigstellung des Ladevorgangs.

Beide Punkte (abweichende Domain + keine Cookies) werden von Page Speed und Yahoo! YSlow als relevant eingestuft und sollen daher Beachtung finden.

Analyse-Tools bewerten die Webseiten nach mehreren Kriterien
Analyse-Tools bewerten die Webseiten nach mehreren Kriterien

3. GZIP-Komprimierung und Caching von Dateien
Komprimierfähige Dateien wie beispielsweise Stylesheets und JavaScript werden von Google in gestraffter Form verschickt und auf der Client-Seite (in diesem Fall ist es der Browser) entpackt. So wird Traffic gespart und die Geschwindigkeit der Datenübertragung zusätzlich gesteigert. Google App Engine erkennt solche Dateien selbsttätig und behandelt sie mit der GZIP-Komprimierung, ohne dass der Administrator des Accounts dafür aktiv werden muss (z.B. Modifizierungen am Server oder an der .htaccess).

Nach wenigen manuellen Korrekturen versieht der App Engine Server den ausgehenden Datenstrom mit korrekten Headern, die nachhaltig und effizient dafür sorgen, dass die im Browser-Cache abgelegten Elemente bis auf Widerruf dort aufbewahrt und für die Anzeige verwendet werden sollen. Unverzügliche Darstellung im Browserfenster und ökonomische Anfragestellung zum entfernten Server ergeben sich im Endeffekt.

GZIP-Komprimiert und in den Browser-Cache befördert
GZIP-komprimiert und in den Browser-Cache befördert

4. Traffic-Einsparung und Server-Schonung
Durch die Auslagerung der statischen Files auf den Google-Server kommt der eigene Server (hoffentlich) zur Ruhe und kann sich um andere Rechenaufgaben wie z.B. die Generierung von dynamischen Inhalten kümmern. Die Praxis bestätigt immer wieder aufs Neue: Nach der Ausgliederung pendelt die Serverlast spürbar zurück.

Live-Beispiel der Implementierung
Um das Hosting der Daten auf bzw. in Google App Engine und die entsprechende Integration der Quelle im XHTML-Gerüst zu demonstrieren, wurden statische Elemente (Stylesheets und Grafiken) meiner Portfolio-Website eBiene.de auf Google als eigenständiges Projekt ausgelagert. Es ging nicht um die Notwendigkeit, vielmehr um die Machbarkeit der Realisierung.

Wir verlassen an dieser Stellen den theoretischen Part des Artikels. Der praktische Teil spezifiziert, wie Objekte zu Google App Engine übertragen und in die Projektseiten eingebunden werden. Spot ab!

1. Projekt anlegen
Auf der Google App Engine Website gelangt man nach der Registrierung bzw. Anmeldung (Keine Abfrage von Konto- oder Kreditkartendaten, dafür eine kostenfreie Verifizierung per SMS notwendig) auf die Übersichtsseite der gegenwärtigen Projekte. Sind keine Projekte bis dato existent, hat man eine direkte Möglichkeit den Namen für das neue Projekt zu vergeben. Der Projektname mutiert zugleich zur Subdomain von appspot.com (cdn.appspot.com ist in unserem Beispiel die entsprechende Subdomain). Die systemweite Eindeutigkeit des Application Identifiers hat den bitteren Nachgeschmack, das die Vielzahl der möglichen Namen von anderen Teilnehmern bereits genutzt und somit längt vergeben ist. Kreativität ist also gefragt.

Ist die Applikation erfolgreich angelegt, bekommt Developer die Gelegenheit auf das Projekt-Dashboard zu springen: In der Zusammenfassung werden Statistiken für jegliche Art an Verbrauch chronologisch abgebildet. CPU-Gesamtzeit, aufgebrauchte Bandbreite und so weiter.

Application Identifier als Subdomain
Application Identifier wird zur Subdomain des Projektes

2. Upload-Client in Betrieb nehmen
Die Nutzung des Dienstes wird durch die fehlende Möglichkeit erschwert, Daten auf die bekannte Weise via lokales FTP-Programm zum Google-Server zu übertragen. Für diesen Zweck existiert u.a. ein Entwickler-Werkzeug in Form einer smarten Anwendung, die einen vorher definierten Ordner samt Inhalt (Verzeichnisse, Files) auf den entfernten Rechner dupliziert: Ein Klick auf Deploy gleicht den Bestand der Datenstruktur ab.

Auf der offiziellen Download-Seite wird Google App Engine SDK für das gewünschte Betriebsystem heruntergeladen und installiert. Im geöffneten Tool-Fenster kann über das Menü eine New Applikation angelegt werden: Application Name ist der eben im Web gewählte Application Identifier, Application Directory ist der Ort auf der heimischen Festplatte, der als Referenz für die Spiegelung der Dateien gelten soll. Port ist 8080, andere Optionen bleiben unberührt.

Google App Engine Launcher
Lediglich 2 Felder pro Projekt gehören ausgefüllt

3. Statische Inhalte in Google App Engine definieren
Die Applikation wird nach dem Klick auf den Button Create als entsprechender Listeneintrag im Client und auf der Festplatte im gleichnamigen Ordner angelegt. Navigiert man dahin, werden dort 3 Standard-Systemdateien vorgefunden:

  • app.yaml
  • index.yaml
  • main.py

Im Verzeichnis werden nun Unterordner für statische Inhalte erstellt. Exemplarisch: css und img, wo jeweils Stylesheets und Bilder separiert aufbewahrt werden. Neu hinzugefügte Ordner gehören in der Konfigurationsdatei app.yaml als Ordner mit nicht dynamischem Content deklariert. Die Datei app.yaml passen wir nun händisch im Texteditor an – nach der Änderung sieht sie wie folgt aus (wobei xxx für den Projektnamen steht):

application: xxx
version: 1
runtime: python
api_version: 1

default_expiration: "365d"

handlers:
- url: /css
  static_dir: css

- url: /img
  static_dir: img

Der Parameter default_expiration kommuniziert die Tagesanzahl für das Caching, die der Server wiederum an den Browser sendet. Der Wert ist variabel.

Ordnerstruktur einer App Engine Application
Exemplarische Ordnerstruktur einer App Engine Application

4. Hochladen und im XHTML einbinden
Befinden sich nun Dateien in den erstellten Ordnern, so können diese via Schaltfläche Deploy auf den Server gespiegelt werden. Im zusätzlich eingeblendeten Fenster zeigt die Anwendung den Ablauf der laufenden Aktion und weist auf eventuelle Fehler hin.

Geglückter Upload sichert die Erreichbarkeit der übertragenen Dateien unter der bekannten Subdomain. Ein Test in der Adresszeile des Browsers genügt als Bestätigung. Fällt die Prüfung positiv aus, kann die Statik im Quelltext der Webseiten referenziert werden.

Das waren die vier Schritte, die für den Umzug vom traditionellen Hoster auf Google App Engine notwendig waren. Leider erkennt Yslow die Google App Engine Plattform nicht als vollwertigen CDN-Hoster. Das liegt an der Tatsache, dass Google im Analyse-Tool nicht als solcher hinterlegt ist. Yahoo! verrät, wie die interne Liste um weitere CDN-Provider erweitert werden kann.

Fazit
Google App Engine ist eine perfekte Alternative zum gewöhlichen Webhoster, wenn es darum geht, statische Medien sinnvoll und gewinnbringend auszulagern. Ob eine Website für diesen Zweck groß genug, die Zielgruppe ausreichend international und die angesprochene Upload-Lösung bequem ist, entscheiden ganz alleine die Projektmacher. Als kostenloser Einstieg ins Cloud Computing ist Google App Engine jedoch wärmstens zu empfehlen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.