Content Delivery Networks sind mittlerweile äußerst erschwinglich geworden und können eine erhebliche Entlastung für Webserver darstellen. Was ein CDN ist und wie es mit WordPress interagieren kann, möchte ich in diesem Beitrag kurz und in Form einer Schritt für Schritt Anleitung darstellen.

Was ist ein CDN?

Ein CDN, die Abkürzung für Content Delivery Network, ist ein Verbund an Servern, die auf der Welt verteilt sind und Webinhalte schneller an die Nutzer ausliefern sollen. Dabei werden die Inhalte und Funktionsweisen des CDN durch den Webseitenbetreiber gesteuert und die Benutzer sind im Gegensatz zu klassischen Proxy Servern “gezwungen” die Inhalte dort abzuholen.

Üblicherweise besteht eine Webseite aus Texten, Bildern und gegebenenfalls auch Programmen (JavaScript, Java, Flash, etc.). Alle diese Daten werden durch den Webserver an den Besucher einer Seite ausgeliefert. Technisch gesehen holt der Browser zunächst eine HTML Seite vom Server, in der dann alle weiteren zu ladenden Daten (Bilder, etc.) verzeichnet sind. Die vom Browser angeforderten Daten nehmen dabei den Weg vom Server des Webseitenbetreibers durch das Internet bis zum Computer des Nutzers, ein gegebenenfalls recht langer Weg.

Schon relativ früh in der Entwicklung des Internets wurden sogenannte Proxy (Stellvertreter) Server etabliert. Diese wurden zwischen dem Computer des Seitenbesuchers und dem Webserver geschaltet. Der Browser hat nun seine Anfragen an den Proxy gerichtet, der die Anfrage dann an den Webserver weitergereicht hat um von diesem dann die Daten zu erhalten und an den Enduser durchzureichen. Gleichzeitig aber hat der Proxy, der sich netztechnisch in der Nähe des Endusers befindet, die Daten bei sich zwischengespeichert. Hat nun ein weiterer User die Seite oder Elemente daraus angefragt, so konnte der Proxy diese an den Browser senden, ohne dass der Webserver noch einmal kontaktiert werden musste. Für den zweiten User sollte sich damit eine schnellere Antwortzeit ergeben und insgesamt weniger Daten über das Netzwerk transferiert werden. (Von einer Erläuterung weiterer Vorteile, wie Anonymisierungen, Filter, etc., die sich durch einen Proxy ermöglichen lassen, sehe ich hier einmal ab.)

Das CDN übernimmt eine ähnliche Funktion wie ein Proxy, nur dass es unter der Kontrolle des Webseitenbetreibers steht, alle User ausgewählte Inhalte von dort beziehen müssen und durch eine möglicherweise gute, weltweit verteilte Platzierung der CDN Server ein Geschwindigkeitsvorteil erzielt werden kann. Damit das CDN Inhalte ausliefern kann, müssen diese auf die ein oder andere Weise zunächst auf das CDN hochgeladen werden und in den HTML Seiten das CDN für die entsprechenden Inhalte dann auch die passenden Referenzen eingepflegt werden. Faktisch bedeutet dies, dass zum Beispiel das Logo der Webseite nicht vom Webserver selber geladen wird, sondern von einem anderen Server des CDN Providers. Hierbei handelt es sich dann allerdings nicht um einen Server, sondern um viele in der Welt verteilte mit einer entsprechenden Intelligenz, so dass immer der für den User am nächsten liegende Server die Daten an den Browser sendet.

Anbieter für CDN

Was bis vor wenigen Jahren nur großen und zahlungskräftigen Firmen vorbehalten war, ist nun äußerst erschwinglich (einstelliger Euro Betrag pro Monat) und damit auch für Blogger interessant. Angeboten werden Content Delivery Networks von den Großen wie Google und Amazon, aber auch zahlreiche kleinere Firmen bieten entsprechende Lösungen an.

Bei der Auswahl des richtigen CDN Anbieters lohnt sich eine genaue Analyse der Zielgruppe der Webseiten. Wer seine Inhalte vorwiegend einem deutschen oder europäischen Publikum präsentieren möchte, ist mit einem gut positionierten, lokalen Anbieter möglicherweise auch gut bedient und muss nicht einen global Player einsetzen. Doch bei den äußerst überschaubaren Kosten ist auch die Nutzung der Profi Infrastruktur von Amazon AWS oder Google nicht von der Hand zu weisen.

In diesem Beitrag zeige ich die Einrichtung und Nutzung eines CDN aus dem Portfolio von Amazon, das ich für diese Webseite auch selber nutze: AWS CloudFront.

Push oder Pull

Inhalte, die das CDN anstelle des eigentlichen Webservers ausliefern sollen, müssen zunächst auf das CDN gespeichert werden. Hierzu bieten sich zwei Optionen an, die beide ihren Charme haben:

Im Push Verfahren ist der Webseitenbetreiber selber verantwortlich dafür, dass die Inhalte (Bilder, JavaScript Dateien, etc.) auf das CDN hochgeladen werden. Bei AWS kann dies in den sogenannten S3 Storage geschehen. Dies kostet einen überschaubaren Betrag extra und kann durch WordPress Plugins bei Verwendung dieses Content Management Systems dem User abgenommen werden. Dieses Verfahren lohnt sich für Inhalte, die sich sehr selten bis nie verändern.

Bei der zweiten Variante setzt man rein auf das AWS CloudFront. Dabei funktioniert das CDN im wesentlichen exakt wie ein oben beschriebener Proxy: Wird eine Anfrage an das CDN gerichtet, lädt dieses die Daten zunächst vom Webserver, speichert sie zwischen und sendet sie zugleich an den anfragenden Nutzer. Weitere Nutzer profitieren dann von den bereits zwischengespeicherten Daten. Damit die Daten im CDN nicht veralten, wird nach einer variabel einstellbaren Zeit der Inhalt vom Webserver neu geladen und damit gegebenenfalls aufgefrischt.

Beide Varianten haben ihre Vor- und Nachteile, so dass eine Kombination aus beiden die Ideallösung darstellt. Doch eine entsprechende Konfiguration und Pflege ist recht aufwändig, so dass ich mich im folgenden auf die Variante zwei fokussieren werde.

AWS CloudFront

Der erste Schritt ist die Anmeldung bei einem entsprechenden CDN Provider, in meinem Fall Amazon mit seinem Dienst AWS CloudFront. Viele Anbieter bieten einen kostenlosen Testmonat an. Auch ist die Nutzung oftmals ohne fixe Grundgebühr möglich, so dass bei keiner Nutzung auch keine weiteren Kosten anfallen. Die Abrechnung ist in der Regel verbrauchsabhängig. Je mehr Inhalte über das CDN verteilt werden, desto mehr betragen die monatlichen Gebühren.

Zunächst ist ein kostenloses Konto bei Amazon AWS zu erstellen. Hat man dies erfolgreich absolviert, erhält man Zugriff auf die (erbärmlich langsame) AWS Management Console. Von diesem Zeitpunkt an ist man dann allerdings vorwiegend auf die englische, sehr technische Sprache angewiesen.

In der oberen, rechten Ecke sollte zunächst die Lokation gewählt werden, die dem Zielgebiet für die Dienste am nächsten liegt. Für Leistungen in und für den deutschen Raum, sollte damit Frankfurt ausgewählt werden.

Aus dem riesigen Angebot an Diensten (Services) sind für das CDN nur zwei bis drei erforderlich:

• Identity & Asset Management (IAM)
• CloudFront und
• gegebenenfalls Billing und Cost Explorer um später die Abrechnungen einsehen zu können.

Das Identity & Asset Management ist eine Nutzerverwaltung über die auch die Berechtigungen auf die einzelnen Dienste sehr umfangreich und komplex eingestellt werden können.

User via IAM einrichten

Die Kommunikation zwischen der WordPress Installation und AWS CloudFront erfordert eigene Zugangsdaten. Außerdem sollte der neu anzulegende User auch die passenden Berechtigungen erhalten. Hierzu startet man in der AWS Management Console den Dienst Identity & Asset Management (IAM).

Im Menü wählt man nun den Bereich “Users” und erzeugt mit “Create new User” einen neuen technischen Benutzer. Nach Eingabe des Benutzernamens (z.B. “wp_meinedomain”) werden die Zugangsdaten angezeigt in Form einer Access Key ID und einer Secret Access Key. Die beiden Werte werden später in der Konfiguration des WordPress Plugins benötigt.

In der Übersicht aller User, die nun erscheint, sollte der neue User ausgewählt und noch weiter bearbeitet werden, denn dieser User soll von seinen Rechten her beschränkt werden, so dass er nur die nötigsten Funktionen im AWS nutzen kann. Unter “Permissions” und “Managed Policies” erhält er über “Attach Policy” den Regelsatz “CloudFrontFullAccess”.

Ferner ist die folgende Inline Policy einzurichten, wenn der User auch auf ein S3 Bucket zugreifen können soll:

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:DeleteObject",
                "s3:Put*",
                "s3:Get*",
                "s3:Set*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKETNAME",
                "arn:aws:s3:::BUCKETNAME/*"
            ]
        },
        {
            "Action": "s3:List*",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

BUCKETNAME ist dabei durch den entsprechenden Bucket (z.B. der Domainname der Webseite) zu ersetzen.

CloudFront einrichten

Wählt man den Dienst CloudFront in der AWS Management Console aus, hat man nun die Möglichkeit eine neue CloudFront Distribution (Create Distribution) einzurichten. Es ist durchaus möglich mehrere Distributionen in einem Account zu verwalten. Für eine Webseite reicht jedoch eine Distribution aus, zumal unterschiedliche Distributionen kaum mit WordPress abgebildet werden können.

Im ersten Schritt ist die Verteilungsmethode für den bereitzustellenden Inhalt auszuwählen. Für klassische Webseiten wählt man hier den Button in der Kategorie Web. RTMP ist für Streaming Medien (Filme, etc.) vorgesehen.

Der zweite Schritt ist deutlich umfangreicher und komplexer, kann jedoch zu einem späteren Zeitpunkt jederzeit geändert werden.

Origin Settings – Die Datenquelle

Zunächst ist anzugeben, woher CloudFront die Inhalte beziehen soll. Origin Domain Name sollte damit die Domain der Webseite erhalten. Der Origin Path ist in dem Fall irrelevant und Origin ID ist eine frei wählbare Bezeichnung, die von dem Tool mit einem Vorschlagswert versehen wird.

Nach Eingabe der Domain werden weitere Felder eingeblendet: Verwendet man keine SSL Verschlüsselung, so können die Voreinstellungen hinsichtlich des Protokolls (HTTP only) beibehalten werden, andernfalls empfiehlt es sich “Match viewer” zu wählen. Die Einstellung legt fest, über welches Protokoll das CDN die Daten vom Webserver bezieht. Bei “Match viewer” werden die Daten auf die gleiche Weise angefordert, wie der Besucher der Seite das vorgibt.

Default Cache Behavior Settings – Standardverhalten des Caches

Im zweiten Abschnitt wird das Verhalten des Caches festgelegt, also über welches Protokoll sollen die Inhalte ausgeliefert werden und wie lange sollen die Inhalte im Cache verbleiben. Hier sollten zunächst keine Anpassungen erforderlich sein. Wer die Daten länger im Cache liegen lassen möchte, kann dies durch “Custom” und Angabe größerer Werte bei der TTL (time to live) erzwingen.

Wer sehr dynamische Inhalte präsentiert, die durch Nutzeranfragen generiert werden, sollte “Forward Query Strings” aktivieren, in den meisten Fällen ist dies allerdings nicht erforderlich und reduziert nur die Leistungsfähigkeit des CDN.

Wohl sinnvoll kann die Wahl der Datenkompression sein “Compress Objects Automatically”, da dies zu einem zusätzlichen Geschwindigkeitsschub führen kann, da eine geringere Menge an Daten über das Netz transferiert werden müssen. Mit der Kompression kommen alle gängigen Browser klar.

Distribution Settings – Einstellungen zur Verteilung

Der nächste Abschnitt ist relevant für die Kosten. Mit “Price Class” legt man fest, von wo aus überall verteilt werden soll. Amazon AWS rechnet für unterschiedliche Regionen auf der Welt auch unterschiedlich ab. Betreibt man eine vorwiegend deutsche Seite, ist eine Verteilung in Asien ggf. nicht erforderlich und man kann sich die Kosten sparen, indem man nur “Use Only US and Europe” auswählt.

Wer die Verwendung des CDNs ein wenig verschleiern möchte und Zugriff auf seine DNS Einträge hat, kann eine eigene Domain oder Subdomain für das CDN erstellen und im Feld “Alternate Domain Names” angeben. Wer mit SSL Verschlüsselung arbeitet muss dann auch sicherstellen, dass diese Domain auch ein passendes Zertifikat hat, ansonsten gibt es unschöne Fehlermeldungen oder Seiteneffekte. Der Einfachheit halber sollte man an dieser Stelle auf dieses Feature verzichten.

Die weiteren Einstellungen sollten für den Anfang nicht verändert werden.

Mit einem Klick auf “Create Distribution” ist dann auch schon alles getan.

In der CloudFront Distributions Übersicht sollte die Distribution nun angezeigt werden, unter anderem mit dem Domain Namen, der auf .cloudfront.net endet. Bis die Distribution nun nutzbar ist, vergehen noch ein paar Minuten. Sobald sie bereit ist, wird unter Status “Deployed” angezeigt. Bis dahin kann dann schon die Einrichtung in WordPress vorgenommen werden.

WordPress Plugin zur Nutzung von CDN

Das eingesetzte Content Management System muss die Webseiten nun verändert ausliefern. Alle Inhalte, die durch das CDN verteilt werden sollen, müssen in den HTML Dateien mit einer andere URL angegeben werden. Um dies nicht von Hand pflegen zu müssen und auch die Möglichkeit zu haben jederzeit das CDN wieder zu deaktivieren ohne aufwändig alle Seiten neu zu gestalten, sollte ein entsprechendes Plugin diese Arbeit übernehmen.

Gute Erfahrungen habe ich mit der kostenfreien Version des Plugins W3 Total Cache gemacht. Letztlich gibt es auch andere Plugins, die diese Aufgabe erfüllen können. In dem Fall müssen in den Einstellungen dann ähnliche Eintragungen vorgenommen werden.

Die Cache Plugins sollen für die Integration des CDN in sofern sorgen, dass sie Links auf Objekte (Bilder, Dateien, etc.) vor der Auslieferung an den User umschreiben auf die Domain des CDN. Zusätzlich kann man die Plugins natürlich auch noch dafür nutzen um weitere Optimierungen vorzunehmen und einen eigenen Cache auf dem Webserver aufzubauen und so die Seitenauslieferung bereits zu beschleunigen.

Für unsere Zwecke wird nach der Installation in den Einstellungen des Plugins unter “General Settings” im Bereich CDN das CDN aktiviert und als Typ “Amazon CloudFront” eingetragen.

Im nächsten Schritt sucht man den Reiter CDN in den Einstellungen auf.

Unter “General” kann festgelegt werden, welche Elemente über das CDN ausgeliefert werden sollen. Mit den Einstellungen entsprechend dem Screenshot habe ich gute Erfahrungen gemacht. Externe Medien, also Dateien, die NICHT auf dem eigenen Webserver liegen, lasse ich lieber unter der Kontrolle des eigentlichen Providers und eigne sie mir nicht unnötigerweise selber an.

Im Segment “Configuration” ist nun die Verbindung zum CDN herzustellen. Hierzu gibt man den unter AWS IAM erstellten Zugriffsschlüssel (Access Key) und das zugehörige Passwort (Secret Key) ein.

Wurden diese Daten korrekt eingegeben, kann man nun den in der CloudFront Distribution angegebenen Domainnamen im Bereich Origin wiederfinden. Bei “Replace site’s hostname with” sollte dann die kryptische Subdomain der CloudFront Distribution vermerkt werden. (Wenn man eine eigene Domain oder Subdomain für das CDN verwendet, dann kann diese ebenfalls hier eingetragen werden.)

Ein “Test CloudFront Distribution” ist nach diesen Einstellungen eine gute Entscheidung um festzustellen, ob alles auch so funktioniert, wie es soll.

Im Bereich “Advanced” sind dann noch weitere Einstellungsmöglichkeiten gegeben. Das CDN kann hier für SSL Verbindungen oder bestimmte Nutzergruppen ausgeschaltet werden. Ferner können bestimmte Dateien für der CDN Nutzung explizit ein- oder ausgeschlossen werden. Insgesamt sind hier keine Einstellungen abweichend vom Standard erforderlich. Lediglich die “Cookie Domain” sollte auf die eigene Domain festgelegt werden.

Nach dem Speichern der Konfiguration wird gegebenenfalls ein Löschen des Caches empfohlen. Sollte ein solcher Hinweis erscheinen, ist es durchaus sinnvoll dies durch einen Klick auf den entsprechenden Button auch durchzuführen. Andernfalls dauert es einige Zeit, bis die Seiten im Cache neu erstellt werden und die Anpassungen auch tatsächlich greifen.

Wenn alles funktioniert, wird die Webseite in gewohnter Weise angezeigt. Schaut man sich den Quelltext der Seite an, sollten dort zahlreiche Links mit Verweis auf die CDN Domain (…cloudfront.net) zu finden sein. Wer noch mehr wissen möchte, kann seine Seite auch durch Webpagetest.org analysieren lassen.

In Geduld üben

Mit der Nutzung eines Caches, CDN oder Proxies muss man sich ein wenig umgewöhnen, denn es kann durchaus der Fall sein, dass Änderungen nicht gleich sichtbar sind. Bisweilen lohnt es sich also auch einmal eine Stunde zu warten, bevor man in Foren nervös um Hilfe sucht. In jedem Fall allerdings sollten in WordPress nach Änderungen alle Caches geleert werden und im Browser die Seite durch ein Shift + Reload zwingend neu geladen werden. Nur in ganz extremen Fällen sollte ein “Purge CDN” vorgenommen werden, bei dem alle Daten auf dem CDN entfernt werden.

Nacharbeiten

Viele WordPress Themes bringen ihre eigenen Schriftarten mit. Gerade im Firefox Browser kann dies zu Fehlern führen, wenn die Schriftarten auch über das CDN ausgeliefert werden. Firefox prüft aus Sicherheitsgründen, ob die Schriftart auch tatsächlich vom eigentlichen Webserver kommt. Ein paar Zeilen sollten daher in die .htaccess Datei auf dem Webserver eingetragen werden:

<FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css)$">
 
     Header set Access-Control-Allow-Origin "*"

Mit diesen Eintragungen sollten die Schriften und zahlreiche Sonderzeichen und Symbole auf der Webseite wieder sauber dargestellt werden.