Les exigences: avoir une solution pratique qui fonctionne pour le cloud ou tout type d'environnement où aucun accès aux équilibreurs de charge matérielle, aux protocoles BGP et tout le reste.
Le numéro de demande de revenu d'une application est inconnu mais devrait être suffisamment élevé pour répondre à une attente de charge accrue sans crainte.
Trouvons une application avec une nature de charge similaire, par exemple un magasin de journalisation et une application de recherche. J'en ai trouvé un .
Ce qu'ils veulent:
- Équilibrez la charge entre les capteurs
- Offrir une tolérance aux pannes, nous permettant de continuer à ingérer des données si l'un des collecteurs décède ou rencontre des problèmes
- Échelle horizontale avec la croissance de nos volumes de journaux
Qu'ont-ils essayé et appris sur ELB:
- Ne fonctionne pas comme prévu
- Problèmes de latence dus à une charge accrue
- Pas assez de surveillance
- Trop de limitations (nombre de ports et protocoles ouverts)
Pourquoi ont-ils choisi avec Route53:
- "Round robin est un équilibrage de charge assez basique, mais il fonctionne bien pour nous du point de vue de l'efficacité"
- "Nous profitons des contrôles de santé de basculement Route 53."
- "S'il y a un problème avec un collecteur, Route 53 le retire automatiquement du service; nos clients ne verront aucun impact."
- Aucun préchauffage requis avec Route 53
La route 53 s'est avérée être le meilleur moyen pour Loggly de tirer parti de nos collecteurs haute performance compte tenu de nos énormes volumes de journaux, de variations imprévisibles et de la croissance constante de notre entreprise. Cela correspond aux objectifs principaux des collecteurs: collecter des données à la vitesse de la ligne du réseau sans perte, et cela nous permet de bénéficier de l'élasticité de tous les services AWS que nous utilisons chez Loggly.
Cet exemple particulier montre que dans certains scénarios (collecteur de journaux, service d'annonces ou similaire), l'équilibreur de charge est redondant et que la «solution de round robin de contrôle de santé DNS» fait très bien son travail.
Voyons ce que AWS dit du basculement DNS:
Avec le basculement DNS, Route 53 peut détecter une panne de votre site Web et rediriger vos utilisateurs finaux vers des emplacements alternatifs ou de sauvegarde que vous spécifiez. Le basculement DNS de Route 53 s'appuie sur des vérifications de l'état - en effectuant régulièrement des requêtes Internet vers les points de terminaison de vos applications à partir de plusieurs emplacements à travers le monde - pour déterminer si chaque point de terminaison de votre application est actif ou non.
Cette technique rend également ELB (non requis, juste pour une note) plus robuste, encore une fois, il est basé sur RR + Health Check:
Le basculement DNS Route 53 gère tous ces scénarios de défaillance en s'intégrant à ELB en arrière-plan. Une fois activé, Route 53 configure et gère automatiquement les contrôles de santé pour les nœuds ELB individuels.
Voyons maintenant comment cela fonctionne en arrière-plan. La question évidente est de savoir comment gérer la mise en cache DNS:
Cependant, la mise en cache DNS peut toujours être un problème ici (voir notre article précédent où le problème de "longue queue" est couvert) si TTL n'est pas respecté par toutes les couches entre votre client et Route 53. Vous pouvez alors appliquer une technique de "cache busting": envoyer une demande à un domaine unique
("http://<unique-id>.<your-domain>")
et définir une ressource générique
Record "*.<your-domain>" to match it.
L'Algolie a introduit une "stratégie de relance client" qui fonctionne plutôt bien si votre client (JS dans votre cas) peut gérer cela:
Nous avons fini par mettre en œuvre une stratégie de nouvelle tentative de base dans nos clients API. Chaque client API a été développé pour pouvoir accéder à trois machines différentes. Trois enregistrements DNS différents représentaient chaque utilisateur: USERIDID-1.algolia.io, USERID-2.algolia.io etUSERID-3.algolia.io. Notre première implémentation a été de sélectionner au hasard l'un des enregistrements, puis de réessayer avec un autre en cas d'échec.