View a markdown version of this page

Pilier d’optimisation des coûts - AWS Conseils prescriptifs
Comprendre les exigences et les coûts de votre cas d'utilisationSélection des ressources en tenant compte des coûtsÉvolutivité pour répondre aux besoins de l'entreprise sans trop dépenserStockage et transfert de données adaptés

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’optimisation des coûts

Le pilier d'optimisation des coûts du AWS Well-Architected Framework vise à éviter les coûts inutiles et à créer des architectures de manière optimisée en termes de coûts. Les recommandations suivantes peuvent vous aider à respecter les principes de conception d'optimisation des coûts et les meilleures pratiques architecturales pour Amazon Timestream for InfluxDB.

Le pilier de l'optimisation des coûts se concentre sur les domaines clés suivants :

  • Comprendre les exigences et les coûts de votre cas d'utilisation

  • Sélection des ressources en tenant compte des coûts

  • Évolutivité pour répondre aux besoins de l'entreprise sans trop dépenser

  • Stockage et transfert de données adaptés

Comprendre les exigences et les coûts de votre cas d'utilisation

Nous recommandons de ne pas utiliser Timestream pour InfluxDB dans les cas d'utilisation suivants :

  • Si votre modèle de données contient des données relationnelles, Timestream pour InfluxDB n'est pas la bonne solution.

  • Si vous ne pouvez pas utiliser de filtres temporels dans vos requêtes, Influx scannera toutes les séries, ce qui est inefficace.

Sélection des ressources en tenant compte des coûts

Les coûts des instances InfluxDB sont basés sur un taux horaire pour les heures d'exécution de votre instance. Les instances représentent, en moyenne, 85 % du coût total d'exploitation d'une base de données AWS, de sorte qu'un dimensionnement correct peut avoir des implications financières importantes. Le meilleur moyen de dimensionner correctement les instances est de tester les performances des applications :

  • Les CPUUtilization et sont-ils MemoryUtilization constamment élevés ou bas ?

  • Quel est le juste équilibre entre prix et performance ?

Les coûts des instances évoluent de manière linéaire. Le coût horaire de l'db.influx.2xlargeinstance est le double de celui de l'db.influx.xlargeinstance, même si l'allocation de ressources y est également deux fois plus élevée. Le coût horaire de l'db.influx.16xlargeinstance est 16 fois supérieur à celui de l'db.influx.xlargeinstance.

Estimez le nombre d'écritures et de lectures correspondant à votre charge de travail pour une période donnée (seconde, minute, heure ou jour). Timestream pour les instances InfluxDB prend en charge 50 000 à plus de 500 000 écritures par seconde et 10 à 100 requêtes par seconde (QPS) selon le type d'instance. Par exemple, il prend db.influx.2xlarge généralement en charge jusqu'à 150 000 écritures par seconde et environ 25 QPS. Avec un modèle de données et des requêtes efficaces, il peut dépasser ces performances. Si vos besoins varient en fonction de l'heure de la journée, de la semaine ou du mois, vous pouvez planifier la mise à l'échelle à la hausse ou à la baisse en procédant comme suit :

Évolutivité pour répondre aux besoins de l'entreprise sans trop dépenser

Pour les expérimentations d'entrée de gamme avec Timestream pour InfluxDB, vous pouvez utiliser et. db.influx.medium db.influx.large Ces instances sont suffisamment grandes pour que vous puissiez acquérir de l'expérience avec Timestream pour InfluxDB avant d'investir dans des instances plus importantes.

Les db.influx.large instances db.influx.medium et conviennent aux environnements de développement à faible coût. Cependant, ils ont une mémoire RAM plus petite (8 GiB et 16 GiB), moins de v (CPUs 1 vCPU et 2 VCPUs) et des performances réseau allant jusqu'à 10 Go seulement. Toutes les charges de travail ne sont pas adaptées à ces classes d'instances. Surveillez CPUUtilization MemoryUtilization et augmentez ou diminuez selon les besoins. Il existe souvent un ratio cohérent entre la mémoire et le processeur virtuel. La classe d'instance db.influx possède un memory-to-vCPU ratio similaire à celui de la classe d'instance Amazon EC2 r7g. Nous vous recommandons vivement d'effectuer des tests de end-to-end performance ou de charge avant de passer à la production.

La modélisation efficace des données, l'écriture par lots et les requêtes optimisées nécessitent moins de mémoire et d'utilisation des ressources informatiques. Lorsque moins de ressources sont nécessaires, vous pouvez éventuellement utiliser des instances plus petites.

Stockage et transfert de données adaptés

Pour le stockage des données, appliquez les meilleures pratiques suivantes :

  • Stockez uniquement les données de séries chronologiques dans Timestream pour InfluxDB.

  • Définissez une rétention appropriée sur le bucket InfluxDB afin que les données antérieures à la rétention soient supprimées et que les partitions soient automatiquement compactées périodiquement. Pour plus d'informations, consultez la documentation InfluxDB.

  • Optimisez l'utilisation du disque pour les futures écritures.

  • Supprimez tous les compartiments InfluxDB qui ne sont pas nécessaires pour vos charges de travail. InfluxDB prend en charge les suppressions. Vous pouvez effectuer des nettoyages planifiés si cela correspond à votre cas d'utilisation.

Pour le transfert de données, nous vous recommandons de déployer votre application de la même manière Région AWS que votre instance de base de données Timestream for InfluxDB afin d'éviter une surcharge réseau entre régions. Il peut également y avoir des frais de transfert de données. Pour plus d'informations sur le transfert de données, consultez la page de tarification.