Immer mehr Unternehmen richten ihre Tech-Stacks cloud-native aus. Dabei zeichnet sich ein klarer Trend ab: Teilmigrationen oder Hybrid-Cloud-Setups als Zwischenschritt zur vollständigen Migration.
Cloud-Migration
Kürzlich hat ein E-Commerce-Unternehmen seine containerisierten Anwendungen von AWS zu GCP umgezogen, um Googles Managed-Kubernetes-Service GKE zu nutzen.
Produktkatalog-Dateien und Fotos lagen im Object-Storage-Service S3 von Amazon, das DNS lief über AWS Route 53, und als CDN war Cloudflare im Einsatz. Im ersten Schritt wurden die Datenbanken migriert und die Apps parallel in Kubernetes-Cluster ausgerollt.
Als Nächstes sollte das CDN von Cloudflare zu Google wechseln – die statischen Dateien sollten aber vorerst auf S3 verbleiben. Eine weitere Anforderung: Das bestehende, über AWS Route 53 verwaltete DNS sollte weiter genutzt werden.
Beispielhafte mehrstufige Cloud-Migration eines E-Commerce-Unternehmens
Dieser Artikel zeigt Schritt für Schritt, wie sich Inhalte aus einem AWS-S3-Bucket über GCP Cloud CDN mithilfe eines Load Balancers und einer Network Endpoint Group (NEG) cachen lassen. Der Einfachheit halber erstelle ich in diesem Beispiel kein SSL-Zertifikat und richte kein HTTP(S)-Frontend ein – in der Praxis wäre das ein üblicher zusätzlicher Schritt.
Aufbau des Demo-Setups
- Initialen S3-Bucket mit Testdateien anlegen
S3-Bucket erstellen (Bucket-Namen für die spätere Host-Konfiguration am Load Balancer notieren)
2. Testdateien hochladen und in den Metadaten den Cache-Control-Header setzen
Hochgeladene Beispieldateien
Cache-Control-Header hinzugefügt (für CDN erforderlich)
3. Prüfen, ob der Inhalt mit den korrekten Headern ausgeliefert wird
Load Balancer und NEG in GCP konfigurieren
- Backend-Typ "Internet network endpoint group" hinzufügen bzw. anpassen
2. Network Endpoint Group (NEG) auswählen oder "neu erstellen"
Hinweis: Unter Umständen müssen Sie die Network Endpoint Group (NEG) zuerst anlegen, damit sie im Dropdown der Backend-Konfiguration des Load Balancers erscheint. Wird sie nicht angezeigt, lässt sich über "Internet network endpoint group erstellen" eine neue anlegen – anschließend muss die Load-Balancer-Ansicht aktualisiert werden, damit die NEG sichtbar wird.
Wählen Sie "Fully qualified domain name" und tragen Sie den FQDN zum Speicherort Ihres S3-Buckets ein (alternativ funktioniert auch ein eigener DNS-Eintrag, der darauf verweist).
3. Cloud CDN aktivieren und Custom Header (passend zum S3-Bucket-Hostnamen) hinzufügen
Nachdem Sie den "Backend type" für die externe NEG ausgewählt haben, aktivieren Sie "Enable Cloud CDN" und klappen unten die Optionen auf, um einen Custom Header anzulegen.
Der entscheidende Kniff: einen Custom Host Header anlegen, der mit dem S3-Hostnamen übereinstimmt – wie unten dargestellt.
4. Frontend hinzufügen oder anpassen
5. Load Balancer speichern und prüfen, ob die NEG korrekt eingebunden ist
6. Prüfen, ob der Inhalt ausgeliefert wird und der Cache greift
Erreichbarkeit des Inhalts bestätigen (auch direkt im Browser möglich)
Rufen Sie die Inhalte mehrfach im Browser auf und werfen Sie anschließend einen Blick in die Logs (am schnellsten via Stackdriver). Klappen Sie einen Eintrag auf und prüfen Sie, ob die Auslieferung aus dem Cache erfolgt.
Caching für den Load-Balancer-Traffic bestätigt
DNS-Einträge anpassen und Traffic auf Cloud CDN umlenken
Sobald Sie sichergestellt haben, dass alles wie erwartet läuft und Inhalte aus dem Cache kommen, genügt zum Umschalten eine Anpassung der DNS-Einträge.
In diesem Fall lief das CDN über Cloudflare, und ein DNS-Eintrag cdn-environment-location.myco.com verwies auf den CNAME something.cloudflare.com. Legen Sie einfach einen neuen A-Record an, der auf die externe IP des Google Load Balancers zeigt (z. B. gcp-lb-development-cdn.myco.com), und biegen Sie anschließend den CNAME auf diesen neuen Eintrag um.
Zur Sicherheit empfehle ich, bereits am Vortag die TTL des aktiven CDN-Eintrags zu verkürzen, falls nötig. Sollte etwas schiefgehen, können Sie nach dem Anpassen des CNAME schneller zurückrollen, und das DNS-Caching der Clients greift nicht zu lange.
Die Schritte im Überblick:
- TTL der bestehenden CDN-Domain verkürzen
- A-Record anlegen, der auf die IP des GCP Load Balancers verweist
- CNAME-Record der bestehenden CDN-Domain anpassen (Cloudflare-FQDN ersetzen)
- Prüfen, ob der Traffic über Cloud CDN läuft
Glückwunsch, es hat funktioniert! Jetzt noch mit einem HTTP(S)-Frontend absichern ;-)
Kostenbewusstsein bei Cloud-Lösungen
Anfragen von Cloud CDN an S3-Buckets zu proxen ist zwar möglich, setzt aber Custom Header voraus – und dafür fallen Kosten an. Aktuell sind das rund 0,75 USD pro 1 Million Anfragen, gedeckelt bei 500 USD pro Monat. Bei einer großen Website mit viel Traffic kommt da einiges zusammen.
Im Vergleich zu den Cloudflare-Gebühren (Preise nicht bekannt) mag das wenig erscheinen, sollte aber dennoch eingeplant werden. Langfristig sollen die statischen Dateien in Google-Cloud-Storage-Buckets umziehen – und da diese dieselbe S3-API unterstützen, sind kaum bis keine Code-Anpassungen nötig.
Fazit
Wie Sie sehen, ist eine Migration zwischen Technologieanbietern weniger abschreckend, als oft angenommen. Der sicherere Weg ist allerdings, die Arbeit in kleinere Phasen zu zerlegen – so können Sie bei Problemen unkompliziert zurückrollen und den Geschäftsbetrieb möglichst wenig beeinträchtigen.