Concevoir une architecture de solution avec Azure
Pour créer une architecture d’applications, vous devez comprendre l’ampleur des exigences fonctionnelles et non fonctionnelles, puis mettre en corrélation ces exigences et les outils, les technologies et les services susceptibles d’y répondre.
Voici les principales exigences du scénario de localisation de bus :
- Site web pour surveiller en temps réel la localisation des bus
- Notifications quand un bus n’est pas loin
- Déploiement et mise à l’échelle automatisés
Examinons plus en détail ce scénario et voyons comment architecturer une solution à l’aide de différents services Azure.
Récupérer les données des bus en temps réel
De nombreuses villes fournissent des données sur les transports en commun au format GTFS (General Transit Feed Specification), qui prend également en charge un flux en temps réel, appelé GTFS-RT (référence GTFS en temps réel v2). Ce flux se compose d’un document JSON qui ressemble à l’exemple suivant (provenant du flux King County Metro) :
{
"id": "1618418866_4318",
"vehicle": {
"trip": {
"trip_id": "49195161",
"direction_id": 0,
"route_id": "100001",
"start_date": "20210414",
"schedule_relationship": "SCHEDULED"
},
"vehicle": {
"id": "4318",
"label": "4318"
},
"position": {
"latitude": 47.64524,
"longitude": -122.370171
},
"current_stop_sequence": 228,
"stop_id": "2010",
"current_status": "IN_TRANSIT_TO",
"timestamp": 1618418841
}
},
Sachant que ce flux est disponible, vous devez ensuite déterminer comment recevoir une notification quand un bus est suffisamment proche pour que vous puissiez commencer à vous diriger vers l’arrêt de bus et prendre votre bus. Pour ce faire, nous pouvons créer une limite géographique quelques arrêts de bus avant notre station prévue. De cette façon, vous pouvez être averti lorsque le bus pénètre dans la limite géographique ou quand il la quitte. Si vous pouvez recevoir une notification quand cela se produit, vous n’avez plus besoin de vérifier sur une carte où se trouve le bus. Quand vous recevez la notification, vous savez qu’il est temps de partir.
Concevoir l’architecture d’une solution avec les services Azure
En fonction du scénario et de la solution idéale, voici une architecture possible :
Cette architecture utilise plusieurs services différents pour réduire au maximum la quantité de code que vous devez écrire et pour tirer parti au maximum de la scalabilité et des avantages d’infrastructure fournis par Azure.
Well-Known Text (WKT) est un langage de balisage de texte brut pour représenter des emplacements de géométrie vectorielle sur une carte. WKT est un standard de l’Open Geospatial Consortium (OGC) qui sert à représenter les données spatiales dans un format texte. La plupart des systèmes conformes à OGC prennent en charge Well-Known Text (WKT).
Ici, nous allons examiner les composants de la solution et la raison pour laquelle ils ont été sélectionnés. Ensuite, dans ce module, vous vous pencherez sur le service de base de données.
Stocker et traiter les données avec Azure SQL Database
Azure SQL Database est un outil parfaitement adapté pour ce scénario. Voyons pourquoi.
Azure SQL Database prend en charge le format JSON en mode natif, ce qui permet de réduire la quantité de code nécessaire pour manipuler les données envoyées et reçues avec la base de données. Cet outil rend également la solution plus agile et facilite son amélioration en raison de la nature flexible de JSON. Cela vous permet également de transmettre efficacement des tableaux de données à Azure SQL, d’optimiser les allers-retours et de réduire la latence.
Azure SQL fournit également une prise en charge géospatiale complète, ce qui représente un atout majeur dans la mesure où la manipulation de données géospatiales n’est pas la tâche la plus aisée. En disposant d’un moteur géospatial aux fonctionnalités complètes dans la base de données, vous pouvez éviter la complexité d’une intégration avec les bibliothèques externes. Vous n’avez pas non plus besoin de déplacer les données pour déterminer, par exemple, si un bus se trouve dans une limite géographique définie. Comme Azure SQL adhère aux normes de l’Open Geospatial Consortium, il est facile d’intégrer des données stockées dans Azure SQL à des bibliothèques de visualisation telles qu’OpenLayers.
Les fonctionnalités susmentionnées sont basées sur les fondements solides du modèle relationnel, établis et améliorés au fil des années pour répondre aux exigences des applications modernes. Azure SQL Database est évolutif jusqu’à 100 To avec le niveau Hyperscale, ce qui signifie que vous pouvez l’utiliser pour les applications gourmandes en stockage (par exemple des grandes bases de données). Azure SQL Database est également économique quand vous utilisez le niveau Serverless, qui prend en charge la mise à l’échelle automatique, et Suspension et reprise. Azure SQL prend également en charge les index columnstore pour des requêtes analytiques rapides, des modèles Graph pour simplifier la gestion des relations d’objets complexes et un optimiseur de requête de pointe qui s’améliore en permanence et peut traiter les charges de travail les plus exigeantes, comme celles générées aujourd’hui par les jeux en ligne massivement multijoueurs.
Avec Azure SQL, il est également facile d’accéder aux données statiques, telles que les informations d’itinéraire fournies par la norme GTFS, qui peuvent être stockées dans un compte Stockage Blob Azure. Nous pouvons utiliser la fonction OPENROWSET dans Azure SQL pour importer des données à partir d’un fichier texte sans avoir besoin d’un autre service. Cela nous permet de réduire la complexité de la solution.
Azure SQL Database est donc la solution idéale pour notre application de localisation de bus. En effet, vous avez affaire à des données JSON et géospatiales, mais vous souhaitez également tirer parti des fonctionnalités de procédure et d’accès aux données intégrées au moteur. Azure SQL Database Serverless est une option intéressante pour répondre aux besoins de mise à l’échelle automatique, ce qui permet à l’application de gérer les pics d’activité à certains moments de la journée quand davantage de personnes tentent de prendre le bus. Azure SQL Database prend également en charge les technologies d’intégration continue et de livraison continue/déploiement continu (CI/CD), par exemple Azure DevOps et GitHub Actions, qui simplifient l’automatisation du déploiement.
Générer un service d’API avec Azure Functions
Une API est nécessaire pour accéder au flux GTFS et le consommer, pour notifier un utilisateur si un bus a franchi une limite géographique et pour fournir des données à une application web. Vous avez sélectionné le service Azure Functions pour sa simplicité et son architecture serverless. Azure Functions est un excellent service dans la mesure où sa nature serverless s’adapte automatiquement à vos besoins, laissant presque tous les aspects infrastructurels à Azure Functions. Azure Functions fournit la prise en charge de différents langages, et vous permet de choisir votre langage préféré ou celui qui convient le mieux à la tâche qui vous occupe, ce qui suit une approche purement basée sur les microservices.
Envoyer des notifications avec Azure Logic Apps
Pour recevoir une notification indiquant qu’un bus se trouve au sein d’une limite géographique et que vous devez commencer à vous diriger vers l’arrêt de bus, une option dans Azure consiste à utiliser Azure Logic Apps. Azure Logic Apps a un grand nombre de connecteurs qui vous permettent d’intégrer d’autres services. Par exemple, vous pouvez utiliser Azure Logic Apps pour envoyer un message SMS ou envoyer un e-mail à partir de votre compte Outlook ou Gmail. L’avantage d’Azure Logic Apps est qu’il s’agit d’une plateforme ne nécessitant que peu ou pas de programmation, si bien que la configuration du service de notification pour prendre le bus est simple et ne nécessite que quelques actions de souris.
Héberger l’application web avec Azure Static Web Apps
Pour visualiser les données géospatiales (qui représentent les limites géographiques et les positions des bus sur une carte), vous pouvez créer une page HTML statique à l’aide des bibliothèques bien connues jQuery et OpenLayers. La page statique devra extraire des données d’une API REST côté serveur qui sera fournie par une autre fonction Azure. Comme les parties client et back-end sont toutes les deux nécessaires pour que la page de visualisation fonctionne, vous pouvez tirer parti d’Azure Static Web Apps. En combinant les fonctionnalités d’Azure Web Apps et d’Azure Functions et en intégrant GitHub Actions, Azure Static Web Apps facilite le développement et le déploiement de la solution.
Automatiser le déploiement avec GitHub Actions
Comme vous l’avez vu, la solution complète est constituée de plusieurs parties mobiles : le service back-end pour extraire les données du flux en temps réel, la base de données pour stocker, traiter et fournir les données, et enfin la solution de visualisation front-end composée d’un fichier HTML statique et d’un point de terminaison d’API REST. En utilisant un pipeline CI/CD par l’intermédiaire de GitHub Actions, vous allez automatiser le déploiement de tous les éléments, via GitHub et Visual Studio Code, chaque fois que vous validez des modifications. Les modifications apportées à la base de données, le cas échéant, sont déployées avec les modifications liées à Azure Functions et Azure Static Web Apps de manière entièrement automatisée et orchestrée.