Архитектура

Развертывание ClickHouse в собственной облачной инфраструктуре

​

Ключевые понятия

На диаграмме ниже показано, как соотносятся организации ClickHouse Cloud, облачные аккаунты и инфраструктура BYOC.

• Организация ClickHouse Cloud: Сущность верхнего уровня в ClickHouse Cloud, которая управляет пользователями, биллингом и сервисами ClickHouse, не относящимися к BYOC. Пользователи внутри организации могут получать доступ как к стандартным сервисам Cloud, так и к сервисам BYOC.
• Организация ClickHouse BYOC: Отдельная организация, предназначенная для управления развертываниями BYOC. Она использует общих пользователей с организацией Cloud, но связана с одним или несколькими облачными аккаунтами, в которых развернута инфраструктура BYOC.
• Облачный аккаунт/проект/подписка: Принадлежащий клиенту аккаунт AWS, проект GCP или подписка Azure, в которых развертывается инфраструктура BYOC. Каждый аккаунт/проект/подписка может размещать развертывания BYOC в одном или нескольких регионах. Для изоляции рекомендуется выделять отдельный аккаунт/проект/подписку для каждого развертывания BYOC.
• Инфраструктура BYOC: Набор облачных ресурсов, развернутых в определенном регионе облачного аккаунта, включая VPC/VNet, кластер Kubernetes (EKS/GKE/AKS), бакеты объектного хранилища, роли IAM/сервисные учетные записи/сервисные субъекты и вспомогательные сервисы. Один облачный аккаунт может содержать несколько инфраструктур BYOC в разных регионах.
• Сервис ClickHouse: Отдельный кластер ClickHouse, работающий в инфраструктуре BYOC. В одной и той же инфраструктуре BYOC может работать несколько сервисов.

Совмещать аккаунты AWS, проекты GCP и подписки Azure в рамках одной организации можно только для клиентов, которые не подключены через маркетплейс облачного провайдера.

​

Глоссарий

• VPC ClickHouse: VPC, принадлежащая ClickHouse Cloud.
• Customer BYOC VPC: VPC в облачном аккаунте клиента, выделенная для развертывания ClickHouse Cloud BYOC, которая подготавливается и управляется ClickHouse Cloud.
• Customer VPC: Другие VPC в облачном аккаунте клиента, используемые для приложений, которым необходимо подключаться к Customer BYOC VPC.

​

Техническая архитектура

BYOC разделяет плоскость управления ClickHouse, работающую в VPC ClickHouse, и плоскость данных, полностью работающую в вашем облачном аккаунте. В VPC ClickHouse размещаются консоль ClickHouse Cloud, аутентификация, управление пользователями, API, биллинг, компоненты управления инфраструктурой, такие как контроллер BYOC, а также инструменты оповещения и управления инцидентами. Эти сервисы оркестрируют и контролируют ваше развертывание, но не хранят ваши данные.

В вашем Customer BYOC VPC ClickHouse разворачивает кластер Kubernetes (например, Amazon EKS), в котором работает плоскость данных ClickHouse. Как показано на схеме, сюда входят сам кластер ClickHouse, ClickHouse Operator и вспомогательные сервисы, такие как входной шлюз, DNS, управление сертификатами, экспортеры состояния и скрейперы. Выделенный стек мониторинга (Prometheus, Grafana, AlertManager и Thanos) также работает внутри вашего VPC, поэтому ваши метрики и оповещения создаются в вашей среде, а сами данные мониторинга остаются в вашем аккаунте. В ClickHouse Cloud передается ограниченный набор эксплуатационной телеметрии — метрики использования для биллинга, события состояния сервиса и резервных копий, а также оповещения о работоспособности — и больше ничего не экспортируется; полный перечень см. в разделе сетевые границы. Помимо этого экспорта, панели мониторинга ClickHouse и, при одобренной эскалации, его инженеры могут выполнять запросы к стеку и вашим журналам на месте через Tailscale, при этом на стороне ClickHouse ничего не сохраняется — см. доступ ClickHouse к данным.

Основные облачные ресурсы, которые ClickHouse Cloud развернет в вашем аккаунте:

• VPC: Virtual Private Cloud, выделенная для вашего развертывания ClickHouse. Она может управляться как ClickHouse, так и вами, клиентом, и обычно соединяется с VPC ваших приложений через peering.
• Роли IAM и политики: Роли и разрешения, необходимые для Kubernetes, сервисов ClickHouse и стека мониторинга. Они могут быть подготовлены ClickHouse или предоставлены клиентом.
• Бакеты хранилища: Используются для хранения частей данных, резервных копий и (при необходимости) долгосрочных архивов метрик и журналов.
• Кластер Kubernetes: Это может быть Amazon EKS, Google GKE или Azure AKS в зависимости от вашего облачного провайдера. В нем размещаются серверы ClickHouse и вспомогательные сервисы, показанные на схеме архитектуры.

По умолчанию ClickHouse Cloud создает новый выделенный VPC и настраивает необходимые роли IAM, чтобы обеспечить безопасную работу сервисов Kubernetes. Для организаций с более сложными требованиями к сети или безопасности также доступна возможность самостоятельно управлять VPC и ролями IAM. Такой подход дает больше гибкости при настройке сетевой конфигурации и более точный контроль разрешений. Однако самостоятельное управление этими ресурсами увеличивает вашу операционную нагрузку.

​

Хранение данных

Ваши данные ClickHouse, резервные копии, журналы и данные мониторинга остаются в вашем облачном аккаунте; единственные данные, экспортируемые за его пределы, — это ограниченная телеметрия использования и состояния, перечисленная в разделе сетевые границы. Части данных и резервные копии хранятся в вашем Объектном хранилище (например, Amazon S3), а журналы — на томах хранилища, подключённых к узлам ClickHouse. В одном из будущих обновлений журналы будут записываться в LogHouse — сервис логирования на базе ClickHouse, который также работает внутри вашего BYOC VPC. Метрики могут храниться локально или, для длительного хранения, в выделенном бакете в вашем собственном аккаунте — объектное хранилище находится за пределами VPC/VNet и доступно по пути storage API провайдера. Связь плоскости управления между VPC ClickHouse и вашим BYOC VPC используется только для операций управления и никогда — для трафика запросов. По умолчанию сервисы управления ClickHouse обращаются к Kubernetes API вашего кластера через его публичную конечную точку, которая никогда не остаётся открытой: на AWS доступ к ней ограничен списком разрешённых IP-адресов из диапазонов исходящего трафика ClickHouse, на GCP авторизация выполняется через Google Cloud IAM, а на Azure — через Microsoft Entra ID совместно с Azure RBAC. Вместо этого для каждого развертывания можно включить приватное подключение — AWS VPC Lattice, конечную точку плоскости управления GKE на основе DNS в GCP или Azure Private Link, — как показано на схеме. Во всех облаках через Tailscale инженерам ClickHouse предоставляется доступ для устранения неполадок, а также передаются метрики и панели мониторинга; Tailscale продолжает использоваться даже там, где доступ к Kubernetes API осуществляется по приватному пути.

​

Взаимодействие с плоскостью управления

VPC ClickHouse взаимодействует с вашей BYOC VPC по HTTPS (порт 443) для операций управления сервисом, включая изменение конфигурации, проверки работоспособности и команды развертывания. Этот трафик передает только данные плоскости управления, необходимые для оркестрации. Критически важные телеметрия и оповещения передаются из вашей BYOC VPC в VPC ClickHouse, чтобы обеспечить мониторинг использования ресурсов и работоспособности.

​

Основные требования для BYOC

Для модели развертывания BYOC необходимы два ключевых компонента, обеспечивающих надежную работу, простоту сопровождения и безопасность:

​

Межаккаунтные IAM-разрешения

Для подготовки и управления ресурсами в вашем облачном аккаунте ClickHouse Cloud требуются межаккаунтные IAM-разрешения. Это позволяет ClickHouse:

• Подготавливать инфраструктуру: создавать и настраивать VPC, подсети, группы безопасности и другие сетевые компоненты
• Управлять кластерами Kubernetes: развертывать и поддерживать кластеры EKS/GKE/AKS, группы узлов и компоненты кластера
• Создавать ресурсы хранилища: выделять S3 бакеты или эквивалентное объектное хранилище для данных и резервных копий
• Управлять ролями IAM: создавать и настраивать роли IAM для сервисных учетных записей Kubernetes и вспомогательных сервисов
• Обеспечивать работу вспомогательных сервисов: развертывать и управлять стеками мониторинга, контроллерами входного шлюза и другими компонентами инфраструктуры

Эти разрешения предоставляются через межаккаунтную роль IAM (AWS), сервисную учетную запись (GCP) или мультитенантный сервисный субъект (Azure), которые вы создаете на этапе первоначального онбординга. Роль соответствует принципу минимально необходимых привилегий, а разрешения выдаются только в объеме, необходимом для работы BYOC.

Подробную информацию о конкретных требуемых разрешениях см. в разделе Справочник по привилегиям BYOC.

​

Подключение к частной сети Tailscale

Tailscale предоставляет безопасную частную сеть по модели нулевого доверия между ClickHouse Cloud и вашим развертыванием BYOC. Через нее осуществляется доступ инженеров ClickHouse для устранения неполадок и передаются метрики и панели мониторинга, с помощью которых ClickHouse отслеживает ваше развертывание, а при включенной приватной конечной точке API — также трафик Kubernetes API. Это подключение позволяет:

• Непрерывный мониторинг: инженеры ClickHouse могут получать доступ к стеку мониторинга Prometheus, развернутому в вашем BYOC VPC, чтобы отслеживать состояние и производительность сервиса
• Проактивное обслуживание: инженеры могут выполнять плановое обслуживание, обновления и устранение неполадок
• Экстренная поддержка: в случае проблем с сервисом инженеры могут быстро получить доступ к вашему окружению, чтобы диагностировать и устранить проблему
• Управление инфраструктурой: при включенной приватной конечной точке Kubernetes API сервисы управления обращаются к Kubernetes API через это подключение, а не через публичную конечную точку

Агенты Tailscale в вашем кластере устанавливают только исходящие соединения: для самого Tailscale не требуются правила входящего трафика в security group, файрволе или network security group, что снижает риски для безопасности. Весь доступ:

• Согласуется и аудитируется: инженеры должны запрашивать доступ через внутреннюю систему согласования
• Ограничен по времени: срок действия доступа автоматически истекает через заданный период
• Ограничен: инженеры могут получать доступ только к системным таблицам и компонентам инфраструктуры, но никогда — к данным клиентов
• Зашифрован: весь обмен данными защищен сквозным шифрованием

Принцип «только исходящих соединений» относится к самому Tailscale, а не ко всем каналам управления. API-сервер Kubernetes вашего кластера по-прежнему принимает соединения от сервисов управления ClickHouse по TCP 443 — через публичную конечную точку или через приватное подключение. Полный список слушателей см. в перечне входящих соединений.

Подробную информацию о том, как Tailscale работает в BYOC и какие меры безопасности применяются, см. в документации по сетевой безопасности.

​

Почему эти требования важны

Вместе эти два компонента позволяют ClickHouse Cloud:

• Поддерживать надежность: Заблаговременно отслеживать состояние развертывания и предотвращать проблемы
• Обеспечивать безопасность: Использовать доступ с минимально необходимыми привилегиями и полной возможностью аудита
• Упрощать эксплуатацию: Автоматизировать управление инфраструктурой, сохраняя за вами контроль
• Предоставлять поддержку: Быстро реагировать на проблемы и устранять их при возникновении

Все данные клиентов остаются в пределах вашего облачного аккаунта и никогда не передаются через эти каналы управления; доступ к ним через эти каналы также не осуществляется.

Дополнительные рекомендации и соображения:

• Убедитесь, что диапазоны CIDR сети для вашего BYOC VPC не пересекаются с существующими VPC, с которыми вы планируете настроить пиринг VPC.
• Четко помечайте свои ресурсы, чтобы упростить управление и поддержку.
• Заранее предусмотрите достаточный размер подсетей и их распределение по зонам доступности для обеспечения высокой доступности.
• Ознакомьтесь с руководством по безопасности, чтобы понять зоны общей ответственности и лучшие практики при работе ClickHouse Cloud в вашей среде.
• Ознакомьтесь с полным руководством по онбордингу, где приведены пошаговые инструкции по первоначальной настройке учетной записи, конфигурации VPC, сетевому подключению (например, пирингу VPC) и делегированию роли IAM.

Если у вас есть особые требования или ограничения, обратитесь в ClickHouse Support за рекомендациями по расширенным сетевым конфигурациям или пользовательским политикам IAM.