Estrutura de arquitetura do Google Cloud

Last reviewed 2023-11-09 UTC

É possível imprimir esta página ou salvá-la no formato PDF usando a função de impressão do seu navegador e escolhendo a opção Salvar como PDF. Para a versão padrão desta página, retorne ao Framework de arquitetura.

O framework de arquitetura do Google Cloud fornece recomendações e descreve as práticas recomendadas para ajudar arquitetos, desenvolvedores, administradores e outros profissionais de nuvem a projetar e operar uma topologia de nuvem segura, eficiente, resiliente, de alto desempenho e econômica. O Google Cloud Architecture Framework é nossa versão de um framework bem arquitetado.

Uma equipe multifuncional de especialistas do Google valida as recomendações de design e as práticas recomendadas que compõem o framework de arquitetura. A equipe seleciona o framework de arquitetura para refletir os recursos de expansão do Google Cloud, as práticas recomendadas do setor, o conhecimento da comunidade e o feedback que você envia. Para ver um resumo das mudanças significativas, consulte O que há de novo.

As orientações de design no framework de arquitetura se aplicam a aplicativos criados para a nuvem e para cargas de trabalho migradas do local para o Google Cloud, de implantações de nuvem híbrida e de várias nuvens.

O framework de arquitetura do Google Cloud é organizado em seis categorias, também conhecidas como pilares, conforme mostrado no diagrama a seguir:

Design do sistema

Essa categoria é a base do framework de arquitetura do Google Cloud. Defina a arquitetura, os componentes, os módulos, as interfaces e os dados necessários para atender aos requisitos do sistema de nuvem. Saiba mais sobre os produtos e recursos do Google Cloud compatíveis com o design de sistemas.

Excelência operacional

Implemente, opere, monitore e gerencie com eficiência suas cargas de trabalho na nuvem.

Segurança, privacidade e conformidade

Maximizar a segurança dos dados e cargas de trabalho na nuvem, projetar para privacidade e alinhar com os padrões e requisitos regulamentares.

Confiabilidade

Projete e opere cargas de trabalho resilientes e altamente disponíveis na nuvem.

Otimização de custos

Maximizar o valor comercial do seu investimento no Google Cloud.

Otimização de desempenho

Projete e ajuste os recursos da nuvem para um desempenho ideal.

Para ver resumos de produtos do Google Cloud e como eles se relacionam, consulte Produtos, recursos e serviços do Google Cloud em quatro palavras ou menos.

Estrutura de arquitetura do Google Cloud: design do sistema

O design do sistema é a categoria básica do Framework de arquitetura do Google Cloud. Esta categoria fornece recomendações de design e descreve as práticas recomendadas e os princípios para ajudar você a definir a arquitetura, os componentes, os módulos, as interfaces e os dados em uma plataforma de nuvem para atender aos requisitos do seu sistema. Você também vai aprender sobre os produtos e recursos do Google Cloud compatíveis com o design do sistema.

Nos documentos da categoria de design do sistema, presumimos que você entende os princípios básicos de design do sistema. Nesses documentos, não presumimos que você esteja familiarizado com os conceitos de nuvem e com os produtos do Google Cloud.

Para cenários complexos de migração e implantação na nuvem, recomendamos o uso dos serviços de consultoria do Google Cloud. Nossos consultores oferecem experiência em práticas recomendadas e princípios orientadores para ajudar você a ter sucesso na sua jornada para a nuvem. O Google Cloud também tem um sólido ecossistema de parceiros, desde grandes integradores de sistemas globais até parceiros com ampla especialização em áreas específicas, como machine learning. Recomendamos que você interaja com os parceiros do Google Cloud para acelerar sua transformação digital e melhorar os resultados dos negócios.

Observação: antes de alterar seu ambiente de produção, recomendamos que você teste novos recursos ou designs em um ambiente de sandbox.

Na categoria de design do sistema do Framework de arquitetura, você aprenderá a fazer o seguinte:

• Aplicar os princípios básicos de design do sistema.
• Selecione as regiões geográficas para oferecer suporte aos seus aplicativos comerciais.
• Gerenciar recursos da nuvem.
• Escolha e gerencie computação.
• Projetar sua infraestrutura de rede.
• Selecionar e implementar uma estratégia de armazenamento.
• Otimize seu banco de dados.
• Analisar seus dados.
• Implementar o aprendizado de máquina.
• Projete a sustentabilidade das suas cargas de trabalho na nuvem

Princípios básicos de design do sistema

Este documento no Framework de arquitetura do Google Cloud descreve os princípios básicos de design do sistema. Um design de sistema robusto é seguro, confiável, escalonável e independente. Ele permite fazer alterações iterativas e reversíveis sem interromper o sistema, minimizar riscos potenciais e melhorar a eficiência operacional. Para alcançar um design de sistema robusto, recomendamos que você siga quatro princípios principais.

Documente tudo

Quando você começa a mover suas cargas de trabalho para a nuvem ou cria seus aplicativos, um grande obstáculo para o sucesso é a falta de documentação do sistema. A documentação é especialmente importante para visualizar corretamente a arquitetura das implantações atuais.

Uma arquitetura de nuvem bem documentada estabelece uma linguagem e padrões comuns, o que permite que equipes multifuncionais se comuniquem e colaborem de maneira eficaz. Ele também fornece as informações necessárias para identificar e guiar futuras decisões de design. A documentação precisa ser escrita de acordo com os casos de uso para fornecer contexto às decisões de design.

Com o tempo, suas decisões de design vão evoluir e mudar. O histórico de alterações fornece o contexto que suas equipes precisam para alinhar iniciativas, evitar a duplicação e avaliar as mudanças de desempenho com eficiência ao longo do tempo. Os registros de alterações são especialmente importantes quando você integra um novo arquiteto de nuvem que ainda não está familiarizado com o design, a estratégia ou o histórico atual do sistema.

Simplifique o design e use serviços totalmente gerenciados

A simplicidade é essencial para o design do sistema. Se sua arquitetura for muito complexa para entender, será difícil implementar o design e gerenciá-lo ao longo do tempo. Quando possível, use serviços totalmente gerenciados para minimizar os riscos, tempo e esforço associados ao gerenciamento e à manutenção de sistemas de referência.

Se você já estiver executando as cargas de trabalho em produção, teste com serviços gerenciados para ver como eles podem ajudar a reduzir as complexidades operacionais. Se você estiver desenvolvendo novas cargas de trabalho, comece de maneira simples, estabeleça um produto mínimo viável (MVP, na sigla em inglês) e resista ao impulso de trabalhar demais com engenharia. É possível identificar casos de uso excepcionais, iterar e melhorar seus sistemas gradualmente ao longo do tempo.

Dissocie a arquitetura

A dissociação é uma técnica usada para separar os aplicativos e componentes de serviço em componentes menores que podem operar de forma independente. Por exemplo, é possível dividir uma pilha de aplicativos monolítica em componentes de serviço separados. Em uma arquitetura desacoplada, um aplicativo pode executar funções de forma independente, independentemente das várias dependências.

Uma arquitetura desacoplada aumenta a flexibilidade para:

• Aplicar upgrades independentes.
• Aplicar controles de segurança específicos.
• Estabelecer metas de confiabilidade para cada subsistema.
• Monitorar a saúde.
• Controlar os parâmetros de desempenho e custo de forma granular.

Você pode começar o desacoplamento antecipado na fase de design ou incorporá-lo como parte dos upgrades do sistema à medida que escalonar.

Usar uma arquitetura sem estado

Uma arquitetura sem estado pode aumentar a confiabilidade e a escalonabilidade dos aplicativos.

Aplicativos com estado dependem de várias dependências para executar tarefas, como dados armazenados em cache local. Os aplicativos com estado geralmente precisam de mecanismos adicionais para capturar o progresso e reiniciar sem problemas. Aplicativos sem estado podem executar tarefas sem dependências locais significativas usando armazenamento compartilhado ou serviços em cache. Uma arquitetura sem estado permite que seus aplicativos sejam escalonados rapidamente com dependências mínimas de inicialização. Os aplicativos são resistentes a reinicializações rígidas, têm menor inatividade e fornecem melhor desempenho para os usuários finais.

A categoria de design do sistema descreve as recomendações para tornar os aplicativos sem estado ou usar recursos nativos da nuvem para melhorar a captura do estado da máquina para aplicativos com estado.

A seguir

• Selecione as regiões geográficas para oferecer suporte aos seus aplicativos comerciais.
• Gerenciar recursos da nuvem.
• Escolha e gerencie computação.
• Projetar sua infraestrutura de rede.
• Selecionar e implementar uma estratégia de armazenamento.
• Otimize seu banco de dados.
• Analisar seus dados.
• Implementar o aprendizado de máquina.
• Projete a sustentabilidade das suas cargas de trabalho na nuvem

Escolher os arquétipos de implantação do Google Cloud

Neste documento do Framework de arquitetura do Google Cloud, descrevemos seis arquétipos de implantação¹: zonal, regional, multirregional, global, híbrido e multicloud, que podem ser escolhidos para criar arquiteturas para as cargas de trabalho na nuvem com base nos seus requisitos de disponibilidade, custo, desempenho e eficiência operacional.

O que é um arquétipo de implantação?

Um arquétipo de implantação é um modelo abstrato e independente do provedor que você usa como base para criar arquiteturas de implantação específicas do aplicativo que atendam aos seus requisitos técnicos e comerciais. Cada arquétipo de implantação especifica uma combinação de domínios de falha em que um aplicativo pode ser executado. Esses domínios de falha podem ser uma ou mais zonas ou regiões do Google Cloud e podem se estender para incluir seus data centers locais ou domínios de falha em outros provedores de nuvem.

O diagrama a seguir mostra seis aplicativos implantados no Google Cloud. Cada aplicativo usa um arquétipo de implantação que atende aos requisitos específicos.

Como mostra o diagrama anterior, em uma arquitetura que usa o arquétipo de implantação híbrida ou de várias nuvens, a topologia da nuvem é baseada em um dos arquétipos básicos: zonal, regional, multirregional ou global. Nesse sentido, os arquétipos de implantação híbrida e de várias nuvens podem ser considerados como arquétipos de implantação compostos que incluem um dos arquétipos básicos.

Observação: os arquétipos de implantação são diferentes dos escopos de local. O escopo do local de um recurso do Google Cloud define o limite de disponibilidade. Por exemplo, o escopo do local de uma VM do Compute Engine é zonal. Isso significa que, se a zona do Google Cloud em que uma VM é provisionada tiver uma interrupção, a disponibilidade da VM será afetada. No entanto, ao distribuir VMs em várias zonas, é possível criar uma arquitetura altamente disponível baseada no arquétipo de implantação regional.

A escolha de um arquétipo de implantação ajuda a simplificar as decisões subsequentes sobre os produtos e recursos do Google Cloud que você precisa usar. Por exemplo, para um aplicativo conteinerizado altamente disponível, se você escolher o arquétipo de implantação regional, os clusters regionais do Google Kubernetes Engine (GKE) serão mais apropriados do que os clusters zonais do GKE.

Ao escolher um arquétipo de implantação para um aplicativo, é preciso considerar as compensações entre fatores como disponibilidade, custo e complexidade operacional. Por exemplo, se um aplicativo atende a usuários em vários países e precisa de alta disponibilidade, você pode escolher o arquétipo de implantação multirregional. No entanto, para um aplicativo interno usado por funcionários em uma única região geográfica, é possível priorizar o custo em vez da disponibilidade e, portanto, escolher o arquétipo de implantação regional.

Visão geral dos arquétipos de implantação

As guias a seguir fornecem definições para os arquétipos de implantação e um resumo dos casos de uso e considerações de design para cada um.

Zonal

O aplicativo é executado em uma única zona do Google Cloud, conforme mostrado no diagrama a seguir:

Casos de uso	Ambientes de desenvolvimento e teste. Aplicativos que não precisam de alta disponibilidade. Rede de baixa latência entre componentes de aplicativos. Migração de cargas de trabalho comuns. Aplicativos que usam software com restrição de licença.
Considerações sobre o design	Inatividade durante interrupções na zona. Para garantir a continuidade dos negócios, é possível provisionar uma réplica passiva do aplicativo em outra zona na mesma região. Se ocorrer uma interrupção na zona, será possível restaurar o aplicativo para produção usando a réplica passiva.
Mais informações	Consulte as seções a seguir para saber como fazer isso: Arquétipo de implantação por zona Análise comparativa de todos os arquétipos de implantação

Regional

O aplicativo é executado de maneira independente em duas ou mais zonas em uma única região do Google Cloud, conforme mostrado no diagrama a seguir:

Casos de uso	Aplicativos altamente disponíveis que atendem a usuários em uma área geográfica. Cumprir os requisitos de soberania de residência e dados
Considerações sobre o design	Inatividade durante interrupções na região. Para garantir a continuidade dos negócios, faça backup do aplicativo e dos dados em outra região. Se ocorrer uma falha temporária na região, use os backups na outra região para restaurar o aplicativo para produção. Custo e esforço para provisionar e gerenciar recursos redundantes.
Mais informações	Consulte as seções a seguir para saber como fazer isso: Arquétipo de implantação regional Análise comparativa de todos os arquétipos de implantação

Multirregional

Seu aplicativo é executado de maneira independente em várias zonas em duas ou mais regiões do Google Cloud. É possível usar políticas de roteamento de DNS para encaminhar o tráfego de entrada para os balanceadores de carga regionais. Em seguida, os balanceadores de carga regionais distribuem o tráfego para as réplicas zonais do aplicativo, conforme mostrado no diagrama a seguir:

Casos de uso	Aplicativo altamente disponível com usuários dispersos geograficamente. Aplicativos que exigem baixa latência do usuário final. Conformidade com os requisitos de soberania e residência de dados usando uma política de roteamento de DNS com fronteira geográfica virtual.
Considerações sobre o design	Custo para transferência de dados e replicação de dados entre regiões. Complexidade operacional.
Mais informações	Consulte as seções a seguir para saber como fazer isso: Arquétipo de implantação multirregional Análise comparativa de todos os arquétipos de implantação

Global

O aplicativo é executado nas regiões do Google Cloud em todo o mundo, como uma pilha distribuída globalmente (sem reconhecimento de local) ou como pilhas isoladas por região. Um balanceador de carga anycast global distribui o tráfego para a região mais próxima do usuário. Outros componentes da pilha de aplicativos também podem ser globais, como o banco de dados, o cache e o armazenamento de objetos.

O diagrama a seguir mostra a variante distribuída globalmente do arquétipo de implantação global. Um balanceador de carga Anycast global encaminha solicitações para uma pilha de aplicativos distribuída em várias regiões e que usa um banco de dados replicado globalmente.

O diagrama a seguir mostra uma variante do arquétipo de implantação global com pilhas de aplicativos isoladas por região. Um balanceador de carga Anycast global encaminha solicitações para uma pilha de aplicativo em uma das regiões. Todas as pilhas de aplicativos usam um único banco de dados replicado globalmente.

Casos de uso	Aplicativos altamente disponíveis que atendem a usuários em todo o mundo. Oportunidade de otimizar custos e simplificar operações usando recursos globais em vez de várias instâncias de recursos regionais.
Considerações sobre o design	Custos de transferência de dados e replicação de dados entre regiões.
Mais informações	Consulte as seções a seguir para saber como fazer isso: Arquétipo de implantação global Análise comparativa de todos os arquétipos de implantação

Híbrido

Algumas partes do aplicativo são implantadas no Google Cloud, enquanto outras são executadas no local, como mostrado no diagrama a seguir. A topologia no Google Cloud pode usar o arquétipo de implantação zonal, regional, multirregional ou global.

Casos de uso	Local de recuperação de desastres (DR) para cargas de trabalho locais. Desenvolvimento no local para aplicativos na nuvem. Migração progressiva para a nuvem de aplicativos legados. Aprimorar aplicativos locais com recursos de nuvem.
Considerações sobre o design	Esforço de configuração e complexidade operacional. Custo de recursos redundantes.
Mais informações	Consulte as seções a seguir para saber como fazer isso: Arquétipo de implantação híbrida Análise comparativa de todos os arquétipos de implantação

Várias nuvens

Algumas partes do aplicativo são implantadas no Google Cloud e outras em outras plataformas de nuvem, conforme mostrado no diagrama a seguir. A topologia de cada plataforma de nuvem pode usar o arquétipo de implantação zonal, regional, multirregional ou global.

Casos de uso	Google Cloud como local principal e outra nuvem como site de DR. Aprimorar aplicativos com recursos avançados do Google Cloud.
Considerações sobre o design	Esforço de configuração e complexidade operacional. Custo de recursos redundantes e tráfego de rede entre nuvens.
Mais informações	Consulte as seções a seguir para saber como fazer isso: Arquétipo de implantação em várias nuvens Análise comparativa de todos os arquétipos de implantação

Selecionar zonas e regiões geográficas

Neste documento, mostramos o Framework da arquitetura do Google Cloud sobre as práticas recomendadas para implantar seu sistema com base nos requisitos geográficos. Você aprenderá a selecionar zonas e regiões geográficas de acordo com a disponibilidade e a proximidade, para oferecer compatibilidade, otimizar custos e implementar o balanceamento de carga.

Ao selecionar uma ou várias regiões para seus aplicativos comerciais, considere critérios como disponibilidade de serviço, latência do usuário final, latência do aplicativo, custo e requisitos regulamentares ou de sustentabilidade. Para oferecer suporte às políticas e prioridades de negócios, equilibre esses requisitos e identifique as melhores vantagens. Por exemplo, a região mais compatível pode não ser a mais econômica ou não ter a menor pegada de carbono.

Implantar em várias regiões

Regiões são áreas geográficas independentes que consistem em várias zonas. Uma zona é uma área de implantação de recursos do Google Cloud em uma região. Cada zona representa um domínio de falha único dentro de uma região.

Para ajudar a proteger contra inatividade esperada (incluindo manutenção) e ajudar a proteger contra inatividade inesperada, como incidentes, recomendamos que você implante aplicativos tolerantes a falhas que tenham alta disponibilidade e implante seus aplicativos em várias zonas em uma ou mais regiões. Para mais informações, consulte Geografia e regiões, Considerações sobre implantação de aplicativo e Práticas recomendadas para seleção de regiões do Compute Engine.

As implantações multizonais podem fornecer resiliência se as implantações multirregionais forem limitadas devido a custos ou outras considerações. Essa abordagem é especialmente útil para evitar interrupções zonais ou regionais e lidar com questões de recuperação de desastres e continuidade de negócios. Para mais informações, consulte Design para escala e alta disponibilidade.

Selecionar regiões com base na proximidade geográfica

A latência afeta a experiência do usuário e os custos associados à disponibilização de usuários externos. Para minimizar a latência ao veicular tráfego para usuários externos, selecione uma região ou um conjunto de regiões geograficamente próximas aos usuários e em que os serviços são executados de maneira compatível. Para mais informações, consulte Locais do Cloud e Central de recursos de compliance.

Selecionar regiões com base nos serviços disponíveis

Escolha uma região pensando nos serviços que precisam estar disponíveis para sua empresa. A maioria dos serviços está disponível em todas as regiões. Alguns serviços específicos da empresa podem estar disponíveis em um subconjunto de regiões com a versão inicial. Para verificar a seleção de região, consulte Locais do Cloud.

Escolher regiões para fins de compliance

Selecione uma região específica ou um conjunto de regiões para atender aos regulamentos regulatórios ou de conformidade geográficas que exigem o uso de determinadas regiões geográficas. Por exemplo, Regulamento geral de proteção de dados (GDPR) ou residência de dados. Para saber mais sobre como projetar sistemas seguros, consulte Ofertas de conformidade e Residência de dados, transparência operacional e privacidade para clientes europeus no Google Cloud.

Comparar preços dos principais recursos

As regiões têm taxas de custo diferentes para os mesmos serviços. Para identificar uma região econômica, compare o preço dos principais recursos que você planeja usar. As considerações sobre custos variam de acordo com recursos e requisitos de backup, como computação, rede e armazenamento de dados. Para saber mais, consulte a categoria de otimização de custos.

Usar o Cloud Load Balancing para veicular usuários globais

Para melhorar a experiência do usuário global, use o Cloud Load Balancing para fornecer um único endereço IP que seja roteado para o aplicativo. Para saber mais sobre como projetar sistemas confiáveis, consulte o Framework da arquitetura do Google Cloud: confiabilidade.

Usar o seletor de região do Cloud para apoiar a sustentabilidade

O Google é neutro em carbono desde 2007 e tem o compromisso de ser livre de carbono em 2030. Para selecionar uma região pela pegada de carbono, use o Seletor de região do Google Cloud. Para saber mais sobre como projetar para sustentabilidade, consulte Sustentabilidade na nuvem.

A seguir

Saiba como gerenciar seus recursos de nuvem usando o Resource Manager, a hierarquia de recursos do Google Cloud, e o Serviço de política da organização.

Explore outras categorias no Framework de arquitetura, como confiabilidade, excelência operacional e segurança, privacidade e conformidade.

Gerenciar recursos em nuvem

Neste documento do framework de arquitetura do Google Cloud, você verá as práticas recomendadas para organizar e gerenciar seus recursos no Google Cloud.

Hierarquia de recursos

Os recursos do Google Cloud são organizados hierarquicamente em organizações, pastas e projetos. Essa hierarquia permite gerenciar aspectos comuns dos recursos, como controle de acesso, definições de configuração e políticas. Veja as práticas recomendadas para projetar a hierarquia dos recursos de nuvem em Decidir uma hierarquia de recursos para sua zona de destino do Google Cloud.

Etiquetas e rótulos de recursos

Nesta seção, você verá as práticas recomendadas para usar rótulos e tags e organizar seus recursos do Google Cloud.

Usar uma estrutura de pastas simples

Com as pastas, você pode agrupar qualquer combinação de projetos e subpastas. Crie uma estrutura de pastas simples para organizar seus recursos do Google Cloud. É possível adicionar mais níveis conforme necessário para definir sua hierarquia de recursos para que ela atenda às necessidades da sua empresa. A estrutura de pastas é flexível e extensível.Para saber mais, consulte Como criar e gerenciar pastas.

Usar pastas e projetos para refletir as políticas de governança de dados

Use pastas, subpastas e projetos para separar os recursos de acordo com as políticas de governança de dados na sua organização. Por exemplo, use uma combinação de pastas e projetos para separar recursos financeiros, humanos e engenharia.

Use projetos para agrupar recursos que compartilham o mesmo limite de confiança. Por exemplo, recursos para o mesmo produto ou microsserviço podem pertencer ao mesmo projeto. Para mais informações, consulte Decidir uma hierarquia de recursos para sua zona de destino do Google Cloud.

Use tags e rótulos no início do projeto

Use rótulos e tags quando começar a usar os produtos do Google Cloud, mesmo que não precise deles imediatamente. A adição de rótulos e tags posteriormente pode exigir esforços manuais que podem ser propensos a erros e difíceis de concluir.

As tags fornecem uma maneira de permitir ou negar políticas condicionalmente se um recurso tiver uma tag específica. Um rótulo é um par de chave-valor que ajuda a organizar suas instâncias do Google Cloud. Para mais informações sobre rótulos, consulte requisitos para rótulos, uma lista de serviços compatíveis com rótulos e formatos de rótulo de dados.

O Resource Manager fornece rótulos e tags para ajudar a gerenciar recursos, alocar e gerar relatórios sobre custos e atribuir políticas a diferentes recursos para controles de acesso granulares. Por exemplo, é possível usar rótulos e tags para aplicar princípios de gerenciamento e acesso granular a diferentes recursos e serviços de locatário. Para informações sobre rótulos de VM e tags de rede, consulte Relação entre rótulos de VM e tags de rede.

É possível usar rótulos para várias finalidades, incluindo as seguintes:

• Gerenciamento do faturamento de recursos: os rótulos estão disponíveis no sistema de faturamento, o que permite separar o custo por rótulos. Por exemplo, é possível rotular diferentes centros de custo ou orçamentos.
• Agrupar recursos por características semelhantes ou por relação: use rótulos para separar estágios ou ciclos de vida de aplicativos diferentes. Por exemplo, você pode rotular ambientes de produção, desenvolvimento e teste.

Atribua rótulos para dar suporte aos relatórios de custo e faturamento

Para aceitar relatórios granulares de custo e faturamento com base em atributos fora das estruturas de relatórios integradas, como por projeto ou por tipo de produto, atribua rótulos aos recursos. Os rótulos ajudam a alocar o consumo para centros de custos, departamentos, projetos específicos ou mecanismos de recarga internos. Para mais informações, consulte a categoria de otimização de custos.

Evite criar um grande número de rótulos

Evite criar um grande número de rótulos. Recomendamos que você crie rótulos principalmente no nível do projeto e evite criar rótulos no nível da subequipe. Se você criar rótulos muito granulares, eles poderão adicionar ruído às suas análises. Para saber mais sobre casos de uso comuns de rótulos, consulte Usos comuns de rótulos.

Evite adicionar informações confidenciais a rótulos

Os rótulos não foram criados para processar informações confidenciais. Não inclua informações confidenciais em rótulos, incluindo informações que possam ser de identificação pessoal, como o nome ou a profissão de uma pessoa.

Deixe as informações nos nomes dos projetos anônimas

Siga um padrão de nomenclatura do projeto, como COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME, em que os marcadores são exclusivos e não revelam nomes de empresas ou aplicativos. Não inclua atributos que possam ser alterados no futuro, por exemplo, um nome ou uma tecnologia.

Aplicar tags às dimensões de negócios do modelo

É possível aplicar tags para modelar outras dimensões de negócios, como estrutura organizacional, regiões, tipos de carga de trabalho ou centros de custo. Para saber mais sobre tags, consulte Visão geral de tags, Herança de tags e Como criar e gerenciar tags. Para saber como usar tags com políticas, consulte Políticas e tags. Veja como usar tags para gerenciar o controle de acesso em Tags e controle de acesso.

Políticas organizacionais

Esta seção apresenta as práticas recomendadas para configurar regras de governança nos recursos do Google Cloud na hierarquia de recursos da nuvem.

Estabelecer convenções de nomenclatura de projetos

Estabeleça uma convenção de nomenclatura padronizada para o projeto, por exemplo, SYSTEM_NAME-ENVIRONMENT (dev, test, uat, stage, prod).

Os nomes dos projetos têm um limite de 30 caracteres.

Embora seja possível aplicar um prefixo como COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG, os nomes dos projetos podem ficar desatualizados quando as empresas estiverem passando por reorganizações. Pense em mover nomes identificáveis de nomes de projetos para rótulos de projeto.

Automatizar a criação de projetos

Para criar projetos para empresas de produção e em grande escala, use um processo automatizado como o Deployment Manager; ou Módulo do Terraform para a fábrica do projeto do Google Cloud de dados. Essas ferramentas fazem o seguinte:

• Crie automaticamente ambientes de desenvolvimento, testes e produção que tenham as permissões apropriadas.
• Configure a geração de registros e o monitoramento.

O módulo Terraform do fábrica do projeto do Google Cloud ajuda a automatizar a criação de projetos do Google Cloud. Em grandes empresas, recomendamos que você analise e aprove os projetos antes de criá-los no Google Cloud. Esse processo ajuda a garantir o seguinte:

• Os custos podem ser atribuídos. Para mais informações, consulte a categoria de otimização de custos.
• As aprovações estão em vigor para o upload de dados.
• Requisitos regulamentares ou de conformidade são atendidos.

Ao automatizar a criação e o gerenciamento de projetos e recursos do Google Cloud, você recebe o benefício da consistência, reprodutibilidade e testabilidade. Se você tratar sua configuração como código, poderá modificar e gerenciar o ciclo de vida dela junto com seus artefatos de software. A automação permite a aplicação de práticas recomendadas, como convenções de nomenclatura consistentes e rotulagem de recursos. Com a evolução dos requisitos, a automação simplifica a refatoração de projetos.

Faça auditorias dos seus sistemas regularmente

Para garantir que as solicitações de novos projetos possam ser auditadas e aprovadas, integre o sistema de tíquetes da sua empresa ou a um sistema independente que ofereça auditoria.

Configurar projetos de maneira consistente

Configure projetos para atender às necessidades da sua organização de forma consistente. Inclua o seguinte ao configurar projetos:

• Convenções de nomenclatura e ID de projetos
• Vinculação de conta de faturamento
• Configurações de rede
• APIs e serviços ativados
• Configuração de acesso do Compute Engine
• Relatórios de uso e exportação de registros
• Garantia de remoção de projeto

Separe e isole cargas de trabalho ou ambientes

As cotas e limites são aplicados no nível do projeto. Para gerenciar cotas e limites, separe e isole cargas de trabalho ou ambientes no nível do projeto. Para mais informações, consulte Como trabalhar com cotas.

A dissociação de ambientes é diferente dos requisitos de classificação de dados. A separação de dados da infraestrutura pode ser cara e complexa. Portanto, recomendamos que você implemente a classificação de dados com base na confidencialidade dos dados e nos requisitos de conformidade.

Aplicar o isolamento do faturamento

Aplique o isolamento de faturamento para oferecer compatibilidade com diferentes contas de faturamento e visibilidade de custos por carga de trabalho e ambiente. Para mais informações, consulte Criar, modificar ou encerrar sua conta de autoatendimento do Cloud Billing e Ativar, desativar ou alterar o faturamento de um projeto.

Para minimizar a complexidade administrativa, use controles de gerenciamento de acesso granulares para ambientes críticos no nível do projeto ou para cargas de trabalho espalhadas por vários projetos. Ao selecionar o controle de acesso para aplicativos de produção críticos, você garante que as cargas de trabalho sejam protegidas e gerenciadas de maneira eficiente.

Usar o serviço de políticas da organização para controlar recursos

O serviço de políticas da organização fornece aos administradores de políticas um controle centralizado e programático sobre os recursos de nuvem da organização para que possam configurar restrições na hierarquia de recursos. Para mais informações, consulte Adicionar um administrador de política da organização.

Usar o serviço de políticas da organização para obedecer às políticas regulamentares

Para atender aos requisitos de conformidade, use o serviço de política da organização para impor requisitos de conformidade para acesso e compartilhamento de recursos. Por exemplo, é possível limitar o compartilhamento com partes externas ou determinar onde implantar recursos de nuvem geograficamente. Outros cenários de conformidade são os seguintes:

• Centralizar o controle para configurar restrições que definem como os recursos da organização podem ser usados.
• Definir e estabelecer políticas para ajudar as equipes de desenvolvimento a permanecer dentro dos limites de conformidade.
• Ajudar os proprietários de projetos e as equipes a fazer mudanças no sistema, mantendo a conformidade regulatória e minimizando as preocupações sobre o descumprimento de regras de conformidade.

Limite o compartilhamento de recursos com base no domínio

Uma política da organização de compartilhamento restrito ajuda a impedir que os recursos do Google Cloud sejam compartilhados com identidades fora da organização. Para mais informações, consulte Como restringir identidades por domínio e Restrições da política da organização.

Desativar conta de serviço e criação de chave

Para ajudar a melhorar a segurança, limite o uso de contas de serviço de gerenciamento de identidade e acesso (IAM, na sigla em inglês) e das chaves correspondentes. Para mais informações, consulte Como restringir o uso da conta de serviço.

Restringir o local físico de novos recursos

Restrinja o local físico de recursos recém-criados restringindo locais de recursos. Para ver uma lista de restrições que dão a você o controle dos recursos da sua organização, consulte Restrições do serviço de políticas da organização.

A seguir

Saiba como escolher e gerenciar a computação, incluindo as seguintes:

• Abordagem de migração do Compute.

• Criar cargas de trabalho e escalonar as cargas de trabalho

• Gerencie operações.

• Gerencie migrações de VMs.

Explore outras categorias no Framework de arquitetura, como confiabilidade, excelência operacional e segurança, privacidade e conformidade.

Escolher e gerenciar computação

Neste documento, mostramos o Framework da arquitetura do Google Cloud sobre as práticas recomendadas para implantar seu sistema com base nos requisitos de computação. Você aprenderá a escolher uma plataforma de computação e abordagem de migração, projetar e escalonar cargas de trabalho e gerenciar operações e migrações de VM.

A computação está no centro de muitas cargas de trabalho, seja ela relacionada à execução de uma lógica de negócios personalizada ou à aplicação de algoritmos computacionais complexos em conjuntos de dados. A maioria das soluções usa recursos de computação de alguma forma, e é fundamental que você selecione os recursos de computação corretos para as necessidades do aplicativo.

O Google Cloud oferece várias opções para usar o tempo em uma CPU. As opções são baseadas em tipos de CPU, desempenho e como o código é programado para execução, incluindo o faturamento de uso.

As opções de computação do Google Cloud incluem:

• Máquinas virtuais (VM) com benefícios específicos da nuvem, como a migração em tempo real.
• Empacotamento de contêineres em máquinas de cluster que podem compartilhar CPUs.
• Funções e abordagens sem servidor, em que o uso do tempo de CPU pode ser limitado ao trabalho realizado durante uma única solicitação HTTP.

Como escolher a computação

Nesta seção, você verá as práticas recomendadas para escolher e migrar para uma plataforma de computação.

Escolha uma plataforma de computação

Ao escolher uma plataforma de computação para sua carga de trabalho, considere os requisitos técnicos da carga de trabalho, os processos de automação do ciclo de vida, a regionalização e a segurança.

Avalie a natureza do uso da CPU pelo aplicativo e por todo o sistema de suporte, incluindo como o código é empacotado e implantado, distribuído e invocado. Embora alguns cenários possam ser compatíveis com várias opções de plataforma, uma carga de trabalho portátil precisa ser capaz e ter bom desempenho em uma variedade de opções de computação.

A tabela a seguir fornece uma visão geral dos serviços de computação recomendados do Google Cloud para vários casos de uso:

Plataforma de computação	Casos de uso	Produtos recomendados
Sem servidor	Implantar seu primeiro aplicativo. Concentre-se na lógica de processamento e dados e no desenvolvimento de apps, em vez de manter operações da infraestrutura.	Cloud Run: coloque sua lógica de negócios em contêineres usando esta opção totalmente sem servidor totalmente gerenciada. O Cloud Run foi projetado para cargas de trabalho que exigem muita computação, mas nem sempre estão ativadas. Faça o escalonamento eficaz de 0 (sem tráfego) e defina a CPU e a RAM de suas tarefas e serviços. Implante com um único comando e o Google provisiona automaticamente a quantidade certa de recursos. Cloud Functions: separe seu código em partes flexíveis da lógica de negócios sem as preocupações de infraestrutura de balanceamento de carga, atualizações, autenticação ou escalonamento.
Kubernetes	Criar arquiteturas complexas de microsserviços que precisam de serviços adicionais, como o Istio, para gerenciar o controle de malha de serviço.	Google Kubernetes Engine: um mecanismo de orquestração de contêineres de código aberto que automatiza a implantação, o escalonamento e o gerenciamento de aplicativos em contêineres.
Máquinas virtuais (VMs)	Crie e execute VMs de famílias de VMs predefinidas e personalizáveis compatíveis com seus requisitos de aplicativos e cargas de trabalho, bem como software e serviços de terceiros.	Compute Engine: adicione unidades de processamento gráfico (GPUs) às instâncias de VM. Use essas GPUs para acelerar cargas de trabalho específicas nas instâncias, como machine learning e processamento de dados. Para selecionar os tipos de máquina adequados com base nos seus requisitos, consulte Recomendações para famílias de máquinas.

Para mais informações, consulte Como escolher opções de computação.

Escolher uma abordagem de migração de computação

Se você estiver migrando seus aplicativos atuais de outra nuvem ou do local, use um dos seguintes produtos do Google Cloud para ajudar a otimizar o desempenho, o escalonamento, o custo e a segurança.

Meta de migração	Caso de uso	Produto recomendado
Migração lift-and-shift	Migre ou estenda suas cargas de trabalho da VMware para o Google Cloud em minutos.	Google Cloud VMware Engine
Migração lift-and-shift	Mova seus aplicativos baseados em VM para o Compute Engine.	Migrate to Virtual Machines
Upgrade para contêineres	Modernize aplicativos tradicionais em contêineres integrados no Google Kubernetes Engine.	Migrate to Containers

Para saber como migrar suas cargas de trabalho ao alinhar equipes internas, consulte Ciclo de vida da migração da VM e Como criar um programa de migração em grande escala com o Google Cloud.

Como projetar cargas de trabalho

Nesta seção, você verá as práticas recomendadas para projetar cargas de trabalho compatíveis com seu sistema.

Avalie opções sem servidor para uma lógica simples

Lógica simples é um tipo de computação que não exige tipos de máquina ou hardware especializados, como máquinas otimizadas para CPU. Antes de investir em Google Kubernetes Engine (GKE) ou Compute Engine implementações para abstrair a sobrecarga operacional e otimizar para custo e desempenho, avaliar opções sem servidor para lógica leve.

Separe os aplicativos para ficar sem estado

Quando possível, desassocie os aplicativos para serem sem estado a fim de maximizar o uso das opções de computação sem servidor. Essa abordagem permite usar ofertas de computação gerenciada, escalonar aplicativos com base na demanda e otimizar o custo e o desempenho. Para mais informações sobre como desacoplar seu aplicativo para projetar para escalonamento e alta disponibilidade, consulte Projetar para escalonamento e alta disponibilidade.

Usar a lógica de armazenamento em cache ao separar arquiteturas

Se o aplicativo for projetado para ser com estado, use a lógica de armazenamento em cache para separar e tornar a carga de trabalho escalonável. Para mais informações, consulte Práticas recomendadas do banco de dados.

Usar migrações em tempo real para facilitar upgrades

Para facilitar os upgrades de manutenção do Google, use a migração em tempo real ao definir políticas de disponibilidade de instância. Para mais informações, consulte Definir política de manutenção do host da VM.

Como escalonar cargas de trabalho

Nesta seção, você verá as práticas recomendadas para escalonar cargas de trabalho e torná-las compatíveis com seu sistema.

Usar scripts de inicialização e encerramento

Para aplicativos com estado, use scripts de inicialização e encerramento sempre que possível para iniciar e interromper o estado dos aplicativos normalmente. Uma inicialização normal é quando um computador é ligado por uma função de software, e o sistema operacional tem permissão para executar as tarefas de inicialização segura de processos e abertura de conexões.

As inicializações e as interrupções otimizadas são importantes porque os aplicativos com estado dependem da disponibilidade imediata dos dados que estão próximos à computação, geralmente em discos locais ou permanentes ou na RAM. Para evitar a execução dos dados do aplicativo desde o início em cada inicialização, use um script de inicialização para recarregar os últimos dados salvos e executar o processo de onde parou no momento do desligamento. Para salvar o estado da memória do aplicativo e evitar a perda de progresso no desligamento, use um script de desligamento. Por exemplo, use um script de desligamento quando uma VM estiver programada para ser encerrada devido a eventos de manutenção de escalonamento ou escalonamento do Google.

Use MIGs para oferecer suporte ao gerenciamento de VMs

Quando você usa VMs do Compute Engine, os grupos de instâncias gerenciadas (MIGs, na sigla em inglês) são compatíveis com recursos como recuperação automática, balanceamento de carga, atualização de escalonamento automático e cargas de trabalho com estado. É possível criar MIGs regionais ou zonais com base nas suas metas de disponibilidade. É possível usar MIGs para cargas de trabalho sem estado em exibição ou em lote e para aplicativos com estado que precisam preservar o estado exclusivo de cada VM.

Usar escalonadores automáticos de pods para escalonar suas cargas de trabalho do GKE

Usar horizontal e Escalonadores automáticos de pod verticais para escalonar suas cargas de trabalho e usar provisionamento automático de nós para dimensionar os recursos computacionais subjacentes.

Distribuir o tráfego do aplicativo

Para escalonar seus aplicativos globalmente, use o Cloud Load Balancing para distribuir suas instâncias de aplicativos em mais de uma região ou zona. Os balanceadores de carga otimizam o roteamento de pacotes das redes de borda do Google Cloud para a zona mais próxima, o que aumenta a eficiência do tráfego e minimiza os custos de exibição. Para otimizar a latência do usuário final, use o Cloud CDN para armazenar em cache o conteúdo estático sempre que possível.

Automatize a criação e o gerenciamento de computação

Minimize os erros causados por humanos no seu ambiente de produção automatizando a criação e o gerenciamento da computação.

Como gerenciar operações

Nesta seção, você verá as práticas recomendadas para gerenciar operações compatíveis com seu sistema.

Usar imagens públicas fornecidas pelo Google

Use imagens públicas fornecidas pelo Google Cloud. As imagens públicas do Google Cloud são atualizadas regularmente. Para mais informações, consulte Lista de imagens públicas disponíveis no Compute Engine.

Também é possível criar suas próprias imagens com ajustes e configurações específicas. Sempre que possível, automatize e centralize a criação de imagens em um projeto separado que possa ser compartilhado com usuários autorizados na sua organização. A criação e seleção de imagens personalizadas em um projeto separado permite atualizar, corrigir e criar uma VM usando suas próprias configurações. Depois, compartilhe a imagem selecionada da VM com projetos relevantes.

Usar snapshots para backups de instâncias

Os snapshots permitem criar backups para as instâncias. Os snapshots são especialmente úteis para aplicativos com estado, que não são flexíveis o suficiente para manter o estado ou salvar o progresso quando passam por interrupções abruptas. Se você costuma usar snapshots para criar novas instâncias, é possível otimizar o processo de backup criando uma imagem base a partir desse snapshot.

Usar uma imagem de máquina para ativar a criação de instâncias de VM

Embora um snapshot capture apenas uma imagem dos dados dentro de uma máquina, uma imagem de máquina captura configurações e configurações da máquina, além dos dados. Use uma imagem de máquina para armazenar todas as configurações, metadados, permissões e dados de um ou mais discos necessários para criar uma instância de VM.

Ao criar uma máquina a partir de um snapshot, é preciso definir as configurações nas novas instâncias de VM, o que exige muito trabalho. O uso de imagens de máquina permite copiar essas configurações conhecidas para novas máquinas, reduzindo a sobrecarga. Para mais informações, consulte Quando usar uma imagem de máquina (em inglês).

Capacidade, reservas e isolamento

Nesta seção, você verá as práticas recomendadas para gerenciar capacidade, reservas e isolamento para oferecer suporte ao sistema.

Usar descontos por uso contínuo para reduzir custos

É possível reduzir os custos de despesas operacionais (OPEX, na sigla em inglês) das cargas de trabalho que estão sempre ativadas usando os descontos por uso contínuo. Para mais informações, consulte a categoria de otimização de custos.

Escolha os tipos de máquina para oferecer suporte aos custos e desempenho

O Google Cloud oferece tipos de máquina que permitem escolher computação com base em parâmetros de custo e desempenho. Escolha uma oferta de baixo desempenho para otimizar os custos ou uma opção de computação de alto desempenho com um custo maior. Para mais informações, consulte a categoria de otimização de custos.

Usar nós de locatário individual para atender às necessidades de conformidade

Os nós de locatário individual são servidores físicos do Compute Engine, dedicados a hospedar apenas as VMs do seu projeto. Os nós de locatário individual podem ajudar a atender aos requisitos de conformidade para isolamento físico, incluindo:

• Mantenha as VMs fisicamente separadas das VMs em outros projetos.
• Agrupe as VMs no mesmo hardware do host.
• Isolar as cargas de trabalho de processamento de pagamentos.

Para mais informações, consulte Nós de locatário individual.

Usar reservas para garantir a disponibilidade de recursos

O Google Cloud permite definir reservas para suas cargas de trabalho para garantir que esses recursos estejam sempre disponíveis. Não há cobrança extra para criar reservas, mas você paga pelos recursos reservados, mesmo que não os use. Para mais informações, consulte Como consumir e gerenciar reservas.

VM Migration

Nesta seção, você verá as práticas recomendadas para migrar VMs para suporte ao sistema.

Avaliar ferramentas de migração integradas

Avalie ferramentas de migração integradas para mover suas cargas de trabalho de outra nuvem ou do local. Para mais informações, consulte Migração para o Google Cloud. O Google Cloud oferece ferramentas e serviços para ajudar a migrar cargas de trabalho e otimizar para custo e desempenho. Para receber uma avaliação gratuita dos custos de migração com base no seu cenário atual de TI, consulte o Programa de avaliação e migração rápidas do Google Cloud.

Usar a importação de disco virtual para sistemas operacionais personalizados

Para importar sistemas operacionais compatíveis personalizados, consulte Como importar discos virtuais. Os nós de locatário individual podem ajudar você a atender aos requisitos de "Traga sua própria licença" para licenças por núcleo ou por processador. Para mais informações, consulte Como usar suas próprias licenças.

Recomendações

Para aplicar a orientação no Framework de arquitetura a seu próprio ambiente, recomendamos que você faça o seguinte:

• Analise as ofertas do Google Cloud Marketplace para avaliar se seu aplicativo está listado em um fornecedor compatível. O Google Cloud é compatível com a execução de vários sistemas de código aberto e vários softwares de terceiros.

• Considere o Migrate to Containers and GKE para extrair e empacotar um aplicativo baseado em VM como um aplicativo conteinerizado em execução no GKE.

• Use o Compute Engine para executar aplicativos no Google Cloud. Se você tiver dependências legadas em execução em um aplicativo baseado em VM, verifique se elas atendem aos requisitos do fornecedor.

• Avalie o uso de um balanceador de carga de rede de passagem interna do Google Cloud para escalonar a arquitetura desacoplada. Para mais informações, consulte Visão geral do balanceador de carga de rede de passagem interna.

• Avalie suas opções para mudar de casos de uso locais tradicionais, como uso de proxy de alta disponibilidade. Para mais informações, consulte as práticas recomendadas para endereço IP flutuante.

• Use o VM Manager para gerenciar sistemas operacionais para seus grupos de VMs grandes que executam Windows ou Linux no Compute Engine, e aplique políticas de configuração consistentes.

• Considere usar o Autopilot do GKE e deixe o Google SRE gerenciar totalmente seus clusters.

• Use o Controlador de Políticas e o Config Sync para o gerenciamento de configuração e políticas nos clusters do GKE.

• Garanta a disponibilidade e a escalonabilidade das máquinas em regiões e zonas específicas. O Google Cloud pode ser escalonado de acordo com suas necessidades de computação. No entanto, se você precisar de muitos tipos de máquina específicos em uma região ou zona específica, trabalhe com as equipes de conta para garantir disponibilidade. Para mais informações, consulte Reservas do Compute Engine.

A seguir

Conheça os princípios de design de rede, incluindo:

• Projetar arquiteturas de carga de trabalho VPC.

• Projete a conectividade entre VPCs.

Explore outras categorias no Framework de arquitetura, como confiabilidade, excelência operacional e segurança, privacidade e conformidade.

Projetar sua infraestrutura de rede

Neste documento, mostramos o framework de arquitetura do Google Cloud sobre as práticas recomendadas para implantar seu sistema com base no design de rede. Saiba como escolher e implementar a nuvem privada virtual (VPC) e como testar e gerenciar a segurança da rede.

Princípios básicos

O design de rede é fundamental para o design bem-sucedido do sistema, porque ajuda a otimizar o desempenho e proteger as comunicações com aplicativos internos e externos. Quando você escolher os serviços de rede, é importante avaliar as necessidades do seu aplicativo e avaliar como os aplicativos se comunicarão entre si. Por exemplo, enquanto alguns componentes exigem serviços globais, outros podem precisar estar localizados geograficamente em uma região específica.

A rede particular do Google conecta nossos locais regionais a mais de 100 pontos de presença da rede global. O Google Cloud usa redes definidas por software e tecnologias de sistemas distribuídos para hospedar e fornecer seus serviços em todo o mundo. O principal elemento do Google para rede no Google Cloud é a VPC global. A VPC usa a rede global de alta velocidade do Google para vincular seus aplicativos em várias regiões, oferecendo compatibilidade com privacidade e confiabilidade. O Google garante que seu conteúdo seja entregue com alta capacidade usando tecnologias como Largura de banda de Gargalo e Tempo de propagação de ida e volta (BBR, na sigla em inglês), inteligência de controle de congestionamento.

O desenvolvimento do design de rede em nuvem inclui as seguintes etapas:

1. Projete a arquitetura da VPC da carga de trabalho. Comece identificando quantos projetos do Google Cloud e redes VPC são necessários.
2. Adicione conectividade entre VPCs. Defina como suas cargas de trabalho se conectam a outras em diferentes redes VPC.
3. Projetar conectividade de rede híbrida. Projete como as VPCs de carga de trabalho se conectam ao ambiente local e outros a nuvem.

Ao projetar sua rede do Google Cloud, considere o seguinte:

• Uma VPC oferece um ambiente de rede particular na nuvem para serviços de interconexão criados no Compute Engine, Google Kubernetes Engine (GKE) e Soluções de computação sem servidor. Também é possível usar uma VPC para acessar de forma particular serviços gerenciados pelo Google, como Cloud Storage, BigQuery e . Cloud SQL.
• Redes VPC, inclusive as rotas associadas e regras de firewall, são recursos globais. elas não estão associadas a nenhuma região ou zona específica.
• Sub-redes são recursos regionais. As instâncias de VM do Compute Engine que são implantadas em diferentes zonas na mesma região da nuvem podem usar endereços IP da mesma sub-rede.
• O tráfego para instâncias e a partir delas pode ser controlado usando regras de firewall VPC.
• A administração da rede pode ser protegida usando papéis de gerenciamento de identidade e acesso (IAM, na sigla em inglês).
• As redes VPC podem ser conectadas com segurança em ambientes híbridos usando Cloud VPN ou Cloud Interconnect.

Para ver uma lista completa das especificações de VPC, consulte Especificações.

Arquitetura de VPC de carga de trabalho

Nesta seção, você verá as práticas recomendadas para projetar arquiteturas de VPC de carga de trabalho para dar suporte ao sistema.

Considerar o design da rede VPC antecipadamente

Faça do design de rede VPC uma parte inicial da criação de sua configuração organizacional no Google Cloud. As escolhas de design em nível organizacional não podem ser facilmente revertidas posteriormente no processo. Para mais informações, consulte Práticas recomendadas e arquiteturas de referência para o design da VPC e Decidir o design da rede para sua zona de destino do Google Cloud.

Começar com uma única rede VPC

Para muitos casos de uso que incluem recursos com requisitos comuns, uma única rede VPC fornece os recursos necessários. Redes VPC únicas são simples de criar, manter e entender. Para mais informações, consulte Especificações de rede VPC.

Mantenha a topologia de rede VPC simples

Para garantir uma arquitetura gerenciável, confiável e bem compreendida, mantenha o design da sua topologia de rede VPC o mais simples possível.

Usar redes VPC no modo personalizado

Para garantir que a rede do Google Cloud se integre perfeitamente aos seus sistemas de rede atuais, recomendamos que você use o modo personalizado ao criar redes VPC. O modo personalizado ajuda você a integrar a rede do Google Cloud aos esquemas atuais de gerenciamento de endereços IP e permite controlar quais regiões da nuvem estão incluídas na VPC. Para mais informações, consulte VPC.

Conectividade entre VPCs

Nesta seção, você verá as práticas recomendadas para projetar a conectividade entre VPCs e ser compatível com seu sistema.

Escolha um método de conexão VPC

Se você decidir implementar várias redes VPC, será necessário conectar essas redes. As redes VPC são espaços de locatário isolados na rede definida por software (SDN, na sigla em inglês) do Andromeda do Google. As redes VPC podem se comunicar de várias maneiras. Escolha como conectar a rede com base nos requisitos de largura de banda, latência e contrato de nível de serviço (SLA). Para saber mais sobre opções de conexão, consulte Escolher o método de conexão da VPC que atenda às necessidades de custo, desempenho e segurança.

Use uma VPC compartilhada para administrar vários grupos de trabalho

Para organizações com várias equipes, a VPC compartilhada oferece uma ferramenta eficaz para aprimorar a simplicidade arquitetônica de uma única rede VPC em vários grupos de trabalho.

Usar convenções de nomenclatura simples

Escolha convenções de nomenclatura simples, intuitivas e consistentes. Isso ajuda os administradores e os usuários a entender a finalidade de cada recurso, onde ele está localizado e como ele é diferenciado de outros recursos.

Use testes de conectividade para verificar a segurança da rede

No contexto da segurança de rede, é possível usar testes de conectividade para verificar se o tráfego que você pretende impedir entre dois endpoints está bloqueado. Para verificar se o tráfego está bloqueado e por que ele está bloqueado, defina um teste entre dois endpoints e avalie os resultados. Por exemplo, é possível testar um recurso VPC que permite definir regras compatíveis com bloqueio de tráfego. Para mais informações, consulte a visão geral dos testes de conectividade.

Usar o Private Service Connect para criar endpoints particulares

Para criar endpoints particulares que permitam acessar os serviços do Google com seu próprio esquema de endereço IP, use o Private Service Connect. É possível acessar os endpoints particulares pela VPC e por meio de conectividade híbrida que termina na VPC.

Proteja e limite a conectividade externa

Limite o acesso à Internet apenas aos recursos que necessitam dele. Recursos com apenas um endereço IP interno privado ainda podem acessar muitos serviços e APIs do Google por meio do Acesso privado do Google.

Use o Network Intelligence Center para monitorar suas redes de nuvem

O Network Intelligence Center oferece uma visão abrangente das suas redes do Google Cloud em todas as regiões. Ele ajuda a identificar padrões de tráfego e acesso que podem causar riscos operacionais ou de segurança.

A seguir

Conheça as práticas recomendadas de gerenciamento de armazenamento, incluindo as seguintes:

• Selecione um tipo de armazenamento.
• Escolha padrões de carga de trabalho e padrões de acesso ao armazenamento.

Explore outras categorias no Framework de arquitetura, como confiabilidade, excelência operacional e segurança, privacidade e conformidade.

Selecionar e implementar uma estratégia de armazenamento

Neste documento, mostramos o framework de arquitetura do Google Cloud sobre as práticas recomendadas para implantar seu sistema com base no armazenamento. Você aprenderá a selecionar uma estratégia de armazenamento e como gerenciar armazenamento, padrões de acesso e cargas de trabalho.

Para facilitar a troca de dados e fazer backup e armazenar dados com segurança, as organizações precisam escolher um plano de armazenamento com base na carga de trabalho, operações de entrada/saída por segundo (IOPS, na sigla em inglês), latência, frequência de recuperação, local, capacidade e formato (bloco, arquivo e objeto).

O Cloud Storage oferece serviços de armazenamento de objetos confiáveis e seguros, incluindo:

• Opções de redundância integradas para proteger os dados contra falhas de equipamento e garantir a disponibilidade deles durante a manutenção do data center.
• Opções de transferência de dados, incluindo estas:
  • Serviço de transferência do Cloud Storage
  • Transfer Appliance
  • Serviço de transferência de dados do BigQuery
  • Migração para o Google Cloud: como transferir seus conjuntos de dados grandes
• Classes de armazenamento para dar suporte às cargas de trabalho.
• Somas de verificação calculadas para todas as operações do Cloud Storage que permitem ao Google verificar leituras e gravações.

No Google Cloud, a IOPS é escalonada de acordo com o espaço de armazenamento provisionado. Alguns tipos de armazenamento, como discos permanentes, exigem replicação e backup manuais porque são regionais ou por zona. Por outro lado, o armazenamento de objetos é altamente disponível e replica automaticamente dados em uma única região ou em várias regiões.

Tipo de armazenamento

Nesta seção, você verá as práticas recomendadas para escolher um tipo de armazenamento compatível com seu sistema.

Avaliar as opções de armazenamento de alto desempenho

Avalie discos permanentes ou unidades de estado sólido (SSD) locais para aplicativos de computação que exigem armazenamento de alto desempenho. O Cloud Storage é um armazenamento de objetos imutável com controle de versões. O uso do Cloud Storage com o Cloud CDN ajuda na otimização de custos, especialmente para objetos estáticos acessados com frequência.

O Filestore é compatível com aplicativos de várias gravações que precisam de espaço compartilhado de alto desempenho. O Filestore também é compatível com aplicativos modernos e legados que exigem operações de arquivos do tipo POSIX por meio de ativações do Network File System (NFS).

O Cloud Storage é compatível com casos de uso, como a criação de data lakes e abordagem de requisitos de arquivamento. Tome decisões de compensação com base em como você escolhe a classe do Cloud Storage devido aos custos de acesso e recuperação, especialmente ao configurar políticas de retenção. Para mais informações, consulte Criar uma estratégia de armazenamento ideal para sua carga de trabalho na nuvem.

Todas as opções de armazenamento são criptografadas por padrão em repouso e em trânsito usando chaves gerenciadas pelo Google. Para tipos de armazenamento como o Persistent Disk e o Cloud Storage, é possível fornecer sua própria chave ou gerenciá-los por meio do Cloud Key Management Service (Cloud KMS). Estabeleça uma estratégia para lidar com essas chaves antes de aplicá-las aos dados de produção.

Escolher os serviços do Google Cloud compatíveis com o design de armazenamento

Para saber mais sobre os serviços do Google Cloud compatíveis com o design de armazenamento, use a tabela a seguir:

Serviço do Google Cloud	Descrição
Cloud Storage	Oferece armazenamento e recuperação global de qualquer quantidade de dados a qualquer momento. É possível usar o Cloud Storage para uma variedade de cenários, incluindo veiculação de conteúdo do site, armazenamento de dados para arquivamento e recuperação de desastres ou distribuição de objetos de dados grandes por meio de download direto. Para ver mais informações, consulte os seguintes tópicos: Práticas recomendadas do Cloud Storage Locais dos buckets Classes de armazenamento Cloud Storage FUSE
Persistent Disk	Um armazenamento em blocos de alto desempenho para o Google Cloud. O Persistent Disk fornece armazenamento SSD e de disco rígido (HDD, na sigla em inglês) que pode ser anexado a instâncias em execução no Compute Engine ou no Google Kubernetes Engine (GKE). Os discos regionais fornecem armazenamento durável e replicação de dados entre duas zonas na mesma região. Se você precisar de IOPS mais altas e baixa latência, o Google Cloud oferece o Filestore. Os SSDs locais são fisicamente anexados ao servidor que hospeda a instância da máquina virtual. É possível usar SSDs locais como espaço em disco temporário.
Filestore	Um serviço de armazenamento de arquivos gerenciado para aplicativos que exigem uma interface de sistema de arquivos e um sistema de arquivos compartilhado para dados. O Filestore proporciona aos usuários uma experiência perfeita para manter o armazenamento conectado à rede (NAS, na sigla em inglês) gerenciado com as respectivas instâncias do Compute Engine e do GKE.
Cloud Storage para Firebase	Criado para desenvolvedores de aplicativos que precisam armazenar e disponibilizar conteúdo gerado pelo usuário, como fotos ou vídeos. Todos os seus arquivos são armazenados em buckets do Cloud Storage. Portanto, eles podem ser acessados no Firebase e no Google Cloud.

Escolher uma estratégia de armazenamento

Para selecionar uma estratégia de armazenamento que atenda aos requisitos do aplicativo, use a seguinte tabela:

Caso de uso	Recomendações
Você quer armazenar dados em escala com o menor custo, e o desempenho de acesso não é um problema.	Cloud Storage
Você está executando aplicativos de computação que precisam de armazenamento imediato. Saiba mais em Como otimizar o desempenho de discos permanentes e SSDs locais.	Persistent Disk ou SSD local
Você está executando cargas de trabalho de alto desempenho que precisam de acesso de leitura e gravação ao espaço compartilhado.	Filestore
Você tem casos de uso de computação de alto desempenho (HPC) ou de alta capacidade (HTC, na sigla em inglês).	Como usar clusters na computação técnica em grande escala no Google Cloud

Escolher armazenamento ativo ou de arquivamento com base nas necessidades de acesso do armazenamento

Uma classe de armazenamento é um fragmento de metadados usado por todos os objetos. Para dados exibidos em uma taxa alta com alta disponibilidade, use a classe Standard Storage. Para dados que são acessados com pouca frequência e podem tolerar uma disponibilidade um pouco menor, use a classe Nearline Storage, Coldline Storage ou Archive Storage. Para mais informações sobre considerações de custo para escolher uma classe de armazenamento, consulte Preços do Cloud Storage.

Avaliar as necessidades de localização de armazenamento e proteção de dados do Cloud Storage

Para um bucket do Cloud Storage localizado em uma região, os dados contidos nele são replicados automaticamente entre as zonas da região. A replicação de dados entre zonas protege os dados se houver uma falha zonal em uma região.

O Cloud Storage também oferece locais redundantes entre as regiões, o que significa que os dados são replicados em vários data centers geograficamente separados. Para mais informações, consulte Locais de bucket.

Usar o Cloud CDN para melhorar a entrega de objetos estáticos

Para otimizar o custo de recuperação de objetos e minimizar a latência do acesso, use o Cloud CDN. O Cloud CDN usa o balanceador de carga de aplicativo externo do Cloud Load Balancing para fornecer suporte a roteamento, verificação de integridade e endereço IP anycast. Para mais informações, consulte Como configurar o Cloud CDN com buckets de nuvem.

Padrão do acesso de armazenamento e tipo de carga de trabalho

Nesta seção, você verá as práticas recomendadas para escolher padrões de acesso de armazenamento e tipos de carga de trabalho compatíveis com seu sistema.

Usar o Persistent Disk para permitir o acesso ao armazenamento de alto desempenho

Os padrões de acesso aos dados dependem de como o desempenho do sistema é projetado. O Cloud Storage fornece armazenamento escalonável, mas não é uma escolha ideal quando você executa cargas de trabalho pesadas de computação que precisam de acesso de alta capacidade para grandes quantidades de dados. Para acesso a armazenamento de alto desempenho, use disco permanente.

Usar espera exponencial ao implementar lógica de repetição

Use a espera exponencial ao implementar a lógica de nova tentativa para lidar com erros 5XX, 408 e 429. Cada bucket do Cloud Storage é provisionado com capacidade inicial de E/S. Para mais informações, consulte as Diretrizes de taxa de solicitação e distribuição de acesso. Planejar um aumento gradual para solicitações de repetição.

Gerenciamento de armazenamento

Nesta seção, você verá as práticas recomendadas de gerenciamento de armazenamento compatíveis com o sistema.

Atribuir nomes exclusivos a cada bucket

Torne cada nome de bucket exclusivo em todo o namespace do Cloud Storage. Não inclua informações confidenciais em um nome de bucket. Escolha nomes de buckets e objetos que são difíceis de adivinhar. Para mais informações, consulte as diretrizes de nomenclatura de bucket e diretrizes de nomenclatura de objeto.

Mantenha os buckets do Cloud Storage privados

A menos que haja um motivo relacionado a negócios, verifique se o bucket do Cloud Storage não está acessível de forma anônima ou pública. Para mais informações, consulte Visão geral do controle de acesso.

Atribuir nomes de objetos aleatórios para distribuir a carga uniformemente

Atribua nomes aleatórios de objetos para facilitar o desempenho e evitar o uso excessivo do ponto de acesso. Use um prefixo aleatório para objetos sempre que possível. Para mais informações, consulte Usar uma convenção de nomenclatura que distribua a carga uniformemente pelos intervalos de chaves.

Usar a prevenção do acesso público

Para impedir o acesso no nível da organização, da pasta, do projeto ou do bucket, use a prevenção do acesso público. Para mais informações, consulte Como usar a prevenção do acesso público.

A seguir

Saiba mais sobre os serviços de banco de dados do Google Cloud e as práticas recomendadas, incluindo:

• Selecione e migre seu banco de dados.
• Gerencie a criptografia do banco de dados.
• Gerenciar as redes e o acesso ao banco de dados.

Explore outras categorias no Framework de arquitetura, como confiabilidade, excelência operacional e segurança, privacidade e conformidade.

Otimizar seu banco de dados

Neste documento, mostramos o framework de arquitetura do Google Cloud sobre as práticas recomendadas para implantar seu sistema com base no design do banco de dados. Saiba como projetar, migrar e escalonar bancos de dados, criptografar informações de banco de dados, gerenciar o licenciamento e monitorar seu banco de dados para eventos.

Principais serviços

Este documento na categoria de design do sistema Framework de arquitetura fornece práticas recomendadas que incluem vários serviços de banco de dados do Google Cloud. A tabela a seguir fornece uma visão geral de alto nível desses serviços:

Serviço do Google Cloud	Descrição
Cloud SQL	Um serviço de banco de dados totalmente gerenciado que permite configurar, manter, gerenciar e administrar seus bancos de dados relacionais que usam o Cloud SQL para PostgreSQL, Cloud SQL para MySQL e Cloud SQL para SQL Server. O Cloud SQL oferece alto desempenho e escalonabilidade. Hospedado no Google Cloud, o Cloud SQL fornece uma infraestrutura de banco de dados para aplicativos em execução em qualquer lugar.
Bigtable	Uma tabela que pode ser escalonada para bilhões de linhas e milhares de colunas, permitindo que você armazene até petabytes de dados. Apenas um valor em cada linha é indexado. Esse valor é conhecido como a chave de linha. Use o Bigtable para armazenar quantidades muito grandes de dados de chave única com latência muito baixa. Ele conta com alta capacidade de operações de leitura e gravação em latência baixa, além de ser a fonte de dados ideal para operações de MapReduce.
Spanner	Um serviço de banco de dados empresarial escalonável e distribuído globalmente criado para a nuvem que inclui estrutura de banco de dados relacional e escala horizontal não relacional. Essa combinação resulta em transações de alto desempenho e consistência em linhas, regiões e continentes. O Spanner fornece um SLA de disponibilidade de 99.999%, sem inatividade planejada e segurança de nível empresarial.
Memorystore	Um serviço Redis totalmente gerenciado para o Google Cloud. Os aplicativos executados no Google Cloud podem melhorar o desempenho usando o serviço Redis altamente disponível, escalonável e seguro sem gerenciar implantações complexas do Redis.
Firestore	Um banco de dados de documentos NoSQL criado para oferecer escalonamento automático, alto desempenho e desenvolvimento de aplicativos. Embora a interface do Firestore tenha muitos dos mesmos recursos dos bancos de dados tradicionais, ela é um banco de dados NoSQL e descreve as relações entre os objetos de dados de maneira diferente.
Firebase Realtime Database	Um banco de dados hospedado na nuvem. O Firebase armazena dados como JSON e sincroniza em tempo real com cada cliente conectado. Quando você cria apps multiplataforma com nossos SDKs para iOS, Android e JavaScript, todos os clientes compartilham uma instância do Realtime Database e recebem automaticamente atualizações com os dados mais recentes.
Bancos de dados de código aberto	Os parceiros do Google oferecem diferentes bancos de dados de código aberto, incluindo MongoDB, MariaDB e Redis.
AlloyDB para PostgreSQL	Um serviço de banco de dados totalmente gerenciado e compatível com PostgreSQL para cargas de trabalho empresariais exigentes. Desempenho até 4 vezes mais rápido para cargas de trabalho transacionais e consultas analíticas até 100 vezes mais rápidas em comparação com o PostgreSQL padrão. O AlloyDB para PostgreSQL simplifica o gerenciamento com sistemas de Autopilot habilitados para machine learning.

Seleção de banco de dados

Nesta seção, você verá as práticas recomendadas para escolher um banco de dados a ser compatível com seu sistema.

Considerar o uso de um serviço de banco de dados gerenciado

Avalie os serviços de banco de dados gerenciados do Google Cloud antes de instalar seu próprio banco de dados ou cluster de banco de dados. A instalação do próprio banco de dados envolve sobrecarga de manutenção, incluindo a instalação de patches e atualizações e o gerenciamento de atividades operacionais diárias, como monitoramento e backup.

Use requisitos de aplicativos funcionais e não funcionais para impulsionar a seleção do banco de dados. Considere o acesso de baixa latência, o processamento de dados de série temporal, a recuperação de desastres e a sincronização de clientes móveis.

Para migrar bancos de dados, use um dos produtos descritos na tabela a seguir:

Produto de migração de banco de dados	Descrição
Cloud SQL	Um serviço regional compatível com réplicas de leitura em regiões remotas, leituras de baixa latência e recuperação de desastres.
Spanner	Uma oferta multirregional com consistência externa, replicação global e um contrato de nível de serviço (SLA, na sigla em inglês) de cinco noves.
Bigtable	Um serviço de banco de dados NoSQL totalmente gerenciado e escalonável para grandes cargas de trabalho analíticas e operacionais com até 99.999% de disponibilidade.
Memorystore	Um serviço de banco de dados totalmente gerenciado que fornece uma versão gerenciada de duas soluções conhecidas de armazenamento em cache de código aberto: Redis e Memcached.
Firebase Realtime Database	O Firebase Realtime Database é um banco de dados NoSQL hospedado na nuvem. Com ele, você armazena e sincroniza dados entre seus usuários em tempo real.
Firestore	Um banco de dados de documentos NoSQL criado para oferecer escalonamento automático, alto desempenho e facilidade no desenvolvimento de aplicativos.
Código aberto	Opções alternativas de banco de dados, incluindo MongoDB e MariaDB.

Migração de bancos de dados

Para garantir que os usuários não apresentem inatividade de aplicativos ao migrar cargas de trabalho atuais para o Google Cloud, é importante escolher tecnologias de banco de dados que atendam aos seus requisitos. Para informações sobre opções e práticas recomendadas para migração de banco de dados, consulte Soluções de migração de banco de dados e Práticas recomendadas para migrações homogêneas de banco de dados.

O planejamento para uma migração de banco de dados inclui o seguinte:

• Avaliação e descoberta do banco de dados atual.
• Definições de critérios de sucesso da migração.
• Configuração do ambiente para migração e o banco de dados de destino.
• Criação do esquema no banco de dados de destino.
• Migração dos dados para o banco de dados de destino.
• Validação da migração para verificar se todos os dados foram migrados corretamente e se estão presentes no banco de dados.
• Criação de estratégia de reversão.

Escolher uma estratégia de migração

Selecionar o banco de dados de destino apropriado é uma das chaves para uma migração bem-sucedida. A tabela a seguir fornece opções de migração para alguns casos de uso:

Caso de uso	Recomendação
Novo desenvolvimento no Google Cloud.	Selecione um dos bancos de dados gerenciados criados para a nuvem (Cloud SQL, Cloud Spanner, Bigtable ou Firestore) para atender aos requisitos do seu caso de uso.
Migração lift-and-shift.	Escolha um serviço de banco de dados gerenciado e compatível, como o Cloud SQL, MYSQL, PostgreSQL ou SQLServer.
O aplicativo requer acesso granular a um banco de dados incompatível com o CloudSQL.	Execute seu banco de dados nas VMs do Compute Engine.

Usar o Memorystore para ser compatível com a camada de banco de dados de armazenamento em cache

O Memorystore é um banco de dados Redis e Memcached totalmente gerenciado compatível com latência de submilissegundos. O Memorystore é totalmente compatível com o Redis e o Memcached de código aberto. Se você usar esses bancos de dados de armazenamento em cache nos seus aplicativos, poderá usar o Memorystore sem fazer alterações no nível do aplicativo no código.

Usar servidores Bare Metal para executar um banco de dados Oracle

Se suas cargas de trabalho exigirem um banco de dados Oracle, use os servidores Bare Metal fornecidos pelo Google Cloud. Essa abordagem se encaixa em uma estratégia de migração lift-and-shift.

Se quiser mover a carga de trabalho para o Google Cloud e modernizar após o trabalho da carga de base, considere usar opções de banco de dados gerenciadas, como Spanner, Bigtable e Firestore.

Os bancos de dados criados para a nuvem são bancos de dados gerenciados modernos, criados de baixo para cima na infraestrutura em nuvem. Esses bancos de dados oferecem recursos padrão exclusivos, como escalonabilidade e alta disponibilidade, que são difíceis de alcançar se você executa o próprio banco de dados.

Modernize seu banco de dados

Planeje sua estratégia de banco de dados no início do processo de design do sistema, seja para projetar um novo aplicativo na nuvem ou migrando um banco de dados atual para a nuvem. O Google Cloud oferece opções de bancos de dados gerenciados para bancos de dados de código aberto, como o Cloud SQL para MySQL e o Cloud SQL para PostgreSQL. Recomendamos que você use a migração como uma oportunidade para modernizar seu banco de dados e prepará-lo para atender às necessidades comerciais futuras.

Usar bancos de dados fixos com aplicativos prontos para uso

Os aplicativos comerciais e prontos para uso (COTS, na sigla em inglês) exigem um tipo fixo de banco de dados e configuração fixa. A migração lift-and-shift geralmente é a abordagem mais apropriada para aplicativos COTS.

Verificar o conjunto de habilidades de migração de banco de dados da equipe

Escolha uma abordagem de migração de banco de dados na nuvem com base nos recursos e nas habilidades da migração do banco de dados da sua equipe. Use o Google Cloud Partner Advantage para encontrar um parceiro que possa ajudar você em toda a jornada de migração.

Projetar seu banco de dados para atender aos requisitos de HA e DR

Ao projetar seus bancos de dados para atender aos requisitos de alta disponibilidade (HA, na sigla em inglês) e recuperação de desastres (DR, na sigla em inglês), avalie o equilíbrio entre confiabilidade e custo. Os serviços de banco de dados criados para a nuvem criam várias cópias dos dados em uma ou várias regiões, dependendo do banco de dados e da configuração.

Alguns serviços do Google Cloud têm variantes multirregionais, como o BigQuery e o Spanner. Para ser resistente a falhas regionais, use esses serviços multirregionais no seu design sempre que possível.

Se você projetar seu banco de dados em VMs do Compute Engine, em vez de usar bancos de dados gerenciados no Google Cloud, execute várias cópias dos seus bancos de dados. Para mais informações, consulte Projetar para escala e alta disponibilidade na categoria Confiabilidade.

Especificar regiões de nuvem para oferecer suporte à residência de dados

A residência dos dados descreve onde eles residem fisicamente. Considere escolher regiões específicas da nuvem para implantar seus bancos de dados com base nos requisitos de residência de dados.

Se você implantar seus bancos de dados em várias regiões, poderá haver replicação de dados entre eles, dependendo de como você os configura. Selecione a configuração que mantém seus dados nas regiões em repouso que você quer. Alguns bancos de dados, como o Spanner, oferecem replicação multirregional padrão. Também é possível aplicar a residência de dados definindo uma política da organização que inclua as restrições de locais de recursos. Para mais informações, consulte Como restringir locais de recursos.

Incluir recuperação de desastres no design de residência de dados

Inclua o objetivo de tempo de recuperação (RTO, na sigla em inglês) e o objetivo de ponto de recuperação (RPO, na sigla em inglês) nos planos de residência de dados e considere o equilíbrio entre RTO/RPO e custos da solução de recuperação de desastres. Números menores de RTO/RPO resultam em custos mais altos. Se você quiser que seu sistema se recupere mais rapidamente após interrupções, ele custará mais para ser executado. Além disso, inclua a satisfação do cliente na sua abordagem de recuperação de desastres para garantir que seus investimentos em confiabilidade sejam apropriados. Para mais informações, consulte 100% de confiabilidade é o destino errado e o Guia de planejamento de recuperação de desastres.

Torne seu banco de dados compatível com o Google Cloud

Ao escolher um banco de dados para a carga de trabalho, verifique se o serviço selecionado atende à conformidade da região geográfica em que você está operando e onde os dados estão armazenados fisicamente. Para mais informações sobre as certificações e os padrões de conformidade do Google, consulte Ofertas de conformidade.

Criptografia

Esta seção fornece práticas recomendadas para identificar requisitos de criptografia e escolher uma estratégia de chave de criptografia para oferecer suporte ao sistema.

Determinar os requisitos de criptografia

Os requisitos de criptografia dependem de vários fatores, incluindo as políticas de segurança da empresa e os requisitos de conformidade. Todos os dados armazenados no Google Cloud são criptografados em repouso por padrão, sem que você precise fazer nada, usando o AES256. Para mais informações, consulte Criptografia em repouso no Google Cloud.

Escolher uma estratégia de chave de criptografia

Decida se você quer gerenciar chaves de criptografia ou usar um serviço gerenciado. O Google Cloud é compatível com os dois cenários. Se você quiser que um serviço totalmente gerenciado gerencie as chaves de criptografia no Google Cloud, escolha Cloud Key Management Service (Cloud KMS). Se você quiser gerenciar as chaves de criptografia para manter mais controle sobre o ciclo de vida delas, use as chaves de criptografia gerenciadas pelo cliente (CMEK).

Para criar e gerenciar suas chaves de criptografia fora do Google Cloud, escolha uma das seguintes opções:

• Se você usa uma solução de parceiro para gerenciar suas chaves, utilize o Cloud External Key Manager.
• Se você gerenciar suas chaves no local e quiser usá-las para criptografar os dados no Google Cloud, importe essas chaves para o Cloud KMS como chaves do KMS ou chaves do módulo de chaves de hardware (HSM, na sigla em inglês). Use essas chaves para criptografar seus dados no Google Cloud.

Design e escalonamento do banco de dados

Nesta seção, você encontrará as práticas recomendadas para projetar e escalonar um banco de dados para dar suporte ao seu sistema.

Use métricas de monitoramento para avaliar as necessidades de escalonamento

Use métricas de ferramentas e ambientes de monitoramento atuais para estabelecer uma compreensão básica dos tamanhos e das exigências de escalonamento do banco de dados. Por exemplo, dimensionar e projetar estratégias de escalonamento para a instância do banco de dados.

Para novos designs de banco de dados, determine os números de escalonamento com base nos padrões esperados de carga e tráfego do aplicativo de exibição. Para mais informações, consulte Como monitorar instâncias do Cloud SQL, Como monitorar com o Cloud Monitoring e Como monitorar uma instância.

Rede e acesso

Nesta seção, você encontrará as práticas recomendadas para gerenciar a rede e o acesso ao seu sistema.

Executar bancos de dados dentro de uma rede particular

Execute seus bancos de dados dentro da rede particular e conceda acesso restrito apenas dos clientes que precisam interagir com o banco de dados. É possível criar instâncias do Cloud SQL dentro de uma VPC. O Google Cloud também fornece VPC Service Controls para bancos de dados do Cloud SQL, Spanner e Bigtable para garantir que o acesso a esses recursos seja restrito apenas aos recursos clientes em redes VPC autorizadas.

Conceder privilégios mínimos aos usuários

O gerenciamento de identidade e acesso (IAM, na sigla em inglês) controla o acesso aos serviços do Google Cloud, incluindo serviços de banco de dados. Para minimizar o risco de acesso não autorizado, conceda o menor número de privilégios a seus usuários. Para acessar os bancos de dados no nível do aplicativo, use contas de serviço com o menor número de privilégios.

Automação e dimensionamento correto

Nesta seção, você conhecerá as práticas recomendadas para definir a automação e o dimensionamento correto para seu sistema.

Definir instâncias de banco de dados como código

Um dos benefícios da migração para o Google Cloud é a capacidade de automatizar a infraestrutura e outros aspectos da carga de trabalho, como camadas de computação e banco de dados. O Google Deployment Manager e ferramentas de terceiros, como Nuvem do Terraform, definem as instâncias do banco de dados como código, o que permite aplicar uma abordagem consistente e recorrente à criação e atualização dos bancos de dados.

Usar o Liquibase para controlar a versão do seu banco de dados

Os serviços de banco de dados do Google, como o Cloud SQL e o Spanner, dão suporte ao Liquibase, uma ferramenta de controle de versões de código aberto para bancos de dados. O Liquibase ajuda você a rastrear as alterações no esquema do banco de dados, reverter as alterações e fazer migrações reproduzíveis.

Testar e ajustar o banco de dados para dar suporte ao escalonamento

Faça testes de carga na sua instância do banco de dados e ajuste-os com base nos resultados do teste para atender aos requisitos do seu aplicativo. Determine a escala inicial do seu banco de dados por indicadores de desempenho principais de teste de carga (KPI, na sigla em inglês) ou usando KPIs de monitoramento derivados do seu banco de dados atual.

Ao criar instâncias de banco de dados, comece com um tamanho baseado nos resultados do teste ou nas métricas históricas de monitoramento. Teste as instâncias de banco de dados com a carga esperada na nuvem. Em seguida, ajuste as instâncias até receber os resultados desejados para a carga esperada nas instâncias do banco de dados.

Escolha o banco de dados certo para seus requisitos de escalonamento

O escalonamento de bancos de dados é diferente do escalonamento de componentes da camada de computação. Os bancos de dados têm estado; quando uma instância do seu banco de dados não for capaz de lidar com a carga, considere a estratégia apropriada para escalonar as instâncias do banco de dados. As estratégias de escalonamento variam de acordo com o tipo de banco de dados.

Use a tabela a seguir para saber mais sobre os produtos do Google que abordam casos de uso de escalonamento.

Caso de uso	Produto recomendado	Descrição
Dimensione horizontalmente sua instância de banco de dados adicionando nós a ele quando precisar aumentar a capacidade e o armazenamento de disponibilização.	Spanner	Um banco de dados relacional criado para a nuvem.
Adicione nós para escalonar seu banco de dados.	Bigtable	Serviço de banco de dados de Big Data NoSQL totalmente gerenciado.
Gerencie automaticamente o escalonamento do banco de dados.	Firestore	Banco de dados flexível e escalonável para desenvolvimento em dispositivos móveis, Web e servidores.
Para exibir mais consultas, faça o escalonamento vertical das instâncias do banco de dados do Cloud SQL para oferecer mais capacidade de computação e memória. No Cloud SQL, a camada de armazenamento é separada da instância do banco de dados. É possível optar por escalonar a camada de armazenamento automaticamente sempre que ela atingir a capacidade.	Cloud SQL	Serviço de banco de dados totalmente gerenciado que ajuda a configurar, manter, gerenciar e administrar seus bancos de dados relacionais no Google Cloud.

Operações

Nesta seção, você encontrará as práticas recomendadas para operações compatíveis com seu sistema.

Usar o Cloud Monitoring para monitorar e configurar alertas para seu banco de dados

Use o Cloud Monitoring para monitorar instâncias de banco de dados e configurar alertas para notificar as equipes adequadas sobre eventos. Para informações sobre as práticas recomendadas de alertas eficientes, consulte Criar alertas eficientes.

Todos os bancos de dados criados na nuvem fornecem métricas de geração de registros e monitoramento. Cada serviço tem um painel para visualizar as métricas de geração de registros e de monitoramento. As métricas de monitoramento de todos os serviços são integradas ao Google Cloud Observability. O Spanner disponibiliza ferramentas de introspecção de consultas, como o Key Visualizer, para depuração e análise de causa raiz. O Key Visualizer fornece os seguintes recursos:

• Ajuda a analisar os padrões de uso do Spanner gerando relatórios visuais dos bancos de dados. Os relatórios exibem padrões de uso por intervalos de linhas ao longo do tempo.
• Fornece insights sobre padrões de uso em escala.

O Bigtable também oferece uma ferramenta de diagnóstico do Key Visualizer que ajuda a analisar os padrões de uso da instância do Bigtable.

Licenciamento

Nesta seção, você conhecerá as práticas recomendadas de licenciamento para oferecer suporte ao sistema.

Escolher entre licenças sob demanda e licenças existentes

Se você usa o Cloud SQL para SQL Server, traga suas próprias licenças não é compatível. Seus custos de licenciamento são baseados no uso por hora.

Se você quiser usar licenças do Cloud SQL para SQL Server atuais, considere executar o Cloud SQL para SQL Server em VMs do Compute. Para mais informações, consulte Licenças da Microsoft e Como escolher entre licenças sob demanda ou adquiridas pelo usuário.

Se você usa a Oracle e está migrando para a Solução Bare Metal para Oracle, é possível usar suas próprias licenças. Para mais informações, consulte Planejar a solução Bare Metal.

Cronogramas, metodologia e conjuntos de ferramentas de migração

Nesta seção, você encontrará as práticas recomendadas para planejar e oferecer suporte à migração do banco de dados para dar suporte ao sistema.

Determine a prontidão da modernização do banco de dados

Avalie se sua organização está pronta para modernizar os bancos de dados e usar aqueles criados para a nuvem.

Considere a modernização do banco de dados ao planejar os cronogramas de migração da carga de trabalho, porque é provável que a modernização afete o aplicativo.

Envolver as partes interessadas relevantes no planejamento da migração

Para migrar um banco de dados, conclua as seguintes tarefas:

• Configure os bancos de dados de destino.
• Converta o esquema.
• Configurar a replicação de dados entre o banco de dados de origem e de destino.
• Depure problemas à medida que surgirem durante a migração.
• Estabeleça a conectividade de rede entre a camada do aplicativo e o banco de dados.
• Implemente a segurança do banco de dados de destino.
• Verifique se os aplicativos se conectam aos bancos de dados de destino.

Essas tarefas geralmente exigem conjuntos de habilidades diferentes, e várias equipes colaboram na organização para concluir a migração. Ao planejar a migração, inclua as partes interessadas de todas as equipes, como desenvolvedores de apps, administradores de banco de dados e equipes de infraestrutura e segurança.

Se sua equipe não tiver habilidades para oferecer suporte a esse tipo de migração, os parceiros do Google poderão ajudar você a realizar suas migrações. Para mais informações, consulte Google Cloud Partner Advantage.

Identificar conjuntos de ferramentas para migrações homogêneas e heterogêneas

Uma migração homogênea é uma migração entre bancos de dados de origem e de destino com a mesma tecnologia. Uma migração heterogênea é aquele com um banco de dados de destino diferente do banco de dados de origem.

As migrações heterogêneas geralmente envolvem etapas adicionais de conversão de esquema do banco de dados de origem para o tipo de mecanismo do banco de dados de destino. As equipes de banco de dados precisam avaliar os desafios envolvidos na conversão do esquema porque dependem da complexidade do esquema do banco de dados de origem.

Testar e validar cada etapa da migração de dados

As migrações de dados envolvem várias etapas. Para minimizar os erros de migração, teste e valide cada etapa da migração antes de passar para a próxima. Os fatores a seguir impulsionam o processo de migração:

• Se a migração é homogênea ou heterogênea.
• Que tipo de ferramentas e conjuntos de habilidades você precisa para realizar a migração.
• Para migrações heterogêneas, a experiência com o mecanismo de banco de dados de destino.

Determinar requisitos de replicação contínua de dados

Crie um plano para migrar os dados inicialmente e replicá-los continuamente da origem para o banco de dados de destino. Continue a replicação até que o destino esteja estabilizado e o aplicativo seja completamente migrado para o novo banco de dados. Esse plano ajuda você a identificar possíveis tempos de inatividade durante a troca do banco de dados e a se planejar adequadamente.

Se você planeja migrar mecanismos de banco de dados do Cloud SQL, do Cloud SQL para MySQL ou do Cloud SQL para PostgreSQL, use o Serviço de migração de banco de dados para automatizar esse processo de maneira totalmente gerenciada. Para informações sobre ferramentas de terceiros compatíveis com outros tipos de migração, consulte Cloud Marketplace.

Recomendações

Para aplicar a orientação no Framework de arquitetura a seu próprio ambiente, recomendamos que você faça o seguinte:

• A multilocação para bancos de dados envolve o armazenamento de dados de vários clientes em uma infraestrutura compartilhada (neste caso, um banco de dados). Se você oferecer uma oferta de software como serviço (SaaS) baseada nos clientes, entenda como isolar conjuntos de dados logicamente que pertencem a diferentes clientes e ofereça suporte ao acesso deles. requisitos. Além disso, avalie seus requisitos com base em níveis de separação.

  Para bancos de dados relacionais, como Chave de gancho e Cloud SQL, existem várias abordagens, como isolar dados de locatários no nível da instância e do banco de dados, nível de esquema ou tabela. Como outras decisões de design, há uma compensação entre o grau de isolamento e outros fatores, como custo e desempenho. As políticas do IAM controlam o acesso às suas instâncias do banco de dados.

• Escolha o banco de dados certo para os requisitos do seu modelo de dados.

• Escolha valores-chave para evitar o uso excessivo de pontos de acesso. Um ponto de acesso é um local em uma tabela que recebe muito mais solicitações de acesso do que outros. Para mais informações sobre pontos de acesso, consulte Práticas recomendadas de design de esquema.

• Fragmente sua instância de banco de dados sempre que possível.

• Use as práticas recomendadas de gerenciamento de conexão, como o pooling de conexões e a espera exponencial.

• Evite transações muito grandes.

• Projete e teste a resposta do seu aplicativo a atualizações de manutenção em bancos de dados.

• Proteja e isole as conexões com seu banco de dados.

• Dimensione o banco de dados e as expectativas de crescimento para garantir que ele atenda aos seus requisitos.

• Teste suas estratégias de failover de HA e DR.

• Faça backups e restaure, além de exportações e importações, para que você esteja familiarizado com o processo.

Recomendações do Cloud SQL

• Use a rede privada de endereços IP (VPC). Para mais segurança, considere o seguinte:
  • Use o proxy Auth do Cloud SQL para aceitar a rede particular.
  • Restrinja o acesso de endereços IP públicos constraints/sql.restrictPublicIp.
• Se você precisar de uma rede de endereços IP públicos, considere o seguinte:
  • Use o firewall integrado com uma lista de endereços IP limitada ou restrita e verifique se as instâncias do Cloud SQL exigem que as conexões de entrada usem SSL. Para mais informações, consulte Como configurar certificados SSL/TLS.
• Para mais segurança, considere o seguinte:
  • Não conceda acesso geral. Em vez disso, use o proxy do Cloud SQL Auth.
  • Restrinja redes autorizadas constraints/sql.restrictAuthorizedNetworks.
• Use privilégios limitados para usuários do banco de dados.

A seguir

Conheça as práticas recomendadas de análise de dados, incluindo:

• Conheça os princípios básicos de análise de dados e os principais serviços do Google Cloud.
• Saiba mais sobre o ciclo de vida dos dados.
• Saiba como processar dados.
• Escolha e gerencie o armazenamento de dados.
• Processar e transformar dados.

Explore outras categorias no Framework de arquitetura, como confiabilidade, excelência operacional e segurança, privacidade e conformidade.

Analise seus dados

Neste documento, o framework de arquitetura do Google Cloud explica alguns dos princípios básicos e práticas recomendadas para análise de dados no Google Cloud. Você aprenderá sobre alguns dos principais serviços de análise de dados e como eles podem ajudar nos vários estágios do ciclo de vida de dados. Essas práticas recomendadas ajudam você a atender às suas necessidades de análise de dados e criar o design do sistema.

Princípios básicos

As empresas querem analisar dados e gerar insights úteis com base neles. O Google Cloud oferece vários serviços que ajudam você em todo o ciclo de vida dos dados, desde a ingestão de dados até os relatórios e a visualização. A maioria desses serviços é totalmente gerenciada, e alguns deles são sem servidor. Também é possível criar e gerenciar um ambiente de análise de dados em VMs do Compute Engine, como a auto-hospedagem do Hadoop do Apache ou Beam.

Seu foco específico, experiência em equipe e visão estratégica ajuda a determinar quais serviços do Google Cloud você adota para atender às suas necessidades de análise de dados. Por exemplo, o Dataflow permite gravar transformações complexas em uma abordagem sem servidor, mas você precisa depender de uma versão opinativa das configurações para necessidades de computação e processamento. Como alternativa, o Dataproc permite executar as mesmas transformações, mas você gerencia os clusters e ajusta os jobs por conta própria.

No design do sistema, pense na estratégia de processamento que suas equipes usam, como extrair, transformar, carregar (ETL) ou extrair, carregar, transform (ELT). O design do sistema também considera se você precisa processar análises em lote ou de streaming. O Google Cloud oferece uma plataforma de dados unificada e permite que você crie um data lake ou um armazenamento de dados para atender aos seus negócios necessidades.

Principais serviços

A tabela a seguir fornece uma visão geral de alto nível dos serviços de análise do Google Cloud:

Serviço do Google Cloud	Descrição
Pub/Sub	Base simples, confiável e escalonável para análise de stream e sistemas de computação orientados por eventos.
Dataflow	Um serviço totalmente gerenciado para transformar e enriquecer dados em modos de stream (tempo real) e lote (histórico).
Dataprep by Trifacta	Serviço de dados inteligente para explorar, limpar e preparar visualmente dados estruturados e não estruturados para análise.
Dataproc	Um serviço de nuvem rápido, fácil de usar e totalmente gerenciado para executar clusters do Apache Spark e Apache Hadoop.
Cloud Data Fusion	Serviço de integração de dados totalmente gerenciado, criado para a nuvem e permite criar e gerenciar pipelines de dados ETL/ELT. Ele fornece uma interface gráfica e uma ampla biblioteca de código aberto de transformações e conectores pré-configurados.
BigQuery	Armazenamento de dados sem servidor totalmente gerenciado e de baixo custo escalonável de acordo com suas necessidades de armazenamento e potência de computação. O BigQuery é um banco de dados ANSI SQL em colunas que pode analisar terabytes a petabytes de dados.
Cloud Composer	Serviço de orquestração de fluxo de trabalho totalmente gerenciado que permite criar, programar e monitorar pipelines que abrangem nuvens e data centers no local.
Data Catalog	Serviço de metadados escalonável e totalmente gerenciado que ajuda a descobrir, gerenciar e entender todos os dados.
Looker Studio	Serviço de análise visual totalmente gerenciado que pode ajudar você a extrair insights de dados por meio de painéis interativos.
Looker	Plataforma empresarial que conecta, analisa e visualiza dados em ambientes com várias nuvens.
Formulário de dados	Produto totalmente gerenciado para ajudar você a colaborar, criar e implantar pipelines de dados e garantir a qualidade dos dados.
Dataplex	Serviço de data lake gerenciado que gerencia, monitora e rege dados em data lakes, armazenamentos de dados e data marts usando controles consistentes.
AnalyticsHub	Plataforma que troca recursos de análise de dados de maneira eficiente e segura em toda a organização para enfrentar desafios de confiabilidade e custo de dados.

Ciclo de vida dos dados

Ao criar o design do sistema, é possível agrupar os serviços de análise de dados do Google Cloud relacionados à movimentação geral de dados em qualquer sistema ou ao redor do ciclo de vida dos dados.

O ciclo de vida dos dados inclui os estágios e os serviços de exemplo a seguir:

• A ingestão inclui serviços como Pub/Sub, Serviço de transferência do Cloud Storage, Transfer Appliance e BigQuery.
• Armazenamento inclui serviços como o Cloud Storage, Bigtable, Memorystore e o BigQuery.
• Processamento e transformação incluem serviços como o Dataflow, Dataproc, Dataprep, a Proteção de dados sensíveis e o BigQuery.
• A análise e o armazenamento incluem serviços como o BigQuery.
• A geração de relatórios e a visualização incluem serviços como oLooker Studio e o Looker.

Os estágios e serviços a seguir são executados em todo o ciclo de vida dos dados:

• A integração de dados inclui serviços como o Data Fusion.
• Gerenciamento de metadados e governança inclui serviços como o Data Catalog.
• O gerenciamento de fluxo de trabalho inclui serviços como o Cloud Composer.

Ingestão de dados

Aplique as práticas recomendadas de ingestão de dados a seguir ao seu ambiente.

Determinar a fonte de dados para processamento

Os dados geralmente vêm de outro provedor ou serviço de nuvem ou de um local:

• Para ingerir dados de outros provedores de nuvem, você normalmente usa o Cloud Data Fusion, o Serviço de transferência do Cloud Storage ou o BigQuery Serviço de transferência.

• Para ingestão de dados local, considere o volume de dados a serem ingeridos e o conjunto de habilidades da sua equipe. Se sua equipe preferir uma abordagem com interface gráfica do usuário (GUI) de baixo código, use o Cloud Data Fusion com um conector adequado, como o Java Database Connectivity (JDBC). Para grandes volumes de dados, use o Transfer Appliance ou o Serviço de transferência do Cloud Storage.

Pense em como você quer processar seus dados depois de ingeri-los. Por exemplo, o serviço de transferência do Cloud Storage grava apenas dados em um bucket do Cloud Storage e o serviço de transferência de dados do BigQuery grava dados apenas em um conjunto de dados do BigQuery. O Cloud Data Fusion é compatível com vários destinos.

Identificar fontes de dados de streaming ou em lote

Considere como é necessário usar seus dados e identificar onde há casos de uso de streaming ou em lote. Por exemplo, se você executar um serviço de streaming global com requisitos de baixa latência, poderá usar o Pub/Sub. Se você precisar dos dados para fins de análise e geração de relatórios, é possível fazer streaming de dados para o BigQuery.

Se você precisar fazer streaming de dados de um sistema como o Apache Kafka em um ambiente local ou outro ambiente de nuvem, use o Kafka para o BigQuery Dataflow. Para cargas de trabalho em lote, o primeiro passo geralmente é ingerir dados no Cloud Storage. Use a ferramenta gsutil ou o Serviço de transferência do Cloud Storage para ingerir dados.

Ingerir dados com ferramentas automatizadas

Mover dados manualmente de outros sistemas para a nuvem pode ser um desafio. Se possível, use ferramentas que permitam automatizar os processos de ingestão de dados. Por exemplo, o Cloud Data Fusion fornece conectores e plug-ins para trazer dados de fontes externas com uma GUI de arrastar e soltar. Se as equipes quiserem escrever código, o Data Flow ou o BigQuery pode ajudar a automatizar a ingestão de dados. O Pub/Sub pode ajudar tanto em uma abordagem com poucos códigos quanto no primeiro código. Para ingerir dados em buckets de armazenamento, use o gsutil para tamanhos de dados de até 1 TB. Para ingerir quantidades de dados maiores que 1 TB, use o Serviço de transferência do Cloud Storage.

Usar ferramentas de migração para ingerir de outro armazenamento de dados

Se precisar migrar de outro sistema de armazenamento de dados, como o Teradata, o Netezza ou o Redshift, use a ajuda de migração do serviço de transferência de dados do BigQuery. O serviço de transferência de dados do BigQuery também fornece transferências de terceiros que ajudam a ingerir dados de uma programação de fontes externas. Para mais informações, consulte as abordagens detalhadas de migração para cada armazenamento de dados.

Estimar suas necessidades de ingestão de dados

O volume de dados que você precisa ingerir ajuda a determinar qual serviço usar no design do sistema. Para ingestão de dados de streaming, o Pub/Sub é escalonado para dezenas de gigabytes por segundo. A capacidade, o armazenamento e os requisitos regionais para seus dados ajudam a determinar se o Pub/Sub Lite é uma opção melhor para o design do sistema. Para mais informações, consulte Como escolher o Pub/Sub ou o Pub/Sub Lite.

Para ingestão de dados em lote, estime o total de dados que você quer transferir e a velocidade com que quer fazer isso. Analise as opções de migração disponíveis, incluindo uma estimativa de tempo e uma comparação de transferências on-line e off-line.

Usar ferramentas adequadas para ingerir dados regularmente em uma programação;

Com o Serviço de transferência do Cloud Storage e o Serviço de transferência de dados do BigQuery, é possível programar jobs de ingestão. Para um controle refinado do tempo de ingestão ou do sistema de origem e destino, use um sistema de gerenciamento de fluxo de trabalho como o Cloud Composer. Para uma abordagem mais manual, use o Cloud Scheduler e o Pub/Sub para acionar uma função do Cloud Functions.
Se você quiser gerenciar a infraestrutura do Compute, use o comando gsutil com o cron para a transferência de dados de até 1 TB. Se você usa essa abordagem manual em vez do Cloud Composer, siga as práticas recomendadas para criar scripts de transferências de produção.

Analise as necessidades de ingestão de dados do servidor FTP/SFTP

Se você precisar de um ambiente sem código para ingerir dados de um servidor FTP/SFTP, use os plug-ins de cópia FTP. Se quiser modernizar e criar uma solução de fluxo de trabalho de longo prazo, o Cloud Composer é um serviço totalmente gerenciado que permite ler e gravar em várias origens e coletores.

Usar os conectores do Apache Kafka para ingerir dados

Se você usa Pub/Sub, Dataflow ou BigQuery, pode ingerir dados usando um dos conectores do Apache Kafka. Por exemplo, o conector do Kafka do Pub/Sub de código aberto permite ingerir dados do Pub/Sub ou do Pub/Sub Lite.

Outros recursos

• Práticas recomendadas para agentes do serviço de transferência do Cloud Storage
• Como ingerir dados no BigQuery para poder analisá-los
• Como processar dados clínicos e operacionais com o Cloud Data Fusion
• Como otimizar o processamento de eventos e registros de análise em larga escala

Armazenamento de dados

Aplique as práticas recomendadas de armazenamento de dados a seguir ao seu ambiente.

Escolha o armazenamento de dados adequado para suas necessidades

Para ajudar você a escolher que tipo de solução de armazenamento usar, analise e entenda o uso downstream dos seus dados. Os seguintes casos de uso comuns dos seus dados recomendam qual produto do Google Cloud usar:

Caso de uso de dados	Recomendação de produto
Baseada em arquivo	Filestore
Baseados em objeto	Cloud Storage
Baixa latência	Bigtable
Série temporal	Bigtable
Cache on-line	Memorystore
Processamento de transações	Cloud SQL
Business Intelligence (BI) e análise	BigQuery
Processamento em lote	Cloud Storage Bigtable se os dados de entrada forem séries temporais e você precisar de acesso de baixa latência a eles. BigQuery se você usar SQL.

Analisar as necessidades de estrutura de dados

Para a maioria dos dados não estruturados, como documentos e arquivos de texto, áudio e vídeo ou registros, um armazenamento baseado em objeto é a escolha mais adequada. Em seguida, você pode carregar e processar os dados do armazenamento de objetos quando necessário.

Para dados semiestruturados, como XML ou JSON, seus casos de uso e padrões de acesso a dados ajudam a orientar sua escolha. É possível carregar esses conjuntos de dados no BigQuery para detecção automática de esquema. Se você tiver requisitos de baixa latência, poderá carregar os dados JSON no Bigtable. Se você tem requisitos legados ou seus aplicativos funcionam com bancos de dados relacionais, também é possível carregar conjuntos de dados em um armazenamento relacional.

Para dados estruturados, como CSV, Parquet, Avro ou ORC, você poderá usar o BigQuery se tiver requisitos de BI e análise que usam SQL. Para mais informações, consulte Como carregar dados em lote. Se você quiser criar um data lake em padrões e tecnologias abertos, use o Cloud Storage.

Migrar dados e reduzir custos para o HDFS

Procure maneiras de mover dados do Hadoop Distributed File System (HDFS) do local ou de outro provedor de nuvem para um sistema de armazenamento de objetos mais barato. O Cloud Storage é a opção mais comum que as empresas fazem como um armazenamento de dados alternativo. Para informações sobre as vantagens e desvantagens dessa escolha, consulte HDFS vs. Cloud Storage.

Você pode mover dados com um método push ou pull. Os dois métodos usam o comando hadoop distcp. Para mais informações, consulte Como migrar dados do HDFS no local para o Google Cloud.

Também é possível usar o conector do Cloud Storage (em inglês) de código aberto para permitir que jobs do Hadoop e do Spark acessem dados no Cloud Storage. O conector é instalado por padrão nos clusters do Dataproc e pode ser instalado manualmente em outros clusters.

Use o armazenamento de objetos para criar um data lake coeso

O data lake é um repositório centralizado projetado para armazenar, processar e proteger grandes quantidades de dados estruturados, semiestruturados e não estruturados. É possível usar o Cloud Composer e o Cloud Data Fusion para criar um data lake.

Para criar uma plataforma de dados moderna, é possível usar o BigQuery como sua fonte de dados central em vez do Cloud Storage. O BigQuery é um armazenamento de dados moderno com separação de armazenamento e computação. Um data lake criado no BigQuery permite executar análises tradicionais do BigQuery no Console do Cloud. Ela também permite acessar os dados armazenados de outros frameworks, como o Apache Spark.

Outros recursos

• Práticas recomendadas do Cloud Storage
• Práticas recomendadas para otimização de custos do Cloud Storage
• Práticas recomendadas para garantir a privacidade e a segurança dos seus dados no Cloud Storage
• Práticas recomendadas para o Memorystore
• Como otimizar o armazenamento no BigQuery
• Projeto de esquema do Bigtable

Processar e transformar dados

Aplique as práticas recomendadas de análise de dados a seguir ao seu ambiente quando processar e transformar dados.

Explorar o software de código aberto que é possível usar no Google Cloud

Muitos serviços do Google Cloud usam software de código aberto para facilitar a transição. O Google Cloud oferece soluções gerenciadas e sem servidor que têm APIs abertas e são compatíveis com frameworks de código aberto para reduzir a dependência de um único fornecedor.

O Dataproc é um serviço gerenciado compatível com Hadoop que permite hospedar softwares de código aberto, com pouco ônus operacional. O Dataproc inclui suporte para Spark, Hive, Pig, Presto e Zookeeper. Ele também fornece o Metastore do Hive como um serviço gerenciado para se remover como um ponto único de falha no ecossistema do Hadoop.

É possível migrar para o Dataflow se você usa o Apache Beam como um mecanismo de processamento em lote e de streaming. O Dataflow é um serviço totalmente gerenciado e sem servidor que usa o Apache Beam. Use o Dataflow para gravar jobs no Beam, mas deixe o Google Cloud gerenciar o ambiente de execução.

Se você usa o CDAP como plataforma de integração de dados, é possível migrar para o Cloud Data Fusion para uma experiência totalmente gerenciada.

Determinar as necessidades de processamento de dados ETL ou ELT

A experiência e as preferências da equipe ajudam a determinar o design do sistema para o processamento de dados. O Google Cloud permite usar sistemas de processamento de dados ETL tradicional ou ELT mais moderno (em inglês).

• Para pipelines de ETL, é possível usar o Data Fusion, o Dataproc ou o Dataflow.

  • Para novos ambientes, recomendamos o Dataflow para uma maneira unificada de criar aplicativos em lote e por streaming.
  • Para uma abordagem totalmente gerenciada, o Data Fusion fornece uma GUI de arrastar e soltar para ajudar a criar pipelines.

• Para os pipelines de ELT, use o BigQuery, que é compatível com o carregamento de dados em lote e de streaming. Depois que os dados estiverem no BigQuery, use o SQL para executar todas as transformações e derivar novos conjuntos de dados para os casos de uso dos negócios.

• Se quiser modernizar e migrar do ETL para o ELT, use o Dataform.

Usar a estrutura apropriada para seu caso de uso de dados

Seus casos de uso de dados determinam quais ferramentas e frameworks serão usados. Alguns produtos do Google Cloud são criados para lidar com todos os casos de uso de dados a seguir, enquanto outros são compatíveis apenas com um caso de uso específico.

• Para um sistema de processamento de dados em lote, é possível processar e transformar dados no BigQuery com uma interface SQL familiar. Se você tiver um pipeline atual executado no Apache Hadoop ou Spark no local ou em outra nuvem pública, será possível usar o Dataproc.
  • Também é possível usar o Dataflow se você quiser uma interface de programação unificada para casos de uso em lote e de streaming. Recomendamos modernizar e usar o Dataflow para ETL e BigQuery para ELT.

• Para pipelines de dados de streaming, use um serviço gerenciado e sem servidor, como o Dataflow, que fornece janelas, escalonamento automático e modelos. Para mais informações, consulte Como criar pipelines de dados prontos para produção usando o Dataflow.

  • Se você tiver equipes e recursos focados em análise e SQL, também poderá fazer streaming de dados para o BigQuery.

• Para casos de uso em tempo real, como análise de séries temporais ou análise de streaming de vídeo, use o Dataflow.

Mantenha o controle futuro sobre o mecanismo de execução

Para minimizar a dependência de fornecedores e poder usar uma plataforma diferente no futuro, use o Modelo de programação do Apache Beam e Dataflow como uma solução sem servidor gerenciada. O modelo de programação do Beam permite alterar o mecanismo de execução subjacente, como alterar do Dataflow para Apache Flink ou Apache Spark (em inglês).

Usar o Dataflow para processar dados de várias fontes

Para ingerir dados de várias fontes, como Pub/Sub, Cloud Storage, HDFS, S3 ou Kafka, use o Dataflow. O Dataflow é um serviço gerenciado sem servidor compatível com modelos do Dataflow, que permite às equipes executar modelos de diferentes ferramentas.

O Dataflow Prime oferece escalonamento automático horizontal e vertical de máquinas usadas no processo de execução de um pipeline. Ela também fornece diagnósticos e recomendações inteligentes que identificam problemas e sugerem como corrigi-los.

Descubra, identifique e proteja dados sensíveis

Use a Proteção de dados confidenciais para inspecionar e transformar dados estruturados e não estruturados. A proteção de dados confidenciais funciona para dados localizados em qualquer lugar no Google Cloud, como no Cloud Storage ou em bancos de dados. É possível classificar, mascarar e tokenizar seus dados confidenciais para continuar a usá-los com segurança no processamento downstream. Use a Proteção de dados sensíveis para executar ações como verificar dados do BigQuery ou desidentificar e reidentificar PII em conjuntos de dados de grande escala.

Modernize os processos de transformação de dados

Use o Dataform para gravar transformações de dados como código e começar a usar o controle de versão por padrão. Também é possível adotar práticas recomendadas de desenvolvimento de software, como CI/CD, testes de unidade e controle de versão para o código SQL. O Dataform é compatível com todos os principais produtos e bancos de dados de armazenamento de dados na nuvem, como o PostgreSQL.

Outros recursos

• Dataproc
  • Guia de práticas recomendadas
  • Dicas para clusters de longa duração
  • Como usar o Apache Hive no Dataproc
  • Práticas recomendadas para execução em produção
  • Práticas recomendadas para usar o Apache Ranger
  • Recomendações de configuração de escalonamento automático
  • Ajuda para jobs lentos do Hadoop/Spark
• Dataflow
  • Mover pipelines para produção
  • Casos de uso comuns
• Data Fusion
  • Desempenho do pipeline
• BigQuery
  • Otimizar o desempenho da consulta
• Dataform
  • Práticas recomendadas para gerenciar projetos
• Proteção de dados confidenciais
  • Mantenha os custos sob controle
  • Inspecionar armazenamento e bancos de dados confidenciais
  • Inspecionar texto para dados confidenciais

Análise de dados e armazenamentos

Aplique as seguintes práticas recomendadas de análise de dados e armazenamento ao seu ambiente.

Analisar suas necessidades de armazenamento de dados

Data lakes e armazenamentos de dados não são mutuamente exclusivos. Os data lakes são úteis para armazenamento e processamento de dados não estruturados e semiestruturados. Os armazenamentos de dados são melhores para análise e BI.

Revise as necessidades de dados para determinar onde armazenar os dados e qual produto do Google Cloud é o mais apropriado para processar e analisar os dados. Produtos como o BigQuery podem processar PBs de dados e crescer com suas demandas.

Identificar oportunidades de migrar de um armazenamento de dados tradicional para o BigQuery

Revise os armazenamentos de dados tradicionais que estão em uso atualmente no seu ambiente. Para reduzir a complexidade e possivelmente reduzir os custos, identifique oportunidades de migrar os armazenamentos de dados tradicionais para um serviço do Google Cloud, como o BigQuery. Para mais informações e exemplos de cenários, consulte Como migrar armazenamentos de dados para o BigQuery.

Planejar o acesso federado aos dados

Revise os requisitos de dados e como pode ser necessário interagir com outros produtos e serviços. Identifique as necessidades da federação de dados e crie um design de sistema apropriado.

Por exemplo, o BigQuery permite definir tabelas externas que podem ler dados de outras fontes, como Bigtable, Cloud SQL, Cloud Storage ou Google Drive. É possível mesclar essas fontes externas com tabelas armazenadas no BigQuery.

Usar slots flexíveis do BigQuery para fornecer capacidade de burst sob demanda

Às vezes, você precisa de capacidade extra para fazer análises experimentais ou exploratórias que precisam de muitos recursos de computação. O BigQuery permite receber capacidade extra de computação na forma de slots flexíveis. Esses slots flexíveis ajudam você quando há um período de alta demanda ou quando você quer concluir uma análise importante.

Entender as diferenças de esquema se você migrar para o BigQuery

O BigQuery é compatível com esquemas star e snowflake, mas, por padrão, usa campos aninhados e repetidos. Campos repetidos e aninhados podem ser mais fáceis de ler e correlacionar em comparação com outros esquemas. Se seus dados forem representados em um esquema em estrela ou floco de neve e você quiser migrar para o BigQuery, revise o design do sistema em busca de alterações necessárias nos processos ou na análise.

Outros recursos

• Práticas recomendadas para cargas de trabalho de vários locatários no BigQuery
• Práticas recomendadas para segurança no nível da linha no BigQuery
• Práticas recomendadas para visualizações materializadas no BigQuery

Relatórios e visualização

Aplique as seguintes práticas recomendadas para geração de relatórios e visualização ao seu próprio ambiente.

Usar o BigQuery BI Engine para visualizar seus dados

O BigQuery BI Engine é um serviço rápido de análise na memória. Use o BI Engine para analisar dados armazenados no BigQuery com tempo de resposta de consulta de subsegundos e alta simultaneidade. O BI Engine é integrado à API BigQuery. Use a capacidade reservada do BI Engine para gerenciar os preços sob demanda ou com taxa fixa para suas necessidades. O BI Engine também pode trabalhar com outros aplicativos de painel ou BI que exigem tempos de resposta de subsegundo.

Modernizar seus processos de BI com o Looker

O Looker é uma plataforma empresarial moderna para BI, aplicativos de dados e análise incorporada. Você pode criar modelos de dados consistentes com base nos seus dados com velocidade e precisão, além de acessar dados dentro de armazenamentos de dados transacionais e analíticos. O Looker também pode analisar os dados em vários bancos de dados e nuvens. Se você tiver ferramentas e processos de BI, recomendamos modernizar e usar uma plataforma central, como o Looker.

Outros recursos

• Como migrar o armazenamento de dados para o BigQuery: geração de relatórios e análises
• Arquitetura para conectar software de visualização ao Hadoop no Google Cloud
• Como acelerar consultas pequenas no BigQuery com o BI Engine

Usar ferramentas de gerenciamento de fluxo de trabalho

A análise de dados envolve muitos processos e serviços. Movimentações de dados em diferentes ferramentas e pipelines de processamento durante o ciclo de vida de análise de dados. Para gerenciar e manter pipelines de dados completos, use ferramentas de gerenciamento de fluxo de trabalho apropriadas. O Cloud Composer é uma ferramenta de gerenciamento de fluxo de trabalho totalmente gerenciada com base no projeto de código aberto Apache Airflow.

Use o Cloud Composer para iniciar pipelines do Dataflow e usar modelos de fluxo de trabalho do Dataproc. O Cloud Composer também ajuda a criar um pipeline de CI/CD para testar, sincronizar e implantar DAGs ou usar um pipeline de CI/CD para processamento de dados fluxos de trabalho. Para mais informações, assista às práticas recomendadas de desenvolvimento do Cloud Composer.

Recursos de migração

Se você já executa uma plataforma de análise de dados e quer migrar algumas ou todas as cargas de trabalho para o Google Cloud, revise os seguintes recursos de migração para conhecer as práticas recomendadas e orientações:

• Diretrizes gerais de migração
  • Migração para o Google Cloud: como escolher seu caminho de migração.
  • Exemplo de modernização da plataforma de análise de engajamento de anúncios do Twitter
• Migração do Cloud Storage
  • Como migrar dados do HDFS do local para o Google Cloud.
  • Como transferir os dados do Amazon S3 para o Cloud Storage usando o VPC Service Controls e o Serviço de transferência do Cloud Storage.
• Migração do Pub/Sub
  • Migração do Kafka para o Pub/Sub.
• Migração do Bigtable
  • Como migrar dados do HBase para o Bigtable.
  • Migração do Aerospike para o Bigtable.
• Migração do Dataproc
  • Como migrar a infraestrutura no local do Hadoop para o Google Cloud.
  • Custos e dicas de migração do Hadoop.
  • Hadoop para Dataproc
  • Jobs do Hadoop locais para o Dataproc.
  • Apache Spark para Dataproc
  • Metastore Hive externo para o metastore do Dataproc.
• Migração do BigQuery
  • Desafios legados da migração do armazenamento de dados.
  • Como migrar armazenamentos de dados para o BigQuery.
  • BigQuery para profissionais de armazenamento de dados.
• Migração do Composer
  • Migre ambientes para o Airflow 2.

A seguir

Conheça as práticas recomendadas de design de sistema para IA do Google Cloud e machine learning, incluindo as seguintes:

• Saiba mais sobre serviços de IA do Google Cloud e machine learning compatíveis com o design de sistemas.
• Conheça as práticas recomendadas de processamento de dados de ML.
• Conheça as práticas recomendadas para o desenvolvimento e treinamento de modelos.

Explore outras categorias no Framework de arquitetura, como confiabilidade, excelência operacional e segurança, privacidade e conformidade.

Implementar o aprendizado de máquina

Neste documento, o framework de arquitetura do Google Cloud explica alguns dos princípios básicos e práticas recomendadas para análise de dados no Google Cloud. Você aprenderá sobre alguns dos principais serviços de IA e machine learning (ML) e como eles podem ajudar durante os vários estágios do ciclo de vida de IA e ML. Essas práticas recomendadas ajudam você a atender às suas necessidades de IA e ML, além de criar o design do sistema. Para seguir este documento, é necessário ter familiaridade com os conceitos básicos de IA e ML.

Para simplificar o processo de desenvolvimento e minimizar a sobrecarga ao criar modelos de ML no Google Cloud, considere o nível mais alto de abstração que faça sentido para seu caso de uso. O nível de abstração é definido como a quantidade de complexidade com que um sistema é visualizado ou programado. Quanto maior o nível de abstração, menos detalhes estarão disponíveis para o espectador.

Para selecionar os serviços de IA e ML do Google com base nas necessidades da sua empresa, use a tabela a seguir:

Perfil	Serviços do Google
Usuários comerciais	Soluções padrão, comoContact Center AI Insights ,Document AI .Discovery AI eAPI Cloud Healthcare.
Desenvolvedores com experiência mínima em ML	As APIs pré-treinadas abordam tarefas perceptivas comuns como visão, vídeo e linguagem natural. Essas APIs são compatíveis com modelos pré-treinados e fornecem detectores padrão. Elas estão prontas para uso sem experiência com ML ou com o esforço de desenvolvimento de modelos. As APIs pré-treinadas incluem: API Vision, API Video, API Natural Language, API Speech-to-Text, API Text-to-Speech e API Cloud Translation.
IA generativa para desenvolvedores	A ferramenta Vertex AI para Pesquisa e Conversação permite que os desenvolvedores usem recursos prontos para uso para criar e implantar bots de chat em minutos e mecanismos de pesquisa em horas. Os desenvolvedores que quiserem combinar múltiplos recursos em fluxos de trabalho corporativos podem usar a API Gen App Builder para integração direta.
Desenvolvedores e cientistas de dados	O AutoML permite fazer o desenvolvimento de modelos personalizados com dados próprios de imagem, vídeo, texto ou tabela. O AutoML acelera o desenvolvimento de modelos com pesquisa automática por meio do modelo Google para a arquitetura de modelo com melhor desempenho. Assim, você não precisa criar o modelo. O AutoML processa tarefas comuns para você, como escolher uma arquitetura de modelo, ajuste de hiperparâmetro, provisionar máquinas para treinamento e disponibilização.
Cientistas de dados e engenheiros de ML	As ferramentas de modelos personalizados da Vertex AI permitem treinar e exibir modelos personalizados e operacionalizar o fluxo de trabalho de ML. Também é possível executar sua carga de trabalho de ML em computadores autogerenciados, como VMs do Compute Engine.
Cientistas de dados e engenheiros de machine learning	O suporte de IA generativa na Vertex AI (também conhecido como genai) oferece acesso aos grandes modelos de IA generativa do Google para que você possa testar, ajustar e implantá-los nos aplicativos com tecnologia de IA.
Engenheiros de dados, cientistas e analistas de dados familiarizados com as interfaces SQL	O BigQuery ML permite desenvolver modelos baseados em SQL com base em dados armazenados no BigQuery.

Principais serviços

Veja na tabela a seguir uma visão geral dos serviços de IA e ML:

Serviço do Google	Descrição
Cloud Storage e BigQuery	Forneça opções de armazenamento flexíveis para dados e artefatos de machine learning.
BigQuery ML	Permite criar modelos de machine learning diretamente de dados armazenados no BigQuery.
Pub/Sub, Dataflow, Cloud Data Fusion e Dataproc	Compatibilidade com a ingestão e o processamento de dados em lote e em tempo real. Para mais informações, consulte Análise de dados.
Vertex AI	Oferece aos cientistas de dados e engenheiros de machine learning uma única plataforma para criar, treinar, testar, monitorar, ajustar e implantar modelos de ML para tudo, de IA generativa até MLOps. As ferramentas incluem o seguinte: Rotulagem de dados da Vertex para obter rótulos de dados precisos. Contêineres de aprendizado profundo (em inglês) para criar e implantar modelos em um ambiente portátil e consistente. Vertex AI Workbench para um ambiente de JupyterLab gerenciado ou gerenciado pelo usuário. Vertex Training para um serviço de treinamento totalmente gerenciado. Vertex AI TensorBoard para rastreamento experimental. Vertex AI Vizier (em inglês) para ajuste de hiperparâmetros. Vertex Prediction para um framework de implantação unificado compatível com modelos de treinamento personalizado, BigQuery ML e AutoML. Vertex Explainable AI para apresentar explicações para previsões de modelo. Experimentos da Vertex para acelerar a implantação de modelos na produção. Agora, com uma seleção de modelos mais rápida. Ferramentas de MLOps, como o Vertex AI Pipelines, para orquestração e a Vertex Feature Store, para um repositório de recursos totalmente gerenciado.
Vertex AI para Pesquisa e Conversação	Permite criar chatbots e mecanismos de pesquisa para sites e para uso em dados corporativos. A IA de conversação na Vertex AI para Pesquisa e Conversação pode ajudar a reinventar as interações de clientes e funcionários com assistentes digitais e bots de chat com IA generativa. Por exemplo, com essas ferramentas, é possível fornecer mais do que apenas informações, ativando as transações na experiência de chat. O Vertex AI para Pesquisa e Conversação empresarial permite que as empresas criem experiências de pesquisa para clientes e funcionários em sites públicos ou privados. Além de fornecer resultados de pesquisa multimodais de alta qualidade, a Pesquisa corporativa pode resumir os resultados e fornecer citações correspondentes com IA generativa.
IA generativa na Vertex AI	Oferece acesso aos grandes modelos de IA generativa do Google para que você possa testar, ajustar e implantá-los para uso nos seus aplicativos com tecnologia de IA. A IA generativa na Vertex AI também é conhecida como genai. Os modelos de IA generativa, também conhecidos como modelos de fundação, são categorizados pelo tipo de conteúdo que eles são projetados para gerar. Esse conteúdo inclui embeddings de texto e chat, imagem, código e texto. O Vertex AI Studio permite prototipar e testar rapidamente modelos de IA generativa no console do Google Cloud. É possível testar comandos de amostra, projetar seus comandos e personalizar modelos de fundação para lidar com tarefas que atendam às necessidades do aplicativo. Ajuste de modelos: permite personalizar modelos de fundação para casos de uso específicos, ajustando-os com um conjunto de dados de exemplos de entrada e saída. Model Garden oferece modelos de fundação empresariais, modelos de tarefas específicos e APIs.
APIs pré-treinadas	As APIs pré-treinadas incluem API Vision, API Video, API Natural Language, API Speech-to-Text, API Text-to-Speech e API Cloud Translation.
AutoML	Fornece ferramentas de modelos personalizados para criar, implantar e escalonar modelos de ML. Os desenvolvedores podem fazer upload dos próprios dados e usar o serviço AutoML aplicável para criar um modelo personalizado. AutoML Image: executa a classificação de imagens e a detecção de objetos em dados de imagem. AutoML Video: executa a detecção de objetos, a classificação e o reconhecimento de ações em dados de vídeo. AutoML Text: realiza classificação de linguagem, extração de entidade e análise de sentimento em dados de texto. AutoML Translation: detecta e traduz entre pares de idiomas. AutoML Tabular: permite criar um modelo de regressão, classificação ou previsão. Destinado a dados estruturados.
Infraestrutura de IA	Permite usar aceleradores de IA para processar cargas de trabalho de ML em grande escala. Esses aceleradores permitem que você treine e faça inferências nos modelos de aprendizado profundo e nos modelos de machine learning de maneira econômica. As GPUs podem ajudar com treinamento econômico de inferência e escalonamento vertical ou horizontal para modelos de aprendizado profundo. As Unidades de Processamento de Tensor (TPUs) são um ASIC criado especialmente para treinar e executar redes neurais profundas.
Dialogflow	Entrega agentes virtuais que proporcionam uma experiência de conversa.
Contact Center AI	Oferece uma experiência automatizada e central de insights com a funcionalidade Agent Assist para agentes humanos.
Document AI	Oferece compreensão de documentos em escala para documentos em geral e para tipos de documentos específicos, como relacionados a empréstimos e compras.
Lending DocAI	Automatiza o processamento de documentos hipotecários. Reduz o tempo de processamento e otimiza a captura de dados, além de oferecer suporte a requisitos regulamentares e de conformidade.
Procurement DocAI	Automatize a captura de dados de compras em escala, transformando documentos não estruturados, como faturas e comprovantes, em dados estruturados para aumentar a eficiência operacional, melhorar a experiência do cliente e tomar decisões fundamentadas em análises métricas.
Recomendações	Entrega recomendações de produtos personalizadas.
Healthcare Natural Language AI	Permite analisar e analisar documentos médicos.
API Media Translation	Permite a tradução de fala em tempo real a partir de dados de áudio.

Processamento de dados

Aplique as seguintes práticas recomendadas de processamento de dados ao seu ambiente.

Verifique se os dados atendem aos requisitos de ML

Os dados usados para ML precisam atender a determinados requisitos básicos, independentemente do tipo de dados. Esses requisitos incluem a capacidade dos dados de prever a meta, a consistência de granularidade entre os dados usados para treinamento e os dados usados na previsão, bem como os dados rotulados com precisão para treinamento. Seus dados também precisam ter volume suficiente. Para mais informações, consulte Processamento de dados.

Armazene dados tabulares no BigQuery

Se você usa dados tabulares, considere armazenar todos eles no BigQuery e usar a API BigQuery Storage para ler dados deles. Para simplificar a interação com a API, use uma das seguintes opções de ferramentas, dependendo de onde você quer ler os dados:

• Se você usa o Dataflow, use o conector de E/S do BigQuery.
• Caso você use o TensorFlow ou o Keras, use o leitor de tf.data.dataset para BigQuery.
• Se você usar dados não estruturados, como imagens ou vídeos, armazene todos eles no Cloud Storage.

O tipo de dados de entrada também determina as ferramentas de desenvolvimento de modelo disponíveis. APIs pré-treinadas, AutoML e BigQuery ML podem fornecer ambientes de desenvolvimento mais econômicos e econômicos para certos casos de uso de imagem, vídeo, texto e dados estruturados.

Verifique se você tem dados suficientes para desenvolver um modelo de ML

Para desenvolver um modelo de ML útil, é preciso ter dados suficientes. Para prever uma categoria, o número recomendado de exemplos para cada categoria é 10 vezes o número de recursos. Quanto mais categorias você quiser prever, mais dados serão necessários. Conjuntos de dados desbalanceados exigem ainda mais dados. Se não houver dados rotulados suficientes disponíveis, pense no aprendizado semi-supervisionado.

O tamanho do conjunto de dados também tem implicações no treinamento e na disponibilização: se você tiver um conjunto de dados pequeno, poderá treiná-lo diretamente em uma instância de notebooks. Caso você tenha conjuntos de dados maiores que exijam distribuição distribuída treinamento, use o serviço de treinamento personalizado Vertex AI. Se você quiser que o Google treine o modelo para seus dados, use o AutoML.

Preparar dados para consumo

Ter dados bem preparados pode acelerar o desenvolvimento de modelos. Ao configurar o pipeline de dados, verifique se ele pode processar dados em lote e em streaming para que você receba resultados consistentes dos dois tipos de dados.

Desenvolvimento e treinamento de modelos

Aplique as práticas recomendadas de desenvolvimento e treinamento de modelos a seguir ao seu próprio ambiente.

Escolher o desenvolvimento de modelos gerenciados ou personalizados

Ao criar seu modelo, pense no mais alto nível de abstração possível. Use o AutoML sempre que possível para que as tarefas de desenvolvimento e treinamento sejam processadas para você. Para modelos treinados de forma personalizada, escolha as opções gerenciadas para escalonabilidade e flexibilidade, em vez de opções autogerenciadas. Para saber mais sobre as opções de desenvolvimento de modelo, consulte Usar ferramentas e produtos recomendados.

Considere o serviço de treinamento Vertex AI em vez do treinamento autogerenciado nas VMs do Compute Engine ou no Deep Aprenda sobre contêineres de VM. Para um ambiente JupyterLab, considere o Vertex AI Workbench, que oferece ambientes JupyterLab gerenciados pelo usuário e gerenciados. Para mais informações, consulte Desenvolvimento de machine learning e Treinamento operacional.

Usar contêineres pré-criados ou personalizados para modelos treinados de forma personalizada

Para modelos treinados de forma personalizada no Vertex AI, é possível usar contêineres pré-criados ou personalizados, dependendo do framework e da versão do machine learning. Contêineres pré-criados estão disponíveis para aplicativos de treinamento em Python criados para versões específicas do TensorFlow, scikit-learn, PyTorch e XGBoost.

Caso contrário, crie um contêiner personalizado para o job de treinamento. Por exemplo, use um contêiner personalizado se quiser treinar seu modelo usando um framework do Python ML que não está disponível em um contêiner predefinido ou se quiser treinar usando uma linguagem de programação diferente do Python de dados. No contêiner personalizado, pré-instale o aplicativo de treinamento e todas as respectivas dependências em uma imagem que executa o job de treinamento.

Considere os requisitos de treinamento distribuído

Considere seus requisitos de treinamento distribuído. Alguns frameworks de ML, como o TensorFlow e o PyTorch, permitem executar códigos de treinamento idênticos em várias máquinas. Esses frameworks coordenam automaticamente a divisão do trabalho com base em variáveis de ambiente definidas em cada máquina. Outros frameworks podem exigir outras personalizações.

A seguir

Para mais informações sobre IA e machine learning, consulte:

• Práticas recomendadas para implementar machine learning no Google Cloud.
• Guia para profissionais de MLOps: uma estrutura para entrega e automação contínua de machine learning.

Explore outras categorias no Framework de arquitetura, como confiabilidade, excelência operacional e segurança, privacidade e conformidade.

Design sustentável

Neste documento, no framework de arquitetura do Google Cloud, resumimos como abordar a sustentabilidade ambiental das suas cargas de trabalho no Google Cloud. Ele inclui informações sobre como minimizar sua pegada de carbono no Google Cloud.

Entenda sua pegada de carbono

Para entender a pegada de carbono do uso do Google Cloud, use o painel Carbon Footprint. O painel do Carbon Footprint atribui emissões aos seus projetos do Google Cloud e aos serviços em nuvem que você usa.

Para mais informações, consulte Entender sua pegada de carbono em "Reduzir sua pegada de carbono do Google Cloud".

Escolha as regiões de nuvem mais adequadas

Uma maneira simples e eficaz de reduzir as emissões de carbono é escolher as regiões de nuvem com menos emissões. Para ajudar você nessa escolha, o Google publica dados de carbono em todas as regiões do Google Cloud.

Ao escolher uma região, talvez seja necessário equilibrar as emissões com outros requisitos, como preços e latência de rede. Para ajudar a selecionar uma região, use o Seletor de região do Google Cloud.

Para mais informações, consulte Escolher as regiões de nuvem mais adequadas em "Reduzir sua pegada de carbono do Google Cloud".

Escolha os serviços de nuvem mais adequados

Para reduzir a pegada de carbono atual, migre suas cargas de trabalho de VM locais para o Compute Engine.

Considere também que muitas cargas de trabalho não exigem VMs. Em geral, é possível usar uma oferta sem servidor. Esses serviços gerenciados podem otimizar o uso de recursos da nuvem, geralmente de maneira automática, o que reduz os custos da nuvem e a emissão de carbono ao mesmo tempo.

Para mais informações, consulte Escolher os serviços de nuvem mais adequados em "Reduzir sua pegada de carbono do Google Cloud".

Minimize os recursos inativos da nuvem

Os recursos inativos geram custos e emissões desnecessários. Estas são algumas causas comuns de recursos inativos:

• Recursos de nuvem ativos e não utilizados, como instâncias de VM inativas.
• Recursos com provisionamento excessivo, como tipos de máquinas de instâncias de VM maiores que o necessário para uma carga de trabalho.
• Arquiteturas não ideais, como migrações de migrações lift-and-shift, que nem sempre são otimizadas para eficiência. Faça melhorias incrementais nessas arquiteturas.

Veja a seguir algumas estratégias gerais para ajudar a minimizar o desperdício de recursos de nuvem:

• Identifique recursos inativos ou em excesso e exclua-os ou redimensione-os.
• Refatore sua arquitetura para incorporar um design mais otimizado.
• Migre cargas de trabalho para serviços gerenciados.

Para mais informações, consulte Minimizar recursos de nuvem inativa em "Reduzir sua pegada de carbono do Google Cloud".

Reduza emissões para cargas de trabalho em lote

Execute cargas de trabalho em lote em regiões com menores emissões de carbono. Para outras reduções, execute cargas de trabalho em momentos que correspondam a intensidade de carbono de grade menor, quando possível.

Para mais informações, consulte Reduzir emissões para cargas de trabalho em lote em "Reduzir sua pegada de carbono do Google Cloud".

A seguir

• Saiba como usar os dados de emissão de carbono para medir, informar e reduzir suas emissões de carbono na nuvem.
• Saiba como reduzir sua pegada de carbono do Google Cloud.

Estrutura de arquitetura do Google Cloud: excelência operacional

Esta categoria no Framework da arquitetura do Google Cloud mostra como operar serviços de maneira eficiente no Google Cloud. Ele discute como executar, gerenciar e monitorar sistemas que agregam valor aos negócios. Ele também discute os produtos e recursos do Google Cloud compatíveis com a excelência operacional. O uso dos princípios de excelência operacional ajuda a criar uma base para confiabilidade. Isso é feito com a configuração de elementos básicos, como observabilidade, automação e escalonabilidade.

Neste framework de arquitetura, descrevemos as práticas recomendadas, fornecemos recomendações de implementação e explicamos alguns produtos e serviços disponíveis que ajudam a alcançar a excelência operacional. O objetivo é ajudar você a projetar sua implantação do Google Cloud para que ele corresponda às necessidades da sua empresa.

Na categoria "Excelência operacional" do Framework de arquitetura, você aprende a fazer o seguinte:

• Automatize as implantações
• Configurar o monitoramento, os alertas e a geração de registros
• Estabelecer processos de suporte e escalonamento na nuvem
• Gerenciar capacidade e cota
• Planejar o pico de tráfego e eventos de lançamento
• Crie uma cultura de automação

Automatize as implantações

Este documento no Framework da arquitetura do Google Cloud fornece as práticas recomendadas para automatizar suas compilações, testes e implantações.

A automação ajuda a padronizar builds, testes e implantações eliminando erros induzidos por humanos para processos repetidos, como atualizações de código. Nesta seção, descrevemos como usar várias verificações e proteções durante a automação. Um processo padronizado e controlado por máquina ajuda a garantir a implantação segura das implantações. Ele também fornece um mecanismo para restaurar implantações anteriores conforme necessário, sem afetar significativamente a experiência do usuário.

Armazenar o código em repositórios de códigos centrais

Armazene o código em repositórios de código centrais que incluam um sistema de controle de versões com inclusão de tags e a capacidade de reverter as alterações no código. O controle de versões permite organizar arquivos e controlar o acesso, as atualizações e as exclusões em equipes e organizações.

Para diferentes estágios de desenvolvimento, controle a versão e rotule os repositórios conforme necessário. Por exemplo, os rótulos podem ser test, dev e prod.

No Google Cloud, é possível armazenar o código no Cloud Source Repositories, criar versões e integrá-las a outros produtos do Google Cloud. Se você estiver criando aplicativos em contêineres, use o Artifact Registry, um registro gerenciado para contêineres.

Para saber mais sobre o controle de versões, consulte Controle de versões. Para mais detalhes sobre como implementar o desenvolvimento baseado em linha principal com seus repositórios, consulte Desenvolvimento baseado em linha principal.

Use integração e implantação contínuas (CI/CD)

Automatize as implantações usando uma abordagem de integração e implantação contínuas (CI/CD). Uma abordagem de CI/CD é uma combinação de pipelines configurados e processados e seguidos pela equipe de desenvolvimento.

Uma abordagem de CI/CD aumenta a velocidade de implantação ao aumentar a produtividade da equipe de desenvolvimento de software. Essa abordagem permite que os desenvolvedores façam alterações menores e mais frequentes que são testadas completamente, reduzindo o tempo necessário para implantar essas alterações.

Como parte da abordagem de CI/CD, automatize todas as etapas que fazem parte da criação, teste e implantação do código. Exemplo:

• Sempre que um novo código for confirmado no repositório, faça com que a confirmação invoque automaticamente o pipeline de criação e teste.
• Automatize testes de integração.
• Automatize a implantação para que as alterações sejam implantadas após o build atender a critérios de teste específicos.

No Google Cloud, é possível usar o Cloud Build e o Cloud Deploy para os pipelines de CI/CD.

Use o Cloud Build para ajudar a definir dependências e versões que podem ser usadas para empacotar e criar um pacote de aplicativo. Controle a versão da sua configuração de compilação para garantir que todos os seus builds sejam consistentes e para garantir que você possa reverter para uma configuração anterior, se necessário.

Use o Cloud Deploy para implantar seus aplicativos em ambientes específicos do Google Cloud e gerenciar seus pipelines de implantação.

Para mais detalhes sobre como implementar CI/CD, consulte Integração contínua e Automação da implantação.

Provisione e gerencie sua infraestrutura usando infraestrutura como código

Infraestrutura como código é o uso de um modelo descritivo para gerenciar infraestrutura, como VMs, e configurações, como regras de firewall. A infraestrutura como código permite que você faça o seguinte:

• Crie seus recursos de nuvem automaticamente, incluindo os ambientes de implantação ou teste do pipeline de CI/CD.
• Trate as mudanças de infraestrutura como as alterações do aplicativo. Por exemplo, certifique-se de que as alterações na configuração sejam revisadas, testadas e possam ser auditadas.
• Ter uma única versão das informações para a infraestrutura em nuvem;
• Replique seu ambiente de nuvem conforme necessário.
• Reverta para uma configuração anterior, se necessário.

Esse conceito de infraestrutura como código também se aplica a projetos no Google Cloud. Essa abordagem pode ser usada para definir recursos, como conectividade de VPC compartilhada ou acesso ao Identity and Access Management (IAM) nos seus projetos. Para conferir um exemplo dessa abordagem, consulte o módulo do Terraform de fábrica do projeto do Google Cloud.

Ferramentas de terceiros, como o Terraform, ajudam você a criar sua infraestrutura no Google Cloud automaticamente. Para mais informações, consulte Como gerenciar a infraestrutura como código com o Terraform, o Cloud Build e o GitOps.

Avalie o uso de recursos do Google Cloud, como garantias de projeto, políticas de retenção do Cloud Storage e bloqueios de buckets do Cloud Storage para impedir que recursos críticos sejam excluídos de maneira acidental ou mal-intencionada.

Incorpore testes durante todo o ciclo de vida da entrega de software

Os testes são essenciais para o lançamento do seu software. O teste contínuo ajuda as equipes a criar softwares de alta qualidade com mais rapidez e a melhorar a estabilidade do software.

Tipos de teste:

• Testes de unidade. Eles são rápidos e realizam implantações com eficiência. Trate os testes de unidade como parte do codebase e inclua-os como parte do processo de compilação.
• Testes de integração. Eles são importantes, especialmente para cargas de trabalho projetadas para escalonamento e que dependem de mais de um serviço. Esses testes podem ficar complexos quando você testa a integração com serviços interconectados.
• Teste do sistema. Eles são demorados e complexos, mas identificam casos extremos e corrigir problemas antes da implantação.
• Outros testes. Há outros testes que você precisa executar, incluindo testes estáticos, de carga, de segurança, de validação de políticas e outros. Faça esses testes antes de implantar o aplicativo na produção.

Para incorporar testes:

• execute todos os tipos de testes continuamente durante todo o ciclo de vida da entrega de software;
• automatize esses testes e os inclua no pipeline de CI/CD; faça com que o pipeline falhe se qualquer um dos testes falhar;
• atualize e adicione novos testes continuamente para melhorar e manter a integridade operacional da implantação;

Para seus ambientes de teste:

• usar projetos separados do Google Cloud para cada ambiente de teste; para cada aplicativo, use um ambiente de projeto separado. Essa separação fornece uma demarcação clara entre os recursos do ambiente de produção e os recursos dos ambientes inferiores. Essa separação ajuda a garantir que as alterações em um ambiente não afetem acidentalmente outros ambientes.
• Automatizar a criação de ambientes de teste. Uma maneira de fazer isso é usar a infraestrutura como código.
• Usar um ambiente de produção sintético para testar as alterações. Esse ambiente é semelhante à produção para testar o aplicativo e realizar vários tipos de testes nas cargas de trabalho, incluindo testes completos e de desempenho.

Para mais informações sobre como implementar testes contínuos, consulte Automação de teste.

Lance implantações gradualmente

Escolha sua estratégia de implantação com base em parâmetros importantes, como interrupção mínima de usuários finais, atualizações graduais, estratégias de reversão e testes A/B. Para cada carga de trabalho, avalie esses requisitos e escolha uma estratégia de implantação com técnicas comprovadas, como atualizações graduais, implantações azul-verde e implantações canário.

Deixe que os processos de CI/CD só façam e enviem alterações em seu ambiente de produção.

Considere usar uma infraestrutura imutável. Uma infraestrutura imutável é não alterada ou atualizada. Quando for necessário implantar um novo código ou alterar qualquer outra configuração no ambiente, substitua todo o ambiente (uma coleção de VMs ou pods, por exemplo) pelo novo ambiente. As implantações azul-verde são um exemplo de infraestrutura imutável.

Recomendamos que você faça testes canário e observe se há erros no sistema conforme implantar as alterações. Esse tipo de observação é mais fácil se você tiver um sistema robusto de monitoramento e alerta. Para realizar testes A/B ou canário, use os grupos de instâncias gerenciadas do Google Cloud. Dessa forma, será possível fazer um lançamento lento ou uma restauração, se necessário.

Use o Cloud Deploy para automatizar implantações e gerenciar o pipeline de implantação. Você também pode usar muitas ferramentas de terceiros, como o Spinnaker e o Tekton, no Google Cloud para implantações automatizadas e para criar pipelines de implantação. de dados.

Restaurar versões anteriores sem problemas

Defina sua estratégia de restauração como parte da estratégia de implantação. Certifique-se de reverter uma implantação ou uma configuração de infraestrutura para uma versão anterior do código-fonte. Restaurar uma implantação estável anterior é uma etapa importante no gerenciamento de incidentes de incidentes de confiabilidade e segurança.

Verifique também se é possível restaurar o ambiente para o estado em que ele estava antes do processo de implantação ser iniciado. Isso inclui:

• A capacidade de reverter mudanças de código no aplicativo.
• A capacidade de reverter quaisquer alterações de configuração feitas no ambiente.
• Uso de infraestrutura imutável e garantia de que as implantações não mudem o ambiente. Essas práticas facilitam a reversão das alterações de configuração.

Monitore seus pipelines de CI/CD

Para manter seu processo automatizado de criação, teste e implantação em execução sem problemas, monitore seus pipelines de CI/CD. Defina alertas que indiquem quando algo em qualquer pipeline falha. Cada etapa do pipeline precisa escrever log statements adequados para que a equipe possa realizar uma análise de causa raiz se um pipeline falhar.

No Google Cloud, todos os serviços de CI/CD são integrados ao Google Cloud Observability. Exemplo:

• O Cloud Source Repositories é integrado ao serviço do Pub/Sub.
• O Cloud Build é integrado ao Pub/Sub e também armazena registros de auditoria e registros de criação. É possível definir alertas para determinadas palavras-chave nos registros de criação e para muitas outras métricas usando o serviço Cloud Monitoring.
• O Cloud Deploy armazena registros de auditoria.

Para detalhes sobre monitoramento e geração de registros, consulte Configurar o monitoramento, os alertas e a geração de registros.

Implante aplicativos com segurança

Revise a seção Implantar aplicativos com segurança da categoria de segurança, conformidade e privacidade do framework de arquitetura.

Estabelecer diretrizes de gerenciamento para as versões

Para ajudar os engenheiros a cometer erros e permitir a entrega de software em alta velocidade, verifique se as diretrizes de gerenciamento para o lançamento de novas versões de software estão claramente documentadas.

Os engenheiros de lançamento supervisionam a criação e a entrega de software. O sistema de engenharia de versões é guiado por quatro práticas:

• Modo de autoatendimento. Estabeleça diretrizes para ajudar os engenheiros de software a evitar erros comuns. Essas diretrizes geralmente são codificadas em processos automatizados.

• Lançamentos frequentes. A alta velocidade soluciona problemas e facilita a correção de problemas. Os lançamentos frequentes dependem de testes de unidade automatizados.

• Builds herméticos. Use ferramentas de compilação para garantir a consistência. Controle as versões de compiladores de build para criar versões atuais e compará-las com as de um mês atrás.

• Aplicação da política. Todas as alterações precisam de revisão de código. O ideal é que incluam um conjunto de diretrizes e políticas para reforçar a segurança. A aplicação de políticas melhora a revisão de código, a solução de problemas e o teste de uma nova versão.

A seguir

• Configurar monitoramento, alertas e geração de registros (próximo documento desta série)
• Implante aplicativos com segurança na categoria "Segurança", "Compliance" e "Privacidade" do framework de arquitetura
• Revise as práticas recomendadas para criar contêineres .
• Saiba mais sobre recursos técnicos
• Explore outras categorias no Framework da arquitetura, como design do sistema, segurança, privacidade e conformidade, confiabilidade, otimização de custos e otimização de desempenho.

Configurar o monitoramento, os alertas e a geração de registros

Este documento no Framework da arquitetura do Google Cloud mostra como configurar o monitoramento, os alertas e a geração de registros para que você possa agir com base no comportamento do seu sistema. Isso inclui identificar métricas significativas para rastrear e criar painéis para facilitar a visualização de informações sobre seus sistemas.

O programa de pesquisa DevOps Resource and Assessment (DORA) define o monitoramento como:

"Monitoramento é o processo de coleta, análise e uso de informações para acompanhar aplicativos e infraestrutura, permitindo orientar as decisões de negócios. O monitoramento é um recurso importante, porque fornece informações sobre seus sistemas e trabalho."

O Monitoring permite que os proprietários de serviços:

• Tome decisões embasadas quando as mudanças no serviço afetarem o desempenho
• Aplicar uma abordagem científica à resposta a incidentes
• Avaliar o alinhamento do seu serviço com as metas de negócios

Com o monitoramento, a geração de registros e os alertas ativados, é possível fazer o seguinte:

• analisar tendências de longo prazo;
• comparar experiências ao longo do tempo;
• definir alertas sobre métricas importantes;
• criar painéis relevantes em tempo real;
• realizar análises retroativas;
• monitorar métricas de negócios e de integridade do sistema
  • As métricas de negócios ajudam a entender o suporte que os sistemas oferecem ao seu negócio. Por exemplo, use métricas para monitorar os seguintes elementos:
    • O custo de um aplicativo para atender a um usuário
    • Mudança no volume de tráfego do site após uma reformulação
    • Quanto tempo leva para um cliente comprar um produto no seu site
  • As métricas de integridade do sistema ajudam a entender se os sistemas estão funcionando corretamente e dentro de níveis de desempenho aceitáveis.

Use os quatro sinais de ouro a seguir para monitorar seu sistema:

• Latência. O tempo necessário para atender uma solicitação.
• Tráfego. Quanto está sendo demandado do seu sistema.
• Erros. A taxa de solicitações que falham. A falha pode ser explícita (por exemplo, HTTP 500s), implícita (por exemplo, uma resposta de sucesso HTTP 200 acoplada ao conteúdo errado) ou por política (por exemplo, se você se comprometer com uma resposta de um-segundo, qualquer solicitação acima de um segundo será um erro).
• Saturação. A capacidade do serviço. Saturação é uma medida da fração do sistema, enfatizando os recursos mais restritos (ou seja, em um sistema restrito a memória, mostre memória em um sistema restrito por E/S, mostre I/O).

Criar um plano de monitoramento

Crie um plano de monitoramento que esteja alinhado à missão e à estratégia de operações da sua organização. Incluir planejamento de monitoramento e observabilidade durante o desenvolvimento do aplicativo. A inclusão de um plano de monitoramento no início do desenvolvimento do aplicativo pode levar uma organização a alcançar a excelência operacional.

Inclua os seguintes detalhes no plano de monitoramento:

• Inclua todos os seus sistemas, incluindo recursos locais e na nuvem.
• Inclua o monitoramento dos custos da nuvem para garantir que o escalonamento de eventos não faça com que o uso ultrapasse os limites do orçamento.
• Crie diferentes estratégias de monitoramento para medir o desempenho da infraestrutura, a experiência do usuário e os indicadores principais de desempenho (KPIs, na sigla em inglês) do negócio. Por exemplo, limites estáticos podem funcionar bem para medir o desempenho da infraestrutura, mas não refletem verdadeiramente a experiência do usuário.

Atualize o plano de acordo com as estratégias de monitoramento. Repetir o plano para melhorar a integridade dos sistemas.

Definir métricas que avaliam todos os aspectos da organização

Defina as métricas necessárias para medir o comportamento da implantação. Para fazer isso, siga estas etapas:

• Defina seus objetivos de negócio.
• Identifique as métricas e os KPIs que podem fornecer informações quantificáveis para medir o desempenho. Certifique-se de que suas definições de métrica sejam traduzidas para todos os aspectos da sua organização, de necessidades empresariais a custos técnicos, incluindo custos de nuvem.
• Use essas métricas para criar indicadores de nível de serviço (SLIs) para os aplicativos. Para mais informações, consulte Escolher SLIs apropriadas.

Métricas comuns para vários componentes

As métricas são geradas em todos os níveis do serviço, desde infraestrutura e rede até lógica de negócios. Exemplo:

• Métricas de infraestrutura:
  • Estatísticas de máquina virtual, incluindo instâncias, CPU, memória, utilização e contagens
  • Estatísticas baseadas em contêiner: incluindo utilização de cluster, capacidade de cluster, utilização de nível de pod e contagens.
  • Estatísticas de rede, incluindo entrada/saída, largura de banda entre componentes, latência e capacidade
  • Solicitações por segundo, conforme medido pelo balanceador de carga.
  • Total de blocos de disco lidos por disco.
  • Pacotes enviados por uma determinada interface de rede.
  • Tamanho do heap de memória para um determinado processo.
  • Distribuição de latências de resposta.
  • Número de consultas inválidas rejeitadas por uma instância de banco de dados.
• Métricas de aplicação:
  • Comportamento específico do aplicativo, incluindo consultas por segundo, gravações por segundo e mensagens enviadas por segundo
• Métricas de estatísticas de serviços gerenciados:
  • QPS, capacidade de processamento, latência e utilização para serviços gerenciados pelo Google (APIs ou produtos, como o BigQuery, o App Engine e o Bigtable)
• Métricas de estatísticas de conectividade de rede:
  • Estatísticas relacionadas à VPN/interconexão sobre a conexão com sistemas no local ou de fora do Google Cloud.
• SLIs.
  • Métricas associadas à integridade geral do sistema.

Configurar o monitoramento

Configure o monitoramento para monitorar recursos locais e na nuvem.

Escolha uma solução de monitoramento que:

• A plataforma é independente
• Fornece recursos uniformes para monitoramento de ambientes locais, híbridos e de várias nuvens

O uso de uma única plataforma para consolidar os dados de monitoramento recebidos de diferentes fontes permite criar métricas uniformes e painéis de visualização.

Ao configurar o monitoramento, automatize as tarefas de monitoramento sempre que possível.

Como monitorar com o Google Cloud

Usar um serviço de monitoramento, como o Cloud Monitoring, é mais fácil do que criar um serviço de monitoramento. Monitorar um aplicativo complexo é um esforço significativo de engenharia por si só. Mesmo com a infraestrutura atual para instrumentação, coleta de dados e exibição e alertas, esse é um trabalho em tempo integral para alguém criar e manter.

Considere usar o Cloud Monitoring para ter visibilidade do desempenho, da disponibilidade e da integridade dos aplicativos e da infraestrutura para recursos locais e na nuvem.

O Cloud Monitoring é um serviço gerenciado que faz parte do Google Cloud Observability. Use o Cloud Monitoring para monitorar os serviços do Google Cloud e métricas personalizadas. O Cloud Monitoring fornece uma API para integração com ferramentas de monitoramento de terceiros.

O Cloud Monitoring agrega métricas, registros e eventos da infraestrutura baseada na nuvem do sistema. Esses dados dão aos desenvolvedores e operadores um conjunto avançado de sinais observáveis que podem acelerar a análise da causa raiz e reduzir o tempo médio para resolução. Use o Cloud Monitoring para definir alertas e métricas personalizadas que atendam aos objetivos da sua empresa e ajudem a agregar, visualizar e monitorar a integridade do sistema.

O Cloud Monitoring conta com painéis padrão para serviços de aplicativos de nuvem e de código aberto. Usando o modelo de métricas, é possível definir painéis personalizados com ferramentas avançadas de visualização e configurar gráficos no Metrics Explorer.

Configurar alerta

Um bom sistema de alertas melhora sua capacidade de lançar recursos. Isso ajuda a comparar o desempenho ao longo do tempo para determinar a velocidade dos lançamentos de recursos ou a necessidade de reverter um lançamento de recurso. Para informações sobre reversões, consulte Restaurar versões anteriores sem problemas.

Ao configurar os alertas, mapeie-os diretamente para métricas importantes. Essas métricas críticas incluem:

• Os quatro sinais de ouro:
  • Latência
  • Tráfego
  • Erros
  • Saturação
• Integridade do sistema
• Service Usage
• Ocorrências de segurança
• Experiência do usuário

Torne os alertas práticos para reduzir o tempo de resolução. Para fazer isso, siga estas etapas para cada alerta:

• Inclua uma descrição clara, incluindo o que é monitorado e o impacto nos negócios.
• Forneça todas as informações necessárias para agir imediatamente. Se alguns cliques e a navegação forem necessários para entender os alertas, a pessoa de plantão terá dificuldade para agir.
• Defina níveis de prioridade para vários alertas.
• Identifique claramente a pessoa ou a equipe responsável por responder ao alerta.

Para aplicativos e serviços essenciais, crie ações de recuperação automática nos alertas acionados devido a condições de falha comuns, como falhas de integridade do serviço, alterações de configuração ou picos de capacidade.

Ao configurar os alertas, tente eliminar o trabalho. Por exemplo, elimine o trabalho eliminando erros frequentes ou automatizando correções para esses erros, o que evita que um alerta seja acionado. Eliminar o trabalho permite que as pessoas que estão de plantão se concentrem em tornar os componentes operacionais do seu aplicativo confiáveis. Para mais informações, consulte Criar uma cultura de automação.

Criar painéis de monitoramento e alerta

Quando o monitoramento estiver em vigor, crie painéis relevantes e descomplicados que incluam informações dos seus sistemas de monitoramento e alerta.

A escolha de uma maneira adequada de visualizar seu painel pode ser difícil agrupar suas metas de confiabilidade. Crie painéis para visualizar ambos:

• Análise de curto prazo e em tempo real
• Análise de longo prazo

Para saber mais sobre como implementar o gerenciamento visual, consulte o artigo do recurso Gerenciamento visual.

Ativar a geração de registros para aplicativos essenciais

Os serviços de geração de registros são essenciais para monitorar sistemas. Embora as métricas sejam a base de itens específicos para monitorar, os registros contêm informações valiosas necessárias para depuração, análise relacionada à segurança e requisitos de conformidade.

Registrar os dados gerados pelos sistemas ajuda a garantir uma postura de segurança eficaz. Para mais informações sobre registros e segurança, consulte Implementar controles de detecção e geração de registros na categoria de segurança do framework de arquitetura.

O Cloud Logging é um serviço integrado de geração de registros que pode ser usado para armazenar, pesquisar, analisar, monitorar e criar alertas sobre eventos e dados de registros. O Logging coleta automaticamente os registros dos serviços do Google Cloud e de outros provedores de nuvem. Esses registros podem ser usados para criar métricas para monitoramento e exportações de registros para serviços externos, como Cloud Storage, BigQuery e Pub/Sub.

Configurar uma trilha de auditoria

Para responder a perguntas como "quem fez o quê, onde e quando" nos seus projetos do Google Cloud, use os Registros de auditoria do Cloud.

Os registros de auditoria do Cloud capturam vários tipos de atividade, como os seguintes:

• Os Registros de atividade do administrador contêm entradas de registros para chamadas de API ou de outras ações administrativas que modificam a configuração ou os metadados de recursos. Os registros de atividades do administrador estão sempre ativados.
• Os registros de auditoria de acesso a dados gravam chamadas de API que criam, modificam ou leem dados fornecidos pelo usuário. Os registros de auditoria de Acesso a dados estão desativados por padrão porque podem ser bem grandes. É possível configurar quais serviços do Google Cloud geram registros de acesso a dados.

Para uma lista dos serviços do Google Cloud que gravam registros de auditoria, consulte serviços do Google com registros de auditoria. Use os controles de gerenciamento de identidade e acesso (IAM) para limitar quem tem acesso para visualizar os registros de auditoria.

A seguir

• Estabeleça processos na nuvem de suporte e encaminhamento para um supervisor (próximo documento desta série).
• Conheça o Google Cloud Observability.
• Implante o Cloud Monitoring para ter visibilidade do desempenho, da disponibilidade e da integridade dos seus aplicativos e da sua infraestrutura.
• Saiba mais sobre monitoramento e observabilidade.
• Explore outras categorias no Framework da arquitetura, como design do sistema, segurança, privacidade e conformidade, confiabilidade, otimização de custos e otimização de desempenho.

Estabelecer processos de suporte e escalonamento na nuvem

Este documento no Framework da arquitetura do Google Cloud mostra como definir um processo de escalonamento eficaz. Estabelecer o suporte do seu provedor de nuvem ou de outros provedores de serviços é uma parte essencial do gerenciamento de encaminhamento eficaz.

O Google Cloud oferece vários canais de suporte, incluindo suporte ao vivo ou orientações publicadas, como comunidades de desenvolvedores ou documentação do produto. Uma oferta do Cloud Customer Care garante que você trabalhe com o Google Cloud para executar suas cargas de trabalho com eficiência.

Estabelecer o suporte dos seus provedores

Compre um contrato de suporte do provedor de nuvem ou de outros provedores de serviços de terceiros. O suporte é fundamental para garantir a resposta rápida e a resolução de vários problemas operacionais.

Para trabalhar com o atendimento ao cliente do Google Cloud, considere comprar uma oferta de atendimento ao cliente que inclua suporte padrão, avançado ou premium. Considere usar o Suporte Enhanced ou Premium para seus principais ambientes de produção.

Definir o processo de encaminhamento

Um processo de escalonamento bem definido é essencial para reduzir o esforço e o tempo necessários para identificar e resolver problemas nos seus sistemas. Isso inclui problemas que exigem suporte para produtos do Google Cloud ou para outros produtores de nuvem ou serviços de terceiros.

Para criar o roteiro de encaminhamento, faça o seguinte:

• Defina quando e como encaminhar problemas internamente.
• Defina quando e como criar casos de suporte com seu provedor de nuvem ou outro provedor de serviços de terceiros.
• Saiba como trabalhar com as equipes que oferecem suporte. No caso do Google Cloud, você e as equipes de operações precisam analisar as Práticas recomendadas para trabalhar com o Atendimento ao cliente. Incorpore essas práticas ao seu roteiro de encaminhamento.
• Encontre ou crie documentos que descrevam sua arquitetura. Esses documentos incluem informações úteis para os engenheiros de suporte.
• Defina como suas equipes se comunicam durante uma interrupção.
• Certifique-se de que as pessoas que precisam de suporte tenham níveis adequados de permissões para acessar a Central de suporte do Google Cloud ou para se comunicar com outros provedores de suporte. Para saber mais sobre como usar a Central de suporte do Google Cloud, acesse Procedimentos de suporte.
• Configure o monitoramento, os alertas e a geração de registros para ter as informações necessárias para agir quando surgirem problemas.
• Criar modelos para relatórios de incidentes Para mais informações sobre como incluir nos relatórios de incidentes, consulte Práticas recomendadas para trabalhar com o Atendimento ao cliente.
• Documente o processo de encaminhamento da sua organização. Certifique-se de ter ações claras e bem definidas para lidar com encaminhamentos.
• Inclua um plano para ensinar os novos membros da equipe a interagir com o suporte.

Teste regularmente seu processo de encaminhamento internamente. Teste o processo de encaminhamento antes de grandes eventos, como migrações, lançamentos de novos produtos e eventos de pico de tráfego. Se você tiver o suporte premium do Atendimento ao cliente do Google Cloud, seu gerente técnico de contas pode ajudar a analisar o processo de encaminhamento e coordenar os testes com o Google Cloud. Atendimento ao cliente.

Garantir que você receba a comunicação do suporte

Verifique se os administradores estão recebendo a comunicação dos provedores de nuvem e de serviços de terceiros. Essas informações permitem que os administradores tomem decisões informadas e corrijam problemas antes que eles causem problemas maiores. Verifique se as seguintes condições são verdadeiras:

• Os administradores de segurança, rede e sistema estão configurados para receber e-mails importantes do Google Cloud e de outros provedores ou serviços.
• Os administradores de segurança, rede e sistema estão configurados para receber alertas do sistema gerados por ferramentas de monitoramento, como o Cloud Monitoring.
• Os proprietários do projeto têm nomes de usuário roteáveis por e-mail para que recebam e-mails importantes.

Para informações sobre como gerenciar notificações do Google Cloud, consulte Como gerenciar contatos para notificações.

Estabelecer processos de revisão

Estabelecer uma análise ou processos post mortem. Siga esses processos depois de criar um novo tíquete de suporte ou encaminhar um existente. Como parte do post mortem, documente as lições aprendidas e acompanhe mitigações. Ao fazer essa avaliação, promova uma cultura retrospectiva sem atribuição de culpados.

Para mais informações sobre post mortems, consulte Cultura post mortem: aprendizado desde a falha (em inglês).

Criar centros de excelência

Pode ser valioso capturar as informações, a experiência e os padrões da sua organização em uma base de conhecimento interna, como um wiki, um site do Google ou um site de intranet. À medida que novos produtos e recursos são lançados continuamente no Google Cloud, esse conhecimento pode ajudar a rastrear o motivo de você ter escolhido um design específico para seus aplicativos e serviços. Para mais informações, consulte Registros de decisão de arquitetura.

Também é uma boa prática indicar especialistas e campeões do Google Cloud na sua organização. Há várias opções de treinamento e certificação disponíveis para ajudar os campeões indicados a crescer na área de especialização deles. As equipes podem se inscrever no blog do Google Cloud (em inglês) para ficar por dentro de histórias de clientes, anúncios e notícias mais recentes.

A seguir

• Gerenciar capacidade e cota (próximo documento desta série)
• Explore outras categorias no Framework da arquitetura, como design do sistema, segurança, privacidade e conformidade, confiabilidade, otimização de custos e otimização de desempenho.

Gerenciar capacidade e cota

Este documento no Framework da arquitetura do Google Cloud mostra como avaliar e planejar sua capacidade e cota na nuvem.

Em data centers convencionais, você costuma gastar períodos todo trimestre analisando os requisitos de recursos atuais e prevendo os futuros. Pense em questões físicas, logísticas e relacionadas a recursos humanos. Preocupações como espaço em rack, resfriamento, eletricidade, largura de banda, cabeamento, tempos de compras, tempos de envio e quantos engenheiros estão disponíveis para a instalação de racks e pilhas de novos equipamentos precisam ser considerados. Também é preciso gerenciar ativamente a capacidade e as distribuições de carga de trabalho para que os jobs com uso intensivo de recursos, como os pipelines do Hadoop, não interfiram com os serviços, como servidores da Web, que precisam ser altamente disponíveis.

Por outro lado, ao usar o Google Cloud, você concede a maior parte do planejamento de capacidade ao Google. Usar a nuvem significa que você não precisa provisionar e manter recursos inativos quando eles não forem necessários. Por exemplo, é possível criar, escalonar verticalmente e reduzir instâncias da VM conforme necessário. Como a cobrança é feita pelo que usa, é possível otimizar os gastos, incluindo o excesso de capacidade necessária apenas nos picos de tráfego. Para ajudar você a economizar, o Compute Engine fornecerá recomendações de tipo de máquina se detectar que você usou instâncias de VM subutilizadas que podem ser redimensionadas ou excluídas.

Avaliar os requisitos da capacidade da nuvem

Para gerenciar sua capacidade com eficiência, você precisa conhecer os requisitos de capacidade da sua organização.

Para avaliar os requisitos de capacidade, comece identificando suas principais cargas de trabalho na nuvem. Avalie o uso médio e máximo dessas cargas de trabalho e as necessidades de capacidade atuais e futuras delas.

Identifique as equipes que usam essas cargas de trabalho principais. Trabalhe com eles para estabelecer um processo de planejamento da demanda interna. Use esse processo para entender as necessidades atuais e previstas de recursos da nuvem.

Analise o padrão de carga e a distribuição de chamadas. Use fatores como os últimos 30 dias de pico, por hora e por minuto na análise.

Use o Cloud Monitoring para ver o desempenho, o tempo de atividade e a integridade geral dos aplicativos e da sua infraestrutura.

Veja suas métricas de utilização da infraestrutura

Para facilitar o planejamento da capacidade, colete e armazene dados históricos sobre o uso dos recursos da nuvem pela sua organização.

Verifique as métricas de utilização da infraestrutura. Por exemplo, para as principais cargas de trabalho, avalie o seguinte:

• Uso médio e máximo
• Picos em padrões de uso
• Picos sazonais com base nos requisitos de negócios, como períodos de festas de fim de ano para varejistas
• Quanto do provisionamento em excesso é necessário para preparar os eventos de pico e lidar rapidamente com possíveis picos de tráfego

Verifique se sua organização configurou alertas para receber notificações automaticamente quando você estiver perto de atingir as limitações de cota e capacidade.

Use as ferramentas de monitoramento do Google para ter insights sobre o uso e a capacidade do aplicativo. Por exemplo, é possível definir métricas personalizadas com o Monitoring. Use essas métricas personalizadas para definir tendências de alerta. O monitoramento também fornece painéis flexíveis e ferramentas de visualização avançadas para ajudar a identificar problemas que venham a surgir.

Criar um processo para o planejamento da capacidade

Estabeleça um processo de planejamento de capacidade e documente este plano.

Ao criar esse plano, faça o seguinte:

1. executar testes de carga para determinar quanta carga o sistema pode processar ao atingir as metas de latência, considerando uma quantidade fixa de recursos. Os testes de carga precisam usar uma combinação de tipos de solicitação que corresponda aos perfis de tráfego de produção dos usuários ativos. Não use uma combinação uniforme ou aleatória de operações. Inclua picos de uso no seu perfil de tráfego.
2. Crie um modelo de capacidade. Um modelo de capacidade é um conjunto de fórmulas para calcular os recursos incrementais necessários por aumento de unidade na carga de serviço, conforme determinado no teste de carga.
3. Preveja o tráfego futuro e considere o crescimento. Consulte o artigo Medir a carga futura para um resumo de como o Google cria previsões de tráfego.
4. Aplicar o modelo de capacidade à previsão para determinar as futuras necessidades de recursos.
5. Estime o custo dos recursos que sua organização precisa. Em seguida, receba a aprovação do orçamento da sua organização financeira. Essa etapa é essencial porque a empresa pode fazer comparações de custo e de risco em diversos produtos. Essas contrapartidas podem significar adquirir capacidade menor ou maior do que a necessidade prevista para um determinado produto com base em prioridades de negócios.
6. Trabalhe com seu provedor de nuvem para receber a quantidade correta de recursos no momento certo com cotas e reservas. Envolve equipes de infraestrutura para planejamento de capacidade e faz com que as operações criem planos de capacidade com intervalos de confiança.
7. Repita as etapas anteriores a cada trimestre ou duas.

Para orientações mais detalhadas sobre o processo de planejamento da capacidade e otimização do uso de recursos, consulte Planejamento da capacidade.

Certifique-se de que suas cotas atendam aos requisitos de capacidade

O Google Cloud usa cotas para restringir a quantidade de um determinado recurso compartilhado do Google Cloud que você pode usar. Cada cota representa um recurso contável específico, como chamadas de API para um determinado serviço, o número de balanceadores de carga usados simultaneamente por seu projeto ou o número de projetos que você pode criar. Elas garantem, por exemplo, que alguns clientes ou projetos não monopolizem núcleos de CPU em uma determinada região ou zona.

Ao revisar sua cota, considere os seguintes detalhes:

• Planeje os requisitos de capacidade de seus projetos com antecedência para evitar a limitação inesperada do consumo de recursos.
• Configure sua cota e capacidade para lidar com uma falha na região completa.
• Use cotas para limitar o consumo de um recurso específico. Por exemplo, é possível definir uma cota máxima de uso por consulta por meio da API BigQuery para garantir que um projeto não exceda o limite de gastos do BigQuery.
• Planeje picos de uso e inclua esses picos como parte do seu plano de cotas. Os picos de uso podem ser variações esperadas ao longo do dia, eventos de pico de tráfego inesperados ou eventos de pico de tráfego e lançamento conhecidos. Para mais detalhes sobre como planejar eventos de pico de tráfego e lançamento, leia a próxima seção em excelência operacional: Planejar eventos de pico de tráfego e lançamento.

Se as cotas atuais não forem suficientes, gerencie-as usando o console do Google Cloud. Se você precisar de uma grande capacidade, entre em contato com a equipe de vendas do Google Cloud. No entanto, você precisa saber que muitos serviços também têm limites não relacionados ao sistema de cotas. Consulte Como trabalhar com cotas para mais informações.

Verifique suas cotas regularmente. Envie solicitações de cota antes que elas sejam necessárias. Confira Como trabalhar com cotas para mais detalhes sobre como as solicitações de cotas são avaliadas e como as solicitações são aprovadas ou negadas.

Há várias maneiras de visualizar e gerenciar sua cota do Google Cloud:

• Use o console do Google Cloud
• Como usar o Google Cloud CLI
• Como usar a API Service Usage
• Como usar o Monitoring para visualizar métricas de cotação
• Para gerenciar cotas em muitos projetos do Google Cloud em uma organização ou pasta, implemente a Solução de painel de monitoramento de cotas.

A seguir

• Planeje o pico de tráfego e os eventos de lançamento (próximo documento desta série)
• Explore outras categorias no Framework da arquitetura, como design do sistema, segurança, privacidade e conformidade, confiabilidade, otimização de custos e otimização de desempenho.

Planejar o pico de tráfego e eventos de lançamento

Este documento no Framework da arquitetura do Google Cloud mostra como planejar o pico de tráfego e iniciar eventos para evitar interrupções nos seus negócios.

Os eventos de pico são eventos importantes relacionados aos negócios que causam um aumento acentuado de tráfego além do valor de referência padrão do aplicativo. Esses eventos de pico exigem escalonamento planejado.

Por exemplo, empresas de varejo com presença on-line podem esperar eventos de pico durante os feriados. A Black Friday, que ocorre no dia seguinte ao Dia de Ação de Graças nos Estados Unidos, é um dos dias mais movimentados para compras do ano. No setor de saúde nos Estados Unidos, os meses de outubro e novembro podem ter eventos de pico devido aos picos no tráfego on-line para registro de benefícios.

Os eventos de lançamento são lançamentos substanciais ou migrações de novos recursos na produção. Por exemplo, uma migração do local para a nuvem ou um lançamento de um novo serviço ou recurso de produto.

Se você estiver lançando um novo produto, poderá esperar um aumento de carga nos sistemas durante e após o anúncio. Esses eventos podem causar aumentos de carga de 5 a 20 vezes (ou mais) em sistemas de front-end. Esse aumento de carga também aumenta a carga nos sistemas de back-end. Geralmente, esses carregamentos de front-end e back-end são caracterizados pelo escalonamento rápido durante um curto período, à medida que o evento é aberto no tráfego da Web. Os eventos de lançamento envolvem uma redução no tráfego para os níveis normais. Essa diminuição é geralmente mais lenta que o aumento até o pico.

Os eventos de pico e de lançamento incluem três etapas:

• Planejamento e preparação para o evento de lançamento ou pico de tráfego
• Como lançar o evento
• Analisar o desempenho e a análise pós-evento

As práticas descritas neste documento podem ajudar a executar cada um desses estágios sem problemas.

Criar um manual geral para os eventos de lançamento e pico

Crie um manual geral com uma visão de longo prazo dos eventos de pico atuais e futuros. Continue adicionando lições aprendidas no documento para que ele possa ser uma referência para futuros eventos de pico.

Planejar seu lançamento e eventos de pico

Planeje com antecedência Criar projeções de negócios para lançamentos futuros e eventos de pico esperados (e inesperados). A preparação do sistema para picos de escala depende da compreensão das projeções de negócios. Quanto mais você souber sobre as previsões anteriores, mais precisas serão as previsões da sua nova empresa. Essas novas previsões são informações fundamentais para projetar a demanda esperada no sistema.

Estabelecer um gerenciamento de programa e um planejamento coordenado (em toda a organização e com fornecedores terceirizados) também é fundamental para o sucesso. Configure essas equipes antecipadamente para que sua equipe de gerenciamento de programas possa definir cronogramas, proteger orçamentos e reunir recursos para infraestrutura extra, suporte para testes e treinamento.

É importante configurar canais de comunicação claros. A comunicação é essencial para todas as etapas de um lançamento ou evento de pico. Discuta os riscos e as áreas de preocupação com problemas antecipados e em forma de enxame antes de se tornarem bloqueadores. Crie a documentação de planejamento de eventos. Condense as informações mais críticas sobre o evento de pico e distribua-o. Isso ajuda as pessoas a absorver informações de planejamento e resolver questões básicas. O documento ajuda a promover a participação de pessoas novas no planejamento de eventos de pico.

Registre seu plano para cada evento. Ao documentar seu plano, faça o seguinte:

• Identifique suposições, riscos e fatores desconhecidos.
• Analise os eventos passados para determinar informações relevantes sobre o próximo evento de lançamento ou de pico. Determine quais dados estão disponíveis e qual valor eles enviaram no passado.
• Detalhe o plano de reversão para eventos de lançamento e migração.
• Analise a arquitetura:
  • Documente os principais recursos e componentes de arquitetura.
  • Use o framework de arquitetura para analisar todos os aspectos do ambiente em busca de riscos e preocupações em escala.
  • Crie um diagrama que mostre como os principais componentes da arquitetura estão conectados. Uma revisão do diagrama pode ajudar você a isolar problemas e priorizar a resolução deles.
• Se apropriado, configure o serviço para usar ações de alerta a fim de reiniciar automaticamente em caso de falha. Ao usar o Compute Engine, use o escalonamento automático para lidar com picos de capacidade.
• Para garantir que os recursos do Compute Engine estejam disponíveis quando você precisar deles, use Reservas. As reservas fornecem um nível muito alto de garantia da capacidade dos recursos zonais do Compute Engine. Você pode usar reservas para garantir que seu projeto tenha recursos disponíveis.
• Identifique as métricas e os alertas que serão rastreados:
  • Identifique as métricas da empresa e do sistema para monitoramento do evento. Se alguma métrica ou indicador de nível de serviço (SLIs) não estiver sendo coletado, modifique o sistema para coletar esses dados.
  • Verifique se você tem recursos de monitoramento e alerta suficientes e revisou os padrões de tráfego normal e anterior. Verifique se os alertas estão definidos corretamente. Use as ferramentas do Google Cloud Monitoring para ver o uso, a capacidade e a integridade geral dos seus aplicativos e da infraestrutura.
  • Verifique se as métricas do sistema estão sendo capturadas com os níveis de monitoramento e alerta de interesse.
• Revise os requisitos de capacidade aumentada com sua equipe de conta do Google Cloud e planeje o gerenciamento de cota necessário. Para mais detalhes, consulte Verifique se as cotas correspondem aos requisitos de capacidade.
• Verifique se você tem níveis de suporte na nuvem apropriados, se a equipe entende como abrir os casos de suporte e tem um caminho de encaminhamento estabelecido. Veja mais detalhes em Estabelecer processos de suporte e encaminhamento para a nuvem.
• Defina um plano de comunicação, um cronograma e as responsabilidades:
  • Envolva as partes interessadas multifuncionais para coordenar a comunicação e o planejamento do programa. Essas partes interessadas podem incluir pessoas adequadas de equipes técnicas, operacionais e de liderança, além de fornecedores terceirizados.
  • Estabeleça um cronograma não ambíguo contendo tarefas essenciais e as equipes que as pertencem.
  • Estabeleça uma matriz de atribuição de responsabilidade (RACI, na sigla em inglês) para comunicar a propriedade de equipes, líderes de equipes, partes interessadas e partes responsáveis.
  • Você pode usar o Serviço de gerenciamento de eventos do Suporte Premium para eventos de pico planejados. Com esse serviço, o Customer Care faz uma parceria com sua equipe para criar um plano e oferecer orientações durante o evento.

Estabelecer processos de revisão

Quando o evento de pico de tráfego ou o evento de lançamento terminar, revise o evento para documentar as lições aprendidas. Em seguida, atualize o manual com essas lições. Por fim, aplique o que você aprendeu no próximo evento principal. Aprender com eventos anteriores é importante, especialmente quando destacam restrições para o sistema enquanto estão sob pressão.

Avaliações retrospectivas, também chamadas de post mortems, para eventos de pico de tráfego ou eventos de lançamento são uma técnica útil para capturar dados e entender os incidentes que ocorreram. Faça essa análise para identificar picos de tráfego e eventos de lançamento como o esperado e quaisquer incidentes que tenham causado problemas. À medida que você revisa, adote uma cultura sem culpa.

Para mais informações sobre post mortems, consulte Cultura post mortem: aprendizado desde a falha (em inglês).

A seguir

• Crie uma cultura de automação (próximo documento desta série)
• Explore outras categorias no Framework da arquitetura, como design do sistema, segurança, privacidade e conformidade, confiabilidade, otimização de custos e otimização de desempenho.

Crie uma cultura de automação

Neste documento do Framework da arquitetura do Google Cloud, mostramos como avaliar o trabalho e reduzir os impactos nos sistemas e nas equipes.

O esforço é um trabalho manual e repetitivo, sem valor duradouro, que aumenta conforme o serviço cresce. Tente reduzir ou eliminar o esforço sempre que puder. Caso contrário, o trabalho operacional poderá sobrecarregar os operadores, e qualquer crescimento no uso ou na complexidade do produto pode exigir mais equipe.

A automação é uma maneira essencial de minimizar o trabalho. A automação também melhora a velocidade de lançamento e ajuda a minimizar erros causados por humanos.

Para saber mais, consulte Eliminação de trabalho.

Criar um inventário e avaliar o custo do esforço

Comece criando um inventário e avaliando o custo do trabalho nas equipes que gerenciam seus sistemas. Torne esse processo contínuo e investindo em automação personalizada para estender o que já é fornecido pelos serviços e parceiros do Google Cloud. Muitas vezes, é possível modificar a própria automação do Google Cloud, por exemplo, o escalonador automático do Compute Engine.

Priorizar o esforço

A automação é útil, mas não é uma solução para todos os problemas operacionais. Como primeira etapa para lidar com o trabalho conhecido, recomendamos analisar o inventário de trabalho existente e priorizar a eliminação do maior esforço possível. Assim, você se concentra na automação.

Automatizar o trabalho necessário

Alguns trabalhos nos sistemas não podem ser eliminados. Como uma segunda etapa na lide com o trabalho conhecido, automatize esse esforço usando as soluções que o Google Cloud oferece por meio da automação configurável.

Veja a seguir algumas áreas em que a automação configurável ou a automação personalizada pode ajudar sua organização a eliminar o trabalho:

• Gerenciamento de identidade, por exemplo, Cloud Identity and Identity and Access Management
• soluções hospedadas pelo Google Cloud, em vez de soluções autoprojetas, por exemplo, gerenciamento de clusters (Google Kubernetes Engine (GKE)), gerenciamento de banco de dados relacional (Cloud SQL), gerenciamento de armazenamento de dados (BigQuery) e gerenciamento de APIs (Apigee).
• Provisionamento de serviços do Google Cloud e locatários. Por exemplo, Terraforme Cloud Foundation Toolkit.
• Orquestração automatizada de fluxo de trabalho para operações em várias etapas, por exemplo, Cloud Composer.
• O provisionamento de capacidade extra, por exemplo, vários produtos do Google Cloud, como o Compute Engine e o GKE, oferece escalonamento automático configurável. Avalie os serviços do Google Cloud que você está usando para determinar se eles incluem escalonamento automático configurável.
• Pipelines de CI/CD com implantação automatizada, por exemplo, Cloud Build.
• Análise de teste canário para validar implantações.
• Treinamento de modelo automatizado (para machine learning), por exemplo, AutoML

Se um produto ou serviço do Google Cloud atender apenas parcialmente às suas necessidades técnicas ao automatizar ou eliminar fluxos de trabalho manuais, avalie a solicitação de recursos por meio do representante da conta do Google Cloud. Seu problema pode ser uma prioridade para outros clientes ou já faz parte do nosso roteiro. Em caso afirmativo, conhecer a prioridade e o cronograma do recurso ajuda a avaliar melhor as vantagens de criar sua própria solução em comparação com a espera para usar um recurso do Google Cloud.

Criar ou comprar soluções para trabalhos de alto custo

A terceira etapa, que pode ser concluída em paralelo com a primeira e a segunda etapas, envolve avaliar a criação ou a compra de outras soluções caso o custo do esforço continue alto, por exemplo, se o esforço exigir um tempo significativo }para qualquer equipe que gerencie seus sistemas de produção.

Ao criar ou comprar soluções, considere os custos de integração, segurança, privacidade e conformidade. Projetar e implementar sua própria automação vem com custos de manutenção e riscos de confiabilidade além dos custos iniciais de desenvolvimento e configuração. Portanto, considere essa opção como último recurso.

A seguir

Explore outras categorias no Framework da arquitetura, como design do sistema, segurança, privacidade e conformidade, confiabilidade, otimização de custos e otimização de desempenho.

Estrutura de arquitetura do Google Cloud: segurança, privacidade e conformidade

Esta categoria no Framework da arquitetura do Google Cloud mostra como arquitetar e operar serviços seguros no Google Cloud. Você também aprenderá sobre os produtos e recursos do Google Cloud compatíveis com segurança e conformidade.

O framework de arquitetura descreve as práticas recomendadas, fornece recomendações de implementação e explica alguns dos produtos e serviços disponíveis. O framework ajuda você a projetar sua implantação do Google Cloud para que ele corresponda às necessidades da sua empresa.

Mover suas cargas de trabalho para o Google Cloud requer uma avaliação dos seus requisitos de negócios, riscos, obrigações de conformidade e controles de segurança. Neste documento, apresentamos as principais práticas recomendadas relacionadas à criação de uma solução segura no Google Cloud.

Os princípios básicos do Google incluem defesa em profundidade, em escala e por padrão. No Google Cloud, os dados e sistemas são protegidos por várias defesas em camadas usando políticas e controles configurados no IAM, criptografia, rede, detecção, geração de registros e monitoramento.

O Google Cloud vem com muitos controles de segurança que podem ser usados para criar, como:

• Opções seguras para dados em trânsito e criptografia padrão para dados em repouso.
• Recursos de segurança integrados para produtos e serviços do Google Cloud.
• Uma infraestrutura global projetada para redundância geográfica com controles de segurança em todo o ciclo de vida de processamento de informações.
• Recursos de automação que usam infraestrutura como código (IaC, na sigla em inglês) e restrições de configuração.

Para mais informações sobre a postura de segurança do Google Cloud, consulte o documento de segurança do Google e a Visão geral do design de segurança da infraestrutura do Google. Para um exemplo de ambiente seguro por padrão, consulte o Blueprint de bases empresariais do Google Cloud.

Na categoria de segurança do framework de arquitetura, você aprende a fazer o seguinte:

• Analisar a responsabilidade e o destino compartilhados no Google Cloud
• Entender os princípios de segurança
• Usar controles para gerenciar riscos
• Gerenciar seus recursos
• Identidade e acesso
• Implemente a segurança de computação e contêiner
• Proteger a rede
• Implementar a segurança de dados
• Implantar segurança de aplicativos
• Gerenciar obrigações de conformidade
• Implementar requisitos de residência e soberania de dados
• Implementar os requisitos de privacidade
• Implementar controles de detecção e geração de registros

Responsabilidades compartilhadas e destino compartilhado Google Cloud

Este documento descreve as diferenças entre o modelo de responsabilidade compartilhada e o destino compartilhado no Google Cloud, além de discutir os desafios e as nuances do modelo de responsabilidade compartilhada. Este documento também descreve o que é o destino compartilhado e como funciona a parceria com clientes para enfrentar os desafios de segurança na nuvem.

É importante entender o modelo de responsabilidade compartilhada para definir a melhor forma de proteger dados e cargas de trabalho no Google Cloud. O modelo de responsabilidade compartilhada descreve as tarefas de segurança na nuvem e como essas tarefas são diferentes para os provedores de nuvem.

No entanto, entender a responsabilidade compartilhada pode ser um desafio. O modelo requer conhecimento profundo de cada serviço que você usa, das opções de configuração que cada serviço oferece e do que o Google Cloud faz para proteger o serviço. Cada serviço tem um perfil de configuração diferente, e pode ser difícil identificar a melhor configuração de segurança. O Google acredita que o modelo de responsabilidade compartilhada não ajuda os clientes de nuvem a atingir melhores resultados de segurança. Em vez da responsabilidade compartilhada, acreditamos no destino compartilhado.

O destino compartilhado inclui a criação e operação de uma plataforma de nuvem confiável para cargas de trabalho. Temos práticas recomendadas e um código de infraestrutura atestado e seguro que pode ser usado para implantar as cargas de trabalho com segurança. Lançamos soluções que combinam vários serviços do Google Cloud para resolver problemas complexos de segurança, e oferecemos opções inovadoras de seguro para ajudar você a avaliar e mitigar os riscos que precisa aceitar. O destino compartilhado envolve uma interação mais próxima com você para proteger seus recursos no Google Cloud.

Responsabilidade compartilhada

Você é especialista em requisitos regulamentares e de segurança da sua empresa, e os requisitos para proteger seus dados e recursos confidenciais. Ao executar cargas de trabalho no Google Cloud, você precisa identificar os controles de segurança que precisam ser configurados no serviço para proteger seus dados confidenciais e cada carga de trabalho. Para decidir quais controles de segurança serão implementados, considere os seguintes fatores:

• Obrigações regulatórias de conformidade
• Padrões de segurança e plano de gerenciamento de riscos da organização
• Requisitos de segurança de clientes e fornecedores

Definido por cargas de trabalho

Tradicionalmente, as responsabilidades são definidas com base no tipo de carga de trabalho executada e nos serviços de nuvem de que você precisa. Os serviços do Cloud incluem as seguintes categorias:

Serviço em nuvem	Descrição
Infraestrutura como serviço (IaaS)	Os serviços de IaaS incluem Google Compute Engine, Cloud Storage e serviços de rede, como Cloud VPN, Cloud Load Balancing e Cloud DNS. A IaaS oferece serviços de computação, armazenamento e rede sob demanda com pagamento por utilização. É possível usar a IaaS para migrar uma carga de trabalho local para a nuvem usando lift-and-shift ou executar o aplicativo em VMs específicas, com determinados bancos de dados ou configurações de rede. Na IaaS, a maior parte das responsabilidades de segurança é sua, e nossas responsabilidades se concentram na infraestrutura básica e na segurança física.
Plataforma como serviço (PaaS)	Os serviços de PaaS incluem App Engine, Google Kubernetes Engine (GKE) e BigQuery. O PaaS oferece o ambiente de execução em que você desenvolve e executa aplicativos. É possível usar o PaaS para criar um aplicativo (como um site) e se concentrar no desenvolvimento, e não na infraestrutura subjacente. Na PaaS, somos responsáveis por mais controles do que na IaaS, incluindo controles de rede. Vocês compartilha a responsabilidade conosco pelos controles no nível do aplicativo e pelo gerenciamento do IAM. Você é responsável pela segurança dos dados e pela proteção do cliente.
Software como serviço (SaaS)	Os aplicativos de SaaS incluem Google Workspace, Chronicle e apps de SaaS de terceiros disponíveis no Google Cloud Marketplace. O SaaS oferece aplicativos on-line que você pode assinar ou pagar de alguma maneira. É possível usar aplicativos SaaS quando a empresa não tem a experiência interna ou o requisito de negócios para criar o aplicativo, mas exige a capacidade de processar cargas de trabalho. Em SaaS, a maior parte das responsabilidades de segurança é nossa. Você é responsável pelos seus controles de acesso e pelos dados que quer armazenar no aplicativo.
Função como serviço (FaaS) ou sem servidor	O FaaS oferece a plataforma para que desenvolvedores executem código pequeno de finalidade única (chamado de funções) em resposta a eventos específicos. Use o FaaS quando quiser que algo específico ocorra com base em um determinado evento. Por exemplo, é possível criar uma função que será executada sempre que os dados forem enviados para o Cloud Storage para classificação. O FaaS tem uma lista de responsabilidades compartilhadas semelhante à de SaaS. O Cloud Functions é um aplicativo FaaS.

O diagrama a seguir mostra os serviços em nuvem e define como as responsabilidades são compartilhadas entre o provedor de nuvem e o cliente.

Como mostra o diagrama, o provedor de nuvem sempre permanece responsável pela rede e pela infraestrutura subjacentes, e os clientes sempre são responsáveis pelas políticas de acesso e pelos dados.

Definida pelo setor e pela estrutura regulamentar

Vários setores têm frameworks regulamentares que definem os controles de segurança que precisam ser implementados. Ao mover cargas de trabalho para a nuvem, você precisa entender o seguinte:

• Quais controles de segurança são de sua responsabilidade
• Quais controles de segurança estão disponíveis como parte da oferta na nuvem
• Quais controles de segurança padrão são herdados

Controles de segurança herdados, como nossa criptografia padrão e controles de infraestrutura, são controles que você pode fornecer como parte das evidências da sua posição de segurança a auditores e reguladores. Por exemplo, o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS, na sigla em inglês) define regulamentações para processadores de pagamentos. Quando você migra a empresa para a nuvem, essas regulamentações são compartilhadas entre você e seu CSP. Para entender como as responsabilidades do PCI DSS são compartilhadas entre você e o Google Cloud, consulte Google Cloud: matriz de responsabilidade compartilhada do PCI DSS.

Outro exemplo: nos Estados Unidos, a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA, na sigla em inglês) definiu padrões para o tratamento de informações sobre saúde pessoal (PHI, na sigla em inglês) no meio eletrônico. Essas responsabilidades também são compartilhadas entre o CSP e você. Para saber mais sobre como o Google Cloud cumpre as responsabilidades definidas pela HIPAA, consulte HIPAA: conformidade.

Outros setores, como finanças ou manufatura, também têm regulamentações que definem como os dados podem ser coletados, processados e armazenados. Para mais informações sobre a responsabilidade compartilhada relacionada a esses setores e como o Google Cloud cumpre suas responsabilidades, consulte a Central de recursos de compliance.

Definida por local

Dependendo do cenário da empresa, talvez você precise considerar suas responsabilidades com base na localização de escritórios, clientes e dados. Diferentes países e regiões criaram regulamentações que informam como processar e armazenar dados de clientes. Por exemplo, caso sua empresa tenha clientes residentes na União Europeia, talvez seja necessário respeitar os requisitos descritos no Regulamento geral de proteção de dados (GDPR) e você tenha a obrigação de manter os dados dos clientes na UE. Nessa circunstância, você é responsável por garantir que os dados coletados permaneçam nas regiões do Google Cloud na UE. Para mais informações sobre como cumprimos as obrigações relacionadas ao GDPR, consulte GDPR e Google Cloud.

Para informações sobre os requisitos relacionados à sua região, consulte Ofertas de compliance. Se a situação for particularmente complicada, fale com a equipe de vendas ou com um dos nossos parceiros para ajudar você a avaliar as responsabilidades de segurança.

Desafios da responsabilidade compartilhada

Embora a responsabilidade compartilhada ajude a definir os papéis de segurança que você ou o provedor de nuvem têm, contar com a responsabilidade compartilhada ainda pode criar desafios. Considere os cenários a seguir:

• A maioria das violações de segurança na nuvem é resultado direto da configuração incorreta (listada como número 3 no relatório Pandemic 11 do Cloud Security Alliance), e essa tendência tende a aumentar. Os produtos de nuvem mudam sempre, e novos produtos são lançados constantemente. Acompanhar a mudança constante pode ser difícil. Os clientes precisam de provedores de nuvem para oferecer práticas recomendadas firmes que ajudam a acompanhar a mudança, começando com as práticas recomendadas por padrão e uma configuração segura de referência.
• Ainda que a divisão de itens por serviços em nuvem seja útil, muitas empresas têm cargas de trabalho que exigem vários tipos de serviços em nuvem. Nessas circunstâncias, é preciso considerar como vários controles de segurança desses serviços interagem, inclusive se eles se sobrepõem entre os serviços. Por exemplo, é possível migrar um aplicativo local para o Compute Engine, usar o Google Workspace para e-mails corporativos e também executar o BigQuery para analisar dados e melhorar seus produtos.
• Sua empresa e seus mercados mudam constantemente; conforme as regulamentações mudam, à medida que você entra em novos mercados ou conforme adquire outras empresas. Os novos mercados podem ter requisitos diferentes, e a nova aquisição pode hospedar as cargas de trabalho em outra nuvem. Para gerenciar mudanças constantes, é necessário sempre reavaliar seu perfil de risco e implementar novos controles rapidamente.
• Como e onde gerenciar chaves de criptografia de dados é uma decisão importante que está vinculada às suas responsabilidades de proteger dados. A opção escolhida depende dos requisitos regulamentares, se você está executando um ambiente de nuvem híbrida ou ainda tem um ambiente local, bem como da confidencialidade dos dados que está processando e armazenando.
• O gerenciamento de incidentes é uma área importante e geralmente ignorada, em que suas responsabilidades e as do provedor de nuvem não são facilmente definidas. Muitos incidentes exigem colaboração e suporte do provedor de nuvem na investigação e mitigação. Outros incidentes podem resultar de recursos de nuvem mal configurados ou de credenciais roubadas, e garantir que você siga as práticas recomendadas para proteger recursos e contas pode ser uma tarefa desafiadora.
• Ameaças permanentes avançadas (APTs, na sigla em inglês) e novas vulnerabilidades podem afetar as cargas de trabalho de maneiras que talvez você não considere ao iniciar a transformação na nuvem. É difícil garantir que você se mantenha a atualização nesse cenário em constante mudança e saiba quem é responsável pela mitigação de ameaças, especialmente se a empresa não tiver uma grande equipe de segurança.

Destino compartilhado

Desenvolvemos um destino compartilhado no Google Cloud para começar a enfrentar os desafios que o modelo de responsabilidade compartilhada não soluciona. O destino compartilhado se concentra em como todas as partes podem interagir melhor para melhorar a segurança continuamente. O destino compartilhado se baseia no modelo de responsabilidade compartilhada porque vê a relação entre o provedor de nuvem e o cliente como uma parceria contínua para melhorar a segurança.

Com o destino compartilhado, assumimos a responsabilidade de tornar o Google Cloud mais seguro. O destino compartilhado ajuda você a começar a usar uma zona de destino segura e ser simples, firme e transparente em relação a recomendações de controles de segurança, configurações e as práticas recomendadas associadas. Isso inclui ajudar você a quantificar e gerenciar melhor seus riscos com seguro cibernético por meio do Programa de proteção a riscos. Ao usar o destino compartilhado, queremos evoluir do framework de responsabilidade compartilhada padrão para um modelo melhor que ajuda a proteger sua empresa e criar confiança no Google Cloud.

As seções a seguir descrevem vários componentes do destino compartilhado.

Ajuda para começar

Um componente essencial do destino compartilhado são os recursos que oferecemos para ajudar você a começar, em uma configuração segura do Google Cloud. Começar com uma configuração segura ajuda a reduzir o problema de configurações incorretas, que é a causa raiz da maioria das violações de segurança.

Nossos recursos incluem:

• Blueprint de bases empresariais, que discute as principais preocupações com a segurança e nossas principais recomendações.

• Modelos seguros que permitem implantar e manter soluções seguras usando a infraestrutura como código (IaC, na sigla em inglês). Os modelos têm as recomendações de segurança ativadas por padrão. Muitos modelos são criados por equipes de segurança do Google e gerenciados como produtos. Esse suporte significa que eles são atualizados regularmente, passam por um processo de teste rigoroso e recebem atestados de grupos de teste terceirizados. Os blueprints incluem: bases empresariais, data warehouse seguro e notebooks do Vertex AI Workbench.

• Práticas recomendadas do framework de arquitetura que abordam as principais recomendações para criar designs com segurança integrada. O framework de arquitetura inclui uma seção de segurança e uma zona de comunidade que você pode usar para se conectar com especialistas e colegas.

• Guias de navegação na zona de destino que orientam sobre as principais decisões que você precisa tomar para criar uma base segura para suas cargas de trabalho, incluindo hierarquia de recursos, integração de identidade, segurança, gerenciamento de chaves e estrutura de rede.

Programa de proteção a riscos

O destino compartilhado também inclui o Programa de proteção a riscos (atualmente em pré-lançamento), que ajuda você a usar o poder do Google Cloud como uma plataforma para gerenciar riscos, em vez de apenas ver cargas de trabalho de nuvem como outra fonte de risco que precisa ser gerenciada. O Programa de proteção a riscos é uma colaboração entre o Google Cloud e duas empresas líderes em seguros cibernéticos, Munique Re e Allianz Global & Corporate Speciality.

O Programa de proteção a riscos inclui o Gerenciador de Risco, que mostra insights baseados em dados que podem ser usados para entender melhor sua postura de segurança na nuvem. Se você estiver procurando cobertura de seguro cibernético, compartilhe os insights do Gerenciador de Risco diretamente com nossos parceiros de seguro para receber uma cotação. Para mais informações, consulte Programa de proteção a riscos do Google Cloud agora em Pré-lançamento.

Ajuda com implantação e governança

O destino compartilhado também ajuda na governança contínua do seu ambiente. Por exemplo, concentramos esforços em produtos como estes:

• Assured Workloads, que ajuda a cumprir obrigações de conformidade.
• Security Command Center Premium, que usa inteligência contra ameaças, detecção de ameaças, verificação da Web e outros métodos avançados para monitorar e detectar ameaças. Também é uma maneira de resolver muitas dessas ameaças de maneira rápida e automática.
• Políticas da organização e configurações de recursos, que permitem definir políticas em toda a hierarquia de pastas e projetos.
• Ferramentas de inteligência de política que fornecem insights sobre o acesso a contas e recursos.
• Computação confidencial, que permite criptografar os dados em uso.
• Sovereign Cloud, que está disponível na Alemanha e implementa requisitos de residência de dados.

Colocar a responsabilidade compartilhada e o destino compartilhado em prática

Como parte do processo de planejamento, considere as seguintes ações para entender melhor e implementar os controles de segurança apropriados:

• Crie uma lista dos tipos de cargas de trabalho que você hospedará no Google Cloud e se elas exigem serviços IaaS, PaaS e SaaS. Use o diagrama de responsabilidade compartilhada como uma checklist para garantir que você conhece os controles de segurança que precisa considerar.
• Crie uma lista de requisitos regulamentares que precisam ser cumpridos e acesse recursos na Central de recursos de compliance relacionada a esses requisitos.
• Veja a lista de arquiteturas e modelos disponíveis no Architecture Center para os controles de segurança necessários para cargas de trabalho específicas. Os modelos contam com uma lista de controles recomendados e o código de IaC necessário para implantar essa arquitetura.
• Use a documentação da zona de destino e as recomendações no guia de princípios básicos empresariais para projetar uma hierarquia de recursos e uma arquitetura de rede que atendam aos seus requisitos. Use os modelos de carga de trabalho consistentes, como o armazenamento de dados seguro, para acelerar o processo de desenvolvimento.
• Depois de implantar as cargas de trabalho, verifique se você está cumprindo as responsabilidades de segurança usando serviços como o Gerenciador de Risco, o Assured Workloads, as ferramentas de inteligência de política e o Security Command Center Premium.

Para mais informações, consulte o Guia da ISO para a transformação na nuvem.

A seguir

• Leia os princípios de segurança (próximo documento desta série).
• Fique por dentro dos recursos de destino compartilhado.
• Conheça os modelos disponíveis, incluindo o de princípios básicos de segurança e exemplos de carga de trabalho, como o armazenamento de dados seguro.
• Leia mais sobre o destino compartilhado.
• Leia sobre nossa infraestrutura de segurança subjacente em Visão geral do design de segurança da infraestrutura do Google.
• Leia como implementar Práticas recomendadas do framework de segurança cibernética do NIST no Google Cloud (PDF).

Princípios de segurança

Neste documento, o framework de arquitetura do Google Cloud explica os princípios básicos para executar serviços seguros e compatíveis no Google Cloud. Muitos dos princípios de segurança que você já conhece em seu ambiente local se aplicam a ambientes em nuvem.

Criar uma abordagem de segurança em camadas

Implemente a segurança em cada nível do aplicativo e da infraestrutura aplicando uma abordagem de defesa profunda. Use os recursos em cada produto para limitar o acesso e configurar a criptografia quando apropriado.

Projetar para sistemas separados seguros

Simplifique o design do sistema para acomodar a flexibilidade sempre que possível e documentar os requisitos de segurança de cada componente. Incorpore um mecanismo seguro para garantir a resiliência e a recuperação.

Automatizar a implantação de tarefas confidenciais

Automatize a implantação e outras tarefas administrativas para retirar pessoas do fluxo de trabalho.

Automatizar o monitoramento de segurança

Use ferramentas automatizadas para monitorar o aplicativo e a infraestrutura. Para verificar vulnerabilidades em sua infraestrutura e detectar incidentes de segurança, use a verificação automatizada nos pipelines de integração e implantação contínuas (CI/CD).

É preciso atender aos requisitos de conformidade das suas regiões

Talvez você precise ofuscar ou editar informações de identificação pessoal (PII) para atender aos seus requisitos regulamentares. Sempre que possível, automatize seus esforços de conformidade. Por exemplo, use a Proteção de dados confidenciais e o Dataflow para automatizar o job de edição de PII antes que novos dados sejam armazenados no sistema.

Cumprir os requisitos de soberania de residência e dados

Você pode ter requisitos internos (ou externos) que exigem o controle dos locais de armazenamento e processamento de dados. Esses requisitos variam de acordo com os objetivos de design dos sistemas, questões regulatórias do setor, legislação nacional, implicações tributárias e cultura. Essa seção descreve onde seus dados são armazenados. Para ajudar a cumprir os requisitos de residência de dados, o Google Cloud permite controlar onde os dados são armazenados, como os dados são acessados e como são processados.

Deslocar segurança para a esquerda

O DevOps e a automação de implantação permitem que sua organização aumente a velocidade da entrega de produtos. Para ajudar a garantir que seus produtos permaneçam seguros, incorpore os processos de segurança desde o início do processo de desenvolvimento. Por exemplo, é possível realizar estas ações:

• Testar problemas de segurança no código no início do pipeline de implantação.
• Verifique imagens de contêiner e a infraestrutura de nuvem de maneira contínua.
• Automatize a detecção de antipadrões e de configuração incorreta. Por exemplo, use a automação para procurar secrets que estejam codificados em aplicativos ou na configuração.

A seguir

Saiba mais sobre os principais princípios de segurança com os seguintes recursos:

• Gerenciar riscos com controles (próximo documento desta série)
• Blueprint de bases empresariais do Google Cloud
• Artigo de segurança do Google
• Visão geral do design de segurança da infraestrutura do Google
• Criar um processo colaborativo de gerenciamento de incidentes
• Blueprints implantáveis para setores diferentes

Usar controles para gerenciar riscos

Neste documento no Framework da arquitetura do Google Cloud, descrevemos as práticas recomendadas para gerenciar riscos em uma implantação em nuvem. Realize uma análise cuidadosa dos riscos que se aplicam à sua organização para determinar os controles de segurança necessários. Conclua a análise de risco antes de implantar cargas de trabalho no Google Cloud e, regularmente, posteriormente, conforme as necessidades da sua empresa, os requisitos regulamentares e as ameaças relevantes para sua organização mudarem.

Identificar riscos para sua organização

Antes de criar e implantar recursos no Google Cloud, conclua uma avaliação de risco para determinar quais recursos de segurança são necessários para atender aos requisitos de segurança internos e externos e regulatórios. Sua avaliação de riscos fornece um catálogo de riscos relevantes para você e informa a capacidade da sua organização de detectar e combater ameaças de segurança.

Os riscos em um ambiente de nuvem são diferentes dos riscos em um ambiente local devido ao acordo de responsabilidade compartilhada que você insere com o provedor de nuvem. Por exemplo, em um ambiente local, é preciso reduzir as vulnerabilidades para a pilha de hardware. Por outro lado, em um ambiente de nuvem, esses riscos são assumidos pelo provedor de nuvem.

Além disso, os riscos serão diferentes dependendo de como você planeja usar o Google Cloud. Você está transferindo algumas das cargas de trabalho para o Google Cloud ou todas elas? Você está usando o Google Cloud apenas para recuperação de desastres? Você está configurando um ambiente de nuvem híbrida?

Recomendamos que você use um framework de avaliação de risco padrão do setor que se aplique a ambientes de nuvem e aos seus requisitos regulamentares. Por exemplo, a Cloud Security Alliance (CSA) fornece a matriz de controles do Cloud (CCM, na sigla em inglês). Além disso, há modelos de ameaça, como a estimativa de ameaça do aplicativo OWASP, que oferecem uma lista de possíveis lacunas e que sugerem ações para corrigir as lacunas encontradas de dados. Consulte nosso diretório de parceiros para ver uma lista de especialistas em avaliações de risco do Google Cloud.

Para ajudar a catalogar seus riscos, considere o Gerenciador de Risco, que faz parte do Programa de Proteção de Risco. Esse programa está em pré-lançamento. O Gerenciador de Risco verifica suas cargas de trabalho para ajudar você a entender os riscos da sua empresa. Os relatórios detalhados fornecem um valor de referência de segurança. Além disso, é possível usar os relatórios do Gerenciador de Risco para comparar seus riscos com os riscos descritos no Comparativo de mercado do Center for Internet Security (CIS).

Depois de catalogar seus riscos, você precisa determinar como resolvê-los, ou seja, se quer aceitá-los, evitá-los, transferi-los ou mitigá-los. A seção a seguir descreve os controles de mitigação.

Reduza seus riscos

É possível reduzir os riscos usando controles técnicos, proteções contratuais e verificações ou atestados de terceiros. A tabela a seguir lista como você pode usar essas mitigações quando adotar novos serviços de nuvem pública.

Mitigação	Descrição
Controles técnicos	Os controles técnicos se referem aos recursos e tecnologias usados para proteger o ambiente. Eles incluem controles de segurança na nuvem integrados, como firewalls e geração de registros. Os controles técnicos também podem incluir o uso de ferramentas de terceiros para reforçar ou apoiar sua estratégia de segurança. Existem duas categorias de controles técnicos: O Google Cloud inclui vários controles de segurança para reduzir os riscos que se aplicam a você. Por exemplo, se você tem um ambiente local, pode usar o Cloud VPN e o Cloud Interconnect para proteger a conexão entre o ambiente local e seus recursos da nuvem. O Google conta com recursos robustos de controle e auditoria internos para proteger os dados dos clientes contra acesso interno. Nossos registros de auditoria oferecem aos clientes registros quase em tempo real do acesso do administrador do Google no Google Cloud.
Proteções contratuais	As proteções contratuais se referem aos compromissos jurídicos assumidos por nós com relação aos serviços do Google Cloud. O Google tem o compromisso de manter e expandir nosso portfólio de conformidade. O documento do Adendo sobre processamento de dados do Cloud (CDPA) define nosso compromisso de manter as certificações ISO 27001, 27017 e 27018 e atualizar os relatórios SOC 2 e SOC 3 a cada 12 meses. O documento DPST também descreve os controles de acesso disponíveis para limitar o acesso de engenheiros de suporte do Google aos ambientes dos clientes e descreve nossos registros rigorosos e aprovação. Recomendamos que você revise os controles contratuais do Google Cloud com seus especialistas jurídicos e regulamentares e verifique se eles atendem aos requisitos. Se você precisar de mais informações, entre em contato com o representante técnico da conta.
Verificações ou atestados de terceiros	Verificações ou atestados de terceiros se referem a um fornecedor terceirizado auditar o provedor de nuvem para garantir que ele atenda aos requisitos de conformidade. Por exemplo, o Google foi auditado por um terceiro para garantir a conformidade com a ISO 27017. Veja as certificações e os atestados do Google Cloud na Central de recursos de compliance.

A seguir

Saiba mais sobre gerenciamento de riscos com os seguintes recursos:

• Gerenciar seus recursos (próximo documento desta série)

• Programa de proteção a riscos

• Central de recursos de compliance

• Governança de risco da transformação digital na nuvem (PDF)

Gerenciar seus recursos

Neste documento, você encontra as práticas recomendadas para o gerenciamento de recursos no Framework da arquitetura do Google Cloud.

O gerenciamento de recursos é uma parte importante da análise de requisitos de negócios. Você precisa saber quais recursos tem e entender bem todos eles, os valores deles e quaisquer caminhos ou processos críticos relacionados a eles. Você precisa ter um inventário de recursos preciso antes de projetar qualquer tipo de controle de segurança para protegê-los.

Para gerenciar incidentes de segurança e atender aos requisitos regulamentares da sua organização, você precisa de um inventário de recursos preciso e atualizado, que inclua uma maneira de analisar dados históricos. Você precisa ser capaz de rastrear seus recursos, incluindo como a exposição ao risco pode mudar com o tempo.

Migrar para o Google Cloud significa que você precisa modificar seus processos de gerenciamento de recursos para se adaptar a um ambiente de nuvem. Por exemplo, um dos benefícios de mudar para a nuvem é que você aumenta a capacidade da sua organização para escalonar rapidamente. No entanto, a capacidade de escalonamento rápido pode causar problemas de TI de sombras, em que os funcionários criam recursos na nuvem que não são devidamente gerenciados e protegidos. Portanto, os processos de gerenciamento de recursos precisam fornecer flexibilidade suficiente para que os funcionários trabalhem e, ao mesmo tempo, fornecer controles de segurança adequados.

Usar as ferramentas de gerenciamento de recursos na nuvem

As ferramentas de gerenciamento de recursos do Google Cloud são adaptadas especificamente ao nosso ambiente e aos principais casos de uso de clientes.

Uma dessas ferramentas é o Inventário de recursos do Cloud, que fornece informações em tempo real sobre o estado atual dos recursos e com um histórico de cinco semanas. Ao usar esse serviço, é possível receber um snapshot do seu inventário para uma ampla variedade de recursos e políticas do Google Cloud. As ferramentas de automação podem usar o snapshot para monitoramento ou para aplicação de políticas, ou as ferramentas podem arquivar o snapshot para auditoria de conformidade. Se você quiser analisar as alterações nos recursos, o inventário de recursos também permitirá exportar o histórico de metadados.

Para mais informações sobre o Inventário de recursos do Cloud, consulte Solução personalizada para responder a alterações de recursos e Controles de detecção.

Automatizar o gerenciamento de recursos

A automação permite criar e gerenciar recursos rapidamente com base nos requisitos de segurança que você especificar. É possível automatizar aspectos dos ciclos de vida do recurso das seguintes maneiras:

• Implante sua infraestrutura em nuvem usando ferramentas de automação, como o Terraform. O Google Cloud fornece o blueprint de bases empresariais, que ajuda a configurar recursos de infraestrutura que atendem às práticas recomendadas de segurança. Além disso, ele configura as mudanças de recursos e as notificações de conformidade com a política no Cloud Asset Inventory.
• Implante seus aplicativos usando ferramentas de automação, como o Cloud Run e o Artifact Registry.

Monitorar os desvios de suas políticas de conformidade

Os desvios das políticas podem ocorrer durante todas as fases do ciclo de vida do recurso. Por exemplo, recursos podem ser criados sem os controles de segurança adequados ou seus privilégios podem ser escalonados. Da mesma forma, os recursos podem ser abandonados sem os procedimentos de fim de vida útil apropriados.

Para ajudar a evitar esses cenários, recomendamos que você monitore os recursos para evitar desvios em relação à conformidade. O conjunto de recursos monitorados depende dos resultados da avaliação de risco e dos requisitos de negócios. Para mais informações sobre como monitorar recursos, consulte Como monitorar alterações de recursos.

Integrar com os sistemas de monitoramento de gerenciamento de recursos existentes

Se você já usa um sistema SIEM ou outro sistema de monitoramento, integre seus recursos do Google Cloud a esse sistema. A integração garante que sua organização tenha uma visão única e abrangente de todos os recursos, independentemente do ambiente. Para mais informações, consulte Exportar dados de segurança do Google Cloud para o sistema SIEM e Cenários para exportar dados do Cloud Logging: Splunk.

Usar a análise de dados para enriquecer o monitoramento

É possível exportar seu inventário para uma tabela do BigQuery ou o bucket do Cloud Storage para análise adicional.

A seguir

Saiba mais sobre como gerenciar seus recursos com os seguintes recursos:

• Gerenciar identidade e acesso (próximo documento desta série)
• Gerenciamento de recursos
• Design do sistema

Gerenciar identidade e acesso

Neste documento, você encontra as práticas recomendadas para gerenciar identidade e acesso no Framework da arquitetura do Google Cloud.

A prática de identificar e gerenciar o acesso (também conhecido como IAM) ajuda a garantir que as pessoas certas consigam acessar os recursos certos. O IAM aborda os seguintes aspectos da autenticação e autorização:

• Gerenciamento de conta, incluindo o provisionamento
• Governança da identidade
• Autenticação
• Controle de acesso (autorização)
• Federação da identidade

O gerenciamento de IAM pode ser um desafio quando você tem ambientes diferentes ou usa vários provedores de identidade. No entanto, é fundamental configurar um sistema que atenda aos requisitos da sua empresa e reduza os riscos.

As recomendações neste documento ajudam você a revisar as políticas e os procedimentos atuais do IAM e determinar quais deles podem ser necessários para modificar suas cargas de trabalho no Google Cloud. Por exemplo, revise o seguinte:

• Se você pode usar grupos existentes para gerenciar o acesso ou criar novos grupos.
• Seus requisitos de autenticação (como autenticação multifator (MFA)) usando um token.
• O impacto das contas de serviço nas suas políticas atuais.
• Se você estiver usando o Google Cloud para recuperação de desastres, manter a separação apropriada de tarefas.

No Google Cloud, você usa o Cloud Identity para autenticar seus usuários e recursos e o produto de gerenciamento de identidade e acesso (IAM) do Google para ditar o acesso a recursos. Os administradores podem restringir o acesso nos níveis da organização, da pasta, do projeto e do recurso. As políticas do Google IAM determinam quem pode fazer o que e em quais recursos. As políticas de IAM configuradas corretamente ajudam a proteger o ambiente impedindo o acesso não autorizado a recursos.

Para mais informações, consulte Visão geral do gerenciamento de identidade e acesso.

Usar um único provedor de identidade

Muitos de nossos clientes têm contas de usuário gerenciadas e provisionadas por provedores de identidade fora do Google Cloud. O Google Cloud é compatível com federação na maioria dos provedores de identidade e com diretórios locais, como o Active Directory.

A maioria dos provedores de identidade permite que você ative o Logon único (SSO) para seus usuários e grupos. Para aplicativos que você implanta no Google Cloud e que usam seu provedor de identidade externo, é possível estender seu provedor de identidade para o Google Cloud. Para mais informações, consulte Arquiteturas de referência e Padrões para autenticação de usuários corporativos em um ambiente híbrido.

Se você não tiver um provedor de identidade atual, poderá usar o Cloud Identity Premium ou o Google Workspace para gerenciar identidades. para seus funcionários.

Proteger a conta de superadministrador

A conta de superadministrador (gerenciada pelo Google Workspace ou pelo Cloud Identity) permite que você crie sua organização do Google Cloud. Portanto, esta conta de administrador é altamente privilegiada. As práticas recomendadas para esta conta incluem o seguinte:

• Criar uma nova conta para essa finalidade não usem uma conta de usuário existente.
• Crie e proteja as contas de backup.
• Ative a MFA.

Para mais informações, consulte Práticas recomendadas para contas de superadministrador.

Planejar o uso de contas de serviço

Uma conta de serviço é uma Conta do Google que os aplicativos podem usar para chamar a API Google de um serviço.

Ao contrário das suas contas de usuário, as contas de serviço são criadas e gerenciadas no Google Cloud. As contas de serviço também são autenticadas de maneira diferente das contas de usuário:

• Para permitir que um aplicativo em execução no Google Cloud seja autenticado usando uma conta de serviço, é possível anexar uma conta de serviço ao recurso de computação em que o aplicativo é executado.
• Para permitir que um aplicativo em execução no GKE seja autenticado com uma conta de serviço, é possível usar a Identidade da carga de trabalho.
• Para permitir que aplicativos executados fora do Google Cloud sejam autenticados usando uma conta de serviço, é possível usar a Federação de Identidade da carga de trabalho

Ao usar contas de serviço, considere uma segregação adequada de tarefas durante o processo de design. Observe as chamadas de API que você precisa fazer e determine as contas de serviço e os papéis associados que as chamadas de API exigem. Por exemplo, se você estiver configurando um armazenamento de dados do BigQuery, provavelmente precisará de identidades para pelo menos os seguintes processos e serviços:

• Cloud Storage ou Pub/Sub, dependendo se você está fornecendo um arquivo em lote ou criando um serviço de streaming.
• Dataflow e Proteção de dados confidenciais para desidentificar dados confidenciais.

Para mais informações, consulte Práticas recomendadas para trabalhar com contas de serviço.

Atualizar processos de identidade para a nuvem

A governança de identidade permite rastrear acesso, riscos e violações da política para que você atenda aos requisitos regulamentares. Essa governança exige que você tenha processos e políticas em vigor para poder conceder e auditar papéis e permissões de controle de acesso aos usuários. Seus processos e políticas precisam refletir os requisitos dos seus ambientes, por exemplo, teste, desenvolvimento e produção.

Antes de implantar cargas de trabalho no Google Cloud, revise os processos atuais de identidade e atualize-os, se apropriado. Certifique-se de planejar adequadamente os tipos de conta necessários para sua organização e entender bem os papéis e requisitos de acesso dela.

Para ajudar você a auditar as atividades do IAM do Google, o Google Cloud cria registros de auditoria, que incluem o seguinte:

• Atividade do administrador. Não é possível desativar a geração de registros.
• Atividade de acesso a dados. É preciso ativar essa geração de registros.

Se necessário, para fins de compliance ou se você quiser configurar a análise de registros (por exemplo, com o sistema SIEM), é possível exportar os registros. Como os registros podem aumentar os requisitos de armazenamento, eles podem afetar seus custos. Registre apenas as ações necessárias e defina programações de retenção adequadas.

Configurar o SSO e o MFA

Seu provedor de identidade gerencia a autenticação da conta de usuário. As identidades federadas podem ser autenticadas no Google Cloud usando o SSO. Para contas com privilégios, como superadministradores, configure a MFA. As chaves de segurança Titan são tokens físicos que podem ser usados na autenticação de dois fatores (2FA, na sigla em inglês) para evitar ataques de phishing.

O Cloud Identity é compatível com a MFA usando vários métodos. Para mais informações, consulte Aplicar MFA uniforme aos recursos da empresa.

O Google Cloud é compatível com a autenticação de identidades de carga de trabalho usando o protocolo OAuth 2.0 ou os JSON Web Tokens (JWT) assinados. Para mais informações sobre a autenticação de carga de trabalho, consulte Visão geral da autenticação.

Implementar o menor privilégio e a separação de tarefa

É preciso garantir que as pessoas certas tenham acesso apenas aos recursos e serviços necessários para executar os jobs. Ou seja, siga o princípio do menor privilégio. Além disso, é preciso garantir uma separação apropriada de tarefas.

O provisionamento excessivo do acesso do usuário pode aumentar o risco de ameaças internas, recursos configurados incorretamente e não conformidade com as auditorias. O subprovisionamento de permissões pode impedir que os usuários acessem os recursos necessários para concluir as tarefas.

Uma forma de evitar o superprovisionamento é implementar acesso privilegiado na hora certa, ou seja, fornecer acesso privilegiado somente conforme necessário e conceder esse privilégio temporariamente.

Quando uma organização do Google Cloud é criada, todos os usuários no domínio recebem os papéis Criador do projeto e Criador da conta de faturamento por padrão. Identifique os usuários que realizarão essas tarefas e revogue esses papéis de outros usuários. Para saber mais, consulte Como criar e gerenciar organizações.

Para mais informações sobre como os papéis e as permissões funcionam no Google Cloud, consulte Visão geral e Noções básicas sobre papéis na documentação do IAM. Para mais informações sobre como aplicar o privilégio mínimo, consulte Aplicar o menor privilégio com recomendações de papel.

Acesso à auditoria

Para monitorar as atividades de contas privilegiadas para desvios de condições aprovadas, use os registros de auditoria do Cloud. Os registros de auditoria do Cloud gravam as ações que os membros da sua organização no Google Cloud realizaram nos recursos do Google Cloud. É possível trabalhar com vários tipos de registro de auditoria em todos os serviços do Google. Para mais informações, consulte Como usar os registros de auditoria do Cloud para ajudar a gerenciar o risco de pessoas com informações privilegiadas (vídeo em inglês).

Use o recomendador do IAM para rastrear o uso e ajustar as permissões quando apropriado. Os papéis recomendados pelo recomendador do IAM podem ajudar a determinar quais papéis conceder a um usuário com base no comportamento anterior dele e em outros critérios. Para mais informações, consulte Práticas recomendadas para recomendações de papéis.

Para auditar e controlar o acesso aos seus recursos pela equipe de suporte e engenharia do Google, use a transparência no acesso. A transparência no acesso registra as ações realizadas pela equipe do Google. Use a Aprovação de acesso, que faz parte da transparência no acesso, para conceder aprovação explícita sempre que o conteúdo do cliente for acessado. Veja mais informações em Controlar o acesso dos administradores da nuvem aos seus dados.

Automatize seus controles de política

Defina as permissões de acesso de maneira programática sempre que possível. Para conferir as práticas recomendadas, consulte Restrições de políticas da organização. Os scripts do Terraform para o blueprint de bases empresariais estão no repositório de exemplo de bases.

O Google Cloud inclui o Policy Intelligence, que permite revisar e atualizar automaticamente suas permissões de acesso. A Inteligência de políticas inclui as ferramentas Recomendações, Solucionador de problemas e Análise de políticas, O que:

• Forneça recomendações para a atribuição de papéis do IAM.
• Monitore e ajude a evitar políticas do IAM excessivamente permissivas.
• Receba ajuda para resolver problemas relacionados ao controle de acesso.

Definir restrições nos recursos

O IAM do Google se concentra em quem e permite autorizar quem pode executar ações em recursos específicos com base nas permissões. de dados. O serviço de política da organização se concentra no quê e permite definir restrições nos recursos para especificar como eles podem ser configurados. Por exemplo, é possível usar uma política da organização para fazer o seguinte:

• limite o compartilhamento de recursos com base no domínio;
• Limitar o uso de contas de serviço.
• restrinja a localização física dos recursos recém-criados.

Além de usar as políticas da organização para essas tarefas, é possível restringir o acesso a recursos usando um dos seguintes métodos:

• Use tags para gerenciar o acesso aos recursos sem definir as permissões de acesso em cada um. Em vez disso, você adiciona a tag e define a definição de acesso dela.
• Use as condições do IAM para ter controle extra baseado em atributos do acesso aos recursos.
• Implemente a defesa em profundidade usando o VPC Service Controls para restringir ainda mais o acesso aos recursos.

Para saber mais sobre gerenciamento de recursos, consulte Gerenciamento de recursos.

A seguir

Saiba mais sobre o IAM com os seguintes recursos:

• Implemente a segurança de computação e contêineres (próximo documento desta série)

• Como usar o IAM com segurança

• Arquiteturas de referência

• Recomendador do IAM: privilégio mínimo com menos esforço

• Privacidade de dados do Cloud

• Visão geral do gerenciamento de identidade e acesso

Implemente a segurança de contêineres e computação

O Google Cloud inclui controles para proteger seus recursos de computação e recursos de contêiner do Google Kubernetes Engine (GKE). Este documento no Framework da arquitetura do Google Cloud descreve os principais controles e práticas recomendadas para usá-los.

Usar imagens de VM com aumento de proteção e selecionadas

O Google Cloud inclui uma VM protegida, que permite aumentar a proteção das instâncias de VM. A VM protegida foi projetada para evitar que códigos maliciosos sejam carregados durante o ciclo de inicialização. Ele fornece segurança de inicialização, monitora a integridade e usa o Módulo da plataforma virtual confiável (vTPM). Use VMs protegidas para cargas de trabalho confidenciais.

Além de usar a VM protegida, é possível usar as soluções do Google Cloud Partner para proteger ainda mais suas VMs. Muitas soluções de parceiros oferecidas no Google Cloud se integram ao Security Command Center, que oferece detecção de ameaças a eventos e monitoramento de integridade. Use parceiros para análise avançada de ameaças ou segurança extra no ambiente de execução.

Use a Computação confidencial para processar dados confidenciais

Por padrão, o Google Cloud criptografa dados em repouso e em trânsito na rede, mas eles não são criptografados enquanto estão em uso na memória. Se sua organização lida com dados confidenciais, você precisa reduzir as ameaças que comprometem a confidencialidade e a integridade do aplicativo ou dos dados na memória do sistema. Os dados confidenciais incluem informações de identificação pessoal (PII), dados financeiros e informações de saúde.

A computação confidencial é criada com base na VM protegida. Ele protege os dados em uso ao executar a computação em um ambiente de execução confiável baseado em hardware. Esse tipo de ambiente seguro e isolado ajuda a evitar o acesso ou a modificação não autorizado de aplicativos e dados enquanto esses dados estão em uso. Um ambiente de execução confiável também aumenta as garantias de segurança para organizações que gerenciam dados confidenciais e regulamentados.

No Google Cloud, é possível ativar a Computação confidencial executando VMs confidenciais ou nós confidenciais do GKE. Ative a Computação confidencial ao processar cargas de trabalho confidenciais ou quando você tiver dados confidenciais (por exemplo, secrets) que precisam ser expostos durante o processamento. Para mais informações, consulte o Consórcio para computação confidencial.

Proteger VMs e contêineres

O Login do SO permite que os funcionários se conectem às VMs usando as permissões do gerenciamento de identidade e acesso (IAM, na sigla em inglês) como a fonte confiável, em vez de confiar Chaves SSH. Portanto, não é necessário gerenciar chaves SSH em toda a organização. O login do SO vincula o acesso de um administrador ao ciclo de vida do funcionário. Isso significa que, se os funcionários mudarem para outro papel ou sairem da organização, o acesso deles será revogado com a conta. O Login do SO também é compatível com a autenticação de dois fatores, que adiciona uma camada extra de segurança contra ataques de invasão de conta.

No GKE, o App Engine executa instâncias de aplicativos em contêineres do Docker. Para ativar um perfil de risco definido e impedir que os funcionários façam alterações nos contêineres, verifique se os contêineres são sem estado e imutáveis. O princípio de imutabilidade significa que os funcionários não modificam o contêiner nem o acessam interativamente. Se precisar mudá-la, crie uma nova imagem e implante novamente. Ative o acesso SSH aos contêineres subjacentes somente em cenários de depuração específicos.

Desative os endereços IP externos, a menos que eles sejam necessários.

Para desativar a alocação de endereços IP externos (vídeo) das VMs de produção e para impedir o uso de balanceadores de carga externos, use as políticas da organização. Se você precisar que suas VMs acessem a Internet ou o data center no local, ative um gateway da Cloud NAT.

É possível implantar clusters particulares no GKE. Em um cluster particular, os nós têm endereços IP internos, o que significa que os nós e os pods estão isolados da Internet por padrão. Também é possível definir a política de rede para gerenciar a comunicação entre pods no cluster. Para mais informações, consulte Opções de acesso privado para serviços.

Monitorar o uso da instância de computação e do GKE

Os registros de auditoria do Cloud são ativados automaticamente para o Compute Engine e o GKE. Os registros de auditoria permitem que você capture automaticamente todas as atividades com seu cluster e monitore qualquer atividade suspeita.

Integre o GKE a produtos de parceiros para garantir a segurança do ambiente de execução. É possível integrar essas soluções ao Security Command Center para disponibilizar uma única interface para monitorar os aplicativos.

Mantenha suas imagens e clusters atualizados

O Google Cloud fornece imagens de SO selecionadas que são corrigidas regularmente. É possível trazer imagens personalizadas e executá-las no Compute Engine. No entanto, se fizer isso, você mesmo precisará corrigi-las. O Google Cloud atualiza regularmente as imagens do SO para mitigar novas vulnerabilidades, conforme descrito nos boletins de segurança, e fornece soluções para corrigir vulnerabilidades de implantações atuais.

Se você estiver usando o GKE, recomendamos ativar o upgrade automático do nó para que o Google atualize os nós do cluster com os patches mais recentes. O Google gerencia planos de controle do GKE, que são atualizados e corrigidos automaticamente. Além disso, na implantação, use imagens otimizadas para contêineres selecionadas pelo Google. O Google corrige e atualiza essas imagens regularmente.

Controlar o acesso a imagens e clusters

É importante saber quem pode criar e iniciar instâncias. É possível controlar esse acesso usando o IAM. Para informações sobre como determinar qual é o acesso às cargas de trabalho, consulte Planejar as identidades das cargas de trabalho.

Além disso, é possível usar o VPC Service Controls para definir cotas personalizadas em projetos a fim de limitar quem pode iniciar imagens. Para mais informações, consulte a seção Proteger sua rede.

Para garantir a segurança da infraestrutura do cluster, o GKE permite usar o IAM com controle de acesso baseado em papéis (RBAC, na sigla em inglês) para gerenciar o acesso ao cluster e aos namespaces.

Isolar contêineres em um sandbox

Use o GKE Sandbox para implantar aplicativos multilocatários que precisam de uma camada extra de segurança e isolamento do kernel do host. Por exemplo, use o GKE Sandbox quando estiver executando código desconhecido ou não confiável. O GKE Sandbox é uma solução de isolamento de contêineres que aplica uma segunda camada de defesa entre cargas de trabalho em contêineres no GKE.

O GKE Sandbox foi criado para aplicativos com poucos requisitos de E/S, mas altamente escalonáveis. Essas cargas de trabalho em contêiner precisam manter o desempenho e a velocidade, mas também podem envolver códigos não confiáveis que demandam mais segurança. Use o gVisor, um sandbox de ambiente de execução de contêiner, para fornecer isolamento de segurança extra entre aplicativos e o kernel do host. O gVisor fornece verificações adicionais de integridade e limita o escopo de acesso a um serviço. Ele não é um serviço de proteção de contêiner contra ameaças externas. Para mais informações sobre o gVisor, consulte gVisor: proteger o GKE e usuários sem servidor no mundo real.

A seguir

Saiba mais sobre segurança de contêineres e computação com os seguintes recursos:

• Proteger sua rede (próximo documento desta série)
• Por que a segurança do contêiner é importante (PDF)
• Lista de verificação do lançamento do Google Cloud
• Como verificar a identidade das instâncias
• Identidade da carga de trabalho
• VM protegida
• Práticas recomendadas para snapshots de disco permanente
• Práticas recomendadas de gerenciamento de imagens

Proteger a rede

Neste documento no Framework da arquitetura do Google Cloud, você encontra as práticas recomendadas para proteger sua rede.

Estender sua rede atual para incluir ambientes de nuvem tem muitas implicações para a segurança. Sua abordagem local de defesa de várias camadas provavelmente inclui um perímetro distinto entre a Internet e sua rede interna. Provavelmente, você proteja o perímetro usando firewalls físicos, roteadores, sistemas de detecção de intrusões e assim por diante. Como o limite é claramente definido, é possível monitorar facilmente as intrusões e responder de acordo com elas.

Ao migrar para a nuvem (completamente ou em uma abordagem híbrida), você passa para além do perímetro local. Neste documento, descrevemos maneiras de manter a segurança dos dados e cargas de trabalho da sua organização no Google Cloud. Conforme mencionado em Gerenciar riscos com controles, a configuração e a segurança da rede do Google Cloud dependem dos requisitos da empresa e do apetite ao risco.

Nesta seção, presume-se que você já leu a seção Rede na categoria Design do sistema e já criou um diagrama básico de arquitetura dos seus componentes de rede do Google Cloud. Para um exemplo de diagrama, consulte Hub-and-spoke.

Implantar redes de confiança zero

Migrar para a nuvem significa que o modelo de confiança da sua rede precisa mudar. Como os usuários e as cargas de trabalho não estão mais atrás do perímetro local, não é possível usar proteções de perímetro da mesma maneira para criar uma rede interna confiável. O modelo de segurança de confiança zero significa que ninguém é confiável por padrão, estejam eles dentro ou fora da rede da sua organização. Ao verificar as solicitações de acesso, o modelo de segurança de confiança zero exige que você verifique a identidade e o contexto do usuário. Ao contrário da VPN, você transfere os controles de acesso do perímetro de rede para os usuários e dispositivos.

No Google Cloud, é possível usar o BeyondCorp Enterprise como sua solução de confiança zero. O BeyondCorp Enterprise oferece proteção contra dados e ameaças e outros controles de acesso. Para mais informações sobre como configurar, consulte Primeiros passos com o BeyondCorp Enterprise.

Além do BeyondCorp Enterprise, o Google Cloud inclui o Identity-Aware Proxy (IAP). Com o IAP, é possível aumentar a segurança de confiança zero para seus aplicativos no Google Cloud e no local. O IAP usa políticas de controle de acesso para fornecer autenticação e autorização aos usuários que acessam seus aplicativos e recursos.

Proteja as conexões com seus ambientes locais ou de várias nuvens

Muitas organizações têm cargas de trabalho em ambientes de nuvem e no local. Além disso, para resiliência, algumas organizações usam soluções de várias nuvens. Nesses cenários, é essencial proteger a conectividade entre todos os seus ambientes.

O Google Cloud inclui métodos de acesso particular para VMs com suporte do VPN do Cloud ou Cloud Interconnect , incluindo estes:

• UseInterconexão entre nuvens , como um serviço gerenciado, para vincular suas redes VPC a outrosprovedores de nuvem compatíveis em conexões diretas de alta velocidade. Com o Cross-Cloud Interconnect, você não precisa fornecer seu próprio roteador ou trabalhar com um fornecedor terceirizado.
• Use a Interconexão dedicada e a Interconexão por parceiro para vincular suas redes VPC ao data center local ou a outros provedores de nuvem por conexões diretas de alta velocidade.
• Use as VPNs IPsec para vincular suas redes de nuvem privada virtual (VPC, na sigla em inglês) ao seu data center local ou a outros provedores de nuvem.
• Use os endpoints do Private Service Connect para acessar os serviços publicados que são fornecidos por sua organização ou por outro provedor.
• Use os endpoints do Private Service Connect para permitir que suas VMs acessem as APIs do Google usando endereços IP internos. Com o Private Service Connect, as VMs não precisam ter endereços IP externos para acessar os serviços do Google.
• Se você usa o GKE Enterprise, considere os gateways de saída do Anthos Service Mesh. Se você não usa o GKE Enterprise, use uma opção de terceiros.

Para uma comparação entre os produtos, consulte Como escolher um produto de conectividade de rede.

Desativar redes padrão

Quando você cria um novo projeto do Google Cloud, uma rede VPC padrão do Google Cloud com endereços IP e modo automático Regras de firewall pré-preenchidas são provisionadas automaticamente. Para implantações de produção, recomendamos que você exclua as redes padrão dos projetos atuais e desative a criação de redes padrão nos novos projetos.

Com as redes de nuvem privada virtual, você pode usar qualquer endereço IP interno. Para evitar conflitos de endereço IP, recomendamos planejar primeiro a alocação de rede e endereço IP nas implantações conectadas e nos projetos. Um projeto permite várias redes VPC, mas geralmente é uma prática recomendada limitar essas redes a uma por projeto para aplicar o controle de acesso com eficiência.

Proteger seu perímetro

No Google Cloud, é possível usar vários métodos para segmentar e proteger seu perímetro de nuvem, incluindo firewalls e VPC Service Controls.

Use a VPC compartilhada para criar uma implantação de produção que ofereça uma única rede compartilhada e que isole cargas de trabalho em projetos individuais que podem ser gerenciados por equipes diferentes. Ela oferece implantação centralizada, gerenciamento e controle de recursos de segurança de rede e rede em vários projetos. A VPC compartilhada consiste em projetos host e de serviço que executam as seguintes funções:

• Um projeto host contém recursos relacionados à segurança de rede e rede, como redes VPC, sub-redes, regras de firewall e conectividade híbrida.
• Um projeto de serviço é anexado a um projeto host. Ele permite isolar cargas de trabalho e usuários no nível do projeto usando o gerenciamento de identidade e acesso (IAM), enquanto compartilha os recursos de rede do projeto host gerenciado centralmente.

Defina políticas e regras de firewall no nível da organização, da pasta e da rede VPC. É possível configurar regras de firewall para permitir ou negar o tráfego de instâncias de VM. Para exemplos, consulte Exemplos de políticas de firewall de rede globais e regionais e Exemplos de políticas hierárquicas de firewall. Além de definir regras com base em endereços IP, protocolos e portas, é possível gerenciar o tráfego e aplicar regras de firewall com base na conta de serviço usada por uma instância de VM. ou usando tags seguras.

Para controlar a movimentação de dados nos serviços do Google e configurar a segurança de perímetro baseada em contexto, considere usar o VPC Service Controls. O VPC Service Controls fornece uma camada extra de segurança para os serviços do Google Cloud, independente de regras e políticas de firewall do IAM. Por exemplo, o VPC Service Controls permite a configuração de perímetros entre dados confidenciais e não confidenciais para que você possa aplicar controles que ajudam a evitar a exfiltração de dados.

Com as políticas de segurança do Google Cloud Armor, você permite, nega ou redireciona solicitações para o balanceador de carga de aplicativo externo na conexão do Google Cloud, o mais próximo possível da origem do tráfego de entrada. Essas políticas impedem que o tráfego indesejado consumir recursos ou entrar na rede.

Use o proxy da Web seguro para aplicar políticas de acesso granulares ao tráfego de saída da Web e para monitorar o acesso a serviços da Web não confiáveis.

Inspecionar o tráfego da sua rede

É possível usar o Cloud IDS e o Espelhamento de pacotes para garantir a segurança e a conformidade das cargas de trabalho em execução no Compute Engine e no Google Kubernetes Engine (GKE). .

Use o Sistema de detecção de intrusões do Cloud (atualmente em visualização) para ter visibilidade do tráfego de entrada e saída das suas redes VPC. O Cloud IDS cria uma rede com peering gerenciada pelo Google que espelha VMs. As tecnologias de proteção contra ameaças da Palo Alto Networks espelham e inspecionam o tráfego. Para mais informações, consulte a Visão geral do Cloud IDS.

O espelhamento de pacotes clona o tráfego de instâncias de VM especificadas na rede VPC e o encaminha para coleta, retenção e exame. Depois de configurar o espelhamento de pacotes, é possível usar o Cloud IDS ou ferramentas de terceiros para coletar e inspecionar o tráfego de rede em grande escala. Inspecionar o tráfego de rede dessa maneira ajuda a fornecer detecção de intrusões e monitoramento de desempenho de aplicativos.

Usar um firewall de aplicativos da Web

Para aplicativos e serviços externos da Web, ative o Google Cloud Armor para fornecer recursos distribuídos de proteção contra negação de serviço (DDoS) e firewall de aplicativos da Web (WAF). O Google Cloud Armor é compatível com cargas de trabalho do Google Cloud que são expostas usando balanceamento de carga HTTP(S) externo, de proxy TCP ou de proxy SSL.

O Google Cloud Armor é oferecido em dois níveis de serviço: Standard e Managed Protection Plus: Para aproveitar ao máximo os recursos avançados do Google Cloud Armor, você precisa investir no Managed Protection Plus para suas cargas de trabalho importantes.

Automatização do provisionamento de infraestrutura

A automação permite criar uma infraestrutura imutável, o que significa que não pode ser alterada após o provisionamento. Essa medida oferece à sua equipe de operações um bom estado conhecido, reversão rápida e recursos de solução de problemas. Para automação, use ferramentas como o Terraform, o Jenkins e o Cloud Build.

Para ajudar você a criar um ambiente que usa automação, o Google Cloud fornece uma série de blueprints de segurança que, por sua vez, são criados no blueprint de bases empresariais. O modelo de base de segurança fornece o design opinativo do Google para um ambiente de aplicativos seguro e descreve passo a passo como configurar e implantar sua propriedade do Google Cloud. Usando as instruções e os scripts que fazem parte do blueprint de bases de segurança, é possível configurar um ambiente que atenda às nossas práticas recomendadas e diretrizes de segurança. Você pode criar nesse blueprint com outros modelos ou projetar sua própria automação.

Para mais informações sobre automação, consulte Usar um pipeline de CI/CD para fluxos de trabalho de processamento de dados.

Monitorar a rede

Monitore sua rede e seu tráfego usando telemetria

Os registros de fluxo de VPC e a geração de registros das regras de firewall oferecem visibilidade quase em tempo real do tráfego e do uso do firewall no seu ambiente do Google Cloud de dados. Por exemplo, a geração de registros de regras de firewall registra o tráfego de e para instâncias de VM do Compute Engine. Ao combinar essas ferramentas com o Cloud Logging e o Cloud Monitoring, é possível rastrear, alertar e visualizar o tráfego. e padrões de acesso para melhorar a segurança operacional da implantação.

A ferramenta Firewall Insights permite que você verifique quais regras de firewall corresponderam às conexões de entrada e saída e se as conexões foram permitidas ou negadas. O recurso de regras sombreadas ajuda a ajustar a configuração do firewall mostrando quais regras nunca são acionadas porque outra regra é sempre acionada primeiro.

Use o Network Intelligence Center para ver o desempenho da topologia e da arquitetura da rede. É possível receber insights detalhados sobre o desempenho da rede e otimizar a implantação para eliminar gargalos no serviço. Os testes de conectividade fornecem insights sobre as regras e políticas de firewall que são aplicadas ao caminho da rede.

Para mais informações sobre monitoramento, consulte Implementar a geração de registros e os controles de detetive.

A seguir

Saiba mais sobre segurança de rede com os seguintes recursos:

• Implemente a segurança dos dados (próximo documento desta série)
• Práticas recomendadas e arquiteturas de referência para o design da VPC
• Papéis do IAM para administrar o VPC Service Controls
• Como fazer integração como um parceiro do Security Command Center
• Como visualizar vulnerabilidades e ameaças no Security Command Center
• Espelhamento de pacotes: visualize e proteja sua rede em nuvem
• Como usar o Espelhamento de pacotes para detecção de intrusões
• Como usar o Espelhamento de pacotes com uma solução de IDS do parceiro

Implementar a segurança de dados

Neste documento, você encontra as práticas recomendadas para implementar a segurança dos dados no Framework da arquitetura do Google Cloud.

Como parte da arquitetura de implantação, você precisa considerar quais dados planeja processar e armazenar no Google Cloud e a confidencialidade dos dados. Projete os controles para proteger os dados durante o ciclo de vida deles, identificar a propriedade e a classificação de dados e proteger dados contra uso não autorizado.

Para um blueprint de segurança que implanta um data warehouse do BigQuery com as práticas recomendadas de segurança descritas neste documento, consulte Proteger um data warehouse do BigQuery que armazena dados confidenciais.

Classificar seus dados automaticamente

Realize a classificação de dados no início do ciclo de vida do gerenciamento de dados, o ideal, quando os dados são criados. Os esforços de classificação de dados geralmente exigem apenas algumas categorias, como as seguintes:

• Público: dados aprovados para acesso público.
• Internos: dados não confidenciais que não são liberados para o público.
• Confidencial: dados confidenciais disponíveis para distribuição interna geral.
• Restrito: dados altamente confidenciais ou regulamentados que exigem distribuição restrita.

Use a Proteção de dados confidenciais para descobrir e classificar dados no ambiente do Google Cloud. A proteção de dados confidenciais tem suporte integrado para verificar e classificar dados confidenciais no Cloud Storage, no BigQuery e Datastore. Ela também tem uma API de streaming para oferecer suporte a outras fontes de dados e cargas de trabalho personalizadas.

A proteção de dados confidenciais pode identificar dados confidenciais usando InfoTypes integrados. Ele pode classificar, mascarar, tokenizar e transformar automaticamente elementos confidenciais (como dados de PII) para permitir que você gerencie o risco de coletar, armazenar e usar dados. Em outras palavras, ela pode ser integrada aos processos de ciclo de vida dos dados para garantir que os dados em todos os estágios estejam protegidos.

Para mais informações, consulte Desidentificação e reidentificação de PII em conjuntos de dados de grande escala usando a proteção de dados confidenciais.

Gerenciar a governança de dados usando metadados

A governança de dados é uma combinação de processos que garantem que os dados sejam seguros, privados, precisos, disponíveis e utilizáveis. Embora você seja responsável por definir uma estratégia de governança de dados para sua organização, o Google Cloud fornece ferramentas e tecnologias para ajudar a colocar sua estratégia em prática. O Google Cloud também fornece um framework para governança de dados (PDF) na nuvem.

Use o Data Catalog para encontrar, selecionar e usar metadados para descrever seus recursos de dados na nuvem. Você pode usar o Data Catalog para procurar recursos de dados e incluir tags nos metadados. Para acelerar seus esforços de classificação de dados, integre o Data Catalog à Proteção de dados sensíveis para identificar automaticamente dados sensíveis. Depois que os dados forem marcados, é possível usar o Google Identity and Access Management (IAM) para restringir quais dados os usuários podem consultar ou usar por meio das visualizações do Data Catalog.

Use o Metastore do Dataproc ou o metastore do Hive para gerenciar metadados de cargas de trabalho. O Data Catalog tem um conector do Hive que permite que o serviço descubra metadados dentro de um metastore do Hive.

Use o Dataprep by Trifacta para definir e aplicar regras de qualidade de dados por meio de um console. Use o Dataprep no Cloud Data Fusion ou use o Dataprep como um serviço independente.

Proteger os dados de acordo com a fase do ciclo de vida e a classificação

Depois de definir os dados no contexto do ciclo de vida e classificá-los com base na sensibilidade e risco, você pode atribuir os controles de segurança corretos para protegê-los. É preciso garantir que os controles forneçam proteções adequadas, atendam aos requisitos de conformidade e reduzam os riscos. you medida que você migra para a nuvem, revise sua estratégia atual e onde pode ser necessário alterar os processos atuais.

A tabela a seguir descreve três características de uma estratégia de segurança de dados na nuvem.

Característica	Descrição
Identificação	Entender a identidade de usuários, recursos e aplicativos à medida que criam, modificam, armazenam, usam, compartilham e excluem dados. Use o Cloud Identity e o IAM para controlar o acesso aos dados. Se suas identidades exigirem certificados, considere o Serviço de autoridade de certificação. Veja mais informações em Gerenciar identidade e acesso.
Limite e acesso	Configure controles para acessar os dados, por quem e em quais circunstâncias. Os limites de acesso aos dados podem ser gerenciados nesses níveis: Acesso à camada da rede usando controles como o Cloud Firewall. Para mais insights sobre sua camada de rede, use o Network Intelligence Center. Use o VPC Service Controls para criar perímetros que protegem os recursos e os dados dos serviços que você especifica. Controles de acesso do IAM usando o IAM. Para informações sobre como gerenciar papéis do IAM, consulte Como usar hierarquias de recursos para controle de acesso.
Visibilidade	É possível auditar o uso e criar relatórios que demonstram como os dados são controlados e acessados. O Google Cloud Logging e a transparência no acesso fornecem insights sobre as atividades dos seus próprios administradores e usuários da nuvem. Para mais informações, consulte Monitorar seus dados.

Criptografar seus dados

Por padrão, o Google Cloud criptografa dados de clientes armazenados em repouso sem que você tenha que intervir no processo. Além da criptografia padrão, o Google Cloud oferece opções para criptografia de envelopes e gerenciamento de chaves de criptografia. Por exemplo, os discos permanentes do Compute Engine são criptografados automaticamente, mas é possível fornecer ou gerenciar suas próprias chaves.

Identifique as soluções que melhor se adaptam às suas necessidades de geração, armazenamento e rotação de chave, seja para chaves de armazenamento, computação ou cargas de trabalho de Big Data.

O Google Cloud inclui as seguintes opções de criptografia e gerenciamento de chaves:

• Chaves de criptografia gerenciadas pelo cliente (CMEK). É possível gerar e gerenciar suas chaves de criptografia usando o Cloud Key Management Service (Cloud KMS). Use essa opção se você tiver determinados requisitos de gerenciamento de chaves, como a necessidade de alternar as chaves de criptografia regularmente.
• Chaves de criptografia fornecidas pelo cliente (CSEK, na sigla em inglês). É possível criar e gerenciar suas próprias chaves de criptografia e fornecê-las ao Google Cloud quando necessário. Use essa opção se você gerar suas próprias chaves usando seu sistema de gerenciamento de chaves no local para trazer sua própria chave (BYOK). Se você fornecer suas próprias chaves usando a CSEK, o Google as replicará e as disponibilizará nas cargas de trabalho. No entanto, a segurança e a disponibilidade das CSEKs são de sua responsabilidade, porque as chaves fornecidas pelo cliente não são armazenadas em modelos de instância ou na infraestrutura do Google. Se você perder o acesso às chaves, o Google não poderá ajudar a recuperar os dados criptografados. Pense cuidadosamente sobre quais chaves você quer criar e gerenciar. Use a CSEK apenas para informações mais confidenciais. Outra opção é executar a criptografia do lado do cliente nos dados e armazená-los no Google Cloud, onde os dados são criptografados novamente pelo Google.
• Sistema de gerenciamento de chaves terceirizado com o Cloud External Key Manager (Cloud EKM). O Cloud EKM protege seus dados em repouso usando chaves de criptografia armazenadas e gerenciadas em um sistema de gerenciamento de chaves terceirizado que você controla fora da infraestrutura do Google. Ao usar esse método, você tem uma alta garantia de que seus dados não poderão ser acessados por ninguém de fora da sua organização. O Cloud EKM permite que você alcance um modelo seguro de "chave própria" (HYOK, na sigla em inglês) para o gerenciamento de chaves. Para informações de compatibilidade, consulte a lista de serviços ativados do Cloud EKM.

O Cloud KMS também permite criptografar seus dados com chaves de criptografia baseadas em software ou módulos de segurança de hardware (HSMs, na sigla em inglês) validados pelo nível 3 do FIPS 140-2. Se você estiver usando o Cloud KMS, suas chaves criptográficas serão armazenadas na região em que o recurso for implantado. O Cloud HSM distribui suas necessidades de gerenciamento de chaves nas regiões, fornecendo redundância e disponibilidade global de chaves.

Para informações sobre como a criptografia de envelopes funciona, consulte Criptografia em repouso no Google Cloud.

Controlar o acesso dos administradores da nuvem aos seus dados

É possível controlar o acesso da equipe de suporte e engenharia do Google ao seu ambiente no Google Cloud. O Access Approval permite que você aprove explicitamente antes que os funcionários do Google acessem seus dados ou recursos no Google Cloud. Esse produto complementa a visibilidade fornecida pela transparência no acesso, que gera registros quando a equipe do Google interage com seus dados. Esses registros incluem o local do escritório e o motivo do acesso.

Se você usar esses produtos juntos, poderá negar ao Google a capacidade de descriptografar seus dados por qualquer motivo.

Configurar o local de armazenamento dos seus dados e o local onde os usuários podem acessá-los

É possível controlar os locais de rede em que os usuários podem acessar dados usando o VPC Service Controls. Este produto permite limitar o acesso a usuários em uma região específica. É possível aplicar essa restrição mesmo se o usuário estiver autorizado de acordo com a política do Google IAM. Com o VPC Service Controls, é possível criar um perímetro de serviço que define os limites virtuais de onde um serviço pode ser acessado, evitando que os dados sejam movidos para além desses limites.

Para ver mais informações, consulte os seguintes tópicos:

• Como automatizar a classificação de dados enviados para o Cloud Storage
• Governança de dados na nuvem
• Governança de dados para armazenamento de dados no BigQuery
• O metastore do Cloud Hive agora está disponível

Gerenciar secrets usando o Secret Manager

O Secret Manager permite armazenar todos os secrets em um local centralizado. Secrets são informações de configuração, como senhas de bancos de dados, chaves de API ou certificados TLS. É possível alternar automaticamente as chaves secretas e configurar os aplicativos para usar automaticamente a versão mais recente de uma senha. Cada interação com o Gerenciador de secrets gera um registro de auditoria para você visualizar todos os acessos a cada secret.

A Proteção de dados sensíveis também tem uma categoria de detectores para ajudar a identificar credenciais e secrets em dados que podem ser protegidos com o Secret Manager.

Monitorar seus dados

Para ver a atividade do administrador e os registros de uso de chaves, utilize os registros de auditoria do Cloud. Para ajudar a proteger os dados, monitore os registros com o Cloud Monitoring para garantir o uso adequado das chaves.

O Cloud Logging captura eventos do Google Cloud e permite adicionar outras origens, se necessário. É possível segmentar os registros por região, armazená-los em buckets e integrar o código personalizado para o processamento de registros. Por exemplo, consulte Solução personalizada para análise automatizada de registros.

Também é possível exportar registros para o BigQuery para executar análises de segurança e acesso. Assim, é possível identificar alterações não autorizadas e acesso inadequado aos dados da organização.

O Security Command Center pode ajudar a identificar e resolver problemas de acesso não seguro a dados organizacionais confidenciais que são armazenados na nuvem. Com uma única interface de gerenciamento, é possível procurar uma variedade de vulnerabilidades e riscos de segurança na infraestrutura em nuvem. Por exemplo, é possível monitorar a exportação de dados, verificar os sistemas de armazenamento quanto a dados confidenciais e detectar quais buckets do Cloud Storage estão abertos para a Internet.

A seguir

Saiba mais sobre segurança de dados com os seguintes recursos:

• Implantar aplicativos com segurança (próximo documento desta série)

• Proteger um armazenamento de dados do BigQuery que armazena dados confidenciais

• Como projetar e implantar uma estratégia de segurança de dados (PDF)

• Como proteger seus dados com o Google Cloud Platform (PDF)

• Políticas de retenção usando o bloqueio de bucket

• Práticas recomendadas do Cloud Storage

• Práticas recomendadas para instâncias do SQL Server

• Práticas recomendadas do Datastore

• Data Catalog

Implante aplicativos com segurança

Este documento no Framework da arquitetura do Google Cloud fornece práticas recomendadas para implantar aplicativos com segurança.

Para implantar aplicativos seguros, você precisa ter um ciclo de vida de desenvolvimento de software bem definido, com verificações de segurança apropriadas durante as etapas de design, desenvolvimento, teste e implantação. Ao projetar um aplicativo, recomendamos uma arquitetura de sistema em camadas que use frameworks padronizados para identidade, autorização e controle de acesso.

Automatizar versões seguras

Sem ferramentas automatizadas, pode ser difícil implantar, atualizar e corrigir ambientes de aplicativos complexos para atender a requisitos de segurança consistentes. Por isso, recomendamos que você crie um pipeline de CI/CD para essas tarefas, o que pode resolver muitos desses problemas. Os pipelines automatizados removem erros manuais, fornecem loops padronizados de feedback de desenvolvimento e permitem iterações rápidas do produto. Por exemplo, os pools particulares do Cloud Build permitem implantar um pipeline de CI/CD gerenciado e altamente seguro para setores altamente regulamentados, incluindo finanças e saúde.

Use a automação para verificar vulnerabilidades de segurança quando os artefatos forem criados. Também é possível definir políticas para diferentes ambientes (desenvolvimento, teste, produção etc.) para que apenas artefatos verificados sejam implantados.

Verificar se as implantações do aplicativo seguem os processos aprovados

Se um invasor comprometer seu pipeline de CI/CD, toda a pilha poderá ser afetada. Para proteger o pipeline, aplique um processo de aprovação estabelecido antes de implantar o código na produção.

Se você planeja usar o Google Kubernetes Engine (GKE) ou o GKE Enterprise, estabeleça essas verificações e equilíbrios usando a autorização binária. A autorização binária anexa assinaturas configuráveis a imagens de contêiner. Essas assinaturas (também chamadas de atestados) ajudam a validar a imagem. Na implantação, a autorização binária usa esses atestados para determinar que um processo foi concluído anteriormente. Por exemplo, use a autorização binária para:

• Verificar se um sistema de compilação específico ou um pipeline de integração contínua (CI, na sigla em inglês) criou uma imagem de contêiner.
• Confira se uma imagem de contêiner está em conformidade com uma política de assinatura de vulnerabilidades.
• Verifique se uma imagem de contêiner transmite os critérios de promoção para o próximo ambiente de implantação, por exemplo, do desenvolvimento para o controle de qualidade.

Verificar vulnerabilidades conhecidas antes da implantação

Recomendamos o uso de ferramentas automatizadas que possam realizar continuamente verificações de vulnerabilidade em imagens de contêiner antes que os contêineres sejam implantados na produção.

Use o Artifact Analysis para verificar automaticamente vulnerabilidades em contêineres armazenados no Artifact Registry e no Container Registry. Esse processo inclui duas tarefas: verificação e análise contínua.

Para começar, o Artifact Analysis verifica novas imagens quando são enviadas ao Artifact Registry ou ao Container Registry. A verificação extrai informações sobre os pacotes do sistema no contêiner.

Em seguida, o Artifact Analysis procura vulnerabilidades quando você faz upload da imagem. Após a verificação inicial, o Artifact Analysis monitora continuamente os metadados de imagens verificadas no Artifact Registry e no Container Registry em busca de novas vulnerabilidades. Quando o Artifact Analysis recebe informações de vulnerabilidade novas e atualizadas de origens de vulnerabilidade, ele faz o seguinte:

• Atualiza os metadados das imagens digitalizadas para mantê-las atualizadas.
• Cria novas ocorrências de vulnerabilidade para novas notas.
• Exclui ocorrências de vulnerabilidade que não são mais válidas.

Monitorar o código do aplicativo contra vulnerabilidades conhecidas

É uma prática recomendada usar ferramentas automatizadas que possam monitorar constantemente o código do aplicativo para detectar vulnerabilidades conhecidas, como o OWASP Top 10. Para uma descrição dos produtos e recursos do Google Cloud compatíveis com as técnicas de mitigação do OWASP Top 10, consulte Opções de mitigação do OWASP Top 10 no Google Cloud.

Use o Web Security Scanner para ajudar a identificar vulnerabilidades de segurança nos aplicativos da Web do App Engine, Compute Engine e Google Kubernetes Engine. Ele rastreia seu aplicativo, seguindo todos os links no escopo dos URLs iniciais, e tenta acessar o máximo possível de entradas de usuário e manipuladores de eventos. Ele verifica e detecta automaticamente vulnerabilidades comuns, incluindo scripting em vários locais (XSS), injeção Flash, conteúdo misto (HTTP em HTTPS) e bibliotecas desatualizadas ou não seguras. O Web Security Scanner oferece identificação antecipada desses tipos de vulnerabilidades com baixas taxas de falso positivo.

Controlar a movimentação de dados entre perímetros

Para controlar a movimentação de dados em um perímetro, configure perímetros de segurança em torno dos recursos dos serviços gerenciados pelo Google. Use o VPC Service Controls para colocar todos os componentes e serviços no seu pipeline de CI/CD (por exemplo, Container Registry, Artifact Registry, Artifact Analysis e autorização binária) dentro de um perímetro de segurança.

Os VPC Service Controls melhoram sua capacidade de reduzir o risco de cópia ou transferência não autorizada de dados (exfiltração de dados) de serviços gerenciados pelo Google. Com VPC Service Controls, é possível configurar os perímetros de segurança em torno dos recursos dos serviços gerenciados pelo Google para controlar a movimentação de dados por todo o limite do perímetro. Quando um perímetro de serviço é aplicado, as solicitações que violam a política do perímetro são negadas, como as feitas para serviços protegidos de fora de um perímetro. Quando um serviço é protegido por um perímetro aplicado, o VPC Service Controls garante o seguinte:

• Um serviço não pode transmitir dados para fora do perímetro. Os serviços protegidos funcionam normalmente dentro do perímetro, mas não podem enviar recursos e dados para fora dele. Essa restrição ajuda a impedir que pessoas mal-intencionadas com informações privilegiadas tenham acesso a projetos no perímetro exfiltrem dados.
• As solicitações provenientes de fora do perímetro para o serviço protegido são atendidas somente se respeitarem os critérios dos níveis de acesso atribuídos ao perímetro.
• Esse serviço pode ser disponibilizado para projetos em outros perímetros usando pontes do perímetro.

Criptografar as imagens do contêiner

No Google Cloud, é possível criptografar as imagens de contêiner usando chaves de criptografia gerenciadas pelo cliente (CMEK). As chaves de CMEK são gerenciadas no Cloud Key Management Service (Cloud KMS). Ao usar o CMEK, você pode desativar temporariamente ou permanentemente o acesso a uma imagem de contêiner criptografada desativando ou destruindo a chave.

A seguir

Saiba mais sobre como proteger a cadeia de suprimentos e a segurança dos aplicativos com os seguintes recursos:

• Gerenciar obrigações de conformidade (próximo documento desta série)
• Excelência operacional
• Autorização binária
• Artifact Analysis
• Artifact Registry

Gerenciar obrigações de conformidade

Este documento no Framework da arquitetura do Google Cloud fornece práticas recomendadas para gerenciar obrigações de conformidade.

Os requisitos regulamentares para a nuvem dependem de uma combinação de fatores, incluindo:

• As leis e regulamentos que se aplicam ao local físico da sua organização.
• As leis e regulamentos que se aplicam ao local físico dos seus clientes.
• Requisitos regulamentares do setor.

Esses requisitos moldam muitas das decisões que você precisa tomar sobre quais controles de segurança ativar suas cargas de trabalho no Google Cloud.

Uma jornada típica de conformidade passa por três estágios: avaliação, remediação de lacunas e monitoramento contínuo. Nesta seção, você conhecerá as práticas recomendadas que podem ser usadas durante cada etapa.

Avaliar suas necessidades de conformidade

A avaliação de conformidade começa com uma análise completa de todas as suas obrigações regulamentares e como sua empresa as está implementando. Para ajudar na sua avaliação dos serviços do Google Cloud, use a Central de recursos de compliance. Este site oferece detalhes sobre o seguinte:

• Suporte de serviço para vários regulamentos
• Certificações e atestados do Google Cloud

É possível solicitar um engajamento com um especialista em conformidade do Google para entender melhor o ciclo de vida da conformidade no Google e como os requisitos podem ser atendidos.

Para mais informações, consulte Como garantir conformidade na nuvem (PDF).

Implantar o Assured Workloads

O Assured Workloads é a ferramenta do Google Cloud criada com base nos controles do Google Cloud para você cumprir as obrigações de conformidade. Você pode fazer o seguinte com o Assured Workloads:

• Selecione seu regime de conformidade. Em seguida, a ferramenta define automaticamente os controles de acesso da equipe de referência.
• Defina o local dos dados usando políticas da organização para que os dados em repouso e os recursos permaneçam apenas nessa região.
• Selecione a opção de gerenciamento de chaves (como o período de rotação de chaves) que melhor atende às necessidades de segurança e conformidade.
• Para determinados requisitos regulamentares, como o FedRAMP de nível médio, selecione os critérios de acesso da equipe de suporte do Google, por exemplo, se eles passaram por investigações de histórico para contratação apropriadas.
• Verifique se as chaves de criptografia gerenciadas pelo Google estão em conformidade com o FIPS-140-2 e sejam compatíveis com a conformidade do FedRAMP de nível médio. Para ter uma camada adicional de controle e separação de deveres, use as chaves de criptografia gerenciadas pelo cliente (CMEK). Para mais informações sobre chaves, consulte Criptografar dados.

Analisar os blueprints de modelos e práticas recomendadas que se aplicam ao seu regime de conformidade

O Google publicou blueprints e guias de soluções que descrevem as práticas recomendadas e que fornecem módulos do Terraform para permitir que você implemente um ambiente que ajudará você a alcançar a conformidade. A tabela a seguir lista uma seleção de blueprints que abordam a segurança e o alinhamento com os requisitos de conformidade.

Padrão	Descrição
PCI	Blueprint de segurança: PCI no GKE Conformidade com o padrão de segurança de dados do PCI Como limitar o escopo de conformidade para ambientes PCI no Google Cloud Conformidade com PCI DSS no GKE
FedRAMP	Guia de implementação do FedRAMP do Google Cloud (PDF) Como configurar uma carga de trabalho de três níveis alinhada no FedRAMP no Google Cloud
HIPAA	Como proteger dados de saúde no Google Cloud (PDF) Como configurar uma carga de trabalho em conformidade com a HIPAA usando ferramentas de proteção de dados (PDF)

Monitorar a conformidade

A maioria das regulamentações exige que você monitore determinadas atividades, incluindo controles de acesso. Para ajudar no monitoramento, você pode usar o seguinte:

• Transparência no acesso, que fornece registros quase em tempo real quando os administradores do Google Cloud acessam seu conteúdo.
• A geração de registros de regras de firewall para gravar conexões TCP e UDP dentro de uma rede VPC para qualquer regra que você criar. Esses registros podem ser úteis para auditar o acesso à rede ou fornecer aviso antecipado de que a rede está sendo usada de maneira não aprovada.
• Os registros de fluxo de VPC registram os fluxos de tráfego de rede enviados ou recebidos por instâncias de VM.
• Security Command Center Premium para verificar a conformidade com vários padrões.
• OSSEC (ou outra ferramenta de código aberto) para registrar a atividade de indivíduos que têm acesso de administrador ao ambiente.
• Justificativas do acesso às chaves para visualizar os motivos das solicitações.

Automatize a conformidade

Para garantir a conformidade com as regulamentações em constante mudança, determine se você pode automatizar as políticas de segurança incorporando-as à infraestrutura como implantações de código. Por exemplo, considere o seguinte:

• Use blueprints de segurança para integrar as políticas de segurança às implantações de infraestrutura.

• Configure o Security Command Center para alertar quando ocorrerem problemas de não conformidade. Por exemplo, monitore para identificar problemas como usuários que desativam a verificação em duas etapas ou contas de serviço com privilégios em excesso. Para saber mais, consulte Como configurar as notificações de localização.

• Configurar a correção automática para notificações específicas. Para mais informações, consulte Código do Cloud Functions.

Para mais informações sobre a automação de conformidade, consulte a solução de Risco e conformidade como código (RCaC, na sigla em inglês).

A seguir

Saiba mais sobre compliance com os seguintes recursos:

• Implemente requisitos de residência e soberania de dados (próximo documento desta série).
• Central de recursos de compliance
• Artigo sobre segurança do Google (PDF)
• Assured Workloads

Implementar requisitos de residência e soberania de dados

Este documento no Framework da arquitetura do Google Cloud (em inglês) fornece práticas recomendadas para implementar requisitos de soberania de residência e dados.

Os requisitos de residência e soberania de dados são baseados nos seus regulamentos regionais e específicos do setor, e organizações diferentes podem ter requisitos de soberania de dados diferentes. Por exemplo, você pode ter os seguintes requisitos:

• Controle sobre todo o acesso ao Google pelos dados, incluindo o tipo de pessoal que pode acessar os dados e de qual região eles podem acessá-los.
• Inspeção de mudanças na infraestrutura e nos serviços em nuvem, que podem afetar o acesso ou a segurança dos seus dados. O insight sobre esses tipos de alterações ajuda a garantir que o Google Cloud não consiga burlar controles ou mover seus dados para fora da região.
• Sobrevivência das cargas de trabalho por um longo período quando não for possível receber atualizações de software do Google Cloud.

Gerenciar a soberania de dados

A soberania de dados oferece um mecanismo para impedir que o Google acesse seus dados. Você aprova o acesso somente para comportamentos do provedor que você acredita serem necessários.

Por exemplo, você pode gerenciar a soberania de dados das seguintes maneiras:

• Armazene e gerencie as chaves de criptografia fora da nuvem.
• Conceda acesso a essas chaves apenas com base em justificativas de acesso detalhadas.
• Proteja os dados em uso.

Gerenciar a soberania operacional

A soberania operacional oferece garantias de que a equipe do Google não pode comprometer suas cargas de trabalho.

Por exemplo, você pode gerenciar a soberania operacional das seguintes maneiras:

• Restrinja a implantação de novos recursos em regiões específicas do provedor.
• Limitar o acesso da equipe do Google com base em atributos predefinidos, como cidadania ou localização geográfica.

Gerenciar a soberania de software

A soberania de software oferece garantias de que você pode controlar a disponibilidade de suas cargas de trabalho e executá-las onde quiser, sem depender de um único provedor de nuvem ou ficar preso a ele. A soberania de software inclui a capacidade de sobreviver aos eventos que exigem alteração rápida no local de implantação das cargas de trabalho e em que nível de conexão externa é permitido.

Por exemplo, o Google Cloud é compatível com implantações híbridas e de várias nuvens. Além disso, com o GKE Enterprise, é possível gerenciar e implantar seus aplicativos em ambientes em nuvem e locais.

Controlar a residência de dados

Essa seção descreve onde seus dados são armazenados em repouso. Os requisitos de residência de dados variam de acordo com os objetivos de design do sistema, questões regulatórias do setor, legislação nacional, implicações fiscais e até mesmo a cultura.

O controle da residência de dados começa com:

• Entender o tipo dos dados e a localização deles.
• Determinar quais riscos existem para seus dados e quais leis e regulamentos se aplicam.
• Controlar o destino ou o destino dos dados

Para ajudar a cumprir os requisitos de residência de dados, o Google Cloud permite controlar onde seus dados são armazenados, como são acessados e como são processados. É possível usar políticas de local de recursos para restringir onde os recursos são criados e para limitar onde os dados são replicados entre regiões. É possível usar a propriedade de local de um recurso para identificar onde o serviço implanta e quem o mantém.

Para informações sobre compatibilidade, consulte Serviços com suporte com locais de recursos.

A seguir

Saiba mais sobre a residência e soberania de dados com os seguintes recursos:

• Implemente os requisitos de privacidade (próximo documento desta série)
• Residência de dados, transparência operacional e privacidade para clientes europeus no Google Cloud (PDF)
• Como projetar e implantar a estratégia de segurança de dados (PDF)
• Cloud Key Management Service
• Como proteger seus dados com o Google Cloud Platform (PDF)
• Acesso privilegiado no Google
• Transparência no acesso ao Google Cloud

Implementar os requisitos de privacidade

Neste documento, você encontra as práticas recomendadas para implementar os requisitos de privacidade no Framework da arquitetura do Google Cloud.

Os regulamentos de privacidade ajudam a definir como você pode receber, processar, armazenar e gerenciar os dados dos usuários. Muitos controles de privacidade (por exemplo, controles de cookies, gerenciamento de sessões e permissão de usuários) são de sua responsabilidade, porque você é o proprietário dos dados (incluindo os dados que recebe dos usuários).

O Google Cloud inclui os seguintes controles que promovem a privacidade:

• Criptografia padrão de todos os dados quando estão em repouso, em trânsito e durante o processamento.
• Protege contra acesso de pessoas com informações privilegiadas.
• Compatibilidade com diversas regulamentações de privacidade.

Para mais informações, consulte Compromissos de privacidade do Google Cloud.

Classificar seus dados confidenciais

Defina quais dados são confidenciais e, em seguida, garanta que eles sejam protegidos adequadamente. Os dados confidenciais podem incluir números de cartões de crédito, endereços, números de telefone e outras informações de identificação pessoal (PII).

Com a Proteção de dados confidenciais, é possível configurar classificações apropriadas. Em seguida, você pode marcar e tokenizar seus dados antes de armazená-los no Google Cloud. Para mais informações, consulte Classificar seus dados automaticamente.

Bloquear o acesso a dados confidenciais

Coloque dados confidenciais no próprio perímetro de serviço usando o VPC Service Controls e defina os controles de acesso do Google Identity and Access Management (IAM) para esses dados. Configure a autenticação multifator (MFA) para todos os usuários que exigem acesso a dados confidenciais.

Para mais informações, consulte Controlar o movimento de dados entre perímetros e Configurar o SSO e o MFA.

Monitorar ataques de phishing

Garanta que seu sistema de e-mail esteja configurado para oferecer proteção contra ataques de phishing, que costumam ser usados para ataques de fraude e malware.

Se sua organização usa o Gmail, utilize a proteção avançada contra phishing e malware. Esta coleção de configurações oferece controles para colocar e-mails em quarentena, defesa contra tipos de anexo anômalos e ajuda na proteção contra e-mails de spoofing de entrada. O sandbox de segurança detecta malware nos anexos. O Gmail é atualizado de maneira contínua e automática com as melhorias e proteções de segurança mais recentes para ajudar a manter o e-mail da sua organização seguro.

Estender a segurança com confiança zero à sua força de trabalho híbrida

Um modelo de segurança de confiança zero significa que ninguém é confiável implicitamente, esteja dentro ou fora da rede da organização. Quando os sistemas do IAM verificam as solicitações de acesso, uma postura de segurança de confiança zero significa que a identidade e o contexto do usuário (por exemplo, o endereço IP ou o local) são considerados. Ao contrário da VPN, os controles de segurança de confiança zero mudam dos controles de acesso do perímetro da rede para os usuários e os dispositivos deles. A segurança de confiança zero permite que os usuários trabalhem com mais segurança em qualquer lugar. Por exemplo, os usuários podem acessar os recursos da organização em laptops ou dispositivos móveis em casa.

No Google Cloud, é possível configurar o BeyondCorp Enterprise e o Identity-Aware Proxy (IAP) para ativar a confiança zero no seu Google. Recursos da nuvem. Se os usuários utilizam o Google Chrome e você ativa o BeyondCorp Enterprise, é possível integrar a segurança de confiança zero aos navegadores dos usuários.

A seguir

Saiba mais sobre segurança e privacidade com os seguintes recursos:

• Implementar controles de registro e detetive (próximo documento desta série)
• Centro de Privacidade

• Aviso de privacidade do Google Cloud

• Práticas recomendadas de privacidade para trabalhar com o suporte do Google Cloud

• Como o Google protege a segurança e a privacidade da sua organização

• Perguntas frequentes sobre privacidade

Implementar controles de geração de registros e detetives

Este documento no Framework da arquitetura do Google Cloud fornece práticas recomendadas para implementar controles de geração de registros e detetives.

Os controles de deteção usam telemetria para detectar configurações incorretas, vulnerabilidades e atividades potencialmente mal-intencionadas em um ambiente de nuvem. O Google Cloud permite criar controles personalizados de monitoramento e detetives para seu ambiente. Nesta seção, descrevemos esses outros recursos e recomendações para o uso.

Monitorar o desempenho da rede

O Network Intelligence Center permite visualizar o desempenho da topologia e da arquitetura da rede. Você pode conseguir insights detalhados sobre o desempenho da rede e usar essas informações para otimizar a implantação eliminando os gargalos nos serviços. O Connectivity Tests fornece insights sobre as regras e políticas de firewall que são aplicadas ao caminho da rede.

Monitorar e impedir a exfiltração de dados

A exfiltração de dados é uma das principais preocupações das organizações. Geralmente, isso ocorre quando uma pessoa autorizada extrai dados de um sistema seguro e os compartilha com uma parte não autorizada ou os move para um sistema não seguro.

O Google Cloud oferece vários recursos e ferramentas que ajudam a detectar e evitar a exfiltração de dados. Para mais informações, consulte Como evitar a exfiltração de dados.

Centralizar seu monitoramento

O Security Command Center oferece visibilidade sobre os recursos que você tem no Google Cloud e no estado de segurança deles. O Security Command Center ajuda a prevenir, detectar e responder a ameaças. Ele oferece um painel centralizado que pode ser usado para ajudar a identificar configurações incorretas de segurança em máquinas virtuais, redes, aplicativos e buckets de armazenamento. Você pode resolver esses problemas antes que eles resultem em danos ou prejuízos para o negócio. Os recursos integrados do Security Command Center podem revelar atividades suspeitas nos registros de segurança do Cloud Logging ou indicar máquinas virtuais comprometidas.

Para responder às ameaças, basta seguir as recomendações extras ou exportar os registros para o SIEM para realizar uma investigação mais detalhada. Para informações sobre como usar um sistema SIEM com o Google Cloud, consulte Análise de registros de segurança no Google Cloud.

Ele também fornece vários detectores que ajudam a analisar a segurança da sua infraestrutura. Esses detectores incluem o seguinte:

• Event Threat Detection
• Security Health Analytics (SHA)
• Serviço de ações sensíveis

Outros serviços do Google Cloud, como os registros do Google Cloud Armor, também fornecem descobertas para exibição no Security Command Center.

Ative os serviços necessários para suas cargas de trabalho e monitore e analise apenas dados importantes. Para mais informações sobre como ativar a geração de registros nos serviços, consulte a seção Ativar registros na análise de registros de segurança no Google Cloud.

Monitorar ameaças

O Event Threat Detection é um serviço gerenciado opcional do Security Command Center Premium que detecta ameaças em seu fluxo de registros. Com o Event Threat Detection, é possível detectar ameaças de alto risco e custo, como malware, criptomineração, acesso não autorizado a recursos do Google Cloud, ataques DDoS e ataques SSH de força bruta. Ao usar os recursos da ferramenta para detalhar volumes de dados de registro, suas equipes de segurança podem identificar rapidamente incidentes de alto risco e se concentrar na correção.

Para detectar contas de usuários possivelmente comprometidas na sua organização, use os registros de ações sensíveis do Cloud Platform para identificar quando ações sensíveis são realizadas e confirmar se usuários válidos realizaram essas ações para fins válidos. Uma ação sensível é uma ação, como a adição de um papel altamente privilegiado, que pode prejudicar seus negócios se for realizada por uma pessoa mal-intencionada. Use o Cloud Logging para ver, monitorar e consultar os registros de ações sensíveis do Cloud Platform. Também é possível ver as entradas de registro de ações sensíveis com o Serviço de ações sensíveis, um serviço integrado do Security Command Center Premium.

O Chronicle pode armazenar e analisar todos os seus dados de segurança de maneira centralizada. Para ajudar você a ver toda a duração de um ataque, o Chronicle pode mapear os registros para um modelo comum, aprimorá-los e, em seguida, vinculá-los em linhas do tempo. É possível usar o Chronicle para criar regras de detecção, configurar indicadores de correspondência de comprometimento (IoC) e executar atividades de caça a ameaças. Escreva as regras de detecção na linguagem YARA-L. Para ver exemplos de regras de detecção de ameaças em YARA-L, consulte o repositório de Análise de segurança da comunidade (CSA, na sigla em inglês). Além de escrever suas próprias regras, você pode aproveitar as detectações selecionadas no Chronicle. Essas detecções selecionadas são um conjunto de regras YARA-L predefinidas e gerenciadas que podem ajudar você a identificar ameaças.

Outra opção para centralizar os registros de análise de segurança, auditoria e investigação é usar o BigQuery. No BigQuery, é possível monitorar ameaças ou configurações incorretas usando consultas SQL, como as do repositório de CSAs, para analisar alterações de permissão, atividade de provisionamento, uso de carga de trabalho, acesso a dados e atividade de rede. Para mais informações sobre a análise de registros de segurança no BigQuery desde a configuração até a análise, consulte Análise de registros de segurança no Google Cloud.

O diagrama a seguir mostra como centralizar o monitoramento usando os recursos integrados de detecção de ameaças do Security Command Center e a detecção de ameaças que você faz no BigQuery, no Chronicle ou em um SIEM de terceiros.

Conforme mostrado no diagrama, há várias fontes de dados de segurança que você precisa monitorar. Essas fontes de dados incluem registros do Cloud Logging, alterações de recursos do Inventário de recursos do Cloud, registros do Google Workspace ou eventos do hipervisor ou de um kernel convidado. O diagrama mostra que é possível usar o Security Command Center para monitorar essas fontes de dados. Esse monitoramento ocorre automaticamente, desde que você tenha ativado os recursos adequados e os detectores de ameaças no Security Command Center. O diagrama mostra que também é possível monitorar ameaças exportando dados de segurança e descobertas do Security Command Center para uma ferramenta de análise, como o BigQuery, o Chronicle ou um SIEM de terceiros. Na ferramenta de análise, o diagrama mostra que é possível fazer outras análises e investigações usando e ampliando consultas e regras como as disponíveis na CSA.

A seguir

Saiba mais sobre geração de registros e detecção com os seguintes recursos:

• Cloud Logging

• Conheça o Chronicle Detect no Google Cloud

• Criar um processo colaborativo de gerenciamento de incidentes

Framework de arquitetura do Google Cloud: confiabilidade

Esta seção no Framework de arquitetura do Google Cloud mostra como arquitetar e operar serviços confiáveis em uma plataforma de nuvem. Você também aprenderá sobre alguns dos produtos e recursos do Google Cloud que oferecem suporte à confiabilidade.

O framework de arquitetura descreve as práticas recomendadas, fornece recomendações de implementação e explica alguns dos produtos e serviços disponíveis. O objetivo é ajudar você a projetar sua implantação do Google Cloud para que ele corresponda às necessidades da sua empresa.

Para executar um serviço confiável, sua arquitetura precisa incluir o seguinte:

• Metas de confiabilidade mensuráveis, com desvios que você corrige imediatamente.
• Padrões de design para escalonabilidade, alta disponibilidade, recuperação de desastres e gerenciamento automatizado de mudanças.
• Componentes que se recuperem quando possível e código que inclua instrumentação para observabilidade.
• Procedimentos operacionais que executem o serviço com trabalho manual mínimo e carga cognitiva nos operadores e que permitem detectar e reduzir as falhas rapidamente.

A confiabilidade é a responsabilidade de todos na engenharia, como as equipes de desenvolvimento, gerenciamento de produtos, operações e engenharia de confiabilidade do site (SRE, na sigla em inglês). Todos precisam ser responsáveis e entender as metas de confiabilidade do aplicativo, bem como os orçamentos de risco e erro. As equipes precisam ser capazes de priorizar o trabalho de maneira adequada e escalar conflitos de prioridade entre a confiabilidade e o desenvolvimento de recursos dos produtos.

Na seção sobre confiabilidade do Framework de arquitetura, você aprenderá como:

• Entender os princípios básicos de confiabilidade
• Definir metas de confiabilidade
• Definir SLOs
• Adotar SLOs
• Incorporar a observabilidade na infraestrutura e em aplicativos
• Projetar para escala e alta disponibilidade
• Criar ferramentas e processos operacionais confiáveis
• Criar alertas eficientes
• Criar um processo colaborativo de gerenciamento de incidentes

Princípios de confiabilidade

Neste documento, o Framework de arquitetura explica alguns dos princípios básicos para executar serviços confiáveis em uma plataforma em nuvem. Esses princípios ajudam a criar um entendimento comum à medida que você lê outras seções do Framework de arquitetura que mostram como alguns dos produtos e recursos do Google Cloud são compatíveis com serviços confiáveis.

Terminologia importante

Há vários termos comuns associados às práticas de confiabilidade. Muitos leitores podem conhecer esse recurso. No entanto, para relembrar, consulte as descrições detalhadas na página Terminologia.

Princípios básicos

A abordagem do Google à confiabilidade é baseada nos princípios básicos a seguir.

A confiabilidade é seu principal recurso

Novos recursos de produto às vezes são sua prioridade em curto prazo. No entanto, a confiabilidade é o recurso principal do produto em longo prazo. Isso porque, se o produto for muito lento ou estiver indisponível por um longo período, seus usuários podem sair, tornando outros recursos irrelevantes.

A confiabilidade é definida pelo usuário.

Para cargas de trabalho voltadas ao usuário, meça a experiência do usuário. O usuário precisa estar satisfeito com o desempenho do serviço. Por exemplo, meça a proporção sucesso de solicitações dos usuários, não apenas as métricas do servidor, como o uso da CPU.

Para cargas de trabalho em lote e de streaming, talvez seja necessário medir indicadores principais de desempenho (KPIs) para a capacidade de dados, como linhas verificadas por janela de tempo, em vez de métricas do servidor, como o uso do disco. Os KPIs de capacidade de processamento podem ajudar a garantir que um relatório diário ou trimestral exigido pelo usuário seja concluído a tempo.

100% de confiabilidade é o destino errado

Seus sistemas devem ser confiáveis o suficiente para que os usuários fiquem satisfeitos, mas não excessivamente confiáveis de modo que o investimento não seja justificável. Defina os SLOs que definem o limite de confiabilidade que você quer e use orçamentos de erro para gerenciar a taxa de alteração apropriada.

Aplique os princípios de design e operacionais neste framework a um produto apenas se o SLO desse produto ou aplicativo justificar o custo.

Confiabilidade e inovação rápida são complementares

Use erros de orçamento para alcançar o equilíbrio entre a estabilidade do sistema e a agilidade do desenvolvedor. As orientações a seguir ajudam a determinar quando se deve mover rapidamente ou devagar:

• Quando um erro de orçamento adequado está disponível, é possível inovar rapidamente e melhorar o produto ou adicionar recursos dele.
• Quando o orçamento de erro é reduzido, diminua a velocidade e concentre-se nos recursos de confiabilidade.

Princípios operacionais e de design

Para maximizar a confiabilidade do sistema, os princípios operacionais e de design a seguir se aplicam. Cada um desses princípios é discutido em detalhes no restante da categoria de confiabilidade do framework de arquitetura.

Definir metas de confiabilidade

As práticas recomendadas abordadas nesta seção do Framework de arquitetura incluem:

• Escolha os SLIs apropriados.
• Defina SLOs com base na experiência do usuário.
• Melhore os SLOs de modo iterativo.
• Use SLOs internos rigorosos.
• Use erros de orçamento para gerenciar a velocidade de desenvolvimento.

Para mais informações, consulte Definir metas de confiabilidade na categoria de confiabilidade do framework de arquitetura.

Incorporar a observabilidade na infraestrutura e em aplicativos

O princípio de design a seguir é abordado nesta seção do Framework de arquitetura:

• Instrumentalize seu código para maximizar a capacidade de observação.

Para mais informações, consulte Criar observabilidade na infraestrutura e nos aplicativos no categoria de confiabilidade do Architecture Framework.

Projetar para escala e alta disponibilidade

Os princípios de design a seguir são abordados nesta seção do Framework de arquitetura:

• Crie redundância para maior disponibilidade.
• Replicar dados entre regiões para recuperação de desastres.
• Projetar uma arquitetura multirregional para resiliência a interrupções regionais.
• Eliminar gargalos de escalonabilidade.
• Reduza os níveis de serviço de maneira suave se estiverem sobrecarregados.
• Evite e reduza picos de tráfego.
• Limpe e valide entradas.
• Falhar com segurança para preservar a função do sistema.
• Projete chamadas de API e comandos operacionais para serem passíveis de repetição.
• Identifique e gerencie dependências do sistema.
• Minimize as dependências críticas.
• Garantir que todas as alterações possam ser revertidas.

Para mais informações, consulte Projetar para escala e alta disponibilidade na categoria de confiabilidade do framework de arquitetura.

Crie processos operacionais e ferramentas confiáveis

Os princípios operacionais a seguir são abordados nesta seção do framework de arquitetura:

• Escolha bons nomes para aplicativos e serviços.
• Implementar lançamentos progressivos com procedimentos de testes canários.
• Distribuir o tráfego para promoções e lançamentos programados.
• Automatize o processo de criação, teste e implantação.
• Proteja-se contra erros do operador.
• Teste os procedimentos de recuperação de falhas.
• Realize testes de recuperação de desastres.
• Pratique engenharia de caos.

Para mais informações, consulte Criar ferramentas e processos operacionais confiáveis na categoria de confiabilidade do framework de arquitetura.

Criar alertas eficientes

Os princípios operacionais a seguir são abordados nesta seção do framework de arquitetura:

• Otimizar atrasos de alertas.
• Alerte sobre sintomas, não causas.
• Alerta sobre outliers, não médias.

Para mais informações, consulte Criar alertas eficientes na categoria de confiabilidade do framework de arquitetura.

Criar um processo colaborativo de gerenciamento de incidentes

Os princípios operacionais a seguir são abordados nesta seção do framework de arquitetura:

• Atribua a propriedade clara do serviço.
• Reduzir o tempo de detecção (TTD) com alertas bem ajustados.
• Reduzir o tempo de mitigação (TTM) com planos e treinamento de gerenciamento de incidentes.
• Projetar layouts e conteúdo de painel para minimizar o TTM.
• Documente procedimentos de diagnóstico e mitigação de cenários de interrupção conhecidos.
• Use post mortems sem apontar culpados para aprender com interrupções e evitar recorrências.

Para mais informações, consulte Criar um processo de gerenciamento de incidentes colaborativo na categoria de confiabilidade do framework de arquitetura.

A seguir

• Definir metas de confiabilidade (próximo documento desta série)

Explore outras categorias no Framework de arquitetura, como design do sistema, excelência operacional, segurança, privacidade e conformidade.

Defina metas de confiabilidade

Neste documento, o framework de arquitetura do Google Cloud oferece práticas recomendadas para definir maneiras apropriadas de avaliar a experiência do cliente dos seus serviços para que você possa executar serviços confiáveis. Você aprenderá como iterar nos objetivos de nível de serviço (SLOs) definidos e usar orçamentos de erro para saber quando a confiabilidade poderá ser afetada se você lançar atualizações adicionais.

Escolher SLIs apropriado

É importante escolher indicadores de nível de serviço (SLIs) apropriados para entender completamente o desempenho do seu serviço. Por exemplo, se o aplicativo tiver uma arquitetura multilocatária típica de aplicativos SaaS usados por vários clientes independentes, capture SLIs em um nível por locatário. Se os SLIs forem medidos apenas em nível global, você poderá perder problemas críticos no aplicativo que afetam um único cliente importante ou uma minoria de clientes. Em vez disso, projete seu aplicativo para incluir um identificador de locatário em cada solicitação do usuário e propague esse identificador em cada camada da pilha. Este identificador permite que o sistema de monitoramento agregue estatísticas no nível por locatário em cada camada ou microsserviço ao longo do caminho da solicitação.

O tipo de serviço executado também determina quais SLIs precisam ser monitorados, conforme mostrado nos exemplos a seguir.

Sistemas de veiculação

Os SLIs a seguir são típicos em sistemas que exibem dados:

• A disponibilidade informa a fração do tempo em que um serviço pode ser usado. Ela geralmente é definida em termos da fração de solicitações bem formadas que são bem-sucedidas, como 99%.
• A latência informa a velocidade com que uma determinada porcentagem de solicitações pode ser atendida. Ela geralmente é definida em termos de uma percentil diferente do 50o, como "99o percentil a 300 ms".
• A qualidade informa a qualidade de uma determinada resposta. A definição de qualidade geralmente é específica para o serviço e indica o nível de diferença entre o conteúdo da resposta a uma solicitação e o conteúdo da resposta ideal. A qualidade da resposta pode ser binária (boa ou ruim) ou expressa em uma escala de 0% a 100%.

Sistemas de processamento de dados

Os SLIs a seguir são típicos em sistemas que processam dados:

• A cobertura informa a fração de dados processados, como 99,9%.
• Precisão informa a fração de dados de saída considerados corretos, como 99,99%.
• A atualização informa se os dados de origem ou de saída agregados são recentes. Normalmente, a atualização é mais recente, por exemplo, após 20 minutos.
• A capacidade informa a quantidade de dados que está sendo processada, como 500 MiB/s ou até 1.000 solicitações por segundo (RPS, na sigla em inglês).

Sistemas de armazenamento

Os SLIs a seguir são típicos em sistemas que armazenam dados:

• A durabilidade informa a probabilidade de os dados gravados no sistema serem recuperados no futuro, por exemplo, 99,9999%. Qualquer incidente permanente de perda de dados reduz a métrica de durabilidade.
• A capacidade e a latência também são SLIs comuns para sistemas de armazenamento.

Escolher SLIs e definir SLOs com base na experiência do usuário

Um dos princípios básicos dessa seção do framework de arquitetura é que a confiabilidade é definida pelo usuário. Avalie as métricas de confiabilidade o mais próximo possível do usuário, como as seguintes opções:

• Se possível, instrumentalize o cliente móvel ou da Web.
  • Por exemplo, use o monitoramento de desempenho do Firebase para ter insights sobre as características de desempenho dos apps iOS, Android e da Web.
• Se isso não for possível, instrumentalize o balanceador de carga.
  • Por exemplo, use o Cloud Monitoring para monitoramento e geração de registros do balanceador de carga de aplicativo externo.
• Uma medida de confiabilidade no servidor deve ser a última opção.
  • Por exemplo, monitore uma instância do Compute Engine com o Cloud Monitoring.

Defina um SLO alto o suficiente para que quase todos os usuários estejam satisfeitos com seu serviço, e nada mais alto. Devido à conectividade de rede ou a outros problemas temporários do lado do cliente, seus clientes podem não perceber problemas breves de confiabilidade no seu aplicativo, permitindo que você reduza o SLO.

Para tempo de atividade e outras métricas vitais, procure uma meta inferior a 100%, mas perto dela. Os proprietários de serviços precisam avaliar objetivamente o nível mínimo de desempenho de serviço e disponibilidade que faria com que a maioria dos usuários ficasse feliz, não apenas com base nos níveis contratuais externos.

A velocidade com que você muda afeta a confiabilidade do sistema. No entanto, a capacidade de fazer pequenas alterações frequentes ajuda você a fornecer recursos com mais rapidez e qualidade. Metas de confiabilidade alcançáveis ajustadas à experiência do cliente ajudam a definir o ritmo e o escopo máximos das alterações (velocidade do recurso) que os clientes podem tolerar.

Se não for possível avaliar a experiência do cliente e definir metas em torno dela, você poderá executar uma análise de comparativo de mercado. Se não houver concorrência comparável, avalie a experiência do cliente, mesmo que ainda não seja possível definir metas. Por exemplo, avalie a disponibilidade do sistema ou a taxa de transações significativas e bem-sucedidas para o cliente. É possível correlacionar esses dados com métricas de negócios ou KPIs, como o volume de pedidos no varejo ou o volume de chamadas e tíquetes de suporte ao cliente e a gravidade deles. Durante um período, é possível usar esses exercícios de correlação para chegar a um limite razoável de satisfação do cliente. Esse limite é seu SLO.

Melhore os SLOs de modo iterativo

Os SLOs não devem ser definidos de maneira definitiva. Revise os SLOs trimestralmente ou, pelo menos, anualmente, e confirme se eles continuam a refletir com precisão a satisfação do usuário e se correlacionar bem com interrupções do serviço. Certifique-se de que eles atendam às atuais necessidades da empresa e às novas jornadas críticas do usuário. Revise e aumente seus SLOs conforme necessário após essas revisões periódicas.

Use SLOs internos rigorosos

Recomenda-se ter SLOs internos mais rigorosos do que SLAs externos. Como as violações do SLA tendem a exigir a emissão de um crédito financeiro ou reembolso de clientes, é recomendável resolver os problemas antes que eles tenham impacto financeiro.

Recomendamos que você use esses SLOs internos mais rigorosos com um processo post mortem sem culpa e revisões de incidentes. Para mais informações, consulte Criar um processo colaborativo de gerenciamento de incidentes na categoria de confiabilidade do Architecture Center.

Use erros de orçamento para gerenciar a velocidade de desenvolvimento

As margens de erro informam se o sistema é mais ou menos confiável do que o necessário em um determinado período. Os erros de orçamento são calculados como 100%: SLO durante um período, como 30 dias.

Quando houver capacidade restante no erro de orçamento, será possível continuar a lançar melhorias ou novos recursos rapidamente. Quando o erro de orçamento estiver próximo de zero, congele ou diminua a velocidade do serviço e invista os recursos de engenharia para melhorar os aspectos de confiabilidade.

O Google Cloud Observability inclui o monitoramento de SLO para minimizar o esforço de configurar SLOs e margens de erro. Os serviços incluem uma interface gráfica do usuário para ajudá-lo a configurar SLOs manualmente, uma API para configuração programática de SLOs e painéis integrados para rastrear a taxa de gravação de erros de orçamento. Para mais informações, veja como criar um SLO.

Recomendações

Para aplicar a orientação no framework de arquitetura ao seu próprio ambiente, siga estas recomendações:

• Defina e avalie SLIs voltados ao cliente, como disponibilidade ou latência do serviço.
• Defina um orçamento de erro centrado no cliente que seja mais rigoroso do que o SLA externo. Inclua consequências por violações, como congelamentos de produção.
• Configure SLIs de latência para capturar valores atípicos, como 90o ou 99o percentil, para detectar as respostas mais lentas.
• Analise os SLOs pelo menos uma vez por ano e confirme se eles estão bem relacionados à satisfação do usuário e às interrupções de serviço.

A seguir

Saiba mais sobre como definir suas metas de confiabilidade com os seguintes recursos:

• Agregue capacidade de observação à sua infraestrutura e ao aplicativo (próximo documento desta série)
• Coursera - SRE: medição e gerenciamento de confiabilidade
• Livro de SRE, capítulos do livro e livro de trabalho do SRE para implementar SLOs
• Ajustar métricas de SLI

Explore outras categorias no Framework de arquitetura, como design do sistema, excelência operacional e segurança, privacidade e conformidade.

Definir SLOs

Este documento é a primeira de duas partes que mostram como as equipes que operam serviços on-line podem começar a criar e adotar uma cultura de engenharia de confiabilidade do site (SRE) usando objetivos de nível de serviço (SLO). Um SLO é um nível pretendido de confiabilidade para um serviço.

No software como serviço (SaaS), existe uma tensão natural entre a velocidade do desenvolvimento do produto e a estabilidade operacional. Quanto mais você alterar seu sistema, maior será a probabilidade de ele falhar. Ferramentas de monitoramento e observabilidade podem ajudar a manter a confiança na estabilidade operacional, aumentando a velocidade de desenvolvimento. No entanto, embora essas ferramentas, também conhecidas como de gerenciamento de desempenho de aplicativos (APM), sejam importantes, uma das suas principais aplicações é configurar SLOs.

Se definido corretamente, um SLO pode ajudar as equipes a tomar decisões operacionais baseadas em dados que aumentam a velocidade de desenvolvimento sem prejudicar a estabilidade. O SLO também pode alinhar as equipes de desenvolvimento e operações em torno de um objetivo único acordado, o que pode aliviar a tensão natural que existe entre os objetivos: criar e iterar produtos (desenvolvimento) e manter integridade do sistema (operações).

Os SLOs são descritos em detalhes no Livro SRE e na Pasta de trabalho SRE, junto a outras práticas de SRE. Esta série tenta simplificar o processo de compreensão e desenvolvimento de SLOs para facilitar a adoção deles. Depois de ler e entender esses artigos, você pode encontrar mais nos livros.

O objetivo desta série é mostrar um caminho claro para a implementação de SLOs na sua organização:

• Este documento analisa o que são SLOs e como defini-los para seus serviços.
• A adoção de SLOs abrange diferentes tipos de SLOs baseados em modelos de carga de trabalho, como avaliar esses SLOs e como desenvolver alertas com base neles.

Esta série é destinada a SREs, equipes de operações, DevOps, administradores de sistemas e outros responsáveis pela estabilidade e confiabilidade de um serviço on-line. Ele pressupõe que você entende como os serviços de Internet se comunicam com navegadores da Web e dispositivos móveis e que tem um entendimento básico de como os serviços da Web são monitorados, implantados e solucionados.

Os relatórios State of DevOps identificaram recursos que impulsionam o desempenho da entrega de software. Esta série ajudará você com os seguintes recursos:

• Monitoramento e observabilidade
• Como monitorar sistemas para basear decisões de negócios
• Notificação proativa de falhas

Por que usar SLOs?

Ao criar uma cultura de SRE, por que começar com SLOs? Em resumo, se você não definir um nível de serviço, será difícil medir se os clientes estão satisfeitos com o serviço. Mesmo que você saiba que pode melhorar o serviço, a falta de um nível de serviço definido torna difícil determinar onde e quanto investir em melhorias.

Pode ser tentador desenvolver SLOs separados para cada serviço, se voltado para o usuário ou não. Por exemplo, um erro comum é medir dois ou mais serviços separadamente (por exemplo, um serviço de front-end e um armazenamento de dados de back-end), quando o usuário depende de ambos e não está ciente da distinção. Uma abordagem melhor é desenvolver SLOs baseados no produto (coleção de serviços) e se concentrar nas interações mais importantes que os usuários têm com ele.

Portanto, para desenvolver um SLO eficaz, o ideal é que você entenda as interações dos usuários com o serviço, conhecidas como jornadas críticas do usuário (CUJs, na sigla em inglês). Uma CUJ considera as metas dos usuários e como eles usam os serviços da sua empresa para atingir essas metas. O CUJ é definido a partir da perspectiva do cliente sem considerar os limites do serviço. Se a CUJ for atendida, o cliente estará satisfeito, e clientes satisfeitos são uma medida importante para o sucesso de um serviço.

Um dos principais aspectos da satisfação do cliente com um serviço é a confiabilidade dele. Não importa o que um serviço faz, se não é confiável. Assim, a confiabilidade é o recurso mais importante de qualquer serviço. Uma métrica comum de confiabilidade é o tempo de atividade, que, normalmente, significa a quantidade de tempo que um sistema ficou ativo. No entanto, preferimos uma métrica mais útil e precisa: disponibilidade. A disponibilidade ainda responde à pergunta se um sistema está ativo, mas de maneira mais precisa do que medindo o tempo desde que um sistema estava inativo. Nos sistemas distribuídos hoje, os serviços podem estar parcialmente fora do ar, um fator que o tempo de atividade não captura bem.

A disponibilidade costuma ser descrita em termos de noves, como 99,9% disponível (três noves) ou 99,99% disponíveis (quatro noves). Medir um SLO de disponibilidade é uma das melhores maneiras de avaliar a confiabilidade do sistema.

Além de ajudar a definir o sucesso operacional, um SLO pode ajudar você a escolher onde investir recursos. Os livros de SRE geralmente observam que cada nove que você cria pode resultar em um custo incremental com utilitário secundário. Sabe-se, por exemplo, que atingir o próximo nove em disponibilidade custa dez vezes mais do que o anterior.

Escolher um SLI

Para determinar se um SLO é atendido (ou seja, bem-sucedido), você precisa de uma medida. Essa medida é chamada de indicador de nível de serviço (SLI). Um SLI mede o nível de um determinado serviço que você está entregando ao cliente. O ideal é que o SLI esteja vinculado a uma CUJ aceita.

Selecionar as melhores métricas

A primeira etapa no desenvolvimento de um SLI é escolher uma métrica, como solicitações por segundo, erros por segundo, comprimento da fila, distribuição de códigos de resposta durante um determinado período ou o número de bytes transmitidos.

Essas métricas tendem a ser dos seguintes tipos:

• Contador. Por exemplo, o número de erros que ocorreram até um determinado ponto de medição. Esse tipo de métrica pode aumentar, mas não diminuir.
• Distribuição. Por exemplo, o número de eventos que preenchem um segmento de medição específico para um determinado período. Você pode medir quantas solicitações levam de 0 a 10 ms para serem concluídas, quantas demoram de 11 a 30 ms e quantas levam de 31 a 100 ms. O resultado é uma contagem para cada bucket, por exemplo, [0-10: 50], [11-30: 220], [31-100: 1.103].
• Indicador. Por exemplo, o valor real de uma parte mensurável do sistema, como o comprimento da fila. Esse tipo de métrica pode aumentar ou diminuir.

Para mais informações sobre esses tipos, consulte a documentação do projeto Prometheus e os tipos de métricas do Cloud Monitoring ValueType e MetricKind.

Uma distinção importante sobre SLIs é que nem todas as métricas são SLIs. Na verdade, o SRE Workbook declara o seguinte (grifo adicionado):

"...geralmente, recomendamos tratar o SLI como a proporção de dois números: o número de bons eventos dividido pelo número total de eventos..."

"O SLI varia de 0% a 100%, em que 0% significa que nada funciona e 100% significa que nada está corrompido. Descobrimos essa escala intuitiva e esse estilo estão bem próximos do conceito de erro de orçamento."

Muitas empresas de software rastreiam centenas ou milhares de métricas. Apenas algumas são qualificadas como SLIs. Então, além de ser uma proporção de bons eventos em um total de eventos, o que qualifica uma métrica como um bom SLI? Uma boa métrica de SLI tem as seguintes características:

• A métrica está diretamente relacionada à satisfação do usuário. Geralmente, os usuários ficam insatisfeitos se um serviço não se comportar como esperado, falhar ou ficar lento. Todos os SLOs baseados nessas métricas podem ser validados comparando seu SLI com outros sinais de satisfação do usuário (por exemplo, o número de tíquetes de reclamações de clientes, volume de chamadas de suporte, sentimento de mídia social ou encaminhamentos). Se sua métrica não corresponder a esses outros indícios de satisfação do usuário, talvez não seja uma boa métrica para ser usada como SLI.
• A degradação da métrica está relacionada às interrupções. Uma métrica que apresenta bons resultados durante uma interrupção é a métrica errada para um SLI. Uma métrica que exibe maus resultados durante a operação normal também é errada para um SLI.
• A métrica fornece uma boa proporção sinal/ruído. Qualquer métrica que resulta em um grande número de falsos negativos ou falsos positivos não é uma boa SLI.
• A métrica é escalonada monotonicamente e, de maneira linear, com satisfação no cliente. À medida que a métrica melhora, a satisfação do cliente melhora.

Considere os gráficos no diagrama a seguir. Duas métricas que podem ser usadas como SLIs para um serviço são convertidas em gráficos ao longo do tempo. O período em que um serviço degrada é destacado em vermelho, e o período em que um serviço é bom é destacado em azul.

No caso do SLI inválido, a insatisfação do usuário não corresponde diretamente a um evento negativo (como degradação do serviço, lentidão ou interrupção). Além disso, o SLI flutua independentemente da satisfação do usuário. Com uma boa SLI, a SLI e a satisfação do usuário se correlacionam, os diferentes níveis de satisfação são claros e há muito menos flutuações irrelevantes.

Selecionar o número certo de métricas

Normalmente, um único serviço tem vários SLIs, especialmente quando ele realiza diferentes tipos de trabalho ou atende a diferentes tipos de usuários. Por exemplo, separar as solicitações de leitura de solicitações de gravação é uma boa ideia, já que elas tendem a atuar de maneiras diferentes. Nesse caso, é melhor selecionar métricas apropriadas para cada serviço.

Por outro lado, muitos serviços executam tipos semelhantes de trabalho, o que pode ser diretamente comparável. Por exemplo, se você tiver um marketplace on-line, os usuários poderão visualizar uma página inicial, uma subcategoria ou uma lista de top-10, uma página de detalhes ou pesquisar itens. Em vez de desenvolver e medir uma SLI separada para cada uma dessas ações, combine-as em uma única categoria de SLI, por exemplo, procurar serviços.

Na realidade, as expectativas de um usuário não mudam muito entre as ações de uma categoria semelhante. A satisfação deles não depende da estrutura dos dados que eles buscam, se os dados são derivados de uma lista estática de itens promovidos ou se é o resultado gerado dinamicamente por uma pesquisa sustentada por machine learning em um grande conjunto de dados. Sua felicidade é quantificável por uma resposta a uma pergunta: "Eu vi uma página inteira de itens rapidamente?"

O ideal é usar o menor número possível de SLIs para representar com precisão as tolerâncias de um determinado serviço. Normalmente, um serviço precisa ter entre dois e seis SLIs. Se você tiver poucos SLIs, poderá perder indicadores valiosos. Se tiver muitos SLIs, sua equipe de plantão terá muito o que acompanhar e apenas um utilitário marginal adicionado. Lembre-se de que os SLIs devem simplificar sua compreensão da integridade da produção e fornecer uma sensação de abrangência.

Escolha um SLO

Um SLO é composto pelos seguintes valores:

• Um SLI. Por exemplo, a proporção de respostas com o código HTTP 200 para um número total de respostas.
• Uma duração. O período em que uma métrica é medida. Esse período pode se basear no calendário (por exemplo, do primeiro dia de um mês até o primeiro dia do próximo) ou em uma janela contínua (por exemplo, os últimos 30 dias).
• Um destino. Por exemplo, uma porcentagem desejada de bons eventos em um total de eventos (como 99,9%) que você espera atingir por um determinado período.

À medida que você desenvolve um SLO, definir a duração e a meta pode ser difícil. Uma maneira de iniciar o processo é identificar SLIs e formatá-los ao longo do tempo. Se você não conseguir decidir qual duração e meta usar, lembre-se de que seu SLO não precisa ser perfeito imediatamente. Provavelmente, você irá iterar no SLO para garantir que ele se alinhe à satisfação do cliente e atenda às necessidades da sua empresa. Tente começar com dois noves (99,0%) por um mês.

À medida que acompanha a conformidade com o SLO durante eventos como implantações, interrupções e padrões de tráfego diários, é possível conseguir insights sobre o destino bom, ruim ou até mesmo tolerante. Por exemplo, em um processo em segundo plano, você pode definir 75% de sucesso como adequado. Mas, nas solicitações essenciais para o usuário, é possível tentar algo mais agressivo, como 99,95%.

É claro que não existe um SLO único que pode ser aplicado a todos os casos de uso. Os SLOs dependem de vários fatores:

• expectativas do cliente;
• tipo de carga de trabalho;
• infraestrutura para disponibilização, execução e monitoramento;
• o domínio do problema.

A parte 2 desta série, Adotar SLOs, se concentra em SLOs que não dependem de domínio. SLOs que independem de domínio (como disponibilidade de serviço) não substituem indicadores de nível alto (como widgets vendidos por minuto). No entanto, eles podem ajudar a avaliar se um serviço está funcionando, qualquer que seja o caso de uso comercial.

Os indicadores independentes de domínio geralmente podem ser reduzidos a uma pergunta. Por exemplo, "O serviço está disponível?" ou "O serviço é rápido o suficiente?" Geralmente, a resposta é encontrada em um SLO que considera dois fatores: disponibilidade e latência. Você pode descrever um SLO nos seguintes termos, sendo X = 99,9% e Y = 800 ms:

X% das solicitações válidas são bem-sucedidas e realizadas em menos de Y ms.

A seguir

• Leia Adotar SLOs, que explora essas definições em mais detalhes e apresenta outros SLIs que podem ser mais apropriados para vários tipos de carga de trabalho.
• Confira outros recursos SRE:
  • O livro SRE
  • A pasta de trabalho da SRE
• Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.
• Leia nossos recursos sobre DevOps.
• Saiba mais sobre os recursos de DevOps relacionados a esta série:
  • Monitoramento e observabilidade
  • Como monitorar sistemas para basear decisões de negócios
  • Notificação proativa de falhas
• Faça a verificação rápida de DevOps para entender sua posição em relação ao restante do setor.

Adotar SLOs

Neste documento, definimos vários objetivos de nível de serviço (SLOs, na sigla em inglês) que são úteis para diferentes tipos de cargas de trabalho de serviços comuns. Este documento é a Parte 2 de duas partes. Na Parte 1, Definir SLOs, apresentamos os SLOs, mostramos como eles são derivados dos indicadores de nível de serviço (SLIs, na sigla em inglês) e descrevemos o que faz um bom SLO.

Os relatórios State of DevOps identificaram recursos que impulsionam o desempenho da entrega de software. Esses dois documentos ajudarão você com os seguintes recursos:

• Monitoramento e observabilidade
• Como monitorar sistemas para basear decisões de negócios
• Notificação proativa de falhas

O que medir

Seja qual for o domínio (em inglês), muitos serviços compartilham recursos comuns e podem usar SLOs genéricos. A discussão a seguir sobre SLOs genéricos é organizada por tipo de serviço e inclui explicações detalhadas dos SLIs que se aplicam a cada SLO.

Serviços orientados por solicitação

Um serviço orientado por solicitação recebe uma solicitação de um cliente (outro serviço ou um usuário), executa algum tipo de processamento, talvez envia solicitações de rede para um back-end e retorna uma resposta ao cliente. Os serviços orientados por solicitação costumam ser medidos por SLIs de disponibilidade e latência.

Disponibilidade como um SLI

O SLI para disponibilidade indica se o serviço está funcionando. O SLI para disponibilidade é definido da seguinte maneira:

A proporção de solicitações válidas exibidas com sucesso.

Primeiro, você precisa definir válido. Algumas definições básicas podem ser "tamanho diferente de zero" ou "segue um protocolo de cliente-servidor", mas cabe a um proprietário de serviço definir o que ele quer dizer com válido. Um método comum para avaliar a validade é usar um código de resposta HTTP (ou RPC). Por exemplo, geralmente consideramos erros HTTP 500 como erros do servidor, que são contabilizados em um SLO. Já os erros 400 são erros do cliente, que não são contabilizados.

Depois de decidir o que avaliar, você precisa examinar todos os códigos de resposta retornados pelo sistema para garantir que o aplicativo use esses códigos de maneira adequada e consistente. Ao usar códigos de erro para SLOs, é importante perguntar se um código é um indicador preciso da experiência dos usuários com o serviço. Por exemplo, se um usuário tentar pedir um item que está fora de estoque, o site trava e retorna uma mensagem de erro ou sugere produtos semelhantes? Para uso com SLOs, os códigos de erro precisam estar vinculados às expectativas dos usuários.

Os desenvolvedores podem fazer uso indevido dos erros. No caso em que um usuário pede um produto temporariamente fora do estoque, o desenvolvedor pode programar por engano um erro para ser retornado. No entanto, o sistema está funcionando corretamente e sem erros. O código precisa ser retornado como um sucesso, mesmo que o usuário não possa comprar o item desejado. É claro que os proprietários desse serviço precisam saber que um produto está esgotado, mas a impossibilidade de fazer uma venda não é um erro do ponto de vista do cliente e não deve ser considerado em um SLO. No entanto, se o serviço não conseguir se conectar ao banco de dados para determinar se o item está em estoque, isso é um erro que é contabilizado como erro de orçamento.

Seu serviço pode ser mais complexo. Por exemplo, talvez seu serviço lide com solicitações assíncronas ou ofereça um processo de longa duração para os clientes. Nesses casos, é possível expor a disponibilidade de outra maneira. No entanto, recomendamos que você ainda represente a disponibilidade como a proporção das solicitações válidas bem-sucedidas. É possível definir a disponibilidade como o número de minutos que a carga de trabalho de um cliente está executando, conforme solicitado. Essa abordagem às vezes é chamada de método de "bons minutos" para medir a disponibilidade. No caso de uma máquina virtual, é possível medir a disponibilidade em termos da proporção de minutos após uma solicitação inicial para uma VM para que fique acessível por SSH.

Latência como um SLI

O SLI para latência (às vezes chamado de velocidade) indica se o serviço é rápido o suficiente. O SLI para latência é definido de maneira semelhante à disponibilidade:

A proporção de solicitações válidas exibidas mais rapidamente do que um limite.

É possível medir a latência calculando a diferença entre o início e o fim de um timer para um determinado tipo de solicitação. A chave é a percepção de um usuário sobre a latência. Um problema comum é a precisão excessiva ao medir a latência. Na realidade, os usuários não podem distinguir (em inglês) entre uma atualização de 100 milissegundos (ms) e 300 ms e podem aceitar qualquer ponto entre 300 ms e 1.000 ms.

Em vez disso, é recomendável desenvolver métricas centradas na atividade que mantenham o usuário em foco, por exemplo, nos seguintes processos:

• Interativo: 1.000 ms para o tempo que um usuário aguarda um resultado depois de clicar em um elemento.
• Gravação: 1.500 ms para alterar um sistema distribuído subjacente. Esse período é considerado lento para um sistema, mas os usuários tendem a aceitá-lo. Recomendamos que você diferencie explicitamente entre gravações e leituras em suas métricas.
• Segundo plano: 5.000 ms para uma ação que não é visível ao usuário, como uma atualização periódica de dados ou outras solicitações assíncronas.

A latência é geralmente medida como uma distribuição (em inglês). Consulte Como escolher um SLI na Parte 1 desta série. Dada uma distribuição, é possível medir vários percentis. Por exemplo, é possível medir o número de solicitações que são mais lentas do que o 99º percentil histórico. Nesse caso, consideramos bons eventos como aqueles que são mais rápidos do que esse limite, definido por meio da análise da distribuição histórica. É possível também definir esse limite com base nos requisitos do produto. É possível definir vários SLOs de latência, por exemplo, latência típica versus latência de cauda.

Não recomendamos que você use a latência média (ou mediana) como SLI. Descobrir que a latência mediana é muito lenta significa que metade dos usuários já estão frustrados. Em outras palavras, é possível ter uma latência ruim por dias até descobrir uma ameaça real ao seu erro de orçamento de longo prazo. Portanto, recomendamos que você defina seu SLO como latência de cauda (95º percentil) e como latência mediana (50º percentil).

No artigo Métricas importantes (em inglês) da ACM, Benjamin Treynor Sloss escreve o seguinte:

"Uma boa regra prática... é que a latência de 99º percentil não deve ser mais que três a cinco vezes a latência mediana."

E Treynor Sloss continua:

"Descobrimos que as medidas de latência de 50º, 95º e 99º percentis de um serviço são valiosas individualmente, e o ideal é definir os SLOs para cada uma delas."

Um bom modelo a seguir é determinar seus limites de latência com base em percentis históricos e, em seguida, medir quantas solicitações se enquadram em cada categoria. Para mais detalhes, consulte a seção sobre alertas de latência mais adiante neste documento.

Qualidade como um SLI

A qualidade é um SLI útil para serviços complexos projetados para falhar normalmente por meio da degradação quando as dependências estão lentas ou indisponíveis. O SLI para qualidade é definido da seguinte maneira:

A proporção de solicitações válidas exibidas sem degradação do serviço.

Por exemplo, uma página da Web pode carregar o conteúdo principal de um armazenamento de dados e carregar elementos complementares e recursos opcionais de 100 outros serviços e armazenamentos de dados. Se um serviço opcional estiver inativo ou muito lento, a página ainda poderá ser renderizada sem os elementos complementares. Ao medir o número de solicitações que recebem uma resposta degradada (ou seja, uma resposta sem pelo menos uma resposta do serviço de back-end), informe a proporção de solicitações inválidas. É possível até rastrear quantas respostas ao usuário não receberam uma resposta de um único back-end nem de vários back-ends.

Serviços de processamento de dados

Alguns serviços não são criados para responder a solicitações de usuários, mas consomem dados de uma entrada, processam esses dados e geram uma saída. O desempenho desses serviços em etapas intermediárias não é tão importante quanto o resultado final. Com serviços como esses, os SLIs mais fortes são atualização, cobertura, correção e capacidade, e não latência e disponibilidade.

Atualização como um SLI

O SLI para atualização é definido da seguinte maneira:

A proporção de dados válidos atualizados mais recentemente que um limite.

Em sistemas de processamento em lote, por exemplo, a atualização pode ser medida como o tempo decorrido desde a conclusão de um processamento para uma determinada saída. Em sistemas de processamento mais complexos ou em tempo real, é possível rastrear a idade do registro mais recente processado em um pipeline.

Por exemplo, pense em um jogo on-line que gera blocos de mapa em tempo real. Os usuários podem não perceber a rapidez com que os blocos de mapa são criados, mas podem perceber quando os dados do mapa estão ausentes ou não estão atualizados.

Se preferir, considere um sistema que lê registros de um sistema de rastreamento em estoque para gerar a mensagem "X itens em estoque" para um site de comércio eletrônico. É possível definir o SLI para atualização da seguinte maneira:

A porcentagem de visualizações que usaram as informações de estoque atualizadas no último minuto.

É possível também usar uma métrica para exibir dados não atualizados para informar o SLI para qualidade.

Cobertura como um SLI

O SLI para cobertura é definido da seguinte maneira:

A proporção de dados válidos processados com sucesso.

Para definir a cobertura, primeiro determine se uma entrada será aceita como válida ou ignorada. Por exemplo, se um registro de entrada estiver corrompido ou o tamanho dele for zero e não puder ser processado, considere esse registro como inválido para medir o sistema.

Em seguida, você conta o número de registros válidos. Nesta etapa, use um método count() simples ou outro método. Esse número é a contagem total de registros.

Por fim, para gerar seu SLI para cobertura, conte o número de registros processados com sucesso e compare esse número com a contagem total de registros válidos.

Correção como um SLI

O SLI para correção é definido da seguinte maneira:

A proporção de dados válidos que produziram a saída correta.

Em alguns casos, há métodos para determinar a correção de uma saída que podem ser usados para validar o processamento da saída. Por exemplo, um sistema que gira ou colore uma imagem nunca deve produzir uma imagem de zero byte ou uma imagem com comprimento ou largura igual a zero. É importante separar essa lógica de validação da própria lógica de processamento.

Um método de medição de um SLI de correção é usar dados de entrada de teste reconhecidos, que são dados com uma saída correta conhecida. Os dados de entrada precisam representar os dados do usuário. Em outros casos, é possível que uma verificação matemática ou lógica seja feita na saída, como no exemplo anterior de rotação de uma imagem. Outro exemplo pode ser um sistema de faturamento que determina se uma transação é válida verificando se a diferença entre o saldo antes da transação e o saldo após a transação corresponde ao valor da própria transação.

Capacidade como um SLI

O SLI para capacidade é definido da seguinte maneira:

A proporção de tempo em que a taxa de processamento de dados foi mais rápida que um limite.

Em um sistema de processamento de dados, a capacidade é geralmente mais representativa da satisfação do usuário do que, por exemplo, uma única medição de latência para um determinado trabalho. Por exemplo, se o tamanho de cada entrada variar drasticamente, talvez não faça sentido comparar quanto tempo cada elemento leva para ser concluído se um job avançar a uma taxa aceitável.

Bytes por segundo é uma maneira comum de medir o volume de trabalho necessário para processar dados, seja qual for o tamanho de um conjunto de dados. Mas qualquer métrica que faça o dimensionamento aproximado e linear em relação ao custo de processamento pode funcionar.

Pode ser útil particionar os sistemas de processamento de dados com base nas taxas de capacidade esperadas ou implementar um sistema de qualidade de serviço para garantir que as entradas de alta prioridade sejam processadas e as entradas de baixa prioridade sejam enfileiradas. De qualquer forma, medir a capacidade conforme definido nesta seção pode ajudar você a determinar se seu sistema está funcionando conforme o esperado.

Serviços de execução programada

Para serviços que precisam executar uma ação em um intervalo regular, como cron jobs do Kubernetes, é possível medir o desvio e a duração da execução. Veja a seguir um exemplo de cron job programado do Kubernetes:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

Desvio como um SLI

Como um SLI, o desvio é definido da seguinte maneira:

A proporção de execuções iniciadas dentro de uma janela aceitável do horário de início esperado.

O desvio mede a diferença de horário entre a programação de início de um job e quando ele é iniciado. Por exemplo, se o cron job anterior do Kubernetes, configurado para iniciar no minuto zero de cada hora, começa aos três minutos após a hora, o desvio é de três minutos. Quando um job é executado antecipadamente, você tem um desvio negativo.

É possível medir o desvio como uma distribuição ao longo do tempo, com intervalos aceitáveis correspondentes que definem um bom desvio. Para determinar o SLI, compare o número de execuções que estavam dentro de um bom intervalo.

Duração da execução como um SLI

Como um SLI, a duração da execução é definida da seguinte maneira:

A proporção de execuções que são concluídas dentro da janela de duração aceitável.

Duração da execução é o tempo que um job leva para ser concluído. Para uma determinada execução, um modo de falha comum é para que a duração real exceda a duração programada.

Um caso interessante é como aplicar esse SLI para capturar um job infinito. Como esses jobs não são concluídos, você precisa registrar o tempo gasto em um determinado job, em vez de esperar que ele seja concluído. Essa abordagem fornece uma distribuição precisa de quanto tempo leva para ser concluído, mesmo nos piores cenários.

Assim como acontece com o desvio, é possível acompanhar a duração da execução como uma distribuição e definir limites superiores e inferiores aceitáveis para bons eventos.

Tipos de métricas de outros sistemas

Muitas outras cargas de trabalho têm suas próprias métricas que podem ser usadas para gerar SLIs e SLOs. Veja estes exemplos:

• Sistemas de armazenamento: durabilidade, capacidade, tempo para o primeiro byte, disponibilidade de blob
• Mídia/vídeo: continuidade de reprodução do cliente, tempo para iniciar a reprodução, transcodificação da totalidade de execução do gráfico
• Jogos: tempo para combinar jogadores ativos, tempo para gerar um mapa

Como medir

Depois de saber o que você está medindo, decida como fazer a medição. É possível coletar seus SLIs de várias maneiras.

Geração de registros do lado do servidor

Método para gerar SLIs

Processamento de registros de solicitações ou dados processados do lado do servidor.

Considerações

Vantagens:

• Os registros atuais podem ser reprocessados para preencher registros de SLI históricos.
• Os identificadores de sessão entre serviços podem reconstruir jornadas complexas do usuário em vários serviços.

Desvantagens:

• As solicitações que não chegam ao servidor não são registradas.
• As solicitações que causam falhas em um servidor podem não ser registradas.
• O tempo de processamento dos registros pode resultar em SLIs obsoletos, que podem ser dados inadequados de uma resposta operacional.
• Escrever código para processar registros pode ser uma tarefa passível de erro e demorada.

Métodos e ferramentas de implementação:

• BigQuery
• Dataflow, Apache Spark (em inglês)
• Splunk (em inglês)

Métricas do servidor de aplicativos

Método para gerar SLIs

Exportar métricas de SLI do código que exibe as solicitações dos usuários ou processa os dados deles.

Considerações

Vantagem:

• Adicionar novas métricas ao código geralmente é rápido e barato.

Desvantagens:

• As solicitações que não chegam aos servidores de aplicativos não são registradas.
• As solicitações de vários serviços podem ser difíceis de rastrear.

Métodos e ferramentas de implementação:

• Cloud Monitoring
• Prometheus
• Produtos de APM de terceiros

Métricas de infraestrutura de front-end

Método para gerar SLIs

Usar métricas da infraestrutura de balanceamento de carga, por exemplo, o balanceador de carga global de camada 7 do Google Cloud.

Considerações

Vantagens:

• Métricas e dados históricos geralmente já existem, o que reduz o esforço de engenharia para dar os primeiros passos.
• As medições são realizadas no ponto mais próximo do cliente, mas ainda dentro da infraestrutura de exibição.

Desvantagens:

• Não é viável para SLIs de processamento de dados.
• Só pode aproximar jornadas de usuário de várias solicitações.

Métodos e ferramentas de implementação:

• Cloud Monitoring
• Métricas de CDN/LB ou APIs de geração de relatórios (Cloudflare (em inglês), Akamai, Fastly (em inglês))

Clientes ou dados sintéticos

Método para gerar SLIs

Criar um cliente que envia solicitações geradas em intervalos regulares e que valida as respostas. Para pipelines de processamento de dados, a criação de dados de entrada reconhecidos e sintéticos.

Considerações

Vantagens:

• Mede todas as etapas de uma jornada do usuário de várias solicitações.
• O envio de solicitações de fora da infraestrutura captura mais do caminho geral da solicitação no SLI.

Desvantagens:

• Aproxima a experiência do usuário com solicitações sintéticas, que podem ser enganosas (tanto falsos positivos quanto falsos negativos).
• Cobrir todos os casos extremos é difícil e pode acabar virando um teste de integração.
• Metas de alta confiabilidade exigem sondagens frequentes para uma medição precisa.
• O tráfego da sondagem pode esconder o tráfego real.

Métodos e ferramentas de implementação:

• Verificações de tempo de atividade do Cloud Monitoring
• Soluções de código aberto:
  • Cloudprober (em inglês)
  • blackbox_exporter (em inglês)
• Soluções de fornecedores:
  • Monitoramento sintético da Catchpoint (em inglês)
  • New Relic Synthetics (em inglês)
  • Monitoramento sintético da Datadog (em inglês)

Instrumentação do cliente

Método para gerar SLIs

Adicionar recursos de observabilidade ao cliente com que o usuário interage e registrar eventos na sua infraestrutura de exibição que rastreia SLIs.

Considerações

Vantagens:

• Fornece a medida mais precisa da experiência do usuário.
• Pode quantificar a confiabilidade de terceiros, por exemplo, provedores de CDN ou de pagamento.

Desvantagens:

• A latência de processamento e ingestão de registros do cliente torna esses SLIs inadequados para acionar uma resposta operacional.
• As medições de SLI incluirão vários fatores de alta variação, possivelmente fora do controle direto.
• Incorporar a instrumentação ao cliente pode envolver muito trabalho de engenharia.

Métodos e ferramentas de implementação:

• Google Analytics, Firebase
• Análise do usuário: Amplitude (em inglês) e ferramentas semelhantes
• Monitoramento para dispositivos móveis/front-end: New Relic Browser, Raygun Real User Monitoring, Sentry (links em inglês)
• Cliente e servidor personalizados para registro e rastreamento

Escolher um método de medição

O ideal é escolher um método de medição que se alinhe melhor à experiência do cliente com o serviço e exija o mínimo de esforço da sua parte. Para atingir esse ideal, talvez seja necessário usar uma combinação dos métodos nas tabelas anteriores. Veja a seguir uma abordagem sugerida que pode ser implementada ao longo do tempo, listada em ordem crescente de esforço:

1. Usar exportações de servidores de aplicativos e métricas de infraestrutura. Em geral, é possível acessar essas métricas de imediato, e elas agregam valor rapidamente. Algumas ferramentas de APM incluem as ferramentas de SLO integradas.
2. Usar a instrumentação do cliente. Como os sistemas legados geralmente não têm instrumentação do cliente para usuário final integrada, a configuração da instrumentação pode exigir um investimento significativo. No entanto, se você usar um pacote de APM ou um framework de front-end que fornece instrumentação do cliente, poderá acessar rapidamente insights sobre a satisfação do cliente.
3. Usar o processamento de registros. Se não for possível implementar exportações de servidor ou instrumentação de cliente, mas os registros existirem, talvez o processamento de registros seja a melhor opção. Outra abordagem é combinar exportações e processamento de registros usando as exportações como uma fonte imediata para alguns SLIs (como disponibilidade imediata), e o processamento de registros para sinais de longo prazo (como alertas de esgotamento lento, discutidos mais adiante no guia SLOs e alerta).
4. Implementar testes sintéticos. Depois de ter uma compreensão básica de como seus clientes usam seu serviço, você testa o nível do serviço. Por exemplo, alimente contas de teste com dados válidos conhecidos e consulte-os. Esse teste pode ajudar a destacar modos de falha que não são facilmente observados, como no caso de serviços de baixo tráfego.

Defina seus objetivos

Uma das melhores maneiras de definir objetivos é criar um documento compartilhado que descreva seus SLOs e como você os desenvolveu. Sua equipe pode iterar o documento à medida que ele é implementado e iterado nos SLOs ao longo do tempo.

Recomendamos que os proprietários de empresas, proprietários de produtos e executivos revisem esse documento. As partes interessadas podem oferecer insights sobre as expectativas do serviço e as compensações para confiar em seu produto.

Para as jornadas de usuário críticas (CUJs, na sigla em inglês) da sua empresa, veja um modelo para desenvolver um SLO:

1. Escolha uma especificação de SLI, por exemplo, disponibilidade ou atualização.
2. Defina como implementar a especificação de SLI.
3. Leia todo seu plano para garantir que suas CUJs tenham sido abordadas.
4. Defina os SLOs com base no desempenho anterior ou nas necessidades da empresa.

As CUJs não devem ser limitadas a um único serviço, nem a uma única equipe ou organização de desenvolvimento. Se seus usuários dependem de centenas de microsserviços que operam a 99,5%, mas ninguém rastreia a disponibilidade de ponta a ponta, seu cliente provavelmente não está satisfeito.

Suponha que você tenha uma consulta que dependa de cinco serviços que funcionam em sequência: um balanceador de carga, um front-end, um mixer, um back-end e um banco de dados.

Se cada componente tiver uma disponibilidade de 99,5%, o pior cenário de disponibilidade para o usuário será o seguinte:

99,5% * 99,5% * 99,5% * 99,5% * 99,5% = 97,52%

Esse é o pior cenário de disponibilidade para o usuário porque o sistema geral falhará se algum dos cinco serviços falhar. Isso só acontecerá se todas as camadas da pilha tiverem que estar sempre disponíveis de imediato para processar cada solicitação de usuário, sem fatores de resiliência, como novas tentativas intermediárias, caches ou filas. Um sistema com essa forte ligação entre serviços é um mau design e desafia o modelo de microsserviços.

A simples medição do desempenho em relação ao SLO de um sistema distribuído dessa maneira (serviço a serviço) não reflete com precisão a experiência do cliente e pode resultar em uma interpretação excessivamente sensível.

Em vez disso, é necessário medir o desempenho em relação ao SLO no front-end para entender a experiência dos usuários. O usuário não se importará se um serviço de componente falhar, fazendo com que uma consulta seja repetida automaticamente e com êxito, se a consulta dele ainda for bem-sucedida. Se você tiver compartilhado os serviços internos, esses serviços poderão avaliar separadamente o desempenho em relação aos SLOs, com os serviços voltados para o usuário atuando como clientes. Você precisa processar esses SLOs separadamente.

É possível criar um serviço altamente disponível (por exemplo, 99,99%) sobre um serviço menos disponível (por exemplo, 99,9%) usando fatores de resiliência, como novas tentativas inteligentes, armazenamento em cache e enfileiramento.

Como regra geral, qualquer pessoa com conhecimento prático de estatísticas deve ser capaz de ler e entender seu SLO sem conhecer seu serviço subjacente ou layout organizacional (em inglês).

Exemplo de planilha de SLO

Ao desenvolver o SLO, lembre-se de fazer o seguinte:

• Certifique-se de que seus SLIs especifiquem um evento, um critério de sucesso e onde e como você registra sucesso ou falha.
• Defina a especificação do SLI em termos de proporção de eventos válidos.
• Verifique se o SLO especifica um nível de destino e uma janela de medição.
• Descreva as vantagens e desvantagens da abordagem para que as partes interessadas entendam as compensações e as sutilezas envolvidas.

Por exemplo, considere a seguinte planilha de SLO.

CUJ: carregamento da página inicial

Tipo de SLI: latência Especificação do SLI: proporção de solicitações de página inicial exibidas em menos de 100 ms Implementações de SLI: Proporção de solicitações de página inicial exibidas em menos de 100 ms, conforme medido na coluna de latência do registro do servidor. Desvantagem: essa medição não captura as solicitações que não chegam ao back-end. Proporção de solicitações de página inicial exibidas em menos de 100 ms, conforme medido por sondagens que executam JavaScript em um navegador executado em uma máquina virtual. Vantagens e desvantagens: essa medição detecta erros quando as solicitações não podem alcançar a rede, mas pode perder problemas que afetam apenas um subconjunto de usuários. SLO: 99% das solicitações de página inicial nos últimos 28 dias foram exibidas em menos de 100 ms

Observação: se você não concordar como equipe com um nível desejado, escolha algum nível e concorde em revisá-lo daqui seis meses. Escolher um número errado é melhor do que não escolher nenhum número.

A seguir

• Leia A arte dos SLOs (em inglês), um workshop desenvolvido pela equipe de Engenharia de confiabilidade para o cliente do Google.
• Faça o curso on-line sobre como criar SLOs: Engenharia de confiabilidade do site: medição e gerenciamento de confiabilidade (em inglês).
• Leia Engenharia de confiabilidade do site: como implementar SLOs (em inglês).
• Leia Conceitos de monitoramento de serviço (em inglês).
• Leia sobre o desenvolvimento de SLOs com o Cloud Monitoring (em inglês).
• Avalie o SLO Generator (em inglês) flexível da Professional Services Organization (PSO) do Google.
• Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.
• Leia nossos recursos sobre DevOps.
• Saiba mais sobre os recursos de DevOps relacionados a esta série:
  • Monitoramento e observabilidade
  • Como monitorar sistemas para basear decisões de negócios
  • Notificação proativa de falhas
• Faça a verificação rápida de DevOps para entender sua posição em relação ao restante do setor.

Terminologia

Este documento fornece definições comuns para termos relacionados a SLO usados na seção Framework de arquitetura do Google Cloud: confiabilidade.

• nível de serviço: uma medida do desempenho de um determinado serviço para o usuário. Você pode descrever essa medida em termos de satisfação do usuário e medi-la por vários métodos, dependendo do que o serviço faz e do que o usuário espera que ele faça ou o que foi dito que ele pode fazer.

  Exemplo: "Um usuário espera que nosso serviço esteja disponível e seja rápido."

• jornada crítica do usuário (CUJ, na sigla em inglês): conjunto de interações que um usuário tem com um serviço para atingir uma única meta, por exemplo, um único clique ou um pipeline de várias etapas.

  Exemplo: "Um usuário clica no botão para finalizar a compra e aguarda a resposta de que o carrinho foi processado e um recibo enviado".

• indicador de nível de serviço (SLI): um medidor de satisfação do usuário que pode ser medido de forma quantitativa para um nível de serviço. Em outras palavras, para medir um nível de serviço, você precisa medir um indicador que represente a satisfação do usuário com esse nível de serviço, por exemplo, a disponibilidade dele. Uma SLI pode ser considerada como uma linha em um gráfico que muda com o tempo, à medida que o serviço melhora ou piora. Isso tende a ser um rádio de "bom"/"total" expresso como uma porcentagem sem unidade. Ao usar essas porcentagens de forma consistente, as equipes podem entender o SLI sem um conhecimento profundo da implementação dele.

  Exemplo: "Avalie o número de solicitações bem-sucedidas nos últimos 10 minutos dividido pelo número de todas as solicitações válidas nos últimos 10 minutos."

• Objetivo de nível de serviço (SLO): o nível que você espera que um serviço alcance na maioria das vezes e em relação ao qual um SLI é medido.

  Exemplo: "As respostas de serviço são mais rápidas que 400 milissegundos (ms) para 95% de todas as solicitações válidas avaliadas ao longo de 14 dias."

  

• contrato de nível de serviço (SLA): uma descrição do que precisa acontecer se um SLO não for alcançado. Geralmente, um SLA é um contrato legal entre provedores e clientes e pode até mesmo incluir termos de remuneração. Em discussões técnicas sobre SRE, esse termo geralmente é evitado.

  Exemplo: "Se o serviço não fornecer disponibilidade de 99,95% em um mês, o provedor de serviços compensará o cliente por cada minuto fora da conformidade."

• orçamento do erro: quanto tempo ou quantos eventos negativos você pode tolerar antes de violar seu SLO. Essa medição informa quantos erros sua empresa pode esperar ou tolerar. O erro de orçamento é essencial na ajuda para tomar decisões potencialmente arriscadas.

  Exemplo: "Se nosso SLO estiver com 99,9% disponível, permitiremos que 0,1% das solicitações exibiam erros, sejam incidentes, acidentes ou experimentações".

SLOs e alertas

A seção Framework de arquitetura do Google Cloud: confiabilidade deste documento apresenta detalhes sobre como alertar sobre SLOs.

Uma abordagem incorreta para introduzir um novo sistema de observabilidade, como SLOs, é usar o sistema para substituir completamente um sistema antigo. Em vez disso, você verá os SLOs como um sistema complementar. Por exemplo, em vez de excluir seus alertas atuais, recomendamos que você os execute em paralelo com os alertas de SLO apresentados aqui. Essa abordagem permite que você descubra quais alertas legados preveem alertas de SLO, quais são disparados em paralelo com seus alertas de SLO e quais nunca são disparados.

Um princípio da SRE é alertar com base em sintomas, não em causas (em inglês). Os SLOs são, por sua natureza, medições de sintomas. À medida que você adota alertas de SLO, é possível que perceba que o alerta sintomático é disparado junto com outros alertas. Se você descobrir que seus alertas legados e baseados em causas são disparados sem SLO ou sintomas, eles serão bons candidatos a serem desativados completamente, transformados em alertas de tíquetes ou registrados para referência futura.

Para mais informações, consulte a Apostila de SRE, capítulo 5.

Taxa de esgotamento do SLO

A taxa de esgotamento de um SLO é uma medida da rapidez com que uma interrupção expõe os usuários a erros e esgota o erro de orçamento. Ao medir a taxa de esgotamento, você determina o tempo até que um serviço viole o SLO. Os alertas com base na taxa de esgotamento do SLO são uma abordagem valiosa. Lembre-se de que seu SLO é baseado em uma duração, que pode ser bastante longa (semanas ou até meses). No entanto, a meta é detectar rapidamente uma condição que resulte em uma violação de SLO antes que ela realmente ocorra.

Na tabela a seguir, mostramos o tempo necessário para exceder um objetivo se 100% das solicitações falharem em um determinado intervalo, supondo que as consultas por segundo (QPS, na sigla em inglês) sejam constantes. Por exemplo, se você tiver um SLO de 99,9% medido ao longo de 30 dias, poderá suportar a inatividade total de 43,2 minutos durante esses 30 dias. Por exemplo, essa inatividade pode ocorrer de uma só vez ou espaçada em vários incidentes.

Objetivo	90 dias	30 dias	7 dias	1 dia
90%	9 dias	3 dias	16,8 horas	2,4 horas
99%	21,6 horas	7,2 horas	1,7 horas	14,4 minutos
99,9%	2,2 horas	43,2 minutos	10,1 minutos	1,4 minutos
99,99%	13 minutos	4,3 minutos	1 minuto	8,6 segundos
99,999%	1,3 minutos	25,9 segundos	6 segundos	0,9 segundos

Na prática, não é possível arcar com incidentes de 100% de interrupção se você quer alcançar porcentagens de sucesso altas. No entanto, muitos sistemas distribuídos podem apresentar falha parcial ou se degradar naturalmente. Mesmo nesses casos, você ainda quer saber se uma pessoa precisa ser acionada, mesmo nessas falhas parciais, e os alertas de SLO fornecem uma maneira de determinar isso.

Quando alertar

Uma pergunta importante é quando agir com base na taxa de esgotamento do SLO. Como uma regra, se você esgotar seu erro de orçamento em 24 horas, o momento para chamar alguém para corrigir o problema é agora.

Medir a taxa de falha nem sempre é simples. Uma série de pequenos erros pode parecer assustadora no momento, mas acaba sendo rápida e tem um impacto irrelevante no seu SLO. Da mesma forma, se um sistema falhar levemente por muito tempo, esses erros poderão resultar em uma violação de SLO.

O ideal é que sua equipe reaja a esses sinais para que você gaste quase todo o erro de orçamento (mas não o exceda) em um determinado período. Se você gastar demais, violará o SLO. Se você gastar muito pouco, não correrá risco suficiente ou talvez sobrecarregue sua equipe de plantão.

Você precisa de uma maneira de determinar quando um sistema está corrompido o suficiente para que uma pessoa intervenha. Nas seções a seguir, apresentamos algumas abordagens sobre essa questão.

Esgotamentos rápidos

Um tipo de esgotamento do SLO é o esgotamento rápido, porque ele esgota seu erro de orçamento rapidamente e exige que você intervenha para evitar uma violação do SLO.

Suponha que seu serviço opere normalmente com 1.000 consultas por segundo (QPS, na sigla em inglês), e você queira manter 99% de disponibilidade conforme medido durante uma semana de sete dias. Seu erro de orçamento é de cerca de 6 milhões de erros permitidos (em torno de 600 milhões de solicitações). Se você tiver 24 horas antes do seu erro de orçamento se esgotar, por exemplo, isso representa um limite de cerca de 70 erros por segundo, ou 252.000 erros em uma hora. Esses parâmetros são baseados na regra geral de que os incidentes pagináveis devem consumir pelo menos 1% do erro de orçamento trimestral.

É possível detectar essa taxa de erros antes de transcorrer essa uma hora. Por exemplo, depois de observar uma taxa de 70 erros por segundo durante 15 minutos, é possível chamar o engenheiro de plantão, como mostrado no diagrama a seguir.

O ideal é que o problema seja resolvido antes de você gastar uma hora do seu orçamento de 24 horas. A detecção dessa taxa em uma janela mais curta (por exemplo, um minuto) provavelmente será muito propensa a erros. Se o tempo desejado de detecção for menor que 15 minutos, esse número poderá ser ajustado.

Esgotamentos lentos

Outro tipo de taxa de esgotamento é o esgotamento lento. Suponha que você introduza um bug que esgote seu erro de orçamento semanal no quinto ou sexto dia, ou seu orçamento mensal na segunda semana. Qual é a melhor resposta?

Neste caso, é possível apresentar um alerta de esgotamento lento do SLO que informa que você está prestes a consumir todo o erro de orçamento antes do fim da janela de alerta. É claro que esse alerta pode retornar muitos falsos positivos. Por exemplo, pode haver uma condição em que os erros ocorrem brevemente, mas a uma taxa que consome rapidamente seu erro de orçamento. Nesses casos, a condição é um falso positivo porque dura pouco tempo e não ameaça o erro de orçamento a longo prazo. Lembre-se de que o objetivo não é eliminar todas as fontes de erro, mas manter o intervalo aceitável para não exceder o erro de orçamento. Você quer evitar alertar uma pessoa para intervir em eventos que não sejam uma ameaça legítima ao seu erro de orçamento.

Recomendamos que você notifique uma fila de tíquetes (em vez de ligar ou enviar e-mail para alguém) para eventos de esgotamento lento. Os eventos de esgotamento lento não são emergências, mas exigem atenção de alguém antes que o orçamento se esgote. Esses alertas não podem vir em forma de e-mails para uma lista de equipes, que rapidamente se tornam um incômodo a ser ignorado. Os tíquetes precisam ser rastreáveis, atribuíveis e transferíveis. As equipes devem desenvolver relatórios para carregamento de tíquete, taxas de fechamento, possibilidade de ação e cópias. Tíquetes excessivos e não acionáveis são um ótimo exemplo de trabalho excessivo (em inglês).

O uso eficiente dos alertas de SLO pode levar tempo e depender da cultura e das expectativas da sua equipe. Lembre-se de que é possível ajustar os alertas de SLO ao longo do tempo. É possível também ter vários métodos de alerta, com janelas de alerta variadas, dependendo das suas necessidades.

Alertas de latência

Além dos alertas de disponibilidade, é possível ter alertas de latência. Com os SLOs de latência, você mede a porcentagem de solicitações que não atendem a uma meta de latência. Ao usar esse modelo, é possível usar o mesmo modelo de alerta para detectar esgotamentos rápidos ou lentos da margem de erro.

Conforme observado anteriormente sobre SLOs de latência mediana, metade das suas solicitações pode estar fora do SLO. Em outras palavras, seus usuários podem sofrer uma latência ruim por dias até você detectar o impacto em erro de orçamento de longo prazo. Em vez disso, os serviços precisam definir os objetivos de latência de cauda e de latência típica. Sugerimos usar o percentil 90º histórico para definir a latência típica e o percentil 99º para latência de cauda. Depois de definir essas metas, é possível definir os SLOs com base no número de solicitações que você espera receber em cada categoria de latência e quantas são muito lentas. Essa abordagem segue o mesmo conceito de um erro de orçamento e deve ser tratada da mesma forma. Assim, é possível acabar com uma declaração como "90% das solicitações serão processadas dentro da latência típica e 99,9% dentro das metas de latência de cauda". Essas metas garantem que a maioria dos usuários tenha sua latência típica e ainda permitem acompanhar quantas solicitações são mais lentas do que as metas de latência de cauda.

Alguns serviços podem ter tempos de execução esperados altamente variáveis. Por exemplo, é possível ter expectativas de desempenho muito diferentes para leitura de um sistema de armazenamento de dados em comparação com a gravação. Em vez de enumerar todas as expectativas possíveis, introduza buckets de desempenho do tempo de execução, conforme mostrado nas tabelas a seguir. Essa abordagem pressupõe que esses tipos de solicitações são identificáveis e pré-categorizados em cada bucket. Não espere para categorizar as solicitações imediatamente.

Site voltado para o usuário
Bucket	Tempo de execução máximo esperado
Leitura	1 segundo
Gravação/atualização	3 segundos

Sistemas de processamento de dados
Bucket	Tempo de execução máximo esperado
Pequeno	10 segundos
Médio	1 minuto
Grande	5 minutos
Gigante	1 hora
Imenso	8 horas

Ao avaliar o sistema como ele é hoje, é possível entender quanto tempo essas solicitações costumam levar para ser executadas. Por exemplo, considere um sistema para processar envios de vídeo. Se o vídeo for muito longo, o tempo de processamento deverá levar mais tempo. Podemos usar a duração do vídeo em segundos para categorizar esse trabalho em um bucket, conforme mostrado na tabela a seguir. Na tabela, registramos o número de solicitações por bucket e os vários percentis para distribuição do tempo de execução ao longo de uma semana.

Duração do vídeo	Número de solicitações medidas em uma semana	10%	90%	99,95%
Pequeno	0	-	-	-
Médio	1,9 milhão	864 milissegundos	17 segundos	86 segundos
Grande	25 milhões	1,8 segundo	52 segundos	9,6 minutos
Gigante	4,3 milhões	2 segundos	43 segundos	23,8 minutos
Imenso	81.000	36 segundos	1,2 minuto	41 minutos

Com base nessa análise, é possível derivar alguns parâmetros para alertas:

• fast_typical: no máximo, 10% das solicitações são mais rápidas do que esse tempo. Se muitas solicitações forem mais rápidas do que esse tempo, as metas poderão estar incorretas ou algo sobre o sistema poderá ter sido alterado.
• slow_typical: pelo menos 90% das solicitações são mais rápidas do que esse tempo. Esse limite impulsiona seu SLO de latência principal. Esse parâmetro indica se a maioria das solicitações é rápida o suficiente.
• slow_tail: pelo menos 99,95% das solicitações são mais rápidas do que esse tempo. Esse limite garante que não haja muitas solicitações lentas.
• deadline: o ponto em que uma RPC de usuário ou processamento em segundo plano expira e falha (um limite geralmente codificado no sistema). Essas solicitações não serão, na verdade, lentas, mas falharão de fato com um erro e serão consideradas no seu SLO de disponibilidade.

Uma diretriz de definição de buckets é manter o fast_typical, o slow_typical e o slow_tail de um bucket dentro de uma ordem de magnitude entre eles. Essa diretriz garante que você não tenha um bucket muito amplo. Recomendamos que você não tente evitar a sobreposição ou as lacunas entre os buckets.

Bucket	fast_typical	slow_typical	slow_tail	deadline
Pequeno	100 milissegundos	1 segundo	10 segundos	30 segundos
Médio	600 milissegundos	6 segundos	60 segundos (1 minuto)	300 segundos
Grande	3 segundos	30 segundos	300 segundos (5 minutos)	10 minutos
Gigante	30 segundos	6 minutos	60 minutos (1 hora)	3 horas
Imenso	5 minutos	50 minutos	500 minutos (8 horas)	12 horas

Isso resulta em uma regra como api.method: SMALL => [1s, 10s]. Neste caso, o sistema de rastreamento do SLO verá uma solicitação, determinará o bucket (talvez analisando o nome do método ou o URI e comparando o nome com uma tabela de consulta) e, em seguida, atualizará a estatística com base no tempo de execução dessa solicitação. Se isso levou 700 milissegundos, está dentro da meta de slow_typical. Se for de três segundos, estará dentro de slow_tail. Se for de 22 segundos, estará além de slow_tail, mas ainda não é um erro.

Em termos de satisfação do usuário, pense na falta de latência de cauda como equivalente à indisponibilidade. Ou seja, a resposta é tão lenta que deve ser considerada uma falha. Por causa disso, sugerimos que você use a mesma porcentagem usada para disponibilidade, por exemplo:

99,95% de todas as solicitações são atendidas em dez segundos.

Você decide o que é considerada uma latência típica. Algumas equipes do Google consideram 90% uma boa meta. Isso está relacionado à sua análise e à maneira como você escolheu as durações de slow_typical. Por exemplo:

90% de todas as solicitações são processadas em um segundo.

Alertas sugeridos

De acordo com essas diretrizes, a tabela a seguir inclui um conjunto de valores de referência sugeridos de alertas de SLO.

SLOs	Janela de medição	Taxa de esgotamento	Ação
Disponibilidade, esgotamento rápido Latência típica Latência de cauda	Janela de uma hora	Menos de 24 horas para violação do SLO	Ligar para alguém
Disponibilidade, esgotamento lento Latência típica, esgotamento lento Latência de cauda, esgotamento lento	Janela de sete dias	Mais que 24 horas para violação do SLO	Criar um tíquete

O alerta de SLO é uma habilidade que pode levar tempo para ser desenvolvida. As durações desta seção são sugestões. Ajuste-as de acordo com suas próprias necessidades e nível de precisão. Associar os alertas à janela de medição ou ao consumo de erro de orçamento pode ser útil, ou é possível adicionar outra camada de alerta entre os esgotamentos rápidos e lentos.

Incorpore a observabilidade na infraestrutura e em aplicativos

Este documento no framework de arquitetura do Google Cloud oferece práticas recomendadas para adicionar observabilidade aos serviços para que você possa entender melhor o desempenho do seu serviço e identificar problemas rapidamente. A observabilidade inclui serviços de monitoramento, geração de registros, rastreamento, criação de perfil, depuração e semelhantes.

O monitoramento é a base da hierarquia de confiabilidade do serviço no Manual de SRE do Google. Sem o monitoramento adequado, não é possível saber se um aplicativo está funcionando corretamente.

Instrumentalize seu código para maximizar a capacidade de observação

Um sistema bem projetado tem como objetivo ter a quantidade certa de observabilidade que começa na fase de desenvolvimento. Não espere até que um aplicativo esteja em produção antes de começar a observá-lo. Instrumente seu código e considere as seguintes orientações:

• Para depurar e solucionar problemas de maneira eficiente, pense no que é necessário registrar e rastrear as entradas e nas métricas a serem monitoradas e exportadas. Priorize pelos modos de falha mais prováveis ou frequentes do sistema.
• Audite e elimine periodicamente seu monitoramento. Exclua painéis, gráficos, alertas, traces e registros não utilizados ou desnecessários para reduzir a sobrecarga.

O Google Cloud Observability oferece monitoramento em tempo real, monitoramento e geração de registros multicloud híbridos (como para AWS e Azure), além de rastreamento, criação de perfil e depuração. O Google Cloud Observability também pode descobrir e monitorar automaticamente microsserviços em execução no App Engine ou em uma malha de serviço, como o Istio.

Se você gera muitos dados de aplicativos, pode otimizar o processamento em grande escala de registros de eventos de análise com o BigQuery. O BigQuery também é adequado para persistir e analisar dados de série temporal de alta cardinalidade do framework de monitoramento. Essa abordagem é útil porque permite executar consultas arbitrárias a um custo menor em vez de tentar projetar seu monitoramento perfeitamente desde o início, além de separar os relatórios do monitoramento. É possível criar relatórios a partir dos dados usando o Looker Studio ou o Looker.

Recomendações

Para aplicar a orientação no framework de arquitetura ao seu próprio ambiente, siga estas recomendações:

• Implemente o monitoramento antecipadamente, como antes de iniciar uma migração ou antes de implantar um novo aplicativo em um ambiente de produção.
• Elimine a ambiguidade entre problemas de aplicativos e problemas de nuvem. Use o API Monitoring ou outroCloud Monitoring produtos e a Painel de status do Google Cloud.
• Defina uma estratégia de observabilidade que vá além do monitoramento e que inclua rastreamento, criação de perfil e depuração.
• Limpe regularmente os artefatos de observabilidade que você não usa ou que não agregam valor, como alertas não acionáveis.
• Se você gerar grandes quantidades de dados de observabilidade, envie eventos de aplicativos para um sistema de armazenamento de dados, como o BigQuery.

A seguir

• Projetar para escala e alta disponibilidade (próximo documento desta série)

Explore outras categorias no Framework de arquitetura, como design do sistema, excelência operacional, segurança, privacidade e conformidade.

Projetar para escala e alta disponibilidade

Neste documento no Framework da arquitetura do Google Cloud, você encontra os princípios de design para arquitetar seus serviços, permitindo tolerar falhas e escalonar em resposta à demanda dos clientes. Um serviço confiável continua a responder às solicitações do cliente quando há uma alta demanda no serviço ou quando há um evento de manutenção. Os seguintes princípios de design de confiabilidade e práticas recomendadas precisam fazer parte da arquitetura do sistema e do plano de implantação.

Criar redundância para maior disponibilidade

Sistemas com necessidades de alta confiabilidade não precisam ter pontos únicos de falha, e os recursos precisam ser replicados em vários domínios com falha. Domínio de falha é um pool de recursos que podem falhar de forma independente, como uma região ou zona de instância de VM. Ao replicar entre domínios de falha, o nível agregado de disponibilidade é maior do que o que as instâncias individuais podem alcançar. Para mais informações, consulte Regiões e zonas.

Como um exemplo específico de redundância que pode fazer parte da arquitetura do sistema, para isolar falhas no registro DNS de zonas individuais, use nomes DNS zonais nas instâncias na mesma rede para acessar umas às outras.

Projetar uma arquitetura de várias zonas com failover para alta disponibilidade

Para tornar seu aplicativo resiliente a falhas zonais, arquitete-o para usar pools de recursos distribuídos em várias zonas com replicação de dados, balanceamento de carga e failover automatizado entre zonas. Execute réplicas zonais de cada camada da pilha de aplicativos e elimine todas as dependências entre zonas na arquitetura.

Replicar dados entre regiões para recuperação de desastres

Replicar ou arquivar dados em uma região remota para permitir a recuperação de desastres em caso de interrupção regional ou perda de dados. Quando a replicação é usada, a recuperação é mais rápida porque os sistemas de armazenamento na região remota já têm dados quase atualizados, além da possível perda de uma pequena quantidade de dados devido ao atraso de replicação. Quando você usa o arquivamento periódico em vez da replicação contínua, a recuperação de desastres envolve a restauração de dados de backups ou arquivos em uma nova região. Este procedimento geralmente resulta em um tempo de inatividade maior do que a ativação de uma réplica de banco de dados atualizada continuamente, podendo envolver mais perda de dados devido ao intervalo de tempo entre operações de backup consecutivas. Seja qual for a abordagem usada, toda a pilha de aplicativos precisa ser reimplantada e iniciada na nova região, e o serviço ficará indisponível enquanto isso está acontecendo.

Para uma discussão detalhada sobre técnicas e conceitos de recuperação de desastres, consulte Como arquitetar a recuperação de desastres para interrupções na infraestrutura em nuvem.

Projetar uma arquitetura multirregional para resiliência a interrupções regionais

Se o serviço precisa ser executado continuamente, mesmo no caso raro em que uma região inteira falha, crie-o para usar pools de recursos de computação distribuídos em diferentes regiões. Execute réplicas regionais de cada camada da pilha de aplicativos.

Use a replicação de dados em regiões e o failover automático quando uma região ficar inativa. Alguns serviços do Google Cloud têm variantes multirregionais, como o Spanner. Para ser resistente a falhas regionais, use esses serviços multirregionais no seu design sempre que possível. Para mais informações sobre regiões e disponibilidade de serviços, consulte Locais do Google Cloud.

Evite a dependências entre regiões para que a amplitude do impacto de uma falha no nível da região seja limitada a essa região.

Elimine pontos únicos de falha regionais, como um banco de dados primário de região única que possa causar uma interrupção global quando estiver inacessível. Arquiteturas multirregionais costumam custar mais. Portanto, considere a necessidade de negócios em relação ao custo antes de adotar essa abordagem.

Para mais orientações sobre como implementar redundância em domínios de falha, consulte o artigo de pesquisa arquétipos de implantação para aplicativos em nuvem (PDF em inglês).

Eliminar gargalos de escalonabilidade

Identifique os componentes do sistema que não podem ultrapassar os limites de recursos de uma única VM ou zona. Alguns aplicativos escalonam verticalmente. Nesse caso, você adiciona mais núcleos de CPU, memória ou largura de banda de rede a uma única instância de VM para processar o aumento na carga. Esses aplicativos têm limites absolutos de dimensionamento, e geralmente exigem configuração manual para lidar com o crescimento.

Se possível, recrie esses componentes para escalonamento horizontal, como com fragmentação ou particionamento, em VMs ou zonas. Para lidar com o crescimento do tráfego ou do uso, adicione mais fragmentos. Use tipos de VM padrão que possam ser adicionados automaticamente para processar aumentos na carga por fragmento. Para mais informações, consulte Padrões para aplicativos escalonáveis e resilientes.

Se não for possível redesenhar o aplicativo, será possível substituir componentes gerenciados por você por serviços de nuvem totalmente gerenciados que foram projetados para escalonar horizontalmente sem ação do usuário.

Reduzir os níveis de serviço de maneira suave se estiverem sobrecarregados

Projete seus serviços para tolerarem a sobrecarga. Os serviços devem detectar a sobrecarga e retornar respostas de baixa qualidade para o usuário ou eliminar parcialmente o tráfego, não falhando completamente diante da sobrecarga.

Por exemplo, o serviço pode responder a solicitações de usuários com páginas da Web estáticas e desativar temporariamente o comportamento dinâmico, que é mais caro de processar. Esse comportamento é detalhado no padrão de failover quente do Compute Engine para o Cloud Storage. O serviço também pode permitir operações somente leitura e desativar temporariamente as atualizações de dados.

Os operadores devem ser notificados para corrigir a condição de erro quando um serviço degrada.

Evitar e reduzir picos de tráfego

Não sincronize solicitações entre clientes. Muitos clientes que enviam tráfego ao mesmo tempo causam picos de tráfego que podem causar falhas em cascata.

Implementar estratégias de mitigação de picos do lado do servidor, como limitação, enfileiramento, redução de carga ou disjuntor, degradação suave e priorização de solicitações críticas.

As estratégias de mitigação no cliente incluem limitação do lado do cliente e espera exponencial com instabilidade.

Remover e validar entradas

Para evitar entradas incorretas, aleatórias ou mal-intencionadas que causem falhas temporárias de serviço ou violações de segurança, remova e valide parâmetros de entrada para APIs e ferramentas operacionais. Por exemplo, a Apigee e o Google Cloud Armor podem ajudar a proteger contra ataques de injeção.

Use regularmente o teste de imprecisão, em que um arcabouço de testes chama intencionalmente APIs com entradas aleatórias, vazias ou muito grandes. Realize esses testes em um ambiente de teste isolado.

As ferramentas operacionais precisam validar automaticamente as alterações de configuração antes que as mudanças sejam implementadas, e rejeitar as alterações se a validação falhar.

Falhar com segurança para preservar a função

Se houver uma falha devido a um problema, os componentes do sistema precisarão falhar de forma que o sistema geral continue funcionando. Esses problemas podem ser um bug de software, entrada ou configuração incorreta, uma interrupção de instância não planejada ou erro humano. O que o processo de serviços ajuda a determinar se você precisa ser excessivamente permissivo ou excessivamente simplista, em vez de excessivamente restritivo.

Considere os cenários de exemplo a seguir e como responder a falhas:

• Geralmente, é melhor que um componente de firewall com configuração ruim ou vazia falhe ao abrir e permita que tráfego de rede não autorizado passe por um curto período enquanto o operador corrige o erro. Esse comportamento mantém o serviço disponível, em vez de falhar e fechar 100% do tráfego. O serviço precisa depender de verificações de autenticação e autorização mais profundas na pilha do aplicativo para proteger áreas confidenciais enquanto todo o tráfego passa.
• No entanto, é melhor que um componente do servidor de permissões controle o acesso aos dados do usuário para que ele não seja fechado e bloqueie todo o acesso. Esse comportamento causa uma interrupção do serviço quando a configuração está corrompida, mas evita o risco de vazamento de dados confidenciais do usuário caso o erro seja ignorado.

Em ambos os casos, a falha precisa gerar um alerta de alta prioridade para que um operador possa corrigir a condição de erro. Os componentes de serviço devem errar no lado em que o erro foi ignorado, a menos que apresentem riscos extremos para a empresa.

Projetar chamadas de API e comandos operacionais para serem repetidos

As APIs e ferramentas operacionais precisam tornar as invocações as mais seguras possíveis. Uma abordagem natural para muitas condições de erro é tentar novamente a ação anterior, mas nem sempre é possível saber se a primeira tentativa foi bem-sucedida.

A arquitetura do sistema precisa tornar as ações idempotentes. Se você executar a ação idêntica em um objeto duas ou mais vezes em sequência, ela vai produzir os mesmos resultados que uma única invocação. As ações não idempotentes exigem código mais complexo para evitar uma corrupção do estado do sistema.

Identificar e gerenciar dependências de serviço

Os designers e proprietários de serviços precisam manter uma lista completa de dependências em outros componentes do sistema. O projeto de serviço também precisa incluir recuperação de falhas de dependência ou degradação suave se a recuperação completa não for viável. Considere as dependências nos serviços de nuvem usados pelo sistema e pelas dependências externas, como APIs de serviço de terceiros, reconhecendo que todas as dependências do sistema têm uma taxa de falha diferente de zero.

Ao definir metas de confiabilidade, reconheça que o SLO de um serviço é matematicamente restrito pelos SLOs de todas as dependências críticas. Não é possível ser mais confiável do que o SLO mais baixo de uma das dependências. Para mais informações, consulte o cálculo de disponibilidade do serviço.

Dependências de inicialização

Os serviços se comportam de maneira muito diferente quando são iniciados em comparação com o comportamento de estado estável. As dependências de inicialização podem ser significativamente diferentes das dependências de ambiente de execução de estado estável.

Por exemplo, na inicialização, um serviço pode precisar carregar informações do usuário ou da conta de um serviço de metadados do usuário que raramente invoca novamente. Quando muitas réplicas de serviço são reiniciadas após uma falha ou manutenção de rotina, elas podem aumentar consideravelmente a carga nas dependências de inicialização, principalmente quando os caches estão vazios e precisam ser preenchidos novamente.

Teste a inicialização do serviço sob carga e provisione as dependências de inicialização conforme necessário. Pense em um design para degradação suave salvando uma cópia dos dados que ele recupera de dependências de inicialização críticas. Esse comportamento permite que o serviço seja reiniciado com dados potencialmente desatualizados em vez de impedir a inicialização quando uma dependência crítica tiver uma interrupção. O serviço poderá carregar dados recentes, quando possível, para voltar à operação normal.

As dependências de inicialização também são importantes quando você inicializa um serviço em um novo ambiente. Projete a pilha de aplicativos com uma arquitetura em camadas, sem dependências cíclicas entre elas. As dependências cíclicas podem parecer toleráveis porque não bloqueiam alterações incrementais em um aplicativo. No entanto, as dependências cíclicas podem dificultar ou impossibilitar a reinicialização depois que um desastre remove toda a pilha de serviço.

Minimize as dependências críticas

Minimize o número de dependências críticas para o serviço, ou seja, outros componentes com falha que inevitavelmente causará interrupções no serviço. Para tornar seu serviço mais resiliente a falhas ou lentidão em outros componentes de que depende, considere as seguintes técnicas e princípios de design de exemplo para converter dependências críticas em dependências não críticas:

• Aumente o nível de redundância nas dependências críticas. A adição de mais réplicas diminui a probabilidade de um componente inteiro ficar indisponível.
• Use solicitações assíncronas para outros serviços em vez de bloquear em uma resposta ou use mensagens de publicação/assinatura para separar solicitações de respostas.
• Armazene em cache as respostas de outros serviços para recuperar a indisponibilidade de curto prazo das dependências.

Para tornar as falhas ou lentidão no serviço menos prejudiciais para outros componentes que dependem dele, considere os seguintes exemplos de técnicas e princípios de design:

• Use filas de solicitações priorizadas e dê prioridade maior às solicitações em que um usuário aguarda uma resposta.
• Exiba as respostas de um cache para reduzir a latência e o carregamento.
• Falhar com segurança para preservar a função.
• Faça uma degradação suave quando houver sobrecarga no tráfego.

Garantir que todas as alterações possam ser revertidas

Se não houver uma forma bem definida de desfazer certos tipos de mudanças em um serviço, mude o design do serviço para aceitar a reversão. Teste os processos de reversão periodicamente. As APIs de cada componente ou microsserviço precisam ter versão e compatibilidade com versões anteriores, para que a geração anterior de clientes continue funcionando corretamente à medida que a API evolui. Esse princípio de design é essencial para permitir o lançamento progressivo de alterações da API, com reversão rápida quando necessário.

A reversão pode ser cara para implementar aplicativos em dispositivos móveis. A Configuração remota do Firebase é um serviço do Google Cloud para facilitar a reversão de recursos.

Não é possível reverter as alterações de esquema do banco de dados. Então execute-as em várias fases. Projete cada fase para permitir solicitações seguras de leitura e atualização de esquema pela versão mais recente do aplicativo e pela versão anterior. Essa abordagem de design permite reverter com segurança se houver um problema com a versão mais recente.

Recomendações

Para aplicar a orientação no framework de arquitetura ao seu próprio ambiente, siga estas recomendações:

• Implemente a espera exponencial com ordem aleatória na lógica de repetição de erro dos aplicativos clientes.
• Implemente uma arquitetura multirregional com failover automático para alta disponibilidade.
• Use o balanceamento de carga para distribuir solicitações de usuários entre fragmentos e regiões.
• Projete o aplicativo para degradar suavemente em caso de sobrecarga. Permita respostas parciais ou forneça funcionalidade limitada em vez de falhar completamente.
• Estabeleça um processo baseado em dados para o planejamento de capacidade e use testes de carga e previsões de tráfego para determinar quando provisionar recursos.
• Estabeleça procedimentos de recuperação de desastres e teste-os periodicamente.

A seguir

• Criar ferramentas e processos operacionais confiáveis (próximo documento desta série)

Explore outras categorias no Framework de arquitetura, como design do sistema, excelência operacional e segurança, privacidade e conformidade.

Crie processos operacionais e ferramentas confiáveis

Neste documento, o framework de arquitetura do Google Cloud fornece práticas recomendadas para executar serviços de maneira confiável. Você verá como implantar atualizações, executar serviços em ambientes de produção e testar falhas. A arquitetura da confiabilidade precisa cobrir todo o ciclo de vida do serviço, não apenas o design de software.

Escolha bons nomes para aplicativos e serviços

Evite usar nomes de código internos em arquivos de configuração de produção, porque eles podem ser confusos, especialmente para funcionários mais novos, o que pode aumentar o tempo de minimização (TTM) de interrupções. Na medida do possível, escolha bons nomes para todos os seus aplicativos, serviços e recursos essenciais do sistema, como VMs, clusters e instâncias de banco de dados, sujeitos aos respectivos limites de nome. Um bom nome descreve a finalidade da entidade. são precisas, específicas e diferenciadas; e é significativo para todos que os veem. Um bom nome evita acrônimos, codinomes, abreviações e terminologia potencialmente ofensiva e não cria uma resposta pública negativa mesmo que seja publicado externamente.

Implementar lançamentos progressivos com testes canário

Alterações globais instantâneas em binários de serviço ou configurações são arriscadas. Lance novas versões de executáveis e alterações de configuração gradualmente. Comece com um escopo pequeno, como algumas instâncias de VM em uma zona, e expanda o escopo gradualmente. Reverta rapidamente se a alteração não tiver o desempenho esperado ou afetar negativamente os usuários em qualquer estágio do lançamento. Seu objetivo é identificar e solucionar bugs quando eles afetam apenas uma pequena parte do tráfego do usuário, antes de lançar a alteração globalmente.

Configure um sistema de teste canário que esteja ciente das alterações do serviço e faça uma comparação A/B das métricas dos servidores alterados com os demais. O sistema deve sinalizar um comportamento inesperado ou anômalo. Se o desempenho da alteração não for o esperado, o sistema de teste canário deverá interromper automaticamente as implementações. Os problemas podem ser claros, como erros do usuário, ou sutis, como aumento de uso da CPU ou sobrecarga de memória.

É melhor parar e reverter na primeira dica de problemas e diagnosticar problemas sem a pressão de tempo de uma interrupção. Depois que a alteração for aprovada no teste canário, propague-a gradualmente para escopos maiores, como para uma zona completa e depois para uma segunda zona. Aguarde o sistema alterado lidar com volumes gradualmente maiores de tráfego do usuário para expor bugs latentes.

Para mais informações, consulte Implantação de aplicativos e estratégias de testes.

Distribuir o tráfego para promoções e lançamentos programados

Eventos promocionais, como vendas que começam em uma hora definida, incentivam muitos usuários a se conectarem ao serviço simultaneamente. Diante desses casos, crie um código de cliente para distribuir o tráfego por alguns segundos. Use atrasos aleatórios antes de iniciar as solicitações.

Também é possível pré-aquecer o sistema. Ao pré-aquecer o sistema, você envia o tráfego do usuário previsto com antecedência para garantir que ele funcione conforme o esperado. Isso evita picos de tráfego instantâneos que possam travar os servidores no horário de início programado.

Automatizar a criação, o teste e a implantação

Elimine o esforço manual do processo de lançamento com o uso de pipelines de integração contínua e entrega contínua (CI/CD). Realize testes e implantação de integração automatizados. Por exemplo, crie um processo de CI/CD moderno com o GKE.

Para mais informações, consulte integração contínua, entrega contínua, automação de teste e automação de implantação..

Proteja-se contra erros do operador

Projete suas ferramentas operacionais para rejeitar configurações potencialmente inválidas. Detecte e alerte quando uma versão de configuração estiver vazia, parcial ou truncada, corrompida, logicamente incorreta ou inesperada ou não for recebida dentro do tempo esperado. As ferramentas também precisam rejeitar versões de configuração muito diferentes da versão anterior.

Não permitir alterações ou comandos com um escopo muito amplo que sejam potencialmente destrutivos. Esses comandos amplos podem ser "Revogar permissões para todos os usuários", "Reiniciar todas as VMs nesta região" ou "Reformatar todos os discos nesta zona". Essas alterações só devem ser aplicadas se o operador adicionar sinalizações de linha de comando de substituição de emergência ou configurações de opção ao implantar a configuração.

As ferramentas precisam exibir a amplitude do impacto de comandos arriscados, como o número de VMs que a mudança afeta, e exigir confirmação explícita do operador antes de a ferramenta continuar. Também é possível usar recursos para bloquear recursos essenciais e impedir a exclusão acidental ou não autorizada, como os bloqueios da política de retenção do Cloud Storage.

Testar a recuperação de falhas

Teste regularmente seus procedimentos operacionais para se recuperar de falhas no serviço. Sem testes regulares, os procedimentos podem não funcionar quando você precisar deles no caso de uma falha real. Os itens a serem testados periodicamente incluem failover regional, formas de reverter uma versão e restaurar dados de backups.

Realizar testes de recuperação de desastres

Assim como nos testes de recuperação de falhas, não espere por um desastre. Teste e verifique periodicamente seus procedimentos e processos de recuperação de desastres.

É possível criar uma arquitetura de sistema para fornecer alta disponibilidade (HA, na sigla em inglês). Essa arquitetura não se sobrepõe totalmente à recuperação de desastres (DR), mas geralmente é necessário considerar a HA quando você pensa em valores de objetivo de tempo de recuperação (RTO, na sigla em inglês) e objetivo de ponto de recuperação (RPO, na sigla em inglês).

A HA ajuda você a alcançar ou exceder um nível acordado de desempenho operacional, como tempo de atividade. Ao executar cargas de trabalho de produção no Google Cloud, é possível implantar uma instância de espera passiva ou ativa em uma segunda região. Com essa arquitetura, o aplicativo continuará a fornecer serviços da região não afetada se houver um desastre na região principal. Para mais informações, consulte Como arquitetar a recuperação de desastres para interrupções na nuvem.

Praticar engenharia de caos

Considere o uso da engenharia de caos em suas práticas de teste. Introduza falhas reais em diferentes componentes dos sistemas de produção sob carga em um ambiente seguro. Essa abordagem ajuda a garantir que não haja um impacto geral no sistema porque o serviço processa falhas corretamente em cada nível.

As falhas que você injeta no sistema podem incluir tarefas com falha, erros e tempos limite em RPCs ou reduções na disponibilidade de recursos. Use a injeção de falhas aleatórias para testar falhas intermitentes (oscilação) nas dependências de serviço. Geralmente, esses comportamentos são difíceis de detectar e mitigar na produção.

A engenharia do caos garante que o efeito desses testes seja minimizado e contido. Trate esses testes como prática para interrupções reais e use todas as informações coletadas para melhorar sua resposta de interrupção.

A seguir

• Criar alertas eficientes (próximo documento desta série)

Explore outras categorias no Framework de arquitetura, como design do sistema, excelência operacional e segurança, privacidade e conformidade.

Criar alertas eficientes

Neste documento, no framework de arquitetura do Google Cloud, você encontra princípios operacionais para criar alertas que ajudam a executar serviços confiáveis. Quanto mais informações você tiver sobre o desempenho do serviço, mais informadas serão suas decisões diante de um problema. Projete seus alertas para detecção precoce e precisa de todos os problemas do sistema que afetam o usuário e minimize os falsos positivos.

Otimizar o atraso do alerta

Existe um equilíbrio entre alertas enviados muito cedo e que estressam a equipe de operações e os alertas que são enviados muito atrasados e causam longas interrupções de serviço. Ajuste o atraso do alerta antes que o sistema de monitoramento notifique as pessoas sobre um problema para minimizar o tempo de detecção e, ao mesmo tempo, maximizar o sinal versus ruído. Use a taxa de consumo de margem de erro para derivar a configuração de alerta ideal.

Alertar sobre sintomas e em vez de causas

Acione alertas com base no impacto direto na experiência do usuário. A não conformidade com SLOs globais ou por cliente indica um impacto direto. Evite alertar sobre todas as causas possíveis de uma falha, especialmente quando o impacto for limitado a uma única réplica. Um sistema distribuído bem projetado se recupera perfeitamente de falhas de réplica única.

Alerta sobre valores atípicos em vez de médias

Ao monitorar a latência, defina SLOs e defina alertas para (duas em cada três) latências entre 90o, 95o ou 99o percentil, não para latência média ou 50o percentil. Bons valores de latência média ou mediana podem ocultar valores altas ao 90o percentil ou acima deles, o que causa experiências muito ruins para os usuários. Portanto, aplique esse princípio para alertar sobre valores atípicos ao monitorar a latência de qualquer operação crítica, como uma interação de solicitação/resposta com um servidor da Web, conclusão em lote em um pipeline de processamento de dados ou uma leitura ou gravação em um serviço de armazenamento.

Criar um processo colaborativo de gerenciamento de incidentes

Neste documento, o framework de arquitetura do Google Cloud fornece práticas recomendadas para gerenciar serviços e definir processos para responder a incidentes. Os incidentes ocorrem em todos os serviços. Portanto, você precisa de um processo bem documentado para responder de maneira eficiente a esses problemas e atenuá-los.

Visão geral do gerenciamento de incidente

É inevitável que seu sistema bem projetado acabe falhando em atender aos SLOs. Na ausência de um SLO, seus clientes definem vagamente qual é o nível de serviço aceitável da experiência anterior. Os clientes encaminham para seu suporte técnico ou grupo semelhante, independentemente do que está no SLA.

Para atender adequadamente seus clientes, estabeleça e teste regularmente um plano de gerenciamento de incidentes. O plano pode ser tão curto quanto uma lista de verificação de página única com dez itens. Esse processo ajuda a equipe a reduzir o tempo de detecção (TTD) e o tempo de mitigação (TTM).

O TTM é preferencial em vez do TTR, em que o R para reparo ou recuperação é usado com frequência para indicar uma correção completa em comparação com a mitigação. O TTM enfatiza a mitigação rápida para encerrar rapidamente o impacto do cliente sobre uma interrupção e, em seguida, inicia o processo muitas vezes mais longo para corrigir o problema por completo.

Um sistema bem projetado com operações excelentes aumenta o tempo entre falhas (TBF, na sigla em inglês). Em outras palavras, os princípios operacionais da confiabilidade, incluindo um bom gerenciamento de incidentes, visam reduzir as falhas com frequência.

Para executar serviços confiáveis, aplique as práticas recomendadas a seguir no processo de gerenciamento de incidentes.

Atribuir propriedade de serviço clara

Todos os serviços e as respectivas dependências críticas precisam ter proprietários claros responsáveis pela aderência aos SLOs. Se houver reorganizações ou desgaste de equipes, o lead de engenheiro deve garantir que a propriedade seja explicitamente entregue a uma nova equipe, juntamente com a documentação e o treinamento conforme necessário. Os proprietários de um serviço precisam ser facilmente detectáveis por outras equipes.

Reduzir o tempo de detecção (TTD) com alertas bem ajustados

Antes de reduzir o TTD, revise e implemente as recomendações no Incorporar a observabilidade na infraestrutura e em aplicativos e defina suas metas de confiabilidade seções da categoria de confiabilidade do framework de arquitetura. Por exemplo, elimine a ambiguidade entre problemas de aplicativos e de nuvem.

Um conjunto bem ajustado de SLIs alerta a equipe no momento certo sem sobrecarga de alertas. Para mais informações, consulte a seção Criar alertas eficientes da categoria de confiabilidade do framework de arquitetura ou Ajustar as métricas de SLI: lições de vida do CRE.

Reduzir o tempo de mitigação (TTM) com planos e treinamento de gerenciamento de incidentes.

Para reduzir o TTM, defina um plano de gerenciamento de incidentes documentado e bem treinado. Tenha dados disponíveis sobre o que mudou no ambiente. Certifique-se de que as equipes conheçam as mitigações genéricas que podem aplicar rapidamente para minimizar o TTM. Essas técnicas de mitigação incluem drenagem, reversão de alterações, aumento de recursos e degradação da qualidade do serviço.

Conforme discutido em outro documento da categoria de confiabilidade do Framework de arquitetura, crie processos e ferramentas operacionais confiáveis para oferecer suporte à reversão rápida e segura de alterações.

Projetar layouts e conteúdo de painel para minimizar o TTM

Organize o layout e a navegação do painel de serviços para que um operador possa determinar em um ou dois minutos se o serviço e todas as suas dependências críticas estão em execução. Para identificar rapidamente possíveis causas de problemas, os operadores precisam verificar todos os gráficos no painel para procurar rapidamente aqueles que mudam significativamente no momento do alerta.

A lista a seguir de gráficos de exemplo pode estar no painel para ajudar a resolver problemas. As pessoas que responderem a incidentes devem ser capazes de visualizá-los em um único lugar:

• Indicadores de nível de serviço, como solicitações bem-sucedidas divididas pelo total de solicitações válidas
• Configuração e lançamentos binários
• Solicitações por segundo para o sistema
• Respostas de erro por segundo do sistema
• Solicitações por segundo do sistema para as dependências
• Respostas de erro por segundo ao sistema a partir das dependências

Outros gráficos comuns para ajudar a resolver problemas incluem latência, saturação, tamanho da solicitação, tamanho da resposta, custo da consulta, uso do pool de linhas de execução e métricas da máquina virtual Java (JVM, na sigla em inglês), quando aplicável. Saturação refere-se à integridade por algum limite, como cota ou tamanho de memória do sistema. A utilização de pool de linhas de execução procura regressões devido ao esgotamento do pool.

Teste o posicionamento desses gráficos em alguns cenários de interrupção para garantir que os gráficos mais importantes estejam próximos ao topo e que a ordem dos gráficos corresponda ao fluxo de trabalho de diagnóstico padrão. Também é possível aplicar o machine learning e a detecção de anomalias estatísticas para encontrar o subconjunto certo desses gráficos.

Documente procedimentos de diagnóstico e mitigação de cenários de interrupção conhecido

Escreva manuais e crie um link para eles a partir das notificações de alerta. Se esses documentos estiverem acessíveis a partir das notificações de alerta, os operadores poderão obter rapidamente as informações necessárias para solucionar e mitigar problemas.

Use post mortems sem culpa para aprender com interrupções e evitar recorrências

Estabeleça uma cultura post mortem sem culpa e um processo de revisão de incidentes. Responsabilidade: significa que sua equipe avalia e documenta o que deu errado de maneira objetiva, sem a necessidade de atribuir a culpa.

Erros são oportunidades de aprendizado, não uma causa para críticas. Sempre tente tornar o sistema mais resiliente para que ele possa se recuperar rapidamente de erros humanos ou, melhor ainda, detectar e evitar erros humanos. Extraia o máximo possível de aprendizado de cada post mortem e faça um acompanhamento cuidadoso em cada item de ação post mortem para tornar as interrupções menos frequentes, aumentando assim o TBF.

Exemplo de plano de gerenciamento de incidentes

Foram detectados problemas de produção, por exemplo, por meio de um alerta ou uma página, ou encaminhados para mim:

• Devo delegar para outra pessoa?
  • Sim, se você e sua equipe não conseguirem resolver esse problema.
• Esse problema é uma violação de privacidade ou segurança?
  • Se sim, delegue à equipe de privacidade ou segurança.
• Este problema é uma emergência ou os SLOs estão em risco?
  • Em caso de dúvida, trate como uma emergência.
• Devo envolver mais pessoas?
  • Sim, se afetar mais de X% dos clientes ou se levar mais de Y minutos para resolver. Se estiver em dúvida, sempre envolva mais pessoas, especialmente durante o horário comercial.
• Defina um canal principal de comunicação, como IRC, Hangouts Chat ou Slack.
• Delegue papéis definidos anteriormente, como os seguintes:
  • Comandante do incidente que é responsável pela coordenação geral.
  • Líder de comunicações responsável por comunicações internas e externas
  • O líder de operações é responsável por mitigar o problema.
• Defina quando o incidente termina. Esta decisão pode exigir uma confirmação de um representante de suporte ou de outras equipes semelhantes.
• Colabore no post mortem sem culpa.
• Participe de uma reunião de análise retrospectiva dos incidentes para discutir as ações necessárias da equipe.

Recomendações

Para aplicar a orientação no framework de arquitetura ao seu próprio ambiente, siga estas recomendações:

• Estabeleça um plano de gerenciamento de incidentes e treine suas equipes para usá-lo.
• Para reduzir o TTD, implemente as recomendações para criar observabilidade na infraestrutura e nos aplicativos.
• Crie uma coluna "O que mudou?", que você pode ver quando há incidente.
• Documente os snippets de consulta ou crie um painel do Looker Studio com consultas de registro frequentes.
• Avalie a Configuração remota do Firebase para reduzir os problemas de lançamento de aplicativos para dispositivos móveis.
• Teste a recuperação de falhas, incluindo a restauração de dados de backups, para diminuir o TTM de um subconjunto de incidentes.
• Projete e teste configurações e reversões binárias.
• Replique dados entre regiões para recuperação de desastres e use testes de recuperação de desastres para diminuir o TTM após interrupções regionais.
• Projetar uma arquitetura multirregional para resiliência de interrupções regionais se a empresa precisar de alta disponibilidade justificar o custo, para aumentar o TBF.

A seguir

Saiba mais sobre como criar um processo colaborativo de gerenciamento de incidentes com os seguintes recursos:

• Painel de status do Google Cloud
• Gerenciamento de incidentes no Google
• Processo de resposta a incidentes de dados
• Capítulo do livro "SRE" sobre o gerenciamento de incidentes

Explore outras categorias no Framework de arquitetura, como design do sistema, excelência operacional e segurança, privacidade e conformidade.

Estrutura de arquitetura do Google Cloud: guias de confiabilidade do produto

Nesta seção do framework de arquitetura, há práticas recomendadas específicas do produto quanto à confiabilidade, disponibilidade e consistência de alguns produtos do Google Cloud. Os guias também fornecem recomendações para minimizar e se recuperar de falhas, bem como para escalonar seus aplicativos bem sob carga.

Observação: para saber mais sobre os elementos básicos da confiabilidade no nível da plataforma no Google Cloud (zonas, regiões e recursos com escopo de localização) e os níveis de disponibilidade que eles fornecem, consulte o Guia de confiabilidade da infraestrutura do Google Cloud. Neste guia, também fornecemos diretrizes para avaliar os requisitos de confiabilidade das cargas de trabalho e apresentamos recomendações de arquitetura para criação e gerenciamento de infraestruturas confiáveis no Google Cloud.

Os guias de confiabilidade do produto são organizados nas seguintes áreas:

• Computação
  • Compute Engine
  • Cloud Run
  • Cloud Functions
  • Google Kubernetes Engine
• Armazenamento e bancos de dados
  • Cloud Storage
  • Firestore
  • Bigtable
  • Cloud SQL
  • Spanner
  • Filestore
  • Memorystore
• Rede
  • Cloud DNS
  • Cloud Load Balancing
  • Cloud CDN
• Análise de dados
  • BigQuery
  • Dataflow
  • Dataproc

Guia de confiabilidade do Compute Engine

O Compute Engine é um serviço de computação personalizável que permite criar e executar máquinas virtuais sob demanda na infraestrutura do Google.

Práticas recomendadas

• Práticas recomendadas da API Compute Engine: práticas recomendadas para usar a API Compute Engine e atenuar os efeitos dos limites de taxa da API.
• Como desenvolver sistemas resilientes: orientações detalhadas sobre como arquitetar seus aplicativos do Compute Engine para se recuperar de falhas ou reinicializações de VM única e falhas zonais ou regionais.
• Como aumentar a disponibilidade por provisionamento excessivo: adicione recursos redundantes para manter seu aplicativo em execução diante de perdas de capacidade devido a interrupções regionais ou por zona.
• Como usar o balanceamento de carga para aplicativos altamente disponíveis: como usar o Cloud Load Balancing com o Compute Engine para oferecer alta disponibilidade, mesmo durante uma interrupção de zona.
• Práticas recomendadas para a seleção de regiões do Compute Engine: como escolher quais regiões do Google Cloud usar para os recursos do Compute Engine, a fim de otimizar a latência para seus aplicativos, considerando as compensações de preço/desempenho.
• Práticas recomendadas para migrar VMs usando o Migrate to Virtual Machines: como migrar VMs de um ambiente de origem que oferece suporte ao Compute Engine com o Migrate to Virtual Machines, incluindo avaliação, planejamento e realização da migração. Saiba também como lidar com problemas comuns que podem surgir com a migração.
• Padrões para usar endereços IP flutuantes no Compute Engine: como implementar endereços IP compartilhados ou virtuais em um ambiente do Compute Engine, alterando a arquitetura para um padrão do seu caso de uso. Os padrões incluem aqueles que usam balanceamento de carga, rotas do Google Cloud e recuperação automática.
• Práticas recomendadas para snapshots de discos permanentes: crie snapshots mais rapidamente e com mais confiabilidade.
• Replicação e discos permanentes: como os discos permanentes usam o Colossus para o back-end de armazenamento e acessam discos permanentes de VMs. Além disso, o monitoramento da latência do disco permanente, a replicação de discos permanentes entre regiões ou zonas e como as solicitações de leitura e gravação são processadas para réplicas
• Configurar discos para atender aos requisitos de desempenho: fatores que afetam o desempenho de volumes de armazenamento em blocos anexados a instâncias de VM.
• Práticas recomendadas de gerenciamento de imagens: orientações detalhadas sobre como gerenciar imagens do Compute Engine, como escolher uma imagem de inicialização, personalizar imagens, ciclo de vida da imagem e compartilhar imagens entre projetos.
• Práticas recomendadas para famílias de imagens: a importância de testar a imagem mais recente em uma família antes de usar ela na produção e como configurar o procedimento de teste.
• Práticas recomendadas para instâncias do SQL Server: práticas recomendadas para otimizar instâncias do Compute Engine que executam o Microsoft SQL Server e otimizar o SQL Server Enterprise Edition. Saiba também como usar as configurações de rede padrão do sistema operacional e as atividades operacionais para melhorar o desempenho e a estabilidade.

Guia de confiabilidade do Cloud Run

O Cloud Run é uma plataforma de computação gerenciada adequada para implantação de aplicativos em contêineres e não tem servidor. O Cloud Run cuida de toda a infraestrutura para que os usuários possam se concentrar na criação de aplicativos.

Práticas recomendadas

• Dicas gerais do Cloud Run: como implementar um serviço do Cloud Run, iniciar contêineres rapidamente, usar variáveis globais e melhorar a segurança do contêiner.
• Práticas recomendadas de teste de carga: como carregar serviços do Cloud Run de teste, incluindo problemas de simultaneidade antes de teste de carga, gerenciar o número máximo de instâncias, escolher a melhor região para teste de carga e garantir que os serviços sejam escalonados de acordo com a carga.
• Escalonamento de instâncias: como dimensionar e limitar instâncias de contêiner e manter o tempo de resposta mantendo algumas instâncias inativas em vez de interrompê-las.
• Como usar instâncias mínimas: especifique o menor número de instâncias de contêiner prontas para veiculação e, quando definido corretamente, minimize o tempo médio de resposta reduzindo o número de inicializações a frio.
• Otimização de aplicativos Java para o Cloud Run: entenda as vantagens e desvantagens de algumas otimizações para os serviços do Cloud Run escritos em Java e reduza o tempo de inicialização e o uso de memória.
• Otimização de aplicativos Python para o Cloud Run: otimize a imagem do contêiner melhorando a eficiência do servidor WSGI e otimize os aplicativos reduzindo o número de linhas de execução e executando tarefas de inicialização em paralelo.

Guia de confiabilidade do Cloud Functions

O Cloud Functions é uma plataforma escalonável, orientada por eventos e sem servidor para ajudar a criar e conectar serviços. O Cloud Functions pode ser chamado por meio de solicitação HTTP ou acionado com base em eventos em segundo plano.

Práticas recomendadas

• Práticas recomendadas do Cloud Functions: diretrizes sobre como usar e interagir com o Cloud Functions, implementar a idempotência, implantar funções e otimizar o desempenho.

Guia de confiabilidade do Google Kubernetes Engine

O Google Kubernetes Engine (GKE) é um sistema para operação em escala de aplicativos conteinerizados na nuvem. O GKE implanta, gerencia e provisiona recursos para aplicativos em contêineres. O ambiente do GKE consiste em instâncias do Compute Engine agrupadas para formar um cluster.

Práticas recomendadas

• Práticas recomendadas para operar contêineres: como usar mecanismos de geração de registros, garantir que os contêineres sejam sem estado e imutáveis, monitorar aplicativos e fazer sondagens de atividade e prontidão.
• Práticas recomendadas para criar contêineres: como empacotar um aplicativo único por contêiner, processar identificadores de processos (PIDs, na sigla em inglês), otimizar o cache de criação do Docker e criar imagens menores para acelerar os tempos de upload e download.
• Práticas recomendadas para a rede do Google Kubernetes Engine: use clusters nativos de VPC para facilitar o escalonamento, planeje endereços IP, escalone a conectividade do cluster, use o Google Cloud Armor para bloquear ataques distribuídos de negação de serviço (DDoS), implemente o balanceamento de carga nativo de contêiner para reduzir a latência, use a funcionalidade de verificação de integridade dos balanceadores de carga de aplicativo externos para realizar um failover adequado e use os clusters regionais para aumentar a disponibilidade dos aplicativos em um cluster.
• Preparar aplicativos do Kubernetes baseados na nuvem: aprenda as práticas recomendadas para planejar a capacidade de aplicativos, expandir os aplicativos horizontalmente ou verticalmente, definir limites de recursos em relação às solicitações de recursos de memória e CPU, tornar os contêineres enxutos para uma inicialização mais rápida de aplicativos. e limitar a interrupção de Pod definindo um Pod Disruption Budget (PDB). Além disso, entenda como configurar sondagens de atividade e prontidão para uma inicialização elegante de aplicativos, garantir encerramentos não interruptivos e implementar espera exponencial em solicitações repetidas para evitar picos de tráfego que sobrecarregam o aplicativo.
• Práticas recomendadas para multilocação no GKE: como projetar uma arquitetura de cluster multilocatário com alta disponibilidade e confiabilidade, usar a medição de uso do Google Kubernetes Engine (GKE) para métricas de uso por locatário e fornecer registros específicos ao locatário e forneça monitoramento específico para locatários.

Guia de confiabilidade do Cloud Storage

O Cloud Storage é um repositório de objetos durável e altamente disponível com recursos avançados de segurança e compartilhamento. Esse serviço é usado para armazenar e acessar dados na infraestrutura do Google Cloud.

Práticas recomendadas

• Práticas recomendadas para o Cloud Storage: práticas recomendadas gerais para o Cloud Storage, incluindo dicas para maximizar a disponibilidade e minimizar a latência dos aplicativos, melhorar a confiabilidade das operações de upload e melhorar o desempenho de exclusões de dados em grande escala.
• Diretrizes de taxa de solicitação e distribuição de acesso: como minimizar as latências e respostas de erro em operações de leitura, gravação e exclusão em taxas de solicitação muito altas, entendendo como o escalonamento automático do Cloud Storage funciona.

Guia de confiabilidade do Firestore

O Firestore é um banco de dados de documentos NoSQL que permite armazenar, sincronizar e consultar dados para seus aplicativos da Web e para dispositivos móveis em escala global.

Práticas recomendadas

• Práticas recomendadas do Firestore: como selecionar o local do banco de dados para aumentar a confiabilidade, minimizar as armadilhas de desempenho na indexação, melhorar o desempenho de operações de leitura e gravação, reduzir a latência para notificações de alterações e criar o escalonamento.

Guia de confiabilidade do Bigtable

O Bigtable é um banco de dados NoSQL escalonável e totalmente gerenciado para grandes cargas de trabalho de análise e operacionais. Ele é projetado como uma tabela preenchida de maneira esparsa, que pode ser escalonada para bilhões de linhas e milhares de colunas e compatível com uma alta capacidade de leitura e gravação com baixa latência.

Práticas recomendadas

• Entenda o desempenho do Bigtable: como estimar a capacidade de processamento do Bigtable, como planejar a capacidade do Bigtable analisando a capacidade de processamento e o uso do armazenamento, como a ativação da replicação afeta a capacidade de leitura e gravação de maneira diferente e como o Bigtable otimiza os dados ao longo do tempo.
• Projeto de esquema do Bigtable: orientações sobre como projetar o esquema do Bigtable, incluindo conceitos de repositório de chave-valor, criação de chaves de linha com base em solicitações de leitura planejadas, gerenciamento de colunas e linhas e casos de uso especiais.
• Visão geral da replicação do Bigtable: como replicar o Bigtable em várias zonas ou regiões, conceitos básicos sobre as implicações de desempenho da replicação e como o Bigtable resolve conflitos e lida com failovers.
• Sobre os backups do Bigtable: como salvar uma cópia do esquema e dos dados de uma tabela com os backups do Bigtable, que podem ajudar a recuperar dados corrompidos no nível do aplicativo ou a partir de erros do operador, como a exclusão acidental de uma tabela.

Guia de confiabilidade do Cloud SQL

O Cloud SQL é um serviço de banco de dados relacional totalmente gerenciado para MySQL, PostgreSQL e SQL Server. O Cloud SQL se integra facilmente a aplicativos atuais e serviços do Google Cloud, como o Google Kubernetes Engine e o BigQuery.

Práticas recomendadas

• Alta disponibilidade do Cloud SQL: uma visão geral da configuração de alta disponibilidade do Cloud SQL, incluindo o processamento de réplicas de leitura e o processo de failover. Também inclui como controlar o tempo dos eventos de manutenção do banco de dados e como o uso do disco permanente regional na configuração de alta disponibilidade afeta o desempenho do banco de dados. Esse conteúdo é dividido em três seções:

  • Alta disponibilidade do MySQL
  • Alta disponibilidade do PostgreSQL
  • Alta disponibilidade do SQL Server

• Recuperação de desastres do banco de dados do Cloud SQL: uma visão geral da configuração de recuperação de desastres do Cloud SQL usando uma réplica de leitura entre regiões.

  • Recuperação de desastres do MySQL
  • Recuperação de desastres do PostgreSQL
  • Recuperação de desastres do SQL Server

• Práticas recomendadas gerais para o Cloud SQL: orientações sobre como configurar instâncias, arquiteturas de dados, importações e exportações de dados, backups e a recuperação. Esse conteúdo é dividido em três seções:

  • Práticas recomendadas do MySQL
  • Práticas recomendadas do PostgreSQL
  • Práticas recomendadas do SQL Server

• Práticas recomendadas para importar e exportar dados: em quais circunstâncias os buckets do Cloud Storage não podem ser usados, compactar dados para reduzir custos, limitações conhecidas com a importação e exportação de dados, como automatizar operações de exportação e resolver problemas nas operações de importação e exportação.

  • Práticas recomendadas do MySQL
  • Práticas recomendadas do PostgreSQL
  • Práticas recomendadas do SQL Server

Guia de confiabilidade do Spanner

O Spanner é um serviço distribuído de gerenciamento e armazenamento de bancos de dados SQL com recursos como transações globais, escalonamento horizontal altamente disponível e consistência transacional.

Práticas recomendadas

• Backup e restauração do Spanner: principais recursos de backup e restauração do Spanner, comparação entre backup e restauração e importação e exportação, detalhes de implementação e controle de acesso aos recursos do Spanner.
• Configurações regionais e multirregionais: uma descrição dos dois tipos de configurações de instância que o Spanner oferece: as configurações regionais e as multirregionais. A descrição inclui as diferenças e as desvantagens entre cada configuração.
• Escalonamento automático do Spanner: introdução à ferramenta de escalonamento automático do Spanner (Escalonador automático), uma ferramenta de código aberto que pode ser usada como complemento do Cloud Spanner. Essa ferramenta permite aumentar ou reduzir automaticamente o número de nós ou unidades de processamento em uma ou mais instâncias do Spanner com base nas métricas de utilização de cada instância do Spanner.
• Sobre a recuperação pontual (PITR): descrição da recuperação pontual (PITR) do Spanner, um recurso que protege você contra exclusão ou gravações acidentais de dados do Spanner. Por exemplo, um operador grava acidentalmente dados ou uma distribuição de aplicativo corrompe o banco de dados. Com a PITR, você pode recuperar seus dados de um momento específico no passado (até um máximo de sete dias) sem problemas.
• Práticas recomendadas para o Spanner: orientações sobre o carregamento em massa, uso da linguagem de manipulação de dados (DML), criação de esquema para evitar pontos de acesso e práticas recomendadas de SQL.

Guia de confiabilidade do Filestore

O Filestore é um serviço de armazenamento de arquivos gerenciados para aplicativos do Google Cloud, com uma interface de sistema de arquivos e um sistema de arquivos compartilhados para dados. O Filestore oferece armazenamento conectado à rede (NAS, na sigla em inglês) em escala de petabyte para instâncias do Compute Engine e do Google Kubernetes Engine.

Práticas recomendadas

• Desempenho do Filestore: configurações de desempenho e recomendações do tipo de máquina do Compute Engine, opções de montagem do NFS para melhorar o desempenho em instâncias de VM do cliente Linux e uso da ferramenta fio para testar o desempenho. Inclui recomendações para melhorar o desempenho em vários recursos do Google Cloud.

• Backups do Filestore: descrição de backups do Filestore, casos de uso comuns e práticas recomendadas para criar e usar backups.

• Snapshots do Filestore: descrição de snapshots do Filestore, casos de uso comuns e práticas recomendadas para criar e usar snapshots.

• Rede do Filestore: requisitos de rede e recursos de IP necessários para usar o Filestore.

Guia de confiabilidade do Memorystore

O Memorystore é um armazenamento na memória totalmente gerenciado que fornece uma versão gerenciada de duas soluções de armazenamento em cache de código aberto: Redis e Memcached. O Memorystore é escalonável e automatiza tarefas complexas, como provisionamento, replicação, failover e aplicação de patches.

Práticas recomendadas

• Práticas recomendadas gerais do Redis: orientações sobre como exportar backups do Redis Database (RDB), operações que consomem muitos recursos e operações que exigem uma nova tentativa de conexão. Além disso, informações sobre manutenção, gerenciamento de memória e configuração do conector de acesso VPC sem servidor, bem como o modo de conexão de acesso privado a serviços e monitoramento e alertas.
• Práticas recomendadas de gerenciamento de memória da Redis: conceitos de gerenciamento de memória, como capacidade da instância e configuração de Maxmemory, exportação, escalonamento e operações de upgrade de versão, métricas de gerenciamento de memória e como resolver uma condição de falta de memória.
• Espera exponencial do Redis: como a espera exponencial funciona, um algoritmo de exemplo e como a espera máxima e o número máximo de novas tentativas funcionam.
• Práticas recomendadas do Memcached: como projetar aplicativos para ausências no cache, se conectar diretamente aos endereços IP dos nós e serviço de descoberta automática do Memcached. Além disso, há orientações sobre como configurar o parâmetro max-item-size, fazer o balanceamento de clusters e usar o Cloud Monitoring para monitorar métricas essenciais.
• Práticas recomendadas de gerenciamento de memória do Memcached - como configurar memória para uma instância do Memcached, configuração de memória reservada, quando aumentar a memória reservada e métricas para uso de memória.

Guia de confiabilidade do Cloud DNS

O Cloud DNS é um sistema de nome de domínio de baixa latência que ajuda a registrar, gerenciar e exibir seus domínios. O Cloud DNS escalona para um grande número de zonas e registros DNS. Milhões de registros DNS podem ser criados e atualizados em uma interface de usuário.

Práticas recomendadas

• Práticas recomendadas do Cloud DNS: saiba como gerenciar zonas particulares, configurar o encaminhamento de DNS e criar políticas do servidor DNS. Inclui orientações sobre o uso do Cloud DNS em um ambiente híbrido.

Guia de confiabilidade do Cloud Load Balancing

O Cloud Load Balancing é um serviço totalmente gerenciado, distribuído e definido por software para todo o tráfego. O Cloud Load Balancing também oferece escalonamento automático contínuo, balanceamento de carga de camada 4 e camada 7 e suporte para recursos como balanceamento de carga global IPv6.

Práticas recomendadas

• Práticas recomendadas de desempenho: como distribuir a carga entre as instâncias do aplicativo para ter o melhor desempenho. As estratégias incluem a colocação de back-end em regiões mais próximas ao tráfego, armazenamento em cache, seleção do protocolo de regra de encaminhamento e configuração da afinidade de sessão.
• Como usar o balanceamento de carga para aplicativos altamente disponíveis: como usar o Cloud Load Balancing com o Compute Engine para oferecer alta disponibilidade, mesmo durante uma interrupção de zona.

Guia de confiabilidade do Cloud CDN

O Cloud CDN (rede de fornecimento de conteúdo) é um serviço que acelera o envio de conteúdo pela Internet usando a rede de borda do Google para aproximar o conteúdo ao usuário. O Cloud CDN ajuda a reduzir a latência, o custo e a carga, facilitando o escalonamento de serviços para os usuários.

Práticas recomendadas

• Práticas recomendadas de envio de conteúdo: como otimizar a proporção de ocorrência em cache usando chaves de cache, garantir que o HTTP/3 esteja ativado para melhorar o desempenho e analisar as métricas de monitoramento usando o painel de monitoramento personalizado do Cloud CDN. Além disso, veja como analisar relatórios sobre disponibilidade, latência e capacidade de processamento de testes de desempenho de terceiros.

Guia de confiabilidade do BigQuery

O BigQuery é a plataforma de armazenamento de dados do Google Cloud para armazenar e analisar dados em escala.

Práticas recomendadas

• Introdução à confiabilidade: práticas recomendadas de confiabilidade e introdução a conceitos como disponibilidade, durabilidade e consistência de dados.
• Disponibilidade e durabilidade: os tipos de domínios de falha que podem ocorrer em data centers do Google Cloud, como o BigQuery oferece redundância de armazenamento com base no local de armazenamento de dados e por que os conjuntos de dados entre regiões melhoram a recuperação de desastres.
• Práticas recomendadas para cargas de trabalho de vários locatários no BigQuery: padrões comuns usados em plataformas de dados de vários locatários. Esses padrões incluem garantir a confiabilidade e o isolamento para clientes de fornecedores de software como serviço (SaaS), cotas e limites importantes do BigQuery para planejamento de capacidade, usar o serviço de transferência de dados do BigQuery para copiar conjuntos de dados relevantes para outra região e muito mais.
• Usar visualizações materializadas: como usar visualizações materializadas do BigQuery para consultas mais rápidas e com custo menor, incluindo consultas de visualizações materializadas, alinhamento de partições e compreensão do ajuste inteligente (reescrita automática de consultas).

Guia de confiabilidade do Dataflow

O Dataflow é um serviço de processamento de dados totalmente gerenciado que permite o desenvolvimento rápido e simplificado de pipelines de dados de streaming usando bibliotecas do Apache Beam de código aberto. O Dataflow minimiza a latência, o tempo de processamento e o custo usando escalonamento automático e processamento em lote.

Práticas recomendadas

Como criar pipelines de dados prontos para produção usando o Dataflow: uma série de documentos que aborda o uso do Dataflow, incluindo planejamento, desenvolvimento, implantação e monitoramento de pipelines do Dataflow.

• Visão geral: introdução aos pipelines do Dataflow.
• Planejamento: como medir SLOs, entender o impacto de coletores e fontes de dados na escalonabilidade e no desempenho do pipeline e como considerar a alta disponibilidade, a recuperação de desastres e o desempenho da rede ao especificar as regiões para executar os jobs do Dataflow.
• Desenvolvimento e testes: como configurar ambientes de implantação, evitar a perda de dados usando filas de mensagens inativas para tratamento de erros e como reduzir a latência e o custo minimizando operações caras por elemento. Além disso, com o uso de lotes para reduzir a sobrecarga de desempenho sem sobrecarregar os serviços externos, unificar etapas mescladas de maneira inadequada para que as etapas sejam separadas e melhorar o desempenho, e executar testes completos na pré-produção para garantir que o pipeline continue a atender aos SLOs e a outros requisitos de produção.
• Implantação: integração contínua (CI) e entrega e implantação contínuas (CD), com considerações especiais para implantar novas versões de pipelines de streaming. Veja também um exemplo de pipeline de CI/CD e alguns recursos para otimizar o uso de recursos. Por fim, abordamos a alta disponibilidade, a redundância geográfica e as práticas recomendadas para a confiabilidade do pipeline, incluindo isolamento regional, uso de snapshots, tratamento de erros de envio de jobs e recuperação de erros e interrupções dos serviços que afetam a execução de pipelines.
• Monitoramento: observe os indicadores de nível de serviço (SLIs), que são importantes indicadores de desempenho do pipeline, e defina e avalie os objetivos de nível de serviço (SLOs).

Guia de confiabilidade do Dataproc

O Dataproc é um serviço escalonável e totalmente gerenciado para executar jobs do Apache Hadoop e do Spark. Com o Dataproc, as máquinas virtuais podem ser personalizadas e escalonadas verticalmente, se for necessário. O Dataproc se integra perfeitamente ao Cloud Storage, ao BigQuery, ao Bigtable e a outros serviços do Google Cloud.

Práticas recomendadas

• Modo de alta disponibilidade do Dataproc: compare o modo de alta disponibilidade (HA, na sigla em inglês) do Hadoop com o modo padrão não alta disponibilidade em termos de nomes de instância, Apache ZooKeeper, Hadoop Distributed File System (HDFS) e Yet Another Resource Negotiator (YARN). Aprenda também a criar um cluster de alta disponibilidade.
• Clusters de escalonamento automático: quando usar o escalonamento automático do Dataproc, como criar uma política de escalonamento automático, uso da política de vários clusters, práticas recomendadas de confiabilidade para a configuração de escalonamento automático, métricas e registros.
• Modo de flexibilidade aprimorado (EFM, na sigla em inglês) do Dataproc: exemplos de como usar o modo de flexibilidade aprimorada para minimizar atrasos no progresso do job, configuração avançada, como particionamento e paralelismo, e desativação otimizada do YARN em clusters EFM.
• Desativação otimizada: use a desativação otimizada para minimizar o impacto da remoção de workers de um cluster, como usar esse recurso com workers secundários e exemplos de comando para a desativação otimizada.
• Jobs reinicializáveis: com as configurações opcionais, é possível definir jobs a serem reiniciados em caso de falha para reduzir os tipos comuns de falha, incluindo problemas de falta de memória e reinicializações inesperadas da máquina virtual do Compute Engine.

Estrutura de arquitetura do Google Cloud: otimização de custos

Esta categoria no Framework da arquitetura do Google Cloud fornece recomendações de design e descreve as práticas recomendadas para ajudar arquitetos, desenvolvedores, administradores e outros profissionais de nuvem a otimizar os custos do cargas de trabalho no Google Cloud.

Migrar suas cargas de trabalho de TI para a nuvem pode ajudar a inovar em escala, oferecer recursos mais rapidamente e atender às necessidades crescentes dos clientes. Para migrar cargas de trabalho atuais ou implantar aplicativos criados para a nuvem, é necessário ter uma topologia otimizada para segurança, resiliência, excelência operacional, custo e desempenho.

Na categoria de otimização de custos do Framework de arquitetura, você aprenderá a fazer o seguinte:

• Adotar e implementar o FinOps: estratégias para ajudar você a incentivar os funcionários a considerar o impacto dos custos ao provisionar e gerenciar recursos no Google Cloud.
• Monitore e controle custos: práticas recomendadas, ferramentas e técnicas para acompanhar e controlar o custo dos seus recursos no Google Cloud.
• Otimizar o custo: computação, contêineres e sem servidor: controles de otimização de custos específicos de serviço para o Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions e App Engine.
• Otimizar o custo: armazenamento: controles de otimização de custos para o Cloud Storage, Persistent Disk e Filestore.
• Otimizar o custo: bancos de dados e análises inteligentes: controles de otimização de custos para o BigQuery, o Bigtable, o Spanner, o Cloud SQL, o Dataflow e o Dataproc.
• Otimizar o custo: rede: controles de otimização de custos para seus recursos de rede no Google Cloud.
• Otimizar o custo: operações do Cloud: recomendações para ajudar você a otimizar o custo de monitoramento e gerenciamento de recursos no Google Cloud.

Adotar e implementar as FinOps

Neste documento, o framework de arquitetura do Google Cloud descreve estratégias para ajudar você a considerar o impacto do custo das ações e decisões ao provisionar e gerenciar recursos no Google Cloud. Ele discute FinOps, uma prática que combina pessoas, processos e tecnologias para promover a responsabilidade financeira e a disciplina de otimização de custos em uma organização, independentemente dos tamanho ou maturidade na nuvem.

A orientação nesta seção é destinada a CTOs, CIOs e executivos responsáveis por controlar os gastos da organização na nuvem. As orientações também ajudam os operadores de nuvem a entender e adotar as FinOps.

Todos os funcionários da sua organização podem ajudar a reduzir o custo dos recursos no Google Cloud, independentemente da função (analista, arquiteto, desenvolvedor ou administrador). Nas equipes que não precisaram acompanhar os custos de infraestrutura no passado, talvez seja necessário instruir os funcionários sobre a necessidade de responsabilidade coletiva.

Um modelo comum é usado por uma equipe central de FinOps ou o Centro de excelência em nuvem (CCoE, na sigla em inglês) para padronizar o processo de otimização de custos em todas as cargas de trabalho na nuvem. Esse modelo considera que a equipe central tem o conhecimento e a experiência necessários para identificar oportunidades de alto valor para melhorar a eficiência.

O controle centralizado de custos pode funcionar bem nos estágios iniciais da adoção da nuvem quando o uso é baixo, mas não funciona bem quando a adoção e o uso da nuvem aumentam. É possível que a equipe central tenha dificuldade para escalonar e as equipes de projeto não aceitem as decisões tomadas por outras pessoas.

Recomendamos que a equipe central delegue a tomada de decisão para a otimização de recursos às equipes do projeto. A equipe central pode gerar esforços mais amplos para incentivar a adoção do FinOps em toda a organização. Para permitir que as equipes de projeto individuais pratiquem o FinOps, a equipe central precisa padronizar o processo, o relatório e as ferramentas para otimização de custos. A equipe central precisa trabalhar de perto com equipes que não estão familiarizadas com as práticas de FinOps e ajudá-las a considerar o custo nos processos de tomada de decisão. A equipe central também precisa atuar como um intermediário entre a equipe de finanças e as equipes de projeto individuais.

As seções a seguir descrevem os princípios de design que recomendamos para sua equipe central promover.

Estimular a responsabilidade individual

Qualquer funcionário que cria e usa recursos na nuvem afeta o uso e o custo desses recursos. Para que uma organização atinja a implementação das FinOps, a equipe central precisa ajudar os funcionários a fazer a transição do custo como responsabilidade de outra pessoa para que se torne um responsabilidade individual. Com essa transição, os funcionários são proprietários e tomam as decisões de custo adequadas para as cargas de trabalho, a equipe e a organização. Essa propriedade se estende à implementação de ações de otimização de custos baseadas em dados.

Para incentivar a responsabilidade pelo custo, a equipe central pode realizar as seguintes ações:

• Instrua os usuários sobre oportunidades e técnicas de otimização de custos.
• Recompense os funcionários que otimizam os custos e comemore junto com eles o sucesso.
• Exiba os custos em toda a organização.

Tornar os custos visíveis

Para que os funcionários considerem o custo ao provisionar e gerenciar recursos na nuvem, eles precisam de uma visão completa dos dados relevantes, o mais próximo possível do tempo real. Os dados nos relatórios e painéis precisam mostrar o custo e o impacto empresarial das decisões dos membros da equipe conforme os impactos relevantes ocorrem. Os dados de uso e custo de outras equipes podem servir como valores de referência para identificar padrões de implantação eficientes. Esses dados podem ajudar a promover uma compreensão compartilhada das melhores maneiras de usar serviços em nuvem.

Se uma organização não incentivar e promover o compartilhamento de dados de custo, os funcionários poderão ser resistentes a compartilhar dados. Por motivos comerciais, às vezes, uma organização pode não permitir o compartilhamento de dados brutos de custo. Mesmo nesses casos, recomendamos evitar uma política padrão que restrinja o acesso a informações de custo.

Para tornar os custos visíveis em toda a organização, a equipe central pode realizar as seguintes ações:

• Use um método único e bem definido para calcular os custos totalmente carregados dos recursos da nuvem. Por exemplo, o método pode considerar o gasto total em nuvem ajustado para descontos comprados e custos compartilhados, como o custo dos bancos de dados compartilhados.
• Configure painéis que permitam aos funcionários visualizar os gastos na nuvem quase em tempo real.
• Para motivar as pessoas a assumir os próprios custos, permita uma ampla visibilidade dos gastos na nuvem entre as equipes.

Ativar um comportamento colaborativo

O gerenciamento eficaz de custos com recursos de nuvem exige que as equipes colaborem para melhorar os processos técnicos e operacionais. Uma cultura colaborativa ajuda as equipes a criar padrões de implantação econômicos com base em um conjunto consistente de objetivos e fatores de negócios.

Para permitir o comportamento colaborativo, a equipe central pode realizar as seguintes ações:

• Crie um processo de integração de carga de trabalho que ajude a garantir a eficiência de custos na etapa de design por meio de revisões de pares de arquiteturas propostas por outros engenheiros.
• Crie uma base de conhecimento entre equipes com padrões de arquitetura econômicos.

Estabelecer uma cultura sem culpa

Promova uma cultura de aprendizado e crescimento que corra riscos, faça correções quando necessário e inove. Reconheça que erros, às vezes caros, podem acontecer em qualquer estágio durante o ciclo de vida de design e implantação de TI, como em qualquer outra parte do negócio.

Em vez de culpar e humilhar pessoas que ultrapassaram ou iniciaram um cenário, promova uma cultura sem culpa que ajude a identificar a causa de overruns e erros de cálculo. Nesse ambiente, os membros da equipe são mais propensos a compartilhar visualizações e experiências. Os erros são anonimizados e compartilhados em toda a empresa para evitar recorrência.

Não confunda uma cultura sem culpa de sua responsabilidade. Os funcionários continuam sendo responsáveis pelas decisões que tomam e pelo dinheiro gasto Porém, quando ocorrem erros, a ênfase é na oportunidade de aprendizado para evitar que eles ocorram novamente.

Para estabelecer uma cultura sem culpa, a equipe central pode realizar as seguintes ações:

• Execute análises sem apontar culpados (em inglês) por grandes problemas de custo, com foco na causa raiz sistêmica dos problemas, e não nas pessoas envolvidas.
• Celebre os membros da equipe que respondem a custos excessivos e que compartilham lições aprendidas. Incentive outros membros da equipe a compartilhar erros, ações tomadas e lições aprendidas.

Foco no valor dos negócios

Embora as práticas de FinOps geralmente sejam voltadas à redução de custos, o foco de uma equipe central precisa ser permitir que as equipes de projeto tomem decisões que maximizem o valor comercial dos recursos da nuvem. Pode ser tentador tomar decisões que reduzam o custo até um ponto em que os níveis mínimos de serviço sejam alcançados. No entanto, essas decisões geralmente mudam o custo para outros recursos, gerando maior custo de manutenção e aumentando o custo total de propriedade. Por exemplo, para reduzir custos, opte por usar máquinas virtuais (VMs) em vez de um serviço gerenciado. No entanto, uma solução baseada em VM exige mais esforço de manutenção quando comparada com um serviço gerenciado. Portanto, o serviço gerenciado pode oferecer um valor comercial maior.

As práticas de FinOps podem fornecer às equipes de projeto a visibilidade e os insights necessários para tomar decisões arquitetônicas e operacionais que maximizam o valor comercial dos recursos da nuvem.

Para ajudar os funcionários a se concentrarem no valor comercial, a equipe central pode realizar as seguintes ações:

• Usar serviços gerenciados e arquiteturas sem servidor para reduzir o custo total de propriedade dos recursos de computação. Para ver mais informações, consulte Escolher uma plataforma de computação.

• Correlacione o uso da nuvem com métricas de valor comercial, como eficiência de custos, resiliência, velocidade de atributos e inovação que geram decisões de otimização de custos. Para saber mais sobre métricas de valor comercial, consulte o whitepaper sobre o Cloud FinOps.

• Implemente o custo unitário de todos os seus aplicativos e serviços na nuvem.

A seguir

• Saiba mais sobre o FinOps:
  • Maximizar o valor comercial com o Cloud FinOps
  • Primeiros passos com FinOps no Google Cloud
  • FinOps Foundation
  • Custo de unidade na nuvem
• Monitorar e controlar custos
• Otimize o custo dos serviços do Google Cloud:
  • Custo de otimização: computação, contêineres e sem servidor
  • Otimizar custo: armazenamento
  • Otimizar custo: bancos de dados e análises inteligentes
  • Otimizar custo: rede
  • Otimizar custo: operações na nuvem
• Explore as outras categorias do Framework da arquitetura do Google Cloud

Monitorar e controlar custos

Neste documento, no Framework da arquitetura do Google Cloud, descrevemos as práticas recomendadas, ferramentas e técnicas para ajudar você a rastrear e controlar o custo dos seus recursos no Google Cloud.

As orientações nesta seção são destinadas aos usuários que provisionam ou gerenciam recursos na nuvem.

Áreas de foco em gerenciamento de custos

O custo dos recursos no Google Cloud depende da quantidade de recursos usados e da taxa de cobrança dos recursos.

Para gerenciar o custo dos recursos da nuvem, recomendamos que você se concentre nas seguintes áreas:

• Visibilidade de custo
• Otimização de recursos
• Otimização da taxa

Visibilidade de custo

Acompanhe o gasto e os recursos e serviços que são cobrados para analisar o efeito do custo nos resultados comerciais. Recomendamos que você siga o modelo operacional FinOps, que sugere as seguintes ações para tornar informações de custo visíveis em toda a organização:

• Alocar: atribua um proprietário a cada item de custo.
• Relatório: disponibilize dados de custo, consumíveis e acionáveis.
• Previsão: calcule e acompanhe os gastos futuros.

Otimização de recursos

Alinhe o número e o tamanho dos seus recursos de nuvem aos requisitos da sua carga de trabalho. Sempre que possível, pense em usar serviços gerenciados ou rearquitetar seus aplicativos. Normalmente, as equipes de engenharia individuais têm mais contexto do que a equipe central de FinOps (operações financeiras) sobre oportunidades e técnicas para otimizar a implantação de recursos. Recomendamos que a equipe de FinOps trabalhe com as equipes de engenharia individuais para identificar oportunidades de otimização de recursos que possam ser aplicadas em toda a organização.

Otimização da taxa

A equipe do FinOps geralmente toma decisões de otimização de taxas de maneira centralizada. Recomendamos que as equipes de engenharia individuais trabalhem com a equipe central do FinOps para aproveitar grandes descontos para reservas, uso contínuo, VMs do Spot, preço fixo, volume e desconto de contrato.

Recomendações de design

Nesta seção, sugerimos abordagens que podem ser usadas para monitorar e controlar custos.

Consolide o faturamento e o gerenciamento de recursos

Para gerenciar o faturamento e os recursos no Google Cloud com eficiência, recomendamos que você use uma única conta de faturamento para sua organização e use mecanismos internos de estorno para alocar custos. Use várias contas de faturamento para conglomerados e organizações com estrutura leve que não se afetem uns aos outros. Por exemplo, os revendedores podem precisar de contas distintas para cada cliente. O uso de contas de faturamento separadas também pode ajudar você a cumprir regulamentações fiscais específicas do país.

Outra prática recomendada é mover todos os projetos que você gerencia para sua organização. Recomendamos o uso do Resource Manager para criar uma hierarquia de recursos que ajude você a atingir os seguintes objetivos:

• Estabeleça uma hierarquia de propriedade de recursos com base na relação de cada recurso com o pai imediato.
• Controle como as políticas de acesso e os rótulos de alocação de custos são anexados e herdados pelos recursos na sua organização.

Além disso, recomendamos que você aloque o custo dos serviços compartilhados proporcionalmente com base no consumo. Revise e ajuste os parâmetros de alocação de custos periodicamente com base nas alterações nas metas e prioridades de negócios.

Acompanhar e alocar custos usando tags ou rótulos

Tags e rótulos são dois métodos diferentes que podem ser usados para anotar seus recursos do Google Cloud. As tags oferecem mais recursos do que os rótulos. Por exemplo, é possível implementar um controle detalhado sobre os recursos criando políticas de gerenciamento de identidade e acesso (IAM) que são condicionais baseadas em uma tag ou não anexada a um recurso compatível. Além disso, as tags associadas a um recurso são herdadas por todos os recursos filhos na hierarquia. Para mais informações sobre as diferenças entre tags e rótulos, consulte Visão geral das tags.

Se você estiver criando uma nova estrutura para alocação e rastreamento de custos, recomendamos o uso de tags.

Para categorizar os dados de custo na granularidade necessária, estabeleça um esquema de rotulagem que se adapte ao mecanismo de estorno da sua organização e ajude a alocar os custos adequadamente. É possível definir tags no nível da organização ou do projeto. É possível atribuir rótulos no nível do projeto e definir um conjunto de rótulos que podem ser aplicados por padrão a todos os projetos.

Defina um processo para detectar e corrigir anomalias e anomalias em projetos não rotulados Por exemplo, no Inventário de recursos do Cloud, é possível fazer o download de um inventário (arquivo .csv) de todos os recursos em um projeto e analisar o inventário para identificar recursos que não receberam nenhuma tag ou rótulo.

Para rastrear o custo dos recursos e serviços compartilhados (por exemplo, repositórios comuns, clusters multilocatários e assinaturas de suporte), considere usar uma tag ou rótulo especial para identificar projetos que contenham recursos compartilhados.

Configurar o controle de acesso de faturamento

Para controlar o acesso ao Cloud Billing, recomendamos atribuir o papel de "Administrador da conta de faturamento" apenas aos usuários que gerenciam dados de contato do faturamento. Por exemplo, talvez os funcionários do setor de finanças, contabilidade e operações precisem desse papel.

Para evitar um ponto único de falha no suporte de faturamento, atribua o papel "Administrador da conta de faturamento" a vários usuários ou a um grupo. Somente os usuários com o papel de administrador da conta de faturamento podem entrar em contato com o suporte. Para orientações detalhadas, consulte Exemplos de controle de acesso do Cloud Billing e Papéis importantes.

Faça as configurações a seguir para gerenciar o acesso ao faturamento:

• Para associar uma conta de faturamento a um projeto, os membros precisam ter os papéis de usuário da conta de faturamento e do gerente de faturamento do projeto.
• Para permitir que as equipes associem manualmente as contas de faturamento aos projetos, atribua o papel "Gerente de faturamento" do projeto no nível da organização e o papel "Usuário da conta de faturamento" na conta de faturamento. Você pode automatizar a associação de contas de faturamento durante a criação do projeto atribuindo os papéis de administrador do projeto e de usuário da conta de faturamento a uma conta de serviço. Recomendamos que você restrinja o papel de Criador da conta de faturamento ou remova todas as atribuições desse papel.
• Para evitar falhas temporárias causadas por mudanças não intencionais no status de faturamento de um projeto, é possível bloquear o vínculo entre o projeto e a conta de faturamento dele. Para mais informações, consulte Proteger o link entre um projeto e a conta de faturamento dele.

Configurar relatórios de faturamento

Configure relatórios de faturamento para fornecer dados sobre as principais métricas que você precisa rastrear. Recomendamos que você acompanhe as seguintes métricas:

• Tendências de custo
• Usuários que gastam mais (por projeto e por produto)
• Áreas de gastos irregulares
• Veja insights importantes sobre toda a organização:
  • Detecção de anomalias
  • Tendências ao longo do tempo
  • Tendências que ocorrem em um padrão definido (por exemplo, mês a mês)
  • Comparação de custos e análise de comparativo de mercado entre cargas de trabalho internas e externas
  • Rastreamento de casos de negócios e realização de valores (por exemplo, custos de nuvem em comparação com o custo de recursos locais semelhantes)
  • Validação de que as faturas do Google Cloud são esperadas e precisas

Analisar tendências e prever custos

Personalize e analise relatórios de custos com o BigQuery Billing Export e visualize dados de custos com o Looker Studio. Avalie a tendência dos custos reais e quanto você pode gastar usando a ferramenta de previsão.

Otimizar o uso e o custo dos recursos

Esta seção indica as práticas recomendadas para ajudar você a otimizar o uso e o custo dos seus recursos nos serviços do Google Cloud.

Para evitar gastos excessivos, considere configurar orçamentos e alertas padrão com limites altos para todos os seus projetos. Para ajudar a manter o orçamento, recomendamos que você faça o seguinte:

• Configurar orçamentos e alertas para projetos em que os limites de uso absolutos são necessários (por exemplo, projetos de treinamento ou sandbox).

• Defina orçamentos com base nos orçamentos financeiros que você precisa acompanhar. Por exemplo, se um departamento tem um orçamento geral de nuvem, defina o escopo do orçamento do Google Cloud para incluir os projetos específicos que você precisa rastrear.

• Para garantir que os orçamentos sejam mantidos, delegue a responsabilidade de configurar orçamentos e alertas às equipes que têm as cargas de trabalho.

Para otimizar custos, também recomendamos o seguinte:

• Limite o uso da API nos casos em que o impacto for mínimo ou inexistente para os negócios. O limite pode ser útil para projetos de sandbox ou treinamento e para projetos com orçamentos fixos (por exemplo, análise ad-hoc no BigQuery). O recurso não remove todos os recursos e dados dos projetos associados.
• Use cotas para definir limites absolutos que limitam a implantação de recursos. Elas ajudam você a controlar custos e impedir o uso e o uso indevido de recursos. As cotas são aplicadas no nível do projeto, por tipo de recurso e por local.
• Veja e implemente as recomendações de otimização de custos no Hub de recomendações.
• Compre descontos por uso contínuo (CUD, na sigla em inglês) para economizar dinheiro em recursos para cargas de trabalho com necessidades previsíveis de recursos.

Ferramentas e técnicas

As características de provisionamento e pagamento por uso sob demanda da nuvem ajudam você a otimizar seus gastos com TI. Nesta seção, descrevemos ferramentas que o Google Cloud fornece e técnicas que podem ser usadas para rastrear e controlar o custo dos recursos na nuvem. Antes de usar essas ferramentas e técnicas, revise os conceitos básicos do Cloud Billing.

Relatórios de faturamento

O Google Cloud oferece relatórios de faturamento no Console do Google Cloud para ajudar você a visualizar seus gastos atuais e previstos. Com os relatórios de faturamento, você pode ver dados de custo em uma única página, descobrir e analisar tendências, prever o custo do final do período e tomar medidas corretivas quando necessário.

Os relatórios de faturamento oferecem os seguintes dados:

• Os custos e tendências de custos de um determinado período, organizados da seguinte maneira:
  • Por conta de faturamento
  • Por projeto
  • Por produto (por exemplo, Compute Engine)
  • Por SKU (por exemplo, endereços IP estáticos)
• Os possíveis custos se descontos ou créditos promocionais forem excluídos
• Gasto previsto

Exportação de dados para o BigQuery

É possível exportar relatórios de faturamento para o BigQuery e analisar custos com visualizações granulares e históricas de dados, incluindo os dados categorizados com marcadores. É possível realizar análises mais avançadas usando o BigQuery ML. Recomendamos que você ative a exportação de relatórios de faturamento para o BigQuery quando criar a conta do Cloud Billing. O conjunto de dados do BigQuery contém dados de faturamento a partir da data em que você configurou a exportação do Faturamento do Cloud. O conjunto de dados não inclui dados do período anterior à ativação da exportação.

Observação: os dados de faturamento exportados podem ser diferentes dos dados nas faturas, devido a dados informados tardiamente, variações de carimbo de data/hora, erros e ajustes e tributos. de dados. Para mais informações, consulte Diferenças entre dados exportados e faturas.

Para visualizar os dados de custo, crie painéis personalizados integrados ao BigQuery (modelos de exemplo: Looker e Looker Studio).

É possível usar tags e rótulos como critérios para filtrar os dados de faturamento exportados. O número de rótulos incluídos na exportação de faturamento é limitado. Até 1.000 mapas de rótulos em um período de uma hora são preservados. Eles não aparecem no arquivo PDF ou CSV da fatura. Anote os recursos usando rótulos que indicam a unidade de negócios, a unidade de estorno interno e outros metadados relevantes.

Controle de acesso ao faturamento

É possível controlar o acesso ao Cloud Billing para recursos específicos definindo políticas de gerenciamento de identidade e acesso (IAM) para os recursos. Para conceder ou limitar o acesso ao Cloud Billing é possível definir uma política do IAM no nível da organização, da conta de faturamento do Cloud e/ou do projeto.

Observação: embora as contas de faturamento estejam vinculadas a projetos, as contas de faturamento não são pais de projetos no IAM. Os projetos não herdam permissões da conta de faturamento a que estão vinculados.

O controle de acesso para faturamento e gerenciamento de recursos segue o princípio da separação de tarefas. Cada usuário tem apenas as permissões necessárias para o papel da empresa. Os papéis de administrador da organização e de faturamento não têm as mesmas permissões.

É possível definir permissões relacionadas ao faturamento nos níveis da conta de faturamento e da organização. Os papéis comuns são "Administrador da conta de faturamento", "Usuário da conta de faturamento" e "Visualizador da conta de faturamento".

Recomendamos que você use o faturamento com fatura ou configure uma forma de pagamento alternativa. Manter as configurações de contato e notificação para faturamento e pagamento.

Orçamentos, alertas e cotas

Com os orçamentos, você rastreia os custos reais do Google Cloud em comparação com os gastos planejados. Ao criar um orçamento, é possível configurar regras de alerta para acionar notificações por e-mail quando o gasto real ou previsto exceder um limite definido Também é possível usar orçamentos para automatizar as respostas de controle de custos.

Os orçamentos podem acionar alertas para informar sobre o uso de recursos e tendências de custo, além de solicitar ações de otimização de custos. No entanto, os orçamentos não impedem o uso ou o faturamento dos serviços quando o custo real atinge ou excede o orçamento ou o limite. Para controlar automaticamente os custos, use as notificações de orçamento para desativar o Cloud Billing de maneira programática em um projeto. Também é possível limitar o uso da API para interromper os custos após um limite de uso definido.

Você pode configurar alertas para contas e projetos de faturamento. Configure pelo menos um orçamento para uma conta.

Para evitar o provisionamento de recursos além de um nível predeterminado ou para limitar o volume de operações específicas, é possível definir cotas no nível do recurso ou da API. Veja exemplos de como usar cotas:

• Controle o número de chamadas de API por segundo.
• Limite o número de VMs criadas.
• Restrinja o volume de dados consultados por dia no BigQuery.

Os proprietários de projetos podem reduzir a quantidade de cota que pode ser cobrada em um limite de cota, usando a API Service Usage para aplicar substituições do consumidor a limites de cota específicos. Para mais informações, consulte Como criar uma modificação de cota do consumidor.

Melhoria na eficiência da carga de trabalho

Recomendamos as seguintes estratégias para ajudar a tornar suas cargas de trabalho eficientes no Google Cloud:

• Otimize o uso de recursos melhorando a eficiência do produto.
• Reduza a taxa de cobrança dos recursos.
• Controlar e limitar o uso e os gastos de recursos.

Ao selecionar técnicas de redução de custos e recursos do Google Cloud, considere o esforço necessário e a economia esperada, como mostrado no gráfico a seguir:

Veja a seguir um resumo das técnicas mostradas no gráfico anterior:

• É possível que as técnicas a seguir gerem uma grande economia com pouco esforço:
  • Descontos por uso contínuo
  • Escalonamento automático
  • Slots do BigQuery
• As seguintes técnicas podem aumentar muito a economia com um esforço moderado a alto:
  • Spot VMs
  • Como reformular como aplicativos sem servidor ou em contêiner
  • Mudança de plataforma para usar serviços gerenciados
• As técnicas a seguir potencialmente produzem economias moderadas com esforço moderado:
  • Tipos de máquina personalizados
  • Gerenciamento do ciclo de vida do Cloud Storage
  • Direitos de propriedade
  • Como recuperar recursos inativos

As técnicas explicadas nas seções a seguir podem ajudá-lo a melhorar a eficiência de suas cargas de trabalho.

Refatoração ou rearquitetura

É possível conseguir uma economia significativa de custos ao refatorar ou reestruturar sua carga de trabalho para usar os produtos do Google Cloud. Por exemplo, mudar para serviços sem servidor (como Cloud Storage, App Engine, BigQuery e Cloud Functions) compatível com escalonamento a zero pode ajudar a melhorar a eficiência. Para avaliar e comparar o custo desses produtos, use a calculadora de preços.

Direitos de propriedade

Essa técnica garante que o escalonamento da sua infraestrutura corresponda ao uso pretendido. Essa estratégia é relevante principalmente para soluções de infraestrutura como serviço (IaaS, na sigla em inglês) em que você paga pela infraestrutura subjacente. Por exemplo, você implantou 50 VMs, mas elas não estão totalmente usadas e determina que as cargas de trabalho possam ser executadas de maneira eficaz em menos (ou menores) VMs. Nesse caso, é possível remover ou redimensionar algumas VMs. O Google Cloud oferece recomendações de redimensionamento para ajudar você a detectar oportunidades para economizar dinheiro sem afetar o desempenho ao provisionar VMs menores. O redimensionamento requer menos esforço se realizado durante a fase de design do que a implantação de recursos na produção.

Escalonamento automático

Se os produtos que você usa forem compatíveis com o escalonamento automático dinâmico, pense em projetar as cargas de trabalho para aproveitar os benefícios de custo e desempenho. Por exemplo, para cargas de trabalho com uso intensivo de computação, é possível usar grupos de instâncias gerenciadas no Compute Engine ou colocar os aplicativos em contêineres e implantá-los em um cluster do Google Kubernetes Engine.

Recomendações do Active Assist

O Active Assist usa dados, inteligência e machine learning para reduzir a complexidade da nuvem e o esforço administrativo. O Active Assist facilita a otimização da segurança, do desempenho e dos custos da sua topologia em nuvem. Ele fornece recomendações inteligentes para otimizar seus custos e uso. Você pode aplicar essas recomendações para economizar imediatamente os custos e aumentar a eficiência.

Veja a seguir exemplos de recomendações fornecidas pelo Active Assist:

• Redimensionamento de recursos do Compute Engine: redimensione as instâncias de VM para otimizar custos e desempenho baseados em uso. Identifique e exclua ou faça backup de VMs inativas e discos permanentes para otimizar o custo de infraestrutura.
• Desconto por uso contínuo (CUD, na sigla em inglês): o Google Cloud analisa o uso histórico, encontra a quantidade de compromisso ideal para suas cargas de trabalho e fornece recomendações práticas e fáceis de entender para reduzir custos. Para mais informações, consulte Recomendador de desconto por compromisso de uso.
• Projetos autônomos: descobrir projetos autônomos na sua organização e removê-los ou recuperá-los. Para mais informações, consulte Revisor de projeto autônomo.

Para ver a lista completa, consulte Recomendadores.

A seguir

• Saiba mais sobre os conceitos do Cloud Billing
• Definir orçamentos e alertas de orçamento
• Otimize o custo de serviços de computação, armazenamento, bancos de dados, redes e operações:
  • Custo de otimização: computação, contêineres e sem servidor
  • Otimizar custo: armazenamento
  • Otimizar custo: bancos de dados e análises inteligentes
  • Otimizar custo: rede
  • Otimizar custo: operações na nuvem
• Explore as outras categorias do Framework da arquitetura do Google Cloud

Otimizar custos: computação, contêineres e sem servidor

Este documento no Framework da arquitetura do Google Cloud fornece recomendações para ajudar você a otimizar o custo de suas máquinas virtuais (VMs, na sigla em inglês), contêineres e recursos sem servidor no Google Cloud.

As orientações nesta seção são destinadas a arquitetos, desenvolvedores e administradores responsáveis por provisionar e gerenciar recursos de computação para cargas de trabalho na nuvem.

Os recursos de computação são a parte mais importante da sua infraestrutura em nuvem. Ao migrar suas cargas de trabalho para o Google Cloud, a primeira opção típica é o Compute Engine, que permite provisionar e gerenciar VMs com eficiência na nuvem. O Compute Engine oferece uma ampla variedade de tipos de máquinas e está disponível globalmente em todas as regiões do Google Cloud. Os tipos de máquina predefinidos e personalizados do Compute Engine permitem que você provisione VMs que oferecem capacidade de computação semelhante à sua infraestrutura local, acelerando o processo de migração. O Compute Engine oferece a vantagem de pagar somente pela infraestrutura utilizada e economia significativa à medida que usa mais recursos de computação com descontos por uso prolongado.

Além do Compute Engine, o Google Cloud oferece contêineres e serviços de computação sem servidor. A abordagem sem servidor pode ser mais econômica para novos serviços que nem sempre estão em execução (por exemplo, APIs, processamento de dados e processamento de eventos).

Além das recomendações gerais, este documento fornece orientações para ajudar a otimizar o custo dos recursos de computação ao usar os seguintes produtos:

• Compute Engine
• Google Kubernetes Engine (GKE)
• Cloud Run
• Cloud Functions
• App Engine

Recomendações gerais

As recomendações a seguir são aplicáveis a todos os serviços de computação, contêineres e sem servidor no Google Cloud discutidos nesta seção.

Rastrear o uso e o custo

Use as seguintes ferramentas e técnicas para monitorar o uso e o custo dos recursos:

• Veja e responda às recomendações de otimização de custos no Hub de recomendações.
• Receba notificações por e-mail sobre possíveis aumentos no uso de recursos e no custo configurando alertas de orçamento.
• Gerencie e responda a alertas de maneira programática usando os serviços do Pub/Sub e do Cloud Functions.

Controlar o provisionamento de recursos

Use as recomendações a seguir para controlar a quantidade de recursos provisionados na nuvem e o local onde eles são criados:

• Para garantir que o consumo e o custo dos recursos não excedam a previsão, use as cotas de recursos.
• Provisione recursos na região de menor custo que atenda aos requisitos de latência da carga de trabalho. Para controlar onde os recursos são provisionados, use a restrição da política da organização gcp.resourceLocations.

Receber descontos por uso contínuo

Os descontos por uso contínuo (CUDs, na sigla em inglês) são ideais para cargas de trabalho com necessidades previsíveis de recursos. Depois de migrar sua carga de trabalho para o Google Cloud, encontre o valor de referência para os recursos necessários e tenha descontos mais detalhados pelo uso contínuo. Por exemplo, compre um compromisso de um ou três anos e receba um desconto substancial nos preços de VM do Compute Engine.

Automatizar o rastreamento de custos usando rótulos

Defina e atribua rótulos de maneira consistente. Veja a seguir exemplos de como usar rótulos para automatizar o rastreamento de custos:

• Para VMs que apenas os desenvolvedores usam durante o horário comercial, atribua o rótulo env: development. Use o Cloud Scheduler para configurar uma Função do Cloud sem servidor para encerrar essas VMs após o horário comercial e reiniciá-las quando necessário.

• Para um aplicativo que tem vários serviços do Cloud Run e instâncias do Cloud Functions, atribua um rótulo consistente a todas as funções do Cloud Run e do Cloud Functions. Identifique as áreas de alto custo e tome medidas para reduzir custos.

Personalizar relatórios de faturamento

Configure os relatórios do Cloud Billing configurando os filtros necessários e agrupando os dados conforme necessário (por exemplo, por projetos, serviços ou rótulos).

Promova uma cultura de economia de custos

Treine seus desenvolvedores e operadores na infraestrutura em nuvem. Crie e promova programas de aprendizado usando aulas tradicionais ou on-line, grupos de discussão, avaliações de pares, programação de pares e jogos de economia de custos. Conforme mostrado na pesquisa DORA do Google, a cultura organizacional é um elemento fundamental para melhorar o desempenho, reduzir o retrabalho e o esgotamento, além de otimizar o custo. Ao conceder aos funcionários visibilidade sobre o custo dos recursos, você os ajuda a alinhar as prioridades e atividades com os objetivos e as restrições da empresa.

Compute Engine

Nesta seção, fornecemos orientação para ajudar a otimizar o custo dos recursos do Compute Engine. Além dessa orientação, recomendamos que você siga as recomendações gerais discutidas anteriormente.

Noções básicas sobre o modelo de faturamento

Para saber mais sobre as opções de faturamento do Compute Engine, consulte Preços.

Analisar o consumo de recursos

Para entender o consumo de recursos no Compute Engine, exporte os dados de uso para o BigQuery. Consulte o armazenamento de dados do BigQuery para analisar as tendências de uso da CPU virtual (vCPU) do seu projeto e determinar o número de vCPUs que podem ser recuperadas. Se você tiver definido limites para o número de núcleos por projeto, analise as tendências de uso para identificar anomalias e tomar ações corretivas.

Recuperar recursos inativos

Use as recomendações a seguir para identificar e recuperar VMs e discos não utilizados, como VMs para projetos de prova de conceito que não tiveram prioridade:

• Use o recomendador de VM inativa para identificar VMs inativas e discos permanentes com base nas métricas de uso.
• Antes de excluir recursos, avalie o possível impacto da ação e planeje recriar os recursos, se necessário.
• Antes de excluir uma VM, considere criar um snapshot. Ao excluir uma VM, os discos anexados serão excluídos, a menos que você tenha selecionado a opção Manter disco.
• Quando possível, interrompa as VMs em vez de excluí-las. Quando você interrompe uma VM, a instância é encerrada, mas os discos e endereços IP são mantidos até que você os desanexe ou exclua.

Ajustar a capacidade para corresponder à demanda

Programar o início e a interrupção automáticas das VMs Por exemplo, se uma VM for usada somente oito horas por dia durante cinco dias por semana (ou seja, 40 horas na semana), é possível reduzir os custos em 75% interrompendo a VM durante o período de 128 horas na semana em que a VM não é usada.

Faça o escalonamento automático da capacidade de computação com base na demanda usando grupos de instâncias gerenciadas. É possível fazer escalonamento automático da capacidade com base nos parâmetros importantes para sua empresa, por exemplo, uso da CPU ou capacidade de balanceamento de carga.

Escolher tipos de máquina apropriados

Dimensione as VMs para atender aos requisitos de computação da carga de trabalho usando o recomendador do tipo de máquina de VM.

Para cargas de trabalho com requisitos de recursos previsíveis, adapte o tipo de máquina às suas necessidades e economize dinheiro usando VMs personalizadas.

Para cargas de trabalho de processamento em lote que são tolerantes a falhas, use as VMs do Spot. A computação de alto desempenho (HPC), o Big Data, a transcodificação de mídia, os pipelines de integração contínua e entrega contínua (CI/CD) e os aplicativos da Web sem estado são exemplos de cargas de trabalho que podem ser implantadas em VMs do Spot. Para um exemplo de como a Descartes Labs reduziu os custos de análise usando Spot VMs (a versão mais antiga das Spot VMs) para processar imagens de satélite, consulte o estudo de caso Descartes Labs.

Avaliar opções de licenciamento

Ao migrar cargas de trabalho de terceiros para o Google Cloud, você pode reduzir os custos trazendo suas próprias licenças (BYOL, na sigla em inglês). Por exemplo, para implantar VMs do Microsoft Windows Server, em vez de usar uma imagem premium que gera mais custos para a licença de terceiros, é possível criar e usar uma imagem personalizada do BYOL do Windows. Você paga apenas pela infraestrutura de VM usada no Google Cloud. Essa estratégia ajuda você a manter o valor dos seus investimentos atuais em licenças de terceiros.

Se você decidir usar uma abordagem BYOL, recomendamos o seguinte:

• Provisione o número necessário de núcleos de CPU de computação, independentemente da memória, usando tipos de máquina personalizados e limite o custo de licenciamento de terceiros ao número de núcleos de CPU que que você precisa.
• Reduza o número de vCPUs por núcleo de 2 para 1 desativando multissegmentação simultânea (SMT, na sigla em inglês) e reduza os custos de licenciamento em 50%.

Se as cargas de trabalho de terceiros precisarem de hardware dedicado para atender aos requisitos de segurança ou conformidade, traga suas próprias licenças para nós de locatário individual.

Google Kubernetes Engine

Nesta seção, fornecemos orientação para ajudar a otimizar o custo dos recursos do GKE.

Além das recomendações a seguir, consulte as recomendações gerais discutidas anteriormente:

• Use o Autopilot do GKE para permitir que o GKE maximize a eficiência da infraestrutura do cluster. Você não precisa monitorar a integridade dos nós, lidar com o empacotamento ou calcular a capacidade necessária para suas cargas de trabalho.
• Ajuste o escalonamento automático do GKE usando o escalonador automático do pod horizontal (HPA), o escalonador automático do pod vertical (VPA). Autoescalador de cluster (CA) ou provisionamento automático de nós com base nos requisitos da carga de trabalho.
• Para cargas de trabalho em lote que não sejam sensíveis à latência de inicialização, use o perfil de escalonamento automático otimização-utilização para ajudar a melhorar a utilização do cluster.
• Usar provisionamento automático de nós para estender o escalonador automático de cluster do GKE e criar e excluir pools de nós com base nos especificações de pods pendentes sem provisionamento excessivo.
• Use pools de nós separados: um pool de nós estático para carga estática e pools de nós dinâmicos com grupos de escalonamento automático de clusters para carregamentos dinâmicos.
• Use VMs do Spot para os pools de nós do Kubernetes quando os pods forem tolerantes a falhas e puderem ser encerrados corretamente em menos de 25 segundos. Combinada com o escalonador automático de clusters do GKE, essa estratégia ajuda a garantir que o pool de nós com VMs de menor custo (neste caso, o pool de nós com Spot VMs) seja dimensionado primeiro.
• Escolha tipos de máquina econômicos (por exemplo: E2, N2D), T2D), que oferecem um desempenho entre 20 e 40% mais alto para pagar o preço.
• Use a medição de uso do GKE para analisar os perfis de uso dos clusters por namespaces e rótulos. Identifique a equipe ou o aplicativo que está gastando mais, o ambiente ou o componente que causou picos de uso ou custo e a equipe que está desperdiçando recursos.
• Use cotas de recursos em clusters multilocatários para evitar que qualquer locatário use mais recursos do cluster do que a parcela atribuída a ele.
• Programe a redução automática de ambientes de desenvolvimento e teste após o horário comercial.
• Siga as práticas recomendadas para executar aplicativos do Kubernetes otimizados para custo no GKE.

Cloud Run

Nesta seção, fornecemos orientação para ajudar a otimizar o custo dos recursos do Cloud Run.

Além das recomendações a seguir, consulte as recomendações gerais discutidas anteriormente:

• Ajuste a configuração de simultaneidade (padrão: 80) para reduzir o custo. O Cloud Run determina o número de solicitações a serem enviadas para uma instância com base no uso de CPU e da memória. Ao aumentar a simultaneidade de solicitações, você pode reduzir o número de instâncias necessárias.
• Defina um limite para o número de instâncias que podem ser implantadas.
• Faça uma estimativa do número de instâncias necessárias usando a métrica Tempo de instância faturável. Por exemplo, se a métrica mostra 100s/s, cerca de 100 instâncias foram programadas. Adicionar um buffer de 30% para preservar o desempenho ou seja, 130 instâncias para centenas de tráfegos.
• Para reduzir o impacto das inicializações a frio, configure um número mínimo de instâncias. Quando essas instâncias estão ociosas, elas são cobradas a um décimo do preço.
• Acompanhe o uso da CPU e ajuste os limites da CPU corretamente.
• Use o gerenciamento de tráfego para determinar uma configuração econômica.
• Considere usar o Cloud CDN ou o Firebase Hosting para exibir recursos estáticos.
• Para aplicativos do Cloud Run que processam solicitações globalmente, considere implantar o aplicativo em várias regiões, porque a transferência de dados entre continentes pode ser caro. Esse design é recomendado se você usa um balanceador de carga e a CDN.
• Reduza os tempos de inicialização das instâncias, porque o tempo de inicialização também é faturável.
• Compre descontos por compromisso de uso e economize até 17% no preço sob demanda por um compromisso de um ano.

Cloud Functions

Nesta seção, fornecemos orientação para ajudar a otimizar o custo dos recursos do Cloud Functions.

Além das recomendações a seguir, consulte as recomendações gerais discutidas anteriormente:

• Observe o tempo de execução das suas funções. Faça testes e comparativos de mercado para criar a menor função que ainda atenda ao limite de desempenho necessário.
• Se as cargas de trabalho do Cloud Functions forem executadas constantemente, use o GKE ou o Compute Engine para processar as cargas de trabalho. Contêineres ou VMs podem ser opções de baixo custo para cargas de trabalho sempre em execução.
• Limite o número de instâncias de função que podem coexistir.
• Comparar o desempenho do ambiente de execução às linguagens de programação do Cloud Functions com a carga de trabalho da função. Programas em linguagens compiladas têm inicializações a frio mais longas, mas mais rápidos. Programas em linguagens interpretadas são mais lentos, mas têm uma sobrecarga de inicialização a frio mais baixa. Funções curtas e simples executadas com frequência podem custar menos em uma linguagem interpretada.
• Exclua os arquivos temporários gravados no disco local, que é um sistema de arquivos na memória. Eles consomem memória alocada à função e, às vezes, permanecem entre as invocações. Se você não excluir esses arquivos, pode ocorrer um erro de falta de memória e acionar uma inicialização a frio, o que aumenta o tempo de execução e o custo.

App Engine

Nesta seção, fornecemos orientação para ajudar a otimizar o custo dos recursos do App Engine.

Além das recomendações a seguir, consulte as recomendações gerais discutidas anteriormente:

• Defina o máximo de instâncias com base no seu tráfego e na latência da solicitação. O App Engine geralmente escalona a capacidade com base no tráfego que os aplicativos recebem. É possível controlar o custo limitando o número de instâncias que o App Engine pode criar.
• Para limitar a memória ou a CPU disponível para o aplicativo, defina uma classe de instância. Para aplicativos que usam muita CPU, aloque mais CPU. Teste algumas configurações para determinar o tamanho ideal.
• Compare sua carga de trabalho do App Engine em várias linguagens de programação. Por exemplo, uma carga de trabalho implementada em uma linguagem pode precisar de menos instâncias e custo menor para concluir tarefas a tempo que a mesma carga de trabalho programada em outra linguagem.
• Otimize para menos inicializações a frio. Quando possível, reduza tarefas com uso intensivo da CPU ou de longa duração que ocorrem no escopo global. Tente dividir a tarefa em operações menores que possam ser "carregadas lentamente" no contexto de uma solicitação.
• Se você espera um tráfego em burst, configure um número mínimo de instâncias ociosas que estejam pré-aquecidas. Se você não estiver esperando tráfego, poderá configurar as instâncias ociosas mínimas como zero.
• Para equilibrar o desempenho e o custo, execute um teste A/B dividindo o tráfego entre duas versões, cada uma com uma configuração diferente. Monitore o desempenho e o custo de cada versão, ajuste-os conforme necessário e decida a configuração para a qual o tráfego será enviado.
• Configure a simultaneidade de solicitação e defina o número máximo de solicitações simultâneas maior que o padrão. Quanto mais solicitações cada instância puder processar simultaneamente, mais eficiente será o uso das instâncias existentes para veicular o tráfego.

A seguir

• Saiba como otimizar o custo dos recursos do GKE:
  • Execute aplicativos do Kubernetes otimizados para custo no GKE: práticas recomendadas
  • Práticas recomendadas para reduzir o provisionamento em excesso do GKE
  • Otimize o uso de recursos em um cluster multilocatário do GKE usando o provisionamento automático de nós
  • Reduzir custos diminuindo os clusters do GKE fora do horário de pico
  • Executar aplicativos da Web no GKE usando VMs Spot com custo otimizado
  • Estime seus custos do GKE no início do ciclo de desenvolvimento usando o GitLab
  • Série de vídeos: otimização de custos do GKE
  • Treinamento: otimizar custos para o GKE
• Saiba como otimizar o custo dos recursos do Cloud Run e do Cloud Functions:
  • Gerencie os custos e a confiabilidade em aplicativos totalmente gerenciados
  • Otimize para gerenciamento de custos a longo prazo em aplicativos totalmente gerenciados.
  • Maximize seus investimentos no Cloud Run com novos descontos por uso contínuo
• Otimize os custos de armazenamento, bancos de dados, redes e operações:
  • Otimizar custo: armazenamento
  • Otimizar custo: bancos de dados e análises inteligentes
  • Otimizar custo: rede
  • Otimizar custo: operações na nuvem
• Explore as outras categorias do Framework da arquitetura do Google Cloud

Otimizar custo: armazenamento

Este documento no Framework da arquitetura do Google Cloud fornece recomendações para ajudar você a otimizar o uso e o custo dos seus recursos do Cloud Storage, Persistent Disk e Filestore.

As orientações nesta seção são destinadas a arquitetos e administradores responsáveis por provisionar e gerenciar o armazenamento de cargas de trabalho na nuvem.

Observação: para mais orientações sobre como selecionar serviços de armazenamento apropriados para sua carga de trabalho, consulte Criar uma estratégia de armazenamento ideal para sua carga de trabalho na nuvem }.

Cloud Storage

Ao planejar o Cloud Storage para suas cargas de trabalho, considere seus requisitos de desempenho, retenção de dados e padrões de acesso.

Classe de armazenamento

Escolha uma classe de armazenamento que seja adequada aos requisitos de retenção de dados e frequência de acesso das cargas de trabalho, conforme recomendado na tabela a seguir:

Requisito de armazenamento	Recomendação
Dados acessados com frequência (análises de alta capacidade ou data lakes, sites, streaming de vídeos e apps para dispositivos móveis).	Standard storage
Armazenamento de baixo custo para dados acessados com pouca frequência que podem ser armazenados por pelo menos 30 dias (por exemplo, backups e conteúdo multimídia extenso).	Nearline Storage
Dados acessados com pouca frequência que podem ser armazenados por pelo menos 90 dias (por exemplo, réplicas de dados para recuperação de desastres).	Coldline Storage
Armazenamento de menor custo para dados acessados com pouca frequência que podem ser armazenados por pelo menos 365 dias (por exemplo, arquivos legais e regulamentares).	Archive Storage

Observação: as classes de armazenamento Nearline, Coldline e Archive custam menos do que o armazenamento padrão, mas elas geram cobranças mais altas de recuperação de dados e uma penalidade de exclusão antecipada.

Local

Selecione o local dos seus buckets com base nos seus requisitos de desempenho, disponibilidade e redundância de dados.

• As regiões são recomendadas quando a região está próxima dos seus usuários finais. É possível selecionar uma região específica e receber a redundância garantida na região. As regiões oferecem armazenamento rápido, redundante e acessível para os conjuntos de dados que os usuários de uma determinada área geográfica acessam com frequência.
• As multirregiões oferecem alta disponibilidade para usuários distribuídos. No entanto, o custo de armazenamento é maior que o das regiões. Os buckets multirregionais são recomendados para casos de uso de veiculação de conteúdo e para cargas de trabalho de análise simples.
• As regiões duplas oferecem alta disponibilidade e redundância de dados. O Google recomenda buckets birregionais para cargas de trabalho de análise de alto desempenho e para casos de uso que exigem buckets ativos-ativos reais com computação e armazenamento colocados em vários locais. Com o recurso de região dupla, você escolhe onde seus dados são armazenados, o que ajuda você a atender aos requisitos de conformidade. Por exemplo, é possível usar um bucket de região dupla para atender a requisitos específicos do setor relacionados à distância física entre cópias de seus dados na nuvem.

Políticas do ciclo de vida

Otimize o custo de armazenamento de objetos no Cloud Storage definindo políticas de ciclo de vida. Essas políticas ajudam a economizar dinheiro fazendo downgrade automaticamente da classe de armazenamento de objetos específicos ou excluindo objetos com base nas condições definidas.

Configure políticas de ciclo de vida com base na frequência com que os objetos são acessados e por quanto tempo você precisa retê-los. Veja a seguir exemplos de políticas de ciclo de vida:

• Política de downgrade: você espera que um conjunto de dados seja acessado com frequência, mas apenas por cerca de três meses. Para otimizar o custo de armazenamento desse conjunto de dados, use o armazenamento padrão e configure uma política de ciclo de vida para fazer downgrade de objetos com mais de 90 dias para o armazenamento Coldline.

• Política de exclusão: um conjunto de dados precisa ser retido por 365 dias para atender a determinados requisitos legais e pode ser excluído após esse período. Configure uma política para excluir qualquer objeto com mais de 365 dias.

  Para garantir que os dados que precisam ser retidos por um período específico (para conformidade legal ou regulatória) não sejam excluídos antes dessa data ou hora, configure bloqueios da política de retenção }

Observação: as classes de armazenamento de longo prazo (Nearline, Coldline e Archive) geram cobranças mais altas de recuperação de dados e uma penalidade de exclusão antecipada em comparação com o armazenamento padrão. Se os dados armazenados em uma classe de armazenamento de longo prazo precisarem ser acessados com frequência, será possível copiar os dados para um bucket padrão do Cloud Storage.

Responsabilidade

Para gerar responsabilidade por cobranças operacionais, cobranças de rede e custos de recuperação de dados, use a configuração Pagamentos do solicitante, quando apropriado. Com essa configuração, os custos são cobrados para o departamento ou a equipe que usa os dados, e não do proprietário.

Defina e atribua rótulos de rastreamento de custos de maneira consistente para todos os buckets e objetos. Automatize a rotulagem quando possível.

Redundância

Use as técnicas a seguir para manter a redundância de armazenamento necessária sem a duplicação de dados:

• Para manter a resiliência de dados com uma única fonte de verdade, use um bucket birregional ou multirregional em vez de cópias redundantes de dados em buckets diferentes. Os buckets birregionais e multirregionais fornecem redundância entre regiões. Os dados são replicados de maneira assíncrona em dois ou mais locais e protegidos contra interrupções regionais.
• Se você ativar o controle de versões de objetos, considere definir políticas de ciclo de vida para remover a versão mais antiga de um objeto conforme as versões mais recentes se tornam }não atual. Cada versão não atual de um objeto custa o mesmo que a versão ativa do objeto.
• Desative as políticas de controle de versões de objetos quando elas não forem mais necessárias.
• Revise as políticas de retenção de snapshots e backup periodicamente e ajuste-as para evitar backups desnecessários e retenção de dados.

Persistent Disk

Cada instância de VM implantada no Compute Engine tem um disco de inicialização e, opcionalmente, um ou mais discos de dados. Cada disco gera custos dependendo do tamanho provisionado, da região e do tipo de disco. Todos os snapshots capturados dos seus discos geram custos com base no tamanho deles.

Use as seguintes recomendações de projeto e operacionais para ajudar a otimizar o custo dos discos permanentes:

• Não aloque muito espaço em disco. Não é possível reduzir a capacidade do disco após o provisionamento. Comece com um disco pequeno e aumente o tamanho quando necessário. Os discos permanentes são cobrados pela capacidade provisionada, e não pelos dados armazenados nos discos.

• Escolha um tipo de disco que corresponda às características de desempenho da sua carga de trabalho. A SSD fornece altas IOPS e capacidade, mas custa mais do que os discos permanentes padrão.

• Use discos permanentes regionais somente ao proteger dados contra interrupções zonais. Discos permanentes regionais são replicados para outra zona na região. Portanto, você gera o dobro de custos dos discos zonais equivalentes.

• Acompanhe o uso dos discos permanentes usando o Cloud Monitoring e configure alertas para discos com pouco uso.

• Exclua sites que não sejam mais necessários.

• Para discos com dados que possam ser necessários no futuro, arquive os dados no Cloud Storage de baixo custo e exclua-os.

• Procure e responda às recomendações no Hub de recomendações.

Considere também o uso de hiperdiscos para armazenamento de alto desempenho e discos temporários (SSDs locais) para armazenamento temporário.

Os snapshots de disco são incrementais por padrão e compactados automaticamente. Considere as seguintes recomendações para otimizar o custo dos snapshots de disco:

• Quando possível, organize seus dados em discos permanentes separados. Você pode optar por fazer backup dos discos seletivamente e reduzir o custo de snapshots de discos.
• Ao criar um snapshot, selecione um local com base nos requisitos de disponibilidade e nos custos de rede associados.
• Se você pretende usar um snapshot de disco de inicialização para criar várias VMs, crie uma imagem do snapshot e use a imagem para criar suas VMs. Essa abordagem ajuda a evitar cobranças de rede por dados transmitidos entre o local do snapshot e o local onde ele é restaurado.
• Configure uma política de retenção para minimizar os custos de armazenamento a longo prazo dos snapshots de disco.
• Exclua os snapshots de disco que você não precisa mais. Cada snapshot em uma cadeia pode depender de dados armazenados em um snapshot anterior. Portanto, excluir um snapshot não necessariamente exclui todos os dados nele. Para excluir completamente os dados dos snapshots, exclua todos os snapshots da cadeia.

Filestore

O custo de uma instância do Filestore depende do nível de serviço, da capacidade provisionada e da região em que a instância é provisionada. Veja as recomendações de projeto e operacionais para otimizar o custo das instâncias do Filestore:

• Selecione um nível de serviço e um tipo de armazenamento (HDD ou SSD) apropriados para suas necessidades de armazenamento.
• Não aloque capacidade em excesso. Comece com um tamanho pequeno e aumente mais tarde, quando necessário. O faturamento do Filestore é baseado na capacidade provisionada, e não nos dados armazenados.
• Sempre que possível, organize seus dados em instâncias separadas do Filestore. Você pode optar por fazer backup das instâncias seletivamente e reduzir o custo de backups do Filestore.
• Ao escolher a região e a zona, crie instâncias na mesma zona dos clientes. A cobrança será feita pelo tráfego de transferência de dados da zona da instância do Filestore.
• Ao decidir a região onde os backups do Filestore serão armazenados, considere as cobranças de transferência de dados para armazenar backups em uma região diferente da instância de origem.
• Acompanhe o uso das instâncias do Filestore usando o Cloud Monitoring e configure alertas para instâncias com pouco uso.
• Reduza a capacidade alocada para instâncias do Filestore que têm baixo uso. É possível reduzir a capacidade das instâncias, exceto o nível Básico.

A seguir

• Analisar as práticas recomendadas para a otimização de custos do Cloud Storage (blog)
• Otimize o custo de serviços de computação, bancos de dados, redes e operações:
  • Custo de otimização: computação, contêineres e sem servidor
  • Otimizar custo: bancos de dados e análises inteligentes
  • Otimizar custo: rede
  • Otimizar custo: operações na nuvem
• Explore as outras categorias do Framework da arquitetura do Google Cloud

Otimizar custo: bancos de dados e análises inteligentes

Este documento no Framework da arquitetura do Google Cloud fornece recomendações para ajudar você a otimizar o custo de seus bancos de dados e cargas de trabalho de análise no Google Cloud.

As orientações nesta seção são destinadas a arquitetos, desenvolvedores e administradores responsáveis por provisionar e gerenciar bancos de dados e cargas de trabalho de análise na nuvem.

Esta seção inclui recomendações de otimização de custos para os seguintes produtos:

• Cloud SQL
• Spanner
• Bigtable
• BigQuery
• Dataflow
• Dataproc

Cloud SQL

O Cloud SQL é um banco de dados relacional totalmente gerenciado para MySQL, PostgreSQL e SQL Server.

Monitorar o uso

Revise as métricas no painel de monitoramento e valide se a implantação atende aos requisitos da carga de trabalho.

Otimizar recursos

Veja a seguir recomendações para otimizar seus recursos do Cloud SQL:

• Crie uma estratégia de alta disponibilidade e recuperação de desastres que se alinhe com o objetivo de tempo de recuperação (RTO, na sigla em inglês) e o objetivo de ponto de recuperação (RPO, na sigla em inglês). Dependendo da sua carga de trabalho, recomendamos o seguinte:
  • Para cargas de trabalho que precisam de um RTO e RPO curtos, use a configuração de alta disponibilidade e as réplicas para failover regional.
  • Para cargas de trabalho que resistam a um RTO e RPO mais longos, use backups automatizados e sob demanda, que podem demorar um pouco mais para serem restaurados após uma falha.
• Provisione o banco de dados com a capacidade mínima de armazenamento necessária.
• Para escalonar automaticamente a capacidade de armazenamento conforme seus dados aumentam, ative o recurso de aumento de armazenamento automático.
• Escolha um tipo de armazenamento, unidades de estado sólido (SSD, na sigla em inglês) ou unidades de disco rígido (HDD, na sigla em inglês), adequado para seu caso de uso. O SSD é a escolha mais eficiente e econômica para a maioria dos casos de uso. O HDD é apropriado para grandes conjuntos de dados (> 10 TB) que não são sensíveis à latência ou são acessados com pouca frequência.

Otimizar taxas

Considere comprar descontos por uso contínuo para cargas de trabalho com necessidades previsíveis de recursos. Você pode economizar 25% dos preços sob demanda para um compromisso de um ano e 52% para um de três anos.

Spanner

O Spanner é um banco de dados nativo da nuvem, em escala ilimitada e com consistência forte, que oferece até 99,999% de disponibilidade.

Monitorar o uso

Veja a seguir recomendações para ajudar a rastrear o uso dos recursos do Spanner:

• Monitore a implantação e configure a contagem de nós com base nas recomendações da CPU.
• Defina alertas nas suas implantações para otimizar os recursos de armazenamento. Para determinar a configuração apropriada, consulte os limites por nó recomendados.

Otimizar recursos

Veja a seguir recomendações para otimizar seus recursos do Spanner:

• Execute cargas de trabalho menores no Spanner a um custo muito menor ao provisionar recursos com unidades de processamento (PUs,na sigla em inglês) em comparação com nós. um nó do Spanner é igual a 1.000 PUs.
• Melhore o desempenho da execução de consultas usando o otimizador de consultas (em inglês).
• Crie instruções SQL usando práticas recomendadas para criar planos de execução eficientes.
• Gerencie o uso e o desempenho das implantações do Spanner usando a ferramenta escalonador automático. A ferramenta monitora instâncias, adiciona ou remove nós automaticamente e ajuda a garantir que as instâncias permaneçam dentro dos limites recomendados de CPU e armazenamento.
• Proteger contra exclusão acidental ou gravações usando a recuperação pontual (PITR, na sigla em inglês) Bancos de dados com períodos de armazenamento de versão mais longos, especialmente aqueles que substituem os dados com frequência, usam mais recursos do sistema e precisam de mais nós.
• Analise sua estratégia de backup e escolha uma das seguintes opções:
  • Backup e restauração
  • Exportar e importar

Otimizar taxas

Ao decidir o local dos nós do Spanner, considere as diferenças de custo entre as regiões do Google Cloud. Por exemplo, um nó implantado na região us-central1 custa consideravelmente menos por hora do que um nó na região southamerica-east1.

Bigtable

O Bigtable é um armazenamento NoSQL de colunas largas e nativo da nuvem para cargas de trabalho em grande escala e de baixa latência.

Monitorar o uso

Veja a seguir recomendações para ajudar a rastrear o uso dos recursos do Bigtable:

• Analise as métricas de uso para identificar oportunidades de otimização de recursos.
• Identifique pontos de acesso e teclas de atalho no cluster do Bigtable usando a ferramenta de diagnóstico Key Visualizer.

Otimizar recursos

Veja a seguir recomendações para otimizar seus recursos do Bigtable:

• Para ajudar a garantir o uso da CPU e do disco que ofereça um equilíbrio entre latência e capacidade de armazenamento, avalie e ajuste a contagem de nós e o tamanho do cluster do Bigtable.
• Para manter o desempenho com o menor custo possível, escalone programaticamente o cluster do Bigtable para ajustar automaticamente a contagem de nós.

• Avalie o tipo de armazenamento (HDD ou SSD) mais econômico para seu caso de uso, com base nas seguintes considerações:

  • O armazenamento HDD custa menos que o SSD, mas apresenta desempenho inferior.
  • O armazenamento SSD custa mais do que o HDD, mas oferece desempenho mais rápido e previsível.

  As economias de custo com HDD são mínimas em relação ao custo dos nós no cluster do Bigtable, a menos que você armazene grandes quantidades de dados. Às vezes, o armazenamento HDD é apropriado para conjuntos de dados grandes (mais de 10 TB) não sensíveis à latência ou pouco acessados.

• Remover dados expirados e obsoletos usando a coleta de lixo.

• Para evitar pontos de acesso, aplique as práticas recomendadas para o design da chave de linha.

• Crie um plano de backup econômico que se alinhe ao seu RPO.

• Para diminuir o uso do cluster e reduzir a contagem de nós, adicione um cache de capacidade para consultas armazenáveis em cache usando o Memorystore.

Mais informações

• Blog: Uma introdução à otimização de custos do Bigtable.
• Blog: Práticas recomendadas para desempenho do Bigtable e otimização de custos

O BigQuery

O BigQuery é um data warehouse multicloud sem servidor, altamente escalonável e econômico projetado para a agilidade dos negócios.

Monitorar o uso

Veja a seguir recomendações para ajudar a rastrear o uso dos recursos do BigQuery:

• Visualize os custos do BigQuery segmentados por projetos e usuários. Identifique as consultas mais caras e otimize-as.
• Analise a utilização de slots em projetos, jobs e reservas usando tabelas de metadados INFORMATION_SCHEMA.

Otimizar recursos

Veja a seguir recomendações para otimizar seus recursos do BigQuery:

• Defina expirações de dados no nível do conjunto de dados, da tabela ou da partição com base na sua estratégia de conformidade.
• Limite os custos de consulta restringindo o número de bytes faturados por consulta. Para evitar erros humanos acidentais, ative o controle de custo no nível do usuário e do projeto.
• Consulte apenas os dados necessários. Evite verificações de consulta completas. Para explorar e entender a semântica de dados, use as opções gratuitas de visualização de dados.
• Para reduzir o custo de processamento e melhorar o desempenho, particione e cluster suas tabelas quando possível.
• Filtre sua consulta o quanto antes.
• Ao processar dados de várias fontes (como Bigtable, Cloud Storage, Google Drive e Cloud SQL), evite duplicar dados usando um modelo de dados de acesso federado e consulta de dados diretamente das origens.
• Aproveite o backup do BigQuery em vez de duplicar dados. Consulte Cenários de recuperação de desastres para dados.

Otimizar taxas

Veja a seguir recomendações para ajudar a reduzir as taxas de faturamento dos recursos do BigQuery:

• Avalie como você edita os dados e aproveite os preços de armazenamento de longo prazo mais baixos.
• Analise as diferenças entre os preços de taxa fixa e sob demanda, e escolha uma opção que seja adequada aos seus requisitos.
• Avalie se é possível usar o carregamento em lote em vez de inserções de streaming para fluxos de trabalho de dados. Use inserções de streaming se os dados carregados no BigQuery são consumidos imediatamente.
• Para aumentar o desempenho e reduzir o custo da recuperação de dados, use os resultados da consulta em cache.

Mais informações

• Como controlar custos do BigQuery
• Práticas recomendadas de otimização de custos para o BigQuery.
• Noções básicas sobre os princípios de otimização de custos (PDF)

Dataflow

O Dataflow é um serviço rápido e econômico sem servidor para processamento unificado de dados de stream e lote.

Monitorar o uso

Veja a seguir recomendações para ajudar a rastrear o uso dos recursos do Dataflow:

• Prever o custo de jobs do Dataflow executando pequenos experimentos de carga, encontrando o desempenho ideal do job e extrapolando o fator de capacidade.
• Aumente a visibilidade da capacidade e do uso da CPU usando painéis de observabilidade.
• Observe as métricas de desempenho, da execução e do pipeline relacionadas à integridade usando a interface de monitoramento do Dataflow.

Otimizar recursos

Veja a seguir recomendações para otimizar seus recursos do Dataflow:

• Pense no Dataflow Prime para processar Big Data de maneira eficiente.
• Reduza os custos de processamento em lote usando o recurso de programação flexível (FlexRS, na sigla em inglês) para pipelines em lote com escalonamento automático. O FlexRS usa a programação avançada, o Shuffle do Dataflow e uma combinação de VMs preemptivas e regulares para reduzir o custo de pipelines em lote.
• Melhore o desempenho usando o serviço de embaralhamento na memória em vez do Persistent Disk e dos nós de trabalho.
• Para ter um escalonamento automático mais responsivo e reduzir o consumo de recursos, use o Streaming Engine, que move a execução do pipeline das VMs de worker para o back-end do serviço do Dataflow.
• Se o pipeline não precisar de acesso à Internet e a outras redes do Google Cloud, desative os endereços IP públicos. A desativação do acesso à Internet ajuda a reduzir os custos de rede e melhorar a segurança do pipeline.
• Siga as práticas recomendadas para pipelines eficientes com o Dataflow.

Dataproc

O Dataproc é um serviço gerenciado do Apache Spark e do Apache Hadoop para processamento em lote, consulta, streaming e machine learning.

Veja a seguir recomendações para otimizar o custo dos recursos do Dataproc:

• Escolha os tipos de máquina apropriados para sua carga de trabalho.
• Faça o escalonamento automático para corresponder à demanda usando clusters de escalonamento automático e pague apenas pelos recursos necessários.
• Se um cluster puder ser excluído quando o job for concluído, considere provisionar um cluster temporário usando um modelo de fluxo de trabalho do cluster gerenciado.
• Para evitar cobranças de um cluster inativo, use a exclusão programada, que permite excluir um cluster após um período de inatividade especificado, em um momento determinado ou após um período especificado. de dados.
• Siga as práticas recomendadas para criar clusters de longa duração no Dataproc.
• Compre descontos por uso contínuo para cargas de trabalho sempre ativadas.

A seguir

• Otimize o custo de serviços de computação, armazenamento, rede e operações:
  • Custo de otimização: computação, contêineres e sem servidor
  • Otimizar custo: armazenamento
  • Otimizar custo: rede
  • Otimizar custo: operações na nuvem
• Explore as outras categorias do Framework da arquitetura do Google Cloud

Otimizar custo: rede

Este documento no Framework da arquitetura do Google Cloud fornece recomendações para ajudar você a otimizar o custo dos seus recursos de rede no Google Cloud.

As orientações nesta seção são destinadas a arquitetos e administradores responsáveis por provisionar e gerenciar redes para cargas de trabalho na nuvem.

Considerações sobre o design

Uma diferença fundamental entre redes locais e em nuvem é o modelo de custo dinâmico baseado em uso na nuvem em comparação com o custo fixo de redes em data centers tradicionais.

Ao planejar redes em nuvem, é essencial entender o modelo de preços, que é baseado na direção do tráfego da seguinte maneira:

• Não há cobranças pelo tráfego de entrada no Google Cloud. Recursos que processam o tráfego de entrada, como o Cloud Load Balancing, geram custos.
• Para o tráfego de transferência de dados, que inclui o tráfego entre máquinas virtuais (VMs) no Google Cloud e o tráfego do Google Cloud para a Internet e para hosts locais, os preços são baseados nos seguintes fatores:
  • Se o tráfego usa um endereço IP interno ou externo
  • Se o tráfego cruza os limites de zona ou região
  • Se o tráfego sai do Google Cloud
  • A distância que o tráfego percorre antes de sair do Google Cloud

Quando duas VMs ou recursos de nuvem no Google Cloud se comunicam, o tráfego em cada direção é designado como transferência de dados de saída na origem e transferência de dados de entrada no destino, e o preço é cobrado de acordo.

Considere os seguintes fatores ao criar redes de nuvem econômicas:

• Geolocalização
• Layout de rede
• Opções de conectividade
• Níveis de serviço de rede
• Logging

Esses fatores são discutidos em mais detalhes nas seções a seguir.

Geolocalização

Os custos de rede podem variar dependendo da região do Google Cloud em que seus recursos são provisionados. Para analisar a largura de banda da rede entre as regiões, use os registros de fluxo de VPC e o Network Intelligence Center. O tráfego que flui entre regiões do Google Cloud pode variar dependendo do local das regiões, mesmo que o tráfego não passe pela Internet.

Além da região do Google Cloud, considere as zonas em que seus recursos são implantados. Dependendo dos requisitos de disponibilidade, é possível projetar seus aplicativos para se comunicarem sem custos em uma zona por meio de endereços IP internos. Ao considerar uma arquitetura de zona única, pondere possíveis economias no custo de rede com o impacto na disponibilidade.

Layout de rede

Analise o layout da rede, o fluxo do tráfego entre aplicativos e usuários e a largura de banda consumida por cada app ou usuário. A ferramenta Topologia de rede fornece uma visibilidade abrangente da implantação global do Google Cloud e da interação com a Internet pública, incluindo uma visão geral da topologia, e as métricas de desempenho de rede associadas. É possível identificar implantações ineficientes e tomar as medidas necessárias para otimizar os custos de transferência de dados regionais e intercontinentais.

Opções de conectividade

Quando você precisar enviar com frequência um grande volume de dados (TBs ou PBs) de ambientes locais para o Google Cloud, use a Interconexão dedicada ou Interconexão por parceiro. Uma conexão dedicada pode ser mais barata em comparação com os custos associados à transferência da Internet pública ou ao uso de uma VPN.

Use o Acesso privado do Google quando possível para reduzir custos e melhorar sua postura de segurança.

Níveis de serviço de rede

A infraestrutura de rede premium do Google (nível Premium) é usada por padrão em todos os serviços. Para recursos que não precisam do alto desempenho e da baixa latência que o nível Premium oferece, é possível escolher o nível Standard, que custa menos.

Ao escolher um nível de serviço, considere as diferenças entre os níveis e as limitações do nível Standard. Ajuste a rede de acordo com as necessidades do seu aplicativo e reduza potencialmente o custo de rede para serviços que toleram mais latência e não exigem um SLA.

Geração de registros

Com os registros de fluxos da VPC, a geração de registros de regras de firewall e os registros do Cloud NAT, você pode analisar registros de rede e identificar oportunidades para reduzir os custos.

Para registros de fluxo de VPC e Cloud Load Balancing, também é possível ativar amostragem , que podem reduzir o volume de registros gravados no banco de dados de dados. É possível variar a taxa de amostragem de 1,0 (todas as entradas de registro são retidas) para 0,0 (nenhum registro é mantido). Para solução de problemas ou casos de uso personalizados, é possível optar por sempre coletar telemetria para uma rede ou sub-rede VPC específica ou monitorar uma instância de VM ou interface virtual específica.

Recomendações de design

Para otimizar o tráfego de rede, recomendamos o seguinte:

• Projete suas soluções para aproximar os aplicativos da sua base de usuários. Use o Cloud CDN para reduzir o volume de tráfego e a latência, e aproveite os preços mais baixos da CDN para exibir conteúdo que você espera que muitos usuários acessem com frequência.
• Evite sincronizar os dados globalmente entre as regiões distantes do usuário final ou que podem gerar altos custos de rede. Se um aplicativo for usado somente dentro de uma região, evite o processamento de dados entre regiões.
• Garanta que a comunicação entre as VMs dentro de uma zona seja roteada por meio dos endereços IP internos deles, e não externamente.
• Reduza o custo de transferência de dados e a latência do cliente compactando a saída de dados.
• Analise padrões de gastos e identifique oportunidades para controlar os custos observando os fluxos de tráfego de entrada e saída para projetos essenciais usando os registros de fluxo de VPC.
• Ao projetar suas redes na nuvem, considere a diferença entre a alta disponibilidade que uma rede distribuída oferece e a economia de custos da centralização do tráfego em uma única zona ou região.

Para otimizar o preço pago pelos serviços de rede, recomendamos o seguinte:

• Se o local do servidor não for uma restrição, avalie o custo em regiões diferentes e selecione a região mais econômica. Para o tráfego de saída geral, como o conteúdo exibido por um grupo de servidores da Web, os preços podem variar dependendo da região em que os servidores são provisionados.
• Para reduzir o custo da movimentação frequente de grandes volumes de dados para a nuvem, use uma conexão direta entre as redes locais e do Google Cloud. Use a Interconexão dedicada ou a Interconexão por parceiro.
• Escolha um nível de serviço apropriado para cada ambiente, ou seja, o nível Standard para ambientes de desenvolvimento e teste e o nível Premium para produção.

A seguir

• Revisar as informações de preços de rede
• Analisar as práticas recomendadas para otimização de custos de rede
• Otimize o custo de serviços de computação, armazenamento, bancos de dados e operações:
  • Custo de otimização: computação, contêineres e sem servidor
  • Otimizar custo: armazenamento
  • Custo do Optimize: bancos de dados e análises inteligentes
  • Otimizar o custo: operações na nuvem
• Explore as outras categorias do Framework da arquitetura do Google Cloud

Otimizar custo: operações na nuvem

Este documento no Framework da arquitetura do Google Cloud fornece recomendações para ajudar você a otimizar o custo de monitoramento e gerenciamento de seus recursos no Google Cloud.

As orientações nesta seção são destinadas aos usuários da nuvem responsáveis por monitorar e controlar o uso e o custo dos recursos da organização na nuvem.

O Google Cloud Observability é uma coleção de serviços gerenciados que pode ser usado para monitorar, resolver problemas e melhorar o desempenho das cargas de trabalho no Google Cloud. Esses serviços incluem o Cloud Monitoring, o Cloud Logging, o Error Reporting, o Cloud Trace e o Cloud Profiler. Um dos benefícios dos serviços gerenciados no Google Cloud é que eles são baseados no uso. Você paga apenas pelo que usa e por volume de dados, com cotas mensais de uso de dados gratuitas e acesso ilimitado às métricas e registros de auditoria do Google Cloud.

Cloud Logging

Veja a seguir recomendações para ajudar a otimizar o custo das operações do Logging:

• Filtre os relatórios de faturamento para mostrar os custos do Logging.
• Reduza o volume de registros ingeridos e armazenados excluindo ou filtrando entradas de registro desnecessárias.
• Verifique se os filtros de exclusão são adequados por monitoramento das métricas billing/bytes_ingested e billing/monthly_bytes_ingested no Console do Google Cloud.
• Descarregar e exportar registros para armazenamento de baixo custo.
• Ao fazer streaming de registros de aplicativos de terceiros, reduza os volumes de registros usando o agente de geração de registros somente em instâncias de produção ou configurando-o para enviar menos dados.

Cloud Monitoring

Veja a seguir recomendações para ajudar a otimizar o custo das operações do Monitoring:

• Otimize o uso de rótulos e métricas limitando o número de rótulos. Evite rótulos com alta cardinalidade. Por exemplo, se você usar um endereço IP como rótulo, cada endereço IP terá uma série de rótulos de um item, resultando em vários rótulos quando você tem muitas VMs.
• Reduza o volume de métricas detalhadas para aplicativos que não requer essas métricas ou remova o agente de monitoramento, especialmente para ambientes não essenciais.
• Minimize o volume de ingestão reduzindo o número de métricas personalizadas que seu aplicativo envia;

Cloud Trace

Veja a seguir recomendações para ajudar a otimizar o custo das operações do Trace:

• Se você usar o Trace como um destino de exportação para seus traces do OpenCensus, reduza o volume de traces ingeridos usando o recurso de amostragem no OpenCensus.
• Limite o uso do Trace e controle os custos usando cotas. É possível aplicar cotas de período com a página de cota específica da API no Console do Google Cloud.

A seguir

• Otimize os custos para o Google Cloud Observability
• Vídeo: Gerenciar os custos do Google Cloud Observability
• Otimize o custo de serviços de computação, armazenamento, bancos de dados e rede:
  • Otimizar custos: computação, contêineres e sem servidor
  • Otimizar custo: armazenamento
  • Otimizar custo: bancos de dados e análises inteligentes
  • Otimizar o custo: rede
• Explore as outras categorias do Framework da arquitetura do Google Cloud

Estrutura de arquitetura do Google Cloud: otimização de desempenho

Essa categoria no framework de arquitetura do Google Cloud descreve o processo de otimização de desempenho e as práticas recomendadas para otimizar o desempenho de cargas de trabalho no Google Cloud.

As informações deste documento são destinadas a arquitetos, desenvolvedores e administradores que planejam, projetam, implantam e gerenciam cargas de trabalho no Google Cloud.

Otimizar o desempenho das cargas de trabalho na nuvem pode ajudar sua organização a operar de maneira eficiente, melhorar a satisfação do cliente, aumentar a receita e reduzir custos. Por exemplo, quando o tempo de processamento de back-end de um aplicativo diminui, os tempos de resposta ficam mais rápidos para os usuários, o que pode aumentar a retenção de usuários e a receita.

Pode haver uma compensação entre desempenho e custo. Mas, em alguns casos, otimizar o desempenho pode ajudar você a reduzir custos. ​​Por exemplo, o escalonamento automático ajuda a fornecer um desempenho previsível quando a carga aumenta, garantindo que os recursos não sejam sobrecarregados. Ele também ajuda a reduzir custos durante períodos de carga baixa removendo os recursos não utilizados.

Nessa categoria do framework de arquitetura, você vai aprender a fazer o seguinte:

• Implementar o processo de otimização de desempenho.
• Monitorar e analisar o desempenho.
• Otimizar o desempenho da computação.
• Otimizar o desempenho do armazenamento.
• Otimizar o desempenho da rede.
• Otimizar o desempenho do banco de dados.
• Otimizar o desempenho da análise.

Processo de otimização de desempenho

Neste documento, no framework de arquitetura do Google Cloud, fornecemos uma visão geral do processo de otimização de desempenho.

A otimização do desempenho é um processo contínuo, e não uma atividade única. O diagrama a seguir mostra os estágios no processo de otimização de desempenho:

Confira a seguir uma visão geral das etapas do processo de otimização de desempenho:

Definir os requisitos de desempenho

Antes de começar a projetar e desenvolver os aplicativos que você quer implantar ou migrar para a nuvem, determine os requisitos de desempenho. Defina os requisitos da maneira mais granular possível para cada camada de pilha de aplicativos: balanceamento de carga de front-end, servidores da Web ou de aplicativos, banco de dados e armazenamento. Por exemplo, para a camada de armazenamento da pilha, defina a capacidade de processamento e as operações de E/S por segundo (IOPS) que seus aplicativos precisam.

Projetar e implantar aplicativos

Projete seus aplicativos usando padrões de design elásticos e escalonáveis que podem ajudar a atender aos requisitos de desempenho. Considere as seguintes diretrizes para projetar aplicativos elásticos e escalonáveis:

• Arquitete as cargas de trabalho para otimizar o posicionamento do conteúdo.
• Isole o tráfego de leitura e gravação.
• Isole o tráfego estático e dinâmico.
• Implemente o armazenamento de conteúdo em cache. Use caches de dados para camadas internas.
• Use serviços gerenciados e arquiteturas sem servidor.

O Google Cloud oferece ferramentas de código aberto que podem ser usadas para comparar o desempenho dos serviços do Google Cloud com outras plataformas de nuvem.

Monitorar e analisar o desempenho

Depois de implantar os aplicativos, monitore continuamente o desempenho usando registros e alertas, analise os dados e identifique problemas de desempenho. À medida que seus aplicativos ficarem mais complexos e evoluírem, reavalie seus requisitos de desempenho. Talvez seja necessário reformular algumas partes dos aplicativos para manter ou melhorar o desempenho.

Otimizar o desempenho

Com base no desempenho dos seus aplicativos e mudanças nos requisitos, configure os recursos da nuvem para atender aos requisitos de desempenho atuais. Por exemplo, redimensione os recursos ou configure o escalonamento automático. Ao configurar os recursos, avalie as oportunidades para usar recursos e serviços do Google Cloud lançados recentemente que podem ajudar a otimizar ainda mais o desempenho.

O processo de otimização de desempenho não termina nessa etapa. Continue o ciclo de monitoramento de desempenho, reavaliando requisitos quando necessário e ajustando os recursos da nuvem para manter e melhorar o desempenho.

A seguir

• Monitorar e analisar o desempenho.
• Otimizar o desempenho da computação.
• Otimizar o desempenho do armazenamento.
• Otimizar o desempenho da rede.
• Otimizar o desempenho do banco de dados.
• Otimizar o desempenho da análise.

Monitorar e analisar o desempenho

Veja neste documento do Framework da arquitetura do Google Cloud os serviços do Google Cloud Observability que podem ser usados para registrar, monitorar e analisar o desempenho das cargas de trabalho.

Monitorar as métricas de desempenho

Use o Cloud Monitoring para analisar as tendências das métricas de desempenho, os efeitos dos experimentos, definir alertas para métricas importantes e realizar análises retrospectivas.

Registrar dados e eventos críticos

O Cloud Logging é um serviço integrado de geração de registros usado para armazenar, analisar, monitorar e definir alertas de dados e eventos de registro. O Cloud Logging pode coletar registros dos serviços do Google Cloud e de outros provedores de nuvem.

Analisar o desempenho do código

Um código com baixo desempenho pode aumentar a latência dos aplicativos, bem como o custo da execução. O Cloud Profiler ajuda a identificar e resolver problemas de desempenho ao analisar continuamente o desempenho de funções com uso intensivo da CPU ou de memória usadas por um aplicativo.

Coletar dados de latência

Em pilhas de aplicativos complexas e arquiteturas baseadas em microsserviços, pode ser difícil avaliar a latência na comunicação entre serviços e identificar gargalos de desempenho. As ferramentas do Cloud Trace e do OpenTelemetry ajudam a coletar os dados de latência das suas implantações em escala. Essas ferramentas também ajudam a analisar os dados de latência de maneira eficiente.

Monitorar o desempenho da rede

O Painel de desempenho do Network Intelligence Center oferece uma visão abrangente das métricas de desempenho da rede do Google e dos recursos do seu projeto. Essas métricas ajudam a determinar a causa de problemas de desempenho relacionados à rede. Por exemplo, é possível identificar se um problema de desempenho é resultado de um problema no seu projeto ou na rede do Google.

A seguir

• Consulte as práticas recomendadas para monitorar seus recursos da nuvem.
• Confira as práticas recomendadas para otimizar o desempenho dos recursos do Google Cloud:
  • Otimize o desempenho da computação.
  • Otimizar o desempenho do armazenamento.
  • Otimizar o desempenho da rede.
  • Otimizar o desempenho do banco de dados.
  • Otimizar o desempenho da análise.

Otimizar o desempenho da computação

Neste documento, no framework de arquitetura do Google Cloud, você encontra recomendações para otimizar o desempenho do Compute Engine, do Google Kubernetes Engine (GKE) e dos recursos sem servidor.

Compute Engine

Nesta seção, fornecemos orientação para ajudar a otimizar a performance dos recursos do Compute Engine.

Recursos de escalonamento automático

Com os Grupos de instâncias gerenciadas (MIGs, na sigla em inglês), é possível escalonar os aplicativos sem estado implantados nas VMs do Compute Engine de maneira eficiente. O escalonamento automático ajuda seus aplicativos a continuar a oferecer um desempenho previsível quando a carga aumenta. Em um MIG, um grupo de VMs do Compute Engine é iniciado com base em um modelo definido por você. No modelo, configure uma política de escalonamento automático, que especifica um ou mais sinais que o escalonador automático usa para escalonar o grupo. Os indicadores de escalonamento automático podem ser baseados na programação, como o horário de início ou a duração, ou com base em métricas de destino, como uso médio da CPU. Para mais informações, consulte Escalonamento automático de grupos de instâncias.

Desativar SMT

Cada CPU virtual (vCPU) alocada para uma VM do Compute Engine é implementada como um multithread de hardware único. Por padrão, duas vCPUs compartilham um núcleo físico da CPU. Essa arquitetura é chamada de threads simultâneos (SMT).

Para cargas de trabalho altamente paralelas ou que executam cálculos de pontos flutuantes (como transcodificação, simulações de Monte Carlo, análise de sequência genética e modelagem de risco financeiro), é possível melhorar o desempenho desativando o SMT. Para ver mais informações, consulte Definir número de linhas de execução por núcleo.

Usar GPUs

Para cargas de trabalho como visualização e machine learning, é possível adicionar unidades de processamento gráfico (GPUs) às VMs. O Compute Engine fornece GPUs NVIDIA no modo de passagem para que as VMs tenham controle direto sobre as GPUs e a memória associada. Para cargas de trabalho de muitos gráficos, como a visualização 3D, é possível usar estações de trabalho virtuais NVIDIA RTX. Depois de implantar as cargas de trabalho, monitore o uso da GPU e analise as opções para otimizar a performance da GPU.

Usar tipos de máquina otimizados para computação

Cargas de trabalho como jogos, transcodificação de mídia e computação de alto desempenho (HPC) exigem alto desempenho consistente por núcleo da CPU. O Google recomenda o uso de tipos de máquina otimizados para computação para as VMs que executam essas cargas de trabalho. As VMs otimizadas para computação são criadas em uma arquitetura que usa recursos como acesso à memória não uniforme (NUMA, na sigla em inglês) para um desempenho ideal e confiável.

Cargas de trabalho de HPC apertadas têm um conjunto exclusivo de requisitos para atingir a eficiência de pico no desempenho. Para mais informações, consulte a seguinte documentação:

• Sistemas de arquivos paralelos para cargas de trabalho de HPC
• Arquitetura: sistema de arquivos Lustre no Google Cloud usando DDN EXAScaler

Escolher armazenamento apropriado

O Google Cloud oferece uma ampla variedade de opções de armazenamento para VMs do Compute Engine: discos permanentes, discos de unidade de estado sólido (SSD) locais, Filestore e Cloud Storage. Veja recomendações de design e práticas recomendadas para otimizar o desempenho de cada uma dessas opções de armazenamento, consulte Otimizar a performance do armazenamento.

Google Kubernetes Engine

Nesta seção, fornecemos orientações para ajudar a otimizar a performance dos seus recursos do Google Kubernetes Engine (GKE).

Recursos de escalonamento automático

É possível redimensionar automaticamente os pools de nós em um cluster do GKE para corresponder à carga atual usando o recurso escalonador automático de clusters. O escalonamento automático ajuda seus aplicativos a continuar oferecendo um desempenho previsível quando a carga aumenta. O escalonador automático de clusters redimensiona os pools de nós automaticamente com base nas solicitações de recursos (e não na utilização real de recursos) dos pods em execução nos nós. Quando você usa o escalonamento automático, pode haver uma compensação entre desempenho e custo. Revise as práticas recomendadas para configurar o escalonamento automático de clusters com eficiência.

Observação: com os clusters do Autopilot, você não precisa se preocupar com o provisionamento de nós ou o gerenciamento de pools de nós. Os pools de nós são provisionados e escalonados automaticamente com base nos requisitos das cargas de trabalho.

Usar VMs C2D

É possível melhorar o desempenho de cargas de trabalho conteinerizadas com uso intensivo de computação usando tipos de máquina C2D. É possível adicionar nós C2D aos clusters do GKE escolhendo um tipo de máquina C2D nos pools de nós.

Desativar SMT

A várias linhas de execução simultâneas (SMT) pode aumentar significativamente a capacidade do aplicativo para tarefas gerais de computação e para cargas de trabalho que precisam de alta E/S. No entanto, para cargas de trabalho em que os dois núcleos virtuais estão vinculados à computação, o SMT pode causar desempenho inconsistente. Para um desempenho melhor e mais previsível, é possível desativar o SMT para os nós do GKE definindo o número de vCPUs por núcleo como 1.

Usar GPUs

Para cargas de trabalho com uso intenso de computação, como reconhecimento de imagens e transcodificação de vídeo, é possível acelerar o desempenho criando pools de nós que usam GPUs. Para mais informações, consulte Como executar GPUs.

Usar balanceamento de carga nativo de contêiner

O balanceador de carga nativo de contêiner permite que os balanceadores de carga distribuam o tráfego diretamente e de maneira uniforme aos pods. Essa abordagem proporciona melhor desempenho de rede e melhor visibilidade da latência da rede entre o balanceador de carga e os pods. Devido a esses benefícios, o balanceamento de carga nativo de contêiner é a solução recomendada para balanceamento de carga por meio da Entrada.

Definir uma política de posicionamento compacto

Cargas de trabalho em lote acopladas precisam de baixa latência de rede entre os nós no pool de nós do GKE. ​​É possível implantar essas cargas de trabalho em pools de nós de zona única e garantir que os nós estejam fisicamente próximos uns dos outros definindo uma política de posicionamento compacta. Para mais informações, consulte Definir posicionamento compacto para nós do GKE.

Serviços de computação sem servidor

Nesta seção, fornecemos orientações para ajudar a otimizar o desempenho dos seus serviços de computação sem servidor no Google Cloud: Cloud Run e Cloud Functions. Esses serviços oferecem recursos de escalonamento automático, em que a infraestrutura subordinada lida com o escalonamento automaticamente. Ao usar esses serviços sem servidor, é possível reduzir o esforço de escalonamento dos microsserviços e das funções, e você pode se concentrar em otimizar o desempenho no nível do aplicativo.

Para mais informações, consulte a seguinte documentação:

• Como otimizar o desempenho dos serviços do Cloud Run
• Como otimizar aplicativos Java para o Cloud Run
• Como otimizar o desempenho no Cloud Functions

A seguir

Confira as práticas recomendadas para otimizar o desempenho dos seus recursos de armazenamento, rede, banco de dados e análise:

• Otimize a performance do armazenamento.
• Otimizar o desempenho da rede.
• Otimizar o desempenho do banco de dados.
• Otimizar o desempenho da análise.

Otimizar o desempenho do armazenamento

Este documento no Framework da arquitetura do Google Cloud fornece recomendações para ajudar você a otimizar a performance dos seus recursos de armazenamento no Google Cloud.

Cloud Storage

Nesta seção, apresentamos as práticas recomendadas para ajudar você a otimizar o desempenho das operações do Cloud Storage.

Avaliar o desempenho do bucket

Avalie o desempenho dos buckets do Cloud Storage usando o comando gsutil perfdiag. Este comando testa o desempenho do bucket especificado enviando uma série de solicitações de leitura e gravação com arquivos de diferentes tamanhos. É possível ajustar o teste para corresponder ao padrão de uso dos apps. Use o relatório de diagnóstico gerado pelo comando para definir as expectativas de desempenho e identificar possíveis gargalos.

Armazenar em cache objetos acessados com frequência

Para melhorar a latência de leitura de objetos acessados com frequência acessíveis publicamente, configure esses objetos para serem armazenados em cache. O armazenamento em cache pode melhorar o desempenho, mas o conteúdo desatualizado pode ser exibido se um cache tiver a versão antiga de um objeto.

Escalonar solicitações com eficiência

À medida que a taxa de solicitação de um bucket aumenta, o Cloud Storage aumenta automaticamente a capacidade de E/S do bucket distribuindo a carga de solicitação por vários servidores. Para alcançar o desempenho ideal ao dimensionar solicitações, siga as práticas recomendadas para aumentar as taxas de solicitação e distribuir a carga de maneira uniforme.

Ativar multithreading e multiprocessamento

Ao usar gsutil para fazer upload de vários arquivos pequenos, é possível melhorar a performance da operação usando a opção -m. Essa opção faz com que a solicitação de upload seja implementada como uma operação em lote, paralela (ou seja, com várias linhas de execução e multiprocessamento). Use essa opção apenas quando você realizar operações por uma conexão de rede rápida. Para mais informações, consulte a documentação da opção -m em Opções de linha de comando global.

Fazer upload de arquivos grandes como compostos

Para fazer upload de arquivos grandes, use uma estratégia chamada uploads compostos paralelos. Com essa estratégia, o arquivo grande é dividido em blocos, que são enviados em paralelo e, depois, recompostos na nuvem. Os uploads compostos paralelos podem ser mais rápidos do que as operações de upload regulares quando a largura de banda da rede e a velocidade do disco não estão limitando os fatores. No entanto, essa estratégia tem algumas limitações e implicações de custo. Para mais informações, consulte Uploads compostos paralelos.

Discos permanentes e SSDs locais

Nesta seção, apresentamos as práticas recomendadas para ajudar você a otimizar o desempenho dos discos permanentes e dos SSDs locais anexados para VMs do Compute Engine.

O desempenho de discos permanentes e SSDs locais depende do tipo e do tamanho do disco, do tipo de máquina da VM e do número de vCPUs. Use as seguintes diretrizes para gerenciar o desempenho dos discos permanentes e SSDs locais:

• Ao provisionar o armazenamento em blocos para suas VMs, escolha os tipos e tamanhos de disco adequados para sua carga de trabalho. Para mais informações, consulte Configurar discos para atender aos requisitos de performance.
• Compare o desempenho do armazenamento em blocos. Para mais informações, consulte a seguinte documentação:
  • Comparativo do desempenho do disco permanente
  • Comparação do desempenho do SSD local
• Otimize o desempenho dos seus discos permanentes e SSDs locais. Para mais informações, consulte a seguinte documentação:
  • Como otimizar o desempenho do disco permanente
  • Como otimizar o desempenho da SSD local

Filestore

Nesta seção, apresentamos as práticas recomendadas para ajudar você a otimizar a performance das instâncias do Filestore. Use o Filestore para provisionar servidores de arquivos do Network File System (NFS) totalmente gerenciados para VMs do Compute Engine e clusters do GKE.

• Ao provisionar uma instância do Filestore, escolha um nível de serviço que atenda aos requisitos de performance e capacidade da sua carga de trabalho.
• Para VMs cliente que executam cargas de trabalho dependentes do cache, use um tipo de máquina que ajude a otimizar a performance da rede da instância do Filestore. Para mais informações, consulte Tipo de máquina de cliente recomendado.
• Para otimizar a performance das instâncias do Filestore para VMs cliente que executam o Linux, o Google recomenda configurações específicas de montagem do NFS. Para mais informações, consulte Opções de montagem do cliente Linux.
• Para minimizar a latência da rede, provisione as instâncias do Filestore em regiões e zonas próximas ao local em que você planeja usar as instâncias.
• Monitore o desempenho das instâncias do Filestore e configure alertas usando o Cloud Monitoring.

A seguir

Confira as práticas recomendadas para otimizar o desempenho dos recursos de computação, rede, banco de dados e análise:

• Otimize a performance da computação.
• Otimize a performance da rede.
• Otimizar o desempenho do banco de dados.
• Otimizar o desempenho da análise.

Otimizar o desempenho da rede e das APIs

Veja neste documento do Framework da arquitetura do Google Cloud recomendações para otimizar o desempenho dos seus recursos de rede e APIs no Google Cloud.

Níveis de serviço de rede

Os níveis de serviço de rede permitem otimizar o custo de rede e o desempenho das suas cargas de trabalho. Escolha um destes níveis:

• O nível Premium usa o backbone global altamente confiável do Google para ajudar você a conseguir latência e perda de pacotes mínimas. O tráfego entra e sai da rede do Google em um ponto de presença (PoP, na sigla em inglês) de borda global próximo do usuário final. Recomendamos o uso do nível Premium como padrão para um desempenho ideal. O nível Premium oferece suporte a endereços IP externos regionais e globais para VMs e balanceadores de carga.
• O nível Standard está disponível apenas para recursos que usam endereços IP externos regionais. O tráfego entra e sai da rede do Google em um PoP de borda mais próximo do local do Google Cloud em que a carga de trabalho é executada. O preço do nível Standard é menor que o do nível Premium. O nível Standard é adequado para tráfego que não é sensível à perda de pacotes e que não tem requisitos de baixa latência.

Você pode ver a latência da rede dos níveis Standard e Premium de cada região da nuvem no Painel de desempenho do Network Intelligence Center.

Quadros enormes

As redes de nuvem privada virtual (VPC) têm uma unidade máxima de transmissão (MTU, na sigla em inglês) padrão de 1460 bytes. No entanto, é possível configurar as redes VPC para que sejam compatíveis com uma MTU de até 8896 (frames jumbo).

Com uma MTU mais alta, a rede precisa de menos pacotes para enviar a mesma quantidade de dados, reduzindo assim a largura de banda usada pelos cabeçalhos TCP/IP. Isso leva a uma largura de banda efetiva maior para a rede.

Para mais informações sobre a MTU intraVPC e a MTU máxima de outras conexões, consulte a página Unidade máxima de transmissão na documentação da VPC.

Desempenho da VM

As VMs do Compute Engine têm uma largura de banda de saída máxima que, em parte, depende do tipo de máquina. Um aspecto da escolha de um tipo de máquina apropriado é considerar a quantidade de tráfego que você espera que a VM gere.

A página Largura de banda da rede contém uma discussão e uma tabela de larguras de banda de rede para os tipos de máquina do Compute Engine.

Se os requisitos de largura de banda entre VMs forem muito altos, considere as VMs compatíveis com a rede Tier_1.

Cloud Load Balancing

Veja nesta seção as práticas recomendadas para otimizar o desempenho das instâncias do Cloud Load Balancing.

Implantar aplicativos perto dos usuários

Provisione os back-ends do seu aplicativo perto do local em que você espera que o tráfego de usuários chegue ao balanceador de carga. Quanto mais próximos os usuários ou aplicativos de clientes estiverem dos servidores de carga de trabalho, menor será a latência da rede entre os usuários e a carga de trabalho. Para minimizar a latência de clientes em diferentes partes do mundo, pode ser necessário implantar os back-ends em várias regiões. Saiba mais em Práticas recomendadas para a seleção de regiões do Compute Engine.

Escolher um tipo de balanceador de carga adequado

O tipo de balanceador de carga escolhido para o aplicativo pode determinar a latência que os usuários enfrentam. Saiba como avaliar e otimizar a latência do aplicativo para diferentes tipos de balanceador de carga em Otimizar a latência do aplicativo com balanceamento de carga.

Ativar o armazenamento em cache

Para acelerar a disponibilização de conteúdo, ative o armazenamento em cache e o Cloud CDN como parte da configuração padrão do balanceador de carga HTTP externo. Verifique se os servidores de back-end estão configurados para enviar os cabeçalhos de resposta necessários para que as respostas estáticas sejam armazenadas em cache.

Usar HTTP quando HTTPS não for necessário

O Google criptografa automaticamente o tráfego entre balanceadores de carga de proxy e back-ends no nível do pacote. A criptografia no nível do pacote adiciona a criptografia da camada 7 usando HTTPS entre o balanceador de carga e os back-ends Considere usar HTTP em vez de HTTPS ou HTTP/2 para o tráfego entre o balanceador de carga e os back-ends. Ao usar HTTP, também é possível reduzir o uso da CPU das VMs de back-end. No entanto, quando o back-end for um grupo de endpoints de rede (NEG, na sigla em inglês) da Internet, use HTTPS ou HTTP/2 para o tráfego entre o balanceador de carga e o back-end. Isso ajuda a garantir o tráfego seguro na Internet pública. Para um melhor desempenho, recomendamos comparar os padrões de tráfego do aplicativo.

Network Intelligence Center

O Network Intelligence Center do Google Cloud fornece uma visão abrangente do desempenho da rede do Google Cloud em todas as regiões. O Network Intelligence Center ajuda a determinar se os problemas de latência são causados por problemas no projeto ou na rede. Também é possível usar essas informações para selecionar as regiões e zonas em que você precisa implantar suas cargas de trabalho para otimizar o desempenho da rede.

Use as seguintes ferramentas do Network Intelligence Center para monitorar e analisar o desempenho da rede das suas cargas de trabalho no Google Cloud:

• O Painel de desempenho mostra a latência entre as regiões do Google Cloud e entre regiões e locais individuais na Internet. O Painel de desempenho pode ajudar a determinar onde colocar cargas de trabalho para a melhor latência e determinar quando um problema do aplicativo pode ocorrer devido a problemas de rede subjacentes.

• A Topologia de rede oferece um panorama visual das redes de nuvem privada virtual (VPC), da conectividade híbrida com as redes locais e da conectividade com os serviços gerenciados pelo Google. A Topologia de rede fornece métricas operacionais em tempo real que podem ser usadas para analisar e entender o desempenho da rede e identificar padrões de tráfego anormais.

• O Network Analyzer é uma ferramenta automática de monitoramento e diagnóstico de configurações. Ele verifica as configurações de rede VPC em regras de firewall, rotas, dependências de configuração e conectividade de serviços e aplicativos. Também ajuda a identificar falhas de rede, além de fornecer análises de causas raiz e recomendações. O Network Analyzer traz insights prioritários para analisar problemas com a configuração da rede, como a alta utilização de endereços IP em uma sub-rede.

Gateway de API e Apigee

Veja nesta seção algumas recomendações para otimizar o desempenho das APIs que você implanta no Google Cloud usando o Gateway de API e a Apigee.

O Gateway de API permite criar e gerenciar APIs para back-ends sem servidor do Google Cloud, incluindo Cloud Functions, Cloud Run e App Engine. Esses serviços são gerenciados e são escalonados automaticamente. No entanto, conforme os aplicativos implantados nesses serviços são escalonados, pode ser necessário aumentar as cotas e limitações de taxa para o Gateway de API.

Observação: a exposição de aplicativos ou da infraestrutura a mais tráfego pode causar gargalos de desempenho na camada seguinte da pilha de aplicativos.

A Apigee fornece os seguintes painéis de análise para ajudar você a monitorar o desempenho das APIs gerenciadas:

• Painel de desempenho do proxy de API: monitore os padrões de tráfego e os tempos de processamento do proxy de API.
• Painel de desempenho do destino: visualize padrões de tráfego e métricas de desempenho em destinos de back-end do proxy de API.
• Painel de desempenho do cache: monitore as métricas de desempenho do cache da Apigee, como a taxa média de ocorrência em cache e o tempo médio no cache.

Se você usar a integração com a Apigee, considere os limites de configuração do sistema ao criar e gerenciar suas integrações.

A seguir

Confira as práticas recomendadas para otimizar o desempenho dos recursos de computação, armazenamento, banco de dados e análise:

• Otimize o desempenho da computação.
• Otimize o desempenho do armazenamento.
• Otimize o desempenho do banco de dados.
• Otimizar o desempenho da análise.

Otimizar o desempenho do banco de dados

Neste documento do Framework de arquitetura do Google Cloud, você encontra recomendações para otimizar o desempenho dos seus bancos de dados no Google Cloud.

Cloud SQL

As recomendações a seguir ajudam a otimizar a performance das instâncias do Cloud SQL que executam bancos de dados do SQL Server, MySQL e PostgreSQL.

• Para bancos de dados do SQL Server, o Google recomenda que você modifique determinados parâmetros e retenha os valores padrão para alguns parâmetros.
• Ao escolher o tipo de armazenamento para bancos de dados MySQL ou PostgreSQL, considere a compensação de custo-performance entre SSD e armazenamento HDD.
• Para identificar e analisar problemas de desempenho com bancos de dados PostgreSQL, use o painel Cloud SQL Insights.
• Para diagnosticar o baixo desempenho ao executar consultas SQL, use a instrução EXPLAIN.

Para mais informações, consulte a seguinte documentação:

• Desempenho do Optimize: SQL Server
• Desempenho do Optimize: MySQL
• Desempenho do Optimize: PostgreSQL

Bigtable

Nesta seção, apresentamos recomendações para ajudar você a otimizar a performance das instâncias do Bigtable.

Capacidade do plano com base nos requisitos de desempenho

Você pode usar o Bigtable em um amplo espectro de aplicativos, cada um com um objetivo de otimização diferente. Por exemplo, para jobs de processamento de dados em lote, a capacidade pode ser mais importante do que a latência. Para um serviço on-line que atende às solicitações do usuário, talvez seja necessário priorizar a latência mais baixa em vez da capacidade de processamento. Ao planejar a capacidade dos clusters do Bigtable, considere as vantagens e desvantagens entre a capacidade de processamento e a latência. Para mais informações, consulte Planejar a capacidade do Bigtable.

Seguir as práticas recomendadas para a concepção de esquemas

As tabelas podem ser escalonadas para bilhões de linhas e milhares de colunas, permitindo que você armazene petabytes de dados. Ao projetar o esquema para as tabelas do Bigtable, considere as práticas recomendadas de design de esquemas.

Monitorar o desempenho e fazer ajustes

Monitore o uso da CPU e do disco para as instâncias, analise o desempenho de cada cluster e analise as recomendações de dimensionamento mostradas nos gráficos de monitoramento.

Spanner

Nesta seção, apresentamos recomendações para ajudar a otimizar a performance das instâncias do Spanner.

Escolha uma chave primária que impeça um ponto de acesso

Um ponto de acesso é um único servidor que é forçado a processar muitas solicitações. Ao escolher a chave primária para seu banco de dados, siga as práticas recomendadas de design de esquemas para evitar um ponto de acesso.

Seguir as práticas recomendadas para programação SQL

O compilador SQL no Spanner converte cada instrução SQL declarativa que você grava em um plano de execução de consulta imperativo. O Spanner usa esse plano de execução para executar a instrução SQL. Ao criar instruções SQL, siga as práticas recomendadas de SQL para garantir que o Spanner use planos de execução que ofereçam desempenho ideal.

Use as opções de consulta para gerenciar o otimizador de consultas SQL

O Spanner usa um otimizador de consultas SQL para transformar instruções SQL em planos de execução de consulta eficientes. O plano de execução de consulta que o otimizador produz pode mudar um pouco quando o otimizador de consultas evolui ou quando as estatísticas do banco de dados são atualizadas. É possível minimizar o potencial de regressão de performance quando o otimizador de consultas ou as estatísticas do banco de dados mudam usando opções de consulta.

Visualizar e ajustar a estrutura dos planos de execução de consulta

Para analisar problemas de performance na consulta, visualize e ajuste a estrutura dos planos de execução da consulta usando o visualizador de planos de consulta.

Use APIs de operações para gerenciar operações de longa duração

Para determinadas chamadas de método, o Spanner cria operações de longa duração, que podem levar um tempo significativo. Por exemplo, quando você restaura um banco de dados, o Spanner cria uma operação de longa duração para rastrear o progresso da restauração. Para ajudar você a monitorar e gerenciar operações de longa duração, o Spanner disponibiliza APIs de operações. Para mais informações, consulte Como gerenciar operações de longa duração.

Seguir as práticas recomendadas para carregamento em massa

O Spanner dá suporte a várias opções para carregar grandes quantidades de dados em massa. O desempenho de uma operação de carregamento em massa depende de fatores como particionamento, número de solicitações de gravação e tamanho de cada solicitação. Para carregar grandes volumes de dados de maneira eficiente, siga as práticas recomendadas de carregamento em massa.

Monitorar e controlar o uso da CPU

O uso da CPU da instância do Spanner pode afetar as latências das solicitações. Um servidor de back-end sobrecarregado pode causar latências de solicitações mais altas. O Spanner oferece métricas de utilização da CPU para ajudar você a investigar uma alta taxa de utilização da CPU. Para aplicativos sensíveis ao desempenho, talvez seja necessário aumentar a utilização da CPU aumentando a capacidade de computação.

Analisar e resolver problemas de latência

Quando um cliente faz uma chamada de procedimento remoto para o Spanner, a solicitação da API é preparada primeiro pelas bibliotecas de cliente. A solicitação passa pelo Google Front End e pelo front-end da API Cloud Spanner antes de chegar ao banco de dados do Spanner. Para analisar e resolver problemas de latência, é necessário medir e analisar a latência de cada segmento do caminho que a solicitação de API passa. Para mais informações, consulte o Guia completo de latência do Spanner.

Iniciar aplicativos após o banco de dados atingir o estado de calor

À medida que o banco de dados do Spanner cresce, ele divide o espaço-chave dos dados em divisões. Cada divisão é um intervalo de linhas que contém um subconjunto da sua tabela. Para balancear a carga geral no banco de dados, o Spanner move dinamicamente divisões individuais de maneira independente e as atribui a servidores diferentes. Quando as divisões são distribuídas entre vários servidores, o banco de dados é considerado em estado quente. Um banco de dados caloroso pode maximizar o paralelismo e fornecer melhor performance. Antes de iniciar os aplicativos, recomendamos que você aqueça o banco de dados com carregamentos de dados de teste.

A seguir

Confira as práticas recomendadas para otimizar o desempenho dos recursos de computação, armazenamento, rede e análise:

• Otimize o desempenho da computação.
• Otimizar o desempenho do armazenamento.
• Otimize o desempenho da rede.
• Otimizar o desempenho da análise.

Otimizar o desempenho do Google Analytics

Neste documento, no framework de arquitetura do Google Cloud, você encontra recomendações para otimizar o desempenho das cargas de trabalho de análise no Google Cloud.

O BigQuery

Nesta seção, apresentamos recomendações para ajudar você a otimizar a performance das consultas no BigQuery.

Otimizar o design da consulta

O desempenho da consulta depende de fatores como o número de bytes lidos e gravados pelas consultas e o volume de dados transmitido entre slots. Para otimizar a performance das consultas no BigQuery, aplique as práticas recomendadas descritas na documentação a seguir:

• Introdução à otimização do desempenho da consulta
• Como gerenciar dados de entrada e fontes de dados
• Como otimizar a comunicação entre slots
• Otimizar a computação em consultas
• Gerenciar saídas de consulta
• Como evitar antipadrões de SQL

Definir e usar visualizações materializadas de maneira eficiente

Para melhorar o desempenho das cargas de trabalho que usam consultas comuns e repetidas, use visualizações materializadas. Há limites para o número de visualizações materializadas que você pode criar. Não crie uma visualização materializada separada para cada permutação de uma consulta. Em vez disso, defina visualizações materializadas que podem ser usadas para vários padrões de consultas.

Melhore a performance JOIN

É possível usar visualizações materializadas para reduzir o custo e a latência de uma consulta que realiza agregação em uma JOIN. Considere um caso em que você mescla uma tabela de fatos grande com algumas tabelas de dimensões pequenas e, em seguida, executa uma agregação na parte superior da mesclagem. Talvez seja prático reescrever a consulta para primeiro realizar a agregação na tabela de fatos com chaves externas como chaves de agrupamento. Em seguida, mescle o resultado com as tabelas de dimensão. Por fim, execute uma pós-agregação.

Dataflow

Nesta seção, apresentamos recomendações para ajudar a otimizar o desempenho da consulta dos pipelines do Dataflow.

Ao criar e implantar pipelines, configure parâmetros de execução, como o tipo de máquina do Compute Engine que precisa ser usado para as VMs de worker do Dataflow. Para mais informações, consulte Opções de pipeline.

Depois de implantar os pipelines, o Dataflow gerencia os recursos do Compute Engine e do Cloud Storage necessários para executar jobs. Além disso, os seguintes recursos do Dataflow ajudam a otimizar o desempenho dos pipelines:

• Carregamento em paralelo: o Cloud Dataflow particiona automaticamente os dados e distribui o código do worker nas instâncias do Compute Engine para processamento paralelo. Para mais informações, consulte carregamento em paralelo e distribuição.
• Otimização: o Dataflow usa o código do pipeline para criar um gráfico de execução que represente objetos PCollection e transformações no pipeline. Em seguida, ele otimiza o gráfico para ter desempenho e uso de recursos mais eficientes. Além disso, otimiza de modo automático as operações de custo potencialmente alto, como agregações de dados. Para mais informações, consulte Otimização de fusão e Otimização de combinação.
• Ajuste automático: o Dataflow otimiza os jobs de maneira dinâmica durante a execução usando Escalonamento automático horizontal, Escalonamento automático vertical, e Reequilíbrio de trabalho dinâmico.

É possível monitorar a performance dos pipelines do Dataflow usando a interface de monitoramento com base na Web ou a CLI gcloud do Dataflow.

Observação: também é possível usar o Cloud Profiler para identificar as partes do código de pipeline que consomem a maioria dos recursos. Para mais informações, consulte Como monitorar a performance do pipeline.

Dataproc

Nesta seção, você verá as práticas recomendadas para otimizar o desempenho dos clusters do Dataproc.

Escalonar clusters automaticamente

Para garantir que os clusters do Dataproc ofereçam um desempenho previsível, ative o escalonamento automático. O Dataproc usa as métricas de memória do Hadoop YARN e uma política de escalonamento automático que você define para ajustar automaticamente o número de VMs de worker em um cluster. Para mais informações sobre como usar e configurar o escalonamento automático, consulte Clusters de escalonamento automático.

Provisionar armazenamento apropriado

Escolha uma opção de armazenamento adequada para o cluster do Dataproc com base nos seus requisitos de desempenho e custo:

• Se você precisar de um sistema de arquivos de baixo custo compatível com o Hadoop (HCFS, na sigla em inglês), que pode ser lido e gravado pelos jobs do Hadoop e do Spark, com alterações mínimas, use o Cloud Storage. Os dados armazenados no Cloud Storage são permanentes e podem ser acessados por outros clusters do Dataproc e outros produtos, como o BigQuery.
• Se você precisar de um sistema de arquivos distribuídos do Hadoop (HDFS, na sigla em inglês) de baixa latência para o cluster do Dataproc, use discos permanentes do Compute Engine anexados aos nós de trabalho. Os dados armazenados no HDFS são temporários, e o custo de armazenamento é maior do que a opção do Cloud Storage.
• Para aproveitar a vantagem de performance dos discos permanentes do Compute Engine e os benefícios de custo e durabilidade do Cloud Storage, é possível combinar as duas opções de armazenamento. Por exemplo, é possível armazenar seus conjuntos de dados de origem e finais no Cloud Storage e provisionar capacidade limitada do HDFS para os conjuntos de dados intermediários. Ao decidir o tamanho e o tipo de discos para o armazenamento HDFS, considere as recomendações na seção Discos permanentes e SSDs locais.

Reduza a latência ao usar o Cloud Storage

Para reduzir a latência ao acessar dados armazenados no Cloud Storage, recomendamos o seguinte:

• Crie o bucket do Cloud Storage na mesma região do cluster do Dataproc.
• Desativar auto.purge para tabelas gerenciadas pelo Apache Hive armazenadas no Cloud Storage.
• Ao usar o Spark SQL, considere criar clusters do Dataproc com as versões mais recentes de imagens disponíveis. Ao usar a versão mais recente, você pode evitar problemas de performance que podem permanecer em versões mais antigas, como a performance lento de INSERT OVERWRITE (link em inglês) no Spark 2.x.
• Para minimizar a possibilidade de gravar muitos arquivos com tamanhos variados ou pequenos no Cloud Storage, configure os parâmetros SQL do Spark spark.sql.shuffle.partitions e spark.default.parallelism ou o parâmetro mapreduce.job.reduces do Hadoop.

Monitorar e ajustar a carga e a capacidade do armazenamento

Os discos permanentes anexados aos nós de trabalho em um cluster do Dataproc mantêm dados embaralhados. Para ter um desempenho ideal, os nós de trabalho precisam de espaço em disco suficiente. Se os nós não tiverem espaço em disco suficiente, eles serão marcados como UNHEALTHY no registro YARN NodeManager. Se esse problema ocorrer, aumente o tamanho do disco para os nós afetados ou execute menos jobs ao mesmo tempo.

Ativar EFM

Quando os nós de trabalho são removidos de um cluster do Dataproc em execução, como devido à redução ou preempção, os dados de embaralhamento podem ser perdidos. Para minimizar os atrasos nas vagas nesses cenários, recomendamos ativar Modo de flexibilidade aprimorada (EFM) para clusters que usam VMs preemptivas ou que escalonam automaticamente apenas o grupo de workers secundários.

A seguir

Confira as práticas recomendadas para otimizar o desempenho dos recursos de computação, armazenamento, rede e banco de dados:

• Otimize o desempenho da computação.
• Otimizar o desempenho do armazenamento.
• Otimizar o desempenho da rede.
• Otimizar o desempenho do banco de dados.

Novidades no framework de arquitetura

Neste documento, listamos as alterações significativas no framework da arquitetura do Google Cloud.

28 de novembro de 2023

• Categoria de confiabilidade:
  • Reorganizamos o conteúdo para melhorar a legibilidade e a consistência:
  • Definir SLOs: a seção "Terminologia" foi movida para uma nova página: Terminologia
  • Adotar SLOs: a seção "SLOs e alertas" foi movida para a nova página: SLOs e alertas

9 de novembro de 2023

• Categoria de design do sistema:
  • Inclusão de orientações para ajudar os arquitetos de nuvem a escolher arquétipos de implantação para cargas de trabalho no Google Cloud.

8 de setembro de 2023

• Categoria de otimização de custos:

  • Adicionamos informações sobre o uso de tags para governança e alocação de custos.
  • Atualizamos as orientações para identificar anomalias na rotulagem.

  Para mais informações, consulte Rastrear e alocar custos usando tags ou rótulos.

28 de agosto de 2023

• Categoria de design do sistema:
  • Atualizamos a lista de serviços de IA e ML no Google Cloud.

23 de agosto de 2023

• Categoria de otimização de custos:
  • Adicionamos orientações sobre como otimizar o uso de recursos do Spanner para pequenas cargas de trabalho usando unidades de processamento em vez de nós.

18 de agosto de 2023

• Categoria de segurança, privacidade e compliance:
  • Adicionamos orientações relacionadas à HIPAA.
• Categoria de excelência operacional:
  • Atualizamos as práticas recomendadas para o planejamento para eventos de pico de tráfego.

9 de agosto de 2023

• Categoria de confiabilidade:
  • Foram adicionados links para a documentação relacionada à confiabilidade dos seguintes produtos:
    • Dataproc
    • Bigtable
    • Cloud SQL
    • Spanner

13 de julho de 2023

• Design do sistema:
  • O AlloyDB para PostgreSQL foi adicionado à lista de serviços de banco de dados no Google Cloud.
• Otimização de custos:
  • Adicionamos orientações sobre o Google Cloud Hyperdisk e os SSDs locais na seção Disco permanente.

23 de junho de 2023

• Otimização de desempenho:
  • Adicionamos orientações sobre como otimizar o uso da largura de banda usando frames jumbo e tipos de máquina adequados para VMs.

15 de junho de 2023

• Segurança, privacidade e conformidade:
  • Adição de orientação sobre como proteger conexões a ambientes locais e multicloud usando o Cross-Cloud Interconnect.
  • Adição de orientação sobre como proteger o perímetro de cargas de trabalho na nuvem usando políticas e regras de firewall e o Secure Web Proxy.

30 de março de 2023

• Foram adicionados mais dois artigos do SLO ao framework:
  • Definir SLOs
  • Adotar SLOs

16 de setembro de 2022

• Grande expansão da categoria otimização de desempenho.

10 de agosto de 2022

• Mudanças na categoria Design do sistema:
  • Adicionamos princípios básicos de design do sistema.
  • Adicionamos recomendações para usar os serviços de consultoria do Google Cloud e interagir com nossos parceiros.

4 de agosto de 2022

• Adicionamos informações sobre os seguintes recursos na categoria otimização de custos:

  • Para evitar interrupções devido a problemas de faturamento, bloqueie o link entre um projeto e a conta de faturamento dele. Para mais informações, consulte Configurar o controle de acesso de faturamento.

  • Reduzir a cota usando a API Service Usage. Para mais informações, consulte Orçamentos, alertas e cotas.

  • Identificar e remover projetos autônomos. Para mais informações, consulte Recomendações do Active Assist.

13 de julho de 2022

• Mudanças na categoria excelência operacional:

  • Adição de uma prática recomendada sobre como criar um centro de excelência.
  • Adição de uma prática recomendada sobre como configurar uma trilha de auditoria.

27 de junho de 2022

• Inclusão de informações sobre responsabilidades compartilhadas e destino compartilhado no Google Cloud na categoria Segurança.

13 de junho de 2022

• Inclusão de recomendações para ajudar você a projetar cargas de trabalho de nuvem para sustentabilidade ambiental na categoria design do sistema.

1 de junho de 2022

• Inclusão de informações sobre VMs do Spot na seção Custo do Optimize: computação, contêineres e sem servidor.

7 de maio de 2022

• Adicionamos informações sobre locais de duas regiões nas práticas recomendadas de otimização de custos para o Cloud Storage.

4 de maio de 2022

• Adicionamos guias de confiabilidade do produto. Estes guias incluem práticas recomendadas de confiabilidade para os seguintes produtos:

  • Compute: Compute Engine, Cloud Run, Funções do Cloud e Google Kubernetes Engine

  • Armazenamento e bancos de dados: Cloud Storage, Firestore

  • Rede: Cloud DNS e Cloud Load Balancing

  • Análise de dados: BigQuery

25 de fevereiro de 2022

• Mudanças na categoria de segurança:

  • Atualizamos as práticas recomendadas de conformidade para discutir a automação.

15 de dezembro de 2021

• Lançamento do espaço do framework de arquitetura na comunidade do Google Cloud.

25 de outubro de 2021

• Mudanças na categoria de confiabilidade:

  • Adicionamos práticas recomendadas para replicar dados entre regiões para recuperação de desastres e projetar uma arquitetura multirregional para resiliência a interrupções regionais.
  • Adicionamos um exemplo de como calcular margens de erro.
  • Adicionamos uma prática recomendada para escolher bons nomes para aplicativos e serviços.

7 de outubro de 2021

• Atualização importante de todas as categorias.

---

1. Anna Berenberg e Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, Volume 55, Edição 3, Artigo no: 61, pp 1-48 ↩