Wer sich heutzutage mit Big Data Themen kombiniert mit Amazon Web Services (AWS) beschäftigt, benötigt in der Regel schon ein eigenes kleines Wörterbuch für die ganzen Abkürzungen und Toolnamen aus beiden Welten. Ein weiteres Thema ist die eigene Problemstellung in dieser neuen Welt zu implementieren. Das sich dieser Weg durchaus auf verschiedenen Ebenen lohnt, möchte ich in diesem Blogartikel aufzeigen.

Was ist AWS EMR

Amazon bietet eine eigene Big Data Distribution an. Diese hat neben dem Resourcen Manager (Yarn), einem Hadoop File System und Spark noch einige andere Tools wie Sqoop, Oozie und Zeppelin.

Durch den Elastic Map Reduce (EMR) Dienst wird ein Big Data Cluster komplett erzeugt, inklusive ausgewählter Hardware und Software. Wenn das entsprechende „Create Cluster“ Kommando verwendet wird dauert es ca. 7 Minuten bis der neue Cluster Einsatzbereit ist und alle Instanzen den Status „running“ haben.

Der Cluster kann beispielsweise über die AWS Console (AWS Webseite) konfiguriert werden oder über das AWS Kommandozeilentool. Das zuletzt genannte Tool stellt eine spannende Option für Automatisierungen dar.

AWS EMR kostet ein einen kleinen Betrag extra zu den anfallenden Kosten für die Instanzen.

In diesem Beispiel werden m4.large Instanz Typen in der Region EU(Frankfurt) verwendet.

Diese kosten in diesem Moment 0,12 US Dollar pro Instanz und Stunde. Der EMR Aufschlag beträgt 0,03 US Dollar pro Stunde und Instanz. Dies ist exklusive der Mehrwertsteuer. Es gibt zwar noch Transfer und Storage Gebühren und vieles mehr, aber die genannten Kosten und die Mehrwertsteuer stellen den absolut größten Teil der Kosten dar und können für eine grobe Kosteneinschätzung verwendet werden. Weitere Informationen hierzu können direkt auf der AWS Pricing Webseite nachgelesen werden.

Aufgerundet exklusive Mehrwertsteuer kostet jede Instanz pro Stunde 0,15 US Dollar.

Spot Instanzen

AWS bietet Spot Instanzen an. Die Idee ist, dass Kunden statt einem fixen Preis, wie bei den bisher hier verwendeten On-Demand Instanzen (m4.large 0,12 US Dollar pro Instanz pro Stunde), wie bei einer Auktion ein Gebot für die Nutzung der Instanzen abgeben. Dies kann dazu führen, dass Instanzen 90% unter dem On-Demand Preis zur Verfügung gestellt werden können. Daraus können bei richtiger Nutzung großartige Mehrwerte gezogen werden. Es muss nur definiert werden, was das Ziel sein soll. Eines könnte die Reduzierung der Kosten sein.

Ü„nderung der Abrechnungseinheiten von Stunden auf Sekunden

Eine aktuelle Ü„nderung in der Preisgestaltung von AWS ist die Umstellung der Abrechnungsintervalle zum 02.10.2017. Bisher wurden alle Instanzen Stundenweise abgerechnet, wenn eine Verarbeitung 125 Minuten dauert, dann wurden 3 Stunden für jede Instanz im Cluster berechnet. Dies wird jetzt auf sekundengenaue Abrechnung umgestellt. Nachlesen können sie die Details bei AWS direkt new-per-second-billing-for-ec2-instances-and-ebs-volumes.

Es gibt eine Mindestabnahmezeit pro Instanz von 60 Sekunden, danach wird sekundengenau abgerechnet. In unserem Beispiel (125 Minuten Verarbeitung) alte Berechnung:

Prei pro Instanz pro Stunde: 0,12 $ (Instanz) + 0,03 $ (EMR) (Steuern entfallen als Vereinfachung)

Natürlich ist beim Beispiel mit 125 Minuten der Effekt fast maximal. In diesem Beispiel wurden über 30% Kosten eingespart, durch die Veränderung der Abrechnungseinheiten

Was für Gruppen gibt es im EMR: Master, Core, Task

Das AWS EMR bietet durch die verwendete Hadoop Technologie basierend auf dem Hadoop File System (HDFS) und dem Resourcen Manager (YARN) eine perfekte Umgebung, um AWS Spot Instanzen zu verwenden.

Sowohl Instanzen aus der Master Gruppe, wie auch aus der Core Gruppe, sollten nicht mit Spot Instanzen verwendet werden. In der Master Gruppe laufen in der Regel die Master Prozesse von Anwendungen, also zum Beispiel der HDFS NameNode oder den Applications Manager, welcher einen Teil des Yarn Resource Manager ist. An dieser Stelle müssen On-Demand Instanzen verwendet werden, da die Instanzen nicht wegfallen dürfen.

Auch in der Core Gruppe sollten keine Instanzen wegfallen. In dieser Gruppe liegen die DataNodes des HDFS. Wenn von diesen DataNodes zu viele wegfallen, kann es trotz impliziter Replikation zu Datenverlusten kommen.

Die Task Gruppe und ihre Instanzen sind optional und haben weder NameNode noch DataNode Prozesse. Es werden hier also keine HDFS Daten persistiert sondern lediglich Resourcen für die Verarbeitung zur Verfügung gestellt. Aus HDFS Sicht sind die Task Nodes also nicht existent, für Yarn stellen sie jedoch zusätzliche Verarbeitungs-Resourcen zur Verfügung.

Dies hat zur Folge, dass vorhandene Task Instanzen die Verarbeitung beschleunigen. Sollten diese Instanzen mitten in der Verarbeitung nicht mehr verfügbar sein, wie es bei Spot Instanzen der Fall sein kann, ist dies kein Problem. Der Resourcen Manager stellt fest, dass Verarbeitungs-Resourcen weggefallen sind und verteilt deren Aufgaben an andere Instanzen die verfügbar sind und Kapazitäten frei haben. Dies kann sich nur auf die Laufzeit nicht aber auf den Erfolg der Verarbeitung auswirken.

Beispielsetup mit einer Task Gruppe die aus Spot Instanzen besteht

Dies ergibt spannende Möglichkeiten. Wenn die Verarbeitung mit einer Master und 8 Core On-Demand Instanzen durchgeführt wird und 125 Minuten dauert, berechnen wir die EC2 und EMR Kosten für diese Verarbeitung. Wenn weitere 8 Task Spot Instanzen hinzukommen reduziert sich die Laufzeit auf 65% von 125 Minuten (2,08 Stunden) ergibt 81,25 Minuten (1,35 Stunden) Laufzeit.

Der Preis pro Instanz pro Stunde für On-Demand setzt sich zusammen aus (0,12 $ Instanz, 0,03 $ EMR).

Der Preis pro Stunde für Spot Instanzen setzt sich zusammen aus (0,03 $ Instanz und 0,03 $ EMR).

Durch das Hinzufügen von 8 Spot Instanzen als EMR Task Gruppe wurde die Laufzeit der Verarbeitung um 35% reduziert und das zu etwa 12,02% reduzierten Kosten.

Im Positivfall wurde sowohl Geld gespart als auch eine deutlich kürzere Verarbeitungszeit benötigt. Der Negativfall, wir bekommen die Spotinstanzen nicht zu dem gewünschten Preis, bedeutet 100% Laufzeit und 100% Kosten wir haben also den Status Quo.

Dies stellt nur ein einfaches Beispiel dar, was mit etwas Kreativität möglich ist. Natürlich skalieren verschiedene Daten und Programme unterschiedliche und der geneigte Leser muss eigene Tests durchführen, welches Setup das Passende ist. Dabei sind nicht nur Kostenoptimierungen, sondern auch Laufzeitoptimierungen als Ziel möglich. Wie verschiedene Instanz Typen (M4.Large in diesem Beispiel) zu der eigenen Verarbeitung passen wurde ebenfalls komplett ausgeblendet. Auch hier bietet sich noch einiges an Optimierungspotential.