Optus 如何使用 AWS 上的网络数据分析平台改善宽带和移动客户体验

由柏拉图重新发布

关注： 0

这是由 Optus IT 创新团队的开发经理 Rajagopal Mahendran 共同撰写的客座博客文章。

Optus 隶属于新加坡电信集团，该集团在全球发展最快、最具活力的地区之一开展业务，业务遍及 21 个国家/地区。 Optus 不仅提供核心电信服务，还提供广泛的数字解决方案，包括面向企业的云、网络安全和数字广告，以及面向数百万消费者的娱乐和移动金融服务。 Optus 为超过 10.4 万客户提供移动通信服务，为超过 1.1 万家庭和企业提供宽带服务。此外，Optus Sport 将近 1 万球迷连接到英超联赛、国际足球和健身内容。

在这篇文章中，我们看看 Optus 如何使用亚马逊Kinesis 在 AWS 上的数据湖中提取和分析网络相关数据，并改善客户体验和服务规划流程。

挑战

电信提供商面临的一个共同挑战是准确、实时地了解客户所遇到的服务质量和问题。家庭网络和宽带连接质量对客户的工作效率和满意度有重大影响，特别是考虑到在 COVID-19 大流行期间人们越来越依赖家庭网络进行工作、与家人和朋友联系以及娱乐。

此外，网络运营和规划团队通常无法访问正确的数据和见解来规划新的部署和管理他们当前的设备群。

网络分析平台近乎实时地为 Optus 团队及其客户提供故障排除和规划数据和见解，这有助于减少纠正和增强客户体验的平均时间。有了正确的数据和洞察力，客户将获得更好的体验，因为支持人员和客户无需带着大量问题发起支持电话，而是可以实时准确地了解服务和客户的家庭网络。

Optus 内的服务所有者团队还可以利用从该平台得出的见解和趋势来更好地规划未来并为客户提供更高质量的服务。

设计注意事项

为了应对这一挑战及其要求，我们启动了一个项目，将我们当前的批量收集和处理系统转变为基于流的、近实时的处理系统，并引入用于洞察力的 API，以便支持系统和客户应用程序可以显示网络和服务状态的最新快照。

我们有以下功能性和非功能性需求：

新平台必须能够支持从未来类型的客户设备以及新的摄取方式（新的协议和频率）和新的数据格式中获取数据。
它应该支持多个消费者（用于支持人员和客户应用程序以及运营和业务报告的近实时 API）来使用数据并生成洞察力。目的是让平台主动检测问题并为支持人员和客户生成适当的警报。
数据到达后，应在几秒钟内（最多 5 秒）以 API 的形式准备好来自数据的见解。
新平台应该具有足够的弹性，以便在基础设施的某些部分（例如节点或可用区）出现故障时继续处理。
它可以支持更多数量的设备和服务以及更频繁地从设备收集。
一个跨业务和技术的小型跨职能团队将构建和运行该平台。从长远来看，我们需要确保最少的基础设施和运营开销。
管道应该是高度可用的，并且允许在没有停机的情况下进行新的部署。

解决方案概述

考虑到平台的目标和设计考虑，我们决定尽可能使用 AWS 的高阶服务和无服务器服务，以避免团队不必要的运营开销并专注于核心业务需求。这包括使用 Kinesis 系列服务进行流摄取和处理； AWS Lambda 用于加工； Amazon DynamoDB, 亚马逊关系数据库服务（Amazon RDS），以及亚马逊简单存储服务 (Amazon S3) 用于数据持久化；和 AWS 弹性豆茎和 Amazon API网关用于应用程序和 API 服务。下图显示了整体解决方案。

该解决方案在预定义的时间段内从数千个客户网络设备（家庭路由器）中提取日志文件。客户设备只能发送简单的 HTTP PUT 和 POST 请求来传输日志文件。为了接收这些文件，我们使用在 Auto Scaling 组中运行的 Java 应用程序亚马逊弹性计算云 (Amazon EC2) 实例。经过一些初步检查后，接收器应用程序执行清理和格式化，然后将日志文件流式传输到 Amazon Kinesis数据流.

我们有意在摄取层中使用自定义接收器应用程序，以提供支持不同设备和文件格式的灵活性。

要了解架构的其余部分，让我们来看看预期的见解。该平台产生两种类型的见解：

个人见解 – 此类别中回答的问题包括：
- 特定客户设备在过去 15 分钟内遇到了多少错误？
- 最后一个错误是什么？
- 特定客户家中当前连接了多少台设备？
- 特定客户设备捕获的传输/接收速率是多少？
基础见解 – 与一个群体或整个用户群有关，此类别中的问题包括：
- 过去 24 小时内有多少客户设备报告服务中断？
- 哪些设备类型（型号）在过去 6 个月中遇到的错误数量最多？
- 昨晚在一组设备上更新补丁后，他们是否报告了任何错误？维护成功了吗？

架构中的顶部通道显示了生成个人见解的管道。

Lambda 函数的事件源映射配置为使用来自 Kinesis 数据流的记录。此功能读取记录、格式化并根据所需的洞察力准备它们。最后，它将结果存储在 Amazon S3 位置，并更新一个 DynamoDB 表，该表维护存储在 Amazon S3 中的实际数据的摘要和元数据。

为了优化性能，我们在 Lambda 事件源映射中配置了两个指标：

批量大小 – 显示每批中发送到函数的记录数，这有助于实现更高的吞吐量
每个分片的并发批次 – 同时处理来自同一个分片的多个批次，这有助于加快处理速度

最后，API 通过 API Gateway 提供，并在托管在 Elastic Beanstalk 上的 Spring Boot 应用程序上运行。将来，我们可能需要在 API 调用之间保持状态，这就是我们使用 Elastic Beanstalk 而不是无服务器应用程序的原因。

架构中的底部通道是生成基本报告的管道。

我们使用 Amazon Kinesis数据分析，对流数据运行有状态计算，以总结给定时间窗口内的某些指标，如传输率或错误率。然后将这些摘要推送到亚马逊极光具有适用于仪表板和报告目的的数据模型的数据库。

然后使用在 Elastic Beanstalk 上运行的 Web 应用程序在仪表板中呈现这些见解。

吸取的经验教训

使用无服务器模式和高阶服务，特别是 Lambda、Kinesis Data Streams、Kinesis Data Analytics 和 DynamoDB，为我们的架构提供了很大的灵活性，并帮助我们更多地转向微服务而不是大型单体批处理作业。

这种转变还帮助我们大幅降低了运营和服务管理开销。例如，在推出后的最后几个月里，该平台的客户没有遇到任何服务中断。

该解决方案还使我们能够采用更多的 DevOps 和敏捷的工作方式，即由单个小团队开发和运行系统。这反过来又使组织在该领域变得更加敏捷和创新。

我们在开发和生产过程中也发现了一些值得分享的技术诀窍：

结果和好处

我们现在可以近乎实时地了解客户所体验到的固定和移动网络性能。过去，我们只有延迟批处理模式的数据，也只有来自我们自己的网络探测器和设备的数据。

通过在发生变化时近乎实时地查看网络，我们的运营团队还可以以更高的信心和频率对所有客户设备进行升级和维护。

最后，我们的规划团队使用这些见解来形成各种设备和服务的准确、最新的性能视图。这会以更优惠的价格为我们的客户提供更高质量的服务，因为我们的服务规划团队能够优化成本、更好地与供应商和服务提供商谈判并规划未来。

展望未来

随着网络分析平台投入生产数月且现在稳定，需要更多洞察力和新用例。例如，我们正在研究一个移动用例，以更好地管理大型活动（如体育赛事）的容量。我们的目标是让我们的团队以数据为导向，并能够近乎实时地对这些事件中的容量需求做出反应。

另一个需求领域是预测性维护：我们希望将机器学习引入这些管道，以帮助通过使用 AWS 机器学习服务组合更快、更准确地获得洞察力。

关于作者

拉贾戈帕尔·马亨德兰 是 Optus IT 创新团队的开发经理。 Mahendran 在各种组织中拥有超过 14 年的经验，使用大数据、流数据应用程序、移动和云原生应用程序中经过验证的尖端技术交付从中规模到超大规模的企业应用程序。他热衷于利用技术推动创新理念，改善生活。在业余时间，他喜欢丛林漫步和游泳。