Gestion des risques dans l'infrastructure en nuage – Bien choisir son serveur d impression

Transcription

Butler-Cole: L'un des thèmes de cette piste de la conférence est l'atténuation des risques et en particulier la manière dont la responsabilité de l'atténuation des risques est transférée entre les fournisseurs de services et leurs consommateurs dans les systèmes informatiques modernes.

Un des principaux exemples de ceci est le cloud public, et ce qui se passe lorsque les utilisateurs utilisent des services de cloud public, c’est qu’ils transfèrent aux fournisseurs de cloud public le risque de devoir atténuer certains des risques d’infrastructure liés à la sous-traitance, Les fournisseurs de services d'informatique en nuage assument donc la responsabilité de la planification de la capacité, du matériel et de la gestion, de l'exécution des centres de données et de certains des risques de sécurité.

Les fournisseurs de cloud offrent à leur tour une partie de ce risque aux fournisseurs de leurs propres fournisseurs de matériel ou il est à noter que bon nombre des grands fournisseurs de nuage fabriquent maintenant de plus en plus de leur propre matériel à mesure que leurs besoins se spécialisent et une échelle de plus en plus grande. Nous reviendrons sur ce thème, celui des entreprises qui conservent des risques qui sont au cœur de leur activité ou qui revêtent une importance particulière pour elles.

En fin de compte, les fournisseurs de matériel informatique délèguent aux physiciens de Quantum le risque de s’assurer que les composants continueront à fonctionner de la manière qu’ils devraient. Les entreprises qui utilisent les fournisseurs de cloud ont leurs propres clients qui leur assument une partie de leurs risques. Il existe donc toute une chaîne de délégation de risques dans laquelle différents types de risques sont transférés et atténués ultérieurement. date, le point le plus bas de la chaîne.

Neo4j

Je travaille pour Neo4j, la société à l'origine de la base de données de graphes open source Neo4j. Actuellement, Neo4j n’est disponible que sous forme de logiciel rétractable que vous pouvez télécharger et installer vous-même sur votre propre service en exécutant une équipe créant une nouvelle base de données en tant que produit de service au-dessus de Neo4j, de sorte qu’une fois ce produit disponible, au lieu de l’installer vous-même. Je ne peux que visiter notre site Web, utiliser une carte de crédit et commencer à utiliser la base de données.

Ce rôle nous place carrément au centre de cette chaîne de délégation de risques. Nous acceptons le risque de la part de nos clients pour les opérations de la base de données et nous assumons la responsabilité de les atténuer, puis nous transférons aux fournisseurs d'informatique en nuage certains des risques liés à l'infrastructure. Très tôt dans la construction du système, nous avons décidé de ne pas utiliser de matériel alternatif que nous allions déléguer aux fournisseurs de Cloud publics, ce qui nous priverait. Nous utilisons d’autres fournisseurs, voire d’autres services externes, le cas échéant.

Dans cette session, je parlerai des décisions architecturales et de produits que nous avons prises lors de la construction de ce système à la lumière de ce modèle de délégation des risques. En particulier, je vais parler de notre utilisation de Kubernetes et de la façon dont nous avons choisi de l’utiliser, ainsi que des raisons pour lesquelles et de l’utilisation que nous en faisons. Ceci est une vue d'ensemble de l'ensemble de notre système jusqu'à un utilisateur final qui n'est pas visible pour nous et qui utilise le service fourni par nos consommateurs. Le service clé que nous fournissons à nos clients est la possibilité d’utiliser une base de données, une base de données de graphes sans l’avoir à les exploiter. Ainsi, ils bénéficient des avantages du stockage et récupèrent leurs informations sans l’effort de les exploiter.

La raison pour laquelle ils veulent faire cela est parce que faire fonctionner des bases de données est difficile principalement parce que cela concerne State et que State est délicat dans les systèmes informatiques. L'installation d'une base de données a tendance à être relativement simple si vous avez de la chance, mais le faire fonctionner de manière particulièrement fiable malgré les défaillances devient un problème difficile. Ce problème difficile ne concerne pas les entreprises que nos consommateurs essaient de gérer, ils ont d'autres fonctions et sont donc très heureux de nous transférer le risque de gérer la base de données. Ils conservent le risque de la modélisation des données, de la création de requêtes à exécuter sur cette base de données, et cetera. En effet, ces requêtes et le modèle de données sont intimement liés aux activités que nos consommateurs tentent d'exécuter. C'est donc un autre exemple d'entreprise sur le risque qui est au cœur de leur entreprise.

Conserver les risques spécialisés ou essentiels à l'entreprise

C’est un thème que nous verrons maintes fois et que les entreprises choisiront de conserver et d’atténuer les risques qui sont au cœur de leurs activités ou qui disposent de connaissances ou d’informations spécialisées leur permettant de les atténuer efficacement. Le fait est que les influenceurs peuvent changer au fil du temps. Nous verrons des exemples de lieux où le bon endroit pour atténuer les risques et ce qui est considéré comme essentiel pour l'entreprise peuvent changer avec le temps. Par exemple, la sauvegarde des bases de données de nos clients n’est pas essentielle à leur activité et ils sont donc ravis de nous déléguer cette tâche, mais notre spécialité consiste à exploiter des bases de données. Nous sommes donc très heureux d’assumer la responsabilité de nos clients en matière de réduction des risques. .

Voici un exemple de ce dont nous sommes très heureux, ce schéma montre la mise à niveau d'un cluster d'instances Neo4j de la version un du logiciel à la version deux. Dans un service en cluster, vous souhaitez pouvoir effectuer ce processus de mise à niveau sans interruption et avec la sécurité des données afin de vous assurer que vous ne perdrez aucune donnée pendant que vous le faites et que vous souhaitez que tout cela fonctionne sans heurts. le visage des échecs, même pendant le processus de mise à niveau.

Premièrement, il est difficile de concevoir le processus proprement dit. Ce n'est pas un problème trivial, l'informatique distribuée est difficile, et donc concevoir simplement le processus correct pour mettre à niveau ce système peut s'avérer complexe. En fait, il est suffisamment complexe pour que nous utilisions une version simplifiée de ce sujet comme sujet de discussion dans nos entretiens et nous recrutons. Si ce type de réflexion vous passionne, nous serions très heureux de vous entendre. Cependant, bien que ce soit une tâche difficile à concevoir, c'est notre expertise interne, nous avons construit le système de clustering et nous avons l'expertise nécessaire pour concevoir ce processus. L'autre chose qui rend cela coûteux est le coût d'ingénierie et d'automatisation de ce processus. S'agit-il d'un effort d'ingénierie important, compte tenu en particulier de toute la tolérance de panne nécessaire? L’automatisation de ce travail demande en réalité beaucoup de travail. Si vous ne gérez qu’une ou deux bases de données, il vous en coûtera probablement plus que ce qu’il en vaut la peine de dire, et vous vous retrouvez avec un processus essentiellement manuel. Résultat, il peut être très sujet aux erreurs. Pour nous, cependant, nous pouvons amortir ce coût d'automatisation sur de nombreux consommateurs et il devient donc efficace pour nous de mettre en place des processus d'automatisation très sophistiqués pour exécuter des tâches telles que les mises à niveau de notre service.

Un autre exemple est la sauvegarde. La sauvegarde est beaucoup plus simple en ce qui concerne le type d'opérations requises, mais elle est absolument essentielle au succès de la base de données, car elle est essentielle à la sécurité des données. Neo4j dispose d’une fonction de sauvegarde à distance en ligne qui minimise l’impact du processus de sauvegarde sur le cluster en cours d’exécution. L'automatisation est très simple, mais vous devez prévoir un serveur supplémentaire situé en dehors de votre cluster. Ce serveur doit être d'une taille similaire à celle des machines que vous exécutez déjà dans votre cluster. Cependant, la plupart du temps, ce serveur sera amusé parce que vous exécutez déjà une sauvegarde, par exemple une fois par jour. Il est donc très coûteux de disposer de ce serveur supplémentaire. Cependant, nous pouvons amortir le coût de ce serveur ou le temps passé parce que nous avons de nombreux clients. Ainsi, nous pouvons maintenir notre service de sauvegarde à jour, ce qui nous permet d’agir plus efficacement.

Atténuation efficace

Nous avons vu que trois choses peuvent rendre efficace votre prise de risque et la responsabilité de l'atténuer. Premièrement, la concentration d'expertise ou d'informations, deuxièmement, les économies d'échelle, la possibilité d'amortir sur plusieurs consommateurs et, troisièmement, le lissage temporel ou la capacité d'amortir les coûts dans le temps. Je pense que ce type d'analyse est un moyen de repérer une entreprise viable en informatique. Vous recherchez des risques minimes que vous êtes bien placé pour atténuer et que vos clients potentiels sont heureux de vous transmettre. La valeur des activités que vous développez correspond exactement à la valeur que vos clients attachent à ce que ces risques soient atténués par quelqu'un d'autre.

Les services externes que nous utilisons ne sont pas seulement le fournisseur de services cloud, nous utilisons également Datadog en tant que service métrique, nous utilisons Auth0 pour l'authentification afin de leur laisser le risque de mettre en œuvre correctement les sous-systèmes d'authentification et Stripe que nous utilisons comme crédit. fournisseur de paiement par carte. Les paiements par carte de crédit entraînent d'énormes risques pour des raisons financières et réglementaires. Il sera très difficile pour nous de mettre en œuvre les travaux nécessaires pour atténuer ces risques, mais pour Stripe, ils en ont fait une entreprise. Ils ont des économies d’échelle, ils ont une expertise qui leur permet de le faire efficacement et nos fournisseurs, bien sûr, gèrent les risques, certains de ces risques pour les fournisseurs eux-mêmes.

Mouvement de risque

Un autre thème est que le meilleur endroit pour atténuer les risques peut changer avec le temps, à mesure que la balance des coûts et l'expertise disponible changent. J'ai déjà parlé des fournisseurs d'informatique en nuage qui construisent certains de leurs propres matériels et nous prévoyons peut-être déménager, ramener à notre entreprise certaines des choses que nous externalisons actuellement, par exemple, Datadog est très coûteux, donc peut-être Lorsque nous en arrivons à une sorte d’optimisation des coûts du projet, nous souhaitons l’intégrer à l’interne et gérer nous-mêmes l’infrastructure de métriques.

Kubernetes

Pour parler de quelque chose de légèrement différent, je veux parler de Kubernetes à propos de notre utilisation, en particulier de la façon dont nous avons décidé de l’utiliser dans le processus que nous avons suivi. Notre utilisation de Kubernetes n'est pas remarquable en soi, Kubernetes est maintenant largement déployé. Ce qui est remarquable, c’est que nous l’utilisons pour créer un service de base de données qui est un système avec état et ils le voient un peu inhabituel. En fait, lorsque nous avons commencé à penser à l’utilisation de Kubernetes pour construire ce système, Kelsey Hightower a récemment donné une conférence dans laquelle il a déclaré: "La plupart des gens sont très enthousiastes à l'idée de gérer une base de données à l'intérieur de Kubernetes. votre travail, garanti. " donc cela nous a donné une pause comme vous pouvez l’imaginer. Depuis lors, sa position s’est peut-être adoucie et soudainement devenue plus nuancée au fil du temps. On peut donc actuellement résumer sa position avec le son de Twitter: "Kubernetes soutient les charges de travail apatrides, pas moi." et son point est qu'il dit que Kubernetes ne résout qu'une partie du problème. Les autres parties doivent être résolues par le service Stateful et par une expérience opérationnelle.

Kubernetes, si vous construisez un système Stateful ne vous donne rien gratuitement, vous devez tout de même disposer de l'expertise nécessaire pour exploiter la base de données, par exemple en dehors de Kubernetes, mais il est possible si vous avez cette expertise pour l'exploiter dans Kubernetes. . Nous envisagions d'utiliser Kubernetes comme base de toutes les bases de données en tant que service, malgré les avertissements de cessation de carrière de Kelsey Hightower. Pourquoi était-ce? C’est parce que pour revenir à ce point, j’étais en train de dire que les problèmes difficiles pour lesquels nous possédons l’expertise opérationnelle devaient être résolus de toute façon, où que nous construisions, nous devions construire, concevoir ces systèmes complexes pour effectuer des mises à niveau. .

Kubernetes, bien que cela ne puisse pas nous aider avec les éléments très difficiles de notre système, il pourrait nous aider avec les éléments les plus simples et laisser plus d’énergie disponible pour résoudre les problèmes difficiles. D'autre part, nous étions à peu près certains que si Kubernetes ne soutenait pas très bien les systèmes Stateful il y a quelques années, que les choses évoluaient dans cette direction et que, lorsque nous aurions terminé, Kubernetes aurait peut-être rattrapé nous que le support pour les systèmes avec état aurait été amélioré. J'ai construit mon premier système basé sur des conteneurs vers 2011, je construisais un logiciel en tant que version de service d'une application Web Java, une application Web à locataire unique, c'était un outil de gestion de projet. Nous avons pris l'application Web Java et nous l'avons collée dans des conteneurs afin de la rendre multi-locataire pour ce système SaaS. C’était avant Docker, nous l’avons donc construit à l’aide de conteneurs LXC nus et, je ne sais pas si l’un d’entre vous se souvient de LXC, j’ai passé plus de temps que je ne me soucie de me souvenir des querelles IP, de la définition des réseaux de passerelles et de ma main sale .

Je me souviens avoir pensé à l'époque que cette technologie était prometteuse, qu'elle aidait un peu, mais qu'il y avait sûrement une meilleure solution. À peu près au moment où nous avons fini de construire ce système, le mettre en production, Docker a été libéré. Nous avons appris qu'il y avait effectivement une meilleure façon de faire les choses afin que vous n'ayez pas à vous salir les mains ou du moins, disons, que des personnes intelligentes de dotCloud se salissent à votre place. J'ai déjà vu la technologie des conteneurs garder le fil de ce que j'essayais de faire une fois auparavant et je me sentais raisonnablement confiant que cela allait se reproduire.

Transférer les risques pour notre avenir

Un autre thème ici est que parfois, plutôt que de confier l'atténuation des risques à quelqu'un d'autre, vous pouvez le confier à votre avenir. Vous faites un pari pour que votre futur individu vive dans un monde où l'atténuation des risques sera moins chère qu'aujourd'hui. Nous pensions que Kubernetes pourrait être utile, mais nous avions des réserves fondées sur l'expérience de personnes qui le connaissaient mieux que nous, et nous n'avions aucune expérience d'utilisation. Nous voulions avoir plus d'informations, c'était pour décider si cela nous convenait et nous avons décidé de le faire en s'attaquant aux problèmes difficiles et en l'utilisant aujourd'hui pour mettre en place un système simple et en nous demandant ensuite s'il allait le devenir. être la bonne solution pour exécuter nos bases de données réelles.

Ceci est une vue d'ensemble de très haut niveau de l'architecture de notre système. Au niveau de l'interface, nous avons une application destinée aux utilisateurs finaux que nous avons appelée console. Il s'agit d'une application JavaScript d'une seule page avec un service Web de serveur Python assis derrière elle et qui exécute son état en le maintenant dans une base de données qui réside en dehors de Kubernetes. . Derrière cela se trouve le gestionnaire de base de données, qui est responsable de la gestion des bases de données. Le domaine est complexe, mais l'architecture est très simple: il s'agit simplement d'une autre application Web Python qui expose une API à utiliser par la console, et enfin, à l'arrière-plan. , sont les bases de données Neo4j elles-mêmes. Neo4j fonctionne selon deux modes: vous pouvez l'exécuter en mode instance unique ou en clusters pour améliorer la disponibilité et la tolérance aux pannes. Les instances uniques sont très simples sur le plan opérationnel et les clusters, comme vous pouvez l'imaginer, sont plus complexes sur le plan opérationnel.

Nous avons décidé de lancer ces applications simples et sans état à l'avant de notre système pour construire celles-ci sur Kubernetes depuis le tout début afin de nous donner l'occasion d'apprendre Kubernetes en direct, en exécutant un système approprié pour nous donner les informations nécessaires à la décision. que nous voulions plus tard utiliser les bases de données sur le serveur principal de Kubernetes et laisser l'instance unique Neo4j s'exécuter sur EC2 en utilisant EBS comme mécanisme de persistance.

Pour un système, le simple Kubernetes est excessif, je ne pense pas que cela justifierait l’effort nécessaire pour apprendre le Kubernetes et tout implémenter au-dessus de celui-ci simplement pour pouvoir exécuter deux applications Web relativement simples sans état. Pour nous, cet investissement d'efforts en valait la peine, car il nous fournissait les informations, les informations que nous allions avoir sur le choix de savoir si c'était la bonne décision à prendre plus tôt pour Kubernetes et nous donnait également l'occasion d'apprendre un peu pendant que le monde se rattrapait.

GKE

Ce coût en valait la peine si nous n'avions pas à apprendre à gérer Kubernetes lui-même. Nous devons trouver un service hébergé parce que faire fonctionner Kubernetes est une tâche compliquée, qui demande beaucoup d’efforts et c’était un signe que nous voulions investir dans l’apprentissage avant même de savoir avec certitude si c’était la fonctionnalité de notre système. si nous pouvions trouver un service hébergé et que nous choisissions d'utiliser les nuages ​​Google, GKE, qui est un service Kubernetes hébergé.

À une époque où nous commençions cela, GKE était, je pense, le seul service Kubernetes hébergé prêt pour la production viable, Azure et AWS ont maintenant leurs propres qualités, mais nous avons décidé d'utiliser GKE car il était déjà prêt pour la production. Ceci s'intitule AWS, pays dans lequel nous travaillons actuellement et où nous possédons l'essentiel de notre expertise dans l'équipe sur le cloud Google. Ce n’est pas le discours d’AWS comparé à celui de Google Cloud, mais j’ai beaucoup d’avis à ce sujet, donc si quelqu'un veut essayer de me prendre dans un couloir, je serais très heureux de continuer. le bus très long. Mais il suffisait de dire que nous étions satisfaits de notre expérience d’utilisation de GCP.

Avec le risque de donner des détails à ma propre histoire, nous avons utilisé Kubernetes et nous avons aimé ce que nous avons découvert. Nous avons donc décidé non seulement de construire notre système sur Kubernetes, mais également d’utiliser les modèles architecturaux fournis par Kubernetes comme base de l’architecture. de tout notre système.

La première mise en œuvre de notre système exécutant une instance unique Neo4j était très impérative, à la suite de ce que Martin Fowler appelle le modèle de script de transaction. Je ferai juste un petit détour pour expliquer comment nous avons procédé à la construction du système. Nous avons commencé quand il n'y avait que moi dans l'équipe et je n'ai même pas encore caché personne. La première chose que j'ai faite, c’est que j’ai installé Neo4j sur ces deux instances, puis je les ai raillées à l’intérieur de la société avec Neo4j et leur ai dit: «Cette base de données est un service sur lequel je travaille, c’est gentil. de fait. Quelqu'un veut essayer? " Je fournissais cela en tant que service interne, puis à quelques personnes extérieures, et cela ressemblait un peu à de la fumée et à un miroir reflétant la manière dont Martin faisait tout ce qui était castor pour faire tourner la chose. Puis, au fil du temps, nous avons eu quelques personnes et nous avons automatisé de plus en plus de ce système et nous avons ajouté la surveillance et ajouté des fonctionnalités jusqu'à ce que nous ayons un système entièrement opérationnel, mais nous l'avons maintenu en vie tout le temps, nous n'avons jamais arrêté le système pendant que nous étions. le développer. Effectivement, nous sommes entrés en production avant d'avoir écrit une seule ligne de code, ce qui nous a permis de réduire le risque d'apprendre à utiliser le système en production et d'intégrer le code au fur et à mesure que nous apprenions tout ce que nous apprenions sur fonctionnement du système.

Cette approche de script de transaction était en réalité une traduction directe en code si les opérations manuelles que vous exécutez ont créé la base de données, voici les étapes, mettez à niveau la base de données, voici les étapes. Cela a bien fonctionné pour nous lorsque le système est assez simple, mais cela a commencé lorsque nous avons commencé à montrer une certaine faiblesse. En premier lieu, dans la gestion des erreurs, vous pouvez probablement imaginer le système comme celui-ci, qui coordonne les instances EC2, diverses autres ressources externes, les entrées DNS, chaque ligne de code étant en quelque sorte un appel au service distant qui peut échouer et qui est presque certainement côté effet, la manipulation eError dans ce scénario est difficile. Nous avons constaté dans ces scripts de transaction que nous devions prendre des décisions spéciales pour chaque ligne sur ce que nous ferions en cas d'échec. Pouvons-nous réessayer, pouvons-nous abandonner, devons-nous annuler les étapes précédentes, etc.? Cela devient extrêmement complexe avec le temps.

Deuxièmement, nous sommes sur le point de construire le système pour qu’il puisse récupérer des erreurs et avec cette approche, chaque type d’échec devait avoir son propre script indiquant au système comment le récupérer. Lorsque nous avons commencé à faire évoluer le système et que nous avions hâte d'utiliser des grappes dans lesquelles tout deviendrait un peu plus complexe, nous avons décidé que ces conceptions n'étaient pas viables à long terme. Nous avons donc examiné de près et nous avons réfléchi à une autre solution. approche. Nous avons mis au point un modèle que nous avons appelé modèle de rapprochement. Ainsi, dans ce modèle, plutôt que d'avoir des scripts de transaction, vous disposez d'un système d'enregistrement qui vous rappelle peut-être que vous souhaitez que cette base de données existe. Vous avez un processus appelé processus de rapprochement ou réconciliateur qui examine le système d’enregistrement, examine ce qui existe et exécute un processus de rapprochement entre les deux en apportant de petites modifications à leur état actuel afin de le mettre en conformité avec l'état défini du système.

Comme exemple de la façon dont cela fonctionne, le processus de création d’une base de données que vous entrez dans le système d’enregistrement, le processus de rapprochement voit cet enregistrement, il sait que trois instances de base de données devraient être exécutées dans un cluster et qu’il n’y en a aucun. ainsi, il crée une instance, puis se met en veille, puis se réveille à nouveau et il voit que cette base de données doit comporter trois instances, mais n'en a qu'une, de sorte qu'elle en crée une autre et ainsi de suite jusqu'à ce que l'ensemble du cluster soit en cours d'exécution.

Un autre exemple, la guérison d'un cluster, voici donc un cluster qui fonctionne bien. Nous perdons l'une des instances de ce cluster, le processus de réconciliation voit que la base de données doit exister, qu'elle doit avoir trois instances et ajoute donc une autre pour soigner le cluster. Vous avez tous remarqué que l'étape perdue dans ces deux processus est absolument identique et vous aimeriez donc une légère simplification. Vous bénéficiez de la guérison gratuitement car vous avez mis en œuvre le rapprochement de cette manière et cela ne se répercute pas uniquement dans la création. de vos instances, mais dans tout le système. La guérison ne vient pas tout à fait gratuitement, mais au moins elle émerge naturellement de la conception du système plutôt que de devoir être spécialement prise en charge. Ainsi, au lieu d’avoir un système impératif, nous en avons un qui est déclaratif, convergent et apatride.

Bien sûr, il y a des coûts à cela, cela rend le système plus découplé, mais nous pensions que ces coûts en valaient la peine et nous aimions cette idée, mais c'était un gros changement et c'est un gros risque que nous prenons le type d'architecture fondamentale de notre système était quelque chose de nouveau et nous n'étions au courant d'aucun exemple. Nous recherchions d'autres systèmes qui fonctionnaient de la sorte et nous n'en trouvions aucun. Ceux d'entre vous, si quelqu'un sait quelque chose sur les éléments internes de Kubernetes, vous pourrez voir où l'histoire va se dérouler. Nous avions appris un peu plus sur Kubernetes à ce stade et nous avons aimé ce que nous avons vu et nous nous sommes dit: "Waouh, le problème que nous voulons résoudre ressemble à ce que Kubernetes est en train de faire." et ainsi nous avons levé le couvercle sur Kubernetes, nous avons vérifié le code et commencé à lire le code et c’est exactement comment Kubernetes fonctionne.

Kubernetes a ce modèle de données riche, les conteneurs sont encapsulés dans des pods qui forment un ReplicaSets qui forme des déploiements. Cela vous permet de définir à l'aide de ce modèle très très abstrait, il vous permet de définir l'architecture de votre système. Chacune de ces différentes ressources dans Kubernetes a quelque chose que Kubernetes appelle un contrôleur et ces contrôleurs sont exactement les réconciliateurs de l'approche de réconciliation que nous proposons. Par exemple, le contrôleur ReplicaSet examine le système d’enregistrement pour vérifier que ReplicaSet doit exister. Il examine les pods enregistrés qui sont en cours d'exécution sur le système et les crée ou les détruit sous forme d'impression brillante. Le réconciliateur de déploiement procède de manière similaire dans sa manipulation de ReplicaSets.

Cela nous a donné l'assurance que nous cherchions sur la bonne voie. De plus, nous avons découvert que Kubernetes expose le mécanisme vous permettant de définir vos propres ressources et contrôleurs personnalisés. Il s’agit du modèle de l’opérateur Kubernetes. Vous pouvez utiliser ce modèle lorsque le modèle fourni par Kubernetes ne contient pas exactement ce que vous recherchez, notamment lorsque vous devez implémenter une logique personnalisée lorsque vous apportez des modifications au système. Vous pouvez créer ce que l'on appelle un opérateur et le connecter à Kubernetes. et vous bénéficiez de toutes les fonctionnalités fournies par Kubernetes pour activer ce modèle et vous pouvez l'utiliser pour votre propre code.

Forts de cette sympathie pour l’approche que nous voulions partager avec notre expérience d’utilisation de Kubernetes dans la production pour le cas simple et l’excellence de GKE, nous nous sommes alors montrés très heureux d’aller de l’avant vers Kubernetes. La semaine dernière, nous venons de terminer la migration de notre système des systèmes EC2 à instance unique vers ces bases de données en cluster exécutées sur Kubernetes. Nous avons donc découvert le risque non seulement lié au risque opérationnel lié à GKE, mais également à l'équipe de développement de Kubernetes certains des risques de le choix de l'architecture pour notre système.

Rejet du risque

Une autre chose qui se produit souvent dans ces chaînes de délégation de risque est le risque d'être rejeté. Parfois, les fournisseurs rejettent le risque, le répercutent sur leurs consommateurs s'il s'avère qu'en réalité, il serait moins coûteux pour les consommateurs d'atténuer ces risques, après tout. Cela se produit en particulier lorsque des informations ou des informations indiquant que le consommateur a entre les mains sont inaccessibles aux fournisseurs. Dans ce cas, est-ce que ce type de rejet du risque dans notre système? Eh bien, les fournisseurs de cloud prennent beaucoup de risques mais ils en rejettent une partie.

Si vous appelez l'API pour créer un EVM, cet appel peut échouer. S'ils ne peuvent pas fournir, ils n'ont pas assez de capacité matérielle pour exécuter la machine virtuelle que vous leur demandez, ils diront: "Non, je ne peux pas le faire." C'est votre problème, et ils rejettent ce risque pour vous. Un exemple plus intéressant est le cas de défaillance de machine virtuelle et de la façon dont les systèmes traitent cette situation et cela a considérablement changé avec le temps. Par conséquent, les premières versions d'EC2, si le matériel souligne votre machine virtuelle défaillante, votre instance EC2 s'évaporerait comme cela et vous deviez concevoir votre système. ce risque était rejeté, vous devez construire votre système pour y faire face, car les fournisseurs de cloud ne disposaient pas de suffisamment d'informations pour pouvoir le faire avec précision. Au fil du temps, EC2 a émis des avertissements et la possibilité de migrer votre machine virtuelle du matériel défaillant en l’arrêtant puis en le redémarrant. Enfin, ils ont implémenté une fonctionnalité leur permettant de configurer automatiquement le système. vos ordinateurs virtuels se sont éloignés du matériel défaillant simplement en étant arrêtés et redémarrés avec une courte interruption.

Tous les systèmes fonctionnant sur EC2 profitaient de cela et nous voyions parfois des pannes de nos bases de données car elles étaient arrêtées et redémarrées sur un matériel différent. Nous pensions que tout allait bien, puis nous avons eu un mauvais mois avec EC2. Nous avons eu un taux d'échec de 5% de nos instances EC2 en août, ce qui nous a semblé absurde. Notre système pouvait y faire face, mais il me semblait que c’était beaucoup plus d’échecs que nous en étions très heureux. Nous avons donc procédé à une analyse pour essayer de comprendre et de déterminer si c’était inhabituel ou non. sur Google Cloud. Nous utilisions GKE sur Google Cloud et cela fonctionnait sur le moteur de calcul de Google, qui est le service de machine virtuelle de Google.

Nous avons examiné nos données historiques relatives à nos systèmes de développement pour voir combien d'instances GCE avaient échoué. En août, lorsqu'une instance EC2 sur 20 avait échoué, nous avons examiné et nous avons constaté qu'en juin, juillet et août, nous avions n’avons eu aucune défaillance d’instances de la CME et nous avons été désorientés. Cela semblait trop beau pour être vrai, nous avons donc cherché plus profondément et avons découvert qu'il existait une fonctionnalité que nous utilisions depuis le début sans même savoir qu'elle existait et qu'elle s'appelle "Live migration". Grâce à une très petite ingénierie et à un peu de magie, GCE a développé cette installation permettant de déplacer vos machines virtuelles d’un serveur à un autre, d’un hôte, d’un matériel, d’un matériel défaillant à un autre. Une bonne pièce matérielle, sans aucune interruption du service, présente de très légères pertes lors de la commutation et le réseau bloqué pour pointer d’un serveur à un autre. Ils copient la mémoire pendant que le service est en cours d'exécution, puis continuent à copier les pages de mémoire vides jusqu'à ce qu'il atteigne le point de non-retour, puis ils l'enlèvent et la ramènent de l'autre endroit comme par magie. Nous n'avons eu aucune panne de machine virtuelle et des centaines de ces événements de migration en direct ont eu lieu. Voici donc un exemple où le risque a été rejeté et ensuite accepté de nouveau.

Nous rejetons également certains risques, nous avons décidé à contrecoeur de demander à nos clients de définir l’allocation des ressources pour les bases de données qu’ils exploitent. Nous avons en tête un système élastique qui s’adapte à vos besoins et nous vous facturons en fonction de l’utilisation, des avantages que vous tirez du système plutôt que des coûts d’infrastructure arbitraires. Nous avons décidé à contrecœur de ne pas disposer des informations nécessaires pour construire un tel système. Nous incitons donc nos clients à dimensionner les bases de données qu'ils exploitent.

Résumé

En parlant de cette idée de délégation de chaîne de risques, j'ai abordé un certain nombre de thèmes. Premièrement, les entreprises conservent des risques très spécialisés. Deuxièmement, une atténuation efficace repose sur la concentration d'expertise ou d'informations sur les économies d'échelle ou sur le lissage temporel, amortissement dans le temps. Parfois, au lieu de transférer le risque à d’autres personnes, nous pouvons le transmettre à notre avenir et mieux dire, dans un monde où la réduction des risques est moins chère. Certains risques sont repoussés sur le consommateur s'il s'avère en réalité moins coûteux pour lui d'atténuer et enfin, la responsabilité de l'atténuation des risques monte et descend cette chaîne au fil du temps.

J'ai parlé de notre système et du flux de risques et je pense que c'est une manière utile de penser à notre système et je vous encourage à rentrer chez vous et à faire la même chose pour les systèmes sur lesquels vous travaillez. Ne pensez pas seulement aux risques qui sont atténués dans la composante du système sur laquelle vous travaillez, mais pensez à la chaîne dans son ensemble et aux risques importants tout au long de la chaîne et à l'endroit où le système est réellement utilisé. l’ensemble pourrait être amélioré en déplaçant le point d’atténuation des risques et j’espère que cela vous sera utile.

Questions et réponses

Participant 1: Vraiment une bonne conversation. Une chose que je me demandais quand je vous ai vu parler de transferts de risques, c’est que ce genre de réflexion semble vraiment utile si vous présentiez le paysage concurrentiel lorsque vous comparez les services que vous offrez à ceux qui sont peut-être ceux proposés. les entreprises feraient. Utilisez-vous ce genre de pensée dans le calcul pour déterminer quels sont vos avantages concurrentiels ou comment vous pourriez être en concurrence avec d’autres sociétés?

Butler-Cole: Oui, absolument. En particulier, le point dont je parlais à la fin concernait une chose pour créer ce service, où nos clients n’ont pas à penser au risque de redimensionnement du système. Si nous le réalisions, ce serait très inhabituel pour une base de données. un service. Some do but if you think about other and if you've used Amazon's RDS, their relational database service, there are a huge number of complicated decisions you have to make when you're creating, when you're running an RDS instance about the infrastructure configuring the database. We think we will have a competitive advantage by taking that risk ourselves, by not pushing that back to the consumer and while we're pushing some back we certainly already trying to defend as much of that as possible.

Participant 1: May I add to that? Do you find that your risk goes down over time? Was the open source tools you're consuming get better and better?

Butler-Cole: I guess so. Generally, the ability for people to delegate risk to other people has improved over the last 10 years, 20 years though the emergence of open source where you can just delegate having written a whole bunch of your software to somebody else and in particular the rise of both the public cloud providers and also software as a service and those services are only getting better. Certainly, five years ago we haven't been able to outsource our Kubernetes operations risk and we probably wouldn't even have considered this five years ago than the earlier Kubernetes wouldn't have.

Participant 2: I have a question about the sort of the issues that you encounter, do you think Kubernetes first Stateful services, could you go more into detail about the problems you encounter that could possibly terminate your job but didn't. How did you mitigate those problems?

Butler-Cole: Unless you're doing something very clever, the State comes down to disks, you just have to make sure there exists a disk and that it's reliable. The problem with using Kubernetes is that there is an awful lot of lesser obstruction between you and your disk. Running Kubernetes on GKE, we're actually using GCE's network disk facility under the covers, so there were actual physical disks which are only down in some complex physical arrangement in Google's datacenters and then there's GCEs, APIs, and facilities, and on top of that there are Kubernetes own obstructions and then we build our own obstructions on top of that.

The biggest challenge is just the number of less, this stuff is a lot easier now than it was a couple of years ago, a couple of years ago if you're going to run Kubernetes you have to make all sorts of decisions about which networking, plugging that we're going to use, which storage plug-ins, and so on. Now using GKE you just stand it up and it just works, so it's a question of thinking hard about the disk. The physical disk can then also logically about the identity of those disks within the cluster and making sure they all keep, they all stay lined up.

See more presentations with transcripts