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.