Рекомендации по оценке ресурсов для развертываний Управляемого ClickStack
Ниже приведена модель для оценки вычислительных ресурсов и ресурсов хранения, необходимых для развертывания ClickStack на основе ожидаемого объёма приёма. Полученные значения являются лишь оценками и должны использоваться как начальная отправная точка — это не готовая рекомендация. Фактические требования зависят от сложности запросов, параллелизма, политик хранения и колебаний пропускной способности ингестии. Всегда отслеживайте использование ресурсов и при необходимости масштабируйте систему.
Все значения основаны на несжатом исходном объёме приёмаВсе значения на этой странице — пропускная способность (MB/s, TB/month), размер CPU и хранилища — выражены в терминах несжатого исходного объёма приёма, то есть объёма данных в том виде, в котором они создаются вашими приложениями и отправляются в OpenTelemetry Collector до применения какого-либо сжатия.Именно эту величину следует оценивать по вашим существующим конвейерам журналов, трассировок и метрик. Значения хранилища в таблице ниже уже рассчитаны с учётом предполагаемого коэффициента сжатия 10x, применённого к этому исходному объёму.
При развертывании ClickStack закладывайте вычислительные ресурсы на две независимые рабочие нагрузки: приём и запросы.
Рабочая нагрузка
Оценка ресурсов
Ingest
1 vCPU на каждые 10 MB/s устойчивой пропускной способности приёма
Query
1 vCPU на 1 QPS и на каждые 10 MB/s устойчивой пропускной способности приёма
Изоляция запросов и приёмаВ большинстве самоуправляемых развертываний приём и запросы используют одни и те же узлы. В этом случае используйте общее число CPU как отправную точку. Изолированное масштабирование — когда вычислительные ресурсы для приёма и запросов выделяются независимо — поддерживается в ClickHouse Cloud через отдельные вычислительные пулы, то есть Warehouses.
Допущения
Для хранилища предполагается коэффициент сжатия 10x — обычно это консервативная оценка для журналов и трассировок.
Мы предполагаем, что большинство запросов выполняется по недавним данным и следует логнормальному распределению с пиком примерно на одном часе и хвостом примерно до шести часов. Пользователи могут захотеть выделить отдельные вычислительные ресурсы для запросов к более старым данным. В ClickHouse Cloud эти ресурсы могут простаивать (и, следовательно, не создавать затрат), когда не используются.
Хотя вычислительные ресурсы для запросов можно масштабировать независимо от ресурсов для приёма, они всё равно неразрывно связаны с объёмом приёма. Мы предполагаем, что с ростом приёма увеличивается плотность данных, что приводит к большим объёмам сканирования во время выполнения запросов и, как следствие, к более высоким требованиям к вычислительным ресурсам для запросов.
В следующей таблице приведены примеры размеров ресурсов на основе растущей пропускной способности приёма в мегабайтах в секунду, а также соответствующих объёмов данных в терабайтах в месяц. Предполагается устойчивое среднее значение 1 QPS от ClickStack по всем типам запросов (поиск, панели мониторинга, оповещения).
Модель предполагает устойчивое среднее значение 1 QPS для ClickStack с учётом всех типов запросов, включая поиск, панели мониторинга и оповещения.При более высоких объёмах запросов линейно масштабируйте требования к CPU, умножая базовую потребность в CPU на целевой QPS. Например, развертывание с приёмом данных на скорости 100 МБ/с и целевым значением 9 QPS потребует 90 CPU на запросы (10 × 9) вместо базовых 10, что даст пересчитанный итог в 100 CPU (10 на приём + 90 на запросы).Оценки хранилища исходят из консервативного коэффициента сжатия 10x. На практике журналы, трассировки и метрики часто сжимаются лучше. Мы рекомендуем заранее, до выхода в продакшн, провести тестирование на выборке данных, чтобы определить ваш коэффициент сжатия и требования к хранилищу. Чтобы рассчитать необходимый объём хранилища для более длительного срока хранения, умножьте объём хранилища в месяц на количество месяцев хранения.Здесь предполагается относительно сбалансированное распределение запросов. Рабочие нагрузки со смещением в сторону более тяжёлых исторических или архивных запросов могут требовать существенно иных вычислительных ресурсов, поэтому их следует проверять с помощью нагрузочного тестирования. Мы планируем представить более гибкую модель сайзинга, которая позволит экстраполировать вычислительные ресурсы для запросов на основе различных профилей распределения запросов.
Ресурсы для приёмаПри 1 vCPU на каждые 10 MB/s постоянного приёма:579 ÷ 10 = ~58 vCPU для приёмаРесурсы для запросовРесурсы для запросов зависят как от пропускной способности ингестии, так и от QPS. При 5 QPS:(579 ÷ 10) × 5 = 58 × 5 = 290 vCPU для запросовХранилищеПри постоянной скорости 579 MB/s в течение 30 дней исходный объём приёма составляет 1 500 ТБ/месяц. Применяя предполагаемый коэффициент сжатия 10×:
В сжатом виде за месяц: 1 500 ТБ ÷ 10 = 150 ТБ/месяц
Для хранения в течение 3 месяцев: 150 ТБ × 3 = 450 ТБ всего
Если вы добавляете ClickStack в существующий сервис ClickHouse Cloud, который уже поддерживает другие рабочие нагрузки, например аналитику приложений в реальном времени, настоятельно рекомендуется изолировать трафик обсервабилити.Используйте Управляемые хранилища, чтобы создать дочерний сервис, выделенный под ClickStack. Это позволяет:
Изолировать нагрузку от приёма данных и запросов существующих приложений
Независимо масштабировать рабочие нагрузки обсервабилити
Не допускать влияния запросов обсервабилити на аналитику в продакшне
При необходимости использовать одни и те же базовые данные в разных сервисах
Такой подход гарантирует, что существующие рабочие нагрузки не пострадают, а ClickStack сможет масштабироваться независимо по мере роста объёма данных обсервабилити.Для крупных развертываний или рекомендаций по индивидуальному подбору размера обратитесь в службу поддержки, чтобы получить более точную оценку.
