Racks sans serveur

Sans serveur ne concerne pas l'absence physique de serveurs. Ce n'est pas un «tueur» de conteneurs et pas une tendance passagère. Il s'agit d'une nouvelle approche pour créer des systèmes dans le cloud. Dans l'article d'aujourd'hui, nous aborderons l'architecture des applications sans serveur, voyons quel rôle jouent le fournisseur de services sans serveur et les projets open source. Au final, nous parlerons de Serverless.

Je veux écrire le côté serveur de l'application (oui même une boutique en ligne). Il peut s'agir d'un chat, d'un service de publication de contenu ou d'un équilibreur de charge. Dans tous les cas, il y aura beaucoup de maux de tête: vous devrez préparer l'infrastructure, déterminer les dépendances des applications et penser au système d'exploitation hôte. Ensuite, vous devez mettre à jour les petits composants qui n'affectent pas le travail du reste du monolithe. Eh bien, n'oublions pas la mise à l'échelle sous charge.

Mais que se passe-t-il si nous prenons des conteneurs éphémères dans lesquels les dépendances requises sont déjà préinstallées et les conteneurs eux-mêmes sont isolés les uns des autres et du système d'exploitation hôte? Nous diviserons le monolithe en microservices, chacun pouvant être mis à jour et mis à l'échelle indépendamment des autres. Après avoir placé le code dans un tel conteneur, je peux l'exécuter sur n'importe quelle infrastructure. Déjà mieux.

Et si vous ne souhaitez pas configurer de conteneurs? Je ne veux pas penser à faire évoluer l'application. Je ne veux pas payer pour des conteneurs en cours d'exécution lorsque la charge sur le service est minimale. Je veux écrire du code. Concentrez-vous sur la logique métier et commercialisez les produits à la vitesse de la lumière.

Ces pensées m'ont conduit à l'informatique sans serveur. Sans serveur dans ce cas ne signifie pas l' absence physique de serveurs, mais l'absence de casse-tête pour gérer l'infrastructure.

L'idée est que la logique d'application se décompose en fonctions indépendantes. Ils ont une structure d'événement. Chacune des fonctions effectue une "microtâche". Tout ce qui est requis du développeur est de charger les fonctions dans la console fournie par le fournisseur de cloud et de les corréler avec les sources d'événements. Le code sera exécuté sur demande dans un conteneur préparé automatiquement, et je ne paierai que pour le temps d'exécution.

Voyons à quoi ressemblera le processus de développement d'applications.

Du développeur

Plus tôt, nous avons commencé à parler de l'application pour la boutique en ligne. Dans l'approche traditionnelle, la logique principale du système est réalisée par une application monolithique. Et le serveur avec l'application fonctionne en permanence, même s'il n'y a pas de charge.

Pour passer à sans serveur, nous divisons l'application en microtâches. Sous chacun d'eux, nous écrivons notre propre fonction. Les fonctions sont indépendantes les unes des autres et ne stockent pas les informations d'état. Ils peuvent même être écrits dans différentes langues. Si l'un d'eux plante, l'application entière ne s'arrêtera pas. L'architecture de l'application ressemblera à ceci:


La division en fonctions dans Serverless est similaire à celle des microservices. Mais un microservice peut effectuer plusieurs tâches et, idéalement, une fonction devrait en effectuer une. Imaginez que la tâche consiste à collecter des statistiques et à les afficher à la demande de l'utilisateur. Dans l'approche microservice, la tâche est effectuée par un service avec deux points d'entrée: écrire et lire. Dans l'informatique sans serveur, ce seront deux fonctions différentes qui ne sont pas interconnectées. Un développeur économise des ressources informatiques si, par exemple, les statistiques sont mises à jour plus souvent que téléchargées.

Les fonctions sans serveur doivent être exécutées dans un court laps de temps (timeout), déterminé par le fournisseur de services. Par exemple, pour AWS, le délai d'expiration est de 15 minutes. Cela signifie que les fonctions à longue durée de vie (longue durée de vie) devront être modifiées pour répondre aux exigences - ce Serverless diffère des autres technologies populaires aujourd'hui (conteneurs et Platform as a Service).

Nous attribuons un événement à chaque fonction. Un événement est le déclencheur d'une action:
Les événements peuvent être des requêtes HTTP, des données en streaming, des files d'attente de messages, etc. Les sources d'événements sont le changement ou l'apparence des données. De plus, les fonctions peuvent être exécutées par minuterie.

L'architecture a fonctionné et l'application est presque devenue sans serveur. Ensuite, nous allons chez le fournisseur de services.

Du fournisseur

L'informatique sans serveur est généralement proposée par les fournisseurs de services cloud. Ils l'appellent différemment: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

Nous utiliserons le service via la console ou le compte personnel du fournisseur. Le code de fonction peut être téléchargé de l'une des manières suivantes:

• écrire du code dans les éditeurs intégrés via la console Web,
• Téléchargez l'archive avec le code,
• travailler avec des dépôts git publics ou privés.

Ici, nous configurons les événements qui appellent la fonction. Différents fournisseurs peuvent avoir différents ensembles d'événements.



Le fournisseur de son infrastructure a construit et automatisé le système Function as a Service (FaaS):

1. Le code de fonction arrive au référentiel côté fournisseur.
2. Lorsqu'un événement se produit, les conteneurs avec l'environnement préparé sont automatiquement déployés sur le serveur. Chaque instance de fonction a son propre conteneur isolé.
3. A partir du stockage, la fonction est envoyée au conteneur, calculée, renvoie le résultat.
4. Le nombre d'événements parallèles augmente - le nombre de conteneurs augmente. Le système évolue automatiquement. Si les utilisateurs n'accèdent pas à la fonction, elle sera inactive.
5. Le fournisseur définit le temps d'inactivité des conteneurs - si pendant ce temps les fonctions n'apparaissent pas dans le conteneur, il est détruit.

Nous obtenons donc Serverless de la boîte. Nous paierons le service selon le modèle de paiement à l'utilisation et uniquement pour les fonctions utilisées, et uniquement pour le moment où elles ont été utilisées.

Pour initier les développeurs au service, les fournisseurs offrent jusqu'à 12 mois de tests gratuits, mais ils limitent le temps de calcul total, le nombre de demandes par mois, l'argent ou la consommation d'énergie.

Le principal avantage de travailler avec un fournisseur est la possibilité de ne pas se soucier de l'infrastructure (serveurs, machines virtuelles, conteneurs). De son côté, le fournisseur peut implémenter FaaS à la fois sur ses propres développements et en utilisant des outils open-source. Nous en reparlerons plus loin.

De l'open source

Au cours des deux dernières années, la communauté open-source a activement travaillé sur les outils sans serveur. En particulier, les plus grands acteurs du marché contribuent au développement de plateformes sans serveur:

• Google propose aux développeurs son outil open-source - Knative . Son développement a impliqué IBM, RedHat, Pivotal et SAP;
• IBM a travaillé sur la plate-forme OpenWhisk Serverless, qui est ensuite devenue le projet Apache Foundation;
• Microsoft a partiellement ouvert le code de la plateforme Azure Functions .

Des développements sont également menés dans le sens de frameworks sans serveur. Kubeless et Fission sont déployés au sein de clusters Kubernetes pré-préparés, OpenFaaS fonctionne avec Kubernetes et Docker Swarm. Le framework agit comme une sorte de contrôleur - sur demande, il prépare le runtime à l'intérieur du cluster, puis y exécute une fonction.

Les cadres laissent une place à la configuration des outils pour répondre à vos besoins. Ainsi, dans Kubeless, le développeur peut configurer le délai d'expiration de la fonction (la valeur par défaut est de 180 secondes). La fission, pour tenter de résoudre le problème du démarrage à froid, propose de maintenir une partie des conteneurs en marche tout le temps (bien que cela entraîne le coût des temps d'arrêt). Et OpenFaaS propose un ensemble de déclencheurs pour tous les goûts et toutes les couleurs: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT et autres.

Les instructions pour commencer peuvent être trouvées dans la documentation officielle des frameworks. Travailler avec eux implique un peu plus de compétences que de travailler avec un fournisseur - c'est au moins la capacité de démarrer un cluster Kubernetes via la CLI. Maximum, inclut d'autres outils open-source (par exemple, le gestionnaire de files d'attente de Kafka).

Quelle que soit la façon dont nous travaillons avec Serverless - via un fournisseur ou en utilisant l'open source, nous bénéficions d'un certain nombre d'avantages et d'inconvénients de l'approche Serverless.

Du point de vue des avantages et des inconvénients

Serverless développe les idées d'une infrastructure de conteneurs et d'une approche de microservices, dans lesquelles les équipes peuvent travailler en mode multilingue sans être liées à une seule plateforme. La construction d'un système est simplifiée et la correction des erreurs devient plus facile. L'architecture de microservice vous permet d'ajouter de nouvelles fonctionnalités au système beaucoup plus rapidement que dans le cas d'une application monolithique.

Sans serveur réduit encore plus le temps de développement en laissant le développeur se concentrer uniquement sur la logique métier et le codage de l'application. En conséquence, le temps de mise sur le marché pour le développement est réduit.

En prime, nous obtenons une mise à l'échelle automatique de la charge, et nous ne payons que pour les ressources utilisées et uniquement au moment où elles sont utilisées.

Comme toute technologie, Serverless présente des inconvénients.

Par exemple, un tel inconvénient pourrait être un temps de démarrage à froid (jusqu'à 1 seconde en moyenne pour des langages tels que JavaScript, Python, Go, Java, Ruby).

D'une part, en effet, l'heure d'un démarrage à froid dépend de nombreuses variables: la langue dans laquelle la fonction est écrite, le nombre de bibliothèques, la quantité de code, la communication avec des ressources supplémentaires (mêmes bases de données ou serveurs d'authentification). Étant donné que le développeur contrôle ces variables, il peut raccourcir l'heure de début. Mais d'un autre côté, le développeur ne peut pas contrôler l'heure de lancement du conteneur - tout dépend du fournisseur.

Un démarrage à froid peut se transformer en un démarrage à chaud lorsque la fonction réutilise le conteneur lancé par l'événement précédent. Cette situation se produira dans trois cas:

• si les clients utilisent souvent le service et que le nombre d'appels à la fonction augmente;
• si le fournisseur, la plate-forme ou le framework vous permet de maintenir une partie des conteneurs en fonctionnement tout le temps;
• si le développeur exécute des fonctions de minuterie (disons, toutes les 3 minutes).

Pour de nombreuses applications, un démarrage à froid n'est pas un problème. Ici, vous devez vous baser sur le type et les tâches du service. Un démarrage différé d'une seconde n'est pas toujours critique pour une application métier, mais peut devenir critique pour les services médicaux. Dans ce cas, l'approche sans serveur ne sera probablement plus adaptée.

Le prochain inconvénient de Serverless est la courte durée de vie de la fonction (le délai d'expiration pour lequel la fonction doit s'exécuter).

Mais, si vous devez travailler avec des tâches de longue durée, vous pouvez utiliser une architecture hybride - combiner Serverless avec d'autres technologies.

Tous les systèmes ne pourront pas fonctionner selon le schéma sans serveur.

Certaines applications conserveront toujours les données et l'état au moment de l'exécution. Certaines architectures resteront monolithiques et certaines fonctions dureront longtemps. Cependant (comme les technologies cloud, puis les conteneurs), Serverless est une technologie pleine d'avenir.

Dans cet esprit, je voudrais passer sans problème à la question de l'application de l'approche sans serveur.

Côté application

En 2018, le pourcentage d'utilisation sans serveur a augmenté d'une fois et demie . Parmi les entreprises qui ont déjà mis en œuvre la technologie dans leurs services, il existe des géants du marché tels que Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Dans le même temps, vous devez comprendre que Serverless n'est pas une panacée, mais un outil pour résoudre un certain éventail de tâches:

• Réduisez les temps d'arrêt. Vous n'avez pas besoin de garder constamment la machine virtuelle sous des services auxquels vous n'avez pas beaucoup accès.
• Traitement à la volée des données. Compressez les images, découpez l'arrière-plan, modifiez l'encodage vidéo, travaillez avec des capteurs IoT, effectuez des opérations mathématiques.
  
• Collez ensemble d'autres services. Dépôt Git avec des programmes internes, chat bot dans Slack avec Jira et avec un calendrier.
• Équilibrez la charge. Ici, nous nous attardons plus en détail.

Disons qu'il y a un service auquel 50 personnes viennent. En dessous se trouve une machine virtuelle avec un matériel faible. Périodiquement, la charge sur le service augmente considérablement. Ensuite, le fer faible ne peut pas faire face.

Vous pouvez inclure un équilibreur dans le système qui répartira la charge, par exemple, sur trois machines virtuelles. À ce stade, nous ne pouvons pas prédire avec précision la charge, nous conservons donc une certaine quantité de ressources fonctionnant «en réserve». Et surpayer pour les temps d'arrêt.

Dans cette situation, nous pouvons optimiser le système via une approche hybride: pour l'équilibreur de charge, nous laissons une machine virtuelle et mettons un lien vers Serverless Endpoint avec des fonctions. Si la charge dépasse le seuil, l'équilibreur lance des instances de fonctions qui prennent en charge une partie du traitement des demandes.


Ainsi, Serverless peut être utilisé là où ce n'est pas trop souvent, mais pour traiter un grand nombre de demandes de manière intensive. Dans ce cas, l'exécution de plusieurs fonctions pendant 15 minutes est plus rentable que la détention permanente d'une machine virtuelle ou d'un serveur.

Avec tous les avantages de l'informatique sans serveur, avant de l'implémenter, vous devez d'abord évaluer la logique de l'application et comprendre les tâches que Serverless peut résoudre dans un cas particulier.

Sans serveur et Selectel

Chez Selectel, nous avons déjà facilité le travail avec Kubernetes dans un cloud privé virtuel grâce à notre panneau de contrôle. Nous construisons maintenant notre propre plateforme FaaS. Nous voulons que les développeurs puissent résoudre leurs problèmes avec Serverless via une interface pratique et flexible.

Vous souhaitez suivre le processus de développement de la nouvelle plateforme FaaS? Abonnez-vous à la newsletter Selectel «Cloud Functions» sur la page de service . Nous parlerons du processus de développement et annoncerons la version fermée de Cloud Functions.

Si vous avez des idées sur ce que devrait être une plate-forme FaaS idéale et comment vous souhaitez utiliser Serverless dans vos projets, partagez-les dans les commentaires. Nous prendrons en compte vos souhaits lors du développement de la plateforme.

Matériaux utilisés dans l'article:

• Utilisation sans serveur multipliée par 1,5 (rapport Full RightScale)
• Comment l'heure de démarrage à froid dépend de la langue de l'application