Koordinator ajuda a melhorar o desempenho de aplicativos nativos da nuvem: prática de tecnologia híbrida Xiaohongshu

Autor: Song Zehui (Xiaohongshu), Zhang Zuowei (Alibaba Cloud)

Nota do editor:

Koordinator é um projeto de código aberto incubado com base em muitos anos de experiência prática em programação de contêineres e co-localização dentro do Alibaba. É o primeiro sistema de co-localização de código aberto da indústria pronto para produção e orientado para cenários de grande escala. Ela está comprometida em melhorar a qualidade do serviço de aplicativos e otimizar a eficiência no uso de recursos. Desde que foi oficialmente aberto em abril de 2022, atraiu contribuições, participação e discussões de muitos engenheiros de destaque na indústria.

Xiaohongshu é um membro ativo da comunidade Koordinator e esteve profundamente envolvido na evolução de uma série de funções importantes desde os primeiros dias do projeto. Este artigo é baseado nos registros reais compartilhados sobre o Koordinator na Conferência Yunqi de 2023. Os membros da comunidade Koordinator, Song Zehui (Xiaohongshu) e Zhang Zuowei (Alibaba Cloud), apresentaram a prática de tecnologia híbrida de Xiaohongshu e os planos recentes do Koordinator.

Introdução ao histórico

Com o rápido desenvolvimento dos negócios de Xiaohongshu, a demanda por recursos de computação para vários negócios online e offline também está crescendo rapidamente. Ao mesmo tempo, a utilização média diária de alguns clusters online permanece num nível baixo.As principais razões para este fenómeno são as seguintes:

A utilização dos recursos do serviço online apresenta uma maré estável de acordo com os hábitos de uso dos usuários finais, e a utilização da CPU é extremamente baixa à noite, resultando em uma baixa utilização média da CPU do cluster;
A empresa mantém um grande número de pools de recursos exclusivos, e a fragmentação do pool de recursos produz um grande número de fragmentos de recursos, o que reduz a utilização da CPU;
Por razões de estabilidade, as empresas acumularão recursos excessivamente, reduzindo ainda mais a utilização da CPU.

Com base no histórico acima, a fim de ajudar as empresas a reduzir os custos de uso de recursos e melhorar a utilização da CPU do cluster, a equipe de contêineres Xiaohongshu começará a melhorar significativamente a eficiência dos recursos do cluster a partir de 2022 e reduzirá os custos dos recursos de negócios por meio da implementação em larga escala da tecnologia de co-localização. .

evolução tecnológica

A evolução da tecnologia de co-localização Xiaohongshu é dividida nas seguintes quatro etapas:

Fase 1: Reutilização de recursos ociosos

No início, o gerenciamento de recursos do cluster era extenso e havia um grande número de pools de recursos exclusivos de negócios no cluster. Devido a fatores como fragmentação de recursos, havia um grande número de nós ineficientes com baixas taxas de alocação. Nós ineficientes espalhados em vários clusters causaram muito desperdício de recursos. Por outro lado, alguns cenários quase-line/off-line baseados na transcodificação liberada pelos K8s requerem uma grande quantidade de recursos computacionais ao longo do dia. Com base no histórico acima, a plataforma de contêiner utiliza meios técnicos para coletar recursos ociosos no cluster e alocá-los para transcodificar cenários de negócios.

Usamos o kubelet virtual para conectar o cluster de metadados e o cluster físico, coletar recursos ociosos e alocá-los para serviços de computação quase on-line/off-line em cenários de transcodificação no cluster de metadados. Em termos de estratégia, o agendador secundário é responsável por inspecionar todos os nós do cluster e marcá-los como nós ineficientes.O virtual-kubelet obtém os recursos disponíveis dos nós ineficientes no cluster físico como recursos ociosos do cluster e os aloca para transcodificação offline pela segunda vez. O agendador secundário precisa garantir que, uma vez que o serviço online tenha requisitos de recursos, ele expulsará imediatamente o pod offline e retornará os recursos.

Etapa 2: Toda a máquina é movida e reutilizada de forma compartilhada

No pool de recursos exclusivos para promoção de pesquisa e outros serviços, o fenômeno da maré de utilização da CPU é óbvio e a taxa de utilização é extremamente baixa à noite. Um único nó no pool de recursos geralmente implanta apenas um pod de negócios de grande porte. Com base no acima do plano de fundo, a plataforma usa recursos elásticos (HPA).Durante o horário comercial no início da manhã, o negócio on-line é reduzido proporcionalmente, toda a máquina é desocupada e pods off-line, como transcodificação e treinamento, são executados durante esse período. período, o que tem o efeito de “encher o vale” na utilização.

Durante a implementação específica, é necessário garantir que todos os serviços online possam ser ativados dentro do tempo especificado.Para tal, em termos de estratégia, implementámos a retirada antecipada offline e utilizámos o mecanismo de preempção do agendador para garantir que os serviços online possam ser levantado antes do período de pico de negócios.Recupere o valor total a tempo.

Estágio Três: Departamento Misto Normal

A fim de reduzir a taxa de fragmentação de recursos e reduzir o custo de retenção de recursos empresariais, a plataforma continua a promover o agrupamento de negócios em grande escala e transfere os negócios do agrupamento exclusivo para o agrupamento público misto alojado pela plataforma. e outros meios técnicos, alocação de CPU A eficiência foi efetivamente melhorada, mas ainda não consegue resolver o problema da baixa utilização noturna do pool de recursos combinados. Por outro lado, no cenário complexo de co-localização após a fusão do pool, é difícil continuar a implementar a estratégia de agendamento de co-localização de compartilhamento de tempo e implantação offline de toda a máquina. A plataforma precisa atingir a utilização média em construir recursos de gerenciamento e agendamento de recursos mais refinados. As metas de melhoria incluem especificamente o seguinte:

Lado do agendamento:

- A quantidade de recursos disponíveis que podem ser alocados secundários para off-line é obtida por meio de tecnologia de overselling dinâmico, e a visualização de recursos off-line é abstraída para que o agendador K8s possa percebê-la. O agendador agenda cargas off-line para os nós correspondentes para obter off-line "preencher o vale" de utilização do nó. "Efeito;
- Através do agendamento de carga, tente evitar que serviços online sejam agendados para máquinas de alta carga, para que a carga do nó no cluster fique mais equilibrada;
- Através do agendamento secundário, os serviços de alta utilização nas máquinas de ponto de acesso de carga são removidos, para que a carga do cluster fique em um estado dinamicamente equilibrado.

Lado único da máquina:

- Suporta estratégia de garantia de Qos (Qualidade de serviço) e fornece recursos diferenciados de garantia de recursos de tempo de execução com base no nível de Qos do serviço;
- Suporta detecção de interferência, remoção offline e outros recursos.Quando a interferência offline interfere nos serviços confidenciais online, ela será removida offline o mais rápido possível.

Através dos meios técnicos acima, podemos garantir efetivamente a estabilidade dos serviços quando eles são misturados, de modo que as cargas de trabalho online e offline possam ser executadas regularmente nos nós, maximizando o efeito de preenchimento do vale de utilização.

Projeto e implementação de arquitetura

O design da arquitetura de agendamento de recursos do contêiner Xiaohongshu é mostrado na figura:

Depois que vários cenários de negócios de Xiaohongshu são enviados por meio de várias plataformas de publicação e plataformas de tarefas, eles são entregues ao sistema de agendamento unificado na forma de pods por meio dos recursos de orquestração de carga da camada superior. Com base em diferentes requisitos de agendamento, o sistema de agendamento unificado fornece forte garantia de capacidades de entrega de recursos para serviços online, capacidades diferenciadas de garantia de QoS e capacidade de garantia de requisitos mínimos de recursos e elasticidade final para serviços offline.

Lado do agendamento:

Agendamento offline: coagendamento;
Agendamento secundário: remoção de hotspot, desfragmentação;
Agendamento de carga: baseado no nível de água da CPU;
Visualização de recursos: agendamento de simulação.

Lado único da máquina:

Estratégia de supressão: supressão de TVC, despejo de memória;
Garantia de Qos: ligação de núcleo, supressão de interferência de hyper-threading, etc.;
Relatórios de recursos em lote: cálculo e relatórios de recursos disponíveis em lote;
Coleta de indicadores (do kernel): psi, informações programadas, etc.;
Detecção de interferência: Detecção de interferência baseada em cpi, psi e indicadores de negócios.

Visualização de recurso de agendamento offline

O princípio básico do agendamento de recursos de serviço offline é a venda excessiva dinâmica com base nas capacidades de detecção de carga de serviço online.A implementação específica é alocar recursos ociosos de nó secundários para serviços offline:

Os recursos offline disponíveis são os recursos ociosos no nó (incluindo a soma de recursos não alocados e recursos alocados não utilizados), e os recursos restantes após a dedução dos recursos reservados de segurança.A fórmula de cálculo dos recursos offline disponíveis é a seguinte:

Recursos disponíveis offline = recursos gerais da máquina – recursos reservados – uso real de serviços online

A quantidade calculada de recursos off-line disponíveis é distribuída de acordo com o tempo, conforme mostrado na figura (parte verde da figura):

Durante o processo de implementação real, a fim de evitar grandes flutuações nos recursos off-line disponíveis devido a flutuações no uso de recursos de serviços on-line, afetando assim a qualidade dos recursos off-line e a estabilidade das operações de serviços off-line, os dados reais de uso dos serviços on-line acima A fórmula é processada posteriormente por meio de retratos de recursos para remover o ruído dos dados e, finalmente, calcula uma quantidade relativamente estável de recursos disponíveis off-line (parte verde na figura), conforme mostrado na figura:

Estratégia de garantia de QoS co-localizada

Classificação de QoS

De acordo com os requisitos de negócios para qualidade de serviço (QoS: Qualidade de serviço), simplesmente dividimos os tipos de negócios de Xiaohongshu em três níveis de QoS, conforme mostrado na tabela a seguir:

Nível de qualidade de serviço	ilustrar	Cena de negócios
sensível à latência	O mais alto nível de garantia de Qos, serviços extremamente sensíveis a atrasos	Cenários em que os atrasos na pesquisa e na promoção são extremamente sensíveis
meio	Nível de garantia de Qos padrão, tolerando alguns atrasos de interferência	Gateway, microsserviços java
lote	O nível de garantia de Qos mais baixo, não sensível a atrasos, os recursos podem ser roubados a qualquer momento	Transcodificação, spark, flink, treinamento e outros cenários de computação

Garantia de QoS

De acordo com os requisitos de QoS do serviço, o lado do nó executará a garantia hierárquica de recursos na granularidade do Pod para implementar estratégias diferenciadas de garantia de QoS para cada dimensão de recurso. Os parâmetros de garantia específicos são os seguintes:

recurso	característica	sensível à latência	meio	lote
CPU	Explosão de CPU	habilitar	habilitar	desabilitar
Prioridade de agendamento	Altíssima	padrão	Baixo
núcleo amarrado	compartilhar (padrão)	compartilhar (padrão)	recuperado
numa	Garantia forte	preferir (padrão)	nenhum
Cache L3	100%	100% (padrão)	30% (padrão)
Largura de banda de memória	100%	100% (padrão)	30% (padrão)
Memória	Prioridade de sala de aula	mais baixo	padrão	Altíssima
Linha d'água de recuperação de memória	Virar para cima	padrão	Recusar

No nível de agendamento do núcleo da CPU, três tipos de ligações principais são configurados e um conjunto de estratégias refinadas de orquestração do núcleo da CPU é projetado. O diagrama de alocação é o seguinte:

Os três tipos de núcleos de ligação são:

exclusivo (não recomendado)

- Características: domínio de agendamento cpuset vinculativo, detecção CCD, ligação numa, exclusivo
- Cenário: promoção de pesquisa extremamente sensível e serviços sensíveis a atrasos em grande escala

- Recursos: domínio de agendamento de cpuset vinculativo, reconhecimento de CCD, vinculação numa (opcional), compartilhamento/exclusivo exclusivo, pode ser compartilhado com nenhum tipo de negócio
- Cenário: microsserviços Java, gateways de aplicativos, serviços web que toleram interferência parcial

recuperado

- Recursos: Sem ligação de cpuset, pode compartilhar núcleos com serviços de modo de ligação de núcleo não exclusivos, a alocação de núcleo é completamente deixada para o kernel, os recursos da CPU não são 100% satisfeitos
- Cenário: serviços off-line em lote, alguns serviços de computação que não exigem atraso

Despejo off-line

Em cenários extremos, como o uso de memória de toda a máquina é alto, há risco de acionamento de OOM ou a CPU do serviço offline não pode ser satisfeita por um longo tempo, o lado da máquina única suporta integração multidimensional de acordo com a prioridade configuração definida internamente para o serviço offline, utilização de recursos, tempo de execução, etc. Após a classificação por pontuação, eles são expulsos na ordem.

Cenário de negócios off-line

Como uma comunidade de conteúdo com centenas de milhões de usuários, Xiaohongshu tem cenários de negócios off-line ricos e diversos, incluindo um grande número de cenários de transcodificação de vídeo e imagem, pesquisa e push, treinamento de inferência de algoritmo cv/nlp, produção de recursos de algoritmo, consulta de data warehouse, Os cenários off-line, especificamente, incluem os seguintes tipos de negócios:

Cenário de transcodificação quase off-line (contêinerizado)
Flink streaming/computação em lote (contêinerizado)
Computação em lote Spark (não conteinerizada, em fio)
Cenário de retraço do algoritmo cv/nlp (contêinerizado)
Cenário de treinamento (contêinerizado)

Ao fornecer recursos unificados de agendamento off-line baseados em K8s, esses serviços off-line e serviços on-line são misturados e implantados em um conjunto unificado de recursos de computação para fornecer garantia de qualidade de recursos diferenciada para serviços on-line e enorme poder de computação de baixo nível para serviços off-line. eficiência.

Solução de co-localização K8s e YARN

Devido à comercialização interna de Xiaohongshu, há um grande número de tarefas algorítmicas na pesquisa da comunidade e em outros negócios. Devido à escassez de recursos de cluster off-line, as tarefas se acumularam e não podem ser processadas a tempo. Ao mesmo tempo, o recurso A taxa de utilização do cluster on-line é baixa durante os horários de pico de negócios. Por outro lado, uma proporção considerável do agendamento de recursos de tarefas Spark ainda é executada no agendador Yarn. Nesse contexto, para reduzir os custos de migração de negócios e a seleção de soluções, nós optou por cooperar com a comunidade Kooridinator e adotar a solução híbrida Yarn on K8s para implementação rápida.Mistura de cenário offline do Spark, o plano específico é mostrado na figura:

Cargas de trabalho on-line e off-line em contêineres são publicadas no cluster on-line por meio de links K8s, e as tarefas do Spark são agendadas para nós específicos por meio do Yarn ResourceManager e puxadas pelo componente Nodemanager no nó. O Nodemanager é implantado em um cluster K8s online por meio de contêineres e também envolve os seguintes componentes:

Lado do agendamento

- koord-yarn-operator: suporta sincronização bidirecional de K8s e visualizações de recursos do agendador de fios;

lado do nó

- copiloto: agente de operação NodeManager, fornecendo gerenciamento de tarefas Yarn e interface de controle;
- Neptune-agent/koordlet: relatórios de recursos off-line, gerenciamento de pod/tarefas off-line de nós, resolução de conflitos, despejo, estratégia de supressão;

Os principais recursos para suportar a implantação híbrida de K8s e YARN foram desenvolvidos na comunidade e serão lançados na versão 1.4 do Koordinator no final de novembro.

Sincronização de recursos com vários agendadores

O agendador K8s e o agendador YARN são originalmente independentes e não se conhecem. Para compartilhar e alocar o total de recursos offline disponíveis nos nós do cluster online, o componente koord-yarn-operator precisa ser usado para executar a sincronização bidirecional de recursos e sincronização entre os dois agendadores.Coordene e implemente dois links sincronizados:

O link de sincronização de recursos do agendador K8s-> YARN é responsável por sincronizar a quantidade total de recursos off-line da perspectiva do Yarn. A quantidade total de recursos off-line do YARN é calculada da seguinte forma:

Quantidade total de recursos offline do YARN = Quantidade total disponível offline - nó lateral K8s alocado

O link de sincronização de recursos do agendador YARN->K8s é responsável por sincronizar a quantidade de recursos alocados do YARN.A quantidade total de recursos offline do K8s é calculada da seguinte forma:

Quantidade total de recursos off-line K8s = Quantidade total disponível off-line - o nó lateral do YARN foi alocado

Com base nas visualizações de recursos offline de seus respectivos nós, os dois agendadores tomam decisões de agendamento respectivamente e agendam Pods offline K8s e tarefas YARN para os nós.Uma vez que o processo de sincronização não é adequado para bloqueio, o problema de alocação excessiva de recursos pode ocorrer:

A solução específica é adicionar lógica de arbitragem ao lado da máquina única.Quando a quantidade de recursos de serviço off-line alocados para um nó excede os recursos off-line disponíveis do nó por um longo período e a taxa de uso off-line continua alta, há é uma possibilidade de que os serviços off-line não consigam obter recursos e morram de fome. O serviço off-line será calculado de forma abrangente e despejado em ordem com base em fatores como prioridade, uso de recursos e tempo de execução.

Suporte ao produto Alibaba Cloud EMR

Ao mesmo tempo, a equipe Alibaba Cloud EMR fornece suporte ao desenvolvimento para a função de co-localização no nível do produto.Com base na compatibilidade com os logs originais, monitoramento e lógica de operação e manutenção do EMR, ele suporta a capacidade dos clusters K8s de expandir e reduzir elasticamente os pods do NodeManager.

Renda de implementação

Até agora, as capacidades de co-localização de Xiaohongshu cobrem centenas de milhares de máquinas, milhões de núcleos em poder computacional e suportam agendamento de recursos para dezenas de milhares de serviços de cenário online e offline. Através da promoção contínua da implantação híbrida de contentores em grande escala, Xiaohongshu alcançou ganhos significativos na eficiência de custos de recursos e outros aspectos, incluindo os dois aspectos seguintes:

Utilização da CPU

- Sob a premissa de garantir a qualidade dos serviços online, a utilização média diária da CPU de clusters de colocalização online aumentou para mais de 45% , e a utilização média diária da CPU de alguns clusters pode aumentar continuamente para 55%.
- Por meios técnicos, como colocation offline, a utilização da CPU de clusters online pode ser aumentada em 8% a 15% e a utilização da CPU de alguns clusters de armazenamento pode ser aumentada em mais de 20%.

custo de recurso

- Com a premissa de garantir a estabilidade dos negócios off-line, fornece milhões de horas centrais de poder de computação de baixo custo para vários cenários off-line de Xiaohongshu .
- A taxa de alocação de CPU do cluster co-localizado aumentou para mais de 125%.Em comparação com o pool de recursos exclusivos, a taxa de fragmentação de recursos caiu significativamente.

Processo de coconstrução comunitária

Xiaohongshu é uma das primeiras empresas a participar da comunidade Koordinator. Em abril de 2022, o Koordinator foi oficialmente de código aberto. Em junho do mesmo ano, Xiaohongshu lançou um projeto de co-localização offline internamente e começou a participar do design e código da solução Koordinator submissão. Em agosto de 2022, Xiaohongshu e a comunidade construíram em conjunto o componente proxy de tempo de execução e o implementaram em cenários internos. Em abril de 2023, Xiaohongshu assumiu a liderança no lançamento do projeto de co-implantação YARN e K8s na comunidade.Em agosto de 2023, o plano foi implementado em grande escala dentro de Xiaohongshu.

Até agora, com a ajuda do Koorindiator, a co-localização de Xiaohongshu cobriu dezenas de milhares de nós da empresa, fornecendo centenas de milhares de recursos off-line essenciais, e a utilização geral do cluster de co-localização aumentou para mais de 45%. Conseguiu um bom efeito de pouso.

Resumo e Perspectiva

No processo de exploração de tecnologia de co-localização de Xiaohongshu por mais de um ano, acumulamos uma rica experiência na melhoria da eficiência dos recursos e alcançamos bons resultados de melhoria. À medida que a escala de negócios da empresa cresce gradualmente, os cenários se tornam cada vez mais complexos. Enfrentaremos muitos novos desafios técnicos. Nosso objetivo na próxima etapa é construir recursos unificados de agendamento de recursos para arquitetura de nuvem híbrida. O trabalho específico se concentrará nos três aspectos a seguir:

Suporte para capacidade de agendamento de carga de trabalho mista: construção de recursos de agendamento de carga de trabalho baseados em tarefas, incluindo big data e IA para atender às funções de agendamento de recursos e requisitos de desempenho de todos os cenários de negócios de Xiaohongshu;
A eficiência dos recursos é melhorada ainda mais: Para a arquitetura de nuvem híbrida, promover o agrupamento de recursos em maior escala, promover a entrega de recursos com base em cotas e alcançar melhorias adicionais na utilização de recursos de cluster por meio de elasticidade mais radical, colocalização, vendas excessivas e outros meios técnicos. em custos;
Maiores capacidades de garantia de qualidade de serviço: No contexto de metas de utilização de CPU mais agressivas, através da construção de capacidades de agendamento com reconhecimento de Qos, capacidades de detecção de interferência e contando com meios técnicos, como contêineres de segurança, vários tipos de confusão que podem ser encontrados em águas profundas implantações mistas podem ser resolvidas.problema de interferência externa.

Planos recentes da comunidade Koordinator

Nas próximas versões, o Koordinator focará nos seguintes aspectos:

Otimização de desempenho do agendador: suporta agendamento de classe equivalente e evita cálculos repetidos de filtro, pontuação e outros processos de agendamento, mesclando pods com a mesma solicitação.
QoS da rede: Dimensiona a qualidade do serviço do contêiner da rede, garantindo largura de banda de alta prioridade, projetando o modelo de solicitação/limite para garantir o requisito mínimo de largura de banda.
Carga de big data: suporta preempção atômica de agendamento de grupo e preempção geral de pods por grupo; adaptação de política de QoS para tarefas do Hadoop YARN.
Detecção de interferência de recursos: com base em indicadores subjacentes, ele detecta a concorrência de recursos de contêineres, identifica pods anormais, elimina interferências e realimenta links de agendamento.

Você pode usar o DingTalk para pesquisar o número do grupo: 33383887 para ingressar no grupo DingTalk da comunidade Koordinator

Clique aqui para ver a introdução detalhada e o uso do Koordinator!