Comment Optus améliore l'expérience client haut débit et mobile à l'aide de la plate-forme d'analyse de données réseau sur AWS

Republié par Platon

Suiveurs: 0

Il s'agit d'un article de blog invité co-écrit par Rajagopal Mahendran, responsable du développement au sein de l'équipe d'innovation informatique d'Optus.

Optus fait partie du groupe Singtel, qui opère dans l'une des régions les plus dynamiques et à la croissance la plus rapide au monde, avec une présence dans 21 pays. Optus fournit non seulement des services de télécommunications de base, mais également une vaste gamme de solutions numériques, y compris le cloud, la cybersécurité et la publicité numérique aux entreprises, ainsi que des services de divertissement et financiers mobiles à des millions de consommateurs. Optus fournit des services de communication mobile à plus de 10.4 millions de clients et des services haut débit à plus de 1.1 million de foyers et d'entreprises. De plus, Optus Sport connecte près d'un million de fans à des contenus de Premier League, de football international et de fitness.

Dans cet article, nous examinons comment Optus a utilisé Amazon Kinésis pour ingérer et analyser les données liées au réseau dans un lac de données sur AWS et améliorer l'expérience client et le processus de planification des services.

Le défi

Un défi commun pour les fournisseurs de télécommunications est de former une vue précise et en temps réel de la qualité de service et des problèmes rencontrés par leurs clients. La qualité du réseau domestique et de la connectivité haut débit a un impact significatif sur la productivité et la satisfaction des clients, en particulier compte tenu de la dépendance accrue aux réseaux domestiques pour le travail, la connexion avec la famille et les amis et les divertissements pendant la pandémie de COVID-19.

De plus, les équipes d'exploitation et de planification du réseau n'ont souvent pas accès aux bonnes données et informations pour planifier de nouveaux déploiements et gérer leur flotte actuelle d'appareils.

La plate-forme d'analyse de réseau fournit des données et des informations de dépannage et de planification aux équipes d'Optus et à leurs clients en temps quasi réel, ce qui permet de réduire le temps moyen de rectification et d'amélioration de l'expérience client. Avec les bonnes données et informations, les clients bénéficient d'une meilleure expérience car au lieu de lancer un appel d'assistance avec de nombreuses questions, le personnel d'assistance et le client ont une vue actuelle et précise des services et du réseau domestique du client.

Les équipes de propriétaires de services au sein d'Optus peuvent également utiliser les informations et les tendances dérivées de cette plate-forme pour mieux planifier l'avenir et fournir un service de meilleure qualité aux clients.

Considérations sur la conception

Pour relever ce défi et ses exigences, nous nous sommes lancés dans un projet visant à transformer notre système actuel de collecte et de traitement par lots en un système de traitement en temps quasi réel basé sur des flux, et à introduire des API pour obtenir des informations afin que les systèmes de support et les applications client puissent montrer le dernier instantané de l'état du réseau et du service.

Nous avions les exigences fonctionnelles et non fonctionnelles suivantes :

La nouvelle plate-forme doit être capable de supporter la capture de données des futurs types d'équipements clients ainsi que de nouveaux modes d'ingestion (nouveaux protocoles et fréquence) et de nouveaux formats de données.
Il doit prendre en charge plusieurs consommateurs (une API en temps quasi réel pour le personnel d'assistance et les applications client et les rapports opérationnels et commerciaux) pour consommer des données et générer des informations. L'objectif est que la plate-forme détecte de manière proactive les problèmes et génère des alertes appropriées pour le personnel d'assistance ainsi que pour les clients.
Une fois les données arrivées, les informations issues des données devraient être prêtes sous la forme d'une API en quelques secondes (5 secondes maximum).
La nouvelle plate-forme doit être suffisamment résiliente pour continuer le traitement en cas de défaillance de certaines parties de l'infrastructure, telles que les nœuds ou les zones de disponibilité.
Il peut prendre en charge un nombre accru d'appareils et de services ainsi qu'une collecte plus fréquente à partir des appareils.
Une petite équipe interfonctionnelle à travers les affaires et la technologie construira et exploitera cette plate-forme. Nous devons assurer une infrastructure minimale et des frais généraux opérationnels à long terme.
Le pipeline doit être hautement disponible et permettre de nouveaux déploiements sans temps d'arrêt.

Vue d'ensemble de la solution

En gardant à l'esprit l'objectif de la plate-forme et les considérations de conception, nous avons décidé d'utiliser des services d'ordre supérieur et des services sans serveur d'AWS dans la mesure du possible, afin d'éviter des frais généraux inutiles pour notre équipe et de nous concentrer sur les besoins commerciaux essentiels. Cela inclut l'utilisation de la famille de services Kinesis pour l'ingestion et le traitement des flux ; AWS Lambda pour traitement; Amazon DynamoDB, Service de base de données relationnelle Amazon (Amazon RDS), et Service de stockage simple Amazon (Amazon S3) pour la persistance des données ; et AWS Elastic Beanstalk ainsi que Passerelle d'API Amazon pour le service d'application et d'API. Le schéma suivant montre la solution globale.

La solution ingère les fichiers journaux de milliers d'équipements de réseau client (routeurs domestiques) dans des périodes prédéfinies. L'équipement du client est uniquement capable d'envoyer de simples requêtes HTTP PUT et POST pour transférer des fichiers journaux. Pour recevoir ces fichiers, nous utilisons une application Java exécutée dans un groupe Auto Scaling de Cloud de calcul élastique Amazon (Amazon EC2). Après quelques vérifications initiales, l'application réceptrice effectue un nettoyage et un formatage, puis diffuse les fichiers journaux vers Flux de données Amazon Kinesis.

Nous utilisons intentionnellement une application de récepteur personnalisée dans la couche d'ingestion pour offrir une flexibilité dans la prise en charge de différents appareils et formats de fichiers.

Pour comprendre le reste de l'architecture, regardons les insights attendus. La plateforme produit deux types d'insights :

idées individuelles – Les réponses aux questions de cette catégorie incluent :
- Combien d'erreurs un appareil client particulier a-t-il rencontrées au cours des 15 dernières minutes ?
- Quelle était la dernière erreur ?
- Combien d'appareils sont actuellement connectés chez un client particulier ?
- Quel est le taux de transfert/réception capturé par un appareil client particulier ?
Informations de base – Se rapportant à un groupe ou à l'ensemble de la base d'utilisateurs, les questions de cette catégorie incluent :
- Combien d'appareils clients ont signalé une interruption de service au cours des dernières 24 heures ?
- Quels types d'appareils (modèles) ont rencontré le plus grand nombre d'erreurs au cours des 6 derniers mois ?
- Après la mise à jour du correctif d'hier soir sur un groupe d'appareils, ont-ils signalé des erreurs ? La maintenance a-t-elle réussi ?

La voie supérieure de l'architecture montre le pipeline qui génère les informations individuelles.

Le mappage de source d'événement de la fonction Lambda est configuré pour consommer des enregistrements du flux de données Kinesis. Cette fonction lit les enregistrements, les formate et les prépare en fonction des informations requises. Enfin, il stocke les résultats dans l'emplacement Amazon S3 et met également à jour une table DynamoDB qui conserve un résumé et les métadonnées des données réelles stockées dans Amazon S3.

Pour optimiser les performances, nous avons configuré deux métriques dans le mappage de source d'événement Lambda :

Taille du lot – Affiche le nombre d'enregistrements à envoyer à la fonction dans chaque lot, ce qui permet d'atteindre un débit plus élevé
Lots simultanés par partition – Traite simultanément plusieurs lots du même fragment, ce qui permet un traitement plus rapide

Enfin, l'API est fournie via API Gateway et s'exécute sur une application Spring Boot hébergée sur Elastic Beanstalk. À l'avenir, nous devrons peut-être conserver l'état entre les appels d'API, c'est pourquoi nous utilisons Elastic Beanstalk au lieu d'une application sans serveur.

La voie du bas de l'architecture est le pipeline qui génère les rapports de base.

Nous utilisons Analyse des données Amazon Kinesis, exécutant un calcul avec état sur des données en continu, pour résumer certaines métriques telles que les taux de transfert ou les taux d'erreur dans des fenêtres temporelles données. Ces résumés sont ensuite poussés vers un Amazon Aurora base de données avec un modèle de données adapté aux tableaux de bord et aux rapports.

Les informations sont ensuite présentées dans des tableaux de bord à l'aide d'une application Web exécutée sur Elastic Beanstalk.

Les leçons apprises

L'utilisation de modèles sans serveur et de services d'ordre supérieur, en particulier Lambda, Kinesis Data Streams, Kinesis Data Analytics et DynamoDB, a fourni une grande flexibilité dans notre architecture et nous a aidés à nous tourner davantage vers les microservices plutôt que vers les gros travaux par lots monolithiques.

Ce changement nous a également permis de réduire considérablement nos frais généraux de gestion des opérations et des services. Par exemple, au cours des derniers mois depuis le lancement, les clients de cette plate-forme n'ont subi aucune interruption de service.

Cette solution nous a également permis d'adopter des méthodes de travail plus DevOps et agiles, dans le sens où une seule petite équipe développe et gère le système. Cela a permis à l'organisation d'être plus agile et innovante dans ce domaine.

Nous avons également découvert quelques conseils techniques au cours du développement et de la production qui valent la peine d'être partagés :

Résultats et avantages

Nous avons désormais une visibilité en temps quasi réel sur les performances de nos réseaux fixes et mobiles telles qu'elles sont vécues par nos clients. Dans le passé, nous n'avions que des données qui arrivaient en mode batch avec un retard et également uniquement de nos propres sondes et équipements réseau.

Grâce à la vue en temps quasi réel du réseau lorsque des changements se produisent, nos équipes opérationnelles peuvent également effectuer des mises à niveau et de la maintenance sur l'ensemble du parc d'appareils des clients avec une confiance et une fréquence accrues.

Enfin, nos équipes de planification utilisent ces informations pour former une vue précise et à jour des performances de divers équipements et services. Cela conduit à un service de meilleure qualité pour nos clients à de meilleurs prix car nos équipes de planification des services sont en mesure d'optimiser les coûts, de mieux négocier avec les fournisseurs et les prestataires de services et de planifier l'avenir.

Pour l'avenir

Avec la plate-forme d'analyse de réseau en production depuis plusieurs mois et maintenant stable, il existe une demande pour plus d'informations et de nouveaux cas d'utilisation. Par exemple, nous examinons un cas d'utilisation mobile pour mieux gérer la capacité lors d'événements à grande échelle (tels que des événements sportifs). L'objectif est que nos équipes soient axées sur les données et capables de réagir en temps quasi réel aux besoins de capacité lors de ces événements.

Un autre domaine de demande concerne la maintenance prédictive : nous cherchons à introduire l'apprentissage automatique dans ces pipelines pour aider à générer des informations plus rapidement et plus précisément en utilisant le portefeuille de services AWS Machine Learning.

À propos des auteurs

Rajagopal Mahendran est responsable du développement au sein de l'équipe d'innovation informatique d'Optus. Mahendran a plus de 14 ans d'expérience dans diverses organisations fournissant des applications d'entreprise de moyenne à très grande échelle en utilisant des technologies éprouvées de pointe dans le domaine des mégadonnées, des applications de données en continu, des applications mobiles et cloud natives. Sa passion est de propulser des idées innovantes en utilisant la technologie pour une vie meilleure. Dans ses temps libres, il aime marcher dans la brousse et nager.

Mostafa Safipour est un architecte de solutions chez AWS basé à Sydney. Il travaille avec les clients pour obtenir des résultats commerciaux en utilisant la technologie et AWS. Au cours de la dernière décennie, il a aidé de nombreuses grandes organisations de la région ANZ à créer leurs charges de travail de données, numériques et d'entreprise sur AWS.

Masudur Rahaman Sayem est un architecte de solutions spécialisé pour l'analyse chez AWS. Il travaille avec les clients AWS pour fournir des conseils et une assistance technique sur les projets de données et d'analyse, les aidant à améliorer la valeur de leurs solutions lorsqu'ils utilisent AWS. Il est passionné par les systèmes distribués. Il aime aussi lire, en particulier les bandes dessinées classiques.