L'intégration s'est accompagnée d'une lutte avec littéralement chaque milliseconde de latence, d'une mise à niveau de l'infrastructure et du développement de technologies de diffusion de contenu, que nous avons dû trouver nous-mêmes. Nous vous disons ce que nous avons rencontré au cours du travail, ce qui s'est passé à la fin et pourquoi les utilisateurs en ont besoin.
Pourquoi intégrer le cloud avec CDN du tout
Tout d'abord, un cloud public est une capacité évolutive. Ils peuvent être utilisés de n'importe quelle manière: pour développer et tester des services, ainsi que pour stocker et traiter des données. Chez G-Core Labs, nous avons lancé le cloud l'année dernière et avons déjà réussi à l'utiliser dans des projets à forte charge. Par exemple, notre client de longue date - Wargaming - utilise cette solution pour plusieurs tâches à la fois:
- Test de nouvelles fonctionnalités et services de différents projets;
- Préparer des prototypes de test avec des développeurs externes qui ont besoin d'accéder à des ressources personnalisées et contrôlées isolées;
- Fonctionnement du jeu en ligne "Calibre" sur des machines virtuelles.
Le cloud fait face à tout ce qui précède avec brio, mais le travail ne s'arrête pas là. Quelle que soit l'utilisation de ces capacités ou de ces capacités, le résultat de leur travail doit encore être livré au point de destination. Qu'il s'agisse d'un jeu en ligne ou de véritables formations militaires, c'est là que se pose le problème: qu'il est extrêmement difficile de livrer rapidement des données lourdes à des régions éloignées avec des équipements militaires de plusieurs tonnes. Cette tâche peut être simplifiée en intégrant le cloud au réseau de diffusion de contenu. Avec l'aide du CDN, la partie transportable - les données statiques - peut être lancée «en l'air» directement vers le point de destination, et il ne reste plus qu'à envoyer des données dynamiques «surdimensionnées». Avec cette approche, vous pouvez commencer à travailler en toute sécurité, même sur d'autres continents, car l'intégration permet à des concurrents plus rapides de diffuser du contenu lourd dans le monde entier.
, , : CDN
Passons aux détails. Nous savons de première main qu'il faut beaucoup de temps pour fournir un contenu lourd aux régions éloignées directement à partir du cloud, et qu'il peut être coûteux d'augmenter constamment la capacité de l'infrastructure en fonction de l'augmentation de la charge. Heureusement, en plus du cloud public, nous nous sommes retrouvés avec notre propre CDN, qui est même entré dans le livre Guinness des records, offrant une expérience ininterrompue de jouer à World of Tanks pendant les périodes de pointe.
Pour faire d'une pierre deux coups, nous avons dû l'intégrer au nuage. Ensuite, nous serions en mesure d'offrir aux utilisateurs une solution qui serait moins chère que la mise à niveau de l'infrastructure et permettrait une livraison plus rapide des données dans les régions éloignées. Nous avons donc commencé la première phase de travail et résolu les principaux problèmes:
1. Les services cloud étaient sous une charge constante.Les utilisateurs de projets à forte charge demandaient régulièrement du contenu dans les clouds de nos clients. Cela a entraîné une charge élevée et un long retour de données. Il fallait une solution qui pourrait facilement réduire le nombre de références à la source. Pour ce faire, nous avons intégré des serveurs de cloud public et des serveurs de cache CDN, et également créé une interface unique pour la gestion de ces services. Avec son aide, les utilisateurs peuvent déplacer des données statiques vers les points de présence souhaités sur le réseau. Pour cette raison, les appels vers le cloud ne se produisent que sur les premières demandes de contenu. Il fonctionne de manière standard: CDN prend les données de la source et les envoie à l'utilisateur, ainsi qu'au serveur de cache le plus proche, d'où le contenu est distribué lors des demandes suivantes;
2. Les données ont été transférées pendant une longue période entre le cloud et le CDN.En combinant le cloud avec un réseau de diffusion de contenu, nous avons remarqué que la latence de diffusion des données pouvait être réduite. Pour économiser autant de précieuses millisecondes que possible, nous avons dû implémenter l'échange de trafic entre les serveurs de cache et le cloud au sein de la dorsale;
3. La charge sur la source était inégale. Même après avoir connecté le CDN, les appels restants vers le cloud ont été distribués de manière inefficace. Nous avons résolu ce problème avec les équilibreurs HTTP (S). Désormais, au moment de la demande de contenu, ils déterminent à partir de quelle source (machine virtuelle ou compartiment de stockage cloud) les données doivent être prises pour la mise en cache;
4. Un contenu lourd a mis beaucoup de temps à atteindre les utilisateurs.Pour réduire le temps d'attente, nous avons constamment augmenté la capacité et la géographie de la présence CDN. Désormais, les utilisateurs n'ont plus à attendre que le contenu les atteigne à l'autre bout du monde - au moment du contact, le réseau de diffusion de contenu sélectionne le plus proche des 100 points de présence sur les cinq continents. En conséquence, le temps de réponse moyen dans le monde est de moins de 30 ms.
Après avoir traité ces problèmes, nous avons déjà considéré le travail terminé. Mais le cloud avec CDN avait d'autres plans pour nous.
C'est ainsi que l'acier a été tempéré: nous modernisons l'infrastructure
À un moment donné, il est devenu clair que l'effet de tous nos efforts ne pouvait pas se manifester pleinement pendant que nous utilisions l'ancienne configuration matérielle. Pour que les serveurs et les applications hébergées sur eux fonctionnent mieux et que le contenu soit transféré plus rapidement, une mise à niveau de l'infrastructure était nécessaire. Les étoiles dans le ciel ont convergé plus tôt cette année: nous avons commencé la mise à niveau dès la sortie de la ligne de processeurs Intel Xeon Scalable de deuxième génération.
Maintenant, la configuration standard du serveur ressemble à ceci:
- Les services cloud fonctionnent sur les processeurs Intel Xeon Gold 6152, 6252 et 5220, ont jusqu'à 1 To de RAM, ainsi que SSD et HDD avec triple réplication;
- Les serveurs de cache CDN sont équipés d'Intel Xeon Platinum, de RAID virtuel sur CPU et de SSD D3-S4610.
À la suite de la mise à niveau, les performances ont tellement augmenté que nous avons abandonné certains serveurs et réduit le coût de leur fonctionnement. Il semblait que tout ce qui précède serait plus que suffisant pour le travail de tout projet. Mais une fois, cela ne suffisait pas.
Blindage, partitionnement et géo-distribution: accélération de la diffusion de contenu dans des conditions extrêmes
Le malheur ne vient jamais seul. Cela est particulièrement vrai lorsqu'il s'agit de projets mondiaux. Manque d'infrastructure répartie géographiquement, charges élevées dues à de nombreux utilisateurs du monde entier et à une mer de données hétérogènes dont ils ont besoin pour fournir rapidement - l'un de nos clients, une grande ressource multimédia, devait faire face à toutes ces complexités à la fois. Quelques détails:
- Le contenu a atteint les utilisateurs pendant une longue période, et parfois il ne les a pas du tout atteint en raison de retards importants et de problèmes de réseau. La difficulté était que tout le grand pool de serveurs avec des données était situé dans un point géographique;
- La source de contenu a été consultée par des utilisateurs du monde entier, ce qui a entraîné une augmentation de la charge sur l'infrastructure et conduit à un coût de maintenance élevé, ainsi qu'à une livraison lente des données;
- Les utilisateurs devaient fournir une énorme quantité de contenu constamment mis à jour, unique à chaque région.
Les capacités de base de l'intégration cloud avec CDN étaient ici indispensables. Nous avons commencé à développer des solutions supplémentaires.
Comment nous avons conçu le blindage régional
Nous avons introduit ce concept, et maintenant un service existant, spécifiquement pour résoudre le problème de l'éloignement de la source de contenu. En raison du fait que tous les serveurs du client étaient situés dans un point géographique, les données qui en provenaient ont mis beaucoup de temps à atteindre les utilisateurs de différentes parties du monde. La situation était compliquée par le fait que des contenus différents et constamment mis à jour devaient être diffusés dans différentes régions. Une simple mise en cache des données sur les serveurs de périphérie ne résoudrait pas le problème - ils accèderaient encore souvent à la source à l'autre bout du monde.
Nous avons résolu le problème en déployant un grand pool de serveurs de cache dans des points d'échange de trafic populaires sur différents continents. Les «blindages régionaux» sont devenus une sorte de couches entre les serveurs source et de périphérie dans les pays de l'utilisateur. Désormais, tout le contenu demandé dans les régions correspondantes du monde leur est d'abord tombé dessus, puis a été transféré vers les serveurs de cache. Ainsi, le blindage a réduit la charge sur la source du client à la fois et réduit les délais pour les utilisateurs finaux. Le client, à son tour, économisait sur l'hébergement de plusieurs pools de serveurs avec le même contenu dans différentes parties du monde, car avec ce principe de travail, une source de données suffisait.
Pourquoi avez-vous besoin d'un partage de contenu
Les blindages régionaux ont résolu le problème de la livraison à long terme de contenu dans différentes parties du monde. Cependant, maintenant une nouvelle difficulté est apparue: comme le client avait beaucoup de données et qu'il était constamment mis à jour, il ne se retrouvait pas dans le cache des serveurs périphériques auxquels les utilisateurs accédaient. Cela a conduit au fait qu'une masse de requêtes provenant de serveurs de cache tombait constamment sur des pools régionaux, dont le nombre dans un groupe atteignait 20 à 30 pièces. Pour supprimer une partie de cette charge des boucliers et fournir du contenu aux utilisateurs encore plus rapidement, nous avons ajouté la possibilité de récupérer les données nécessaires du serveur périphérique le plus proche du pool.
Désormais, les serveurs de cache dans les régions de présence ont commencé à accéder aux boucliers uniquement lorsque les données n'étaient pas disponibles dans tout le groupe. De plus, même dans ces cas, le contenu était immédiatement demandé au serveur qui le contenait - grâce au sharding, les serveurs de périphérie «savaient» à l'avance où se trouvait un fichier spécifique et n'ont pas interrogé l'ensemble du pool de boucliers régionaux pour cela. Ce principe de fonctionnement réduisait le nombre de requêtes vers le pool et permettait de distribuer efficacement le contenu à travers celui-ci au lieu de stocker des copies des données sur chaque serveur. En conséquence, les boucliers contenaient plus de contenu et, par conséquent, mettaient moins de pression sur la source du client.
La création d'une telle infrastructure ne peut qu'entraîner une difficulté de plus. Compte tenu du nombre de serveurs de cache dans les groupes, il serait ridicule de supposer qu'aucun d'entre eux ne peut échouer. Dans une telle situation, comme dans le cas de l'ajout d'un nouveau serveur au pool, le cache des groupes devait être redistribué de manière optimale. Pour ce faire, nous avons implémenté l'organisation d'un cache sharded avec un algorithme de hachage cohérent dans le bloc amont de nginx:
upstream cache_servers {
hash $cache_key consistent;
server edge1.dc1.gcorelabs.com;
server edge2.dc1.gcorelabs.com;
server edge3.dc1.gcorelabs.com;
}
L'apparition de serveurs indisponibles dans le pool posait également un autre problème: d'autres serveurs continuaient à leur envoyer des requêtes et attendaient une réponse. Pour se débarrasser de ce délai, nous avons écrit un algorithme de détection de tels serveurs dans le pool. Désormais, du fait qu'ils sont automatiquement transférés à l'état down dans le groupe en amont, nous ne faisons plus référence aux serveurs inactifs et n'attendons plus de données de leur part.
Grâce à ces travaux, nous avons réduit le coût des services pour le client, lui avons épargné les coûts importants d'organisation de sa propre infrastructure et accéléré considérablement la livraison des données aux utilisateurs, malgré toutes les difficultés.
Qui a besoin d'un cloud avec CDN
Le travail d'intégration est terminé et nos clients utilisent déjà le produit. Nous partageons lequel d'entre eux en tire le meilleur parti.
Disons tout de suite que la solution n'était pas utile à tout le monde. Nous ne nous attendions à rien d'autre: pour certains, seuls le stockage et les machines virtuelles suffisent, et pour d'autres - les réseaux de diffusion de contenu. Par exemple, lorsque toute l'audience d'un projet se trouve dans la même région, il n'est pratiquement pas nécessaire de connecter le CDN au cloud. Pour minimiser les délais, dans ce cas, un serveur situé non loin des utilisateurs suffira.
L'intégration se révèle dans toute sa splendeur lorsque vous devez rapidement et loin donner du contenu lourd à un grand nombre d'utilisateurs. Voici quelques exemples de la façon dont un cloud avec CDN aide différents projets:
- Les services de streaming qui sont essentiels à la latence et à la mise en mémoire tampon garantissent un fonctionnement stable et des diffusions de haute qualité;
- Les services de divertissement en ligne fournissent des jeux lourds dans différentes parties du monde plus rapidement et réduisent la charge sur les serveurs, y compris aux pics de charge;
- Les projets multimédias accélèrent les temps de chargement des annonces et restent accessibles lorsque le trafic augmente;
- Les magasins en ligne se chargent plus rapidement dans différents pays, y compris pendant les promotions et les soldes.
Nous continuons à voir exactement comment ils utilisent le cloud avec CDN. Comme vous, nous nous intéressons aux chiffres: à quel point la charge sur l'infrastructure est réduite, à quelle vitesse les utilisateurs reçoivent du contenu dans des régions spécifiques et à quel point l'intégration permet d'économiser de l'argent. Nous partagerons tout cela dans de futurs cas.