Mod�les d'applications �volutives et r�silientes

Ce document pr�sente des mod�les et des pratiques permettant de cr�er des applications r�silientes et �volutives, deux�objectifs essentiels pour nombre d'architectures modernes. Une application bien con�ue doit �voluer � la hausse ou � la baisse en fonction de l'augmentation et de la diminution de la demande, et �tre suffisamment r�siliente pour r�sister aux interruptions de service. Le d�veloppement et l'exploitation d'applications r�pondant � ces exigences n�cessitent une planification et une conception minutieuses.

�volutivit�: adaptation de la capacit� en fonction de la demande

L'�volutivit� est une mesure qui �value la capacit� d'un syst�me � g�rer des volumes de t�ches variables en ajoutant ou en supprimant des ressources du syst�me. Par exemple, une application Web �volutive est une application qui fonctionne bien, que ce soit avec un ou plusieurs utilisateurs, et qui est capable de g�rer les pics et baisses de trafic de mani�re optimale.

La flexibilit� d'ajuster les ressources consomm�es par une application est un facteur strat�gique d�terminant pour migrer vers le cloud. Avec une conception appropri�e, vous pouvez r�duire les co�ts en supprimant les ressources sous-utilis�es, sans compromettre les performances et l'exp�rience utilisateur. Vous pouvez �galement assurer une bonne exp�rience utilisateur lors des pics de trafic en ajoutant davantage de ressources. Ainsi, votre application ne consomme que les ressources n�cessaires pour r�pondre � la demande.

Google�Cloud fournit des produits et des fonctionnalit�s pour vous aider � cr�er des applications �volutives et efficaces�:

• Les autoscalers int�gr�s aux machines virtuelles Compute�Engine et aux clusters Google Kubernetes�Engine (GKE) vous permettent d'augmenter ou de r�duire la consommation des ressources en fonction des m�triques que vous d�finissez.
• La plate-forme sans serveur de Google�Cloud fournit des services g�r�s de calcul et de base de donn�es qui �voluent rapidement de z�ro�requ�te � un volume de requ�tes �lev�, et vous ne payez que ce que vous utilisez.
• Les produits de base de donn�es, tels que BigQuery, Spanner et Bigtable peuvent offrir des performances constantes sur des donn�es de tr�s grande taille.
• Cloud�Monitoring met � votre disposition des m�triques pour vos applications et votre infrastructure. Vous pouvez ainsi prendre des d�cisions en termes de scaling en vous appuyant sur les donn�es.

R�silience�: conception permettant de supporter les d�faillances

Une application r�siliente est une application qui continue � fonctionner malgr� les d�faillances des composants du syst�me. La r�silience n�cessite une planification � tous les niveaux de l'architecture. Elle influe sur l'organisation de l'infrastructure et du r�seau, ainsi que sur la conception de l'application et du stockage de donn�es. La r�silience s'�tend �galement aux personnes et aux cultures.

Il est difficile de d�velopper et d'exploiter des applications r�silientes. Cela est particuli�rement vrai pour les applications distribu�es, qui peuvent contenir plusieurs couches d'infrastructure, de r�seaux et de services. Des erreurs et des pannes peuvent se produire. L'am�lioration de la r�silience de votre application est donc un d�fi constant. Vous pouvez am�liorer la capacit� de votre application � supporter les d�faillances � l'aide d'une planification minutieuse. Avec des processus et une culture organisationnelle appropri�s, vous pouvez �galement tirer des le�ons des d�faillances pour accro�tre davantage la r�silience de votre application.

Google�Cloud fournit des outils et des services pour vous aider � cr�er des applications r�silientes � disponibilit� �lev�e�:

• Les services Google�Cloud sont disponibles dans plusieurs r�gions et zones du monde, ce qui vous permet de d�ployer votre application en r�pondant au mieux � vos objectifs de disponibilit�.
• Les groupes d'instances Compute�Engine et les clusters GKE peuvent �tre r�partis et g�r�s entre les zones disponibles d'une r�gion.
• Les disques persistants r�gionaux Compute�Engine sont r�pliqu�s de mani�re synchrone dans les zones d'une m�me r�gion.
• Google�Cloud propose diff�rentes options d'�quilibrage de charge pour g�rer le trafic de votre application, y compris l'�quilibrage de charge global permettant d'acheminer le trafic vers la r�gion op�rationnelle la plus proche de vos utilisateurs.
• La plate-forme sans serveur de Google�Cloud fournit des produits de calcul et de base de donn�es g�r�s, dot�s d'une fonctionnalit� de redondance int�gr�e et d'�quilibrage de charge.
• Google�Cloud est compatible avec les solutions de CI/CD via des outils natifs et des int�grations aux technologies Open�Source courantes pour vous aider � automatiser la conception et le d�ploiement de vos applications.
• Cloud�Monitoring met � votre disposition des m�triques pour vos applications et votre infrastructure. Vous pouvez ainsi prendre des d�cisions � partir de donn�es concernant les performances et l'�tat de vos applications.

Facteurs et contraintes

Plusieurs exigences et motivations peuvent influer sur l'am�lioration de l'�volutivit� et de la r�silience de votre application. Vous pouvez �galement �tre soumis � certaines contraintes limitant votre capacit� � remplir vos objectifs d'�volutivit� et de r�silience. L'importance relative de ces exigences et contraintes varie en fonction du type d'application, du profil de vos utilisateurs, ainsi que de l'envergure et de la maturit� de votre organisation.

Pilotes

Pour vous aider � hi�rarchiser vos besoins, prenez en compte les facteurs des diff�rentes parties de votre organisation.

Facteurs commerciaux

Les entreprises sont soumises � un certain nombre de facteurs strat�giques, y compris les suivants�:

• Optimiser les co�ts et la consommation des ressources
• Minimiser les temps d'arr�t de l'application
• S'assurer que la demande des utilisateurs peut �tre satisfaite pendant les p�riodes de forte utilisation
• Am�liorer la qualit� et la disponibilit� du service
• Garantir la continuit� de l'exp�rience utilisateur et de la confiance en cas d'interruption de service
• Augmenter la flexibilit� et l'agilit� pour r�pondre aux nouvelles exigences du march�

Facteurs de d�veloppement

Le d�veloppement dans l'entreprise est tributaire des facteurs suivants�:

• Diminuer le temps consacr� � l'analyse des d�faillances
• Augmenter le temps consacr� au d�veloppement de nouvelles fonctionnalit�s
• Minimiser les t�ches laborieuses par le biais de l'automatisation
• D�velopper des applications bas�es sur les derniers mod�les et pratiques du secteur

Facteurs op�rationnels

Il convient �galement de prendre en compte les exigences op�rationnelles suivantes�:

• R�duire la fr�quence des pannes n�cessitant une intervention humaine
• Augmenter la capacit� � r�soudre automatiquement les pannes
• Minimiser les t�ches laborieuses par le biais de l'automatisation
• Minimiser l'impact de la d�faillance d'un composant particulier

Contraintes

Des contraintes peuvent limiter votre capacit� � am�liorer l'�volutivit� et la r�silience de votre application. Assurez-vous que vos d�cisions de conception n'introduisent pas de contraintes ou n'y contribuent pas�:

• D�pendances mat�rielles ou logicielles difficiles � faire �voluer
• D�pendances mat�rielles ou logicielles difficiles � exploiter dans une configuration de haute disponibilit�
• D�pendances entre les applications
• Restrictions de licence
• Manque de comp�tences ou d'exp�rience des �quipes charg�es du d�veloppement et des op�rations
• R�sistance � l'automatisation au sein de l'organisation

Mod�les et pratiques

Le reste de ce document d�finit les mod�les et pratiques permettant de d�velopper des applications r�silientes et �volutives. Ces mod�les ont une incidence sur l'ensemble du cycle de vie de votre application, y compris la conception de l'infrastructure, l'architecture de l'application, les options de stockage, les processus de d�ploiement et la culture organisationnelle.

Trois�th�mes se distinguent dans ces mod�les�:

• Automatisation. Le d�veloppement d'applications �volutives et r�silientes n�cessite une automatisation. L'automatisation du provisionnement de l'infrastructure, des tests et des d�ploiements d'applications permet d'am�liorer la coh�rence et la rapidit�, ainsi que de limiter les erreurs humaines.
• Couplage faible. Traiter votre syst�me sous forme de collection de composants faiblement coupl�s et ind�pendants vous apporte flexibilit� et r�silience. L'ind�pendance englobe la r�partition physique des ressources, l'architecture de l'application et la conception du stockage.
• Conception bas�e sur les donn�es. Il est essentiel de collecter des m�triques pour comprendre le comportement de votre application. Les d�cisions permettant de d�terminer � quel moment faire �voluer votre application ou d'identifier un service non op�rationnel doivent �tre bas�es sur les donn�es. Vous devez attacher une importance particuli�re aux m�triques et aux journaux.

Automatiser le provisionnement de l'infrastructure

La cr�ation d'une infrastructure immuable par le biais de l'automatisation vous permet d'am�liorer la coh�rence de vos environnements et d'augmenter le taux de r�ussite de vos d�ploiements.

G�rer l'infrastructure comme du code

L'Infrastructure as code (IaC) est une technique qui vous encourage � traiter le provisionnement et la configuration de votre infrastructure de la m�me mani�re que vous g�rez le code d'application. La logique de provisionnement et de configuration est stock�e dans un d�p�t source de fa�on � la rendre visible. Elle peut �galement comporter des versions g�r�es et �tre contr�l�e. Comme elle se trouve dans un d�p�t de code, vous pouvez tirer profit des pipelines d'int�gration continue et de d�ploiement continu (CI/CD), de sorte que toutes les modifications apport�es � votre configuration puissent �tre test�es et d�ploy�es automatiquement.

En supprimant les �tapes manuelles du provisionnement de votre infrastructure, l'IaC permet de limiter les erreurs humaines, ainsi que d'am�liorer la coh�rence et la reproductibilit� des applications et des environnements. De cette mani�re, vous pouvez augmenter la r�silience de vos applications.

Cloud Deployment�Manager vous permet d'automatiser la cr�ation et la gestion des ressources Google�Cloud � l'aide de mod�les flexibles. Config�Connector vous permet �galement de g�rer vos ressources � l'aide des techniques et des workflows Kubernetes. Google�Cloud est �galement compatible avec des outils IaC tiers, tels que Terraform, Chef et Puppet.

Cr�er une infrastructure immuable

L'infrastructure immuable est une philosophie qui s'appuie sur les avantages de l'Infrastructure as Code. L'infrastructure immuable exige qu'aucune modification ne soit apport�e aux ressources apr�s leur d�ploiement. Lorsqu'il est n�cessaire de proc�der � la mise � jour d'une machine virtuelle, d'un cluster Kubernetes ou d'une r�gle de pare-feu, vous pouvez mettre � jour la configuration de la ressource dans le d�p�t source. Une fois les modifications test�es et valid�es, vous pouvez red�ployer compl�tement la ressource � l'aide de la nouvelle configuration. En d'autres termes, vous recr�ez les ressources au lieu de les ajuster.

L'infrastructure immuable permet de rendre les d�ploiements et les rollbacks plus pr�visibles. Elle r�sout �galement les probl�mes courants des infrastructures mutables, tels que les �carts de configuration et les serveurs en flocon. En optant pour une infrastructure immuable, vous am�liorez donc davantage la coh�rence et la fiabilit� de vos environnements.

Concevoir pour la haute disponibilit�

La disponibilit� est une mesure de la fraction de temps pendant laquelle un service est utilisable. La disponibilit� est souvent utilis�e comme indicateur cl� de l'�tat g�n�ral du service. Les architectures � disponibilit� �lev�e visent � maximiser la disponibilit� du service, g�n�ralement via le d�ploiement redondant de composants. Autrement dit, la haute disponibilit� implique g�n�ralement la distribution des ressources de calcul, l'�quilibrage de charge et la r�plication des donn�es.

R�partir physiquement les ressources

Les services Google�Cloud sont disponibles partout dans le monde. Ces emplacements sont organis�s en r�gions et en zones. La mani�re dont vous d�ployez votre application dans ces r�gions et zones affecte la disponibilit�, la latence et d'autres propri�t�s de votre application. Pour en savoir plus, consultez les Bonnes pratiques pour la s�lection des r�gions Compute�Engine.

La redondance correspond � la duplication des composants d'un syst�me dans le but d'augmenter sa disponibilit�. Dans Google�Cloud, la redondance est g�n�ralement obtenue en d�ployant votre application ou votre service dans plusieurs zones, voire dans plusieurs r�gions. Si un service existe dans plusieurs zones ou r�gions, il r�siste mieux aux interruptions de service dans une zone ou une r�gion particuli�re. Bien que Google�Cloud s'efforce de pr�venir de telles perturbations, certains �v�nements restent impr�visibles et il est pr�f�rable de s'y pr�parer.

Les groupes d'instances g�r�s Compute�Engine vous permettent de r�partir les instances de machines virtuelles sur plusieurs zones d'une m�me r�gion et de les g�rer en tant qu'unit� logique. Google Cloud propose également des disques persistants régionaux pour répliquer automatiquement vos données dans deux zones d'une même région.

Vous pouvez également améliorer la disponibilité et la résilience des applications déployées sur GKE en créant des clusters régionaux. Un cluster régional répartit les composants, les nœuds et les pods du plan de contrôle GKE sur plusieurs zones d'une même région. Comme les composants du plan de contrôle sont répartis, vous pouvez continuer à accéder au plan de contrôle du cluster, même en cas de panne impliquant une ou plusieurs zones (mais pas toutes).

Favoriser les services g�r�s

Plut�t que d'installer, de maintenir � jour et d'exploiter de mani�re ind�pendante chaque partie d'une pile d'applications, vous pouvez utiliser des services g�r�s pour consommer des parties de la pile d'applications en tant que services. Par exemple, plut�t que d'installer et de g�rer une base de donn�es MySQL sur des machines virtuelles (VM), vous pouvez utiliser une base de donn�es MySQL fournie par Cloud�SQL. Vous b�n�ficiez alors d'un contrat de niveau de service garantissant une certaine disponibilit�. Vous pouvez compter sur Google�Cloud pour g�rer la r�plication des donn�es, les sauvegardes et l'infrastructure sous-jacente. Les services g�r�s vous permettent de consacrer moins de temps � la gestion de l'infrastructure, et davantage � l'am�lioration de la fiabilit� de votre application.

De nombreux services de calcul, de base de donn�es et de stockage Google�Cloud offrent une fonctionnalit� de redondance int�gr�e, qui peut vous aider � atteindre vos objectifs de disponibilit�. La plupart de ces services proposent un mod�le r�gional, ce qui signifie que l'infrastructure qui ex�cute votre application est situ�e dans une r�gion sp�cifique et g�r�e par Google pour �tre disponible de mani�re redondante dans toutes les zones de cette r�gion. Si une zone devient indisponible, votre application ou vos donn�es sont automatiquement diffus�es depuis une autre zone de la r�gion.

Certains services de base de donn�es et de stockage offrent �galement une disponibilit� multir�gionale, ce qui signifie que l'infrastructure qui ex�cute votre application est situ�e dans plusieurs r�gions. Les services multir�gionaux peuvent tol�rer la perte d'une r�gion enti�re, mais g�n�ralement au prix d'une latence plus �lev�e.

�quilibrage de charge � chaque niveau

L'�quilibrage de charge vous permet de r�partir le trafic sur des groupes de ressources. Vous vous assurez ainsi que les ressources individuelles ne sont pas surcharg�es et que les autres restent inactives. La plupart des �quilibreurs de charge fournissent �galement des fonctionnalit�s de v�rification d'�tat permettant de v�rifier que le trafic n'est pas achemin� vers des ressources non op�rationnelles ou indisponibles.

Google�Cloud propose plusieurs options d'�quilibrage de charge. Si votre application s'ex�cute sur Compute�Engine ou GKE, vous pouvez choisir le type d'�quilibreur de charge le plus appropri� en fonction du type, de la source et d'autres aspects du trafic. Pour en savoir plus, consultez la pr�sentation de l'�quilibrage de charge et la pr�sentation de la mise en r�seau de GKE.

Certains services g�r�s Google�Cloud, tels qu'App�Engine et Cloud�Run, �quilibrent �galement la charge du trafic de mani�re automatique.

Il est courant d'�quilibrer la charge des requ�tes re�ues de sources externes, telles que les clients Web ou mobiles. Toutefois, vous pouvez accro�tre la r�silience et la flexibilit� de votre application en utilisant des �quilibreurs de charge entre ses diff�rents services ou niveaux. Google�Cloud fournit un �quilibrage de charge interne de couche�4 et de couche�7 � cet effet.

Le sch�ma suivant pr�sente un �quilibreur de charge externe r�partissant le trafic global entre deux�r�gions, us-central1 et asia-east1. Il pr�sente �galement un �quilibrage de charge interne r�partissant le trafic du niveau Web sur le niveau interne de chaque r�gion.

Surveiller votre infrastructure et vos applications

Avant de d�cider comment am�liorer la r�silience et l'�volutivit� de votre application, vous devez comprendre son comportement. Vous pouvez d�tecter les probl�mes potentiels avant qu'ils ne provoquent une panne en acc�dant � un ensemble complet de m�triques et de s�ries temporelles pertinentes sur les performances et l'�tat de votre application. Elles peuvent �galement vous aider � diagnostiquer et � r�soudre une panne le cas �ch�ant. Le chapitre Surveillance des syst�mes distribu�s du livre SRE de Google fournit un bon aper�u de certaines approches de surveillance.

En plus de fournir des informations sur l'�tat de l'application, les m�triques peuvent �galement �tre utilis�es pour contr�ler le comportement de l'autoscaling des services.

Cloud�Monitoring est l'outil de surveillance int�gr� de Google�Cloud. Cloud�Monitoring ing�re des �v�nements, des m�triques et des m�tadonn�es, et g�n�re des tendances via des tableaux de bord et des alertes. La plupart des services Google�Cloud envoient automatiquement des m�triques � Cloud�Monitoring. Google�Cloud accepte �galement de nombreuses sources tierces. Cloud�Monitoring peut servir de backend pour les outils de surveillance Open�Source populaires, en examinant votre application � l'aide d'une vue centralis�e.

Surveiller � tous les niveaux

Vous pouvez obtenir un aper�u complet de l'�tat et du comportement de votre application en collectant des m�triques � diff�rents niveaux de l'architecture.

Surveillance de l'infrastructure

La surveillance au niveau de l'infrastructure pr�sente l'�tat et les performances de r�f�rence de votre application. Cette approche de surveillance enregistre des informations, telles que la charge du processeur, l'utilisation de la m�moire et le nombre d'octets �crits sur le disque. Ces m�triques peuvent indiquer qu'une machine est surcharg�e ou qu'elle ne fonctionne pas comme pr�vu.

En plus de la collecte automatique de m�triques, Cloud�Monitoring fournit un agent que vous pouvez installer pour obtenir des informations plus d�taill�es � partir des VM Compute�Engine, y compris d'applications tierces s'ex�cutant sur ces machines.

Surveillance de l'application

Nous vous recommandons de recueillir des m�triques au niveau de l'application. Par exemple, vous pourriez avoir besoin d'�valuer le temps n�cessaire pour ex�cuter une requ�te particuli�re ou pour effectuer une s�quence d'appels de service associ�e. Vous pouvez vous-m�me d�finir ces m�triques au niveau de l'application. Elles collectent des informations que les m�triques Cloud�Monitoring int�gr�es ne peuvent pas obtenir. Les m�triques au niveau de l'application peuvent capturer des conditions agr�g�es qui refl�tent plus fid�lement les workflows principaux. Elles peuvent �galement d�celer des probl�mes que les m�triques au niveau de l'infrastructure de bas niveau ne peuvent pas identifier.

Nous vous recommandons �galement de capturer les m�triques au niveau de votre application � l'aide d'OpenTelemetry. OpenTelemetry fournit une norme ouverte unique pour les donn�es de t�l�m�trie. Utilisez OpenTelemetry pour collecter et exporter des donn�es � partir de votre application et de votre infrastructure cloud-first. Vous pouvez ensuite surveiller et analyser les donn�es de t�l�m�trie export�es.

Surveillance des services

Il est important de surveiller les interactions entre les diff�rents services et composants des applications distribu�es bas�es sur des microservices. Ces m�triques peuvent vous aider � diagnostiquer des probl�mes, tels qu'une augmentation du nombre d'erreurs ou de la latence entre les services.

Istio est un outil Open�Source qui fournit des informations et un contr�le op�rationnel sur le r�seau de microservices. Istio g�n�re une t�l�m�trie d�taill�e pour toutes les communications entre les services. Il peut �tre configur� pour envoyer des m�triques � Cloud�Monitoring.

Surveillance de bout en bout

La surveillance de bout en bout, �galement appel�e surveillance par bo�te noire, teste le comportement visible de l'ext�rieur, tel qu'un utilisateur le per�oit. Elle v�rifie si l'utilisateur est en mesure d'effectuer des actions critiques dans les limites des seuils que vous avez d�finis. Cette surveillance � faible pr�cision peut d�tecter des erreurs ou une latence qu'une surveillance plus pr�cise ne pourrait pas identifier. Elle pr�sente �galement la disponibilit� telle qu'elle est per�ue par l'utilisateur.

Exposer l'�tat des applications

Un syst�me � disponibilit� �lev�e doit �tre en mesure d'identifier les parties du syst�me qui sont op�rationnelles et qui fonctionnent correctement. Si certaines ressources ne semblent pas op�rationnelles, le syst�me peut envoyer des requ�tes ailleurs. En r�gle g�n�rale, les v�rifications d'�tat impliquent l'extraction de donn�es d'un point de terminaison pour d�terminer l'�tat d'un service.

La v�rification d'�tat fait partie des principales responsabilit�s d'un �quilibreur de charge. Lorsque vous associez un �quilibreur de charge � un groupe d'instances de machines virtuelles, vous d�finissez �galement une v�rification d'�tat. Celle-ci d�termine comment l'�quilibreur de charge communique avec les machines virtuelles afin d'�valuer si des instances particuli�res doivent continuer � recevoir du trafic. Les v�rifications d'�tat d'un �quilibreur de charge peuvent �galement �tre utilis�es pour l'autor�paration des groupes d'instances, de mani�re � ce que les machines non op�rationnelles soient recr��es. Si vous ex�cutez GKE et que vous �quilibrez la charge du trafic externe via une ressource d'entr�e, GKE cr�e automatiquement les v�rifications d'�tat appropri�es pour l'�quilibreur de charge.

Kubernetes est compatible avec les v�rifications d'activit� et d'aptitude. Ces v�rifications aident l'outil d'orchestration de Kubernetes � d�cider comment g�rer les pods et les requ�tes au sein de votre cluster. Si votre application est d�ploy�e sur Kubernetes, il est recommand� d'exposer son �tat aux v�rifications par le biais de points de terminaison appropri�s.

�tablir des m�triques cl�s

La surveillance et la v�rification d'�tat fournissent des m�triques sur le comportement et l'�tat de votre application. L'�tape suivante consiste � analyser ces m�triques pour d�terminer celles qui sont les plus descriptives ou les plus efficaces. Les m�triques cl�s varient en fonction de la plate-forme sur laquelle l'application est d�ploy�e et des t�ches effectu�es par l'application.

Il est peu probable que vous trouviez une seule m�trique indiquant que votre application n�cessite un scaling ou qu'un service particulier n'est pas op�rationnel. Il s'agit souvent d'une combinaison de facteurs qui, ensemble, indiquent un certain ensemble de conditions. Cloud�Monitoring vous permet de cr�er des m�triques personnalis�es pour faciliter la capture de ces conditions. Le livre sur l'ing�nierie SRE de Google pr�conise de surveiller un syst�me visible par l'utilisateur � l'aide de quatre signaux cl�s�: la latence, le trafic, les erreurs et la saturation.

Tenez �galement compte de la tol�rance aux anomalies. L'utilisation d'une valeur moyenne ou m�diane pour mesurer l'�tat ou les performances n'est peut-�tre pas la meilleure solution, car ces mesures peuvent cacher de profonds d�s�quilibres. Il est donc important de tenir compte de la répartition d'une métrique. Le 99e centile peut être une mesure plus informative que la moyenne.

Définir des objectifs de niveau de service (SLO)

Vous pouvez utiliser les métriques collectées par votre système de surveillance pour définir des objectifs de niveau de service (SLO, Service Level Objective). Les SLO spécifient un niveau cible de performances ou de fiabilité pour votre service. Les SLO sont un élément essentiel des pratiques d'ingénierie SRE. Ils sont décrits en détail dans le chapitre consacré aux objectifs de niveau de service dans le livre sur l'ingénierie SRE, ainsi que dans celui dédié à la mise en œuvre des SLO dans le manuel d'ingénierie SRE.

Vous pouvez utiliser la surveillance des services pour d�finir des SLO en fonction des m�triques de Cloud�Monitoring. Vous pouvez cr�er des r�gles d'alerte sur les SLO pour vous indiquer si vous risquez d'en enfreindre un.

Stocker les m�triques

Les m�triques de votre syst�me de surveillance sont utiles � court terme pour faciliter les v�rifications d'�tat en temps r�el ou �tudier les probl�mes r�cents. Cloud�Monitoring conserve vos m�triques pendant plusieurs semaines afin de r�pondre au mieux � ces cas d'utilisation.

Toutefois, il peut �galement �tre int�ressant de stocker vos m�triques de surveillance pour une analyse � plus long terme. L'acc�s � un enregistrement historique peut vous aider � adopter une approche bas�e sur les donn�es pour affiner l'architecture de votre application. Vous pouvez utiliser les donn�es collect�es pendant et apr�s une panne pour identifier les goulots d'�tranglement et les interd�pendances dans vos applications. Vous pouvez �galement cr�er et valider des tests pertinents � l'aide de ces donn�es.

Les donn�es historiques permettent �galement de v�rifier si votre application r�pond aux objectifs commerciaux au cours de p�riodes cl�s. Par exemple, les donn�es peuvent vous aider � analyser le scaling de votre application lors d'�v�nements promotionnels � trafic �lev� au cours des derniers trimestres, voire d'ann�es.

Pour en savoir plus sur l'exportation et le stockage des m�triques, consultez la page Exportation de m�triques Cloud�Monitoring.

D�terminer le profil de scaling

Vous souhaitez que votre application atteigne ses objectifs en termes d'exp�rience utilisateur et de performances sans surprovisionner les ressources.

Le sch�ma suivant repr�sente le profil de scaling d'une application de mani�re simplifi�e. L'application conserve un niveau de ressources de base et utilise l'autoscaling pour �voluer en fonction de la demande.

�quilibrer les co�ts et l'exp�rience utilisateur

Prendre la d�cision de faire �voluer votre application d�pend essentiellement de l'�quilibrage des co�ts et de l'exp�rience utilisateur. Vous devez d�terminer le niveau de performances minimal acceptable et, �ventuellement, d�finir un plafond. Ces seuils varient d'une application � l'autre, et �ventuellement pour diff�rents composants ou services au sein d'une m�me application.

Par exemple, une application Web ou mobile destin�e aux consommateurs doit fixer des objectifs stricts en termes de latence. Une étude montre que même de légers retards peuvent avoir un impact négatif sur la façon dont les utilisateurs perçoivent votre application, entraînant une baisse des conversions et des inscriptions. Par conséquent, il est important de s'assurer que votre application dispose d'une capacité de diffusion suffisante pour répondre rapidement aux requêtes des utilisateurs. Dans ce cas, les coûts plus élevés liés à l'exécution d'un plus grand nombre de serveurs Web peuvent être justifiés.

Le rapport coût-performances peut être différent pour une application interne qui n'est pas critique pour l'activité, car ses utilisateurs sont susceptibles d'être plus tolérants aux petits retards. Par conséquent, votre profil de scaling peut être moins agressif. Dans ce cas, il peut s'avérer plus judicieux de limiter les coûts que d'optimiser l'expérience utilisateur.

Définir des ressources de référence

Un autre élément clé de votre profil de scaling est le choix d'un ensemble minimal de ressources appropriées.

Les machines virtuelles Compute Engine ou les clusters GKE nécessitent généralement un certain temps pour effectuer le scaling à la hausse, car de nouveaux nœuds doivent être créés et initialisés. Par conséquent, il peut être nécessaire de maintenir un ensemble minimal de ressources, même en l'absence de trafic. Là encore, l'étendue des ressources de référence dépend du type d'application et du profil du trafic.

À l'inverse, les technologies sans serveur telles qu'App Engine, les fonctions Cloud Run et Cloud Run sont conçues pour effectuer le scaling à zéro instance, démarrer et évoluer rapidement, même lors du démarrage à froid de l'instance. Selon le type d'application et le profil du trafic, ces technologies peuvent offrir de bonnes performances pour certaines parties de votre application.

Configurer l'autoscaling

L'autoscaling vous aide à effectuer le scaling automatique des ressources de calcul consommées par votre application. L'autoscaling se produit généralement en cas de dépassement de métriques ou lorsque des conditions sont remplies. Par exemple, si la latence des requêtes vers votre niveau Web commence à dépasser une certaine valeur, vous pouvez ajouter automatiquement des machines pour augmenter la capacité de diffusion.

De nombreux produits de calcul Google Cloud offrent des fonctionnalités d'autoscaling. Les services gérés sans serveur tels que Cloud Run, les fonctions Cloud Run et App Engine sont conçus pour évoluer rapidement. Ces services proposent souvent des options de configuration pour limiter ou influencer le comportement de l'autoscaling, mais en général, une grande partie de celui-ci est dissimulé à l'opérateur.

Compute Engine et GKE fournissent davantage d'options pour contrôler le comportement du scaling. Avec Compute Engine, vous pouvez effectuer le scaling en fonction de différentes entrées, y compris les métriques personnalisées de Cloud Monitoring et la capacité de diffusion de l'équilibreur de charge. Vous pouvez définir des limites minimale et maximale pour le comportement du scaling, ainsi qu'une règle d'autoscaling comportant plusieurs signaux pour gérer différents scénarios. Comme avec GKE, vous pouvez configurer l'autoscaler du cluster pour ajouter ou supprimer des nœuds en fonction des métriques de la charge de travail ou du pod, ou des métriques externes au cluster.

Nous vous recommandons de configurer le comportement de l'autoscaling en fonction des principales métriques de l'application, de votre profil de coût et du niveau minimal de ressources que vous avez défini.

Réduire le délai de démarrage

Pour que le scaling soit efficace, il doit se produire assez rapidement pour gérer l'augmentation de la charge. Cela est particulièrement vrai lorsque vous ajoutez de la capacité de calcul ou de diffusion.

Utiliser des images préconçues

Si votre application s'exécute sur des VM Compute Engine, vous devrez probablement installer un logiciel et configurer les instances pour exécuter votre application. Bien que vous puissiez configurer de nouvelles instances à l'aide de scripts de démarrage, un moyen plus efficace consiste à créer une image personnalisée. Une image personnalisée est un disque de démarrage que vous avez défini avec le logiciel et la configuration spécifiques à l'application.

Pour en savoir plus sur la gestion des images, consultez Bonnes pratiques pour la gestion des images.

Une fois votre image créée, vous pouvez définir un modèle d'instance. Les modèles d'instances combinent l'image du disque de démarrage, le type de machine et d'autres propriétés de l'instance. Vous pouvez ensuite utiliser un modèle d'instance pour créer des instances de VM individuelles ou un groupe d'instances géré. Les modèles d'instances constituent un moyen pratique d'enregistrer la configuration d'une instance de VM afin de l'utiliser ultérieurement pour créer des instances de VM identiques.

Bien que la création d'images personnalisées et de modèles d'instances puisse augmenter la vitesse de déploiement, elle peut également entraîner des coûts de maintenance supplémentaires en raison de la mise à jour plus fréquente des images. Pour en savoir plus, consultez les documents concernant l'équilibrage de la configuration de l'image et la vitesse de déploiement.

Conteneuriser l'application

Une alternative à la création d'instances de VM personnalisées consiste à conteneuriser votre application. Un container est un package logiciel exécutable, autonome et léger qui inclut tous les éléments nécessaires à l'exécution d'une application : du code, un environnement d'exécution, des outils système, des bibliothèques système et des paramètres. Ces caractéristiques facilitent le transfert, le déploiement et le scaling des applications en conteneur, bien plus que les machines virtuelles. Les conteneurs sont généralement rapides à démarrer. Ils sont donc adaptés aux applications évolutives et résilientes.

Google Cloud propose plusieurs services pour exécuter les conteneurs de votre application. Cloud Run fournit une plate-forme de calcul gérée sans serveur pour héberger vos conteneurs sans état. L'environnement flexible App Engine héberge vos conteneurs dans une infrastructure Platform as a Service (PaaS) gérée. GKE fournit un environnement Kubernetes géré permettant d'héberger et d'organiser vos applications en conteneur. Vous pouvez également exécuter les conteneurs de votre application sur Compute Engine lorsque vous avez besoin d'assurer un contrôle complet sur votre environnement de conteneurs.

Optimiser le démarrage de l'application

En plus de vous assurer que votre infrastructure et votre application peuvent être déployées aussi efficacement que possible, il est important de veiller à ce que votre application soit mise en ligne rapidement.

Les optimisations appropriées pour votre application dépendent de ses caractéristiques et de la plate-forme d'exécution. Il est important de procéder comme suit :

• Recherchez et supprimez les goulots d'étranglement en profilant les sections critiques de votre application qui sont appelées au démarrage.
• Diminuez le délai de démarrage initial en mettant en œuvre des techniques comme l'initialisation tardive, en particulier pour les ressources coûteuses.
• Minimisez les dépendances de l'application qui doivent éventuellement être chargées au d�marrage.

Privil�gier les architectures modulaires

Vous pouvez accro�tre la flexibilit� de votre application en choisissant des architectures qui permettent aux composants d'�tre d�ploy�s, g�r�s et mis � l'�chelle ind�pendamment. Ce mod�le peut �galement am�liorer la r�silience de votre application en supprimant les points de d�faillance uniques.

Décomposer l'application en services indépendants

Vous pouvez accroître la flexibilité de votre application en la développant sous forme d'ensemble de services indépendants faiblement couplés. Une conception faiblement couplée permet de lancer et de déployer vos services de manière indépendante. En plus de nombreux autres avantages, cette approche permet à ces services d'utiliser différentes piles technologiques et d'être gérés par plusieurs équipes. Cette approche faiblement couplée est au cœur des modèles d'architectures, tels que les architectures de microservices et orientées services (SOA).

Lorsque vous envisagez de fixer des limites à vos services, il est primordial de prendre en compte les exigences de disponibilité et d'évolutivité. Par exemple, si un composant donné a une exigence de disponibilité ou un profil de scaling différent de vos autres composants, il peut être un bon candidat pour un service autonome.

Opter pour le sans état

Une application ou un service sans état ne conserve pas de données ou d'état persistants. Un modèle sans état vous permet de gérer chaque requête ou interaction avec le service, indépendamment des requêtes précédentes. Ce modèle facilite l'évolutivité et la récupération. Vous pouvez ainsi développer, réduire ou redémarrer le service sans perdre les données requises pour gérer les processus ou les requêtes en cours de transfert. La caractéristique sans état est particulièrement importante lorsque vous utilisez un autoscaler, car les instances, les nœuds ou les pods hébergeant le service peuvent être créés et détruits de manière inattendue.

Il se peut que tous vos services ne soient pas sans état. Dans ce cas, indiquez de façon explicite les services qui nécessitent un état. En distinguant clairement les services sans état et avec état, vous pouvez faciliter l'évolutivité des services sans état tout en adoptant une approche plus réfléchie pour les services avec état.

Gérer la communication entre les services

Un des objectifs d'une architecture de microservices distribuée est de gérer la communication entre les services. Il est probable que les interdépendances des services soient plus nombreuses à mesure que votre réseau de services se développe. Vous ne voulez pas que la défaillance d'un service entraîne celle d'autres services, parfois appelée défaillance en cascade.

Vous pouvez réduire le trafic vers un service surchargé ou défaillant en adoptant des techniques telles qu'un modèle de disjoncteur, des intervalles exponentiels entre les tentatives et une dégradation élégante. Ces modèles augmentent la résilience de votre application soit en facilitant la r�cup�ration des services surcharg�s, soit en g�rant consciencieusement l'�tat des erreurs. Pour en savoir plus, consultez le chapitre G�rer les d�faillances en cascade du livre sur l'ing�nierie SRE de Google.

L'utilisation d'un maillage de services peut vous aider � g�rer le trafic entre vos services distribu�s. Un maillage de services est un logiciel qui relie les services entre eux et permet de dissocier la logique m�tier de la mise en r�seau. Il offre g�n�ralement des fonctionnalit�s de r�silience, telles que de nouvelles tentatives d'ex�cution des requ�tes, des basculements et des disjoncteurs.

Utiliser une base de donn�es et une technologie de stockage appropri�es

Certaines bases de donn�es et certains types de stockage sont difficiles � faire �voluer et � rendre r�silients. Assurez-vous que vos choix concernant la base de donn�es ne limitent pas la disponibilit� et l'�volutivit� de votre application.

�valuer les besoins de la base de donn�es

Le mod�le de conception de l'application en tant qu'ensemble de services ind�pendants s'�tend �galement aux bases de donn�es et au stockage. Il peut s'av�rer judicieux de choisir diff�rents types de stockage pour plusieurs parties de votre application de sorte que les espaces de stockage soient h�t�rog�nes.

Souvent, les applications traditionnelles fonctionnent exclusivement avec des bases de donn�es relationnelles. Les bases de donn�es relationnelles offrent des fonctionnalit�s utiles, telles que les transactions, la coh�rence forte, l'int�grit� r�f�rentielle et l'interrogation complexe des tables. Les fonctionnalit�s des bases de donn�es relationnelles sont donc parfaitement adapt�es � de nombreuses fonctionnalit�s d'application courantes. Cependant, les bases de donn�es relationnelles pr�sentent �galement certaines contraintes. Elles sont g�n�ralement difficiles � faire �voluer et n�cessitent une gestion minutieuse de la configuration de haute disponibilit�. Une base de donn�es relationnelle n'est peut-�tre pas le meilleur choix pour l'ensemble des besoins de votre base de donn�es.

Les bases de donn�es non relationnelles, souvent appel�es "bases de donn�es NoSQL", reposent sur une approche diff�rente. Bien que les d�tails varient selon les produits, les bases de donn�es NoSQL sacrifient g�n�ralement certaines fonctionnalit�s des bases de donn�es relationnelles au profit d'une disponibilit� et d'une �volutivit� accrues. Selon le th�or�me CAP, les bases de donn�es NoSQL mettent souvent l'accent sur la disponibilit� au d�triment de la coh�rence.

La pertinence d'une base de donn�es NoSQL d�pend souvent du degr� de coh�rence requis. Si le mod�le de donn�es d'un service particulier ne n�cessite pas toutes les fonctionnalit�s d'un SGBDR et peut �tre con�u pour �tre coh�rent � terme, opter pour une base de donn�es NoSQL peut offrir une disponibilité et une évolutivité accrues.

Dans le domaine de la gestion des données, les bases de données relationnelles et non relationnelles sont souvent considérées comme des technologies complémentaires et non concurrentes. En utilisant ces deux types de bases de données de manière stratégique, les entreprises peuvent exploiter leurs atouts respectifs pour obtenir des résultats optimaux en termes de stockage, de récupération et d'analyse des données.

En plus d'une gamme de bases de données relationnelles et NoSQL, Google Cloud intègre également Spanner, une base de données à cohérence forte, hautement disponible et distribuée à l'échelle mondiale compatible avec SQL. Pour en savoir plus sur le choix d'une base de données appropriée dans Google Cloud, consultez la page Bases de données Google Cloud.

Mettre en œuvre la mise en cache

L'objectif principal d'un cache est d'optimiser la récupération des données en limitant l'accès à la couche de stockage sous-jacente plus lente.

La mise en cache améliore l'évolutivité en limitant la dépendance au stockage sur disque. Étant donné que les requêtes peuvent être traitées à partir de la mémoire, la latence des requêtes envoyées à la couche de stockage est réduite, ce qui permet généralement à votre service de gérer davantage de requêtes. De plus, la mise en cache peut réduire la charge sur les services en aval de votre application, en particulier les bases de données, ce qui permet aux autres composants qui interagissent avec ce service d'évoluer plus facilement ou pas du tout.

La mise en cache peut également augmenter la résilience à l'aide de techniques comme la dégradation élégante. Si la couche de stockage sous-jacente est surchargée ou indisponible, le cache peut continuer à gérer les requêtes. Même si les données renvoyées par le cache peuvent être incomplètes ou ne pas être à jour, cela peut être acceptable pour certains scénarios.

Memorystore pour Redis fournit un service entièrement géré, alimenté par le datastore en mémoire Redis. Memorystore pour Redis fournit un accès de faible latence et un débit élevé pour les données très consultées. Il peut être déployé dans une configuration de haute disponibilité incluant la réplication interzone et le basculement automatique.

Moderniser les processus et la culture de développement

DevOps peut être considéré comme une vaste collection de processus, de culture et d'outils permettant d'augmenter l'agilité et de réduire le temps de production des applications et des fonctionnalités, en levant le cloisonnement entre les équipes de développement et d'exploitation. L'objectif des techniques DevOps est d'améliorer la qualité et la fiabilité des logiciels.

Ce document n'aborde pas DevOps de manière détaillée, mais certains aspects essentiels liés à l'amélioration de la fiabilité et de la résilience de votre application sont décrits dans les sections suivantes. Pour en savoir plus, consultez la page DevOps de Google Cloud.

Concevoir pour la testabilité

Le test automatisé est un élément clé des pratiques modernes de livraison de logiciels. La capacité à exécuter un ensemble complet de tests unitaires, d'intégration et système est essentielle pour vérifier que votre application se comporte comme prévu et qu'elle peut passer à l'étape suivante du cycle de déploiement. La testabilité est un critère de conception clé pour votre application.

Nous vous recommandons de privilégier les tests unitaires pour la majeure partie de vos tests, car ils sont rapides à exécuter et généralement simples à gérer. Nous vous recommandons également d'automatiser l'intégration de niveau supérieur et les tests système. Ces tests sont considérablement simplifiés si vous appliquez des techniques d'Infrastructure as Code, car des environnements et des ressources de test dédiés peuvent être créés à la demande, puis supprimés une fois les tests terminés.

À mesure que le pourcentage de votre codebase couvert par les tests augmente, vous réduisez les incertitudes et la diminution potentielle de la fiabilité de chaque modification du code. En optant pour une couverture de test adéquate, vous pouvez apporter davantage de modifications avant que la fiabilité ne passe en dessous d'un niveau acceptable.

Les tests automatisés font partie intégrante de l'intégration continue. L'exécution d'un ensemble complet de tests automatisés sur chaque commit de code permet d'obtenir un retour rapide sur les modifications, améliorant ainsi la qualité et la fiabilité de votre logiciel. Les outils natifs de Google Cloud comme Cloud Build et les outils tiers tels que Jenkins vous aident à mettre en œuvre l'intégration continue.

Automatisez vos déploiements

L'intégration continue et l'automatisation complète des tests garantissent la stabilité de votre logiciel. Une fois mises en œuvre, la prochaine étape consiste à automatiser le déploiement de votre application. Le niveau d'automatisation du déploiement varie en fonction de la maturité de votre organisation.

Il est essentiel de choisir une stratégie de déploiement appropriée afin de minimiser les risques associés au déploiement d'un nouveau logiciel. En appliquant une stratégie adaptée, vous pouvez progressivement accroître l'exposition des nouvelles versions à un public plus large, tout en v�rifiant le comportement tout au long du processus. Vous pouvez �galement d�finir des dispositions claires pour le rollback en cas de probl�me.

Adopter des pratiques SRE pour faire face aux d�faillances

Pour les applications distribu�es fonctionnant � grande �chelle, il est courant de rencontrer un certain degr� de d�faillance dans un ou plusieurs composants. Si vous vous conformez aux mod�les d�crits dans ce document, votre application pourra mieux g�rer les perturbations dues � une version logicielle d�fectueuse, � l'arr�t inattendu des machines virtuelles ou m�me � une panne d'infrastructure affectant une zone entière.

Cependant, même avec une conception d'application minutieuse, vous rencontrez inévitablement des événements inattendus qui nécessitent une intervention humaine. Si vous mettez en place des processus structurés pour gérer ces événements, vous pouvez considérablement réduire leur impact et les résoudre plus rapidement. De plus, l'examen des causes et des réponses à l'événement vous permet de protéger votre application contre des événements futurs similaires.

L'implémentation de processus solides de gestion des incidents et la réalisation d'analyses post-mortem sont les principes clés de SRE. Même si l'ensemble des pratiques de Google SRE ne peuvent pas être mises en œuvre dans votre organisation, vous pouvez améliorer la résilience de votre application en n'appliquant que certaines d'entre elles. Les annexes du livre sur l'ingénierie SRE contiennent des modèles qui peuvent vous aider à élaborer vos processus.

Valider et examiner l'architecture

Le comportement des utilisateurs, les profils de trafic et même les priorités commerciales peuvent changer à mesure que votre application évolue. De même, d'autres services ou infrastructures dont votre application dépend peuvent évoluer. Par conséquent, il est important de tester et de valider régulièrement la résilience et l'évolutivité de votre application.

Tester la résilience

Il est essentiel de vérifier que votre application réagit aux défaillances comme vous le souhaitez. Le meilleur moyen d'éviter les défaillances est de les documenter et d'en tirer des leçons.

La simulation et la documentation des défaillances sont complexes. En plus de vérifier le comportement de votre application ou de votre service, vous devez également vous assurer que les alertes attendues et les métriques appropriées sont générées. Nous vous recommandons de suivre une approche structurée, dans laquelle vous documentez les défaillances simples avant de les signaler.

Par exemple, vous pouvez valider et documenter le comportement � chaque �tape en proc�dant comme suit�:

• Documenter les d�faillances intermittentes
• Bloquer l'acc�s aux d�pendances du service
• Bloquer toutes les communications r�seau
• Arr�ter les h�tes

Pour en savoir plus, regardez la vid�o Breaking your systems to make them unbreakable (Faire planter vos syst�mes pour les rendre r�sistants) de la conf�rence Google�Cloud Next�2019.

Si vous utilisez un maillage de services comme Istio pour g�rer les services de votre application, vous pouvez injecter des pannes au niveau de la couche d'application au lieu de d�truire les pods ou les machines, ou corrompre les paquets au niveau de la couche TCP. Vous pouvez introduire des retards pour simuler la latence du r�seau ou un syst�me surcharg� en amont. Vous pouvez �galement mettre en place des abandons, qui imitent des d�faillances dans les syst�mes en amont.

Tester le comportement du scaling

Nous vous recommandons d'utiliser des tests automatiques non fonctionnels pour v�rifier que votre application �volue comme pr�vu. Cette v�rification est souvent associ�e � des tests de performances ou de charge. Vous pouvez utiliser des outils simples tels que hey pour envoyer la charge � une application Web. Pour obtenir un exemple plus d�taill� qui montre comment effectuer des tests de charge sur un point de terminaison REST, consultez Tests de charge distribu�s � l'aide de Google Kubernetes�Engine.

Une approche courante consiste � s'assurer que les m�triques principales respectent les niveaux attendus pour diff�rentes charges. Par exemple, si vous testez l'�volutivit� de votre niveau Web, vous pouvez mesurer la latence moyenne des requ�tes pour les pics de requ�tes des utilisateurs. De m�me, pour une fonctionnalit� de traitement backend, vous pouvez �valuer le temps de traitement moyen des t�ches lorsque leur nombre augmente soudainement.

Vous souhaitez par ailleurs que vos tests estiment le nombre de ressources cr��es pour g�rer la charge de test dans la plage pr�vue. Par exemple, vos tests peuvent v�rifier que le nombre de VM cr��es pour g�rer certaines t�ches de backend ne d�passe pas une certaine valeur.

Il est �galement important de tester les cas sp�ciaux. Quel est le comportement de votre application ou de votre service lorsque les limites maximales de scaling sont atteintes�? Que se passe-t-il si votre service �volue � la baisse et que la charge augmente de nouveau soudainement ?

Toujours avoir un œil sur l'architecture

Le monde de la technologie évolue rapidement, et cela vaut tout particulièrement pour le cloud. Des produits et des fonctionnalités sont lancés fréquemment, de nouveaux modèles apparaissent, et les demandes de vos utilisateurs et des personnes impliquées en interne ne cessent d'augmenter.

Vous devez toujours trouver des moyens d'affiner, de simplifier et d'améliorer l'architecture de vos applications, comme décrit dans l'article de blog Principes de l'architecture cloud native. Les systèmes logiciels sont vivants et doivent s'adapter à l'�volution de vos priorit�s.

�tape suivante

• Lisez l'article de blog Principes de l'architecture cloud native.
• Lisez les livres sur l'ing�nierie SRE pour en savoir plus sur la gestion de l'environnement de production de Google.
• D�couvrez comment DevOps sur Google�Cloud peut am�liorer la qualit� et la fiabilit� de vos logiciels.
• D�couvrez des architectures de r�f�rence, des sch�mas et des bonnes pratiques concernant Google�Cloud. Consultez notre Centre d'architecture cloud.