Оценка ресурсов
Ниже приведена модель для оценки вычислительных ресурсов и ресурсов хранения, необходимых для развертывания ClickStack, на основе ожидаемого объёма приёма данных. Полученные значения являются лишь оценочными и должны использоваться как начальная точка отсчёта — это не готовый рецепт. Фактические требования зависят от сложности запросов, уровня параллелизма, политик хранения и колебаний пропускной способности ингестии. Всегда отслеживайте использование ресурсов и масштабируйте систему по мере необходимости.
Все значения на этой странице — пропускная способность (MB/s, TB/month), размер CPU и объём хранилища — выражены через несжатый исходный объём приёма, то есть размер данных в том виде, в котором они создаются вашими приложениями и отправляются в OpenTelemetry collector до применения какого-либо сжатия.
Именно этот показатель следует оценивать на основе ваших существующих конвейеров логов, трейсов и метрик. Значения объёма хранилища в таблице ниже уже рассчитаны с применением предполагаемого 10-кратного коэффициента сжатия к этому исходному объёму.
При развертывании ClickStack выделяйте вычислительные ресурсы под две независимые рабочие нагрузки: приём и запросы.
| Рабочая нагрузка | Оценка ресурсов |
|---|---|
| Приём | 1 vCPU на каждые 10 MB/s устойчивой пропускной способности приёма |
| Запросы | 1 vCPU на 1 QPS и на каждые 10 MB/s устойчивой пропускной способности приёма |
В большинстве самоуправляемых развертываний приём и запросы используют одни и те же узлы. В этом случае используйте общее число CPU как базовую точку отсчёта. Изолированное масштабирование — при котором вычислительные ресурсы для приёма и запросов выделяются независимо — поддерживается в ClickHouse Cloud через отдельные вычислительные пулы, также называемые хранилищами.
Допущения
- 10-кратный коэффициент сжатия для хранилища — обычно это консервативная оценка для логов и трейсов.
- SLA для запросов: P50 на уровне 1,5 секунды и P99 на уровне 5 секунд.
- Мы исходим из того, что большинство запросов выполняется по свежим данным и следует логнормальному распределению с пиком примерно через один час и спадом примерно к шести часам. Пользователям может потребоваться выделить отдельные вычислительные ресурсы для запросов к более старым данным. В ClickHouse Cloud такие ресурсы могут простаивать (и, следовательно, не создавать затрат), когда не используются.
- Хотя вычислительные ресурсы для запросов можно масштабировать независимо от ресурсов для приёма, они по-прежнему напрямую связаны с объёмом приёма. Мы предполагаем, что по мере роста приёма увеличивается плотность данных, что приводит к большим объёмам сканирования во время выполнения запросов и, как следствие, к более высоким требованиям к вычислительным ресурсам для запросов.
В следующей таблице приведены примеры размеров ресурсов на основе роста пропускной способности приёма в мегабайтах в секунду, а также соответствующие объёмы данных в терабайтах в месяц. Предполагается устойчивое среднее значение 1 QPS в ClickStack для всех типов запросов (поиск, дашборды, оповещения).
| MB/s | TB/month | CPU для приёма | CPU для запросов | Всего CPU | Общее хранилище (в месяц) (GB) |
|---|---|---|---|---|---|
| 10 | 25.92 | 1 | 3 | 4 | 2,592 |
| 20 | 51.84 | 2 | 6 | 8 | 5,184 |
| 50 | 129.6 | 5 | 15 | 20 | 12,960 |
| 100 | 259.2 | 10 | 30 | 40 | 25,920 |
| 200 | 518.4 | 20 | 60 | 80 | 51,840 |
| 500 | 1,296 | 50 | 150 | 200 | 129,600 |
| 1000 | 2,592 | 100 | 300 | 400 | 259,200 |
Уточнение допущений по расчёту ресурсов для вашей среды
Модель предполагает устойчивое среднее значение 1 QPS со стороны ClickStack суммарно по всем типам запросов, включая поиск, дашборды и оповещения.
Для более высоких объёмов запросов линейно масштабируйте требования к CPU, умножая их на целевое значение QPS. Например, развертывание с приёмом 100 МБ/с и целевым значением 9 QPS потребует 90 CPU для запросов (10 × 9) вместо базовых 10, что даст пересчитанный итог в 100 CPU (10 на приём + 90 на запросы).
Оценка хранилища основана на консервативном коэффициенте сжатия 10x. На практике логи, трейсы и метрики часто сжимаются лучше. Мы рекомендуем заранее провести тесты на выборке данных, чтобы определить коэффициент сжатия и требования к хранилищу до выхода в продакшен. Чтобы вычислить требуемый объём хранилища для более длительного срока хранения, умножьте объём хранилища за месяц на количество месяцев хранения.
Это предполагает относительно сбалансированное распределение запросов. Рабочие нагрузки, в которых преобладают более тяжёлые исторические или архивные запросы, могут требовать существенно иных вычислительных ресурсов, и это следует проверять нагрузочным тестированием. Мы планируем представить более гибкую модель расчёта ресурсов, которая позволит экстраполировать вычислительные ресурсы для запросов на основе разных шаблонов распределения запросов.
Пример расчёта
Требования: 1,5 ПБ/месяц приёма, 5 QPS, хранение в течение 3 месяцев.
Преобразование в МБ/с
Модель расчёта ресурсов выражена в МБ/с. Переведём 1,5 ПБ/месяц (1 500 ТБ) в постоянную пропускную способность:
- 1 500 ТБ = 1 500 000 000 МБ
- Секунд в месяце (30 дней): 30 × 24 × 60 × 60 = 2 592 000
- МБ/с = 1 500 000 000 ÷ 2 592 000 ≈ 579 МБ/с
Вычислительные ресурсы для приёма
При 1 vCPU на каждые 10 МБ/с постоянного приёма:
579 ÷ 10 = ~58 vCPU для приёма
Вычислительные ресурсы для запросов
Объём вычислительных ресурсов для запросов масштабируется как по пропускной способности приёма, так и по QPS. При 5 QPS:
(579 ÷ 10) × 5 = 58 × 5 = 290 vCPU для запросов
Хранилище
При постоянной скорости 579 МБ/с в течение 30 дней объём несжатого приёма составляет 1 500 ТБ/месяц. С учётом предполагаемого коэффициента сжатия 10x:
- Сжатый объём в месяц: 1 500 ТБ ÷ 10 = 150 ТБ/месяц
- Для хранения в течение 3 месяцев: 150 ТБ × 3 = 450 ТБ всего
Итоги
| Ресурс | Значение |
|---|---|
| Вычислительные ресурсы для приёма | 58 vCPU |
| Вычислительные ресурсы для запросов | 290 vCPU |
| Всего вычислительных ресурсов | 348 vCPU |
| Хранилище в месяц (сжатое) | 150 ТБ |
| Хранилище для 3-месячного хранения | 450 ТБ |
Изоляция рабочих нагрузок обсервабилити
Если вы добавляете ClickStack в существующий сервис ClickHouse Cloud, который уже поддерживает другие рабочие нагрузки, например аналитику приложений в реальном времени, настоятельно рекомендуется изолировать трафик обсервабилити.
Используйте Управляемые хранилища, чтобы создать дочерний сервис, выделенный для ClickStack. Это позволяет:
- Изолировать нагрузку приёма и запросов от существующих приложений
- Независимо масштабировать рабочие нагрузки обсервабилити
- Не допускать влияния запросов обсервабилити на аналитику в промышленной эксплуатации
- При необходимости использовать одни и те же базовые датасеты в разных сервисах
Этот подход гарантирует, что существующие рабочие нагрузки не будут затронуты, и при этом позволяет ClickStack масштабироваться независимо по мере роста объёма данных обсервабилити.
Для более крупных развертываний или рекомендаций по индивидуальному подбору ресурсов обратитесь в службу поддержки для получения более точной оценки.
