Aprendizado federado entre silos e dispositivos no Google Cloud

Last reviewed 2024-06-03 UTC

Este documento descreve duas arquiteturas de referência que ajudam você a criar um aprendizado federado no Google Cloud usando o Google Kubernetes Engine (GKE). As arquiteturas de referência e os recursos associados descritos neste documento dão suporte ao seguinte:

  • Aprendizado federado entre silos
  • Aprendizado federado entre dispositivos, baseado na arquitetura entre silos

Os públicos-alvo deste documento são arquitetos de nuvem e engenheiros de IA e ML que querem implementar casos de uso de aprendizado federado no Google Cloud. Ela também é destinada a tomadores de decisão que estão avaliando a implementação do aprendizado federado no Google Cloud.

Arquitetura

Os diagramas nesta seção mostram uma arquitetura entre silos e uma arquitetura entre dispositivos para aprendizado federado. Para saber mais sobre os diferentes aplicativos relacionados a essas arquiteturas, consulte Casos de uso.

Arquitetura entre silos

No diagrama a seguir, mostramos uma arquitetura compatível com o aprendizado federado entre silos:

Arquitetura entre silos, componentes descritos no texto a seguir.

O diagrama anterior mostra um exemplo simplista de uma arquitetura entre silos. No diagrama, todos os recursos estão no mesmo projeto na organização do Google Cloud. Esses recursos incluem o modelo cliente local, o modelo global o modelo de cliente e as cargas de trabalho de aprendizado federado associadas.

Essa arquitetura de referência pode ser modificada a fim de trabalhar com várias configurações para silos de dados. Os membros do consórcio podem hospedar os silos de dados das seguintes formas:

  • No Google Cloud, na mesma organização e projeto do Google Cloud.
  • No Google Cloud, na mesma organização do Google Cloud, em diferentes projetos do Google Cloud.
  • No Google Cloud, em diferentes organizações do Google Cloud.
  • Em ambientes privados, locais ou em outras nuvens públicas.

Para que os membros participantes colaborem, eles precisam estabelecer canais de comunicação seguros entre os ambientes. Para mais informações sobre o papel dos membros participantes no esforço de aprendizado federado, como eles colaboram e o que compartilham entre si, consulte Casos de uso.

A arquitetura inclui os seguintes componentes:

  • Uma sub-rede e uma rede de nuvem privada virtual (VPC).
  • Um cluster particular do GKE que ajuda você a fazer o seguinte:
    • Isolar os nós do cluster da Internet.
    • Limitar a exposição dos nós do cluster e do plano de controle à Internet criando um cluster particular do GKE com redes autorizadas.
    • Usar nós de cluster protegidos que usam uma imagem do sistema operacional com aumento da proteção.
    • Ativar o Dataplane V2 para otimizar a rede do Kubernetes.
  • Pools de nós dedicados do GKE: você cria um pool de nós dedicado para hospedar exclusivamente apps e recursos de locatários. Os nós têm taints para garantir que apenas cargas de trabalho do locatário sejam programadas neles. Outros recursos de cluster são hospedados no pool de nós principal.

  • Criptografia de dados (ativada por padrão):

  • Criptografia de dados em uso, ativando a opção Nós confidenciais do Google Kubernetes Engine.

  • Regras de firewall da VPC que se aplicam ao seguinte:

    • Regras de referência que se aplicam a todos os nós no cluster.
    • Regras adicionais que se aplicam apenas aos nós no pool de nós de locatário. Essas regras de firewall limitam a entrada e a saída de nós de locatário.

  • Cloud NAT para permitir a saída para a Internet.

  • Registros do Cloud DNS para ativar o Acesso privado do Google, de modo que os apps no cluster possam acessar as APIs do Google sem passar pela Internet.

  • Contas de serviço, que são as seguintes:

    • Uma conta de serviço dedicada para os nós no pool de nós de locatário.
    • Uma conta de serviço dedicada para apps de locatários usarem com a federação de identidade da carga de trabalho.

  • Suporte ao uso dos Grupos do Google para o controle de acesso baseado em papéis (RBAC) do Kubernetes.

  • Um repositório Git para armazenar descritores de configuração.

  • Um repositório do Artifact Registry para armazenar imagens de contêiner.

  • Config Sync e Policy Controller para implantar configurações e políticas.

  • Gateways do Cloud Service Mesh para permitir, de modo seletivo, o tráfego de entrada e saída do cluster.

  • Buckets do Cloud Storage para armazenar pesos de modelos globais e locais.

  • Acesso a outras APIs do Google e do Google Cloud. Por exemplo, uma carga de trabalho de treinamento precisa acessar os dados armazenados no Cloud Storage, BigQuery ou Cloud SQL.

Arquitetura entre dispositivos

O diagrama a seguir mostra uma arquitetura compatível com o aprendizado federado entre dispositivos:

Arquitetura entre dispositivos, componentes explicados no texto a seguir.

A arquitetura anterior para dispositivos diferentes se baseia na arquitetura de vários silos com a adição dos seguintes componentes:

  • Serviço do Cloud Run que simula a conexão de dispositivos com o servidor
  • Um Certificate Authority Service que cria certificados particulares para o servidor e os clientes executarem
  • Um TensorBoard da Vertex AI para visualizar o resultado do treinamento
  • Um bucket do Cloud Storage para armazenar o modelo consolidado
  • O cluster particular do GKE que usa nós confidenciais como pool principal para proteger os dados em uso

A arquitetura entre dispositivos usa componentes do projeto de plataforma federada (FCP) de código aberto. Este projeto inclui o seguinte:

  • Código do cliente para se comunicar com um servidor e executar tarefas nos dispositivos
  • Protocolo para comunicação cliente-servidor
  • Pontos de conexão com o TensorFlow Federated para facilitar a definição de cálculos federados

Os componentes da FCP mostrados no diagrama anterior podem ser implantados como um conjunto de microsserviços. Esses componentes fazem o seguinte:

  • Agregador: esse job lê gradientes do dispositivo e calcula o resultado agregado com a privacidade diferencial.
  • Coletor: esse job é executado periodicamente para consultar tarefas ativas e gradientes criptografados. Essas informações determinam quando a agregação começa.
  • Ferramenta de upload de modelos: detecta eventos e publica resultados para que os dispositivos possam fazer o download de modelos atualizados.
  • Atribuição de tarefas: esse serviço de front-end distribui tarefas de treinamento para os dispositivos.
  • Gerenciamento de tarefas: esse job gerencia tarefas.
  • Agendador de tarefas: o job é executado periodicamente ou é acionado por eventos específicos.

Produtos usados

As arquiteturas de referência para os dois casos de uso de aprendizado federado usam os seguintes componentes do Google Cloud:

O GKE também oferece os seguintes recursos para sua plataforma de aprendizado federada:

  • Hospedar o coordenador de aprendizado federado: ele é responsável por gerenciar o processo de aprendizado federado. Esse gerenciamento inclui tarefas como distribuição do modelo global para participantes, agregação de atualizações dos participantes e atualização do modelo global. É possível usar o GKE para hospedar o coordenador de aprendizado federado de forma altamente disponível e escalonável.
  • Hospedar os participantes do aprendizado federado: os participantes do aprendizado federado são responsáveis por treinar o modelo global nos dados locais. O GKE pode ser usado para hospedar participantes de aprendizado federados de maneira segura e isolada. Essa abordagem pode ajudar a garantir que os dados dos participantes sejam mantidos no local.
  • Fornecer um canal de comunicação seguro e escalonável: os participantes do aprendizado federado precisam se comunicar com o coordenador de aprendizado federado de maneira segura e escalonável. O GKE pode ser usado para fornecer um canal de comunicação seguro e escalonável entre os participantes e o coordenador.
  • Gerenciamento do ciclo de vida das implantações de aprendizado federado: o GKE pode ser usado para gerenciar o ciclo de vida das implantações de aprendizado federado. Esse gerenciamento inclui tarefas como provisionamento de recursos, implantação da plataforma de aprendizado federada e monitoramento do desempenho dessa plataforma.

Além desses benefícios, o GKE também fornece vários recursos que podem ser úteis para implantações de aprendizado federado, como os seguintes:

  • Clusters regionais: o GKE permite criar clusters regionais, ajudando a melhorar o desempenho das implantações de aprendizado federado reduzindo a latência entre os participantes e o coordenador.
  • Políticas de rede: o GKE permite criar políticas de rede, ajudando a melhorar a segurança das implantações de aprendizado federado, controlando o fluxo de tráfego entre os participantes e o coordenador.
  • Balanceamento de carga: o GKE oferece várias opções de balanceamento de carga, ajudando a melhorar a escalonabilidade de implantações de aprendizado federado, distribuindo o tráfego entre os participantes e o coordenador.

O TFF oferece os recursos abaixo para facilitar a implementação de casos de uso de aprendizado federados:

  • A capacidade de expressar cálculos federados de forma declarativa, que são um conjunto de etapas de processamento executadas em um servidor e um conjunto de clientes. Esses cálculos podem ser implantados em diversos ambientes de execução.
  • Agregadores personalizados podem ser criados usando o código aberto do TFF.
  • Suporte a diversos algoritmos de aprendizado federado, incluindo os seguintes algoritmos:
    • Média federada:um algoritmo que faz a média dos parâmetros do modelo dos clientes participantes. Ele é particularmente adequado para casos de uso em que os dados são relativamente homogêneos e o modelo não é muito complexo. Os casos de uso típicos são os seguintes:
      • Recomendações personalizadas: uma empresa pode usar uma média federada para treinar um modelo que recomenda produtos aos usuários com base no histórico de compras.
      • Detecção de fraude: um consórcio de bancos pode usar uma média federada para treinar um modelo que detecta transações fraudulentas.
      • Diagnóstico médico: um grupo de hospitais pode usar uma média federada para treinar um modelo que diagnostica câncer.
    • Gradiente descendente estocástico federado (FedSGD, na sigla em inglês): é um algoritmo que usa o gradiente descendente estocástico para atualizar os parâmetros do modelo. Ele é adequado para casos de uso em que os dados são heterogêneos e o modelo é complexo. Os casos de uso típicos são os seguintes:
      • Processamento de linguagem natural: uma empresa pode usar o FedSGD para treinar um modelo que melhore a acurácia do reconhecimento de fala.
      • Reconhecimento de imagem: uma empresa pode usar o FedSGD para treinar um modelo capaz de identificar objetos em imagens.
      • Manutenção preditiva: uma empresa pode usar o FedSGD para treinar um modelo que prevê a probabilidade de falha de uma máquina.
    • Federated Adam: um algoritmo que usa o otimizador Adam para atualizar os parâmetros do modelo. Os casos de uso típicos são os seguintes:
      • Sistemas recomendadores: uma empresa pode usar o Adam federado para treinar um modelo que recomenda produtos aos usuários com base no histórico de compras.
      • Classificação: uma empresa pode usar o Adam federado para treinar um modelo que classifica os resultados da pesquisa.
      • Previsão da taxa de cliques: uma empresa pode usar o Adam federado para treinar um modelo que prevê a probabilidade de um usuário clicar em um anúncio.

Casos de uso

Nesta seção, descrevemos casos de uso em que as arquiteturas entre silos e dispositivos são as escolhas apropriadas para a plataforma de aprendizado federada.

O aprendizado federado é uma configuração de machine learning em que vários clientes treinam um modelo de forma colaborativa. Esse processo é liderado por um coordenador central, e os dados de treinamento permanecem descentralizados.

No paradigma de aprendizado federado, os clientes fazem o download de um modelo global e o aprimoram treinando localmente nos dados deles. Em seguida, cada cliente envia as atualizações calculadas do modelo de volta ao servidor central, onde as atualizações do modelo são agregadas e uma nova iteração do modelo global é gerada. Nessas arquiteturas de referência, as cargas de trabalho de treinamento de modelos são executadas no GKE.

O aprendizado federado incorpora o princípio de privacidade da minimização de dados (em inglês), restringindo quais dados são coletados em cada estágio do cálculo, limitando o acesso aos dados e processando-os para descartar os dados o mais cedo possível. possível. Além disso, a configuração de problemas do aprendizado federado é compatível com outras técnicas de preservação de privacidade, como o uso de privacidade diferencial (DP, na sigla em inglês) para melhorar a anonimização do modelo. o modelo final não memoriza os dados dos usuários individuais.

Dependendo do caso de uso, os modelos de treinamento com aprendizado federado podem ter outros benefícios:

  • Conformidade: em alguns casos, as regulamentações podem restringir a forma como os dados podem ser usados ou compartilhados. O aprendizado federado pode ser usado para obedecer a essas regulamentações.
  • Eficiência de comunicação: em alguns casos, é mais eficiente treinar um modelo em dados distribuídos do que centralizar os dados. Por exemplo, os conjuntos de dados em que o modelo precisa ser treinado são grandes demais para serem movidos de maneira centralizada.
  • Tornar os dados acessíveis: o aprendizado federado permite que as organizações mantenham os dados de treinamento descentralizados em silos de dados por usuário ou por organização.
  • Maior acurácia do modelo: o treinamento com dados de usuários reais (enquanto garante a privacidade) em vez de dados sintéticos (às vezes chamados de dados de proxy), geralmente, resulta em maior precisão do modelo.

Há diferentes tipos de aprendizado federado, que se caracterizam pelo local de origem dos dados e da realização dos cálculos locais. As arquiteturas neste documento se concentram em dois tipos de aprendizado federado: entre silos e dispositivos. Outros tipos de aprendizado federado estão fora do escopo deste documento.

O aprendizado federado é categorizado pela forma como os conjuntos de dados são particionados, que pode ser da seguinte maneira:

  • Aprendizado federado horizontal (HFL): conjuntos de dados com os mesmos atributos (colunas), mas amostras diferentes (linhas). Por exemplo, vários hospitais podem ter prontuários com os mesmos parâmetros médicos, mas populações de pacientes diferentes.
  • Aprendizado federado vertical (VFL): conjuntos de dados com as mesmas amostras (linhas), mas atributos diferentes (colunas). Por exemplo, um banco e uma empresa de e-commerce podem ter dados de clientes com indivíduos sobrepostos, mas informações financeiras e de compras diferentes.
  • Aprendizado de transferência federado (FTL, na sigla em inglês): sobreposição parcial nas amostras e nos recursos entre os conjuntos de dados. Por exemplo, dois hospitais podem ter registros de pacientes com alguns indivíduos sobrepostos e alguns parâmetros médicos compartilhados, mas também atributos únicos em cada conjunto de dados.

Na computação federada entre silos, os membros participantes são organizações ou empresas. Na prática, o número de membros geralmente é pequeno (por exemplo, até cem membros). A computação entre silos normalmente é usada em cenários em que as organizações participantes têm conjuntos de dados diferentes, mas querem treinar um modelo compartilhado ou analisar resultados agregados sem compartilhar os dados brutos entre si. Por exemplo, os membros participantes podem ter seus ambientes em diferentes organizações do Google Cloud, como quando representam pessoas jurídicas diferentes, ou na mesma organização do Google Cloud, como quando representam diferentes departamentos de mesma pessoa jurídica.

Talvez os membros participantes não considerem as cargas de trabalho uns dos outros como entidades confiáveis. Por exemplo, um membro participante pode não ter acesso ao código-fonte de uma carga de trabalho de treinamento recebida de um terceiro, como o coordenador. Como não pode acessar esse código-fonte, o membro participante não pode garantir que a carga de trabalho seja totalmente confiável.

Para evitar que uma carga de trabalho não confiável acesse seus dados ou recursos sem autorização, recomendamos o seguinte:

  • Implante cargas de trabalho não confiáveis em um ambiente isolado.
  • Conceda às cargas de trabalho não confiáveis apenas os direitos de acesso e as permissões estritamente necessários para concluir as rodadas de treinamento atribuídas à carga de trabalho.

Para ajudar a isolar cargas de trabalho potencialmente não confiáveis, essas arquiteturas de referência implementam controles de segurança, como a configuração de namespaces isolados do Kubernetes, em que cada namespace tem um pool de nós dedicado do GKE. A comunicação entre namespaces e o tráfego de entrada e saída de clusters são proibidos por padrão, a menos que você substitua explicitamente essa configuração.

Exemplos de casos de uso para aprendizado federado entre silos são os seguintes:

  • Detecção de fraude: o aprendizado federado pode ser usado para treinar um modelo de detecção de fraudes em dados distribuídos por várias organizações. Por exemplo, um consórcio de bancos pode usar o aprendizado federado para treinar um modelo que detecta transações fraudulentas.
  • Diagnóstico médico: o aprendizado federado pode ser usado para treinar um modelo de diagnóstico médico em dados distribuídos em vários hospitais. Por exemplo, um grupo de hospitais pode usar o aprendizado federado para treinar um modelo que diagnostica o câncer.

O aprendizado federado entre dispositivos é um tipo de computação federada em que os membros participantes são dispositivos de usuários finais, como smartphones, veículos ou dispositivos de IoT. Esse número pode chegar a uma escala de milhões ou até dezenas de milhões.

O processo para o aprendizado federado entre dispositivos é semelhante ao do aprendizado federado entre silos. No entanto, isso também exige que você adapte a arquitetura de referência para acomodar alguns dos fatores extras que precisa considerar ao lidar com milhares ou milhões de dispositivos. É preciso implantar cargas de trabalho administrativas para lidar com cenários encontrados em casos de uso de aprendizado federado em vários dispositivos. Por exemplo, a necessidade de coordenar um subconjunto de clientes que vai ocorrer no ciclo de treinamento. A arquitetura entre dispositivos oferece essa capacidade, permitindo que você implante os serviços da FCP. Esses serviços têm cargas de trabalho que têm pontos de conexão com o TFF. O TFF é usado para escrever o código que gerencia essa coordenação.

Confira abaixo exemplos de casos de uso para aprendizado federado entre dispositivos:

  • Recomendações personalizadas: é possível usar o aprendizado federado em dispositivos diferentes para treinar um modelo de recomendação personalizado em dados distribuídos em vários dispositivos. Por exemplo, uma empresa pode usar o aprendizado federado para treinar um modelo que recomenda produtos aos usuários com base no histórico de compras.
  • Processamento de linguagem natural: o aprendizado federado pode ser usado para treinar um modelo de processamento de linguagem natural em dados distribuídos em vários dispositivos. Por exemplo, uma empresa pode usar o aprendizado federado para treinar um modelo que melhore a acurácia do reconhecimento de fala.
  • Previsão das necessidades de manutenção do veículo: o aprendizado federado pode ser usado para treinar um modelo que prevê quando um veículo provavelmente precisará de manutenção. Esse modelo pode ser treinado com dados coletados de vários veículos. Essa abordagem permite que o modelo aprenda com as experiências de todos os veículos, sem comprometer a privacidade de nenhum deles.

A tabela a seguir resume os recursos das arquiteturas entre silos e dispositivos, e mostra como categorizar o tipo de cenário de aprendizado federado aplicável ao seu caso de uso.

Engenharia de Computações federadas entre silos Computações federadas em vários dispositivos
Tamanho da população Geralmente pequeno (por exemplo, em até cem dispositivos) Escalonável para milhares, milhões ou centenas de milhões de dispositivos
Participantes Organizações ou empresas Dispositivos móveis, dispositivos de borda, veículos
Particionamento de dados mais comum HFL, VFL e FTL HFL
Sensibilidade de dados Dados sensíveis que os participantes não querem compartilhar entre si em formato bruto. Dados sensíveis demais para serem compartilhados com um servidor central
Disponibilidade de dados Os participantes estão quase sempre disponíveis Apenas alguns participantes estão disponíveis a qualquer momento
Exemplos de casos de uso Detecção de fraude, diagnóstico médico, previsão financeira Monitoramento de atividade física, reconhecimento de voz, classificação de imagens

Considerações sobre o design

Nesta seção, fornecemos orientações para ajudar você a usar essa arquitetura de referência para desenvolver uma ou mais arquiteturas que atendam aos seus requisitos específicos de segurança, confiabilidade, eficiência operacional, custo e desempenho.

Considerações sobre o projeto de arquitetura entre silos

Para implementar uma arquitetura de aprendizado federado entre silos no Google Cloud, é preciso implementar os seguintes pré-requisitos mínimos, que são explicados em mais detalhes nas seguintes seções:

  1. Estabelecer um consórcio de aprendizado federado
  2. Determine o modelo de colaboração para o consórcio de aprendizado federado a ser implementado.
  3. Determinar as responsabilidades das organizações participantes.

Além desses pré-requisitos, há outras ações que o proprietário da federação precisa realizar fora do escopo deste documento, como:

  • Gerencie o consórcio de aprendizado federado.
  • Elaborar e implementar um modelo de colaboração.
  • Prepare, gerencie e opere os dados de treinamento do modelo e o modelo que o proprietário da federação pretende treinar.
  • Crie, conteinerize e orquestre fluxos de trabalho de aprendizado federados.
  • Implante e gerencie cargas de trabalho de aprendizado federados.
  • Configuração dos canais de comunicação para as organizações participantes transferirem dados com segurança.

Estabelecer um consórcio de aprendizado federado

Um consórcio de aprendizado federado é o grupo de organizações que participam de um esforço de aprendizado federado entre silos. As organizações do consórcio compartilham apenas os parâmetros dos modelos de ML, e é possível criptografar esses parâmetros para aumentar a privacidade. Se o consórcio de aprendizado federado permitir a prática, as organizações também poderão agregar dados que não contêm informações de identificação pessoal (PII).

Determinar um modelo de colaboração para o consórcio de aprendizado federado

O consórcio de aprendizado federado pode implementar diferentes modelos de colaboração, como:

  • Um modelo centralizado formado uma única organização coordenadora, chamada de proprietário da federação ou orquestrador, e um conjunto de organizações participantes ou proprietários de dados.
  • Um modelo descentralizado formado por organizações que coordenam em grupo.
  • Um modelo heterogêneo formado por um consórcio de diversas organizações participantes, em que todas trazem recursos diferentes para o consórcio.

Neste documento, presumimos que o modelo de colaboração é um modelo centralizado.

Determinar as responsabilidades das organizações participantes

Após escolher um modelo de colaboração para o aprendizado federado, o proprietário da federação precisa determinar as responsabilidades das organizações participantes.

Além disso, precisa fazer o seguinte ao começar a criar um consórcio de aprendizado federado:

  • Coordenar o esforço de aprendizado federado.
  • Projetar e implementar o modelo global de ML e os modelos de ML a serem compartilhados com as organizações participantes.
  • Definir as rodadas de aprendizado federado, a abordagem para a iteração do processo de treinamento de ML.
  • Selecionar as organizações participantes que contribuem para um determinado ciclo de aprendizado federado. Essa seleção é chamada de coorte.
  • Projetar e implementar um procedimento de verificação de associação ao consórcio para as organizações participantes.
  • Atualizar o modelo global de ML e os modelos de ML a serem compartilhados com as organizações participantes.
  • Oferecer às organizações participantes as ferramentas para validar se o consórcio de aprendizado federado atende aos requisitos de privacidade, segurança e regulamentação.
  • Disponibilizar canais de comunicação seguros e criptografados às organizações participantes.
  • Oferecer às organizações participantes todos os dados agregados não confidenciais necessários para concluir cada rodada de aprendizado federado.

As organizações participantes têm as seguintes responsabilidades:

  • Fornecer e manter um ambiente seguro e isolado (um silo). É no silo que as organizações participantes armazenam os próprios dados e onde o treinamento do modelo de ML é implementado.
  • Treinar os modelos fornecidos pelo proprietário da federação com a própria infraestrutura de computação e os próprios dados locais.
  • Compartilhar os resultados do treinamento de modelo com o proprietário da federação na forma de dados agregados depois de remover todas as PII.

O proprietário da federação e as organizações participantes refinam o treinamento do modelo de ML até que o modelo atenda aos requisitos.

Implementar o aprendizado federado no Google Cloud

Depois de estabelecer o consórcio de aprendizado federado e determinar como o consórcio de aprendizado federado vai colaborar, recomendamos que as organizações participantes façam o seguinte:

  1. Provisionar e configurar a infraestrutura necessária para o consórcio de aprendizado federado..
  2. Implementar o modelo de colaboração.
  3. Iniciar o esforço de aprendizado federado.

Provisionar e configurar a infraestrutura do consórcio de aprendizado federado

Ao provisionar e configurar a infraestrutura do consórcio de aprendizado federado, é responsabilidade do proprietário da federação criar e distribuir as cargas de trabalho que treinam os modelos de ML federado para as organizações participantes. Como um terceiro (o proprietário da federação) criou e forneceu as cargas de trabalho, as organizações participantes precisam tomar precauções ao implantá-las nos ambientes de execução.

As organizações participantes precisam configurar os ambientes de acordo com suas próprias práticas recomendadas de segurança e aplicar controles que limitem o escopo e as permissões concedidas a cada carga de trabalho. Além de seguir suas próprias práticas recomendadas de segurança, é recomendável que o proprietário da federação e as organizações participantes considerem vetores de ameaças específicos do aprendizado federado.

Implementar o modelo de colaboração

Depois que a infraestrutura do consórcio de aprendizado federado estiver preparada, o proprietário da federação projeta e implementa os mecanismos que permitem que as organizações participantes interajam entre si. A abordagem segue o modelo de colaboração escolhido pelo proprietário da federação para o consórcio de aprendizado federado.

Começar o trabalho de aprendizado federado

Após a implementação do modelo de colaboração, o proprietário da federação implementará o modelo de ML global a ser treinado, e os modelos de ML a serem compartilhados com a organização participante. Depois que esses modelos de ML estiverem prontos, o proprietário da federação iniciará a primeira rodada do esforço de aprendizado federado.

Durante cada rodada do esforço de aprendizado federado, o proprietário faz o seguinte:

  1. Distribui os modelos de ML para compartilhar com as organizações participantes.
  2. Espera as organizações participantes fornecerem os resultados do treinamento dos modelos de ML que o proprietário da federação compartilhou.
  3. Coleta e processa os resultados do treinamento produzidos pelas organizações participantes.
  4. Atualiza o modelo de ML global quando recebe os resultados apropriados do treinamento das organizações participantes.
  5. Atualiza os modelos de ML a serem compartilhados com os outros membros do consórcio, quando aplicável.
  6. Prepara os dados de treinamento para a próxima rodada de aprendizado federado.
  7. Inicia a próxima rodada de aprendizado federado.

segurança, privacidade e conformidade

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma plataforma de aprendizado federada no Google Cloud. Esta orientação se aplica às duas arquiteturas descritas neste documento.

As cargas de trabalho de aprendizado federadas que você implanta nos seus ambientes podem expor você, seus dados, seus modelos de aprendizado federado e sua infraestrutura a ameaças que podem afetar seus negócios.

Para ajudar a aumentar a segurança dos seus ambientes de aprendizado federados, essas arquiteturas de referência configuram controles de segurança do GKE que se concentram na infraestrutura dos seus ambientes. Esses controles podem não ser suficientes para proteger você de ameaças específicas às suas cargas de trabalho de aprendizado federadas e aos seus casos de uso. Devido à especificidade de cada carga de trabalho de aprendizado federada e caso de uso, os controles de segurança voltados à proteção da implementação de aprendizado federado estão fora do escopo deste documento. Para mais informações e exemplos sobre essas ameaças, consulte Considerações sobre segurança do aprendizado federado.

Controles de segurança do GKE

Nesta seção, discutimos os controles que você aplica com essas arquiteturas para ajudar a proteger o cluster do GKE.

Segurança aprimorada dos clusters do GKE

Essas arquiteturas de referência ajudam você a criar um cluster do GKE que implementa as seguintes configurações de segurança:

Para mais informações sobre as configurações de segurança do GKE, consulte Aumentar a segurança do cluster e Sobre o painel de postura de segurança.

Regras de firewall de VPC

As regras de firewall da nuvem privada virtual (VPC) determinam qual tráfego é permitido de/para VMs do Compute Engine. As regras permitem filtrar o tráfego na granularidade da VM, dependendo dos atributos da Camada 4.

Crie um cluster do GKE com as regras de firewall padrão do cluster do GKE. Essas regras de firewall permitem a comunicação entre os nós de cluster e o plano de controle do GKE, bem como entre nós e pods no cluster.

Aplique regras de firewall adicionais aos nós do pool do locatário. Essas regras de firewall restringem o tráfego de saída dos nós de locatário. Essa abordagem pode aumentar o isolamento dos nós de locatário. Por padrão, todo o tráfego de saída dos nós de locatário é negado. Todas as saídas obrigatórias precisam ser explicitamente configuradas. Por exemplo, você cria regras de firewall que permitem a saída dos nós de locatário para o plano de controle do GKE e para as APIs do Google usando o Acesso privado do Google. As regras de firewall são segmentadas para os nós de locatário usando a conta de serviço do pool de nós de locatário.

Namespaces

Os namespaces permitem fornecer um escopo para os recursos relacionados em um cluster, por exemplo, pods, serviços e controladores de replicação. Ao usar namespaces, é possível delegar a responsabilidade de administração dos recursos relacionados como uma unidade. Portanto, os namespaces são essenciais para a maioria dos padrões de segurança.

Os namespaces são um recurso importante para o isolamento do plano de controle. No entanto, eles não fornecem isolamento de nós, de plano de dados ou de rede.

Uma abordagem comum é criar namespaces para aplicativos individuais. Por exemplo, é possível criar o namespace myapp-frontend para o componente de IU de um aplicativo.

Essas arquiteturas de referência ajudam a criar um namespace dedicado para hospedar os apps de terceiros. O namespace e os recursos dele são tratados como locatários em seu cluster. Aplique políticas e controles ao namespace para limitar o escopo de recursos no namespace.

Políticas de rede

As políticas de rede aplicam fluxos de tráfego de rede da camada 4 usando regras de firewall no nível do pod. As políticas de rede têm escopo para um namespace.

Nas arquiteturas de referência descritas neste documento, você aplica políticas de rede ao namespace de locatário que hospeda os apps de terceiros. Por padrão, a política de rede nega todo o tráfego com origem e destino em pods do namespace. Qualquer tráfego necessário precisa ser adicionado explicitamente a uma lista de permissões. Por exemplo, as políticas de rede nessas arquiteturas de referência permitem explicitamente o tráfego para os serviços de cluster necessários, como o DNS interno do cluster e o plano de controle do Cloud Service Mesh.

Config Sync

O Config Sync mantém os clusters do GKE sincronizados com as configurações armazenadas em um repositório do Git. O repositório do Git funciona como a única fonte de verdade para as políticas e a configuração do cluster. O Config Sync é declarativo. Ele verifica continuamente o estado do cluster e aplica o estado declarado no arquivo de configuração para aplicar as políticas, o que ajuda a evitar desvios de configuração.

Instale o Config Sync no cluster do GKE. Você configura o Config Sync para sincronizar configurações e políticas de cluster de um repositório do Cloud Source. Os recursos sincronizados incluem:

  • Configuração do Cloud Service Mesh no nível do cluster
  • As políticas de segurança no nível do cluster
  • A configuração e a política no nível do namespace de locatário, incluindo políticas de rede, contas de serviço, regras de RBAC e a configuração do Cloud Service Mesh

Controlador de Políticas

O Controlador de Políticas do Google Kubernetes Engine (GKE) Enterprise é um controlador de admissão dinâmica do Kubernetes que aplica políticas baseadas em CustomResourceDefinition (CRD) que são executadas pelo Open Policy Agent (OPA).

Os controladores de admissão são plug-ins do Kubernetes que interceptam solicitações ao servidor da API Kubernetes antes da permanência de um objeto, mas após a autenticação e autorização da solicitação. É possível usar controladores de admissão para limitar o uso de um cluster.

Instale o Policy Controller no cluster do GKE. Essas arquiteturas de referência incluem exemplos de políticas para proteger o cluster. Aplique automaticamente as políticas ao cluster usando o Config Sync. Aplique as seguintes políticas:

Cloud Service Mesh

O Cloud Service Mesh é uma malha de serviço que ajuda a simplificar o gerenciamento de comunicações seguras entre serviços. Essas arquiteturas de referência configuram o Cloud Service Mesh para que ele faça o seguinte:

  • Injetar automaticamente proxies sidecar.
  • Aplicar a comunicação mTLS entre os serviços na malha.
  • Limitar o tráfego da malha de saída apenas a hosts conhecidos.
  • Limita o tráfego de entrada apenas de determinados clientes.
  • Permitir a configuração de políticas de segurança de rede com base na identidade do serviço e não no endereço IP dos pares na rede.
  • Limitar a comunicação autorizada entre os serviços na malha. Por exemplo, os aplicativos no namespace do locatário só podem se comunicar com aplicativos que estejam no mesmo namespace ou tenham um conjunto de hosts externos conhecidos.
  • Encaminhar todo o tráfego de entrada e saída por gateways de malha, onde é possível aplicar mais controles de tráfego.
  • Oferece suporte à comunicação segura entre clusters;

Afinidades e taints de nós

Os taints de nós e a afinidade de nós são mecanismos do Kubernetes que permitem influenciar na programação dos pods nos nós do cluster.

Os nós com taint repelem pods. O Kubernetes não programará um pod em um nó com taint, a menos que o pod tenha uma tolerância para o taint. Use taints de nó para reservar nós para uso somente por determinadas cargas de trabalho ou locatários. Os taints e as tolerâncias costumam ser usados em clusters multilocatários. Para mais informações, consulte a documentação sobre nós dedicados com taints e tolerâncias.

A afinidade de nós permite restringir os pods a nós com rótulos específicos. Se um pod tiver um requisito de afinidade de nó, o Kubernetes não o programará em um nó, a menos que o nó tenha um rótulo que corresponda ao requisito de afinidade. É possível usar a afinidade de nós para garantir que os pods sejam programados nos nós apropriados.

Use taints e afinidade de nós juntos para garantir que os pods da carga de trabalho do locatário sejam programados exclusivamente em nós reservados para o locatário.

Essas arquiteturas de referência ajudam a controlar a programação dos apps de locatário das seguintes maneiras:

  • Criando um pool de nós do GKE dedicado ao locatário. Cada nó no pool tem um taint relacionado ao nome do locatário.
  • Aplicando automaticamente a tolerância e a afinidade de nós apropriadas a qualquer pod que tenha o namespace de locatário como destino. Aplique a tolerância e a afinidade usando as mutações do Policy Controller.

Privilégio mínimo

É uma prática recomendada de segurança adotar um princípio de privilégio mínimo para os projetos e recursos do Google Cloud, como os clusters do GKE. Ao usar essa abordagem, os apps executados dentro do cluster e os desenvolvedores e operadores que o utilizam terão apenas o conjunto mínimo de permissões necessárias.

Essas arquiteturas de referência ajudam a usar contas de serviço com privilégios mínimos das seguintes maneiras:

  • Cada pool de nós do GKE recebe a própria conta de serviço. Por exemplo, os nós no pool do locatário usam uma conta de serviço dedicada a esses nós. As contas de serviço dos nós são configuradas com as permissões mínimas necessárias.
  • O cluster usa a Identidade da carga de trabalho para associar contas de serviço do Kubernetes a contas de serviço do Google. Dessa forma, os aplicativos do locatário podem receber acesso limitado a qualquer API necessária do Google sem fazer o download nem armazenar uma chave de conta de serviço. Por exemplo, é possível conceder à conta de serviço permissões para ler dados de um bucket do Cloud Storage.

Essas arquiteturas de referência ajudam a restringir o acesso aos recursos do cluster das seguintes maneiras:

  • Você cria um papel RBAC do Kubernetes de amostra com permissões limitadas para gerenciar aplicativos. É possível conceder esse papel aos usuários e grupos que operam os aplicativos no namespace do locatário. Ao aplicar esse papel limitado de usuários e grupos, esses usuários só têm permissões para modificar recursos do app no namespace do locatário. Eles não têm permissões para modificar recursos no nível do cluster ou configurações de segurança confidenciais, como políticas do Cloud Service Mesh.

Autorização binária

A autorização binária permite aplicar políticas definidas sobre as imagens de contêiner que estão sendo implantadas no seu ambiente do GKE. A autorização binária permite que apenas imagens de contêiner que estejam em conformidade com as políticas definidas sejam implantadas. Ela proíbe a implantação de outras imagens de contêiner.

Nesta arquitetura de referência, a autorização binária é ativada com a configuração padrão. Para inspecionar a configuração padrão da autorização binária, consulte Exportar o arquivo YAML da política.

Para mais informações sobre como configurar políticas, consulte as seguintes orientações específicas:

Verificação de atestado entre organizações

É possível usar a autorização binária para verificar atestados gerados por um signatário externo. Por exemplo, em um caso de uso de aprendizado federado entre silos, é possível verificar atestados criados por outra organização participante.

Para verificar os atestados criados por terceiros, faça o seguinte:

  1. Receba as chaves públicas que o terceiro usou para criar os atestados que você precisa verificar.
  2. Crie os atestadores para verificar os atestados.
  3. Adicione as chaves públicas recebidas do terceiro aos atestadores que você criou.

Para mais informações sobre como criar atestadores, consulte as seguintes orientações específicas:

Painel de compliance do GKE

O painel de conformidade do GKE fornece insights úteis para fortalecer sua postura de segurança e ajuda a automatizar os relatórios de conformidade para benchmarks e padrões do setor. É possível registrar seus clusters do GKE para ativar a geração de relatórios de conformidade automatizados.

Para mais informações, consulte Sobre o painel do GKE Compliance.

Considerações sobre segurança de aprendizado federado

Apesar do modelo estrito de compartilhamento de dados, o aprendizado federado não é inerentemente seguro contra todos os ataques direcionados. Leve esses riscos em consideração ao implantar qualquer uma das arquiteturas descritas neste documento. Há também o risco de vazamentos não intencionais de informações sobre modelos de ML ou dados de treinamento de modelos. Por exemplo, um invasor pode comprometer intencionalmente o modelo de ML global ou rodadas do esforço de aprendizado federado, bem como realizar um ataque de temporização (um tipo de ataque de canal lateral) para coletar informações sobre o tamanho dos conjuntos de dados de treinamento.

As ameaças mais comuns contra uma implementação de aprendizado federado são:

  • Memorização de dados de treinamento intencional ou não intencional Sua implementação de aprendizado federado ou um invasor podem armazenar dados de maneira intencional ou não intencional de maneiras difíceis de trabalhar. Um invasor pode reunir informações sobre o modelo de ML global ou as rodadas anteriores do esforço de aprendizado federado com engenharia reversa dos dados armazenados.
  • Extrair informações sobre atualizações no modelo de ML global. Durante o esforço de aprendizado federado, um invasor pode fazer engenharia reversa das atualizações no modelo global de ML que o proprietário da federação coleta das organizações e dos dispositivos participantes.
  • O proprietário da federação pode comprometer rodadas. Um proprietário de federação comprometido pode controlar um silo ou dispositivo não autorizado e iniciar uma rodada do esforço de aprendizado federado. No final da rodada, o proprietário da federação comprometido pode coletar informações sobre as atualizações que coleta de organizações e dispositivos participantes legítimos, comparando essas atualizações com a que o silo não autorizado produziu.
  • As organizações e os dispositivos participantes podem comprometer o modelo global de ML. Durante o esforço de aprendizado federado, um invasor pode tentar afetar maliciosamente o desempenho, a qualidade ou a integridade do modelo de ML global produzindo atualizações falsas ou sem consequências.

Para ajudar a reduzir o impacto das ameaças descritas nesta seção, recomendamos as seguintes práticas recomendadas:

  • Ajustar o modelo para reduzir ao mínimo a memorização dos dados de treinamento.
  • Implemente mecanismos de preservação da privacidade.
  • Faça auditorias regulares do modelo de ML global, dos modelos de ML que você pretende compartilhar, dos dados de treinamento e da infraestrutura que você implementou para atingir suas metas de aprendizado federado.
  • Implemente um algoritmo de agregação segura para processar os resultados do treinamento produzidos pelas organizações participantes.
  • Gere e distribua chaves de criptografia de dados com segurança usando uma infraestrutura de chave pública.
  • Implante a infraestrutura em uma plataforma de computação confidencial.

Os proprietários de federação também precisam seguir estas etapas adicionais:

  • Verifique a identidade da organização dos participantes e a integridade de cada silo no caso de arquiteturas entre silos, e a identidade e integridade de cada dispositivo no caso de arquiteturas entre dispositivos.
  • Limite o escopo das atualizações ao modelo global de ML que as organizações e os dispositivos participantes podem produzir.

Confiabilidade

Nesta seção, descrevemos os fatores de design que você precisa considerar ao usar uma das arquiteturas de referência neste documento para projetar e criar uma plataforma de aprendizado federada no Google Cloud.

Ao projetar sua arquitetura de aprendizado federado no Google Cloud, recomendamos que você siga as orientações desta seção para melhorar a disponibilidade e a escalonabilidade da carga de trabalho e tornar sua arquitetura resistente a interrupções e desastres.

GKE: o GKE é compatível com vários tipos de clusters diferentes que podem ser personalizados de acordo com os requisitos de disponibilidade das cargas de trabalho e seu orçamento. Por exemplo, é possível criar clusters regionais que distribuem o plano de controle e os nós em várias zonas de uma região ou clusters zonais que têm o plano de controle e os nós em uma única zona. As arquiteturas de referência entre silos e dispositivos dependem de clusters regionais do GKE. Para mais informações sobre os aspectos a serem considerados ao criar clusters do GKE, consulte Opções de configuração de cluster.

Dependendo do tipo de cluster e de como o plano de controle e os nós do cluster são distribuídos entre regiões e zonas, o GKE oferece diferentes recursos de recuperação de desastres para proteger suas cargas de trabalho contra interrupções zonais e regionais. Para mais informações sobre os recursos de recuperação de desastres do GKE, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem: Google Kubernetes Engine.

Google Cloud Load Balancing: o GKE oferece suporte a várias maneiras de balancear o tráfego para as cargas de trabalho. As implementações do GKE das APIs Gateway do Kubernetes e Serviço do Kubernetes permitem provisionar e configurar automaticamente o Cloud Load Balancing para expor com segurança e confiabilidade as cargas de trabalho em execução nos clusters do GKE.

Nessas arquiteturas de referência, todo o tráfego de entrada e saída passa pelos gateways do Cloud Service Mesh. Com esses gateways, é possível controlar com firmeza como o tráfego flui dentro e fora dos clusters do GKE.

Desafios de confiabilidade no aprendizado federado entre dispositivos

O aprendizado federado entre dispositivos tem vários desafios de confiabilidade que não são encontrados em cenários entre silos. Isso inclui o seguinte:

  • Conectividade do dispositivo não confiável ou intermitente
  • Armazenamento limitado no dispositivo
  • Computação e memória limitadas

A conectividade não confiável pode causar problemas como os seguintes:

  • Atualizações obsoletas e divergência de modelos: quando os dispositivos têm conectividade intermitente, as atualizações do modelo local podem ficar desatualizadas, representando informações desatualizadas em comparação com o estado atual do modelo global. A agregação de atualizações desatualizadas pode gerar divergências no modelo, em que o modelo global se desvia da solução ideal devido a inconsistências no processo de treinamento.
  • Contribuições desequilibradas e modelos enviesados: a comunicação intermitente pode resultar em uma distribuição desigual de contribuições dos dispositivos participantes. Dispositivos com conectividade ruim podem contribuir com menos atualizações, levando a uma representação desequilibrada da distribuição de dados subjacente. Esse desequilíbrio pode induzir o modelo global em relação aos dados de dispositivos com conexões mais confiáveis.
  • Aumento da sobrecarga de comunicação e do consumo de energia: a comunicação intermitente pode levar a um aumento da sobrecarga de comunicação, já que os dispositivos podem precisar reenviar atualizações perdidas ou corrompidas. Esse problema também pode aumentar o consumo de energia nos dispositivos, especialmente aqueles com duração limitada da bateria, já que talvez seja necessário manter conexões ativas por períodos mais longos para garantir a transmissão de atualizações.

Para reduzir alguns dos efeitos causados pela comunicação intermitente, as arquiteturas de referência neste documento podem ser usadas com a FCP.

Uma arquitetura de sistema que executa o protocolo FCP pode ser projetada para atender aos seguintes requisitos:

  • Processar rodadas longas.
  • Ative a execução especulativa. As rodadas podem começar antes que o número necessário de clientes seja reunido, na expectativa de mais verificações em breve.
  • Permitir que os dispositivos escolham as tarefas de que querem participar. Essa abordagem pode ativar recursos como amostragem sem substituição, que é uma estratégia de amostragem em que cada unidade de amostra de uma população tem apenas uma chance de ser selecionada. Essa abordagem ajuda a mitigar contribuições desequilibradas e modelos tendenciosos
  • Extensível para técnicas de anonimização, como privacidade diferencial (DP) e agregação confiável (TAG, na sigla em inglês).

Para reduzir o armazenamento limitado do dispositivo e os recursos de computação, as técnicas abaixo podem ajudar:

  • Entender qual é a capacidade máxima disponível para executar a computação de aprendizado federado
  • Entender quantos dados podem ser mantidos em um determinado momento
  • Projete o código de aprendizado federado do lado do cliente para operar na computação e na RAM disponíveis nos clientes.
  • Entenda as implicações de ficar sem armazenamento e implemente o processo para gerenciar

Otimização de custos

Esta seção fornece orientações para otimizar o custo de criação e execução da plataforma de aprendizado federada no Google Cloud que você estabelece usando essa arquitetura de referência. Essa orientação se aplica às duas arquiteturas descritas neste documento.

A execução de cargas de trabalho no GKE pode ajudar a otimizar seu ambiente, provisionando e configurando os clusters de acordo com os requisitos de recursos das cargas de trabalho. Ele também ativa recursos que reconfiguram dinamicamente os clusters e os nós do cluster, como o escalonamento automático de nós e pods do cluster e o dimensionamento correto dos clusters.

Para mais informações sobre como otimizar o custo dos ambientes do GKE, consulte Práticas recomendadas para executar aplicativos econômicos do Kubernetes no GKE.

Eficiência operacional

Nesta seção, descrevemos os fatores que você precisa considerar para otimizar a eficiência ao usar essa arquitetura de referência para criar e executar uma plataforma de aprendizado federada no Google Cloud. Essa orientação se aplica às duas arquiteturas descritas neste documento.

Para aumentar a automação e o monitoramento da sua arquitetura de aprendizado federado, recomendamos que você adote os princípios de MLOps, que são princípios DevOps no contexto de sistemas de machine learning. A prática de MLOps significa que você defende a automação e o monitoramento de todas as etapas da construção de sistemas de ML, inclusive integração, teste, lançamento, implantação e gerenciamento de infraestrutura. Para mais informações sobre MLOps, consulte MLOps: entrega contínua e pipelines de automação em machine learning.

Otimização de desempenho

Nesta seção, descrevemos os fatores que você precisa considerar para otimizar o desempenho das cargas de trabalho ao usar essa arquitetura de referência para criar e executar uma plataforma de aprendizado federada no Google Cloud. Essa orientação se aplica às duas arquiteturas descritas neste documento.

O GKE é compatível com vários recursos para dimensionar e escalonar automaticamente e manualmente seu ambiente do GKE para atender às demandas das cargas de trabalho e evitar o provisionamento excessivo de recursos. Por exemplo, é possível usar o Recomendador para gerar insights e recomendações e otimizar o uso de recursos do GKE.

Ao pensar em como escalonar seu ambiente do GKE, recomendamos que você crie planos de curto, médio e longo prazo para o escalonamento dos ambientes e das cargas de trabalho. Por exemplo, como você pretende aumentar sua presença no GKE em algumas semanas, meses e anos? Ter um plano pronto ajuda você a aproveitar ao máximo os recursos de escalonabilidade oferecidos pelo GKE, otimizar seus ambientes do GKE e reduzir custos. Para mais informações sobre o planejamento da escalonabilidade do cluster e da carga de trabalho, consulte Sobre a escalonabilidade do GKE.

Para melhorar o desempenho de suas cargas de trabalho de ML, adote as unidades de processamento de tensor do Cloud (Cloud TPUs), que são aceleradores de IA projetados pelo Google e otimizados para treinamento e inferência de modelos de IA grandes.

Implantação

Para implantar as arquiteturas de referência entre silos e dispositivos descritas neste documento, consulte o repositório do GitHub Aprendizado federado no Google Cloud.

A seguir

Colaboradores

Autores:

Outros colaboradores: