Arquitectura

Despliega ClickHouse en tu propia infraestructura en la nube

​

Conceptos clave

El diagrama siguiente muestra cómo se relacionan entre sí las organizaciones de ClickHouse Cloud, las cuentas en la nube y la infraestructura BYOC.

• Organización de ClickHouse Cloud: La entidad de nivel superior de ClickHouse Cloud que administra usuarios, facturación y servicios de ClickHouse que no son BYOC. Los usuarios de una organización pueden acceder tanto a los servicios estándar de Cloud como a los servicios BYOC.
• Organización BYOC de ClickHouse: Una organización independiente dedicada a administrar implementaciones de BYOC. Comparte usuarios con la organización de Cloud, pero está vinculada a una o más cuentas en la nube donde se implementa la infraestructura BYOC.
• Cuenta en la nube/proyecto/suscripción: La cuenta de AWS, el proyecto de GCP o la suscripción de Azure del cliente donde se aprovisiona la infraestructura BYOC. Cada cuenta/proyecto/suscripción puede alojar implementaciones de BYOC en una o varias regiones. Se recomienda usar una cuenta/proyecto/suscripción dedicados para cada implementación de BYOC a fin de garantizar el aislamiento.
• Infraestructura BYOC: El conjunto de recursos cloud implementados en una región específica de una cuenta en la nube, incluidos una VPC/VNet, un clúster de Kubernetes (EKS/GKE/AKS), buckets de almacenamiento de objetos, roles de IAM/cuentas de servicio/entidades de servicio y servicios de soporte. Una misma cuenta en la nube puede contener varias infraestructuras BYOC en distintas regiones.
• Servicio de ClickHouse: Un clúster individual de ClickHouse que se ejecuta dentro de una infraestructura BYOC. Varios servicios pueden ejecutarse dentro de la misma infraestructura BYOC.

La combinación de cuentas de AWS, proyectos de GCP y suscripciones de Azure en una misma organización solo es posible para clientes que no estén configurados a través de un marketplace de proveedores de servicios cloud.

​

Glosario

• ClickHouse VPC: La VPC que pertenece a ClickHouse Cloud.
• VPC BYOC del cliente: La VPC, que pertenece a la cuenta en la nube del cliente, es aprovisionada y gestionada por ClickHouse Cloud, y está dedicada a una implementación de BYOC de ClickHouse Cloud.
• Customer VPC: Otras VPC que pertenecen a la cuenta en la nube del cliente y se utilizan para aplicaciones que necesitan conectarse a la VPC BYOC del cliente.

​

Arquitectura técnica

BYOC separa el plano de control de ClickHouse, que se ejecuta en la VPC de ClickHouse, del plano de datos, que se ejecuta por completo en su cuenta en la nube. La VPC de ClickHouse aloja la ClickHouse Cloud Console, la autenticación, la gestión de usuarios, las API, la facturación, componentes de gestión de infraestructura como el controlador de BYOC y herramientas de alertas y gestión de incidentes. Estos servicios orquestan y supervisan su despliegue, pero no almacenan sus datos.

En su VPC BYOC del cliente, ClickHouse aprovisiona un cluster de Kubernetes (por ejemplo, Amazon EKS) que ejecuta el plano de datos de ClickHouse. Como se muestra en el diagrama, esto incluye el propio cluster de ClickHouse, el ClickHouse Operator y servicios auxiliares como ingreso, DNS, gestión de certificados, exportadores de estado y scrapers. Una pila de monitorización dedicada (Prometheus, Grafana, AlertManager y Thanos) también se ejecuta dentro de su VPC, de modo que sus métricas y alertas se originan en su entorno y los propios datos de monitorización permanecen en su cuenta. A ClickHouse Cloud se reenvía un conjunto acotado de telemetría operativa —métricas de uso para la facturación, eventos de estado del servicio y de las copias de seguridad, y alertas de salud— y no se exporta nada más; consulte límites de red para ver el inventario completo. Al margen de esa exportación, los paneles de ClickHouse y, previa escalación aprobada, sus ingenieros pueden consultar la pila y sus logs in situ a través de Tailscale, sin que nada quede almacenado del lado de ClickHouse; consulte acceso a datos de ClickHouse.

Los principales recursos de Cloud que ClickHouse Cloud desplegará en su cuenta son:

• VPC: Una Virtual Private Cloud dedicada a su despliegue de ClickHouse. Puede ser gestionada por ClickHouse o por usted, el cliente, y normalmente se configura con peering hacia las VPC de sus aplicaciones.
• Roles y políticas de IAM: Roles y permisos necesarios para Kubernetes, los servicios de ClickHouse y la pila de monitorización. Pueden ser aprovisionados por ClickHouse o proporcionados por el cliente.
• Buckets de almacenamiento: Se utilizan para almacenar partes de datos, copias de seguridad y, opcionalmente, archivos de métricas y logs a largo plazo.
• Cluster de Kubernetes: Puede ser Amazon EKS, Google GKE o Azure AKS según su proveedor de Cloud. Aloja los servidores de ClickHouse y los servicios auxiliares que se muestran en el diagrama de arquitectura.

De forma predeterminada, ClickHouse Cloud aprovisiona una VPC nueva y dedicada, y configura los roles de IAM necesarios para garantizar el funcionamiento seguro de los servicios de Kubernetes. Para las organizaciones con necesidades avanzadas de red o seguridad, también existe la opción de gestionar la VPC y los roles de IAM de forma independiente. Este enfoque permite una mayor personalización de las configuraciones de red y un control más preciso sobre los permisos. Sin embargo, optar por autogestionar estos recursos aumentará sus responsabilidades operativas.

​

Almacenamiento de datos

Sus datos de ClickHouse, las copias de seguridad, los logs y los datos de monitorización permanecen en su cuenta en la nube; los únicos datos que se exportan a otro lugar son los datos acotados de telemetría de uso y estado que se enumeran en límites de red. Las partes de datos y las copias de seguridad se almacenan en su almacenamiento de objetos (por ejemplo, Amazon S3), mientras que los logs se almacenan en los volúmenes de almacenamiento conectados a sus nodos de ClickHouse. En una futura actualización, los logs se escribirán en LogHouse, un servicio de logging basado en ClickHouse que también se ejecuta dentro de su VPC BYOC. Las métricas pueden almacenarse localmente o, para su conservación a largo plazo, en un bucket dedicado dentro de su propia cuenta: el almacenamiento de objetos se sitúa fuera de la VPC/VNet y se accede a él a través de la ruta de la API de almacenamiento del proveedor. La conectividad del plano de control entre la VPC de ClickHouse y su VPC BYOC se utiliza únicamente para operaciones de gestión, nunca para el tráfico de consultas. De forma predeterminada, los servicios de administración de ClickHouse acceden a la API de Kubernetes de su cluster a través de su endpoint público, que nunca queda expuesto sin restricciones: en AWS, el acceso está restringido mediante una lista de permitidos de IP a los rangos de salida de ClickHouse; en GCP, se autoriza mediante Google Cloud IAM, y en Azure, mediante Microsoft Entra ID junto con Azure RBAC. Como alternativa, puede habilitarse una conexión privada por implementación —AWS VPC Lattice, el endpoint del plano de control basado en DNS de GKE en GCP o Azure Private Link—, como se muestra en el diagrama. En todas las nubes, Tailscale canaliza el acceso de resolución de problemas de los ingenieros de ClickHouse, así como las métricas y los dashboards, y se mantiene incluso cuando la ruta de la API de Kubernetes es privada.

​

Comunicación con el plano de control

La VPC de ClickHouse se comunica con tu VPC BYOC a través de HTTPS (puerto 443) para operaciones de administración del servicio, como cambios de configuración, comprobaciones de estado y comandos de implementación. Este tráfico transporta únicamente datos del plano de control para la orquestación. La telemetría crítica y las alertas fluyen desde tu VPC BYOC hacia la VPC de ClickHouse para permitir la supervisión del uso de recursos y del estado.

​

Requisitos clave para BYOC

El modelo de implementación de BYOC requiere dos componentes esenciales para garantizar un funcionamiento fiable, facilidad de mantenimiento y seguridad:

​

Permisos de IAM entre cuentas

ClickHouse Cloud necesita permisos de IAM entre cuentas para aprovisionar y administrar recursos dentro de su cuenta en la nube. Esto permite a ClickHouse:

• Aprovisionar infraestructura: Crear y configurar VPC, subredes, grupos de seguridad y otros componentes de red
• Administrar clústeres de Kubernetes: Implementar y mantener clústeres de EKS/GKE/AKS, grupos de nodos y componentes del clúster
• Crear recursos de almacenamiento: Aprovisionar buckets de S3 o almacenamiento de objetos equivalente para datos y backups
• Administrar roles de IAM: Crear y configurar roles de IAM para cuentas de servicio de Kubernetes y servicios auxiliares
• Operar servicios auxiliares: Implementar y administrar pilas de monitorización, controladores de Ingreso y otros componentes de infraestructura

Estos permisos se otorgan mediante un rol de IAM entre cuentas (AWS), una cuenta de servicio (GCP) o una entidad de servicio multiinquilino (Azure) que usted crea durante el proceso inicial de incorporación. El rol sigue el principio de mínimo privilegio, con permisos limitados únicamente a lo necesario para las operaciones de BYOC.

Para obtener información detallada sobre los permisos específicos necesarios, consulte la Referencia de privilegios de BYOC.

​

Conexión de red privada de Tailscale

Tailscale proporciona una red privada segura y de confianza cero entre ClickHouse Cloud y su implementación de BYOC. Por ella circulan el acceso de diagnóstico y resolución de problemas de los ingenieros de ClickHouse y las métricas y los paneles que ClickHouse utiliza para monitorizar su despliegue, así como el tráfico de la API de Kubernetes cuando se habilita un endpoint privado de la API. Esta conexión permite:

• Monitorización continua: los ingenieros de ClickHouse pueden acceder a la pila de monitorización de Prometheus desplegada en su VPC BYOC para supervisar el estado y el rendimiento del servicio
• Mantenimiento proactivo: los ingenieros pueden realizar tareas rutinarias de mantenimiento, actualizaciones y operaciones de diagnóstico y resolución de problemas
• Soporte de emergencia: en caso de problemas del servicio, los ingenieros pueden acceder rápidamente a su entorno para diagnosticar y resolver incidencias
• Gestión de infraestructura: cuando se habilita un endpoint privado de la API de Kubernetes, el servicio de administración accede a la API de Kubernetes a través de esta conexión, en lugar de hacerlo a través de su endpoint público

Los agentes de Tailscale de su cluster establecen únicamente conexiones salientes: el propio Tailscale no requiere ninguna regla de entrada en security groups, firewalls ni network security groups, lo que reduce su superficie de exposición. Todo acceso es:

• Aprobado y auditado: los ingenieros deben solicitar acceso a través de un sistema interno de aprobación
• Limitado en el tiempo: el acceso caduca automáticamente después de un período determinado
• Restringido: los ingenieros solo pueden acceder a las tablas del sistema y a los componentes de infraestructura, nunca a los datos del cliente
• Cifrado: toda la comunicación está cifrada de extremo a extremo

Esta restricción a conexiones salientes se aplica únicamente al propio Tailscale, no a todas las rutas de gestión. El servidor de la API de Kubernetes de su cluster sigue aceptando conexiones del servicio de administración de ClickHouse en el puerto TCP 443, ya sea a través del endpoint público o de una conexión privada; consulte el inventario de conexiones entrantes para ver la lista completa de listeners.

Para obtener información detallada sobre cómo funciona Tailscale en BYOC y sobre los controles de seguridad, consulte la documentación de seguridad de red.

​

Por qué son importantes estos requisitos

En conjunto, estos dos componentes permiten a ClickHouse Cloud:

• Mantener la fiabilidad: Supervisar y mantener de forma proactiva su despliegue para prevenir problemas
• Garantizar la seguridad: Usar acceso de privilegio mínimo con trazabilidad de auditoría completa
• Simplificar las operaciones: Automatizar la gestión de la infraestructura mientras usted mantiene el control
• Proporcionar soporte: Responder con rapidez a los problemas y resolverlos cuando se produzcan

Todos los datos del cliente permanecen dentro de su cuenta en la nube y nunca se accede a ellos ni se transfieren a través de estos canales de gestión.

Recomendaciones y consideraciones adicionales:

• Asegúrese de que los rangos CIDR de red de su BYOC VPC no se superpongan con ninguna VPC existente con la que planee establecer peering.
• Etiquete sus recursos claramente para simplificar la gestión y el soporte.
• Planifique un dimensionamiento adecuado de las subredes y su distribución entre zonas de disponibilidad para lograr alta disponibilidad.
• Consulte la guía de seguridad para comprender la responsabilidad compartida y las buenas prácticas cuando ClickHouse Cloud opera dentro de su entorno.
• Revise la guía completa de incorporación para obtener instrucciones paso a paso sobre la configuración inicial de la cuenta, la configuración de la VPC, la conectividad de red (por ejemplo, peering de VPC) y la delegación de roles de IAM.

Si tiene requisitos o restricciones particulares, póngase en contacto con el soporte de ClickHouse para recibir orientación sobre configuraciones de red avanzadas o políticas de IAM personalizadas.