Ivan Kruglov, développeur principal chez Booking.com, a parlé du SlOmer DevOps avec le thème SRE et, après avoir parlé, a accepté de parler de Kubernetes, Service Mesh, des solutions open source et «non standard» de Booking.com autour d'une tasse de café
Comme le sujet du SRE s'est avéré être beaucoup plus large, Ivan et son collègue Ben Tyler, développeur principal chez Booking.com, ont accepté de devenir les conférenciers de Slurm SRE, qui se tiendra du 3 au 5 février 2020 . Il abordera la théorie et la pratique de l'application du budget SLI / SLO / erreur, l'analyse post-mortem, l'élimination efficace des incidents informatiques, la construction de systèmes fiables (surveillance et alerte, dégradation gracieuse, injection-échec, planification des capacités, prévention des échecs en cascade) )
Et maintenant un mot à Ivan.
Quel a été pour vous un défi professionnel intéressant ces derniers temps?
Au cours des deux dernières années, j'ai fait deux choses. Premièrement: faire le cloud intérieur de Booking.com. Il est construit sur Kubernetes. À cette occasion, j'ai eu un rapport long et complet sur Highload.
Nous avons eu une façon longue et intéressante de construire notre cloud. Ceci est mon projet précédent, que j'ai laissé à un collègue.
Maintenant, je traite d'un sujet appelé Service Mesh. C'est, en fait, un sujet brûlant, comme l'étaient le Big Data et Kubernetes à une époque.
L'idée est, d'une part, simple, d'autre part, complexe - dans une architecture de microservices, toute l'interaction passe par le réseau, eh bien, c'est une sorte de partie intégrante des microservices. Et l'interaction elle-même est une opération complexe, beaucoup de choses peuvent mal se passer là-bas. Tout cela doit être contrôlé. En particulier, des restrictions sont imposées - si nous avons un monolithe et que deux fonctions fonctionnent et que ces deux fonctions peuvent se faire confiance, car elles font partie du même processus, alors maintenant, en théorie, les microservices ne peuvent pas se faire confiance.
Comment savez-vous d'où vient la demande? Voici un microservice, une requête HTTP vient à lui. Provenait-il vraiment du service dont je pense? Et de la même manière, le service demandé par un autre service. Je dois être sûr que le service que j'appelle est le service dont j'ai besoin, et non une sorte de faux. Dans les petites organisations, ce n'est probablement pas si vrai. Et dans les grandes, lorsque vous avez des milliers et des dizaines de milliers de voitures, vous ne suivrez pas chaque machine. Et pour les grandes entreprises, c'est un problème assez sérieux. Autrement dit, tout est construit avec une confiance zéro. Chaque fois que vous effectuez une communication, vous devez effectuer une vérification. Il s'avère qu'au niveau de l'interaction réseau il est nécessaire d'authentifier et d'autoriser l'opération. Ce sont tous des processus assez difficiles à mettre en œuvre. Et il s'avère que le Service Mesh assume ces tâches pour assurer une interaction sécurisée. Ce n'est là qu'une des fonctionnalités de Service Mesh. Il y a beaucoup plus - fiabilité, surveillance, traçage et autres.
Et pensez-vous que cette technologie est l'avenir?
Le service Mesh est une tendance qui se développe. Ceci est mon opinion personnelle. C'est déjà assez courant. Par exemple, il y a Istio. Puis dans les nuages, dans la même Amazonie, est apparu Service Mesh. Je pense que tous les principaux fournisseurs auront bientôt ou auront déjà un maillage de service à part entière.
Autrement dit, la même technologie révolutionnaire qu'elle était autrefois, et maintenant il y a Kubernetes?
Je pense que oui. Bien qu'il soit intéressant de noter ici qu'à mon avis, ni Kubernetes ni Service Mesh n'inventent quelque chose de nouveau. Kubernetes a pris une pile technologique existante et l'a automatisée. Service Mesh fait à peu près la même chose. Il donne de nouveaux outils sur une base existante. Envoy est apparu dans Service Mesh, que je vais démontrer aujourd'hui. (Remarque Ivan a abordé cette question dans un discours prononcé lors du Slurm DevOps intensive .) L'idée est que Service Mesh est un instrument de plus haut niveau qui vous permet d'orchestrer les communications d'une grande flotte de microservices. Je vais vous expliquer ... Pour démarrer l'architecture du microservice, vous avez d'abord besoin de ce que l'on appelle le runtime - c'est l'endroit où l'application sera lancée. C'est ce que fait Kubernetes. Service Mesh le complète, dans le sens où il fournit l'interaction entre ces microservices qui seront exécutés lors de l'exécution.
Allez-vous développer cette technologie dans un avenir proche?
Je peux parler pour moi. Je suis impliqué dans les infrastructures. Et en termes d'infrastructure, au cours des prochaines années, ce sera l'un des principaux sujets - Kubernetes et Service Mesh.
Vont-ils se développer en parallèle?
Certainement, car ils se complètent. Kubernetes exécute. Service Mesh offre une interopérabilité.
Plus précisément, Kubernetes possède certains composants qui semblent couvrir des aspects du Service Mesh. Mais dans Kubernetes, ils sont trop basiques. Autrement dit, Kubernetes, en termes de mise en réseau, ne vous offre qu'un réseau de bas niveau. Je veux dire, les paquets IP peuvent aller du point A au point B. C'est tout. D'accord, il y a des contrôleurs Ingress, il y a des moments de routage de niveau supérieur, c'est-à-dire non seulement une interaction réseau. Néanmoins, dans Kubernetes, par exemple, il n'y a pas de mécanismes intégrés pour garantir la fiabilité de l'exécution des requêtes. Un exemple très simple. Dans Kubernetes, si le «dessous» (Pod) tombe, Kubernetes le ramassera lui-même. Par défaut. Il s'agit d'un mécanisme de nouvelle tentative. Mais au niveau de l'interaction réseau, cela ne se produit pas. Autrement dit, si le service de la page principale envoie une demande au service de panier, et pour une raison quelconque, cela n'a pas fonctionné, la demande ne sera pas réessayée.
Le maillage de service à cet égard ajoute des fonctionnalités. Il permet, si la demande a échoué, de la répéter à nouveau. Il existe d'autres mécanismes tels que la détection des valeurs aberrantes. Si, par exemple, nous avons une flotte de "foyers" qui fonctionnent pour le service de la "page principale", et une flotte de "foyers" qui sont un service de "panier". S'ils sont géographiquement séparés, des choses peuvent apparaître en eux qu'une partie des «foyers» voit une partie des «foyers» et l'autre partie des «foyers» voit l'autre partie des «foyers». En conséquence, dans le maillage de service, il existe des mécanismes qui vous permettent de créer dynamiquement une image de qui est disponible pour tout le monde et de basculer entre eux - tout cela en temps réel. Et si l'un des «foyers» a trop de latence, jetez-le. Tout le monde «sous» peut décider qu'avec ce «foyer» ma conversation est lente - tout le monde est normal, et c'est lent - parce que je vais le jeter hors de ma piscine. C'est ainsi que fonctionne le mécanisme de détection des anomalies. Lorsque nous avons dix "foyers", neuf "foyers" fonctionnent sans erreur et le dixième envoie constamment des erreurs. Ou neuf «foyers» répondent avec une latence de 15 ms et un répond avec une latence de 400 ms. Et Service Mesh décide de le jeter.
Service Mesh vous permet également de collecter des statistiques côté client. Autrement dit, nous avons un client et nous avons un serveur. Habituellement, les statistiques sont collectées côté serveur. Eh bien, parce que c'est le plus simple. Nous voulons utiliser des métriques pour comprendre dans quelle mesure notre utilisateur interagit avec notre service. Par conséquent, en théorie, vous devez mesurer du côté client et non du côté serveur. Parce qu'il y a un grand écart entre eux, qui est rempli d'interactions réseau.
Chaque composant de cette variété peut échouer.
Et le Service Mesh est bon en ce qu'il met l'agent en arrière - et envoie des statistiques de deux côtés. Et des situations peuvent survenir lorsque du côté service, la latence est de 20 ms et du côté client 2 secondes. Par exemple, côté serveur, nous collectons des statistiques à partir d'un serveur Web, mais nous avons perdu 5% des paquets pour une raison quelconque. En conséquence, en raison de la retransmission dans la pile TCP, il s'avère que notre client voit la latence en 2 secondes. Et côté serveur, on constate toujours une excellente latence: comme tout a été envoyé au buffer, c'est tout! Je vais bien, j'ai une latence de 20 ms. Et à quoi ressemble le client?!
Et comment résolvez-vous cela?
Fondamentalement, cela est résolu par l'outillage client. Dans le bon sens, les statistiques doivent être collectées le plus près possible du client. Mais l'outillage client n'est pas toujours possible et pas toujours pratique.
Quelles sont les mesures de fiabilité et de disponibilité de votre entreprise?
Tout est en gros standard. Aujourd'hui j'en parlerai. (Remarque. Discours d'Ivan le troisième jour de Slurm DevOps ) Il y a cinq ou six indicateurs clés. Les soi-disant indicateurs de niveau de service: latence, durabilité, fraîcheur, justesse ... Lorsque je me préparais pour la présentation sur le Slurm, j'ai essayé de trouver des cas non standard sur Booking.com, des exemples SLI intéressants qui ne cadraient pas avec ce modèle. Parce que, en théorie, l'idée clé de SRE est basée sur une telle déclaration de haut niveau - nous devons mettre en évidence une métrique ou des métriques qui refléteraient l'expérience utilisateur. Et pour certains services, la latence, la durabilité conviennent, pour d'autres non. Et comment trouver ce point d'équilibre qui refléterait l'expérience utilisateur - c'est une tâche intéressante.
Quelles solutions uniques avez-vous trouvées sur Booking.com lorsque vous êtes venu travailler là-bas? Ou est-ce que tout est standard?
Non. Nous avons beaucoup de choses «non standard». Expliquons pourquoi ce n'est pas standard entre guillemets. D'où vient le non standard ... Le non standard vient souvent du fait que l'entreprise a rencontré un problème plus tôt que le marché, et donc il n'y a pas de solution «standard». À cet égard, Booking.com, étant une entreprise qui opère sur le marché depuis 1997 et a atteint une telle taille, a été confrontée à un certain nombre de problèmes qui n'ont pas été résolus.
Par exemple, Google. Selon mes observations, cela ressemble à ceci. A l'intérieur, ils font des développements majeurs, qui sont présentés en public en cinq ou dix ans. Par exemple, j'ai parlé avec les gars de Google qui ont corrigé le noyau Linux. Ensuite, j'ai eu certains problèmes dans la pile TCP. Je leur dis: «C'est clairement le problème central. Comment combattez-vous cela? " Ils disent: «Ah, nous avons donc un noyau corrigé. Ici, nous pouvons modifier le paramètre. En 2013, nous l'avons corrigé. Et nous ne faisons que le déployer en open-source en 2018. »
À peu près la même chose avec Service Mesh. Il est également construit à l'image de la technologie que Google utilise en interne. Mais ils ne le téléchargent pas directement en open source. Istio est essentiellement une réimplémentation open source de leur système interne. Avec Kubernetes également. À mon avis, c'est parce que lorsqu'une entreprise est pionnière, elle crée des solutions pour elle-même. Parce que c'est plus rapide, moins cher. L'open source coûte cher. Et peu importe qui dit que vous devez le diffuser, vous avez vraiment besoin de construire une communauté. Et pour construire une communauté, vous devez investir énormément d'efforts. Et c'est seulement alors que le retour vous reviendra. Il me semble que derrière toute «pharmacie» sérieuse, il y a une commercialisation encore plus sérieuse, dans laquelle l'argent est naturellement investi.
Pourquoi suis-je ... Comme je l'ai dit, lors de la résolution d'un problème, l'entreprise fait beaucoup pour elle-même. Et puis le mettre en open source est assez difficile. Vous devez couper la logique métier et un tas de petits détails. Nous avons notre propre service Service Mesh, notre propre système de surveillance. Et pour le diffuser en open source, il faut le refaire. La publication open source a ses avantages ...
Lequel, par exemple?
Marque technologique, fidélisation, intégration facilitée. Ils sont importants.
Vous ne pouvez pas les compter directement.
Oui, c'est vrai. Ne comptez pas directement. Il s'agit d'un investissement stratégique à long terme. Je ne suis pas pour ou contre l'open source. Vous devez être équilibré, évaluer ce que l'entreprise donne à la publication d'une technologie particulière. Équilibrer la stratégie à long terme et à court terme.
Pour en revenir à la question, combien est standard et non standard dans Booking.com. Je dirai ceci, non pas que la majorité n'est pas standard, mais beaucoup. Parce que nous résolvions des problèmes qui étaient encore inconnus sur le marché, ou d'autres entreprises n'étaient qu'au début du voyage. Rien que pour l'entreprise, il est plus simple et plus rapide de résoudre les problèmes par lui-même.
PS : Il n'est pas possible de couvrir tout le sujet du SRE dans une seule présentation. Il n'y a pas que des outils, il y a aussi la philosophie de l'approche. Par conséquent, nous avons mis en évidence tout un Slurm SRE intensif pour ce sujet , qui se tiendra du 3 au 5 février 2020 . Les conférenciers seront Ivan Kruglov, développeur principal chez Booking.com, son collègue Ben Tyler, développeur principal chez Booking.com, Eduard Medvedev , directeur technique chez Tungsten Labs, Eugene Varavva, développeur à profil large de Google.