Guide de dimensionnement des ressources pour les déploiements Managed ClickStack
Ce qui suit propose un modèle pour estimer les ressources de calcul et de stockage nécessaires à un déploiement ClickStack en fonction du volume d’ingestion prévu. Les valeurs obtenues sont uniquement des estimations et doivent servir de référence initiale - elles ne constituent pas une recommandation prescriptive. Les besoins réels dépendent de la complexité des requêtes, de la concurrence, des politiques de rétention et des variations du débit d’ingestion. Surveillez toujours l’utilisation des ressources et adaptez le dimensionnement selon les besoins.
Tous les chiffres sont basés sur l’ingestion brute non compresséeTous les chiffres indiqués sur cette page - débit (MB/s, TB/mois), dimensionnement CPU et stockage - sont exprimés en volume d’ingestion brute non compressée, c’est-à-dire la taille des données telles qu’elles sont produites par vos applications et envoyées au collecteur OpenTelemetry avant toute compression.C’est ce volume que vous devez estimer à partir de vos pipelines existants de logs, de traces et de métriques. Les chiffres de stockage du tableau ci-dessous intègrent déjà le taux de compression de 10x supposé appliqué à ce volume brut.
Lors du déploiement de ClickStack, provisionnez les ressources de calcul pour couvrir deux charges de travail indépendantes : ingestion et requêtes.
Charge de travail
Ressources estimées
Ingestion
1 vCPU pour 10 MB/s de débit d’ingestion soutenu
Requêtes
1 vCPU par QPS et pour 10 MB/s de débit d’ingestion soutenu
Isolation des requêtes par rapport à l’ingestionDans la plupart des déploiements autogérés, l’ingestion et les requêtes partagent les mêmes nœuds. Dans ce cas, utilisez le total des CPU comme référence. Le dimensionnement isolé - où les ressources de calcul pour l’ingestion et les requêtes sont provisionnées indépendamment - est pris en charge dans ClickHouse Cloud via des pools de calcul distincts, appelés Warehouses.
Hypothèses
Un taux de compression de 10x pour le stockage - généralement une hypothèse prudente pour les logs et les traces.
Des SLA de requête avec un P50 de 1,5 seconde et un P99 de 5 secondes.
Nous supposons que la plupart des requêtes portent sur des données récentes, selon une distribution log-normale qui culmine autour d’une heure et décroît jusqu’à environ six heures. Les utilisateurs peuvent souhaiter provisionner des ressources de calcul dédiées pour interroger des données plus anciennes. Dans ClickHouse Cloud, celles-ci peuvent rester inactives (et donc ne pas engendrer de coûts) lorsqu’elles ne sont pas utilisées.
Bien que les ressources de calcul des requêtes puissent être dimensionnées indépendamment de celles de l’ingestion, elles restent intrinsèquement liées au volume d’ingestion. Nous partons du principe qu’à mesure que l’ingestion augmente, la densité des données croît, ce qui entraîne des volumes analysés plus importants au moment des requêtes et, par conséquent, des besoins plus élevés en ressources de calcul pour les requêtes.
Le tableau suivant présente des exemples de dimensionnement basés sur un débit d’ingestion croissant en mégaoctets par seconde, ainsi que les volumes de données correspondants en téraoctets par mois. Il suppose une moyenne soutenue de 1 QPS depuis ClickStack sur l’ensemble des types de requêtes (recherche, tableaux de bord, alertes).
Affiner les hypothèses de dimensionnement pour votre environnement
Le modèle suppose une moyenne soutenue de 1 QPS depuis ClickStack, tous types de requêtes confondus, y compris la recherche, les dashboards et les alertes.Pour des volumes de requêtes plus élevés, faites évoluer les besoins en CPU de manière linéaire en multipliant les besoins en CPU par le QPS cible. Par exemple, un déploiement ingérant 100 MB/s avec un objectif de 9 QPS nécessiterait 90 CPU pour les requêtes (10 × 9) au lieu des 10 de référence, soit un total révisé de 100 CPU (10 pour l’ingestion + 90 pour les requêtes).Les estimations de stockage supposent un taux de compression prudent de 10x. En pratique, les logs, les traces et les métriques obtiennent souvent une compression plus élevée. Nous recommandons d’effectuer des tests sur un échantillon de données afin de déterminer à l’avance votre taux de compression et vos besoins de stockage avant la mise en production. Pour calculer le stockage nécessaire pour une durée de rétention plus longue, multipliez le stockage mensuel par le nombre de mois de rétention requis.Cela suppose une répartition des requêtes relativement équilibrée. Les charges de travail davantage orientées vers des requêtes historiques ou d’archivage plus lourdes peuvent avoir des besoins en calcul sensiblement différents et doivent être validées par des tests de charge. Nous prévoyons d’introduire un modèle de dimensionnement plus flexible, permettant d’extrapoler les ressources de calcul des requêtes selon différents profils de répartition des requêtes.
Exigences : ingestion de 1,5 PB/mois, 5 QPS, rétention de 3 mois.Conversion en MB/sLe modèle de dimensionnement est exprimé en MB/s. Conversion de 1,5 PB/mois (1 500 TB) en débit constant :
1 500 TB = 1 500 000 000 MB
Secondes par mois (30 jours) : 30 × 24 × 60 × 60 = 2 592 000
MB/s = 1 500 000 000 ÷ 2 592 000 ≈ 579 MB/s
Calcul pour l’ingestionAvec 1 vCPU pour 10 MB/s d’ingestion constante :579 ÷ 10 = ~58 vCPUs pour l’ingestionCalcul pour les requêtesLa capacité de calcul pour les requêtes dépend à la fois du débit d’ingestion et du QPS. À 5 QPS :(579 ÷ 10) × 5 = 58 × 5 = 290 vCPUs pour les requêtesStockageAvec 579 MB/s constants sur 30 jours, l’ingestion brute représente 1 500 TB/mois. En appliquant le ratio de compression supposé de 10x :
Compressé par mois : 1 500 TB ÷ 10 = 150 TB/mois
Pour une rétention de 3 mois : 150 TB × 3 = 450 TB au total
Si vous ajoutez ClickStack à un service ClickHouse Cloud existant qui prend déjà en charge d’autres charges de travail, comme l’analytique applicative en temps réel, il est fortement recommandé d’isoler le trafic d’observabilité.Utilisez Managed Warehouses pour créer un service enfant dédié à ClickStack. Cela vous permet de :
Isoler la charge liée à l’ingestion et aux requêtes des applications existantes
Faire évoluer indépendamment les charges de travail d’observabilité
Empêcher les requêtes d’observabilité d’affecter l’analytique en production
Partager, si nécessaire, les mêmes jeux de données sous-jacents entre les services
Cette approche garantit que vos charges de travail existantes restent inchangées, tout en permettant à ClickStack de monter en charge de manière indépendante à mesure que les données d’observabilité augmentent.Pour les déploiements de plus grande envergure ou pour des conseils personnalisés en matière de dimensionnement, veuillez contacter le support afin d’obtenir une estimation plus précise.
