Skip to main content

​
Concepts clés

Le diagramme ci-dessous illustre les relations entre les organizations ClickHouse Cloud, les comptes cloud et l’infrastructure BYOC.
  • Organization ClickHouse Cloud : entité de premier niveau dans ClickHouse Cloud qui gère les utilisateurs, la facturation et les services ClickHouse non BYOC. Les utilisateurs d’une organization peuvent accéder à la fois aux services Cloud standard et aux services BYOC.
  • Organization ClickHouse BYOC : organization distincte dédiée à la gestion des déploiements BYOC. Elle partage les utilisateurs avec l’organization Cloud, mais est liée à un ou plusieurs comptes cloud dans lesquels l’infrastructure BYOC est déployée.
  • Compte cloud/projet/abonnement : compte AWS, projet GCP ou abonnement Azure appartenant au client, dans lequel l’infrastructure BYOC est provisionnée. Chaque compte/projet/abonnement peut héberger des déploiements BYOC dans une ou plusieurs régions. Pour une meilleure isolation, il est recommandé d’utiliser un compte/projet/abonnement dédié pour chaque déploiement BYOC.
  • Infrastructure BYOC : ensemble des ressources cloud déployées dans une région spécifique d’un compte cloud, notamment un VPC/VNet, un cluster Kubernetes (EKS/GKE/AKS), des buckets de stockage d’objets, des rôles IAM/comptes de service/principaux de service et des services de support. Un même compte cloud peut contenir plusieurs infrastructures BYOC dans différentes régions.
  • Service ClickHouse : cluster ClickHouse individuel exécuté au sein d’une infrastructure BYOC. Plusieurs services peuvent s’exécuter dans une même infrastructure BYOC.
Le mélange de comptes AWS, de projets GCP et d’abonnements Azure au sein d’une même organization n’est possible que pour les clients qui ne sont pas configurés via une marketplace d’un fournisseur de services cloud.

​
Glossaire

  • ClickHouse VPC : Le VPC appartenant à ClickHouse Cloud.
  • Customer BYOC VPC : Le VPC, appartenant au compte cloud du client, est provisionné et géré par ClickHouse Cloud, et dédié à un déploiement BYOC de ClickHouse Cloud.
  • Customer VPC : Les autres VPC appartenant au compte cloud du client, utilisés pour les applications qui doivent se connecter au Customer BYOC VPC.

​
Architecture technique

BYOC sépare le plan de contrôle ClickHouse, qui s’exécute dans le ClickHouse VPC, du plan de données, qui s’exécute entièrement dans votre compte cloud. Le ClickHouse VPC héberge la ClickHouse Cloud Console, les mécanismes d’authentification, la gestion des utilisateurs, les API, la facturation, des composants de gestion de l’infrastructure tels que le contrôleur BYOC, ainsi que les outils d’alerte et de gestion des incidents. Ces services orchestrent et supervisent votre déploiement, mais ne stockent pas vos données. Dans votre Customer BYOC VPC, ClickHouse provisionne un cluster Kubernetes (par exemple, Amazon EKS) qui exécute le plan de données ClickHouse. Comme le montre le schéma, cela inclut le cluster ClickHouse lui-même, le ClickHouse Operator, ainsi que des services de support tels que l’Ingress, le DNS, la gestion des certificats, les exportateurs d’état et les scrapers. Une stack de supervision dédiée (Prometheus, Grafana, AlertManager et Thanos) s’exécute également dans votre VPC : vos métriques et vos alertes sont donc générées dans votre environnement et les données de supervision elles-mêmes restent dans votre compte. Un ensemble restreint de données de télémétrie opérationnelle est transmis à ClickHouse Cloud — métriques d’utilisation pour la facturation, événements d’état des services et des sauvegardes, et alertes de santé — et rien d’autre n’est exporté ; consultez limites réseau pour l’inventaire complet. Indépendamment de cet export, les tableaux de bord de ClickHouse et, en cas d’escalade approuvée, ses ingénieurs peuvent interroger la stack et vos logs sur place via Tailscale, sans qu’aucune donnée ne soit conservée du côté de ClickHouse — voir accès aux données par ClickHouse.

Les principales ressources cloud que ClickHouse Cloud déploiera dans votre compte sont :
  • VPC : un Virtual Private Cloud dédié à votre déploiement ClickHouse. Il peut être géré soit par ClickHouse, soit par vous, le client, et est généralement mis en peering avec les VPC de vos applications.
  • Rôles et stratégies IAM : les rôles et permissions nécessaires pour Kubernetes, les services ClickHouse et la stack de supervision. Ils peuvent être provisionnés par ClickHouse ou fournis par le client.
  • Buckets de stockage : utilisés pour stocker les parties de données, les sauvegardes et, éventuellement, les archives de métriques et de logs à long terme.
  • Cluster Kubernetes : il peut s’agir d’Amazon EKS, de Google GKE ou d’Azure AKS selon votre fournisseur de cloud. Il héberge les serveurs ClickHouse ainsi que les services de support présentés dans le schéma d’architecture.
Par défaut, ClickHouse Cloud provisionne un nouveau VPC dédié et configure les rôles IAM nécessaires pour garantir le fonctionnement sécurisé des services Kubernetes. Pour les organisations ayant des besoins avancés en matière de réseau ou de sécurité, il est également possible de gérer le VPC et les rôles IAM de manière indépendante. Cette approche permet une personnalisation plus poussée des configurations réseau et un contrôle plus précis des permissions. Toutefois, choisir de gérer vous-même ces ressources augmentera vos responsabilités opérationnelles.

​
Stockage des données

Vos données ClickHouse, vos sauvegardes, vos logs et vos données de supervision restent dans votre compte cloud ; les seules données exportées ailleurs sont les données de télémétrie d’utilisation et de santé, strictement délimitées, listées dans limites réseau. Les parties de données et les sauvegardes sont stockées dans votre stockage objet (par exemple, Amazon S3), tandis que les logs sont stockés sur les volumes de stockage attachés à vos nœuds ClickHouse. Dans une prochaine mise à jour, les logs seront écrits dans LogHouse, un service de logging basé sur ClickHouse qui s’exécute également dans votre VPC BYOC. Les métriques peuvent être stockées localement ou, pour une conservation à long terme, dans un bucket dédié de votre propre compte — le stockage objet se situe en dehors du VPC/VNet et est accessible via le chemin de l’API de stockage du fournisseur. La connectivité du plan de contrôle entre le ClickHouse VPC et votre VPC BYOC est utilisée uniquement pour les opérations de gestion, et jamais pour le trafic de requêtes. Par défaut, les services de gestion ClickHouse accèdent à l’API Kubernetes de votre cluster via son endpoint public, qui n’est jamais laissé ouvert : l’accès y est restreint aux plages d’adresses IP sortantes de ClickHouse par une liste d’autorisation sur AWS, autorisé par Google Cloud IAM sur GCP, et autorisé par Microsoft Entra ID conjointement avec Azure RBAC sur Azure. Une connexion privée peut être activée à la place pour chaque déploiement — AWS VPC Lattice, l’endpoint du plan de contrôle GKE basé sur DNS sur GCP, ou Azure Private Link — comme indiqué dans le schéma. Sur chaque cloud, Tailscale achemine l’accès de dépannage des ingénieurs ClickHouse ainsi que les métriques et les tableaux de bord, et reste en place même lorsque le chemin vers l’API Kubernetes est privé.

​
Communication du plan de contrôle

Le ClickHouse VPC communique avec votre VPC BYOC via HTTPS (port 443) pour les opérations de gestion du service, notamment les modifications de configuration, les vérifications d’état et les commandes de déploiement. Ce trafic ne transporte que des données du plan de contrôle destinées à l’orchestration. La télémétrie critique et les alertes transitent de votre VPC BYOC vers le ClickHouse VPC afin d’assurer le suivi de l’utilisation des ressources et de l’état de santé.

​
Exigences clés pour le BYOC

Le mode de déploiement BYOC nécessite deux éléments essentiels pour garantir la fiabilité des opérations, simplifier la maintenance et assurer la sécurité :

​
Autorisations IAM inter-comptes

ClickHouse Cloud a besoin d’autorisations IAM inter-comptes pour provisionner et gérer des ressources dans votre compte cloud. Cela permet à ClickHouse de :
  • Provisionner l’infrastructure : créer et configurer des VPC, des sous-réseaux, des groupes de sécurité et d’autres composants réseau
  • Gérer les clusters Kubernetes : déployer et maintenir des clusters EKS/GKE/AKS, des groupes de nœuds et des composants de cluster
  • Créer des ressources de stockage : provisionner des buckets S3 ou un stockage objet équivalent pour les données et les backups
  • Gérer les rôles IAM : créer et configurer des rôles IAM pour les comptes de service Kubernetes et les services de support
  • Exploiter les services de support : déployer et gérer des stacks de supervision, des contrôleurs d’Ingress et d’autres composants d’infrastructure
Ces autorisations sont accordées via un rôle IAM inter-comptes (AWS), un compte de service (GCP) ou un principal de service mutualisé (Azure) que vous créez lors du processus initial de configuration. Ce rôle respecte le principe du moindre privilège, avec des autorisations strictement limitées à ce qui est nécessaire aux opérations BYOC. Pour des informations détaillées sur les autorisations spécifiques requises, consultez la référence des privilèges BYOC.

​
Connexion au réseau privé Tailscale

Tailscale fournit un réseau privé sécurisé et zero trust entre ClickHouse Cloud et votre déploiement BYOC. Ce réseau achemine les accès de dépannage des ClickHouse engineers, ainsi que les métriques et tableaux de bord utilisés par ClickHouse pour surveiller votre déploiement ; il achemine également le trafic de l’API Kubernetes lorsqu’un endpoint d’API privé est activé. Cette connexion permet :
  • Surveillance continue : les ClickHouse engineers peuvent accéder à la stack de supervision Prometheus déployée dans votre VPC BYOC afin de surveiller l’état de santé et les performances du service
  • Maintenance proactive : les ingénieurs peuvent effectuer des opérations de maintenance courante, des mises à niveau et de dépannage
  • Assistance d’urgence : en cas de problème de service, les ingénieurs peuvent accéder rapidement à votre environnement pour diagnostiquer et résoudre les problèmes
  • Gestion de l’infrastructure : lorsqu’un endpoint privé de l’API Kubernetes est activé, les services de gestion accèdent à l’API Kubernetes via cette connexion plutôt que via son endpoint public
Les agents Tailscale de votre cluster établissent uniquement des connexions sortantes : aucune règle entrante de groupe de sécurité, de pare-feu ou de groupe de sécurité réseau n’est nécessaire pour Tailscale lui-même, ce qui réduit votre exposition. Tout accès est :
  • Approuvé et audité : les ingénieurs doivent demander l’accès via un système d’approbation interne
  • Limité dans le temps : l’accès expire automatiquement après une période définie
  • Restreint : les ingénieurs ne peuvent accéder qu’aux tables système et aux composants de l’infrastructure, jamais aux données des clients
  • Chiffré : toutes les communications sont chiffrées de bout en bout
Ce fonctionnement strictement sortant concerne uniquement Tailscale, et non l’ensemble des chemins de gestion. Le serveur API Kubernetes de votre cluster continue d’accepter les connexions des services de gestion ClickHouse sur le port TCP 443, que ce soit via l’endpoint public ou via une connexion privée ; consultez l’inventaire des connexions entrantes pour obtenir la liste complète des listeners. Pour plus d’informations sur le fonctionnement de Tailscale dans BYOC et sur les contrôles de sécurité, consultez la documentation sur la sécurité réseau.

​
Pourquoi ces exigences sont importantes

Ensemble, ces deux composants permettent à ClickHouse Cloud de :
  • Maintenir la fiabilité : surveiller et gérer votre déploiement de manière proactive afin d’éviter les incidents
  • Garantir la sécurité : appliquer le principe du moindre privilège avec une traçabilité complète
  • Simplifier les opérations : automatiser la gestion de l’infrastructure tout en vous laissant le contrôle
  • Fournir une assistance : réagir rapidement et résoudre les problèmes lorsqu’ils surviennent
Toutes les données client restent dans votre compte cloud et ne sont jamais consultées ni transmises par ces canaux de gestion. Recommandations et points à prendre en compte supplémentaires :
  • Assurez-vous que les plages CIDR réseau de votre VPC BYOC ne chevauchent celles d’aucun VPC existant avec lequel vous prévoyez d’établir un peering.
  • Étiquetez clairement vos ressources pour simplifier la gestion et l’assistance.
  • Prévoyez un dimensionnement adéquat des sous-réseaux et leur répartition entre les zones de disponibilité afin d’assurer une haute disponibilité.
  • Consultez le guide de sécurité pour comprendre le modèle de responsabilité partagée et les bonnes pratiques lorsque ClickHouse Cloud fonctionne dans votre environnement.
  • Consultez le guide d’onboarding complet pour obtenir des instructions pas à pas sur la configuration initiale du compte, la configuration du VPC, la connectivité réseau (par exemple, le VPC peering) et la délégation de rôle IAM.
Si vous avez des exigences ou des contraintes particulières, contactez ClickHouse Support pour obtenir des conseils sur les configurations réseau avancées ou les stratégies IAM personnalisées.
Dernière modification le 28 septembre 2026