Scheduled scaling

Artigo sobre o recurso Scheduled Scaling no ClickHouse Cloud

Os serviços do ClickHouse Cloud escalam automaticamente com base na utilização de CPU e memória, mas muitas cargas de trabalho seguem padrões previsíveis — picos diários de ingestão, jobs em lote executados durante a noite ou tráfego que cai acentuadamente nos fins de semana. Para esses casos de uso, o Scheduled Scaling permite definir exatamente quando seu serviço deve aumentar ou reduzir a escala, independentemente das métricas em tempo real.

Com o Scheduled Scaling, você configura um conjunto de regras baseadas em tempo diretamente no console do ClickHouse Cloud. Cada regra especifica os dias em que está ativa, uma hora de início e uma hora de término em UTC e as configurações a serem aplicadas durante essa janela — o número de réplicas (horizontal), a memória mínima e máxima por réplica (vertical) e se o serviço pode ficar ocioso. Enquanto a janela estiver ativa, o ClickHouse Cloud aplica essas configurações e, quando ela termina, reverte para sua configuração de scaling padrão, para que seu serviço esteja dimensionado corretamente antes da chegada da demanda, em vez de reagir depois.

Isso é diferente do autoscaling baseado em métricas, que responde dinamicamente à pressão sobre CPU e memória. O Scheduled Scaling é determinístico: você sabe exatamente quando o scaling acontecerá e para qual tamanho. As duas abordagens são complementares — um serviço pode ter um agendamento básico de scaling e ainda se beneficiar do autoscaling dentro dessa janela se as cargas de trabalho variarem de forma inesperada.

No momento, o Scheduled Scaling está disponível em Beta.

​

Configurando um agendamento de escalonamento

Para configurar um agendamento, acesse seu serviço no console do ClickHouse Cloud e vá até as configurações. Em seguida, selecione Schedule Override e adicione uma nova regra.

Cada regra exige:

• Dias ativos: os dias da semana aos quais a regra se aplica
• Hora de início e término: a janela durante a qual a regra se aplica, informado em UTC e em horas inteiras. Uma janela cuja hora de término é anterior à hora de início se estende pela noite até o dia seguinte
• Configurações a aplicar: o número de réplicas, a memória mínima e máxima por réplica e o tempo mínimo de ociosidade (ou sem ociosidade) a usar enquanto a janela estiver ativa

Várias regras podem ser combinadas para formar um agendamento semanal completo, desde que suas janelas não se sobreponham. Por exemplo, uma única regra que abrange de segunda a sexta-feira, das 06:00 às 20:00 UTC, pode manter seu serviço em um tamanho maior durante o dia de trabalho, com sua configuração padrão sendo aplicada fora dessa janela.

​

Casos de uso

Cargas de trabalho em lote e ETL: Aumente a escala antes da execução de um job noturno de ingestão e reduza-a novamente assim que ele for concluído, evitando superprovisionamento durante as horas ociosas do dia.

Padrões de tráfego previsíveis: Serviços com horários de pico consistentes (por exemplo, tráfego de consultas em horário comercial) podem ser escalados antecipadamente para lidar com a carga antes que ela chegue, em vez de esperar o autoscaling reagir.

Redução de escala no fim de semana: Reduza a contagem de réplicas ou a camada de memória nos fins de semana, quando a demanda é menor, e depois restaure a capacidade antes do pico de segunda-feira pela manhã.

Controle de custos: Para equipes que gerenciam os gastos com o ClickHouse Cloud, reduções programadas de escala durante períodos conhecidos de baixa utilização podem reduzir significativamente o consumo de recursos sem nenhuma intervenção manual.

Uma ação de Scheduled Scaling e uma recomendação concorrente de autoscaling podem interagir — o agendamento tem precedência no momento em que é acionado.

​

Como lidar com picos de carga de trabalho

Se você espera um pico de carga de trabalho em breve, pode usar a ClickHouse Cloud API para escalar seu serviço preventivamente a fim de lidar com esse pico e reduzi-lo quando a demanda diminuir.

Para entender quantos núcleos de CPU e quanta memória estão sendo usados por cada uma das suas réplicas, você pode executar a consulta abaixo:

SELECT *
FROM clusterAllReplicas('default', view(
    SELECT
        hostname() AS server,
        anyIf(value, metric = 'CGroupMaxCPU') AS cpu_cores,
        formatReadableSize(anyIf(value, metric = 'CGroupMemoryTotal')) AS memory
    FROM system.asynchronous_metrics
))
ORDER BY server ASC
SETTINGS skip_unavailable_shards = 1