Cloudflare aspire à rendre les propriétés Internet partout plus rapides, plus sûres et plus fiables. L'équilibrage de charge contribue à la rapidité et à la fiabilité et n’a cessé d’évoluer au cours des trois dernières années.
Prenons un scénario qui éclaire un peu plus ce qu'est un équilibreur de charge et l’intérêt qu’il représente. Un équilibreur de charge standard comprend un ensemble de pools, disposant chacun de serveurs d'origine qui sont des noms d'hôtes et/ou des adresses IP. Une stratégie de routage est assignée à chaque équilibreur de charge, qui détermine le processus de sélection du pool de serveurs d'origine.
Supposons que vous construisiez une API qui utilise le fournisseur de cloud ACME Web Services. Malheureusement, ACME a eu une semaine difficile, et leur service a connu une interruption régionale à l’est des États-Unis. Par conséquent, votre site Web n'a pas pu desservir le trafic pendant cette période, ce qui a entraîné une diminution de la confiance des utilisateurs envers la marque et un manque à gagner. Pour éviter que cela ne se reproduise, vous décidez de prendre deux mesures : utiliser un fournisseur de cloud secondaire (afin d'éviter d'avoir ACME comme point de défaillance unique) et utiliser l'équilibrage de charge de Cloudflare pour profiter de l'architecture multi-cloud. L'équilibrage de charge de Cloudflare peut vous aider à maximiser la disponibilité de votre API pour votre nouvelle architecture. Par exemple, vous pouvez assigner des contrôles d’intégrité à chacun de vos pools de serveurs d'origine. Ces contrôles d’intégrité peuvent surveiller la santé de vos serveurs d'origine en vérifiant les codes de statut HTTP, les corps de réponse, et plus encore. Si la réponse d'un pool de serveurs d'origine ne correspond pas à ce qui est attendu, alors le trafic cessera d'être dirigé vers ce dernier. Cela réduira le temps d'arrêt de votre API en cas de panne régionale d'ACME, car le trafic dans cette région sera redirigé de façon transparente vers votre ou vos pools de serveurs d'origine de repli. Dans ce scénario, vous pouvez définir le pool de repli comme étant le pool de serveurs d'origine de votre fournisseur de cloud secondaire. En plus des contrôles d’intégrité , vous pouvez utiliser la politique de routage « aléatoire » afin de répartir les demandes d'API de vos clients de manière uniforme sur l’ensemble de votre backend. Si vous souhaitez plutôt optimiser votre temps de réponse, vous pouvez utiliser « l’orientation dynamique », qui enverra le trafic au serveur d'origine déterminé comme étant la plus proche de votre client.
Nos clients aiment l'équilibrage de charge Cloudflare, et nous cherchons toujours à améliorer et à faciliter la vie de nos clients. Depuis le lancement de l'équilibrage de charge de Cloudflare, la demande la plus fréquente des clients était un service d'analyse qui fournirait des informations sur les décisions de d’orientation du trafic.
Aujourd'hui, nous déployons Load Balancing Analytics dans l'onglet Traffic (Trafic) du tableau de bord Cloudflare. Voici les trois principales composantes de ce service d'analyse :
- Un aperçu du flux de trafic qui peut être filtré par l'équilibreur de charge, le pool, le serveur d'origine et la région.
- Une carte des latences indiquant des métriques de statut d’intégrité des serveurs d'origine et de latence du réseau mondial de Cloudflare qui couvre 194 villes et qui continue de s'étendre !
- Des journaux d'événements indiquant les changements dans l’intégrité des serveurs d'origine. Cette fonctionnalité a été lancée en 2018 et suit les transitions des pools et des serveurs d'origine entre les états intègres et non-intègres. Nous avons déplacé ces journaux sous le nouveau sous-onglet Load Balancing Analytics. Consultez la documentation pour en savoir plus.
Dans cet article de blog, nous allons discuter de la distribution des flux de trafic et de la carte des latences.
Aperçu des flux de trafic
Nos utilisateurs veulent une vue détaillée des destinations de leur trafic, des raisons pour lesquelles le trafic se rend à ces destinations, et des informations sur les changements susceptibles d'optimiser leur infrastructure. Avec l'analyse d'équilibrage de charge, les utilisateurs peuvent visualiser graphiquement les demandes de trafic sur les équilibreurs de charge, les pools et les serveurs origine sur des plages de temps variables.
La compréhension de la distribution des flux de trafic informe le processus de création de nouveaux pools de serveurs d'origine, d'adaptation aux demandes de trafic de pointe et d'observation de la réponse de failover en cas de défaillances des pools de serveurs d'origine.
La figure 1 montre un aperçu du trafic pour un domaine donné. Le mardi 24, le pool rouge a été créé et ajouté à l'équilibreur de charge. Dans les 36 heures qui ont suivi, alors que le pool rouge gérait plus de trafic, les pools bleu et vert ont tous deux vu leur charge de travail réduite. Dans ce scénario, le graphique de répartition du trafic a fourni au client de nouvelles informations. Tout d'abord, il a démontré que le trafic était dirigé vers le nouveau pool rouge. Il a également permis au client de comprendre le nouveau niveau de distribution du trafic sur son réseau. Enfin, il a permis au client de confirmer si le trafic avait diminué dans les pools attendus. Au fil du temps, ces graphiques peuvent être utilisés pour mieux gérer la capacité et planifier les besoins ultérieurs des infrastructures.
Carte des latences
L’aperçu de la répartition du trafic n'est qu'une partie du puzzle. Un autre élément essentiel est la compréhension de la performance des requêtes dans le monde entier. Cet aspect est utile car les clients peuvent s'assurer que les requêtes des utilisateurs sont traitées aussi rapidement que possible, quel que soit le lieu d'origine de la requête.
La configuration standard de l'équilibrage de charge contient des moniteurs qui sondent l’intégrité des serveurs d’origine des clients. Ces moniteurs peuvent être configurés pour fonctionner depuis une ou plusieurs régions particulières ou, pour les clients Enterprise, depuis tous les emplacements Cloudflare. Ils recueillent des informations utiles, telles que le temps aller-retour, qui peuvent être agrégées pour créer la carte des latences.
La carte fournit un résumé de la réactivité des origines dans le monde entier, afin que les clients puissent voir les régions où il y a moins de requêtes et où il faudrait peut-être faire des recherches plus approfondies. Une mesure commune utilisée pour identifier la performance est la latence des demandes. Nous avons constaté que la latence p90 pour toutes les serveurs d’origine en équilibrage de charge surveillés est de 300 millisecondes, ce qui signifie que 90 % de tous les contrôles d’intégrité des moniteurs ont un temps aller-retour plus rapide que 300 millisecondes. Nous avons utilisé cette valeur pour identifier les endroits où la latence était plus lente que la latence p90 observée par d'autres clients de l'équilibrage de charge.
Dans la figure 2, nous pouvons voir la réactivité du pool de l'Asie du Nord-Est. Le pool de l'Asie du Nord-Est est lent, en particulier pour les moniteurs d'Amérique du Sud, du Moyen-Orient et d'Afrique australe, mais rapide pour les moniteurs qui sondent plus près du pool de serveurs d'origine. Malheureusement, cela signifie que les utilisateurs du pool dans des pays comme le Paraguay connaissent une forte latence des demandes. Les temps de chargement élevés des pages ont de nombreuses conséquences fâcheuses : un taux de rebond plus élevé des visiteurs, une diminution du taux de satisfaction des visiteurs et un classement plus bas par les moteurs de recherche. Afin d'éviter ces répercussions, un administrateur de site pourrait envisager d'ajouter un nouveau pool de serveurs d'origine dans une région plus proche des régions mal desservies. Dans la figure 3, nous pouvons voir le résultat de l'ajout d'un nouveau pool de serveurs d'origine à l’est de l'Amérique du Nord. Nous voyons que le nombre d'emplacements où le domaine a été jugé comme étant non-intègre tombe à zéro et que le nombre d’emplacements lents diminue de plus de 50 %.
Couplée aux métriques de flux de trafic de la page Overview (Aperçu), la carte des latences fournit aux utilisateurs des informations leur permettant d'optimiser leurs systèmes internes, de réduire leurs coûts et d'augmenter la disponibilité de leurs applications.
API GraphQL Analytics
En arrière plan, l'analyse de l'équilibrage de la charge est optimisée par l'API GraphQL Analytics. Comme vous l'apprendrez plus tard cette semaine, GraphQL nous apporte de nombreux avantages chez Cloudflare. Les clients n'ont plus qu'à apprendre un seul format API qui leur permettra d'extraire uniquement les données dont ils ont besoin. Pour le développement interne, GraphQL élimine le besoin des API d'analyse personnalisées pour chaque service, réduit le coût des requêtes en augmentant les requêtes cachées et réduit la fatigue des développeurs en utilisant un langage de requête simple avec des formats d'entrée et de sortie normalisés. Très bientôt, tous les clients de l'équilibrage de charge qui sont sur les offres payantes auront la possibilité d'extraire des informations de l'API GraphQL. Voyons quelques exemples de la façon dont vous pouvez utiliser l'API GraphQL pour comprendre vos journaux d'équilibrage de charge.
Supposons que vous vouliez comprendre le nombre de demandes que les pools pour un équilibreur de charge voient depuis les différents emplacements du réseau mondial de Cloudflare. La requête de la figure 4 compte le nombre de combinaisons uniques (emplacement, ID de pool) toutes les quinze minutes au cours d'une semaine.
Pour le contexte, notre exemple d'équilibreur de charge, lb.example.com, utilise l’orientation dynamique. L’orientation dynamique dirige les requêtes vers le pool de serveurs d'origine le plus réactif et le plus disponible, qui est souvent le plus proche. Il le fait au moyen d'une mesure de temps aller-retour pondérée. Essayons de comprendre pourquoi tout le trafic de Singapour (SIN) est dirigé vers notre pool d'Asie du Nord-Est (asia-ne). Nous pouvons exécuter la requête de la Figure 5. Cette requête nous montre que le pool asie-ne a une valeur avgRttMs de 67 ms, alors que les deux autres pools ont des valeurs avgRttMs supérieures à 150 ms. La valeur avgRttMs inférieure explique pourquoi le trafic de Singapour est acheminé vers le pool asia-ne.
Remarquez comment la requête de la figure 4 utilise le schéma loadBalancingRequestsGroups, alors que la requête de la figure 5 utilise le schéma loadBalancingRequests. Les requêtes loadBalancingRequestsGroups regroupent les données sur l'intervalle de requête demandé, alors que loadBalancingRequests fournit des informations granulaires sur les requêtes individuelles. Pour ceux qui sont prêts à commencer, Cloudflare a écrit un guide très pratique. Le site Web de GraphQL est également une excellente ressource. Nous vous recommandons d'utiliser un IDE comme GraphiQL pour exécuter vos requêtes. GraphiQL incorpore la documentation du schéma dans I'IDE, procède au remplissage automatique, enregistre vos requêtes et gère vos en-têtes personnalisés, ce qui contribue à faciliter l’expérience du développeur.
Conclusion
Maintenant que la solution Load Balancing Analytics est en service et disponible pour tous les clients Pro, Business, Enterprise, nous sommes ravis que vous commenciez à l'utiliser ! Nous avons joint un sondage à la page d’aperçu du trafic, et nous aimerions beaucoup recevoir votre avis.