Kuinka Optus parantaa laajakaista- ja mobiiliasiakaskokemusta käyttämällä AWS:n Network Data Analytics -alustaa

Julkaissut Platon

seuraajia: 0

Tämä on vierasblogiviesti, jonka on kirjoittanut Optus IT Innovation Teamin kehityspäällikkö Rajagopal Mahendran.

Optus on osa The Singtel-konsernia, joka toimii yhdellä maailman nopeimmin kasvavista ja dynaamisimmista alueista ja toimii 21 maassa. Optus tarjoaa televiestinnän ydinpalvelujen lisäksi laajan valikoiman digitaalisia ratkaisuja, mukaan lukien pilvi-, kyberturvallisuus ja digitaalinen mainonta yrityksille sekä viihde- ja mobiilirahoituspalveluita miljoonille kuluttajille. Optus tarjoaa matkaviestinpalveluja yli 10.4 miljoonalle asiakkaalle ja laajakaistapalveluita yli 1.1 miljoonalle kodille ja yritykselle. Lisäksi Optus Sport yhdistää lähes miljoona fania Valioliigaan, kansainväliseen jalkapalloon ja kuntoilusisältöön.

Tässä viestissä tarkastelemme, kuinka Optus käytti Amazon kinesis nielemään ja analysoimaan verkkoon liittyvää dataa AWS:n datajärvessä ja parantamaan asiakaskokemusta ja palvelun suunnitteluprosessia.

Haaste

Tietoliikennepalvelujen tarjoajien yhteinen haaste on muodostaa tarkka, reaaliaikainen näkemys palvelun laadusta ja asiakkaiden kohtaamista ongelmista. Kotiverkon ja laajakaistayhteyksien laadulla on merkittävä vaikutus asiakkaiden tuottavuuteen ja tyytyväisyyteen, etenkin kun otetaan huomioon lisääntynyt riippuvuus kotiverkoista työssä, perheen ja ystävien kanssa pitämisessä sekä viihteessä COVID-19-pandemian aikana.

Lisäksi verkkotoiminnoilla ja suunnittelutiimeillä ei useinkaan ole pääsyä oikeisiin tietoihin ja oivalluksiin suunnitella uusia käyttöönottoja ja hallita nykyistä laitekantaa.

Verkkoanalytiikkaalusta tarjoaa vianmääritys- ja suunnittelutietoja ja näkemyksiä Optus-tiimeille ja heidän asiakkailleen lähes reaaliajassa, mikä auttaa lyhentämään korjauksiin kuluvaa aikaa ja parantamaan asiakaskokemusta. Oikeilla tiedoilla ja oivalluksilla asiakkailla on parempi kokemus, sillä tukihenkilöstöllä ja asiakkaalla on sen sijaan, että aloitettaisiin paljon kysymyksiä sisältävä tukipuhelu, ajantasainen ja tarkka näkemys palveluista ja asiakkaan kotiverkosta.

Optuksen palvelunomistajatiimit voivat myös hyödyntää tästä alustasta saatuja oivalluksia ja trendejä tulevaisuuden suunnittelussa ja laadukkaamman palvelun tarjoamisessa asiakkaille.

Suunnitteluun vaikuttavat tekijät

Vastataksemme tähän haasteeseen ja sen vaatimuksiin aloitimme hankkeen muuttaa nykyinen eräkeräys- ja -käsittelyjärjestelmämme stream-pohjaiseksi, lähes reaaliaikaiseksi käsittelyjärjestelmäksi ja ottaa käyttöön sovellusliittymiä, joiden avulla tukijärjestelmät ja asiakassovellukset voivat näyttää viimeisin tilannekuva verkon ja palvelun tilasta.

Meillä oli seuraavat toiminnalliset ja ei-toiminnalliset vaatimukset:

Uuden alustan on kyettävä tukemaan tiedonkeruuta tulevaisuuden asiakaslaitteista sekä uusia tiedonottotapoja (uudet protokollat ja taajuudet) ja uusia datamuotoja.
Sen pitäisi tukea useita kuluttajia (lähes reaaliaikainen API tukihenkilöstölle ja asiakassovelluksille sekä toiminnan ja liiketoiminnan raportointiin) tietojen kuluttamiseen ja oivallusten luomiseen. Tavoitteena on, että alusta tunnistaa ongelmat ennakoivasti ja tuottaa asianmukaiset hälytykset tukihenkilöstölle ja asiakkaille.
Tietojen saapumisen jälkeen tiedoista saatavien havaintojen pitäisi olla valmiita API-muodossa muutamassa sekunnissa (enintään 5 sekuntia).
Uuden alustan tulee olla riittävän joustava jatkaakseen käsittelyä, kun infrastruktuurin osat, kuten solmut tai saatavuusvyöhykkeet, epäonnistuvat.
Se voi tukea lisääntynyttä laitteiden ja palveluiden määrää sekä useampaa keräämistä laitteista.
Pieni monialainen yritys- ja teknologiatiimi rakentaa ja pyörittää tätä alustaa. Meidän on varmistettava pitkällä aikavälillä mahdollisimman vähäinen infrastruktuuri ja käyttökustannukset.
Putkilinjan tulisi olla erittäin saatavilla ja mahdollistaa uudet käyttöönotot ilman seisokkeja.

Ratkaisun yleiskatsaus

Alustan ja suunnittelun tavoitteet huomioon ottaen päätimme käyttää AWS:n korkeamman tilauksen palveluita ja palvelimettomia palveluita mahdollisuuksien mukaan välttääksemme tiimimme tarpeettomia operatiivisia kustannuksia ja keskittyäksemme ydinliiketoiminnan tarpeisiin. Tämä sisältää Kinesis-palveluperheen käytön suoratoistoon ja -käsittelyyn; AWS Lambda käsittelyyn; Amazon DynamoDB, Amazon Relational Database -palvelu (Amazon RDS) ja Amazonin yksinkertainen tallennuspalvelu (Amazon S3) tietojen pysyvyyttä varten; ja AWS Elastinen pavunvarsi ja Amazon API -yhdyskäytävä sovellusten ja API-palveluiden käyttöön. Seuraava kaavio näyttää kokonaisratkaisun.

Ratkaisu syöttää lokitiedostot tuhansista asiakkaiden verkkolaitteista (kotireitittimistä) ennalta määrätyin ajanjaksoina. Asiakaslaitteisto pystyy lähettämään vain yksinkertaisia HTTP PUT- ja POST-pyyntöjä lokitiedostojen siirtämiseksi. Näiden tiedostojen vastaanottamiseen käytämme Java-sovellusta, joka on käynnissä Auto Scaling -ryhmässä Amazonin elastinen laskentapilvi (Amazon EC2) -tapauksissa. Muutaman alustavan tarkistuksen jälkeen vastaanotinsovellus suorittaa puhdistuksen ja alustuksen, minkä jälkeen se suoratoistaa lokitiedostot Amazon Kinesis -tietovirrat.

Käytämme tietoisesti mukautettua vastaanotinsovellusta tiedonkeruukerroksessa tarjotaksemme joustavuutta eri laitteiden ja tiedostomuotojen tukemisessa.

Ymmärtääksemme muun arkkitehtuurin, katsotaanpa odotettuja oivalluksia. Alusta tuottaa kahdenlaisia oivalluksia:

Yksilölliset oivallukset – Tässä kategoriassa vastattuja kysymyksiä ovat:
- Kuinka monta virhettä tietyssä asiakkaan laitteessa on ollut viimeisen 15 minuutin aikana?
- Mikä oli viimeisin virhe?
- Kuinka monta laitetta on tällä hetkellä kytkettynä tietyssä asiakkaan kotona?
- Mikä on tietyn asiakkaan laitteen sieppaama siirto-/vastaanottonopeus?
Perustiedot – Ryhmään tai koko käyttäjäkuntaan liittyviä kysymyksiä tässä kategoriassa ovat:
- Kuinka moni asiakaslaite ilmoitti palveluhäiriöstä viimeisen 24 tunnin aikana?
- Missä laitetyypeissä (malleissa) on esiintynyt eniten virheitä viimeisen 6 kuukauden aikana?
- Ovatko ne ilmoittaneet virheistä viime yön päivityksen jälkeen laitteille? Onko huolto onnistunut?

Arkkitehtuurin ylin kaista näyttää putkilinjan, joka tuottaa yksittäisiä oivalluksia.

Lambda-toiminnon tapahtumalähteen kartoitus on määritetty kuluttamaan tietueita Kinesis-tietovirrasta. Tämä toiminto lukee tietueita, muotoja ja valmistelee ne tarvittavien oivallusten perusteella. Lopuksi se tallentaa tulokset Amazon S3 -sijaintiin ja päivittää myös DynamoDB-taulukon, joka ylläpitää yhteenvetoa ja metadataa Amazon S3:een tallennetuista todellisista tiedoista.

Suorituksen optimoimiseksi määritimme kaksi mittaria Lambda-tapahtumalähteen kartoitukseen:

Erän koko – Näyttää toimintoon lähetettävän tietueen määrän kussakin erässä, mikä auttaa saavuttamaan suuremman suorituskyvyn
Samanaikaiset erät per sirpale – Käsittelee useita eriä samasta sirpaleesta samanaikaisesti, mikä nopeuttaa käsittelyä

Lopuksi API tarjotaan API Gatewayn kautta ja toimii Spring Boot -sovelluksessa, jota isännöi Elastic Beanstalk. Jatkossa saatamme joutua säilyttämään tilan API-kutsujen välillä, minkä vuoksi käytämme Elastic Beanstalkia palvelimettoman sovelluksen sijaan.

Arkkitehtuurin alin kaista on liukuhihna, joka luo perusraportteja.

Käytämme Amazon Kinesis Data Analytics, joka suorittaa tilapitoista laskentaa suoratoistodatalle yhteenvedon tekemiseksi tietyistä mittareista, kuten siirtonopeuksista tai virhemääristä tietyissä aikaikkunoissa. Nämä yhteenvedot työnnetään sitten kohtaan an Amazon Aurora tietokanta tietomallilla, joka soveltuu kojelautailu- ja raportointitarkoituksiin.

Havainnot esitetään sitten kojelaudoissa Elastic Beanstalkin verkkosovelluksella.

Saadut kokemukset

Palvelimettomien mallien ja korkeamman tason palveluiden, erityisesti Lambdan, Kinesis Data Streamsin, Kinesis Data Analyticsin ja DynamoDB:n, käyttö tarjosi paljon joustavuutta arkkitehtuuriimme ja auttoi meitä siirtymään enemmän kohti mikropalveluita isojen monoliittisten erätöiden sijaan.

Tämä muutos auttoi meitä myös dramaattisesti vähentämään toiminnan ja palveluiden hallinnan yleiskustannuksia. Esimerkiksi useiden viime kuukausien aikana julkaisun jälkeen tämän alustan asiakkaat eivät kokeneet palveluhäiriöitä.

Tämän ratkaisun ansiosta pystyimme myös ottamaan käyttöön enemmän DevOppeja ja ketterämpiä työtapoja siinä mielessä, että yksi pieni tiimi kehittää ja pyörittää järjestelmää. Tämä puolestaan antoi organisaatiolle mahdollisuuden olla ketterämpi ja innovatiivisempi tällä alalla.

Löysimme kehittämisen ja tuotannon aikana myös joitain teknisiä vinkkejä, jotka kannattaa jakaa:

Tulokset ja edut

Meillä on nyt lähes reaaliaikainen näkyvyys kiinteiden ja matkaviestinverkkojen toimivuudesta asiakkaidemme kokemana. Aiemmin meillä oli vain dataa, joka saapui erätilassa viiveellä ja myös vain omista verkkotunnistimistamme ja laitteistamme.

Lähes reaaliaikaisen näkymän verkosta muutosten tapahtuessa operatiiviset tiimimme voivat myös suorittaa päivityksiä ja huoltoja asiakkaiden laitteisiin entistä varmemmin ja tiheämmin.

Lopuksi suunnittelutiimimme käyttävät näitä näkemyksiä muodostaakseen tarkan ja ajantasaisen näkymän eri laitteista ja palveluista. Tämä johtaa laadukkaampaan palveluun asiakkaillemme edullisemmin hinnoin, koska palvelusuunnittelutiimimme pystyvät optimoimaan kustannukset, neuvottelemaan paremmin myyjien ja palveluntarjoajien kanssa sekä suunnittelemaan tulevaisuutta.

Katse eteenpäin

Verkkoanalytiikka-alusta on ollut tuotannossa useita kuukausia ja nyt vakaa, joten oivalluksille ja uusille käyttötapauksille on kysyntää. Tutkimme esimerkiksi mobiilikäyttötapausta hallitaksemme paremmin kapasiteettia suurissa tapahtumissa (kuten urheilutapahtumissa). Tavoitteena on, että tiimimme ovat datalähtöisiä ja pystyvät reagoimaan lähes reaaliajassa kapasiteettitarpeisiin näissä tapahtumissa.

Toinen kysyntäalue liittyy ennakoivaan ylläpitoon: pyrimme tuomaan koneoppimisen näihin putkiin, jotta voimme saada oivalluksia nopeammin ja tarkemmin käyttämällä AWS-koneoppimispalveluvalikoimaa.

Tietoja kirjoittajista

Rajagopal Mahendran on kehityspäällikkö Optus IT Innovation Teamissa. Mahendranilla on yli 14 vuoden kokemus erilaisista organisaatioista, jotka toimittavat yrityssovelluksia keskikokoisista erittäin suuriin mittakaavaihin käyttämällä hyväksi todettua huipputeknologiaa big datassa, suoratoistodatasovelluksissa, mobiili- ja pilvipohjaisissa sovelluksissa. Hänen intohimonsa on edistää innovatiivisia ideoita teknologian avulla paremman elämän edistämiseksi. Vapaa-ajallaan hän rakastaa pensaskävelyä ja uimista.

Mostafa Safipour on ratkaisuarkkitehti AWS:ssä Sydneystä. Hän työskentelee asiakkaiden kanssa toteuttaakseen liiketoiminnan tuloksia teknologian ja AWS:n avulla. Viimeisen vuosikymmenen aikana hän on auttanut monia suuria organisaatioita ANZ-alueella rakentamaan data-, digitaali- ja yritystyökuormituksensa AWS:llä.

Masudur Rahaman Sayem on AWS:n Analyticsin ratkaisuarkkitehti. Hän työskentelee AWS-asiakkaiden kanssa tarjotakseen ohjausta ja teknistä tukea data- ja analytiikkaprojekteissa, mikä auttaa heitä parantamaan ratkaisujensa arvoa AWS:n käytössä. Hän on intohimoinen hajautetuista järjestelmistä. Hän pitää myös lukemisesta, erityisesti klassisista sarjakuvista.