Як Optus покращує досвід широкосмугового та мобільного зв’язку за допомогою платформи Network Data Analytics на AWS

Це гостьовий допис у блозі, співавтором якого є Раджагопал Махендран, менеджер з розвитку команди інновацій Optus IT.

---

Optus є частиною групи Singtel, яка працює в одному з найбільш швидкозростаючих і найдинамічніших регіонів світу, присутня в 21 країні. Optus надає не тільки основні телекомунікаційні послуги, але й широкий спектр цифрових рішень, включаючи хмарні технології, кібербезпеку та цифрову рекламу для підприємств, а також розважальні та мобільні фінансові послуги для мільйонів споживачів. Optus надає послуги мобільного зв'язку більш ніж 10.4 мільйонам клієнтів і широкосмугові послуги для більш ніж 1.1 мільйона будинків і підприємств. Крім того, Optus Sport об’єднує близько 1 мільйона вболівальників до Прем’єр-ліги, міжнародного футболу та фітнес-контенту.

У цій публікації ми розглянемо, як використовувався Optus Амазонський кінезіс отримати й проаналізувати пов’язані з мережею дані в озері даних на AWS і покращити взаємодію з клієнтами та процес планування послуг.

Змагання

Поширеним завданням для провайдерів телекомунікацій є формування точного уявлення в реальному часі про якість обслуговування та проблеми, з якими стикаються їхні клієнти. Якість домашньої мережі та широкосмугового з’єднання має значний вплив на продуктивність і задоволеність клієнтів, особливо враховуючи збільшення залежності від домашніх мереж для роботи, спілкування з родиною та друзями та розваг під час пандемії COVID-19.

Крім того, команди мережевих операцій і планування часто не мають доступу до потрібних даних і статистичних даних, щоб планувати нові розгортання та керувати поточним парком пристроїв.

Платформа мережевої аналітики надає дані для усунення несправностей і планування, а також аналітичну інформацію для команд Optus і їхніх клієнтів майже в реальному часі, що допомагає скоротити середній час для усунення проблем і покращити взаємодію з клієнтами. Завдяки правильним даним і статистиці клієнти отримують кращий досвід, оскільки замість того, щоб починати дзвінок у службу підтримки з великою кількістю запитань, персонал служби підтримки та клієнт мають поточне й точне уявлення про послуги та домашню мережу клієнта.

Команди власників послуг у Optus також можуть використовувати інформацію та тенденції, отримані з цієї платформи, щоб краще планувати майбутнє та надавати клієнтам послуги вищої якості.

Дизайнерські міркування

Щоб вирішити цю проблему та її вимоги, ми започаткували проект із перетворення нашої поточної системи пакетного збору й обробки на систему обробки на основі потоку майже в реальному часі та запровадили API для аналізу, щоб системи підтримки та додатки клієнтів могли показувати останній знімок стану мережі та служби.

У нас були такі функціональні та нефункціональні вимоги:

• Нова платформа повинна бути здатна підтримувати збір даних з майбутніх типів клієнтського обладнання, а також нові способи прийому (нові протоколи та частота) і нові формати даних.
• Він повинен підтримувати кілька споживачів (API, що працює майже в реальному часі для персоналу служби підтримки та додатків клієнтів, а також операційну та бізнес-звітність), щоб споживати дані та генерувати ідеї. Мета полягає в тому, щоб платформа проактивно виявляла проблеми та створювала відповідні сповіщення для персоналу служби підтримки, а також клієнтів.
• Після надходження даних статистичні дані з даних мають бути готові у формі API за кілька секунд (максимум 5 секунд).
• Нова платформа має бути достатньо стійкою, щоб продовжувати обробку в разі збою частин інфраструктури, наприклад вузлів або зон доступності.
• Він може підтримувати збільшену кількість пристроїв і служб, а також більш частий збір із пристроїв.
• Невелика міжфункціональна команда, яка займається бізнесом і технологіями, створить і запустить цю платформу. Нам потрібно забезпечити мінімальну інфраструктуру та операційні витрати в довгостроковій перспективі.
• Конвеєр має бути високодоступним і дозволяти нові розгортання без простоїв.

Огляд рішення

Зважаючи на платформу та дизайн, ми вирішили використовувати служби вищого рівня та безсерверні служби від AWS, де це можливо, щоб уникнути непотрібних операційних витрат для нашої команди та зосередитися на основних потребах бізнесу. Це включає використання сімейства служб Kinesis для прийому та обробки потоку; AWS Lambda для обробки; Amazon DynamoDB, Служба реляційних баз даних Amazon (Amazon RDS), і Служба простого зберігання Amazon (Amazon S3) для збереження даних; і AWS Elastic Beanstalk та API -шлюз Amazon для обслуговування програм і API. На наступній діаграмі показано загальне рішення.

Рішення завантажує файли журналу з тисяч мережевого обладнання клієнтів (домашніх маршрутизаторів) у заздалегідь визначені періоди. Обладнання клієнта здатне надсилати лише прості запити HTTP PUT і POST для передачі файлів журналу. Щоб отримати ці файли, ми використовуємо програму Java, яка працює в групі автоматичного масштабування Обчислювальна хмара Amazon Elastic (Amazon EC2). Після деяких початкових перевірок програма-одержувач виконує очищення та форматування, а потім передає файли журналу Потоки даних Amazon Kinesis.

Ми навмисно використовуємо спеціальну програму приймача на рівні прийому, щоб забезпечити гнучкість підтримки різних пристроїв і форматів файлів.

Щоб зрозуміти решту архітектури, давайте подивимося на очікувані ідеї. Платформа створює два типи аналітичних даних:

• Індивідуальне розуміння – Відповіді на запитання цієї категорії включають:
  • Скільки помилок виникло на певному пристрої користувача за останні 15 хвилин?
  • Яка остання помилка?
  • Скільки пристроїв наразі підключено до будинку конкретного клієнта?
  • Яка швидкість передачі/отримання, зафіксована конкретним пристроєм клієнта?
• База даних – Питання цієї категорії стосуються групи або всієї бази користувачів:
  • Скільки пристроїв клієнтів повідомили про збій обслуговування за останні 24 години?
  • Які типи пристроїв (моделі) зазнали найбільшої кількості помилок за останні 6 місяців?
  • Чи повідомили вони про якісь помилки після вчорашнього оновлення виправлення на групі пристроїв? Чи було технічне обслуговування успішним?

Верхня смуга в архітектурі показує конвеєр, який генерує окремі ідеї.

Відображення джерела подій функції Lambda налаштовано на споживання записів із потоку даних Kinesis. Ця функція зчитує записи, форматує та готує їх на основі необхідної інформації. Нарешті, він зберігає результати в розташуванні Amazon S3, а також оновлює таблицю DynamoDB, яка зберігає зведення та метадані фактичних даних, що зберігаються в Amazon S3.

Щоб оптимізувати продуктивність, ми налаштували дві метрики у відображенні джерела подій Lambda:

• Розмір партії – Показує кількість записів, які потрібно надіслати функції в кожному пакеті, що допомагає досягти вищої пропускної здатності
• Одночасні пакети на шард – Одночасно обробляє кілька пакетів з одного фрагмента, що сприяє швидшій обробці

Нарешті, API надається через API Gateway і працює в додатку Spring Boot, розміщеному на Elastic Beanstalk. У майбутньому нам може знадобитися зберігати стан між викликами API, тому ми використовуємо Elastic Beanstalk замість безсерверної програми.

Нижня смуга в архітектурі - це конвеєр, який генерує базові звіти.

Ми використовуємо Аналіз даних Amazon Kinesis, запускаючи обчислення з відстеженням стану над потоковими даними, щоб узагальнити певні показники, як-от швидкість передачі даних або частоту помилок у заданих часових вікнах. Потім ці підсумки надсилаються до an Амазонська Аврора база даних із моделлю даних, придатною для панелі керування та звітності.

Далі дані представлені на інформаційних панелях за допомогою веб-додатку, що працює на Elastic Beanstalk.

Уроки, витягнуті

Використання безсерверних шаблонів і сервісів вищого рівня, зокрема Lambda, Kinesis Data Streams, Kinesis Data Analytics і DynamoDB, забезпечило велику гнучкість нашої архітектури та допомогло нам більше переходити до мікросервісів, а не до великих монолітних пакетних завдань.

Ця зміна також допомогла нам значно скоротити накладні витрати на управління операціями та обслуговуванням. Наприклад, за останні кілька місяців з моменту запуску у клієнтів цієї платформи не було жодних збоїв у роботі сервісу.

Це рішення також дозволило нам застосувати більше DevOps і гнучкі способи роботи, тобто одна невелика команда розробляє та запускає систему. Це, у свою чергу, дозволило організації бути більш гнучкими та інноваційними у цій сфері.

Під час розробки та виробництва ми також знайшли деякі технічні поради, якими варто поділитися:

Результати та переваги

Тепер ми маємо змогу майже в реальному часі бачити продуктивність наших фіксованих і мобільних мереж за оцінками наших клієнтів. Раніше ми мали лише дані, які надходили в пакетному режимі із затримкою, а також лише з наших власних мережевих зондів і обладнання.

Завдяки перегляду мережі майже в реальному часі, коли відбуваються зміни, наші оперативні команди також можуть виконувати оновлення та технічне обслуговування всього парку пристроїв клієнтів з більшою впевненістю та частотою.

Нарешті, наші групи планування використовують цю інформацію, щоб сформувати точне, актуальне уявлення про продуктивність різноманітного обладнання та послуг. Це забезпечує високу якість послуг для наших клієнтів за кращими цінами, оскільки наші команди з планування послуг мають змогу оптимізувати витрати, краще вести переговори з постачальниками та постачальниками послуг і планувати майбутнє.

Забігаючи вперед

Оскільки платформа мережевої аналітики працює вже кілька місяців і працює стабільно, є попит на більше інформації та нові варіанти використання. Наприклад, ми розглядаємо варіант використання мобільних пристроїв, щоб краще керувати потужністю під час масштабних подій (таких як спортивні заходи). Мета полягає в тому, щоб наші команди керувалися даними та могли майже в реальному часі реагувати на потреби в потужності в таких подіях.

Інша сфера попиту пов’язана з профілактичним обслуговуванням: ми прагнемо запровадити машинне навчання в ці конвеєри, щоб допомогти отримати інформацію швидше й точніше за допомогою портфоліо послуг AWS Machine Learning.

---

Про авторів

Раджагопал Махендран є менеджером з розвитку в команді ІТ-інновацій Optus. Махендран має понад 14 років досвіду роботи в різних організаціях, які постачають корпоративні додатки від середнього до дуже великого масштабу з використанням перевірених і передових технологій у великих даних, додатках потокових даних, мобільних і хмарних додатках. Його пристрасть полягає в створенні інноваційних ідей за допомогою технологій для кращого життя. У вільний час він любить прогулянки та купання.

Мостафа Сафіпур є архітектором рішень в AWS із Сіднея. Він працює з клієнтами для досягнення бізнес-результатів за допомогою технологій і AWS. За останнє десятиліття він допоміг багатьом великим організаціям у регіоні ANZ створювати робочі навантаження з даних, цифрові та корпоративні дані на AWS.

Масудур Рахаман Саєм є спеціалізованим архітектором рішень для аналітики в AWS. Він працює з клієнтами AWS, щоб надати рекомендації та технічну допомогу щодо проектів із обробки даних і аналітики, допомагаючи їм підвищити цінність їхніх рішень при використанні AWS. Він захоплений розподіленими системами. Він також любить читати, особливо класичні комікси.

Джерело: https://aws.amazon.com/blogs/big-data/how-optus-improves-broadband-and-mobile-customer-experience-using-the-network-data-analytics-platform-on-aws/