Suchen

Expertenbeitrag

 Rostislav Markov

Rostislav Markov

Senior Consultant , Amazon Web Services

Serie: Konzeption & Aufbau einer IIoT-Lösung Intelligent skalieren im IIoT

| Autor/ Redakteur: Rostislav Markov und Kathleen deValk* / Sebastian Human

Im Rahmen einer wöchentlichen Serie behandeln wir die Entwicklung einer erfolgreichen IIoT-Plattform. Teil 4 fokussiert die Dimensionierung und Skalierung der nötigen Infrastruktur.

Firmen zum Thema

Grundzüge und Richtlinien einer späteren Skalierung sollten frühzeitig festgelegt werden, um eine IIoT-Plattform bestmöglich auf das zukünftige Lastaufkommen vorzubereiten.
Grundzüge und Richtlinien einer späteren Skalierung sollten frühzeitig festgelegt werden, um eine IIoT-Plattform bestmöglich auf das zukünftige Lastaufkommen vorzubereiten.
(Bild: gemeinfrei / Unsplash)

Ein großer Vorteil von Cloud-Diensten ist, dass diese ohne nennenswerten Aufwand skaliert werden können. So bringen entsprechend gute Services von Anfang an automatische Skalierungsfunktionen mit. Dadurch kann sich die Infrastruktur quasi von selbst dem wachsenden Bedarf über mehrere Verfügbarkeitszonen und sogar Regionen hinweg anpassen. Allerdings bedeutet Skalierbarkeit im IIoT mehr als nur die physische Konfiguration horizontaler und vertikaler Prozesse durch die Modifikation von Hardware und den zugehörigen Softwarediensten. Vielmehr muss die gesamte Plattform von vornherein für jede Art der Skalierung konzeptioniert sein. Nur so lässt sich in jedem Anwendungsfall garantieren, dass sämtliche Servicelasten tatsächlich verarbeitet werden können.

Servicelimits für AWS-Dienste

Jeder AWS-Dienst hat harte und weiche Grenzen: Mikroservices mit Richtlinien zur automatischen Skalierung können wahlweise als virtuelle Maschinen in der Amazon Elastic Compute Cloud (EC2) laufen oder per Elastic Container Service (ECS) beziehungsweise dem Elastic Kubernetes Service (EKS) bereitgestellt werden. Eine weitere Alternative sind serverlose Container mit AWS Lambda.

Ganz egal, wie der Work-Load verarbeitet wird: In jedem Fall ist eine physische Infrastruktur erforderlich – und diese hat durchaus Limits.

Weiche Grenzen schützen dabei vor zu hoher Ressourcenbindung. Sie sorgen dafür, dass nicht unnötigerweise zu viele Kapazitäten angefordert werden. Im Bedarfsfall lassen sich diese Soft Limits jederzeit erhöhen. Hard Limits dagegen sind fest im Design der AWS-Services verankert und können nicht verändert werden. So sind zum Beispiel Skalierungsaktionen bei der Verarbeitung von Zeitreihendaten mit Kinesis Streams nur zweimal alle 24 Stunden möglich. Für DynamoDB-Stream-Tabellen wiederum gilt ein hartes Limit von maximal 1.000 Schreibvorgängen pro Sekunde.

Die Skalierung erfolgt oftmals automatisch durch den jeweiligen Dienst. Unter Umständen muss man aber auch eine Startphase zum Aufwärmen der notwendigen Infrastruktur einplanen – etwa die Anlaufzeit eines zugrundeliegenden Containers, der den Work-Load für den betreffenden Service verarbeitet. Auch das erneute Orchestrieren der Arbeitslast über eine erweiterte Infrastruktur kann eine bestimmte Zeitspanne in Anspruch nehmen. Beim Lösungsdesign gilt es daher, Servicelimits und ihre wechselseitigen Abhängigkeiten genau zu beachten. Nur dann funktioniert die Gesamtlösung später wie geplant.

Plattformnutzung klar reglementieren

Die Frage ist, wie Entwickler mit unerwarteten Lastspitzen umgehen können, die über die festgelegten Servicelimits hinausgehen. Sobald die APIs einer IIoT-Plattform geöffnet werden, ist die tatsächliche Nutzung für einen bestimmten Zeitpunkt nicht mehr eindeutig vorhersehbar. Neue Anwendungen könnten ihre Schnittstellen mit mehr Anfragen belasten, als die Plattform bewältigen kann und damit die Leistung drosseln und sogar zu Datenverlust führen.

Vermeiden lässt sich diese Situation natürlich durch eine entsprechend großzügige Infrastruktur-Dimensionierung, die jede nur denkbare Lastspitze abfängt – was allerdings eine sehr kostspielige Option darstellt. Deutlich günstiger ist es, die Kapazitätsbeschränkungen in einem Modell der geteilten Verantwortung zu kommunizieren und klare Vorgaben für die Verwendung von Plattform-APIs zu definieren. Zudem empfiehlt es sich, die tatsächliche Plattformnutzung zu messen, um Lastspitzen, Belastungsmuster sowie Durchschnittswerte auf Tages- oder Wochenbasis zu erhalten. Gänzlich ausschließen lassen sich unerwartete Lastspitzen aber auch damit nicht.

Zur Einhaltung der vorgegebenen Servicelimits ist es deshalb ratsam, API-Entwickler aufzufordern, den Kapazitätsbedarf ihrer Anwendungen während der Registrierung mitzuteilen. Auch automatische Meldungen von IIoT-Geräten beim Erreichen bestimmter Schwellenwerte ermöglichen es, proaktiv auf bevorstehende Lastspitzen zu reagieren. Die Stabilität einer IIoT-Plattform kann also auf Dauer nur durch eine klare Reglementierung der Nutzungsbedingungen gewährleistet werden.

Infrastruktur optimal dimensionieren

Die richtige Dimensionierung der Infrastruktur stellt die Weichen für einen proaktiven Umgang sowohl mit geplanten als auch mit ungeplanten Auslastungsspitzen. Sie legt außerdem fest, wie viel nicht mehr benötigte Kapazität später wieder freigegeben werden kann. Wer von Anfang an die Grundzüge und Richtlinien für die Skalierung definiert, nutzt die wichtigsten Stellschrauben, um seine Lösungskonfiguration optimal an das künftige Lastaufkommen anzupassen.

Die richtige Dimensionierung einer IIoT-Plattform betrifft nicht nur den Produktivbetrieb, sondern auch die Lösungsentwicklung. Gerade in der Test- und Entwicklungsphase werden die Infrastrukturkosten vielerorts vernachlässigt. Eine automatische Skalierung, mit geplanten Start- und Stoppzeiten, oder die On-Demand-Bereitstellung der Umgebung können dabei helfen, Kosten zu sparen. Auch in der Produktivphase sorgen durchdachte Skalierungsrichtlinien für eine nachhaltig kostengünstige Ressourcenausnutzung.

Im nächsten Teil der Serie geht es um die Frage, wie sich ein hohes Bereitstellungstempo schon im Lösungsdesign verankern lässt. Dabei handelt es sich um einen wichtigen Erfolgsfaktor beim Betrieb einer IIoT-Plattform.

* Kathleen deValk arbeitet als Chief Architect Siemens MindSphere.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 46379744)

Über den Autor

 Rostislav Markov

Rostislav Markov

Senior Consultant , Amazon Web Services