Base de dados integrada ou externa? Como escolher uma arquitetura de base de dados para uma aplicação autoalojada

Comece pelo limite operacional, não pela opção que parece mais sofisticada

Para uma aplicação baseada em Docker, uma base de dados integrada geralmente significa que a aplicação e o respetivo serviço de base de dados suportado são definidos como parte da mesma aplicação Compose. Podem ser executados em contentores separados, enquanto a base de dados mantém os seus dados num volume Docker. Uma base de dados externa é um serviço de base de dados operado separadamente, ao qual a aplicação acede através de uma ligação configurada.

Nenhuma das disposições é, por si só, mais fiável, segura ou profissional. A pergunta útil é: que equipa é responsável pelo limite completo do serviço e consegue essa equipa operar bem as suas dependências, alterações e procedimentos de recuperação?

Uma base de dados integrada pode ser a arquitetura de menor risco quando é oficialmente suportada pela aplicação e uma pequena equipa precisa de uma stack contida com um ciclo de vida claro. Uma base de dados separada pode ser apropriada quando a documentação da aplicação o exige, quando cargas de trabalho aprovadas precisam realmente de um serviço partilhado ou quando uma equipa de bases de dados ou de infraestrutura já tem procedimentos operacionais definidos para esse serviço.

• Escolha o menor limite operacional que cumpra os requisitos documentados da aplicação.
• Não trate “externa” como sinónimo de resiliente nem “integrada” como sinónimo de descartável.
• Tome a decisão por aplicação e por modelo de implementação documentado, em vez de adotar uma única regra para todas as cargas de trabalho.

Verifique o modelo de implementação suportado pela aplicação antes de desenhar a infraestrutura

A documentação da própria aplicação é a autoridade quanto a suportar uma base de dados integrada, uma base de dados externa ou ambas. Faça esse trabalho antes de aprovisionar um servidor ou migrar dados de produção. Uma cadeia de ligação tecnicamente possível não prova que um padrão de implementação seja suportado durante atualizações, migrações ou recuperação de incidentes.

Verifique os requisitos documentados relativos ao motor e à versão da base de dados. Depois, verifique exatamente como a aplicação recebe as definições de ligação, como executa migrações de esquema, se espera uma extensão de base de dados ou um passo de inicialização específico e se documenta pressupostos de alta disponibilidade ou de cópias de segurança.

O comportamento no arranque também é importante. No Compose, o facto de uma dependência ter sido iniciada não significa, por si só, que esteja pronta para aceitar ligações à base de dados. A Docker documenta que o Compose normalmente espera que um contentor de dependência esteja em execução, não que esteja pronto. Quando a implementação da aplicação o requer, uma verificação de integridade da base de dados e uma condição de dependência service_healthy podem impedir que uma aplicação tente a ligação inicial demasiado cedo.

• Motor de base de dados suportado, versão principal e quaisquer extensões necessárias.
• Definições de ligação suportadas e se TLS, certificados ou regras de rede são requisitos documentados.
• Comando de migração, momento da migração, comportamento perante falhas e orientações de reversão.
• Caminho de atualização suportado tanto para a aplicação como para a base de dados.
• Orientações de cópia de segurança, restauro e alta disponibilidade publicadas pelo fornecedor da aplicação.
• Expectativas de sequenciamento de arranque e verificações de integridade.

Mapeie todo o percurso dos dados: a base de dados relacional raramente é o sistema inteiro

Antes de selecionar uma arquitetura de base de dados, identifique todos os componentes que mantêm estado persistente ou crítico para a segurança. A base de dados relacional pode ser a fonte autoritativa para os registos da aplicação, mas a mesma aplicação também pode depender de armazenamento de ficheiros, armazenamento de objetos, uma cache, um índice de pesquisa, uma fila, ficheiros de configuração e segredos. Cada um pode ter um modelo diferente de persistência, cópia de segurança e restauro.

O Docker Compose distingue recursos como serviços, volumes, configurações e segredos. Essa distinção é operacionalmente importante. Um volume Docker nomeado pode sobreviver à remoção de um contentor, separando o ciclo de vida de um contentor de base de dados do ciclo de vida dos dados da base de dados. No entanto, isso não estabelece que simplesmente copiar um diretório de dados de uma base de dados ativa seja uma cópia de segurança consistente da base de dados.

Crie um inventário que identifique a fonte autoritativa para cada tipo de dados. Esta é a base de um plano de recuperação, de um plano de migração e de uma resposta precisa à pergunta: “O que perdemos se este componente não estiver disponível ou for restaurado a partir de um ponto anterior?”

• Base de dados relacional: registos transacionais da aplicação, identidades, definições ou metadados, quando documentado.
• Armazenamento de ficheiros ou objetos: carregamentos, anexos, exportações geradas, conteúdos multimédia ou documentos, quando utilizado.
• Cache: determine se pode ser recriada em segurança ou se contém estado que afeta a recuperação.
• Índice de pesquisa ou armazenamento vetorial: determine se é autoritativo ou se pode ser recriado a partir de outra fonte.
• Estado de fila ou de fluxo de trabalho: identifique se o trabalho pendente precisa de ser preservado e como é recuperado.
• Configuração e segredos da aplicação: mantenha a configuração necessária para voltar a ligar componentes e desencriptar ou aceder a dados protegidos.

Quando uma base de dados integrada é a escolha acertada

Uma base de dados integrada é frequentemente apropriada quando corresponde a uma implementação da aplicação oficialmente documentada, a carga de trabalho tem um âmbito restrito e a mesma equipa consegue operar a aplicação e a base de dados como um único serviço. Limita o número de sistemas independentes que têm de ser configurados, monitorizados, alterados e recuperados em conjunto.

Esta escolha não significa tratar a base de dados como um componente secundário sem importância. Continua a precisar de armazenamento persistente, credenciais, cobertura de cópias de segurança, monitorização do crescimento do armazenamento, um caminho de atualização documentado e testes de restauro. O seu benefício é um limite de responsabilidade mais simples, não a ausência de operações de base de dados.

Para uma pequena equipa técnica, isto pode ser mais fácil de compreender do que um serviço remoto com rotas de rede separadas, regras de firewall, gestão de contas e janelas de alteração. Mantenha o limite claro: a stack da aplicação e a respetiva base de dados são implementadas, atualizadas e recuperadas como um sistema coordenado.

• O fornecedor documenta a implementação integrada como suportada.
• Uma equipa é responsável pelo ciclo de vida da aplicação e da base de dados.
• Um serviço de base de dados dedicado não é exigido por política, arquitetura ou orientação do fornecedor.
• A equipa consegue criar cópias de segurança e restaurar a base de dados e todos os armazenamentos autoritativos relacionados.
• A stack tem um modelo claro de armazenamento persistente, em vez de depender do sistema de ficheiros transitório do contentor.

Quando uma base de dados externa se justifica

Utilize uma base de dados operada separadamente quando existir um requisito concreto, e não apenas uma preferência pela separação. Razões válidas incluem a arquitetura documentada de uma aplicação, uma equipa de bases de dados existente com responsabilidade clara e procedimentos de recuperação, ou uma necessidade real de várias cargas de trabalho aprovadas utilizarem um serviço de base de dados partilhado.

Um serviço partilhado não deve tornar-se um depósito casual para aplicações não relacionadas. Cada carga de trabalho continua a precisar de funções de base de dados definidas, limites de acesso, coordenação de manutenção e uma decisão de recuperação. Partilhar um motor ou cluster não elimina a necessidade de isolar credenciais e decidir quem pode fazer alterações.

Uma plataforma especializada de bases de dados ou uma equipa interna de infraestrutura pode ser a melhor opção quando a organização já possui as competências, os controlos e o modelo de serviço para a operar. Essa equipa deve conseguir indicar quem gere o acesso, as atualizações, a verificação de cópias de segurança, o restauro, a capacidade e a resposta a incidentes. Se essas respostas não forem claras, mover a base de dados para outro local pode apenas deslocar trabalho sem responsável.

• O fornecedor da aplicação documenta uma base de dados externa como obrigatória ou suportada para a implementação pretendida.
• Uma equipa identificada é responsável pelas operações da base de dados e dispõe de um procedimento de recuperação testado.
• A conectividade de rede, a autenticação e a gestão da firewall têm responsáveis claros.
• A necessidade de um serviço partilhado é real, aprovada e compatível com o isolamento de acesso adequado.
• A manutenção da aplicação e da base de dados pode ser coordenada, incluindo migrações de esquema e atualizações de versões principais.

Não confunda separação com resiliência

Uma base de dados externa introduz outro limite de serviço. A aplicação passa a depender da acessibilidade da rede, da resolução de nomes de anfitrião, de regras de firewall e encaminhamento, de credenciais, de regras de autenticação, da configuração do listener da base de dados e do calendário de manutenção do serviço externo. Cada uma destas dependências precisa de um responsável e de um caminho de resposta a incidentes.

Especificamente no PostgreSQL, a exposição de ligações TCP/IP é controlada por definições como listen_addresses, enquanto os controlos de autenticação de clientes determinam quem se pode ligar. O PostgreSQL também utiliza funções para gestão de privilégios, e o utilizador ativo da base de dados determina o acesso aos objetos da base de dados. Estes são controlos úteis, mas têm de ser concebidos e mantidos deliberadamente.

A separação pode melhorar a arquitetura de uma organização quando corresponde a capacidades estabelecidas. Também pode acrescentar latência, mais coordenação de gestão de alterações e uma superfície de falha mais ampla. Avalie todo o percurso entre o processo da aplicação e a base de dados, não apenas o servidor da base de dados.

• A aplicação consegue resolver e alcançar o ponto de extremidade da base de dados nas condições de falha esperadas?
• Que percursos de rede e regras de firewall permitem a ligação?
• Que função de base de dados a aplicação utiliza e de que privilégios precisa efetivamente?
• Como são entregues, rodadas e revogadas as credenciais?
• Quem aprova manutenções que possam afetar a conectividade da aplicação ou a compatibilidade de esquema?
• O que acontece quando a base de dados está acessível, mas não está pronta, está sobrecarregada ou em recuperação?

Conceba a recuperação como um procedimento para o sistema completo

Uma cópia de segurança só é útil se conseguir restaurar o serviço para um ponto de recuperação acordado. Planeie a recuperação em todo o percurso dos dados: a base de dados, ficheiros carregados ou armazenamento de objetos, configuração da aplicação, segredos ou material de encriptação e a ordem correta de restauro. Um restauro bem-sucedido apenas da base de dados pode ainda deixar uma aplicação incapaz de localizar ficheiros, autenticar-se em serviços ou desencriptar dados protegidos.

No PostgreSQL, o planeamento de cópias de segurança exige uma escolha deliberada entre dumps lógicos, cópias de segurança ao nível do sistema de ficheiros e arquivamento contínuo. O PostgreSQL documenta estas abordagens como diferentes, com pontos fortes e fracos distintos. Um dump lógico criado com pg_dump produz comandos que recriam o estado da base de dados capturado quando o dump começou; não equivale a copiar simplesmente um volume de contentor.

Os objetivos de recuperação devem orientar a escolha técnica. Se o ponto de recuperação exigido requer restauração para um momento entre cópias de segurança agendadas, são necessárias capacidades que vão além dos dumps lógicos comuns. A recuperação para um ponto no tempo do PostgreSQL baseia-se numa cópia de segurança base mais arquivamento contínuo do registo de escrita antecipada; a saída de pg_dump e pg_dumpall não pode ser utilizada para reprodução do registo de escrita antecipada.

Teste os restauros num ambiente isolado. Registe o tempo de restauro, o ponto recuperado, as verificações de validação efetuadas, os passos manuais pendentes e quem autorizou o resultado. Considere a evidência de um teste de restauro mais valiosa do que uma suposição baseada no sucesso reportado por uma tarefa de cópia de segurança.

• Identifique a fonte autoritativa e o método de cópia de segurança para cada componente persistente.
• Defina objetivos de ponto de recuperação e de tempo de recuperação que a equipa consiga explicar e testar.
• Documente a ordem de restauro, incluindo bases de dados, ficheiros, configuração e segredos.
• Verifique as identidades, funções e permissões necessárias para restaurar a propriedade e os privilégios da base de dados.
• Execute testes periódicos de restauro e retenha os resultados.
• Confirme que a validação ao nível da aplicação é bem-sucedida após o restauro, e não apenas que o serviço de base de dados inicia.

Atribua responsabilidades antes do lançamento em produção

A arquitetura está incompleta até que as responsabilidades operacionais sejam atribuídas. Isto aplica-se igualmente a bases de dados integradas e externas. Uma base de dados pode estar tecnicamente acessível e, ainda assim, ser operacionalmente insegura porque ninguém é responsável pelo acesso privilegiado, crescimento do armazenamento, falhas de migração ou verificação de restauro.

Torne as responsabilidades explícitas num manual operacional simples ou num registo de responsabilidade pelo serviço. O objetivo não é burocracia. É garantir que uma migração falhada, uma credencial expirada, um volume em crescimento ou um pedido de recuperação tenha um caminho de resposta conhecido.

As atualizações de bases de dados merecem atenção especial. O PostgreSQL documenta métodos explícitos de atualização para versões principais, incluindo abordagens de dump e restauro. Uma cópia de segurança ao nível do sistema de ficheiros não substitui esse método documentado de atualização por dump e restauro. Coordene as versões de base de dados suportadas pela aplicação com o procedimento de atualização da base de dados antes de uma janela de manutenção.

• Quem aplica as atualizações da base de dados e da aplicação?
• Quem controla o acesso de administrador e as funções regulares da base de dados da aplicação?
• Quem roda as credenciais e atualiza em segurança a configuração da aplicação?
• Quem monitoriza a capacidade, as falhas de ligação e o crescimento do armazenamento?
• Quem aprova e executa migrações de esquema?
• Quem responde se uma migração falhar ou exigir reversão?
• Quem é responsável pelas cópias de segurança, testes de restauro e autorização da recuperação?
• Quem coordena atualizações de versões principais da base de dados com a compatibilidade da aplicação?