Lorsqu'une application est réécrite de façon à utiliser des microservices, le nombre de composants et de points de terminaison associés à une seule transaction utilisateur est en hausse. Par conséquent, l'observabilité est essentielle pour le bon fonctionnement des services fournis aux utilisateurs. Cette architecture de référence montre comment capturer des informations de trace dans les applications de microservices à l'aide d'OpenTelemetry et de Cloud Trace.
Ce document est destiné aux développeurs, aux ingénieurs SRE et aux ingénieurs DevOps qui souhaitent comprendre les principes de base du traçage distribué et qui souhaitent appliquer ces principes à leurs services pour améliorer leur observabilité.
Architecture
Le schéma suivant représente l'architecture d'une application qui met en œuvre cette architecture.
Comme le montre le schéma précédent, cette architecture comprend deux clusters GKE. Vous déployez une application sur chacun des clusters. Le trafic utilisateur est envoyé vers l'application de frontend, sur le cluster de frontend. Le pod de frontend du cluster de frontend communique avec le pod de backend du cluster de backend. Le pod de backend appelle un point de terminaison d'API externe.
Les données d'observabilité sont exportées vers Cloud Trace, qui suit la propagation des requêtes dans les applications.
Considérations de conception
Pour les services exécutés sur Kubernetes, vous pouvez utiliser un maillage de services tel que Istio pour permettre le traçage distribué du trafic de service à service sans instrumentation dédiée. Cependant, vous pouvez avoir l'une des exigences suivantes:
- Vous souhaitez mieux contrôler les traces que celles fournies par Istio.
- Vous devrez peut-être capturer les informations internes de l'application dans les informations de trace.
- Vous devrez peut-être tracer le code qui ne s'exécute pas sur Kubernetes.
Pour ces cas d'utilisation, vous pouvez utiliser OpenTelemetry, une bibliothèque Open Source qui peut ajouter une instrumentation aux applications de microservices distribuées afin de collecter des traces, des métriques et des journaux sur une grande variété de langues, plates-formes et environnements.
Comprendre les traces, les délais et le contexte
Le concept de traçage distribué est décrit dans l'étude sur Dapper publiée par Google. Comme décrit dans l'article, le schéma suivant montre cinq segments dans une trace.
Une trace correspond au total des informations qui décrivent la manière dont un système distribué répond à une requête utilisateur. Les traces sont composées de segments, dont chacun représente une paire spécifique, constituée d'une requête et d'une réponse, impliquée dans le traitement de la demande de l'utilisateur. Le segment parent décrit la latence observée par l'utilisateur final. Chacun des segments enfants décrit la façon dont un service particulier du système distribué a été appelé et traité. Des informations de latence collectées pour chacun d'eux sont également indiquées.
Le schéma illustre une requête de frontend unique qui effectue deux requêtes de backend. Le second appel de backend nécessite deux appels d'aide. Chaque appel est associé à son ID de segment et à l'ID du segment parent.
L'une des difficultés du traçage dans des systèmes distribués réside dans le fait que les informations relatives à la requête de frontend d'origine ne sont pas automatiquement transférées lorsque des requêtes ultérieures sont envoyées à plusieurs services de backend.
Avec certains outils (par exemple, en langage Go), vous pouvez effectuer des requêtes en contexte, à savoir l'adresse IP et les identifiants du cluster. OpenTelemetry étend le concept de contexte pour inclure le contexte de segment, ce qui signifie que des informations supplémentaires sont chargées dans l'en-tête HTTP. Les informations sur le segment parent peuvent ensuite être incluses avec chaque requête ultérieure. Vous pouvez ensuite ajouter des segments enfants pour composer la trace globale, ce qui vous permet de voir comment la requête utilisateur a traversé le système, jusqu'à son traitement côté utilisateur.
Déploiement
Pour déployer cette architecture, consultez la page Déployer le traçage distribué pour observer la latence des microservices.
Étapes suivantes
- Découvrez OpenTelemetry.
- Apprenez-en plus sur les fonctionnalités DevOps associées à cette architecture :
- Effectuez l'évaluation DevOps rapide pour comprendre votre position par rapport au reste du secteur.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.