Les entreprises se tournent de plus en plus vers les services cloud en raison de leur facilité d'utilisation et de leur coût flexible. Vous pouvez facilement déléguer la plateforme, l'infrastructure ou même l'exécution de l'environnement à votre fournisseur de cloud. Tous ces différents niveaux de services ont gagné en popularité et sont connus sous le nom de PaaS, IaaS et FaaS.

Les entreprises peuvent désormais se concentrer sur leur logique métier sans avoir besoin de construire et de gérer une forte capacité informatique. C'est particulièrement vrai pour les startups qui peuvent rapidement se lancer sur le marché grâce à leur fournisseur de cloud.

Ici, chez Agilytic, nous aimons tester et déployer des preuves de concept avec de nouvelles technologies émergentes, réduisant ainsi le coût de gestion technique sur de nombreux aspects d'un projet. Cet article vous présentera une expérience que nous avons réalisée dans notre laboratoire Azure avec l'application Azure Function. Nous avons essayé de mettre en œuvre une application à charge de travail intensive en utilisant de nouveaux services cloud gérés pour réduire au maximum la gestion technique. Le but était d'observer les limites techniques en termes de fonctionnalités et d'évolutivité, ainsi que le coût par rapport à d'autres déploiements cloud classiques.

Dans notre laboratoire, je vais vous présenter une application à charge de travail intensive qui analyse des documents PDF. L'analyse comprend quatre étapes différentes de traitement avancé, allant de la reconnaissance optique de caractères à la classification de texte. Sur un seul vCPU, nous avons estimé que le temps de traitement prend en moyenne 1 minute pour les quatre étapes.

L'architecture de l'application Azure Function

Dans un schéma IaaS, la première idée serait de créer des machines virtuelles et des processus pour effectuer le travail réel. Nous pouvons accroître la solution en créant davantage de machines virtuelles et de processus. Les principaux inconvénients de cette approche seraient la gestion et l'administration des systèmes. Nous devrons administrer le système d'exploitation, les mises à jour, etc. Nous devrons également gérer l'architecture de l'application et synchroniser le flux de travail, surtout lorsqu'il est distribué.

L'idée était d'expérimenter le développement d'une telle application sur une plateforme en tant que service (PaaS) au lieu d'une infrastructure en tant que service (IaaS). En utilisant l'application Azure Function, nous irons même au-delà de ce que l'on appelle une fonction en tant que service (FaaS). Dans une telle FaaS, la charge de gestion est réduite au maximum car nous n'avons ni à gérer la plateforme ni l'architecture de l'application. Nous sommes libres de nous concentrer sur la partie du code qui apporte une valeur commerciale directe tout en minimisant la gestion et le coût potentiel. Choisir une telle solution présente aussi des inconvénients comme la dépendance envers le fournisseur. L'expérience ici se concentre sur le bénéfice et la valeur ajoutée d'un point de vue technique plutôt que sur des préférences commerciales.

Nous avons décidé d'opter pour l'Azure Function App, où chaque instance de la function app mettra en œuvre une étape de traitement. Azure Service Bus Queue assure la communication entre les étapes. De cette façon, nous n'avons pas d'implication de surcharge de gestion. Un stockage de blob stocke tous les documents.

Le flux de travail passera d'une étape à l'autre en séquence en utilisant des messages échangés via l'Azure Service Bus Queue, soutenant la distribution de la charge entre les Function Apps. Comme les Function Apps sont sans état, vous pouvez facilement les traiter, les distribuer et les mettre à l'échelle. Par exemple, lorsque l'une étape termine un travail, un message est envoyé à l'étape suivante via le Service Bus pour poursuivre le traitement.

L'architecture Azure est composée de :

• Function App - Exécuter notre code.

• Service Bus Queue - Transférer le flux de travail séquentiellement d'une étape à une autre.

• DataLake storage - Pour stocker les résultats.

• Blob storage - Pour stocker les documents.

Les différentes étapes sont :

• Dispatcher - Un composant très léger générant les différents travaux à exécuter.

• Recherche & Téléchargement - Rechercher et télécharger les documents stockés dans le blob Azure pour le traitement.

• Extraction de texte - Combinaison d'interprétation Postscript et reconnaissance optique de caractères pour extraire les données textuelles du PDF.

• NLP - Traitement de langage naturel pour la classification de texte à partir du texte extrait.

Le code derrière l'application Azure Function

Chaque étape est responsable d'une tâche spécifique. Grâce à l'Azure Service Bus Queue, nous pouvons garantir une livraison au moins une fois de manière automatique sans effort supplémentaire. De cette manière, nous nous assurons de ne pas perdre le suivi des exécutions en cas de défaillance. L'Azure Function App vous permet de mettre en œuvre votre logique métier sans interagir directement avec le Service Bus Queue. L'Azure Function App enveloppera effectivement votre logique métier dans son propre modèle consommateur-producteur. Cette manière de travailler nous permet de nous concentrer sur la logique métier sans être confrontés à des problèmes d'intégration. Azure maintient et prend en charge tout sauf notre logique métier. Ceci est en fait le principal avantage de l'utilisation de FaaS par rapport à PaaS.

La configuration de l'Azure Function App est simple. Vous devez fournir le type d'entrée et de sortie, le nom des files d'attente et le nom de la variable d'environnement contenant la chaîne de connexion pour se connecter au Service Bus en toute sécurité. D'autres paramètres peuvent être nécessaires selon votre type d'entrée et de sortie.

{
 "scriptFile": "__init__.py",
 "bindings": [
   {
     "name": "msgIn",
     "type": "serviceBusTrigger",
     "direction": "in",
     "queueName": "inputqueue",
     "connection": "InputBusQueueConnectionString"
   },
   {
     "name": "msgOut",
     "type": "serviceBus",
     "direction": "out",
     "queueName": "outputqueue",
     "connection": "OutputBusQueueConnectionString",
   }
 ]
}import json
import business

import azure.functions as func

def main(msgIn: func.ServiceBusMessage, msgOut: func.Out[str]):
   input_data = json.loads(msgIn.get_body())
   output_data = business.process(input_data)
   msgOut.set(json.dumps(output_data))

C'est aussi simple que cela. Notre code de logique métier sera portable car il reste indépendant du reste du code. L'implémentation de cette fonction principale nous permet de choisir une méthode de sérialisation préférée. Plus tard, nous serons libres de modifier notre architecture et d'abandonner l'Azure Function App pour un autre service sans réimplémenter ou refactoriser notre logique métier.

Cette architecture est similaire à ce que peut offrir Apache Storm.

Les avantages

Cette architecture offre de nombreux avantages :

• Des résultats en temps réel. Chaque document est traité le plus rapidement possible sans coût technique supplémentaire.

• L'architecture globale est tolérante aux pannes et cohérente. Lorsqu'une single Function App plante, le reste du traitement continue indépendamment. L'étape de traitement défaillante sera également réessayée grâce à l'Azure Service Bus Queue et au mode Peek-lock. Le réessai sera limité à l'étape échouée, pas à toutes les étapes.

• L'architecture est entièrement évolutive à un niveau de précision. Nous serions capables d'élargir une étape précise si c'est le goulot d'étranglement. Nous verrons plus tard que cette évolutivité a certaines limites.

• Il n'y a absolument aucune surcharge de gestion. Tant l'Azure Function App que l'Azure Service Bus Queue sont des services entièrement gérés.

Les limitations

L'architecture offre un grand avantage en termes d'évolutivité, comme nous l'avons vu. Cependant, l'évolutivité de l'Azure Function App a certaines limitations. Différents types de services permettent de mettre à l'échelle les fonctions d'application jusqu'à 4 cœurs de manière verticale. Potentiellement, cela accélérerait notre processus par un facteur de quatre si nous décidons de gérer une Azure Function App multi-threading. Malheureusement, nous ne pouvons pas dépasser quatre cœurs par instance de fonction dans le plan de service premium.

L'architecture initiale présentée ici peut facilement évoluer parce qu'elle est sans état et utilise le Service Bus Queue. Cependant, il y a aussi une limite horizontale quant à l'ampleur avec laquelle nous pouvons mettre à l'échelle une application de fonction. En effet, nous ne pouvons pas mettre en place plus de 100 instances dans le plan de service Premium ou 200 instances dans le plan de consommation. Cela nous donne un maximum de (100 × 4) 400 vCPUs par étape dans notre traitement.

En supposant qu'un seul document prend 1 minute pour traverser toutes les étapes de manière séquentielle, le maximum que nous puissions atteindre est de 400 documents par minute ou 6,66/s.

Le coût

En supposant que nous souhaitons traiter au moins 6,66 documents par seconde, nous aurons besoin de 100 instances avec 4 vCPUs dans le plan de service premium.

Actuellement, une telle configuration nécessiterait un coût mensuel d'environ 185 759,74 $. En comparaison, une alternative utilisant uniquement des machines virtuelles coûterait seulement 31 220,69 $ par mois.

Conclusion

Bien que cette architecture offre de nombreux avantages intéressants, nous ne pouvons pas négliger l'aspect financier. Nous ne recommanderions certainement pas d'utiliser une telle architecture pour des charges de travail intensives principalement en raison des limitations d'évolutivité et de coût. L'Azure Function App vise initialement le développement d'un point de terminaison API simple desservant le reste de l'infrastructure Azure. Cela ne correspond évidemment pas au cas d'utilisation présenté ici.

L'Azure Function App est toujours bonne et s'adapterait à une fonction basée sur des événements ne ciblant pas une quantité intensive de calculs par seconde. L'architecture présentée ici a encore du sens et serait mieux mise en œuvre avec d'autres composants tels qu'Azure Container Instance. Pour le but spécifique de cet article, nous pensons qu'Azure Batch serait définitivement un bien meilleur choix.