Monitore dispositivos em tempo real com base nas ações IoT usando a IA Generativa do OCI e o Oracle E-Business Suite

No mundo de hoje, para cada aplicativo, temos muitos dispositivos e pontos de dados conectados a um servidor central para processamento de dados. Esses pontos de dados emitem métricas continuamente e, se monitorados e calculados, podemos obter alguns insights muito úteis dos dados. Esses insights podem ser usados para fazer previsões como quando algum dispositivo pode travar e, eventualmente, podem ser integrados a um sistema como o Oracle E-Business Suite para fazer um pedido para substituir o dispositivo defeituoso em qualquer lugar.

A arquitetura que propomos - para a saúde, levará os insumos dos eventos recebidos emitidos pelos dispositivos. Esses eventos terão os dados sobre a integridade do dispositivo, por exemplo, os dados emitidos por um monitor de oxigênio em execução em um hospital terão os dados sobre sua idade, sistema operacional, patches de segurança aplicados, informações históricas e atuais sobre seu uso de memória e armazenamento e a carga que está servindo.

Limparemos e, em seguida, passaremos esses dados para nosso modelo de ML em execução no serviço Oracle Cloud Infrastructure Data Science e, em seguida, calcularemos a probabilidade, o que nos informará as chances de esse dispositivo parar de funcionar e quando. Agregaremos todos esses dados e de acordo com o envio de requisitos ao Oracle Autonomous Data Warehouse para geração de relatórios adicionais. Também podemos integrar os dados ainda mais ao Oracle E-Business Suite para que ele possa fazer um pedido automaticamente assim que corresponder aos critérios especificados para falha do dispositivo.

Arquitetura

Essa arquitetura de referência demonstra como utilizar recursos de nuvem na Oracle Cloud Infrastructure (OCI) para criar uma solução de monitoramento de dispositivos hospedada na OCI.

Nesta arquitetura, mostramos como essa solução de monitoramento de dispositivos será hospedada na OCI e como os usuários administradores acessarão a solução para fins comerciais e administrativos ou operacionais.

O diagrama a seguir ilustra esse fluxo de dados da arquitetura de referência.



oci-genai-iot-ebs-arch-oracle.zip

Assim que os dados forem gerados no dispositivo, o aplicativo cliente em execução no dispositivo acessará o OCI Streaming em um ponto final exposto por meio do Gateway de API. Esses pontos finais serão protegidos por um serviço de segurança da Web de ponta - WAF - que significa Web Application Firewall. Este serviço garantirá que a segurança frontend seja por padrão aplicável ao aplicativo. O mesmo ponto final de streaming é conectado de um Service Connector Hub, que continuará monitorando o fluxo e, assim que houver novos dados produzidos pelo dispositivo, ele consumirá os dados e acionará o OCI Functions para processamento adicional dos dados.

O OCI Functions usará os dados consumidos e iniciará o processamento de dados. Haverá cenários em que vários registros serão consumidos em chamada de consumo único, dependendo do tráfego de entrada, e a função será capaz de cuidar de todos os registros separadamente. Para cada registro, a função executará as seguintes tarefas:

  1. Limpe os dados do registro e reúna os parâmetros necessários a partir deles.
  2. Crie uma chamada de Solicitação de API para o modelo de ML hospedado em um ponto final. A entrada desta solicitação serão os parâmetros necessários para que o modelo faça uma previsão de falha do dispositivo. A resposta desta solicitação será a previsão de falha do dispositivo (variando de 0,00 a 10,00, onde 0,00 significa menos chances de falha do dispositivo e 10,00 significa mais chances de falha do dispositivo).
  3. Depois de obtermos a previsão, a função adicionará isso ao registro de entrada e o enviará para o Autonomous Data Warehouse para relatórios futuros e reaprendizado contínuo do modelo de ML.
  4. Com base no valor de previsão, o OCI Functions acionará a próxima tarefa. Se a previsão for para não falha, a função sairá da execução desse registro, pois não há mais nada a fazer. Se a previsão for para falha, a função executará as seguintes subtarefas:
    1. Acesse a tabela de referência do Autonomous Data Warehouse para obter todos os detalhes do novo pedido, como detalhes do remetente e do aprovador do pedido, dados relacionados ao dispositivo e a todas as outras partes interessadas.
    2. Use a IA Generativa do OCI para gerar o resumo de detalhes do pedido.
    3. Envie os detalhes do pedido para o Oracle E-Business Suite ou qualquer outro software CRM de ERP.
    4. Use a IA Generativa do OCI para elaborar um e-mail para resumo das partes interessadas.
    5. Envie a notificação às partes interessadas correspondentes para informar sobre a colocação do pedido.
  5. Depois que esse fluxo for concluído, a função marcará o registro como processado e será movida para o próximo registro.

A solução consiste em um modelo de ML de autoaprendizado, que continuará se atualizando com os novos dados que chegam ao Autonomous Data Warehouse. Todas as três camadas do aplicativo são hospedadas em sub-redes diferentes para garantir que tenhamos aberto as portas de segurança corretas, conforme exigido pelo aplicativo. Os dados armazenados nos bancos de dados são extraídos de outra sub-rede para garantir a segurança adequada.

O diagrama de arquitetura também ilustra outro fluxo de acesso do usuário para usuários administradores. Esses são os usuários responsáveis por operar o aplicativo de monitoramento de dispositivos no OCI. Eles acessarão os recursos do aplicativo usando SSH na VPN Site a Site ou FastConnect. Isso criará um túnel seguro que conectará o dispositivo CPE no data center do cliente com o DRG no OCI. Usando esse caminho, os administradores acessarão os recursos do aplicativo no OCI nos computadores do data center. Esse acesso é necessário para garantir que todos os trabalhos de operações, como aplicação de patches, atualização de aplicativos, atualizações de segurança do sistema operacional e outras tarefas, sejam feitos com segurança e no prazo.

Nesta arquitetura, também podemos adicionar os conceitos de alta disponibilidade e recuperação de desastres implementados na OCI. Alta disponibilidade significa que o aplicativo é implantado em vários domínios de disponibilidade na mesma região. Isso garantirá que o aplicativo esteja sempre disponível, mesmo no caso de um dos domínios de disponibilidade ficar inativo devido a algum problema como incêndio ou eletricidade. A recuperação de desastres significa que o aplicativo também é implantado em várias regiões do OCI. Isso garantirá que o aplicativo esteja sempre disponível, mesmo no caso de uma das regiões cair devido a algum problema como tsunami, ciclone ou terremoto. Além disso, você também deve colocar recursos em vários domínios de falha para garantir que a arquitetura também esteja protegida contra qualquer falha no nível do rack dentro do data center da Oracle. Esses são tópicos extremamente importantes a serem considerados, pois esses aplicativos devem ser executados continuamente por longos períodos sem tempo de inatividade.

Na mesma arquitetura, também podemos ver que criamos a implantação usando o serviço OCI DevOps, que garantirá que todos os componentes sejam implantados de maneira ágil. Todos os componentes são implantados usando o Terraform e mantidos por meio do Ansible. Isso mostra como você pode aproveitar a automação na OCI e seguir a abordagem Infrastructure-as-a-Code (IaaC) para tornar o aplicativo mainframe mais ágil e fácil de manter.

A arquitetura tem os seguintes componentes:

  • Tenancy

    Uma tenancy é uma partição segura e isolada que a Oracle configura no Oracle Cloud quando você acessa o Oracle Cloud Infrastructure. Você pode criar, organizar e administrar seus recursos no Oracle Cloud em sua tenancy. Uma tenancy é sinônimo de uma empresa ou organização. Geralmente, uma empresa terá uma única tenancy e refletirá sua estrutura organizacional dentro dessa tenancy. Uma única tenancy geralmente está associada a uma única assinatura, e uma única assinatura geralmente só tem uma tenancy.

  • Região

    Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regioes sao independentes de outras regioes, e grandes distancias podem separá-las (entre paises ou ate continentes).

  • Compartimento

    Compartimentos são partições lógicas entre regiões em uma tenancy do Oracle Cloud Infrastructure. Use compartimentos para organizar seus recursos no Oracle Cloud, controlar o acesso aos recursos e definir cotas de uso. Para controlar o acesso aos recursos em um determinado compartimento, você define políticas que especificam quem pode acessar os recursos e quais ações eles podem executar.

  • Domínios de disponibilidade

    Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.

  • Domínios de falha

    Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falhas físicas do servidor, manutenção do sistema e falhas de energia dentro de um domínio de falha.

  • Rede virtual na nuvem (VCN) e sub-redes

    Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • FastConnect

    O Oracle Cloud Infrastructure FastConnect fornece uma maneira fácil de criar uma conexão privada dedicada com o Oracle Cloud Infrastructure. O FastConnect oferece opções de largura de banda maior e uma experiência de rede mais confiável quando comparado com as conexões baseadas na internet.

  • IPSec VPN

    O VPN Connect fornece conectividade IPSec VPN site a site entre sua rede on-premises e VCNs no Oracle Cloud Infrastructure. O conjunto de protocolos IPSec criptografa o tráfego IP antes que os pacotes sejam transferidos da origem para o destino e decompõe o tráfego quando ele chega.

  • Lista de segurança

    Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.

  • Gateway de serviço

    O gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle percorre a malha da rede Oracle e não passa pela internet.

  • Sistemas de banco de dados autônomos

    O Oracle Autonomous Database é um serviço totalmente automatizado que facilita para todas as organizações o desenvolvimento e a implementação de cargas de trabalho de aplicativos, independentemente da complexidade, escala ou criticidade. O mecanismo convergente do serviço suporta diversos tipos de dados, simplificando o desenvolvimento e a implantação de aplicativos, desde modelagem e codificação até ETL, otimização de banco de dados e análise de dados. Com ajuste, dimensionamento e aplicação de patches automatizados orientados por machine learning, o Autonomous Database oferece o mais alto desempenho, disponibilidade e segurança para cargas de trabalho OLTP, análise, lote e Internet of Things (IoT). Criado no Oracle Database e no Oracle Exadata, o Autonomous Database está disponível na Oracle Cloud Infrastructure (OCI) para implantações sem servidor ou dedicadas, bem como on-premises com a Oracle Exadata Cloud@Customer e a OCI Dedicated Region.

  • Streaming

    O Oracle Cloud Infrastructure Streaming oferece uma solução de armazenamento totalmente gerenciada, escalável e durável para a ingestão de streams contínuos de alto volume de dados que você pode consumir e processar em tempo real. Você pode usar o serviço Streaming para ingestão de dados de alto volume, como logs de aplicativo, telemetria operacional, dados de fluxo de cliques na Web ou para outros casos de uso nos quais os dados são produzidos e processados de forma contínua e sequencial em um modelo de mensagem de publicação/inscrição.

  • Conectores de serviço

    O Oracle Cloud Infrastructure Service Connector Hub é uma plataforma de barramento de mensagens da nuvem que orquestra a movimentação de dados entre serviços no OCI. Você pode usar conectores de serviço para mover dados de um serviço de origem para um serviço de destino. Os conectores de serviço também permitem que você especifique opcionalmente uma tarefa (como uma função) a ser executada nos dados antes de serem entregues ao serviço de destino.

    Você pode usar o Oracle Cloud Infrastructure Service Connector Hub para criar rapidamente uma estrutura de agregação de logs para sistemas de gerenciamento de eventos e informações de segurança (SIEM).

  • Data Science

    O Oracle Cloud Infrastructure Data Science é uma plataforma totalmente gerenciada e sem servidor que as equipes de ciência de dados podem usar para criar, treinar e gerenciar modelos de machine learning (ML) no Oracle Cloud Infrastructure (OCI). Ele pode se integrar facilmente a outros serviços da OCI, como Oracle Autonomous Data Warehouse, Oracle Cloud Infrastructure Object Storage e muito mais. Você pode criar e avaliar modelos de machine learning de alta qualidade que aumentam a flexibilidade dos negócios, colocando os dados confiáveis da empresa para funcionar rapidamente e pode oferecer suporte a objetivos de negócios orientados a dados com implementação mais fácil de modelos de ML.

  • Serviço Functions

    O Oracle Cloud Infrastructure Functions é uma plataforma de Funções como um Serviço (FaaS) totalmente gerenciada, multitenant, altamente escalável e sob demanda. Ele é ativado pelo mecanismo de código aberto do Fn Project. As funções permitem que você implante seu código e o chame diretamente ou acione em resposta a eventos. O Oracle Functions usa contêineres Docker hospedados no Oracle Cloud Infrastructure Registry.

  • Logging
    O registro em log é um serviço altamente escalável e totalmente gerenciado que oferece acesso aos seguintes tipos de logs de seus recursos na nuvem:
    • Logs de auditoria: Logs relacionados a eventos emitidos pelo serviço Audit.
    • Logs de serviço: Logs emitidos por serviços individuais, como logs de fluxo do serviço API Gateway, do serviço Events, do serviço Functions, do serviço Load Balancing, do serviço Object Storage e da VCN.
    • Logs personalizados: Logs que contêm informações de diagnóstico de aplicativos personalizados, outros provedores de nuvem ou um ambiente on-premises.

Recomendações

Use as recomendações a seguir como ponto de partida para implementar essa arquitetura de referência usando o OCI Functions e o OCI Events. Seus requisitos podem ser diferentes da arquitetura descrita aqui.
  • VCN

    Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar às sub-redes na VCN. Use blocos CIDR que estejam dentro do espaço de endereço IP privado padrão.

    Selecione blocos CIDR que não se sobreponham a qualquer outra rede (no Oracle Cloud Infrastructure, seu data center local ou outro provedor de nuvem) para a qual você pretende configurar conexões privadas.

    Depois de criar uma VCN, você poderá alterar, adicionar e remover seus blocos CIDR.

    Ao projetar as sub-redes, considere seus requisitos de fluxo de tráfego e segurança. Anexe todos os recursos dentro de uma camada ou função específica à mesma sub-rede, que pode servir como um limite de segurança.

  • Projeto do Aplicativo

    Essa arquitetura de referência usa o OCI Functions para todo o processamento. Há poucas limitações no uso do OCI Functions, como tempo máximo de execução de 300 segundos, e se você pretende usar essa arquitetura para uma grande quantidade de dados de fluxo de entrada, poderá considerar a execução do aplicativo nas instâncias do OCI Compute. Você pode executar vários executores e cada executor para consumir e processar os eventos de entrada separadamente e em paralelo.

  • Disaster Recovery

    Uma instância de recuperação de desastre stand-by em outra região do OCI é recomendada para aplicativos empresariais. A Estratégia de DR deve ser consistente em todas as 3 camadas para atender aos requisitos de SLA e durabilidade dos dados. A recuperação de desastre do Oracle Exadata Database Service on Dedicated Infrastructure é sincronizada com a produção usando o Oracle Data Guard. O Oracle Exadata Database Service on Dedicated Infrastructure standby é uma cópia transacionalmente consistente do banco de dados principal. O Oracle Data Guard mantém automaticamente a sincronização entre os bancos de dados por meio da transmissão e da aplicação de dados de redo do banco de dados principal para o standby. No caso de um desastre na região principal, o Oracle Data Guard faz failover automaticamente para o banco de dados stand-by na região secundária. Os balanceadores de carga front-end são implantados em um modo stand-by para balanceadores de carga de rede ou com alta disponibilidade usando o Balanceador de Carga como Serviço.

Considerações

Ao implementar essa arquitetura de referência, é importante considerar os seguintes aspectos.

  • Desempenho

    OCI Functions, Autonomous Data Warehouse e outros serviços importantes são altamente escaláveis. Considere ajustar o número de recursos de computação e armazenamento, com base no tamanho e no requisito do seu aplicativo de mainframe.

  • Segurança

    Use políticas para restringir quem pode acessar os recursos do OCI. Para o OCI Object Storage, a criptografia é ativada por padrão e não pode ser desativada. Todo o acesso a funções implantadas no OCI Functions é controlado por meio do Oracle Cloud Infrastructure Identity and Access Management (OCI IAM), que permite que os privilégios de gerenciamento de funções e de chamada de funções sejam designados a usuários e grupos de usuários específicos. É recomendável armazenar segredos e dados confidenciais no OCI Vault. Considere o uso do OCI Vault para armazenar chaves de API e token de autenticação usados para autorização com serviços do OCI.

  • Disponibilidade

    A Oracle garante alta disponibilidade do OCI Functions, Autonomous Data Warehouse e outros serviços, que são nativos da nuvem e totalmente gerenciados. Para cargas de trabalho implantadas em um único domínio de disponibilidade, você pode garantir a resiliência distribuindo os recursos entre os domínios de falha, conforme mostrado nesta arquitetura. Se você planeja implantar sua carga de trabalho em uma região que tenha mais de um domínio de disponibilidade, poderá distribuir os recursos entre vários domínios de disponibilidade.

  • Escalabilidade

    Você pode dimensionar os servidores de aplicativos verticalmente alternando e alterando a forma das instâncias de computação. Uma forma com uma contagem de núcleos mais alta fornece mais memória e largura de banda de rede. Se você precisar de mais armazenamento, aumente o tamanho dos volumes em blocos anexados ao servidor de aplicativos. Você pode dimensionar os bancos de dados verticalmente ativando mais núcleos para o sistema de BD do Autonomous Data Warehouse. Você pode adicionar OCPUs em múltiplos de dois para um quarter rack. Os bancos de dados permanecem disponíveis durante uma operação de dimensionamento. Se sua carga de trabalho ultrapassar as CPUs e o armazenamento disponíveis, você poderá migrar para um rack maior.

Confirmação

  • Autor: Lovelesh Saxena