Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pilier d’excellence opérationnelle
Le pilier de l'excellence opérationnelle du AWS Well-Architected Framework se concentre sur le fonctionnement et le suivi des systèmes, ainsi que sur l'amélioration continue des processus et des procédures afin de créer de la valeur commerciale. Le pilier de l'excellence opérationnelle inclut la capacité à soutenir le développement et à gérer efficacement les charges de travail, ainsi qu'à mieux comprendre leur fonctionnement.
Vous pouvez réduire la complexité opérationnelle grâce à des charges de travail autoréparables, qui détectent et corrigent la plupart des problèmes sans intervention humaine. Pour atteindre cet objectif, suivez les meilleures pratiques décrites dans cette section. Utilisez CloudWatch les métriques Amazon pour Amazon Timestream pour InfluxDB, le point de terminaison des métriques natives d'InfluxDB, et les mécanismes permettant de réagir lorsque votre APIs charge de travail s'écarte du comportement attendu.
Cette discussion sur le pilier de l'excellence opérationnelle met l'accent sur les domaines clés suivants :
-
Infrastructure en tant que code (IaC)
-
Gestion des modifications
-
Stratégies de résilience
-
Gestion des incidents
-
Enregistrement et surveillance à des fins d'audit
Automatisez le déploiement en utilisant une approche IaC
Les meilleures pratiques pour automatiser le déploiement sur Timestream pour InfluxDB à l'aide d'iAC sont les suivantes :
-
Appliquez IaC pour déployer Timestream pour InfluxDB chaque fois que possible. Pour une configuration cohérente de l'environnement AWS Cloud Development Kit (AWS CDK), utilisez un AWS CloudFormationmodèle ou HashiCorp Terraform
pour créer toutes les ressources requises pour votre instance. -
Automatisez les procédures opérationnelles Timestream pour InfluxDB, telles que le redimensionnement des instances.
-
Utilisez des balises pour ajouter des métadonnées à votre flux temporel pour les ressources InfluxDB et suivez l'utilisation en fonction des balises. Pour plus d'informations, consultez la section Marquage d'Amazon Timestream pour InfluxDB.
Effectuez des modifications fréquentes, mineures et réversibles
Les recommandations suivantes mettent l'accent sur de petites modifications réversibles afin de minimiser la complexité et de réduire le risque d'interruption de la charge de travail :
-
Stockez les modèles et les scripts IaC dans un service de contrôle de source, tel GitHub que ou. GitLab Ne stockez pas les AWS informations d'identification dans le contrôle de source.
-
Exigez que les déploiements iAc utilisent un service d'intégration et de livraison continues (CI/CD), tel que ou. AWS CodeDeployAWS CodeBuild Ces services compilent, testent et déploient du code dans un environnement hors production qui contient une instance InfluxDB éphémère avant d'affecter votre instance InfluxDB de production.
-
Testez les requêtes d'infrastructure et d'application dans un environnement inférieur avant de les déployer en production. Cela minimise le risque d'interruption et permet de garantir qu'ils fonctionnent bien avec votre charge de travail et votre évolutivité.
Anticipez les défaillances
Une infrastructure autoréparante illustre l'excellence opérationnelle en anticipant les défaillances et en tentant de résoudre les problèmes sans intervention. Les recommandations suivantes vous aident à atteindre cette maturité avec Timestream pour InfluxDB :
-
Utilisez des métriques pour surveiller l'utilisation de la mémoire, du processeur et du stockage. Vous pouvez configurer CloudWatch pour être informé quand les habitudes d'utilisation changent ou quand vous arrivez au bout de votre capacité de déploiement. De cette façon, vous pouvez maintenir les performances et la disponibilité du système.
-
Augmentez la taille de votre instance de base de données lorsque vous approchez de la limite de ressources. Vous devrez disposer de capacités de mémoire et de stockage supplémentaires pour vous adapter aux hausses imprévues des besoins de vos applications.
-
Si la charge de travail de votre base de données est I/O supérieure à ce que vous avez provisionné, la restauration après un basculement ou une défaillance de la base de données sera lente. Pour augmenter la I/O capacity of a DB instance, migrate to a different DB instance that has higher I/O capacité.
-
Si votre application cliente met en cache les données DNS de vos instances de base de données, définissez une valeur time-to-live (TTL) inférieure à 30 secondes. L’adresse IP sous-jacente d’une instance de base de données peut changer après un basculement. La mise en cache des données DNS pendant une période prolongée peut entraîner des échecs de connexion. Il se peut que votre application essaie de se connecter à une adresse IP qui n'est plus en service.
-
Si votre application doit survivre à une Région AWS panne complète, envisagez de configurer la réplication ou d'écrire dans une autre région dans le cadre de vos plans de reprise après sinistre (DR). Comprenez les limites lors de la configuration de la réplication. Pour plus d'informations sur la réplication, consultez la documentation InfluxDB.
Tirez les leçons de toutes les défaillances opérationnelles
Une infrastructure d'autoréparation est un effort à long terme que vous développez par itérations lorsque de rares problèmes surviennent ou que les réponses ne sont pas aussi efficaces que vous le souhaitez. Pour vous concentrer sur la mise en place d'une infrastructure autoréparante, adoptez les pratiques suivantes :
-
Favorisez l'amélioration en tirant les leçons de tous les échecs.
-
Partagez ce que vous avez appris au sein des équipes et de l'organisation. Si plusieurs équipes d'une organisation utilisent Timestream pour InfluxDB, créez un salon de discussion ou un groupe d'utilisateurs commun pour partager les leçons apprises et les meilleures pratiques.
Utilisez les fonctionnalités de journalisation pour surveiller les activités non autorisées ou anormales
Pour observer des modèles de performance et d'activité anormaux, prenez en compte les pratiques suivantes :
-
Activez la livraison des journaux pour stocker les journaux InfluxDB dans Amazon Simple Storage Service (Amazon S3). Les journaux InfluxDB enregistrent des informations qui peuvent aider à vérifier les points suivants :
-
Temps de réponse
-
Détails du compactage
-
Toute erreur critique ou tout avertissement rencontré par le système
Consultez les journaux pour détecter tout accès non autorisé ou toute anomalie. Dans l'ensemble, la journalisation fournit des informations de diagnostic pour le dépannage.
-
Timestream for InfluxDB prend en charge la journalisation des actions du plan de contrôle en utilisant. AWS CloudTrail Pour plus d'informations, consultez Logging Timestream pour les appels d'API InfluxDB avec. AWS CloudTrail
-
Vous pouvez surveiller
CPUUtilizationMemoryUtilization, et lesDiskUtilizationmétriques depuis Timestream/InfluxDB > < Namespace > in. CloudWatch
Pour plus d'informations, consultez la documentation Timestream for InfluxDB.
