Wie Optus das Breitband- und Mobilfunk-Kundenerlebnis mithilfe der Network Data Analytics-Plattform auf AWS verbessert

Quellknoten: 886719

Dies ist ein Gast-Blogbeitrag, der von Rajagopal Mahendran, Entwicklungsmanager beim Optus IT Innovation Team, mitgeschrieben wurde.


Optus ist Teil der Singtel-Gruppe, die in einer der am schnellsten wachsenden und dynamischsten Regionen der Welt tätig ist und in 21 Ländern vertreten ist. Optus bietet nicht nur Kerntelekommunikationsdienste, sondern auch eine umfangreiche Palette digitaler Lösungen, darunter Cloud, Cybersicherheit und digitale Werbung für Unternehmen sowie Unterhaltungs- und mobile Finanzdienstleistungen für Millionen von Verbrauchern. Optus bietet mobile Kommunikationsdienste für über 10.4 Millionen Kunden und Breitbanddienste für über 1.1 Millionen Haushalte und Unternehmen. Darüber hinaus verbindet Optus Sport fast 1 Million Fans mit Inhalten aus der Premier League, internationalem Fußball und Fitness.

In diesem Beitrag schauen wir uns an, wie Optus verwendet wurde Amazon Kinesis um netzwerkbezogene Daten in einem Data Lake auf AWS aufzunehmen und zu analysieren und das Kundenerlebnis und den Serviceplanungsprozess zu verbessern.

Die Herausforderung

Eine häufige Herausforderung für Telekommunikationsanbieter besteht darin, sich in Echtzeit einen genauen Überblick über die Servicequalität und die Probleme ihrer Kunden zu verschaffen. Die Qualität von Heimnetzwerken und Breitbandkonnektivität hat erhebliche Auswirkungen auf die Produktivität und Zufriedenheit der Kunden, insbesondere angesichts der zunehmenden Abhängigkeit von Heimnetzwerken für die Arbeit, die Verbindung mit Familie und Freunden sowie für die Unterhaltung während der COVID-19-Pandemie.

Darüber hinaus haben Netzwerkbetriebs- und Planungsteams häufig keinen Zugriff auf die richtigen Daten und Erkenntnisse, um neue Rollouts zu planen und ihre aktuelle Geräteflotte zu verwalten.

Die Netzwerkanalyseplattform stellt Optus-Teams und ihren Kunden nahezu in Echtzeit Daten und Erkenntnisse zur Fehlerbehebung und Planung zur Verfügung, was dazu beiträgt, die mittlere Zeit zur Behebung zu verkürzen und das Kundenerlebnis zu verbessern. Mit den richtigen Daten und Erkenntnissen haben Kunden ein besseres Erlebnis, denn anstatt einen Supportanruf mit vielen Fragen zu starten, haben die Supportmitarbeiter und der Kunde einen aktuellen und genauen Überblick über die Dienste und das Heimnetzwerk des Kunden.

Service-Owner-Teams innerhalb von Optus können die aus dieser Plattform gewonnenen Erkenntnisse und Trends auch nutzen, um besser für die Zukunft zu planen und den Kunden einen qualitativ hochwertigeren Service zu bieten.

Entwurfsüberlegungen

Um dieser Herausforderung und ihren Anforderungen zu begegnen, haben wir ein Projekt gestartet, um unser aktuelles Batch-Erfassungs- und Verarbeitungssystem in ein Stream-basiertes Verarbeitungssystem nahezu in Echtzeit umzuwandeln und APIs für Erkenntnisse einzuführen, die Supportsysteme und Kundenanwendungen anzeigen können die neueste Momentaufnahme des Netzwerk- und Dienststatus.

Wir hatten die folgenden funktionalen und nichtfunktionalen Anforderungen:

  • Die neue Plattform muss in der Lage sein, die Datenerfassung von künftigen Arten von Kundengeräten sowie neue Arten der Erfassung (neue Protokolle und Häufigkeit) und neue Datenformate zu unterstützen.
  • Es sollte mehrere Verbraucher unterstützen (eine nahezu in Echtzeit arbeitende API für Supportmitarbeiter und Kundenanwendungen sowie Betriebs- und Geschäftsberichte), um Daten zu konsumieren und Erkenntnisse zu generieren. Ziel ist es, dass die Plattform Probleme proaktiv erkennt und entsprechende Warnmeldungen an Supportmitarbeiter und Kunden generiert.
  • Nachdem die Daten eingegangen sind, sollten die Erkenntnisse aus den Daten in wenigen Sekunden (maximal 5 Sekunden) in Form einer API vorliegen.
  • Die neue Plattform sollte robust genug sein, um die Verarbeitung fortzusetzen, wenn Teile der Infrastruktur ausfallen, beispielsweise Knoten oder Verfügbarkeitszonen.
  • Es kann eine größere Anzahl von Geräten und Diensten sowie eine häufigere Erfassung von den Geräten unterstützen.
  • Ein kleines funktionsübergreifendes Team aus Wirtschaft und Technologie wird diese Plattform aufbauen und betreiben. Wir müssen auf lange Sicht einen minimalen Infrastruktur- und Betriebsaufwand sicherstellen.
  • Die Pipeline sollte hochverfügbar sein und neue Bereitstellungen ohne Ausfallzeiten ermöglichen.

Lösungsüberblick

Unter Berücksichtigung des Plattformziels und von Designüberlegungen haben wir uns entschieden, nach Möglichkeit höherwertige Services und serverlose Services von AWS zu nutzen, um unnötigen Betriebsaufwand für unser Team zu vermeiden und uns auf die Kerngeschäftsanforderungen zu konzentrieren. Dazu gehört die Nutzung der Kinesis-Dienstfamilie für die Stream-Aufnahme und -Verarbeitung; AWS Lambda zum Bearbeiten; Amazon DynamoDB, Relationaler Amazon-Datenbankdienst (Amazon RDS) und Amazon Simple Storage-Service (Amazon S3) für Datenpersistenz; Und AWS Elastic Beanstalk und Amazon API-Gateway für Anwendungs- und API-Bereitstellung. Das folgende Diagramm zeigt die Gesamtlösung.

Die Lösung erfasst in vordefinierten Zeiträumen Protokolldateien von Tausenden Netzwerkgeräten des Kunden (Heimrouter). Das Kundengerät ist nur in der Lage, einfache HTTP-PUT- und POST-Anfragen zur Übertragung von Protokolldateien zu senden. Um diese Dateien zu empfangen, verwenden wir eine Java-Anwendung, die in einer Auto Scaling-Gruppe ausgeführt wird Amazon Elastic Compute-Cloud (Amazon EC2) Instanzen. Nach einigen ersten Prüfungen führt die Empfängeranwendung eine Bereinigung und Formatierung durch und streamt dann die Protokolldateien an Amazon Kinesis-Datenströme.

Wir verwenden absichtlich eine benutzerdefinierte Empfängeranwendung in der Aufnahmeschicht, um Flexibilität bei der Unterstützung verschiedener Geräte und Dateiformate zu bieten.

Um den Rest der Architektur zu verstehen, werfen wir einen Blick auf die erwarteten Erkenntnisse. Die Plattform liefert zwei Arten von Erkenntnissen:

  • Individuelle Einblicke – Zu den in dieser Kategorie beantworteten Fragen gehören:
    • Wie viele Fehler sind bei einem bestimmten Kundengerät in den letzten 15 Minuten aufgetreten?
    • Was war der letzte Fehler?
    • Wie viele Geräte sind derzeit bei einem bestimmten Kunden zu Hause angeschlossen?
    • Wie hoch ist die Übertragungs-/Empfangsrate, die von einem bestimmten Kundengerät erfasst wird?
  • Grundlegende Erkenntnisse – Fragen in dieser Kategorie, die sich auf eine Gruppe oder die gesamte Benutzerbasis beziehen, umfassen:
    • Wie viele Kundengeräte haben in den letzten 24 Stunden eine Dienstunterbrechung gemeldet?
    • Bei welchen Gerätetypen (Modellen) kam es in den letzten 6 Monaten zu den meisten Fehlern?
    • Wurden nach dem Patch-Update gestern Abend auf einer Gruppe von Geräten irgendwelche Fehler gemeldet? War die Wartung erfolgreich?

Die oberste Zeile in der Architektur zeigt die Pipeline, die die einzelnen Erkenntnisse generiert.

Die Ereignisquellenzuordnung der Lambda-Funktion ist so konfiguriert, dass sie Datensätze aus dem Kinesis-Datenstrom konsumiert. Diese Funktion liest die Datensätze, formatiert sie und bereitet sie basierend auf den erforderlichen Erkenntnissen vor. Schließlich speichert es die Ergebnisse am Amazon S3-Speicherort und aktualisiert außerdem eine DynamoDB-Tabelle, die eine Zusammenfassung und die Metadaten der tatsächlich in Amazon S3 gespeicherten Daten verwaltet.

Um die Leistung zu optimieren, haben wir zwei Metriken in der Lambda-Ereignisquellenzuordnung konfiguriert:

  • Chargengröße – Zeigt die Anzahl der Datensätze an, die in jedem Stapel an die Funktion gesendet werden sollen, was zu einem höheren Durchsatz beiträgt
  • Gleichzeitige Stapel pro Shard – Verarbeitet mehrere Stapel aus demselben Shard gleichzeitig, was zu einer schnelleren Verarbeitung beiträgt

Schließlich wird die API über API Gateway bereitgestellt und läuft auf einer Spring Boot-Anwendung, die auf Elastic Beanstalk gehostet wird. In Zukunft müssen wir möglicherweise den Status zwischen API-Aufrufen beibehalten, weshalb wir Elastic Beanstalk anstelle einer serverlosen Anwendung verwenden.

Die unterste Spur in der Architektur ist die Pipeline, die Basisberichte generiert.

Wir verwenden Amazon Kinesis-Datenanalyse, zustandsbehaftete Berechnung von Streaming-Daten ausführen, um bestimmte Metriken wie Übertragungsraten oder Fehlerraten in bestimmten Zeitfenstern zusammenzufassen. Diese Zusammenfassungen werden dann an eine weitergeleitet Amazonas-Aurora Datenbank mit einem Datenmodell, das für Dashboarding- und Berichtszwecke geeignet ist.

Die Erkenntnisse werden dann mithilfe einer auf Elastic Beanstalk ausgeführten Webanwendung in Dashboards präsentiert.

Lessons learned

Die Verwendung serverloser Muster und Dienste höherer Ordnung, insbesondere Lambda, Kinesis Data Streams, Kinesis Data Analytics und DynamoDB, sorgte für viel Flexibilität in unserer Architektur und half uns, mehr auf Microservices statt auf große monolithische Batch-Jobs umzusteigen.

Diese Umstellung hat uns auch dabei geholfen, den Aufwand für das Betriebs- und Servicemanagement drastisch zu senken. Beispielsweise kam es bei Kunden dieser Plattform in den letzten Monaten seit der Einführung zu keiner Serviceunterbrechung.

Diese Lösung ermöglichte es uns auch, mehr DevOps und agile Arbeitsweisen einzuführen, in dem Sinne, dass ein einziges kleines Team das System entwickelt und betreibt. Dies wiederum ermöglichte es der Organisation, in diesem Bereich agiler und innovativer zu sein.

Im Laufe der Entwicklung und Produktion haben wir auch einige technische Tipps entdeckt, die es wert sind, weitergegeben zu werden:

Ergebnisse und Vorteile

Wir haben jetzt nahezu in Echtzeit Einblick in die Leistung unserer Fest- und Mobilfunknetze, wie sie unsere Kunden erleben. In der Vergangenheit hatten wir nur Daten, die im Batch-Modus mit Verzögerung kamen und auch nur von unseren eigenen Netzwerksonden und Geräten.

Mit der nahezu Echtzeitansicht des Netzwerks bei Änderungen können unsere Betriebsteams auch Upgrades und Wartungsarbeiten an der gesamten Kundengeräteflotte zuverlässiger und häufiger durchführen.

Schließlich nutzen unsere Planungsteams diese Erkenntnisse, um eine genaue, aktuelle Leistungsübersicht über verschiedene Geräte und Dienstleistungen zu erstellen. Dies führt zu einer höheren Servicequalität für unsere Kunden zu besseren Preisen, da unsere Serviceplanungsteams in die Lage versetzt werden, Kosten zu optimieren, besser mit Anbietern und Dienstleistern zu verhandeln und für die Zukunft zu planen.

Blick in die Zukunft

Da die Netzwerkanalyseplattform seit mehreren Monaten in Produktion ist und nun stabil ist, besteht Bedarf an weiteren Erkenntnissen und neuen Anwendungsfällen. Wir prüfen beispielsweise einen mobilen Anwendungsfall, um die Kapazität bei Großveranstaltungen (z. B. Sportveranstaltungen) besser zu verwalten. Das Ziel besteht darin, dass unsere Teams datengesteuert sind und nahezu in Echtzeit auf den Kapazitätsbedarf bei diesen Ereignissen reagieren können.

Ein weiterer Bedarfsbereich betrifft die vorausschauende Wartung: Wir möchten maschinelles Lernen in diese Pipelines einführen, um mithilfe des AWS Machine Learning-Serviceportfolios schnellere und genauere Erkenntnisse zu gewinnen.


Über die Autoren

Rajagopal Mahendran ist Entwicklungsmanager beim Optus IT Innovation Team. Mahendran verfügt über mehr als 14 Jahre Erfahrung in verschiedenen Organisationen bei der Bereitstellung von Unternehmensanwendungen mittlerer bis sehr großer Größenordnung unter Verwendung bewährter bis hochmoderner Technologien in den Bereichen Big Data, Streaming-Datenanwendungen, mobile und Cloud-native Anwendungen. Seine Leidenschaft ist es, innovative Ideen mithilfe von Technologie für ein besseres Leben voranzutreiben. In seiner Freizeit liebt er Buschwanderungen und Schwimmen.

Mostafa Safipour ist Lösungsarchitekt bei AWS mit Sitz in Sydney. Er arbeitet mit Kunden zusammen, um mithilfe von Technologie und AWS Geschäftsergebnisse zu erzielen. Im letzten Jahrzehnt hat er vielen großen Organisationen in der ANZ-Region dabei geholfen, ihre Daten-, Digital- und Unternehmens-Workloads auf AWS aufzubauen.

Masudur Rahaman Sayem ist ein Spezialist für Lösungsarchitekten für Analytics bei AWS. Er arbeitet mit AWS-Kunden zusammen, um ihnen Beratung und technische Unterstützung bei Daten- und Analyseprojekten zu bieten und ihnen dabei zu helfen, den Wert ihrer Lösungen beim Einsatz von AWS zu steigern. Seine Leidenschaft gilt verteilten Systemen. Er liest auch gerne, vor allem klassische Comics.

Quelle: https://aws.amazon.com/blogs/big-data/how-optus-improves-broadband-and-mobile-customer-experience-using-the-network-data-analytics-platform-on-aws/

Zeitstempel:

Mehr von AWS