Modifier

Processus du détecteur d’anomalies

Azure Databricks
Azure Service Bus
Comptes Stockage Azure

Cet article présente une architecture pour une implémentation en quasi-temps réel d’un processus de détection d’anomalie.

Architecture

Diagramme de l’architecture du processus de détecteur d’anomalies.

Téléchargez un fichier Visio de cette architecture.

Dataflow

  1. Les données de série chronologique peuvent provenir de plusieurs sources, par exemple Azure Database pour MySQL, Stockage Blob, Event Hubs, Azure Cosmos DB, SQL Database et Azure Database pour PostgreSQL.
  2. Les données sont ingérées dans le calcul à partir de différentes sources de stockage à surveiller par le détecteur d’anomalies.
  3. Databricks permet d’agréger, d’échantillonner et de calculer les données brutes pour générer l’heure avec les résultats détectés. Databricks est capable de traiter le flux et les données statiques. Stream Analytics et Azure Synapse peuvent être des alternatives en fonction des exigences.
  4. L’API du détecteur d’anomalies détecte les anomalies et retourne les résultats à calculer.
  5. Les métadonnées liées à l’anomalie sont mises en file d’attente.
  6. Application Insights sélectionne le message dans la file d’attente de messages en fonction des métadonnées liées à l’anomalie, puis envoie une alerte relative à l’anomalie.
  7. Les résultats sont stockés dans Azure Data Lake Service Gen2.
  8. Les applications web et Power BI peuvent visualiser les résultats de la détection d’anomalie.

Components

Technologies clés utilisées pour implémenter cette architecture :

  • Service Bus : MaaS (Messaging as a Service) fiable dans le cloud et intégration hybride simple.
  • Azure Databricks : Service d’analyse rapide, simple et collaboratif basé sur Apache Spark.
  • Power BI : Outils décisionnels et de visualisation interactive des données.
  • Comptes de stockage : Stockage dans le cloud durable, hautement disponible et considérablement évolutif.
  • Cognitive Services : Services cloud dotés d’API REST et de SDK de bibliothèque de client qui vous aident à intégrer l’intelligence cognitive à vos applications.
  • Logic Apps : plateforme serverless pour la création de workflows d’entreprise qui intègrent des applications, des données et des services. Dans cette architecture, les applications logiques sont déclenchées par des requêtes HTTP.
  • Azure Data Lake Storage Gen2 : Azure Data Lake Storage Gen2 fournit une sémantique du système de fichiers, une sécurité au niveau des fichiers et la mise à l’échelle.
  • Application Insights : Application Insights est une fonctionnalité d’Azure Monitor qui fournit une gestion extensible des performances des applications et une surveillance pour les applications web en direct.

Autres solutions

  • Event Hubs avec Kafka : solution qui évite d’avoir à exécuter son propre cluster Kafka. Cette fonctionnalité Event Hubs fournit un point de terminaison compatible avec les API Kafka.
  • Azure Synapse Analytics : service d’analytique qui réunit l’entreposage de données d’entreprise et des fonctionnalités analytiques pour le Big Data.
  • Azure Machine Learning : Crée, forme, déploie et gère des modèles d’apprentissage automatique et de détection d’anomalies dans un environnement cloud.

Détails du scénario

L’API Détecteur d’anomalies d’Azure Cognitive Services vous permet de faire du monitoring et de détecter les anomalies dans vos données de série chronologique sans avoir à connaître le machine learning. Les algorithmes de l’API s’adaptent en identifiant et en appliquant automatiquement les modèles les plus appropriés à vos données de série chronologique, quel que soit le secteur d’activité, le scénario ou le volume de données. Ils déterminent les limites de la détection d’anomalie, les valeurs attendues et les points de données anormaux.

Cas d’usage potentiels

Certaines zones que la détection d’anomalies aide à surveiller :

  • Fraude bancaire (secteur de la finance)
  • Défauts de structure (secteur de l’industrie)
  • Problèmes médicaux (secteur de la santé)

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Extensibilité

La plupart des composants utilisés dans cet exemple de scénario sont des services gérés dont la mise à l’échelle est automatique.

Pour obtenir des conseils d’ordre général sur la conception de solutions évolutives, consultez la liste de contrôle de l’efficacité des performances dans le Centre des architectures Azure.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Des identités managées pour ressources Azure permettent à d’autres ressources internes d’accéder à votre compte et de les affecter à vos instances Azure Functions. Autorisez ces identités à accéder uniquement aux ressources nécessaires pour garantir que rien de plus n’est exposé à vos fonctions (et éventuellement à vos clients).

Pour obtenir des conseils d’ordre général sur la conception de solutions sécurisées, consultez la documentation sur la sécurité Azure.

Résilience

Comme tous les composants de ce scénario sont gérés, à un niveau régional, ils sont résilients automatiquement.

Pour obtenir des conseils d’ordre général sur la conception de solutions résilientes, consultez l’article Conception d’applications résilientes pour Azure.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Pour explorer le coût d’exécution de ce scénario, consultez la calculatrice préremplie avec tous les services. Pour pouvoir observer l’évolution de la tarification pour votre cas d’usage particulier, modifiez les variables appropriées en fonction du trafic et des volumes de données que vous escomptez.

Nous proposons trois exemples de profils de coût selon la quantité de trafic (nous supposons que toutes les images font 100 Ko) :

  • Exemple de calculatrice : cet exemple de tarification est une calculatrice avec tous les services de cette architecture, à l’exception de Power BI et d’une solution d’alerte personnalisée.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes