Como a Optus melhora a experiência do cliente em banda larga e móvel usando a plataforma de análise de dados de rede na AWS

Republicado por Platão

seguidores: 0

Esta é uma postagem de blog co-escrita por Rajagopal Mahendran, gerente de desenvolvimento da equipe de inovação de TI da Optus.

A Optus faz parte do grupo Singtel, que opera em uma das regiões mais dinâmicas e de maior crescimento do mundo, com presença em 21 países. A Optus fornece não apenas serviços básicos de telecomunicações, mas também uma ampla gama de soluções digitais, incluindo nuvem, segurança cibernética e publicidade digital para empresas, bem como entretenimento e serviços financeiros móveis para milhões de consumidores. A Optus fornece serviços de comunicação móvel para mais de 10.4 milhões de clientes e serviços de banda larga para mais de 1.1 milhão de residências e empresas. Além disso, a Optus Sport conecta cerca de 1 milhão de fãs à Premier League, futebol internacional e conteúdo de fitness.

Nesta postagem, vemos como a Optus usou Amazon Kinesis para ingerir e analisar dados relacionados à rede em um data lake na AWS e melhorar a experiência do cliente e o processo de planejamento de serviço.

O desafio

Um desafio comum para os provedores de telecomunicações é formar uma visão precisa e em tempo real da qualidade do serviço e dos problemas enfrentados por seus clientes. A qualidade da rede doméstica e da conectividade de banda larga tem um impacto significativo na produtividade e satisfação do cliente, especialmente considerando a crescente dependência das redes domésticas para trabalho, ligação com familiares e amigos e entretenimento durante a pandemia da COVID-19.

Além disso, as equipes de operações e planejamento de rede muitas vezes não têm acesso aos dados e insights corretos para planejar novas implementações e gerenciar sua frota atual de dispositivos.

A plataforma de análise de rede fornece dados e insights de solução de problemas e planejamento para as equipes da Optus e seus clientes quase em tempo real, o que ajuda a reduzir o tempo médio para retificar e aprimorar a experiência do cliente. Com os dados e insights corretos, os clientes têm uma experiência melhor porque, em vez de iniciar uma chamada de suporte com muitas perguntas, a equipe de suporte e o cliente têm uma visão atual e precisa dos serviços e da rede doméstica do cliente.

As equipes proprietárias de serviços da Optus também podem usar os insights e tendências derivados desta plataforma para planejar melhor o futuro e fornecer serviços de maior qualidade aos clientes.

Considerações de design

Para enfrentar esse desafio e seus requisitos, embarcamos em um projeto para transformar nosso atual sistema de coleta e processamento de lotes em um sistema de processamento baseado em fluxo, quase em tempo real, e introduzimos APIs para obter insights, para que os sistemas de suporte e os aplicativos dos clientes possam mostrar o instantâneo mais recente do status da rede e do serviço.

Tínhamos os seguintes requisitos funcionais e não funcionais:

A nova plataforma deve ser capaz de suportar a captura de dados de futuros tipos de equipamentos de clientes, bem como novas formas de ingestão (novos protocolos e frequência) e novos formatos de dados.
Deve oferecer suporte a vários consumidores (uma API quase em tempo real para equipes de suporte e aplicativos de clientes e relatórios operacionais e de negócios) para consumir dados e gerar insights. O objetivo é que a plataforma detecte problemas de forma proativa e gere alertas apropriados para a equipe de suporte e também para os clientes.
Depois que os dados chegarem, os insights dos dados deverão estar prontos na forma de uma API em alguns segundos (5 segundos no máximo).
A nova plataforma deve ser suficientemente resiliente para continuar o processamento quando partes da infraestrutura falharem, como nós ou zonas de disponibilidade.
Ele pode suportar um número maior de dispositivos e serviços, bem como uma coleta mais frequente dos dispositivos.
Uma pequena equipe multifuncional de negócios e tecnologia construirá e administrará esta plataforma. Precisamos garantir o mínimo de infraestrutura e sobrecarga operacional no longo prazo.
O pipeline deve estar altamente disponível e permitir novas implantações sem tempo de inatividade.

Visão geral da solução

Com o objetivo das considerações de plataforma e design em mente, decidimos usar serviços de ordem superior e serviços sem servidor da AWS sempre que possível, para evitar sobrecarga operacional desnecessária para nossa equipe e focar nas principais necessidades do negócio. Isso inclui o uso da família de serviços Kinesis para ingestão e processamento de stream; AWS Lambda Para processamento; Amazon DynamoDB, Serviço de banco de dados relacional da Amazon (Amazon RDS) e Serviço de armazenamento simples da Amazon (Amazon S3) para persistência de dados; e AWS Elastic Beanstalk e Gateway de API da Amazon para atendimento de aplicativos e API. O diagrama a seguir mostra a solução geral.

A solução ingere arquivos de log de milhares de equipamentos de rede de clientes (roteadores domésticos) em períodos predefinidos. O equipamento do cliente só é capaz de enviar solicitações HTTP PUT e POST simples para transferir arquivos de log. Para receber esses arquivos, usamos uma aplicação Java rodando em um grupo de Auto Scaling de Amazon Elastic Compute Nuvem (Amazon EC2). Após algumas verificações iniciais, o aplicativo receptor realiza a limpeza e a formatação e, em seguida, transmite os arquivos de log para Fluxos de dados do Amazon Kinesis.

Usamos intencionalmente um aplicativo receptor personalizado na camada de ingestão para fornecer flexibilidade no suporte a diferentes dispositivos e formatos de arquivo.

Para entender o restante da arquitetura, vamos dar uma olhada nos insights esperados. A plataforma produz dois tipos de insights:

percepções individuais – As perguntas respondidas nesta categoria incluem:
- Quantos erros um dispositivo específico do cliente sofreu nos últimos 15 minutos?
- Qual foi o último erro?
- Quantos dispositivos estão conectados atualmente na casa de um determinado cliente?
- Qual é a taxa de transferência/recebimento capturada por um dispositivo específico do cliente?
Informações básicas – Pertencentes a um grupo ou a toda a base de usuários, as perguntas nesta categoria incluem:
- Quantos dispositivos de clientes relataram interrupção de serviço nas últimas 24 horas?
- Quais tipos de dispositivos (modelos) tiveram o maior número de erros nos últimos 6 meses?
- Após a atualização do patch da noite passada em um grupo de dispositivos, eles relataram algum erro? A manutenção foi bem sucedida?

A faixa superior da arquitetura mostra o pipeline que gera os insights individuais.

O mapeamento da fonte de eventos da função Lambda é configurado para consumir registros do fluxo de dados do Kinesis. Esta função lê os registros, formata e os prepara com base nos insights necessários. Por fim, ele armazena os resultados no local do Amazon S3 e também atualiza uma tabela do DynamoDB que mantém um resumo e os metadados dos dados reais armazenados no Amazon S3.

Para otimizar o desempenho, configuramos duas métricas no mapeamento da fonte de eventos do Lambda:

Tamanho do batch – Mostra o número de registros a serem enviados para a função em cada lote, o que ajuda a obter maior rendimento
Lotes simultâneos por fragmento – Processa vários lotes do mesmo fragmento simultaneamente, o que ajuda no processamento mais rápido

Por fim, a API é fornecida via API Gateway e executada em uma aplicação Spring Boot hospedada no Elastic Beanstalk. No futuro, talvez precisemos manter o estado entre as chamadas de API, e é por isso que usamos o Elastic Beanstalk em vez de um aplicativo sem servidor.

A linha inferior da arquitetura é o pipeline que gera relatórios básicos.

Usamos Análise de dados do Amazon Kinesis, executando computação com estado em dados de streaming, para resumir certas métricas, como taxas de transferência ou taxas de erro em determinadas janelas de tempo. Esses resumos são então enviados para um Aurora Amazônica banco de dados com um modelo de dados adequado para fins de painéis e relatórios.

Os insights são então apresentados em painéis usando uma aplicação web executada no Elastic Beanstalk.

As lições aprendidas

O uso de padrões sem servidor e serviços de ordem superior, em particular Lambda, Kinesis Data Streams, Kinesis Data Analytics e DynamoDB, proporcionou muita flexibilidade em nossa arquitetura e nos ajudou a avançar mais para microsserviços em vez de grandes trabalhos em lote monolíticos.

Essa mudança também nos ajudou a diminuir drasticamente nossas despesas gerais de gerenciamento operacional e de serviços. Por exemplo, nos últimos meses desde o lançamento, os clientes desta plataforma não sofreram qualquer interrupção do serviço.

Esta solução também nos permitiu adotar mais DevOps e formas ágeis de trabalhar, no sentido de que uma única pequena equipa desenvolve e executa o sistema. Isto, por sua vez, permitiu à organização ser mais ágil e inovadora neste domínio.

Também descobrimos algumas dicas técnicas ao longo do desenvolvimento e produção que valem a pena compartilhar:

Resultados e benefícios

Agora temos visibilidade quase em tempo real do desempenho de nossas redes fixas e móveis, conforme vivenciado por nossos clientes. No passado, tínhamos apenas dados que chegavam em lote com atraso e também apenas de nossas próprias sondas e equipamentos de rede.

Com a visão quase em tempo real da rede quando ocorrem mudanças, nossas equipes operacionais também podem realizar atualizações e manutenção em toda a frota de dispositivos do cliente com maior confiança e frequência.

Por último, nossas equipes de planejamento usam esses insights para formar uma visão precisa e atualizada do desempenho de vários equipamentos e serviços. Isto leva a serviços de maior qualidade para nossos clientes a melhores preços porque nossas equipes de planejamento de serviços estão capacitadas para otimizar custos, negociar melhor com fornecedores e prestadores de serviços e planejar o futuro.

Olhando para o futuro

Com a plataforma de análise de rede em produção há vários meses e estável agora, há demanda por mais insights e novos casos de uso. Por exemplo, estamos analisando um caso de uso móvel para gerenciar melhor a capacidade em eventos de grande escala (como eventos esportivos). O objetivo é que as nossas equipas sejam orientadas por dados e capazes de reagir quase em tempo real às necessidades de capacidade nestes eventos.

Outra área de demanda diz respeito à manutenção preditiva: estamos buscando introduzir machine learning nesses pipelines para ajudar a gerar insights com mais rapidez e precisão usando o portfólio de serviços do AWS Machine Learning.

Sobre os autores

Rajagopal Mahendran é gerente de desenvolvimento da equipe de inovação de TI da Optus. Mahendran tem mais de 14 anos de experiência em diversas organizações, fornecendo aplicativos empresariais de médio a grande porte, usando tecnologias comprovadas de ponta em big data, aplicativos de streaming de dados, aplicativos móveis e nativos da nuvem. Sua paixão é impulsionar ideias inovadoras usando tecnologia para uma vida melhor. Nas horas vagas, ele adora caminhar pela mata e nadar.

Mostafa Safipour é arquiteto de soluções na AWS baseado em Sydney. Ele trabalha com clientes para obter resultados de negócios usando tecnologia e AWS. Na última década, ele ajudou muitas grandes organizações na região ANZ a criar suas cargas de trabalho de dados, digitais e empresariais na AWS.

Masudur Rahaman Sayem é arquiteto de soluções especialista em análises na AWS. Ele trabalha com clientes da AWS para fornecer orientação e assistência técnica em projetos de dados e análises, ajudando-os a melhorar o valor de suas soluções ao usar a AWS. Ele é apaixonado por sistemas distribuídos. Ele também gosta de ler, principalmente histórias em quadrinhos clássicas.