Faire de nouvelles erreurs Je suis ingénieur logiciel depuis environ 15 ans maintenant. Tout au long de ma carrière, j'ai beaucoup appris et appliqué ces apprentissages pour concevoir et mettre en œuvre (et parfois supprimer progressivement ou laisser tels quels) de nombreux systèmes distribués. En cours de route, j’ai commis de nombreuses erreurs et je continue à les commettre. Mais comme mon objectif principal était la fiabilité, j'ai repensé à mon expérience et à la communauté pour trouver des moyens de minimiser la fréquence des erreurs. Ma devise est : il faut absolument essayer de commettre de nouvelles erreurs (moins évidentes, plus sophistiquées). Faire une erreur, c'est bien - c'est ainsi qu'on apprend, en répétant - c'est triste et décourageant. C'est probablement ce qui m'a toujours fasciné dans les mathématiques. Non seulement parce qu’il est élégant et concis, mais aussi parce que sa rigueur logique évite les erreurs. Cela vous oblige à réfléchir à votre contexte actuel, aux postulats et aux théorèmes sur lesquels vous pouvez vous appuyer. Suivre ces règles s'avère fructueux, vous obtenez le bon résultat. Il est vrai que l’informatique est une branche des mathématiques. Mais ce que nous pratiquons habituellement, c’est le génie logiciel, une chose très distincte. Nous appliquons les réalisations et les découvertes de l’informatique à la pratique, en tenant compte des contraintes de temps et des besoins de l’entreprise. Ce blog est une tentative d'appliquer le raisonnement semi-mathématique à la conception et à la mise en œuvre de programmes informatiques. Nous proposerons un modèle de différents d'exécution fournissant un cadre permettant d'éviter de nombreuses erreurs de programmation. régimes Depuis des débuts modestes Lorsque nous apprenons à programmer et faisons nos premiers pas timides (ou audacieux), nous commençons généralement par quelque chose de simple : programmer des boucles, faire de l'arithmétique de base et imprimer les résultats dans un terminal résoudre des problèmes mathématiques, probablement dans un environnement spécialisé comme MathCAD ou Mathematica Nous acquérons de la mémoire musculaire, apprenons la syntaxe du langage et surtout nous changeons notre façon de penser et de raisonner. Nous apprenons à lire le code, à faire des hypothèses sur la façon dont il est exécuté. Nous ne commençons presque jamais par lire une norme linguistique et lisons attentivement sa section « Modèle de mémoire » - parce que nous ne sommes pas encore équipés pour les apprécier pleinement et les utiliser. Nous pratiquons les essais et les erreurs : nous introduisons des bugs logiques et arithmétiques dans nos premiers programmes. Ces erreurs nous apprennent à vérifier nos hypothèses : cet invariant de boucle est-il correct, pouvons-nous comparer l'index et la longueur des éléments du tableau de cette façon (où mettez-vous ce -1) ? Mais si nous ne voyons pas d’erreurs, nous internalisons souvent implicitement certaines erreurs. le système nous impose et nous fournit. invariants A savoir celui-ci : Les lignes de code sont toujours évaluées dans le même ordre (sérialisées). Ce postulat nous permet de supposer que les propositions suivantes sont vraies (nous n'allons pas les prouver) : l'ordre d'évaluation ne change pas entre les exécutions les appels de fonction reviennent toujours Les axiomes mathématiques permettent de dériver et de construire des structures plus grandes sur une base solide. En mathématiques, nous avons avec 4+1 postulats. Le dernier dit : la géométrie euclidienne les lignes parallèles restent parallèles, elles ne se croisent ni ne divergent Pendant des millénaires, les mathématiciens ont tenté de le prouver et de le déduire des quatre premiers. Il s'avère que ce n'est pas possible. Nous pouvons remplacer ce postulat des « lignes parallèles » par des alternatives et obtenir différents types de géométries (à savoir hyperboliques et elliptiques), qui ouvrent de nouvelles perspectives et s’avèrent applicables et utiles. Après tout, la surface de notre planète n'est pas plate et nous devons en tenir compte, par exemple dans les logiciels GPS et les itinéraires aériens. Le besoin de changement Mais avant cela, arrêtons-nous et posons les questions les plus techniques : pourquoi s'embêter ? Si le programme fait son travail, s’il est facile à prendre en charge, à maintenir et à évoluer, pourquoi devrions-nous abandonner en premier lieu cet invariant douillet d’exécution séquentielle prévisible ? Je vois deux réponses. Le premier est . Si nous pouvons faire en sorte que notre programme s'exécute deux fois plus vite ou de manière similaire - en nécessitant la moitié du matériel - c'est une réussite technique. Si en utilisant la même quantité de ressources informatiques, nous pouvons traiter 2x (ou 3, 4, 5, 10x) de données, cela peut ouvrir des applications complètement nouvelles du même programme. Il peut fonctionner sur un téléphone mobile dans votre poche au lieu d'un serveur. Parfois, nous pouvons accélérer en appliquant des algorithmes intelligents ou en réécrivant dans un langage plus performant. Ce sont nos premières options à explorer, oui. Mais ils ont une limite. L'architecture bat presque toujours la mise en œuvre. La loi de Moor ne fonctionne pas très bien ces derniers temps, les performances d'un seul processeur augmentent lentement, les performances de la RAM (latence principalement) sont à la traîne. Alors, naturellement, les ingénieurs ont commencé à chercher d’autres options. la performance La deuxième considération est . La nature est chaotique, la deuxième loi de la thermodynamique s'oppose constamment à tout ce qui est précis, séquentiel et reproductible. Les bits se retournent, les matériaux se dégradent, l'alimentation diminue, les fils sont coupés, empêchant l'exécution de nos programmes. Garder une abstraction séquentielle et reproductible devient une tâche difficile. Si nos programmes pouvaient survivre aux pannes logicielles et matérielles, nous pourrions fournir des services présentant un avantage commercial concurrentiel. C'est une autre tâche d'ingénierie que nous pouvons commencer à aborder. la fiabilité Equipés de cet objectif, nous pouvons commencer à expérimenter des approches non sérialisées. Fils d'exécution Regardons ce morceau de pseudo-code : ``` def fetch_coordinates(poi: str) -> Point: … def find_pois(center: Point, distance: int) -> List[str]: … def get_my_location() -> Point: … def fetch_coordinates(p) - Point: … def main(): me = get_my_location() for point in find_pois(me, 500): loc = fetch_coordinates(point) sys.stdout.write(f“Name: {point} is at x={loc.x} y={loc.y}”) Nous pouvons lire le code de haut en bas et supposer raisonnablement que la fonction `find_pois` sera appelée `get_my_location`. Et nous récupérerons et renverrons les coordonnées du premier POI après avoir récupéré le suivant. Ces hypothèses sont correctes et permettent de construire un modèle mental, raisonnant sur le programme. après Imaginons que nous puissions faire en sorte que notre code s'exécute de manière non séquentielle. Il existe de nombreuses façons de procéder syntaxiquement. Nous allons ignorer les expériences de réorganisation des instructions (c'est ce que font les compilateurs et les processeurs modernes) et étendre notre langage afin de pouvoir exprimer un nouveau régime d'exécution : ou même par rapport aux autres fonctions. En reformulant, nous devons introduire plusieurs d’exécution. Les fonctions de notre programme s'exécutent dans un environnement spécifique (conçu et maintenu par le système d'exploitation). Nous nous intéressons actuellement à la mémoire virtuelle adressable et à un thread - une unité de planification, quelque chose qui peut être exécuté par un processeur. de fonctions en même temps en parallèle threads Les threads existent en différentes saveurs : un fil POSIX, un fil vert, une coroutine, une goroutine. Les détails diffèrent grandement, mais cela se résume à quelque chose qui peut être exécuté. Si plusieurs fonctions peuvent s'exécuter simultanément, chacune a besoin de sa propre unité de planification. C'est de là que vient le multithreading, au lieu d'un, nous avons plusieurs threads d'exécution. Certains environnements (MPI) et langages peuvent créer des threads implicitement, mais nous devons généralement le faire explicitement en utilisant `pthread_create` en C, des classes de module `threading` en Python ou une simple instruction `go` en Go. Avec quelques précautions, nous pouvons faire en sorte que le même code s'exécute principalement en parallèle : def fetch_coordinates(poi, results, idx) -> None: … results[idx] = poi def main(): me = get_my_location() points = find_pois(me, 500) results = [None] * len(points) # Reserve space for each result threads = [] for i, point in enumerate(find_pois(me, 500)): # i - index for result thr = threading.Thread(target=fetch_coordinates, args=(poi, results, i)) thr.start() threads.append(thr) for thr in threads: thr.wait() for point, result in zip(points, results): sys.stdout.write(f“Name: {poi} is at x={loc.x} y={loc.y}”) notre programme peut fonctionner sur plusieurs processeurs et évoluer à mesure que le nombre de cœurs augmente et se termine plus rapidement. Prochaine question d'ingénierie qu'il faut se poser : à quel prix ? Nous avons atteint notre objectif de performances : Nous avons intentionnellement renoncé à une exécution sérialisée et prévisible. Il y a entre une fonction + un moment précis et les données. À chaque instant, il existe toujours un seul mappage entre une fonction en cours d'exécution et ses données : pas de bijection La conséquence suivante est qu'une fonction peut se terminer avant une autre cette fois, la prochaine fois ce peut être l'inverse. Ce nouveau régime d'exécution conduit à des courses aux données : lorsque des fonctions concurrentes travaillent avec des données, cela signifie que l'ordre des opérations appliquées aux données n'est pas défini. Nous commençons à être confrontés à des courses aux données et apprenons à y faire face en utilisant : sections critiques : mutex (et spinlocks) algorithmes sans verrouillage (la forme la plus simple se trouve dans l'extrait ci-dessus) outils de détection de courses etc. À ce stade, nous découvrons au moins deux choses. Premièrement, il existe plusieurs façons d’accéder aux données. Certaines données sont (par exemple, des variables de portée de fonction) et nous seuls pouvons le voir (et y accéder) et il est donc toujours dans l'état dans lequel nous l'avons laissé. Cependant, certaines données sont partagées ou . Il réside toujours dans la mémoire de notre processus, mais nous utilisons des moyens spéciaux pour y accéder et il peut être désynchronisé. Dans certains cas, pour travailler avec, nous le copions dans notre mémoire locale pour éviter les courses de données - c'est pourquoi == ==est populaire dans Rust. locale télécommande .cloner() Lorsque nous poursuivons ce raisonnement, d’autres techniques telles que le stockage local par thread apparaissent naturellement. Nous venons d'acquérir un nouveau gadget dans notre boîte à outils de programmation, élargissant ce que nous pouvons réaliser en créant des logiciels. Cependant, il existe un invariant sur lequel nous pouvons toujours compter. Lorsque nous recherchons des données partagées (à distance) à partir d'un fil de discussion, nous les obtenons toujours. Il n’existe aucune situation dans laquelle une partie de la mémoire n’est pas disponible. Le système d'exploitation mettra fin à (threads) en tuant le processus en cas de dysfonctionnement de la région de mémoire physique de sauvegarde. La même chose s'applique à « notre » thread si nous avons verrouillé un mutex, nous ne pouvons en aucun cas perdre le verrou et devons arrêter ce que nous faisons immédiatement. Nous pouvons compter sur cet invariant (appliqué par le système d'exploitation et le matériel moderne) selon lequel tous les participants sont morts ou vivants. Tous : si le processus (MOO), le système d'exploitation (bug du noyau) ou le matériel rencontre un problème, tous nos threads cesseront d'exister ensemble sans effets secondaires externes. tous les participants partagent le sort Inventer un processus Une chose importante à noter. Comment avons-nous fait ce premier pas en introduisant les fils de discussion ? Nous nous sommes séparés, avons bifurqué. Au lieu d’avoir une seule unité de planification, nous en avons introduit plusieurs. Continuons à appliquer cette approche de non-partage et voyons comment cela se passe. Cette fois, nous copions la mémoire virtuelle du processus. C'est ce qu'on appelle un . Nous pouvons exécuter une autre instance de notre programme ou démarrer un autre utilitaire existant. C'est une excellente approche pour : générer processus réutiliser un autre code avec des limites strictes exécuter du code non fiable, en l'isolant de notre propre mémoire Presque tout == == fonctionnent de cette façon, afin qu'ils soient capables d'exécuter du code exécutable Javascript non fiable téléchargé depuis Internet et de le terminer de manière fiable lorsque vous fermez un onglet sans faire tomber l'ensemble de l'application. navigateurs modernes Il s'agit encore d'un autre régime d'exécution que nous avons découvert en abandonnant l'invariant , en la mémoire virtuelle et en en faisant une copie. Les copies ne sont pas gratuites : du destin partagé ne partageant plus Le système d'exploitation doit gérer les structures de données liées à la mémoire (pour maintenir le mappage virtuel -> physique) Certains bits auraient pu être partagés et les processus consomment donc de la mémoire supplémentaire Se libérer Pourquoi s'arrêter ici ? Explorons quels autres supports pouvons-nous copier et notre programme. Mais pourquoi procéder à la distribution en premier lieu ? Dans de nombreux cas, les tâches à accomplir peuvent être résolues à l’aide d’une seule machine. distribuer Nous devons être distribués principes afin que notre logiciel cesse de dépendre des problèmes inévitables rencontrés par les couches sous-jacentes. pour échapper au destin partagé Pour n'en nommer que quelques-uns : Mises à niveau du système d'exploitation : nous devons de temps en temps redémarrer nos machines Pannes matérielles : elles surviennent plus souvent que nous le souhaiterions Pannes externes : les pannes de courant et de réseau sont monnaie courante. Si nous copions un système d'exploitation, nous appelons cela une et pouvons exécuter les programmes des clients sur une machine physique et y créer une énorme activité cloud. Si nous prenons deux ordinateurs ou plus et exécutons nos programmes sur chacun, notre programme peut survivre même à une panne matérielle, en fournissant un service 24h/24 et 7j/7 et en obtenant un avantage concurrentiel. Il y a longtemps, les grandes entreprises sont allées encore plus loin et les géants de l'Internet en exécutent désormais des copies dans différents centres de données et même sur des continents, rendant ainsi un programme résilient à un typhon ou à une simple panne de courant. machine virtuelle Mais cette indépendance a un prix : les anciens invariants ne sont pas appliqués, nous sommes livrés à nous-mêmes. Ne vous inquiétez pas, nous ne sommes pas les premiers. Il existe de nombreuses techniques, outils et services pour nous aider. Points à retenir Nous venons d'acquérir la capacité de raisonner sur les systèmes et leurs régimes d'exécution respectifs. Dans tout système à grande échelle, la plupart des éléments sont séquentiels et sans état, de nombreux composants sont multithread avec des types de mémoire et des hiérarchies, tous maintenus ensemble par un mélange de éléments véritablement distribués : Le but est de pouvoir distinguer où nous en sommes actuellement, quels invariants détiennent et agir (modifier/concevoir) en conséquence. Nous avons mis en évidence le raisonnement de base, transformant les « inconnues inconnues » en « inconnues connues ». Ne le prenez pas à la légère, c’est un progrès significatif.
