Votre application mobile fonctionne bien dans vos tests locaux. Les utilisateurs de Londres l'ouvrent et tout se passe rapidement. Les utilisateurs de Tokyo ouvrent la même version et se plaignent que le démarrage est lent, les mises à jour prennent trop de temps et certaines contenus semblent retardés. Vous n'avez pas modifié l'application pour une région et pas l'autre. La différence est la distance.
C'est la raison pratique pour laquelle les développeurs finissent par demander qu'est-ce qu'un réseau d'edge. Pas parce qu'ils veulent un nouveau buzzword, mais parce que les applications mondiales exposent les limites de l'envoi de chaque requête, de chaque ressource et de chaque mise à jour vers un endroit lointain.
Pour les équipes mobiles, cela devient douloureux pendant les mises à jour. Vous devez pousser une correction JavaScript, une mise à jour de la copie ou une petite modification d'asset. Certains utilisateurs la reçoivent rapidement. D'autres attendent plus longtemps, réessayent ou rencontrent des temps d'attente en fonction de leur emplacement et de la distance que la requête doit parcourir. Le réseau d'edge existe pour réduire cette lacune.
Table des matières
- Pourquoi votre application est rapide à Londres mais lente à Tokyo
- L'architecture de base d'un réseau d'edge
- Réseau Edge vs CDN vs Traitement Edge
- Les avantages clés pour votre application
- Cas d'utilisation réels du Réseau Edge
- Comment mettre en œuvre une stratégie Edge
Why Is Your App Fast in London but Slow in Tokyo
Un utilisateur appuie sur l'icône de votre application à Londres. L'application vérifie la configuration à jour, télécharge quelques ressources et continue. Un utilisateur à Tokyo fait la même chose, mais chaque requête doit voyager plus loin pour atteindre votre infrastructure. Même si chaque requête ne semble qu'un peu plus lente, les applications mobiles effectuent souvent plusieurs requêtes de suite. C'est là que les utilisateurs commencent à décrire l'application comme « lente au hasard ».
Le concept manquant est la latence de réseau. Si vous souhaitez un rappel pratique, ce guide à la la latence de réseau dans les applications mobiles connecte l'idée directement au comportement des développeurs de débogage.
Un réseau edge résout cela en déplaçant le traitement réseau et la mise à jour plus près de l'emplacement de l'utilisateur. Au lieu de forcer chaque appareil à communiquer avec un point d'origine lointain, le système peut servir les requêtes à partir d'un emplacement proche. Intel décrit un réseau edge comme une architecture distribuée qui déplace les fonctions de calcul, de stockage et de réseau depuis un nuage central vers des points de présence géographiquement plus proches, réduisant ainsi la distance que les données doivent parcourir pour chaque requête, comme expliqué dans l'aperçu d'Intel sur le sujet architecture de réseau de bord.
Pourquoi cela compte plus maintenant
Cela n'est plus une infrastructure de niche. Une projection indique que d'ici 2025, 75% des données générées par les entreprises seront créées et traitées en dehors d'un centre de données centralisé ou cloud et le marché du calcul en bord de réseau est projeté de passer de$47,0 milliard en 2023 à $171,0 milliard d'ici 2031 selon les projections de l'industrie du calcul en bord de réseauVos utilisateurs ne vivent pas l'« architecture ». Ils vivent les retards, les réessais et les comportements incohérents par région. Pour un développeur mobile, cela se traduit par une règle simple. Si votre application a des utilisateurs mondiaux, votre système de mise à jour, vos actifs et votre chemin d'actualisation doivent se comporter de manière mondiale également. Sinon, votre application ne sera rapide que pour les personnes qui vivent près de votre infrastructure..
edge network architecture
Why this matters more now
L'Architecture de Base d'un Réseau Edge
La meilleure façon de comprendre un réseau edge est de cesser de penser aux serveurs et de commencer à penser à la logistique.
Un setup cloud traditionnel fonctionne comme un magasin central. Tout se trouve dans un grand entrepôt principal. Quelle que soit la localisation du client, chaque commande est expédiée à partir de cette emplacement. C'est simple à gérer, mais ce n'est pas idéal lorsque les clients sont répartis sur plusieurs continents.
Un réseau edge ressemble plus à un système de entrepôts locaux ou magasins de détail. L'entrepôt principal existe toujours, mais les articles courants et certaines opérations locales se produisent plus près du client.
Cloud central versus points de présence proches
Dans le réseau edge, ces emplacements locaux sont souvent appelés points de présenceou PoPs. Ils sont des lieux géographiquement répartis où le trafic peut être reçu, traité, sécurisé et parfois mis en cache avant qu'il ne soit nécessaire de le faire frapper sur le système central.
Pour une application mobile, cela signifie que l'utilisateur du Japon n'a pas toujours besoin de attendre que l'infrastructure soit située en Europe ou en Amérique du Nord. Sa demande peut entrer dans le réseau à un point plus proche et être traitée avec moins de longs trajets sur Internet.
Cela compte également pour les mises à jour. Si votre application vérifie une nouvelle charge de bundle web, un fichier de configuration ou un paquet d'actifs à l'ouverture, chaque trajet supplémentaire apparaît dans le comportement de démarrage. Les équipes qui surveillent cela bénéficient généralement de la mise en place de la surveillance de la performance dans les applications Capacitor afin qu'elles puissent comparer les régions au lieu de se fier uniquement aux tests locaux.
La mise en cache, la mise en route et le traitement local
Trois pièces font fonctionner le modèle pour la plupart des développeurs :
- La mise en cache stocke le contenu fréquent à proximité. Si beaucoup d'utilisateurs demandent les mêmes actifs d'application ou le paquet d'actualisation, le lieu de bord peut conserver une copie prête au lieu de la récupérer à chaque fois de l'origine.
- La mise en route envoie les utilisateurs au meilleur point d'entrée proche. Imaginez-le comme un contrôle de circulation. Le réseau essaie d'éviter d'envoyer un utilisateur sur un chemin long ou congestionné lorsque existe un chemin plus proche.
- Le traitement local gère les tâches simples avant que le nuage central ne soit impliqué. Cela peut inclure le filtrage, les vérifications d'authentification, la gestion des requêtes ou la préparation des données avant qu'elles ne soient transmises vers le haut.
Règle pratique : S'il est demandé la même chose à plusieurs reprises par les utilisateurs dans de nombreux endroits, il ne devrait probablement pas être récupéré d'un origine lointaine pour chaque demande.
C'est la réponse de base à « qu'est-ce qu'un réseau d'edge » en anglais simple. C'est une façon distribuée de placer les fonctions réseau plus près des utilisateurs afin que les requêtes courantes se terminent plus rapidement et avec moins de chances d'erreur.
Le nuage ne disparaît pas. Le nuage devient le principal entrepôt, tandis que les emplacements d'edge deviennent les magasins proches qui éloignent la distance de l'expérience utilisateur.
Réseau d'edge vs CDN vs Edge Computing
Ces trois termes se mélangent constamment et la confusion est compréhensible car ils se chevauchent dans les produits réels.
Un développeur entend que le fournisseur a « livraison d'edge », « calcul d'edge » et « CDN mondial », et cela ressemble à la même chose. Ce n'est pas le cas.
Où les développeurs les mélangent généralement
A CDN est généralement le concept le plus facile à comprendre. Sa tâche est principalement de mettre en cache et de livrer du contenu comme des images, des fichiers JavaScript, des feuilles de style, des segments de vidéo et des fichiers téléchargeables provenant de lieux proches des utilisateurs.
Le calcul à l'égout est plus large. Cela signifie exécuter la logique d'application ou le traitement de données près de l'utilisateur ou du dispositif, et non seulement stocker des fichiers mis en cache là.
Le réseau d'égout est la couche de connectivité distribuée sous-jacente qui rend ces modèles possibles. Neos Networks décrit l'effet principal sur les performances comme une baisse de la latence de bout en bout CDN, et explique que par traitement des données sur les serveurs de bord avant qu'elles ne parviennent au nuage central, les réseaux de bord permettent aux charges de travail sensibles à la latence, telles que l'analyse temps réel et l'inference AI, dans son explication de le réseau de bord et la réduction de la latence.
Cette distinction compte pour les équipes d'applications :
- Si vous souhaitez une livraison d'image ou de bundle plus rapide, vous pouvez vous contenter de la mise en cache de type CDN.
- Si vous souhaitez un traitement des requêtes ou une prise de décision proche des utilisateurs, vous entrez dans le domaine du calcul de bord.
- Si vous souhaitez que tout le chemin soit plus proche géographiquement et à faible latence, vous parlez de réseau de bord.
Si vous travaillez sur le comportement de mise en production, les chemins d'exécution ou les temps de requête, ce recueil d'articles sur la performance réseau pour les équipes d'applications est un sujet complémentaire utile.
Réseau de bord vs. CDN vs. calcul de bord à un coup d'œil
| Attribut | Réseau de bord | Réseau de distribution de contenu (CDN) | Calcul à l'égout |
|---|---|---|---|
| Tâche principale | Déplacer les fonctions de réseau plus près des utilisateurs et des appareils | Cacher et livrer le contenu de manière efficace | Exécuter code ou traiter les données près des utilisateurs ou des appareils |
| Charge de travail typique | Gestion de la circulation des requêtes, gestion du trafic, services de réseau local | Actifs statiques, fichiers téléchargeables, livraison de médias | API logique, filtrage, inférence, traitement en temps réel |
| Où le travail a lieu | Aux points distribués près des utilisateurs | À des emplacements de cache distribués | À des serveurs d'edge ou des appareils proches de la source |
| Meilleur modèle mental | Le réseau routier et les points d'entrée voisins | L'étagère locale avec des articles populaires déjà stockés | Le travailleur local gérant les tâches sur place |
| Ce que les développeurs mobiles remarquent | Moins de retard tout au long du chemin de requête | Chargement et téléchargement d'actifs plus rapides | Décisions plus rapides sans appeler toujours l'origine |
Un CDN peut faire partie d'une stratégie d'edge, mais cela ne signifie pas automatiquement que votre application effectue du calcul d'edge.
Cette phrase clarifie la plupart des débats d'architecture.
The Avantages Clés pour Votre Application
Une fois que l'architecture fonctionne, les avantages deviennent plus faciles à évaluer. Vous n'achetez pas « edge » comme un étiquette. Vous choisissez une façon de réduire la distance, supprimer les déplacements inutiles et garder les applications utilisables lorsque les réseaux ne sont pas parfaits.
Réponses plus rapides que les utilisateurs peuvent ressentir
IBM décrit le réseau d'edge comme déplaçant de nombreuses tâches de calcul loin du traitement des centres de données vers les appareils d'edge, améliorant la vitesse, la bande passante et la fiabilité en réduisant la latence. Un exemple IBM note des vitesses de téléchargement atteignant 384 Kbpsou environ 2 à 3 fois plus rapide que les réseaux réguliers pour ce scénario, comme décrit dans l'explication d'IBM de comment les réseaux d'edge améliorent la vitesse.
Pour les applications mobiles, les utilisateurs ne pensent pas en Kbps. Ils pensent en moments :
- Le splash screen disparaît plus tôt.
- La vérification des mises à jour se termine sans attendre embarrassant.
- The app feels less fragile on weak networks.
- Un petit correctif arrive avant que les formulaires de réclamation s'accumulent.
Si votre équipe essaie de lancer des applications full-stack rapidement, il est utile de se rappeler que la vitesse de livraison n'est pas seulement un problème de flux de travail du développeur. C'est aussi un problème de chemin d'infrastructure.
Plus de résilience lorsque les réseaux sont en désordre
Les systèmes distribués peuvent continuer à servir le trafic même lorsque l'un des chemins ou emplacements a des problèmes. En pratique, cela signifie que les utilisateurs ne sont pas aussi dépendants d'un origine lointaine étant atteignable, rapide et non congestionnée à chaque moment.
Pour les équipes d'applications, cela se manifeste pendant les fenêtres de lancement et la réponse aux incidents. Si vous avez besoin de distribuer des actifs mis à jour ou des configurations à l'échelle mondiale, un emplacement d'edge proche donne souvent aux utilisateurs une meilleure chance de obtenir ce dont ils ont besoin sans un long trajet jusqu'au cœur.
Une bonne étape suivante est de passer en revue votre propre liste de vérification d'optimisation de la performance de l'application et marquez les parties qui sont vraiment des problèmes de distance réseau plutôt que des code problèmes.
Contrôles de sécurité plus proches du trafic
Les réseaux d'edge peuvent également améliorer la posture de sécurité car le filtrage et l'exécution peuvent se produire plus près de l'endroit où le trafic entre.
Considérez les systèmes source sensibles comme des systèmes de haute sécurité et traitez-les avec soin.
Cela ne signifie pas que le networking d'edge rend magiquement une application sécurisée.
Cela signifie que vous pouvez placer des protections plus tôt dans le chemin et réduire la zone d'impact sur les systèmes centraux.
Utilisations réelles de réseaux d'edge
La meilleure façon de rendre le networking d'edge concrètement est de regarder les produits que les gens utilisent déjà chaque jour.
Un homme assis sur un canapé regardant un paysage de montagnes sur un grand écran de télévision mural.
Les plateformes de streaming vidéo s'appuient sur la livraison rapprochée afin que les utilisateurs puissent démarrer la lecture rapidement et éviter la surcharge.
Les jeux en ligne ont un problème similaire avec un symptôme différent. Au lieu de la surcharge, les joueurs remarquent des retards, des réactions retardées ou des comportements multijoueur incohérents.
Les exemples sont utiles car ils sont visibles. Vous pouvez sentir le bénéfice immédiatement lorsque la vidéo démarre plus rapidement ou que le jeu ressent plus de réactivité.
Les mises à jour des applications mobiles sont moins évidentes, mais le même problème d'architecture est présent.
Lorsque votre application vérifie une mise à jour en temps réel, télécharge les actifs web modifiés, les vérifie et les applique à la prochaine mise en route, le chemin de mise à jour devient partie de la qualité du produit. Un utilisateur ne s'intéresse pas à savoir si le retard venait de la taille du bundle, de la géographie du réseau ou de la congestion de l'origine. Ils savent simplement que la correction n'est pas arrivée quand ils en avaient besoin.
C'est pourquoi la livraison à l'égout est importante pour les mises à jour en temps réel. Un service de mise à jour distribué à l'échelle mondiale peut obtenir les bundles modifiés plus proches des appareils, de sorte que le chemin de requête est plus court et moins dépendant d'une origine.
Un exemple pratique est Capgo, qui livre les mises à jour en temps réel pour les applications CapacitorJS et Electron à travers un réseau édgelocalisé et permet aux équipes de publier des bundles web signés, des canaux ciblés et de mettre en œuvre des correctifs sans attendre la revue de l'application Store. Les équipes travaillant sur des déploiements contrôlés peuvent associer cela à les mises à jour en temps réel utilisant la segmentation des utilisateurs pour éviter d'envoyer chaque version à chaque utilisateur à la fois.
Un rapide parcours aide à visualiser où la livraison à l'égout s'insère dans le flux de mise à jour :
Lorsqu'une correction est petite mais urgente, le chemin du réseau jusqu'à l'utilisateur compte presque autant que la correction elle-même.
C'est la réponse centrée sur le développeur que la plupart des articles génériques sur les réseaux édgelé passent sous silence. Les réseaux édgelé ne sont pas seulement concernés par des scénarios IoT futuristes. Ils résolvent un problème mobile très ordinaire : obtenir la mise à jour appropriée pour l'utilisateur approprié rapidement, où que l'utilisateur se trouve.
Comment mettre en œuvre une stratégie d'égout
Choisir une stratégie d'edge commence par les bouches d'application, pas par la publicité des fournisseurs. Si le principal problème est la livraison lente des actifs statiques, une approche axée sur le cache peut suffire. Si le problème est le retard des requêtes, l'incohérence régionale ou la fiabilité des mises à jour en temps réel, vous pouvez avoir besoin d'un ensemble d'edge plus large.
Qu'évaluer avant de choisir un fournisseur
Utilisez une liste de sélection qui correspond directement à votre comportement d'application :
- Emprise géographique : Votre fournisseur devrait avoir une couverture dans les zones où se trouvent vos utilisateurs, pas seulement dans les zones où se trouve votre équipe.
- Gestion du trafic : Recherchez les contrôles de routage, de cache et de livraison qui correspondent à votre charge de travail. Les actifs d'application, les appels API et les lots de mise à jour ne se comportent pas de la même manière.
- Modèle de sécurité : Vérifiez comment le fournisseur gère le contrôle d'accès, l'encryption, les besoins de conformité et le filtrage côté edge.
- Visibilité opérationnelle : Vous avez besoin de journaux, de métriques et d'observabilité suffisante pour expliquer pourquoi une région est plus lente qu'une autre.
- Flux de développement : Les APIs, les intégrations CI/CD, les contrôles de reversion et la ciblage de version sont aussi importants que la conception réseau brute.
Un bon processus de sélection commence par quelques questions concrètes :
- Où vivent nos utilisateurs les plus lents ?
- Quels requêtes se produisent lors du démarrage de l'application ?
- Qu'est-ce qui peut être mis en cache de manière sûre ?
- Quels éléments doivent encore être envoyés à l'origine ?
- Comment allons-nous déboguer un problème de livraison régionale ?
Lorsque l'edge n'est pas la bonne réponse
Tout application n'a pas besoin d'une infrastructure d'edge distribuée. Akamai note que le terme “edge” peut être flouet que c'est Not un miracle en soi . La justification économique dépend de la charge de travail, de la complexité opérationnelle et de la gouvernance, et pour certaines applications, les gains de latence ne justifient pas la surcharge de gestion d'une architecture distribuée, comme discuté dans l'entrée du glossaire d'Akamai sur Qu'est-ce qu'un réseau d'edge et ce qu'il n'est pas.
C'est une vérification de réalité utile.
Si votre application sert une audience géographique étroite, a peu d'activité de réseau de démarrage ou ne dépend pas de la livraison rapide d'actifs et de mises à jour, l'edge peut ajouter de la complexité sans suffisamment de retour.
Plus de localisations signifient plus de composants en mouvement. Plus de composants en mouvement signifient plus de décisions sur le comportement de la cache, la cohérence de la mise en production, la politique de sécurité et la surveillance.
La bonne question n'est pas « Devrions-nous utiliser l'edge parce que les applications modernes le font ? » C'est « Quels requêtes sont actuellement trop loin de l'utilisateur, et est-il utile de réduire cette distance à un coût opérationnel ? » Capgo __CAPGO_KEEP_0__
