Three ways to deploy Airflow on AWS

Airflow on AWS

3 Ways to deploy Airflow on AWS


There are various deployment approaches available for Airflow. It includes deployment of all components on a single VM or deployment of different components on separate single or load-balanced VMs. Some of the components of the Airflow, such as the Task creation and monitoring UI, need a webserver and other components, such as the scheduler and executor, need a
native runtime of Python. The choice of deployment model is driven by the concerns such as performance, availability, and scalability. The focus is always on the scheduler and executor components because they carry out the main workload of
Apache Airflow and need clustering and autoscaling.


What options are available to deploy Airflow on AWS? 

AWS provides a variety of options for deploying Airflow that can be categorized under IaaS, PaaS, as well as SaaS.


Deploy Airflow on AWS EKS

Kubernetes is the proven solution for auto-scaling, elasticity, and automatic resource management. There is a huge community supporting Kubernetes initiatives and hence several ready-to-use configuration files are available for deploying Airflow using EKS. EKS keeps spawning new nodes with the Airflow executor or scheduler for handling new and heavy workloads.

 The biggest drawback in the setup is that the cost for the smaller workloads may turn out to be higher. Depending on the variety of tasks and their resource requirements, EKS may need to launch a greater number of instances without maximum utilization of each node, leading to increased costs.


Deploy Airflow on AWS EC2

Deployment of Airflow on EC2 is almost the same as you would deploy on an on-premises VM: sweet and simple, old-style deployment, pre-configured capacity, fixed nodes in the cluster, and pre-determined load balancing. A set of dedicated EC2 instances takes care of the webserver components and another set of EC2 instances host the scheduler and executors.

 This deployment model offers little dynamism in terms of scale-up or scale-down and the availability of the solution depends on the number of upfront provisioned instances. It works well in a scenario where workloads are fairly fixed and growth is minimal or constant. It cannot handle load spikes at all.

 

Use the Managed Airflow service on AWS

Amazon Managed Workflows for Apache Airflow (MWAA) is a managed orchestration service in its nascent state as of now in 2021. It is a SaaS offering that promises to address the most common concerns around scalability, availability, and security. Like any other service, it is easy to start, however, it is not industry-proven yet.

It has the power to become one of the most sought-after deployment models of Airflow because it is pre-integrated with other proven services of AWS, such as Amazon S3, CloudWatch, IAM, and others.


Our recommendation

When you are moving your Airflow solution on the AWS cloud, we recommend evaluating the option to use EKS orchestration. It would require you to analyze and determine the sizes and frequency of workloads. Careful planning of instance sizes can help you optimize your costs and utilize the instances to their maximum capacity.

Thinkport is a dynamic and constantly growing cloud consulting company, with the goal of developing innovative technologies and solutions in the field of cloud computing. As a certified Microsoft Silver Platform Partner, we work closely with Microsoft, in the Azure cloud environment, and also have certified expertise with Amazon Web Services and the Google Cloud Platform.

Our strengths and expertise lie in the areas of Multi-Cloud, Data Lakes, Big Data, AI and Event-Driven Architectures (Hadoop, Kafka, Solace) and Terraform. To get further insight about our services, feel free to visit our website and newly updated workshop page.

Blog Kurator

Bledion Vladi

Business Development

Email:

bvladi@thinkport.digital

Was ihr über Kafka 2.7 wissen solltet

Apache Kafka 2.7

Die wichtigsten Neuerungen in Kafka 2.7

Contributor: Wladislaw Ponomarenko

In diesem Blogbeitrag werden wir auf die, unserer Meinung nach, wichtigsten Neuerungen in Kafka 2.7 eingehen. Doch zuerst einmal was ist Apache Kafka? Bei Kafka handelt es sich um eine Open Source Event Streaming Plattform. Die hohe Verbreitung von Kafka lässt sich darauf zurückführen, dass die Anzahl der möglichen Nachrichten Zustellungen theoretisch nur durch das Netzwerk limitiert sind. Zudem wird eine hohe Skalierbarkeit geboten und die Möglichkeit Daten dezentral zu speichern. 
Die Neuerungen werden von der Open Source Gemeinschaft organisiert und verwaltet. Hierfür wird der Begriff “Kafka Improvement Proposal”, kurz „KIP“ genutzt (dt. Vorschlag zu Verbesserung von Kafka). In der Version 2.7 gab es zahlreich Neuerungen, die wir im Folgenden in drei Kategorien unterteilt haben.

Broker, Producer und Consumer 

KIP-654: Nicht fatale Fehlermeldung für abgebrochene Transaktionen mit ausstehenden Daten. 

Wenn vor dem Update im Java-Client-Producer versucht wurde, eine Transaktion mit ausstehenden Daten abzubrechen, wurde die fatale Fehlermeldung KafkaException(“Failing batch since transaction was aborted”) ausgegeben. Dieser Zustand ist jedoch zulässig. Mit der Fehlermeldung soll darauf aufmerksam gemacht werden, dass die Datensätze nicht mehr gesendet werden. Die Lösung, die für dieses Problem gewählt wurde, ist das Werfen einer anderen Fehlermeldung. Diese macht den Benutzer darauf aufmerksam, dass die Transaktion abgebrochen wurde. Die Fehlermeldung, die geworfen werden soll, ist die TransactionAbortedException.

Welche Auswirkung haben diese Änderungen?

Falls alles schon implementiert ist, wird der Benutzer eine neue Fehlermeldung sehen, die weiter hin abgefangen wird, da es sich um eine Erweiterung der „KafkaException“ handelt. Hier kann dann der Benutzer entscheiden, wie mit dem Fehler umzugehen ist und gegebenenfalls die Daten erneut senden. 

KIP-651: Unterstützung des PEM-Formates für SSL-Zertifikate und private Schlüssel. 

Vor dem Update hat Kafka nur Filebasierte Schlüssel und trust stores unterstützt. Nach dem Update ist es möglich PEM Dateien als Wert für einen Schlüssel zu übergeben. PEM steht für Privacy-Enhanced Mail und war ehemals als E-Mail Standard gedacht. Heute ist es ein Standardformat für die Speicherung und Verteilung von kryptografischen Schlüsseln und Zertifikaten. 

Welche Auswirkung haben diese Änderungen?

Es werden weiterhin dateibasierte Verschlüsselungen und trust stores unterstützt. Die neuen Änderungen werden erst gültig, wenn diese explizit konfiguriert werden. Zu beachten ist, dass eine Fehlermeldung geworfen wird, sobald Daten und PEM-Werte gleichzeitig konfiguriert werden. 

KIP-612: Begrenzung der Verbindungsherstellungsrate bei Brokern.

Das Erstellen einer neuen Verbindung bringt Verwaltungsdaten mit sich. Das Problem hierbei ist, dass selbst bei gut funktionierenden Clients vermehrt neue Verbindungen auftreten können. Ein Beispiel hierfür wäre das Einsetzen einer neuen Anwendung, in der sich eine große Anzahl an Clients gleichzeitig hochfährt und eine Verbindung erstellt. Alternativ Clients, die für jede ausgeführte Operation eine neue Verbindung aufbauen Dadurch, dass der Broker dann diese Verwaltungsdaten handhabt, wird die Leistung blockiert, was wiederum zu einer höheren Latenz führen kann. Um dieses Problem zu lösen, wird die Möglichkeit implementiert, ein Limit für mögliche neu Verbindungen pro IP-Adresse zu setzen und ein Limit wie viele neu Verbindungen der Broker zulässt.

Welche Auswirkung haben diese Änderungen?

Diese Änderung hat keine Auswirkung auf bereits konfigurierte Systeme, denn um in Funktion zu treten, müssen die Limitierungen konfiguriert werden. Um die Rate zu limitieren, muss einfach der folgende Befehl in die Einstellungen hinzugefügt werden:
max.connection.creation.rate [0,…]. Der Standard Wert beträgt 2147483647. 

KIP-431: AUSGABEERWEITERUNG BEI DEM CONSOLECONSUMER. 

Der Kafka ConsoleConsumer ist ein sehr wichtiges Debugging-Tool in Kafka. Allerdings konnte es vor dem Update keinen Offset, Partition und Header eines Kafka-Datensatzes ausgeben. Hierfür musste man sich mit dem Broker Host direkt verbinden oder eine andere Anwendung dafür verwenden. Dieses Problem wurde gelöst, in dem der ConsoleConsumer um die folgenden Eigenschaften erweitert wurde:
print.offset
print.headers
header.separator
headers.deserializer
null.literal 

WELCHE AUSWIRKUNG HABEN DIESE ÄNDERUNGEN? 

Vor dem Update gab es die Eigenschaft „print.partition=true“ diese war aber nicht dokumentiert und die Ausgabe war „schlüssel|wert|0“, nach dem Update kommt noch der Präfix „Partition“ hinzu. Die Ausgabe sieht danach wie folgt aus: „Partition:0|schlüssel|wert“. Wenn „print.partion“ vohrer nicht benutzt wurde, muss beim Updaten nichts beachtet werden, da lediglich neue Einstellungsmöglichkeiten dazu gekommen sind. 

Connect

KIP-632 Hinzufügen von dem “DirectoryConfigProvider”
Hier wird die Kafka ConfigProvicer Schnittstelle erweitert und bietet nun die Möglichkeit Schlüssel in Dateisystemen zu hinterlegen.
Vorher gab es einen FileConfigProvier, der Schlüssel in einer Properties Datei verwaltet hat. Dies kann jedoch zu Problemen mit zum Beispiel Kubernetes führen, da hier jedes Secret-Objekt mehrere Schlüssel beinhalten kann. Jedoch ist es möglich, sich diese einzeln in einem Verzeichnis auflisten zu lassen.

Welche Auswirkung haben diese Änderungen?

Diese Änderung ist rückwärts kompatibel und kann wie folgt konfiguriert werden ssl.keystore.password=${directory:/Pfad-zum-Schlüssel:schlüssel1}

Kafka Streams

KIP-617: Rückwärts Iteration durch Zustandsspeicher.
Das Abrufen eines Bereichs von Datensätzen aus Kafka Streams State Stores erfolgt durch einen iterator: fetch(K Schlüssel, long von, long bis). Hier wird die Reihenfolge vom frühsten Eintrag bis zum letzten garantiert. Dies kann aber ineffizient sein, wenn man zum Beispiel nur die Letzten x Einträge benötigt. Es wird die Option eingefügt, Datensätze in umgekehrter Reihenfolge, von dem aktuellen Eintrag bis hin zum ältesten, zu iterieren. Dies wird erreicht, indem man den Zustand speichert. Dadurch kann man deutlich effizienter nach letzten Einträgen suchen.

Welche Auswirkung haben diese Änderungen?

Es gibt Standardimplementierungen wodurch bereits laufende Systeme nicht betroffen sind. Benutzt werden kann es durch eine Implementierung der reverseRange Funktion im ReadOnlyKeyValueStore Interface.

KIP-613: Hinzufügen von End-to-End-Latenz Metriken zu Kafka-Streams.

Vor dem Update war es nur schwer möglich, die tatsächliche End-zu-End-Latenz eines Datensatzes, der durch einen Stream fließt, zu messen. Dies erschwerte das Entwickeln von Echtzeitanwendungen, da man nicht genau sagen konnte, wie lange ein Event verarbeitet wird. Diese Neuerung macht es möglich, die Latenz in Form von Metriken offen zu legen und darauf basierend mit der richtige Design Entscheidung die Latenz zu begrenzen. Hierfür sollen folgende Metriken hinzugefügt und auf Task Niveau bereitgestellt werden:
record-e2e-latency-min [ms]
record-e2e-latency-max [ms]
record-e2e-latency-avg [ms]

Welche Auswirkung haben diese Änderungen?

Da es sich um die Implementierung einer Erweiterung handelt, sollte diese vollständig kompatibel sein.

KIP-450 Sliding Window Aggregation in DSL (Domain Specific Language).

Dieses KIP beschäftigt sich mit der Erweiterung des Sliding-Windows durch Aggregation. Zuvor gab es diese Möglichkeiten nur für den Tumbling- und Hopping-Window. Windowing ist eine Zeit basierte Form für das Gruppieren von Einträgen. Hopping-Window mit kleiner Vorlaufzeit ähnelt einem Sliding-Window. Jedoch enthält dieser redundante Daten, da die Fenster sich an vielen Stellen überschneiden. Beim Sliding-Window wird nur das Fenster berechnet und somit kommt es zu keinen Überschneidungen, weswegen dieses Verfahren deutlich effizienter ist.

Welche Auswirkung haben diese Änderungen?

Da es sich um die Implementierung einer Erweiterung handelt, sollte diese vollständig kompatibel sein. Eine mögliche Implementierung könnte wie folgt aussehen: 
stream
.groupByKey()
.windowedBy(SlidingWindows.withTimeDifferenceAndGrace(ofSeconds(x), ofSeconds(x))
.toStream()


 Thinkport ist ein dynamisches und stetig wachsendes Cloud-Beratungsunternehmen, mit dem Ziel innovative Technologien und Lösungen im Bereich Cloud Computing zu entwickeln. Als zertifizierter Microsoft Silver Platform Partner arbeiten wir eng mit Microsoft, im Azure-Cloud-Umfeld, zusammen und verfügen auch über zertifizierte Expertise mit Amazon Web Services und der Google Cloud Plattform.

Unsere Stärken und unser Know-how liegen in den Bereichen Multi-Cloud, Data Lakes, Big Data, AI und Event-Driven Architectures (Hadoop, Kafka, Solace) sowie Terraform. Um einen weiteren Einblick über unsere Dienstleistungen zu bekommen, besuchen Sie gerne unsere Website und die neu aktualisierte Workshop Seite

Blog Kurator

Bledion Vladi

Business Development

Email:

bvladi@thinkport.digital

Thinkports Projekt gewinnt den Digital Leader Award 2021

SIMPL gewinnt den Digital Leader Award 2021

NEWS

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on email

„Health for all, hunger for none“

Das von Thinkport mitentwickelte Bayer Projekt, SIMPL (Small Molecules Imaging Platform) wurde von der Jury aus Digitalisierungsexperten aus Wirtschaft, Wissenschaft und Medien mit dem Digital Leader Award 2021 ausgezeichnet. 

Das Projekt unterstützt Bayers bei der Forschung neuer Handlungsfelder für einen zukunftsfähigen Pflanzenschutz, um umweltfreundlichere und effektivere Pflanzenschutzmittel zu entwickeln. 

Die entwickelte SIMPL-Plattform nutzt maschinelle Lernmodelle, Bilder und verschiedene Lichtspektren, um die Wirkung und Entwicklung von Pflanzen zu analysieren. So werden bisherige manuell gesteuerte und zeitaufwändige Prozesse durch eine cloudbasierte Lösung wie die SIMPL-Plattform ersetzt, die täglich tausende von Bildern verschiedener Pflanzen analysiert, um Wirkmechanismen zu identifizieren. 

So werden mehr Wirkstoffe getestet, zeitaufwendige Suchen durch das robuste Tool automatisiert und Entscheidungen effizienter getroffen.

News Writer

Bledion Vladi

Business Development

Email:

bvladi@thinkport.digital

Testdaten generieren mithilfe von Openmaps

Testdaten generieren mithilfe von Openmaps

Mit OpenMap einfach Daten generieren

Contributor: Nicolas Voigt

Für eine Streaming-Anwendung mit Apache Kafka werden geografische Testdaten benötigt. Vorliegendes Schaubild bildet ein Tech Stack Overview ab. Hierbei wird der Ablauf samt beteiligter Software veranschaulicht. 

Abb.1 - Tech Stack Overview

Für die Erzeugung eines simplen Datasets,
beispielsweise in Form von GPS-Koordinaten von Autos, wird ein Fleet von Pods
unter Betrachtung von Kubernetes benutzt. 
Ein einzelner Pod wird hierbei ein einzelnes Dataset von Koordinaten bzw. ein
Auto generieren (s.h. Abbildung 1).

Wichtige Voraussetzungen und involvierte Module/Software

1.      Spring Boot ist ideal für die Entwicklung und Bereitstellung individueller Microservices, unabhängig von der gewählten Programmierungssprache. Es wird eine hoch skalierbare und robuste Kommunikation zwischen den Services ermöglicht.

 

2.      Osmapi wird von StreetComplete benutzt und bildet einen Client der OSM API 0.6. Es ist ein offizielles Modul von Openstreetmap und als Testprojekt im Vergleich zu Google Maps relativ kostengünstig. Vorteilig ist zudem, dass Openstreetmap, einige kostenlose Varianten anbietet und leicht anbindbar ist. Die OSM-API ist hierbei lediglich für die Bearbeitung der Karte verantwortlich und nicht für das Abrufen größerer Datenmengen geeignet. Die Aufarbeitung größeren Datenbeständen erfolgt wiederum von Overpass-API.

3.      Spring für Apache Kafka wendet zentrale Spring-Konzepte auf Basis von Kafka-basierten Messaging-Lösungen an. Vorteilig hierbei ist, dass es mit Azure Eventhub angebunden ist, jedoch auch nur in Verbindung mit diesem zu nutzen ist. Als High-Level-Abstraktion bietet spring-kafka eine Vorlage für die Sendung von Nachrichten an. Zudem unterstützt es bei Message-driven POJOs mit KafkaListener-Annotationen.

 

4.      Innerhalb der Streaming Anwendung werden folgende drei Azure Services verwendet:

Zum einen AKS Azure Kubernetes, welche eine Open-Source-API bereitstellt und Container bzw. gruppierte Pods (s.h. Abbildung 1) genauer steuert. Ein weiterer Streaming Service ist Azure Application Gateway, welche hilfreich ist, um URL-basiertes Routing durchzuführen. Für den Schutz der einzelnen Pods sollte eine direkte Verbindung mit dem Internet vermieden werden. Azure Gateway ist zudem wichtig,
um eine Abtrennung zwischen Pods und Internet zu schaffen und den Einlass von fehlerhaften Inhalten gegebenenfalls zu verhindern und zu monitoren. Die dritte Serviceanwendung Interconnect VPN stellt die Funktionalität, Sicherheit und Verwaltungsrichtlinien eines privaten Netzwerks sicher. Grund für die Nutzung von VPN Interconnect ist zusätzlich der Fakt, dass Eventhub im eigenen privaten Subnet läuft.

Abb.2 - Vorgang Datengeneration mit Openstreetmap

Wie das Ganze deployed wird 

Die Bereitstellung der Daten erfolgt mit der Open-Source-Infrastruktur as code (IaC) Plattform Terraform, welche von HashiCorp entwickelt wurde. Die Infrastruktur wird in diesem Zusammenhang als YAML Dateien beschrieben. Vorteil dieser Software-Anwendung ist zudem, dass
diese äußerst git friendly ist, sprich eine parallele Entwicklung der Infrastruktur ermöglicht und eine einfache Historie samt Änderungen aufzeigt. Zusätzlich ist es rollback friendly und im Falle eines Bugs kann die vorherige fehlerfreie Infrastruktur schnell und leicht wieder eingesetzt werden. Letztlich wird eine einfache Einstellung bezüglich der Skalierung und Parallelisierung gegeben.

Abb.3 - Source Snippets Auszug

Conclusion:

Zusammenfassend bilden Gateway und VPN Interconnect eine Verbindungsstelle, damit die Pods die generierten GPS-Koordinaten
verifizieren können. Insgesamt ist die Infrastruktur korrekt einzuordnen, abänderbar und leicht verständlich.

 

Thinkport ist ein dynamisches und stetig wachsendes Cloud-Beratungsunternehmen, mit dem Ziel innovative Technologien und Lösungen im Bereich Cloud Computing zu entwickeln. Als zertifizierter Microsoft Silver Platform Partner arbeiten wir eng mit Microsoft, im Azure-Cloud-Umfeld, zusammen und verfügen auch über zertifizierte Expertise mit Amazon Web Services und der Google Cloud Plattform.
Unsere Stärken und unser Know-how liegen in den Bereichen Multi-Cloud, Data Lakes, Big Data, AI und Event-Driven Architectures (Hadoop, Kafka, Solace) sowie Terraform. Um einen weiteren Einblick über unsere Dienstleistungen zu bekommen, besuchen Sie gerne unsere Website und die neu aktualisierte Workshop Seite

Referenzen: 
1. https://github.com/westnordost/osmapi
2. https://docs.microsoft.com/de-de/azure/developer/java/spring-framework/configure-spring-cloud-stream-binder-java-app-kafka-azure-event-hub
3. https://spring.io/projects/spring-kafka
4. https://www.confluent.io/resources/event-driven-microservices-with-spring-boot-and-confluent-cloud/?utm_medium=sem&utm_source=google&utm_campaign=ch.sem_br.nonbrand_tp.prs_tgt.kafka_mt.xct_rgn.emea_lng.eng_dv.all_con.kafka-spring&utm_term=apache%20kafka%20spring&creative=&device=c&placement=&gclid=CjwKCAjwwqaGBhBKEiwAMk-FtFxg3qKuRsotG1cOIuXpYhkVcQB0SjdVFplQO-29JygGZA7-huflWBoCxIgQAvD_BwE

Blog Kurator

Bledion Vladi

Business Development

Email:

bvladi@thinkport.digital

Crossplane – composing cloud infrastructure in a more effective way

Crossplane - composing cloud infrastructure in a more effective way

Cloud Infrastructure with Crossplane

Contributor: Rodion Slepnev

Crossplane is an open-source software operating as an add-on on top of Kubernetes letting to provision infrastructure of any complexity and configuration using most prominent cloud providers such as Google Cloud Platform (GCP), Microsoft Azure and Amazon Web Services (AWS) as well as other like Equinix, Alibaba Cloud and Red Hat Cloud Suite and operates across Mac, Linux and Windows operating systems. Being an extension of Kubernetes it runs on Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), Alibaba Container Service for Kubernetes (ACK), Amazon Elastic Kubernetes Service (EKS) and others.

It enables to describe infrastructure declaratively without writing any code and extensively disclosing the underlying infrastructure of the particular vendor. 

Crossplane extends Kubernetes cluster, providing ready-to-use Custom Resource Definitions (CRDs), which create a new custom resources with a name and schema that are specified by a user. It is also possible to compose these granular resources into higher level abstractions that can be versioned, managed, deployed and consumed.

Figure 1 represents an example of composed infrastructure implemented via Crossplane making possible to combine resources from different vendors.

Fig.1 - Composing Infrastructure

Furthermore one can build his own internal infrastructure abstractions on top of the CRDs from Crossplane. New custom APIs can include policy guardrails, hiding infrastructure complexity — set of CRDs and controllers are bundled together known as packages that represent and manage external infrastructure (i.e. a provider), then installing them into a cluster where Crossplane is running.

Installation process: 

Following the guidelines we installed Crossplane on AWS EKS although. Figure 2 shows what applications are being launched on the cluster (so-called workloads).

Fig.2 - Crossplane on EKS cluster

Example as proof of concept: 

Figure 3 shows the custom script composed from two CRDs which creates a VPC with a Security Group in AWS environment (all default examples could be found here).

Fig.3 - Custom Script

The script itself describes infrastructure declaratively which as mentioned above lets encapsulate its specific details by using predefined words without writing any code and/or implementing it via internal sources like, for example, AWS Cloudformation. 

Descriptions of CRDs provided by Crossplane for all versions together with the references to the corresponding branches on GitHub can be found here

Script is being implemented via kubectl (Fig.4) as it is also mentioned with examples in the guidelines:

Fig.4 - Running the custom script

As a result one can see successfully provisioned Virtual Private Cloud (VPC) with a dedicated security group (Fig.5 and Fig.6):

Fig.5 - VPC provisioned from the custom script
Fig.6 - Security Group attached to VPC

Conclusion

Crossplane is currently under active development with a small community but showing reasonable progress looking at fixed issues. Although it has bugs being not fixed yet, features that are not reflected in the documentation especially installation part and the final stage is still far from completion Crossplane shows a quite good potential and in perspective could become more popular tool in its application area like, for example, Pulumi and other tools with similar functionality.

Thinkport is an actively developing company trying to find new approaches and technologies that concern cloud computing and relevant topics and it was very exciting to find and research Crossplane in one of its projects where it takes an active part. If you have further specific questions on the topic, or a handful of niche areas we are specialized in, visit our newly updated workshop page.

References: 
1. Crossplane official website — https://crossplane.io 
2. Crossplane GitHub repository — https://github.com/crossplane 
3. Crossplane documentation — https://crossplane.io/docs/v1.1
4. Kubernetes documentation — https://kubernetes.io/docs/home
5. CRD descriptions — https://doc.crds.dev/github.com/crossplane/crossplane

Blog Kurator

Bledion Vladi

Business Development

Email:

bvladi@thinkport.digital