Hogyan javítja az Optus a szélessávú és mobil ügyfélélményt az AWS Network Data Analytics platformjával?

Ez egy vendégblogbejegyzés, amelyet Rajagopal Mahendran, az Optus IT Innovation Team fejlesztési menedzsere közösen írt.

---

Az Optus a The Singtel csoport része, amely a világ egyik leggyorsabban növekvő és legdinamikusabb régiójában működik, és 21 országban van jelen. Az Optus nemcsak alapvető távközlési szolgáltatásokat nyújt, hanem digitális megoldások széles skáláját is, beleértve a felhőt, a kiberbiztonságot és a digitális reklámozást a vállalatoknak, valamint szórakoztató és mobil pénzügyi szolgáltatásokat fogyasztók millióinak. Az Optus több mint 10.4 millió ügyfélnek nyújt mobilkommunikációs szolgáltatásokat, több mint 1.1 millió otthonnak és vállalkozásnak pedig szélessávú szolgáltatásokat. Ezenkívül az Optus Sport közel 1 millió rajongót kapcsol össze a Premier League-ben, a nemzetközi futball- és fitnesztartalommal.

Ebben a bejegyzésben megnézzük, hogyan használta az Optus Amazon kinezis a hálózattal kapcsolatos adatok feldolgozása és elemzése az AWS-en található Data Lake-ben, valamint az ügyfélélmény és a szolgáltatástervezési folyamat javítása.

A kihívás

A távközlési szolgáltatók közös kihívása, hogy pontos, valós idejű képet alkossanak a szolgáltatás minőségéről és az ügyfeleik által tapasztalt problémákról. Az otthoni hálózat és a szélessávú csatlakozás minősége jelentős hatással van az ügyfelek termelékenységére és elégedettségére, különös tekintettel arra, hogy a COVID-19 világjárvány idején a munka, a családdal és a barátokkal való kapcsolattartás, valamint a szórakozás során fokozottan támaszkodnak az otthoni hálózatokra.

Ezenkívül a hálózati műveletek és a tervezési csapatok gyakran nem férnek hozzá a megfelelő adatokhoz és információkhoz az új bevezetések megtervezéséhez és jelenlegi eszközparkjuk kezeléséhez.

A hálózati elemző platform csaknem valós időben nyújt hibaelhárítási és tervezési adatokat és betekintést az Optus csapatainak és ügyfeleiknek, ami segít csökkenteni a kijavításhoz szükséges átlagos időt és javítani az ügyfélélményt. A megfelelő adatokkal és betekintéssel az ügyfelek jobb élményben részesülnek, mert ahelyett, hogy sok kérdést tartalmazó ügyfélszolgálati hívást kezdeményeznének, a támogató személyzet és az ügyfél aktuális és pontos rálátása van a szolgáltatásokra és az ügyfél otthoni hálózatára.

Az Optuson belüli szolgáltatástulajdonos csapatok az ebből a platformból származó ismereteket és trendeket is felhasználhatják, hogy jobban megtervezzék a jövőt, és magasabb színvonalú szolgáltatást nyújtsanak az ügyfeleknek.

Tervezési szempontok

Ennek a kihívásnak és a követelményeknek való megfelelés érdekében elindítottunk egy projektet, amelynek célja, hogy jelenlegi kötegelt adatgyűjtési és feldolgozási rendszerünket stream-alapú, közel valós idejű feldolgozórendszerré alakítsuk át, és API-kat vezessünk be a betekintéshez, hogy a támogató rendszerek és az ügyfélalkalmazások megmutathassák. a hálózat és a szolgáltatás állapotának legfrissebb pillanatképe.

A következő funkcionális és nem funkcionális követelményeink voltak:

• Az új platformnak képesnek kell lennie arra, hogy támogassa az adatrögzítést a jövőbeli ügyfélberendezésekről, valamint az új adatbeviteli módokat (új protokollok és gyakoriság) és új adatformátumokat.
• Támogatnia kell több fogyasztót (közel valós idejű API a támogató személyzet és az ügyfélalkalmazások, valamint a működési és üzleti jelentéskészítés számára) az adatok felhasználásához és a betekintések generálásához. A cél az, hogy a platform proaktívan észlelje a problémákat, és megfelelő riasztást generáljon a támogató személyzet és az ügyfelek számára.
• Az adatok megérkezése után néhány másodpercen belül (legfeljebb 5 másodpercen belül) API formájában készen kell lennie az adatokból származó betekintéseknek.
• Az új platformnak elég rugalmasnak kell lennie ahhoz, hogy folytassa a feldolgozást, ha az infrastruktúra egyes részei, például csomópontok vagy elérhetőségi zónák meghibásodnak.
• Támogathatja az eszközök és szolgáltatások megnövekedett számát, valamint az eszközökről való gyakoribb gyűjtést.
• Ezt a platformot egy kis, többfunkciós csapat fogja felépíteni és működtetni az üzleti életben és a technológiában. Hosszú távon minimális infrastruktúrát és működési rezsiköltséget kell biztosítanunk.
• A csővezetéknek magasan rendelkezésre kell állnia, és lehetővé kell tennie az új telepítéseket leállás nélkül.

Megoldás áttekintése

A platform célját és a tervezési szempontokat szem előtt tartva úgy döntöttünk, hogy ahol lehetséges, magasabb szintű szolgáltatásokat és szerver nélküli szolgáltatásokat használunk az AWS-től, hogy elkerüljük csapatunk felesleges működési költségeit, és az alapvető üzleti igényekre összpontosítsunk. Ez magában foglalja a Kinesis szolgáltatáscsalád használatát az adatfolyamok befogadására és feldolgozására; AWS Lambda feldolgozásra; Amazon DynamoDB, Amazon Relációs adatbázis-szolgáltatás (Amazon RDS), és Amazon egyszerű tárolási szolgáltatás (Amazon S3) az adatok fennmaradásához; és AWS Elastic Beanstalk és a Amazon API átjáró alkalmazásokhoz és API kiszolgáláshoz. Az alábbi ábra az átfogó megoldást mutatja.

A megoldás az ügyfelek több ezer hálózati eszközétől (otthoni útválasztóktól) előre meghatározott időszakonként feldolgozza a naplófájlokat. Az ügyfél berendezése csak egyszerű HTTP PUT és POST kérések küldésére képes a naplófájlok átvitelére. E fájlok fogadásához egy Java-alkalmazást használunk, amely az Auto Scaling csoportban fut Amazon rugalmas számítási felhő (Amazon EC2) példányok. Néhány kezdeti ellenőrzés után a fogadó alkalmazás végrehajtja a tisztítást és a formázást, majd a naplófájlokat továbbítja a Amazon Kinesis adatfolyamok.

Szándékosan egyéni vevőalkalmazást használunk a feldolgozási rétegben, hogy rugalmasságot biztosítsunk a különböző eszközök és fájlformátumok támogatásában.

Az architektúra többi részének megértéséhez vessünk egy pillantást a várható betekintésekre. A platform kétféle betekintést nyújt:

• Egyéni meglátások – Az ebben a kategóriában megválaszolt kérdések a következők:
  • Hány hibát tapasztalt egy adott ügyféleszköz az elmúlt 15 percben?
  • Mi volt az utolsó hiba?
  • Hány eszköz van jelenleg csatlakoztatva egy adott ügyfél otthonában?
  • Mekkora az átviteli/fogadási sebesség egy adott ügyféleszköz által?
• Alapbetekintések – Egy csoportra vagy a teljes felhasználói bázisra vonatkozóan az ebbe a kategóriába tartozó kérdések a következők:
  • Hány ügyféleszköz jelentett szolgáltatáskimaradást az elmúlt 24 órában?
  • Mely eszköztípusoknál (modelleknél) fordult elő a legtöbb hiba az elmúlt 6 hónapban?
  • Az eszközök egy csoportján a tegnap esti javítás frissítése után jelentettek bármilyen hibát? Sikeres volt a karbantartás?

Az architektúra legfelső sávja az egyéni betekintést generáló folyamatot mutatja.

A Lambda funkció eseményforrás-leképezése úgy van konfigurálva, hogy a Kinesis adatfolyam rekordjait használja fel. Ez a funkció beolvassa a rekordokat, formátumokat, és a szükséges ismeretek alapján előkészíti azokat. Végül az eredményeket az Amazon S3 helyén tárolja, és frissít egy DynamoDB táblát is, amely összefoglalót és az Amazon S3-ban tárolt tényleges adatok metaadatait karbantartja.

A teljesítmény optimalizálása érdekében két mérőszámot konfiguráltunk a Lambda eseményforrás-leképezésben:

• Csomó méret – Megmutatja az egyes kötegekben a függvénynek elküldendő rekordok számát, ami segít a nagyobb átviteli sebesség elérésében
• Egyidejű kötegek szilánkonként – Egyszerre több köteget dolgoz fel ugyanabból a szilánkból, ami elősegíti a gyorsabb feldolgozást

Végül az API-t az API Gateway biztosítja, és egy Spring Boot alkalmazáson fut, amelyet az Elastic Beanstalk tárol. A jövőben előfordulhat, hogy meg kell őriznünk az állapotot az API-hívások között, ezért az Elastic Beanstalk-ot használjuk a szerver nélküli alkalmazás helyett.

Az architektúra alsó sávja az alapjelentéseket előállító folyamat.

Az általunk használt Amazon Kinesis Data Analytics, állapotalapú számítást futtat a streaming adatokon, hogy összefoglaljon bizonyos mutatókat, például az átviteli sebességet vagy a hibaarányt adott időablakban. Ezek az összefoglalók ezután egy Amazon Aurora adatbázis egy adatmodellel, amely alkalmas műszerfali és jelentési célokra.

A betekintést ezután irányítópultokon mutatják be egy Elastic Beanstalk-on futó webalkalmazás segítségével.

Tanulságok

A szerver nélküli minták és a magasabb rendű szolgáltatások, különösen a Lambda, a Kinesis Data Streams, a Kinesis Data Analytics és a DynamoDB használata nagy rugalmasságot biztosított architektúránkban, és segített nekünk a mikroszolgáltatások felé haladni a nagy monolit kötegelt munkák helyett.

Ez az eltolódás hozzájárult ahhoz is, hogy jelentősen csökkentsük működési és szolgáltatásmenedzsment-költségeinket. Például a bevezetés óta eltelt néhány hónapban a platform ügyfelei nem tapasztaltak semmilyen szolgáltatási zavart.

Ez a megoldás lehetővé tette számunkra, hogy több DevOps-ot és agilisabb munkamódszert alkalmazzunk, abban az értelemben, hogy egyetlen kis csapat fejleszti és üzemelteti a rendszert. Ez viszont lehetővé tette a szervezet számára, hogy agilisabb és innovatívabb legyen ezen a területen.

A fejlesztés és a gyártás során néhány technikai tippet is felfedeztünk, amelyeket érdemes megosztani:

Eredmények és előnyök

Mostantól közel valós időben láthatjuk vezetékes és mobilhálózataink teljesítményét ügyfeleink által tapasztalt módon. Korábban csak kötegelt módban érkezett adatunk volt, és azt is csak a saját hálózati szondáktól és berendezéseinktől.

A változások bekövetkezésekor a hálózat közel valós idejű képével operatív csapataink nagyobb biztonsággal és gyakorisággal hajthatnak végre frissítéseket és karbantartásokat az ügyfelek eszközparkján.

Végül tervezőcsapatunk ezeket az ismereteket arra használja fel, hogy pontos, naprakész teljesítményképet alkossanak a különféle berendezésekről és szolgáltatásokról. Ez magasabb színvonalú szolgáltatást eredményez ügyfeleink számára jobb árakon, mert szolgáltatástervező csapataink képesek optimalizálni a költségeket, jobban egyeztetni a szállítókkal és szolgáltatókkal, valamint tervezni a jövőt.

Előretekintés

Mivel a hálózati elemzési platform már több hónapja gyártásban van, és jelenleg stabil, több betekintésre és új felhasználási esetekre van igény. Például egy mobilhasználati esetet vizsgálunk, hogy jobban kezeljük a kapacitást nagyszabású eseményeken (például sporteseményeken). A cél az, hogy csapataink adatközpontúak legyenek, és közel valós időben tudjanak reagálni a kapacitásigényekre ezeken az eseményeken.

A kereslet másik területe a prediktív karbantartás: a gépi tanulást igyekszünk bevezetni ezekbe a folyamatokba, hogy az AWS Machine Learning szolgáltatásportfóliójának segítségével gyorsabban és pontosabban hozzáférhessenek a betekintéshez.

---

A szerzőkről

Rajagopal Mahendran az Optus IT Innovation Team fejlesztési menedzsere. Mahendran több mint 14 éves tapasztalattal rendelkezik különböző szervezetekben, amelyek vállalati alkalmazásokat szállítanak a közepestől a nagyon nagy méretűig, a bevált technológiákkal a big data, streaming adatalkalmazások, mobil és felhőalapú natív alkalmazások terén. Szenvedélye, hogy innovatív ötleteket hajtson végre a technológia segítségével a jobb élet érdekében. Szabadidejében szeret bozótban járni és úszni.

Mostafa Safipour a Sydney-i székhelyű AWS Solutions Architect-je. Ügyfelekkel dolgozik, hogy üzleti eredményeket érjen el a technológia és az AWS segítségével. Az elmúlt évtizedben számos nagy szervezetnek segített az ANZ régióban adat-, digitális és vállalati munkaterhelésük AWS-re való felépítésében.

Masudur Rahaman Sayem az AWS elemzési megoldások specialistája. Az AWS-ügyfelekkel együttműködve útmutatást és technikai segítséget nyújt az adat- és elemzési projektekhez, segítve őket megoldásaik értékének növelésében az AWS használata során. Szenvedélyesen rajong az elosztott rendszerekért. Szeret olvasni is, főleg a klasszikus képregényeket.

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