Le bon matériel pour un Edge Computing réellement distant

Supposons que vous exploitiez des cliniques éphémères dans des villages ruraux et des endroits éloignés où il n’y a pas d’Internet. Vous devez capturer et partager des données dans toute la clinique pour fournir des soins de santé vitaux, mais si les applications que vous utilisez nécessitent une connexion Internet pour fonctionner, elles ne peuvent pas fonctionner dans ces zones.

Ou peut-être êtes-vous un opérateur pétrolier et gazier qui doit analyser les données d’avertissement critiques d’un capteur de pression sur une plate-forme en mer du Nord. Si les données doivent être traitées dans des centres de données cloud, elles doivent parcourir des distances incroyables, à grands frais, sur des réseaux peu fiables. Cela entraîne des degrés élevés de latence ou de lenteur du réseau, de sorte qu’au moment où un résultat est renvoyé à la plate-forme, il peut être trop tard pour prendre des mesures.

Ces types de cas d’utilisation représentent une classe croissante d’applications qui nécessitent une disponibilité de 100 % et une vitesse en temps réel garantie, quel que soit l’endroit où elles opèrent dans le monde.

Un défi fondamental pour répondre à ces exigences reste le réseau – il existe encore de vastes étendues du globe avec peu ou pas d’Internet – ce qui signifie que les applications qui dépendent de la connectivité ne peuvent pas fonctionner dans ces zones.

Les progrès émergents de la technologie réseau comblent ces lacunes, mais quelles que soient la couverture, la fiabilité ou la vitesse d’un réseau, il subira inévitablement des lenteurs et des pannes qui affectent les applications qui en dépendent, entraînant une mauvaise expérience utilisateur et des temps d’arrêt.

Le choix du développement responsable

Comment garantissez-vous la disponibilité et la latence ultra-faible des applications, en particulier lorsque vous travaillez dans des zones mortes d’Internet ? Cela est rendu possible en comprenant les défis de la connectivité réseau et en les contournant.

Le choix de développement responsable consiste à concevoir et à créer des applications qui :

  • Peut toujours fonctionner lorsque la connectivité réseau est interrompue ou indisponible.
  • Peut tirer le meilleur parti de la connectivité réseau lorsqu’elle est disponible, car elle peut être éphémère et pas toujours rapide.

Pour ce faire, vous devez amener le traitement des données et l’infrastructure de calcul du côté proche du réseau, c’est-à-dire à la périphérie littérale, comme dans la camionnette de la clinique contextuelle ou sur la plate-forme pétrolière, réduisant ainsi les dépendances vis-à-vis des centres de données cloud distants.

L’emmener jusqu’au bout

Architecture infonuagique

Une architecture de cloud computing suppose que le stockage et le traitement des données sont hébergés dans le cloud. Dans cette représentation, les services d’application et la base de données sont hébergés et exécutés dans le cloud, accessibles à partir d’appareils périphériques via des appels REST :

L’architecture cloud dépend d’Internet pour que les applications fonctionnent correctement. En cas de lenteur ou d’interruption du réseau, les applications ralentiront ou s’arrêteront.

Architecture de périphérie

Les architectures Edge Computing amènent le traitement des données à la périphérie, à proximité des applications, ce qui les rend plus rapides car les données n’ont pas à voyager jusqu’au cloud et en revenir. Et cela les rend plus fiables car le traitement local des données leur permet de fonctionner même sans Internet.

Il ne s’agit pas de se débarrasser du cloud ; vous avez toujours besoin de ce point d’agrégation éventuel. Il s’agit d’étendre le cloud au côté proche du réseau. Les architectures Edge utilisent le réseau pour la synchronisation, où les données sont synchronisées dans l’écosystème d’applications lorsque la connectivité est disponible.

Et il est important de noter que par « synchronisation », nous entendons quelque chose de plus que la simple utilisation du réseau pour répliquer des données. Il s’agit également d’utiliser le plus efficacement possible la bande passante précieuse et éphémère lorsqu’elle est disponible.

La technologie de synchronisation fournit une compression inter-enregistrements, une compression delta, un traitement par lots, un filtrage, une capacité de redémarrage et bien plus encore – et grâce à ces efficacités, elle transmet moins de données via le câble, ce qui est essentiel sur des réseaux lents, peu fiables ou à bande passante partagée.

En termes simples, une architecture de périphérie vous permet de :

  • Capturez, stockez et traitez les données là où elles se produisent, offrant disponibilité et rapidité.
  • Synchronisez les données de manière sécurisée et efficace dans l’ensemble de l’écosystème d’applications, dans la mesure où la connectivité le permet, pour plus de cohérence.

Voyons maintenant comment adopter une architecture de périphérie.

Tout ce que tu dois faire est ASC

Au cours des deux dernières années, nous avons assisté à une croissance des technologies de nouvelle génération conçues pour rendre les applications plus disponibles dans plus d’endroits et pour plus d’utilisateurs que jamais auparavant.

Ces avancées abaissent la barre et permettent aux organisations d’adopter plus facilement des architectures de périphérie pour garantir la vitesse, la disponibilité et l’utilisation efficace de la bande passante pour les applications, en particulier celles qui fonctionnent dans des endroits distants et des zones mortes Internet.

Pour créer une architecture Edge, vous avez besoin de quatre composants système fondamentaux :

  1. Un environnement de calcul cloud.
  2. Un environnement de calcul en périphérie.
  3. Un réseau reliant le cloud et la périphérie.
  4. Une base de données qui se synchronise du cloud à la périphérie.

Ici, nous combinons trois technologies de pointe pour créer une architecture de pointe qui peut fonctionner à grande vitesse, tout le temps, n’importe où sur la planète.

Nous l’appelons le ASC empiler:

  • UNBoule de neige WS
  • SrythmeX Starlink
  • Couchbase Capella

Qu’est-ce qu’AWS Snowball ?

AWS Snowball est un service qui fournit des appareils sécurisés, portables et robustes (appelés appareils AWS Snowball Edge) qui exécutent l’infrastructure AWS pour alimenter les applications en périphérie.

Périphérique AWS Snowball Edge (Source : Amazon)

Les appareils ont à peu près la taille d’une valise et fournissent une informatique, un traitement et un stockage de données locaux pour des environnements déconnectés tels que des navires, des mines, des plates-formes pétrolières, des cliniques de terrain et des installations de fabrication à distance. Partout où l’infrastructure AWS est nécessaire mais irréalisable en raison du manque d’Internet fiable, Snowball fournit une solution portable.

Décrit en termes plus simples, Snowball est un « centre de données AWS dans une boîte » qui arrive à votre porte préconfiguré avec les services AWS et prêt à l’emploi. Il prend en charge AWS S3, EC2, Lambda, EBS et plus encore. Vous le branchez, puis accédez et gérez l’environnement via AWS Control Plane sur les réseaux locaux.

En fournissant une infrastructure portable, familière et basée sur des normes, AWS Snowball permet à quiconque de configurer et d’exploiter facilement des centres de données en périphérie sans se soucier de la connectivité Internet.

Qu’est-ce que SpaceX Starlink ?

Starlink est un service Internet par satellite de nouvelle génération de SpaceX. Il est composé de « constellations » de milliers de petits satellites en orbite terrestre basse – à environ 340 miles dans l’espace. Cela s’oppose aux satellites géostationnaires traditionnels à grande échelle qui orbitent dans un emplacement fixe à environ 22 000 milles.

En raison de la distance physique plus courte entre l’antenne du client et le satellite, Starlink peut fournir une latence de 20 à 50 millisecondes en moyenne, ce qui est beaucoup plus rapide que l’Internet par satellite traditionnel (qui, en raison de la plus grande distance, peut subir des latences allant jusqu’à 600 millisecondes ou plus).

L’orbite inférieure et la technologie de réseau intelligent permettent à Starlink d’offrir des performances comparables aux réseaux terrestres. Leur service « Business » offre des vitesses de téléchargement allant jusqu’à 350 Mbps et une latence de 20 à 40 ms.

Bien que Starlink fournisse une connectivité Internet vitale dans les zones avec peu ou pas d’autres options, il n’est pas infaillible. Les connexions peuvent subir des ralentissements pendant les heures de pointe lorsque la plupart des utilisateurs d’une cellule donnée sont susceptibles de partager de la bande passante, ou si la parabole subit des interférences provenant d’appareils électroménagers, de lampes fluorescentes ou d’autres réseaux Wi-Fi à proximité. Et les obstacles tels que la couverture nuageuse, les branches d’arbres ou les murs épais peuvent interrompre la connexion.

En tant que tel, il est important de développer des applications capables de supporter des lenteurs et des interruptions intermittentes et de rester entièrement disponibles. Pour ce faire, vous devez optimiser l’utilisation efficace de cette précieuse ressource réseau partagée en déplaçant la plus petite quantité de données possible, sous sa forme la plus compacte.

Qu’est-ce que Couchbase ?

Couchbase est une plate-forme de base de données cloud NoSQL avec une vitesse en mémoire, une familiarité avec SQL et une flexibilité JSON. Il supporte nativement l’architecture edge en fournissant :

  • Couchbase Capella : une base de données cloud entièrement gérée en tant que service (DBaaS).
  • Capella App Services : services entièrement gérés pour le stockage de fichiers, la synchronisation bidirectionnelle, l’authentification et le contrôle d’accès pour les applications mobiles et périphériques.
  • Couchbase Lite : Une version légère intégrable de la base de données Couchbase.

Capella App Services synchronise les données entre la base de données cloud backend et les bases de données périphériques dans la mesure où la connectivité le permet, tandis que pendant les perturbations du réseau, les applications continuent de fonctionner grâce au traitement local des données.

Avec Couchbase, vous pouvez créer des architectures de périphérie à plusieurs niveaux pour prendre en charge n’importe quelle exigence de vitesse, de disponibilité ou de faible bande passante.

Couchbase fournit une synchronisation intégrée pour prendre en charge les architectures de périphérie multiniveaux complexes (Source : Couchbase)

Tester la pile

Couchbase Engineering souhaitait déterminer une base de référence pour savoir comment la pile ASC fonctionne mieux ensemble, chaque technologie travaillant pour améliorer et augmenter les autres fonctionnalités.

Pour ce faire, nous installons la pile dans un emplacement distant dans une architecture Edge classique :

  • AWS Snowball Edge fournit une infrastructure informatique en périphérie.
  • Couchbase est déployé sur l’appareil Snowball Edge pour le stockage et le traitement des données locales.
  • Couchbase Capella sert de DBaaS backend hébergé dans le cloud.
  • Starlink fournit le réseau de l’appareil Snowball Edge à Couchbase Capella.
  • Couchbase Capella App Services fournit une synchronisation sécurisée entre la base de données périphérique et la base de données cloud.

Couchbase s’exécutant sur AWS Snowball en utilisant Starlink pour se synchroniser avec Capella (Source : Couchbase)

Avec cette architecture de périphérie de base en place, nous avons entrepris de mesurer son efficacité à réduire la latence et la consommation de bande passante par rapport à une architecture cloud où l’application lit et écrit sur Starlink via REST.

Nous avons exécuté quatre scénarios de test :

  • Essai 1 était d’écrire 1 000 nouveaux documents sur Snowball Edge via un réseau local (LAN) câblé et de mesurer la quantité de données transférées et la latence par opération.
  • Essai 2 était de synchroniser les 1 000 nouveaux documents de Snowball à Capella via Starlink et de mesurer la quantité de données transférées et le temps complet de transfert.
  • Essai 3 était d’écrire 1 000 nouveaux documents sur Capella via Starlink et de mesurer la quantité de données transférées et la latence par opération.
  • Essai 4 était de synchroniser les 1 000 nouveaux documents de Capella à Snowball via Starlink et de mesurer la quantité de données transférées et le temps complet de transfert.

Les tests ont utilisé un ensemble de données de catalogue de produits du monde réel (1 000 produits), à 650 octets par enregistrement en moyenne.

Les résultats

Comparaison de latence

Les applications accédant à la base de données Couchbase exécutées sur l’appareil Snowball local ont montré une latence considérablement réduite par rapport à l’accès à la base de données cloud.

Pour les lectures et les écritures, les résultats ont montré que l’architecture Edge réduisait la latence de 98 % par rapport à l’architecture cloud :

Comparaison de bande passante

En comparant l’architecture de périphérie et l’architecture cloud pour l’utilisation de la bande passante, les résultats ont montré que le volume total de données envoyé via Starlink avait considérablement diminué sur l’architecture de périphérie.

En raison des efficacités rendues possibles par la synchronisation, comme la compression inter-enregistrements, la compression delta, le traitement par lots, le filtrage, la capacité de redémarrage, etc., l’architecture Edge utilise au mieux la bande passante partagée – critique pour les périodes de pointe, lors de la connexion sous une forte couverture nuageuse ou dans les zones éloignées comme les forêts ou les jungles où les obstacles peuvent entraver la vitesse et le débit.

La synchronisation des mises à jour sur l’architecture Edge réduit la quantité de données transférées via Starlink de 42 % par rapport à l’utilisation d’appels REST vers une architecture cloud.

Ces résultats de test établissent une base de référence prudente pour les améliorations de la latence et de la bande passante qui peuvent être observées lors de l’utilisation de la pile ASC pour une architecture de périphérie de base. Dans un grand environnement de production, les améliorations sont susceptibles d’être plus substantielles.

Le bord est plus proche que tu ne le penses

Couchbase aide depuis longtemps ses clients à répondre aux exigences critiques en matière de vitesse en temps réel et de disponibilité à 100 % pour leurs applications. Et avec la pile ASC, Couchbase s’associe à AWS Snowball et SpaceX Starlink pour aider les organisations à adopter l’edge computing plus rapidement, plus facilement et dans plus d’endroits que jamais.

Et la meilleure partie est que la pile est si portable que vous pouvez littéralement l’emporter avec vous partout où vous allez !

Appareil AWS Snowball Edge et parabole Starlink réels utilisés dans les tests Couchbase

Voyez par vous-même à quel point il est facile de commencer. Essayez Couchbase Capella aujourd’hui gratuitement.

Groupe Créé avec Sketch.
www.actusduweb.com
Suivez Actusduweb sur Google News


Ce site utilise des cookies pour améliorer votre expérience. Nous supposerons que cela vous convient, mais vous pouvez vous désinscrire si vous le souhaitez. J'accepte Lire la suite