Im März 2019 fiel der Startschuss für ein neues, spannendes Projekt für drei Mitglieder des Valiton Tech Teams in München. Der Kunde: BurdaForward, das Projekt: Konzeption und Implementierung einer neuen Affiliate-Marketing Plattform, die alle Publisher von BurdaForward nutzen sollen.

BurdaForward erreicht monatlich mehr als 44 Millionen Internetnutzer mit kostenlosen, werbefinanzierten Inhalten auf Portalen wie chip.de und focus.de. Um Traffic und Erlöse miteinander verknüpfen zu können, bedarf es einer Infrastruktur und Applikationen mit hoher Skalierbarkeit, Robustheit und Zuverlässigkeit. Als erfahrener und zertifizierter Dienstleister kennt Valiton die Stärken der Cloud und unterstützt und berät BurdaForward beim Aufbau der neuen Infrastruktur in der AWS Cloud, sowie bei der Migration von bestehenden Systemen. 

Business- und technische Anforderungen 

Die bisherige Tracking Plattform lief nicht in der Cloud, sondern auf gemanagten virtuellen Maschinen, und wurde dort vom hauseigenen Operations-Team betrieben. Viele Kernprozesse, die Infrastruktur und Applikationsdeployment betreffen, lagen z.B. nicht in der Hand des Entwicklerteams. Diese organisatorische Verteilung führte zu erhöhtem Abstimmungsaufwand und Abhängigkeiten, die den gesamten Entwicklungsprozess verlangsamten. 

Die Infrastruktur selbst musste fest für einen bestimmten Zeitraum abgenommen werden, unabhängig von der tatsächlichen Nutzung.  

Eine weitere Herausforderung war es, Konfigurationsänderungen am Setup von einer Umgebung auf eine andere – beispielsweise vom Staging System auf das Produktivsystem – zu übertragen und die Gefahr eines sogenannten Configuration drift zu vermeiden. 

Einige Key Features der Plattform wurden bisher nur bei bestimmten Mandanten unterstützt. So war zum Beispiel die Möglichkeit der Zuordnung von Umsatz zu einer User Session auf den Portalen bisher auf einen einzigen Publisher beschränkt – ohne Möglichkeit dieses Feature auch bei anderen BurdaForward Portalen zu nutzen. 

Product Manager Sebastian Bonholt äußerte sich folgendermaßen zu den Projektanforderungen: „Wir wollten unser Legacy System durch ein Cloud-Native System ersetzen. Dabei spielten vor allem Aspekte wie: Time-To-Market, Wartbarkeit und Zukunftssicherheit eine große Rolle. Wir hatten durch unser Altsystem bereits viele Anforderungen und Erfahrungen gesammelt und kannten unseren Business Case. Wir hatten allerdings keine ausreichende Erfahrung mit AWS. Da ich die Kollegen der Valiton bereits aus anderen Projekten kannte und schätze, haben wir sie zur Projektausschreibung eingeladen. Wir hatten als explizites Projektziel das Thema Knowledge Transfer definiert, um auch intern unser Wissen aufzubauen. So konnten wir gemeinsam schnell in die Umsetzung starten.“.   

Auf Basis dieser Anforderungen wurde entschieden den Schritt in die AWS Cloud zu gehen. 

Projekt und Architektur 

Im Herzen der neuen Plattform stehen zwei Services: 

1. Ein Link Shortener Service 
2. Ein Link Redirector Service 

Der Link Shortener soll zunächst von Publishern von BurdaForward genutzt werden, um Verlinkungen zu Affiliatepartnern im Content des Portals zu platzieren. Klickt ein User beim Lesen eines Artikels auf ein für ihn interessantes Angebot, wird der Short-Link vom Redirector Service aufgelöst. Der User wird auf die Seite des Werbetreibenden (z.B. amazon.com oder saturn.de) weitergeleitet, während anonymisierte Daten des Click-outs weiterverarbeitet werden. Tätigt der User dann tatsächlich einen Kauf, werden die Daten über den finalen Umsatz wieder vom Partner entsprechend abgerufen. 

Um den Anforderungen gerecht zu werden, wurde eine Microservice-Architektur entworfen, die die Anforderung passend abbildet. Sie bietet hohe Entkopplung der Services, so dass diese unabhängig voneinander entwickelt und deployed werden können. Ergänzt wird die Architektur durch Event-getriebene Kommunikation. Cloudservices wie CloudWatch Events/Eventbridge steuern die Kommunikation zwischen den einzelnen Services und verringern damit den Koordinationsaufwand zwischen den Services. 

Hoher Produktfokus 

Das Projekt benutzt 5 AWS Accounts (Development, Staging, Production, Tools, Sandbox) und setzt so auf die „Limited blast radius“-Praxis. Durch die strenge Abgrenzung der einzelnen Umgebungen werden so auch mögliche Auswirkungen technischer oder sicherheitsrelevanter Vorfälle lokal beschränkt. So kann beispielsweise ein Ausfall in der Staging-Umgebung keine Auswirkungen auf die Production-Umgebung haben. 

In dem Projekt verfolgen wir einen konsequenten Infrastructure as Code (IaC) Ansatz mit Terraform und AWS CloudFormation. Sämtliche Infrastruktur–Konfigurationen sind in unserer Code Versionskontrolle verwaltet. Somit ist es leicht, die gleiche Infrastruktur von der Development-Umgebung in die Staging– und Production-Umgebung zu replizieren und „configuration drift“ zu vermeiden. 

Services wie AWS Lambda und AWS API Gateway ermöglichen eine schnelle Erstellung von Serverless HTTP APIs. Für die Datenhaltung wird auf Services wie AWS S3 und AWS RDS zurückgegriffen. Die Strategie geht auf. Innerhalb von wenigen Monaten sind die Grundkomponenten der Plattform funktionsfähig. 

Performance und Skalierbarkeit 

Die Portale von BurdaForward gehören zu den traffic–stärksten Webseiten in Deutschland.  

Besonders wichtig ist eine kurze Latenz des Redirector Services beim Weiterleiten. Um die Kaufwahrscheinlichkeit beim Click-Out nicht zu beeinflussen streben wir an, möglichst alle der Redirects im niedrigen zweistelligen Millisekundenbereich durchzuführen. Weitere Datenverarbeitung kann nach dem Redirect asynchron über die AWS Cloudwatch EventBridge erfolgen.

Wegen der einfachen Erstellung der Services und der Fokussierung auf die Funktion, wurde AWS Lambda für viele Services als ideale Wahl identifiziert. In manchen Fällen gibt es bei Serverless Anwendungen wie AWS Lambda einen sogenannten „Cold start“ der für eine Verzögerung von bis zu mehreren 100ms führen kann. Aus diesem Grund haben wir uns beim Redirector Service für ein klassisches Docker-Setup entschieden. Wir nutzen hier mit AWS ECS den hauseigenen AWS Orchestration-Service und erreichen nun eine durchschnittliche Responsezeit von unter 30ms. Hierfür nehmen wir auch einen etwas höheren Wartungsaufwand in Kauf. 

Bei jeder Weiterleitung werden Prozesse zur weiteren Datenverarbeitung angestoßen. Hierfür schickt der Redirector Service lediglich ein Event an AWS EventBridge und diese steuert sämtliche nachgelagerte Datenverarbeitung. Die Weiterleitung im Redirector Service findet synchron statt, die Datenaufbereitungspipeline verarbeitet die Daten asynchron. Selbst wenn nachgelagerte Services nicht verfügbar sein sollten oder unter starker Last leiden kann der Redirector Service seine Ressourcen voll auf das Weiterleiten von Click-Outs verwenden. 

Für die Datenaufbereitung müssen Clickout-Daten umformatiert werden und in eine Managed Database von AWS RDS importiert werden. Je nach Traffic könnte die Datenbank dort zum Flaschenhals werden. Auch hier haben wir das Sammeln der einzelnen Datensätze vom Laden in die Datenbank entkoppelt. AWS bietet mit seinem Service Kinesis Firehose einen selbst-skalierenden Daten-Streaming Service an, mit dem wir alle Daten zunächst im Rohformat in S3 Bucket sammeln. Im Anschluss werden durch S3 Bucket Events AWS Lambda Funktionen getriggert, die diese Daten dann per S3-Copy in die Datenbank laden. Somit fokussiert sich jeder Service auf seine Hauptaufgabe. Der Redirector Service führt zeitkritische Redirects aus, während andere Services weniger zeitkritische, aber gründliche, Datenverarbeitung betreiben. 

Bei den Portalen von BurdaForward muss für spontane Trafficspitzen an umsatzstarken Tagen, wie zum Beispiel Black-Friday, vorgesorgt sein. Lasttests haben ergeben, dass die aktuelle Redundanz für mittlere Schwankungen ausreichend ist. Für große Lastspitzen benutzen wir AWS Autoscaling Groups, um automatisiert in die Breite zu skalieren sobald bestimmte CPU und Memory Schwellwerte überschritten sind. 

Kostentransparenz 

Ein weiterer Vorteil der AWS Cloud gegenüber traditioneller Infrastruktur sind Kostentransparenz und -flexibilität. Im Legacy–Setup musste im Voraus für die bestellten VMs bezahlt werden. Im neuen AWS Setup gibt es die Möglichkeit der nutzungsgerechten Abrechnung, sodass nur für tatsächlich genutzte Ressourcen bezahlt wird. Sämtliche Kosten aller Accounts werden in einem Grafana Dashboard im Tools Account erfasst. Damit bietet dieses Dashboard eine tagesaktuelle Sicht auf alle entstandenen Kosten. 

Um Kosten zu sparen, nutzen wir die Möglichkeit ungenutzte Ressourcen zu stoppen. AWS Autoscaling Groups ermöglicht uns automatisierte Skalierungen durchzuführen. Auf diese Weise stoppen und starten wir zeitgesteuert EC2 Instanzen, sodass diese nur zu Arbeitszeiten laufen. Einen ähnlichen Mechanismus gibt es für RDS Instanzen aktuell noch nicht, allerdings können RDS Instanzen per API gestoppt und gestartet werden. Mit einem Cron Event stoppen wir die RDS Instanzen nun auch über Nacht. Diese Maßnahmen sorgen dafür, dass die betroffene Infrastruktur wöchentlich nur 60 anstatt 168 Stunden läuft, eine Ersparnis von fast 65% gegenüber einem 24/7 Betrieb der Ressourcen. 

Viele der Services im Projekt laufen auf dem nutzungsbasierten Standard-Abrechnungsmodell von AWS. EC2 bietet darüber hinaus die Möglichkeit für weitere Einsparungen. Ungenutzte Restkapazitäten werden von AWS als sogenannte Spot-Instanzen günstig angeboten. Der Preis wird durch Angebot und Nachfrage bestimmt und meistens liegt der Spot-Preis weit unter dem On-Demand Preis. AWS Autoscaling Groups bietet einem auf sehr einfachem Weg die Möglichkeit von diesem Angebot Gebrauch zu machen. Dort lässt sich der Wechsel von Spot auf On-Demand Instanzen sehr leicht konfigurieren, wenn der Spot-Preis zu hoch oder die Kapazitäten zu niedrig sind. Für alle Services, die eine kurze Downtime tolerieren, nutzen wir diese Option.   

Wiederverwendbarkeit von Identitäten durch AWS SSO (Cognito) 

Im Projekt nutzen Publisher ein Webfrontend, um die Short-Links, die in den Artikeln platziert werden, für Affiliates zu erstellen. 

Nur berechtige Personen sollen auf dieses Webfrontend zugreifen können. Um das Thema Passwort- und Zugriffsmanagment nicht selbst betreiben zu müssen, setzen wir ebenfalls auf eine Standardlösung von AWS. 

Mit AWS Cognito User setzen wir die ideale Plug-and-Play Lösung für diesen Anwendungsfall ein. Hierzu haben wir im Webfrontend den Client-seitigen JavaScript SDK von AWS eingebunden was den Authentifizierungs-Workflow komplett übernimmt. Nach erfolgreicher Authentifizierung wird der User wieder mit einem Session Token auf unser Webfrontend weitergeleitet. Die User im Userpool lassen sich per SAML auch von einem externen Identity-Provider speisen. In diesem Fall war es naheliegend das vorhanden Active Directory von BurdaForward zu nutzen. So bleibt die Userverwaltung zentral in einer Hand und User können sicher per Single Sign-On auf eine neue Applikation im Projekt Zugriff erhalten – ganz ohne die Notwendigkeit neuer Passwörter und Zugänge. 

Fazit 

Heute, ca. 18 Monaten nach Projektstart, fällt die Bilanz positiv aus. Produkt Manager Sebastian Bonholt kommentiert:  

„Das Projekt verlief bisher sehr erfolgreich. Wir konnten sehr schnell erste, produktive Komponenten launchen. Dies liegt unter anderem daran, dass wir auf managed Services setzen. Unsere iterative Vorgehensweise hat sich dabei sehr bewährt. Dadurch, dass die Kollegen der Valiton Teil unseres Teams und unserer Arbeitsweise wurden, konnten wir im Alltag schnell und unkompliziert auf Herausforderungen reagieren. Statt eines fixen Werkvertrages hat sich das Konzept Time-and-Materials bewährt. Wir haben auf wiederverwertbare Komponenten und Infrastructure-as-Code gesetzt. Beides hat sich im Projektverlauf als sehr hilfreich erwiesen. Die AWS Cloud Komponenten laufen stabil und wir konnten intern schnell Anpassungen an der Produktiv-Umgebung vornehmen und auch für andere Projekte Learnings adaptieren.”

 

 

 

 

Der Vertrag wurde in den letzten Tagen wieder verlängert und das Team freut sich in den nächsten Monaten darauf die Plattform mit mehr Publishern zu erweitern und neue Affiliate-Netzwerke anzubinden. 

Links 

Event-driven Architecture: https://aws.amazon.com/de/event-driven-architecture/ 

Terraform: https://www.terraform.io/ 

Cloudformation: https://aws.amazon.com/de/cloudformation/ 

Serverless: https://www.serverless.com/ 

Spot-Instanzen: https://aws.amazon.com/de/ec2/spot/ 

Cognito: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp.html