Migre para o Amazon RDS for Oracle com otimização de custos

Por Nathan Fuzi, Principal Arquiteto de soluções especialista em Oracle na AWS

Ao migrar aplicação de banco de dados Oracle para a AWS, existem muitas oportunidades de modernizar e otimizar sua arquitetura. Essa migração oferece maior agilidade e flexibilidade, bem como o potencial de migrar para um serviço totalmente gerenciado, como o Amazon Relational Database Service (Amazon RDS) for Oracle. O RDS for Oracle oferece computação escalável, backups automatizados, notificações de eventos e muito mais. Também ajuda administradores de banco de dados e outras equipes de TI a reduzir os diversos aspectos tradicionais do gerenciamento da infraestrutura de banco de dados Oracle, permitindo que eles foquem sua atenção em aspectos da aplicação que agregam mais valor aos negócios. Nesta publicação, discutiremos várias de nossas etapas frequentemente recomendadas para otimizar os custos ao migrar e executar bancos de dados Oracle na AWS. A implementação dessas etapas requer conhecimento detalhado do banco de dados e da aplicação. Portanto, esta publicação é destinada a administradores de banco de dados (DBAs) e gerentes de DBAs.

A migração é uma ótima oportunidade para otimizar os custos estimando adequadamente os recursos de que a aplicação precisa, aproveitando a automação e os recursos da AWS não disponíveis nos data centers tradicionais e reavaliando a necessidade de soluções antigas e componentes de terceiros. Embora pegar as aplicações e trazê-las inalteradas para a AWS possa ser o caminho mais fácil para a nuvem, esse método envolve trazer todos os aspectos legados e de superprovisionamento de recursos da solução local. Analisar as necessidades reais do projeto de migração potencialmente permite que você evite migrar dados desnecessários, reduzir o tempo em que a aplicação ficará fora de operação em comparação com a implementação das alterações separadamente e economiza tempo combinando esforços nos testes. Você não precisa resolver tudo durante a migração, mas sim se concentrar nas mudanças com um claro retorno sobre o investimento (ROI). Você pode até descobrir que certas aplicações podem ser completamente removidas ou absorvidas em outro sistema.

Descontinue o que puder

A primeira sugestão é óbvia em um nível: afinal, não há maneira mais econômica de executar uma aplicação do que não executá-la. Vale a pena verificar se cada banco de dados e as aplicações que o usam ainda são relevantes quando você planejar sua migração. Pode ser que elas estejam em execução porque ninguém se deu ao trabalho de pará-las ou porque um sistema que já estava parado reiniciou sua execução após um incidente associado a um processo de recuperação desatualizado. Saiba o que você está migrando, quem são os principais usuários e o que o banco de dados sustenta antes de descontinuar ou migrar a aplicação.

É fácil descontinuar um banco de dados que está sendo executado no Amazon RDS for Oracle: por padrão, o serviço tira um snapshot da instância antes de excluí-la. Você pode restaurar um snapshot posteriormente se determinar que precisa acessar esses dados. O Amazon RDS permite que você atualize o snapshot se a versão principal estiver obsoleta nesse meio tempo

Examine o uso de recursos e questiona a necessidade da versão Enterprise em vez da versão Standard

Depois de identificar um banco de dados Oracle que você precisa migrar, examine os requisitos e os recursos de edição do banco de dados Oracle. Para obter mais informações sobre a Enterprise Edition (EE) e comparar com a Standard Edition (SE2), acesse Rethink Oracle Standard Edition 2 no Amazon RDS for Oracle.

A diferença de preço entre EE e SE2 é substancial. Se um aplicação não exigir os recursos ou complementos da versão EE, a migração para o SE2 pode eliminar as dependências da licença do EE e reduziros os custos de suporte, além de oferecer uma opção de execução no Amazon RDS for Oracle licença incluída (LI) ou em um banco de dados de código aberto. As instâncias de LI permitem que você pague conforme consome pelas licenças do banco de dados Oracle, bem como pela instância de computação, gerando potenciais economias adicionais e evitando a compra de licenças e contratos de longo prazo. O Amazon RDS for Oracle oferece replicação síncrona para uma segunda zona de disponibilidade e failover automatizado para as versões EE e SE2 com implantações em várias zonas de disponibilidade, oferecendo uma alternativa ao Oracle Data Guard ou à replicação de armazenamento autogerenciada. Discutimos maneiras de eliminar dependências de recursos como particionamento e métodos alternativos para gerenciar planos de SQL. Considere uma combinação do Amazon RDS Performance Insights e do Oracle Statspack para suas necessidades de análise de desempenho, em vez dos Oracle Diagnostics and Tuning Packs for Oracle Enterprise Manager, que são licenciados separadamente em cima da versão EE. O Amazon RDS for Oracle oferece suporte ao Oracle Transparent Data Encryption (TDE), que exige o licenciamento da opção Advanced Security, e o Amazon RDS para Oracle também fornece criptografia de armazenamento do Amazon RDS por meio de chaves do AWS Key Management Service (AWS KMS) de forma nativa.

Implemente ajustes razoáveis nas consultas da aplicação e na instância Oracle e defina uma base de desempenho antes da migração

O ajuste de uma aplicação reduz o consumo de recursos, seja no data center ou na nuvem, e recomendamos realizar análises e ajustes regulares das aplicações de banco de dados, especialmente antes da migração. Uma consulta com baixo desempenho afeta a experiência do usuário e também requer mais recursos para ser executada. Mais recursos consumidos — geralmente em vários aspectos das operações de computação, memória, capacidade de armazenamento e processamento e largura de banda da rede — significam custos mais altos que não agregam valor à aplicação e podem ser reduzidos ou eliminados. Certifique-se de estabelecer uma linha de base de desempenho do banco de dados antes da migração; isso ajudará você a determinar se problemas de desempenho estão relacionados à migração em si ou a aplicação. O Amazon RDS Performance Insights permite a captura do plano de execução de consultas Oracle para ajudar você a identificar mudanças durante a migração.

Examine o consumo recente de recursos para atender às necessidades atuais e selecione a classe e o tamanho apropriados da instância

Ao determinar os requisitos de recursos de uma aplicação de banco de dados, é extremamente importante entender o consumo atual de recursos e não simplesmente duplicar o consumo atual dos recursos alocados. Em um modelo de despesas de capital em que os servidores normalmente são renovados a cada poucos anos, os administradores geralmente têm sistemas superprovisionados para uso atual, em antecipação ao crescimento antes do próximo ciclo de renovação. Isso leva a uma baixa eficiência de custos, enquanto a aplicação não precisa desses recursos adicionais. No entanto, quando você executa sua aplicação no Amazon RDS for Oracle ou Oracle de forma autogerenciada no Amazon Elastic Compute Cloud (Amazon EC2), provisionar uma instância maior e disponibilizar mais recursos para o banco de dados envolve apenas alguns minutos de interrupção do serviço. Isso significa que é fácil responder rapidamente às mudanças na demanda da aplicação— tanto aumentos quanto reduções — em vez de adivinhar as necessidades futuras. Isso também permite que você se mantenha atualizado com o tipo mais recente de instância com novos chipsets e CPUs mais rápidas. Novos chipsets e velocidades de clock mais rápidas podem significar que menos núcleos de CPU são necessários para rodar uma determinada aplicação, potencialmente permitindo que você reduza o tamanho da instância e economize nos custos. A Oracle forneceu ferramentas como o Automatic Workload Repository (AWR, somente para a versão EE) e o Statspack (EE e SE2) para ajudar os administradores de banco de dados a avaliar os requisitos de desempenho e recursos. Criamos uma solução baseada nos dados do Oracle AWR para ajudar você a avaliar os requisitos de recursos em grande escala.

Lembre-se: quando você provisiona uma CPU para um banco de dados comercial, geralmente é necessário pagar o custo da licença do banco de dados, independentemente de a CPU ser utilizada ou não. Seu objetivo deve ser minimizar o consumo de CPU e, em seguida, provisionar somente o necessário para a aplicação, a fim de evitar custos desnecessários de infraestrutura e licenciamento. O Amazon RDS for Oracle oferece a próxima geração de classes de instâncias do EC2 com excelentes índices de custo/beneficio e também oferece instâncias com memória estendida com uma proporção de memória para vCPU de até 32:1 para dimensionamento adequado. Além disso, analise bancos de dados locais que foram superprovisionados com CPU e RAM para compensar o baixo desempenho do armazenamento. O Amazon RDS for Oracle oferece opções de armazenamento em blocos de alto desempenho e baixa latência com o Amazon Elastic Block Storage (Amazon EBS). Atribuir a quantidade e o tipo de armazenamento às necessidades do banco de dados pode ser mais barato a longo prazo do que alocar núcleos e RAM adicionais.

Considere também seus requisitos reais de desempenho para a aplicação, e não o desempenho atual. Assim como o provisionamento excessivo para o crescimento futuro, alocar mais recursos do que o necessário para atingir seus objetivos de desempenho significa potencialmente desperdiçar dinheiro em melhorias desnecessárias de desempenho. Determine qual desempenho sua aplicação precisa hoje e aloque recursos para alcançar esse desempenho, sem gastar mais para obter ganhos desnecessários.

Considere migrar objetos grandes e dados históricos para o armazenamento de objetos, como o Amazon S3

O armazenamento em blocos é mais caro do que o armazenamento de objetos. Muitas aplicações Serverless podem interagir diretamente com objetos no Amazon Simple Storage (Amazon S3), que é um armazenamento de objetos altamente disponível e extremamente durável. A substituição de objetos grandes (LOBs) por URLs do Amazon S3 pode reduzir drasticamente a capacidade total de armazenamento necessária para o banco de dados, movendo objetos para onde outros aplicação possam interagir com eles com mais facilidade e tornando o banco de dados menor e mais barato de operar. Além disso, alguns bancos de dados de código aberto interagem com os LOBs de forma diferente, o que significa que removê-los do banco de dados pode ser um passo em direção a uma eventual migração para um banco de dados de código aberto. Isso exigirá alterações na aplicação, mas pode valer a pena para bancos de dados em que a maioria dos dados está na forma de LOBs.

Você pode considerar uma abordagem semelhante para implementar o ciclo de vida dos dados, em que você exporta dados antigos de uma partição, um intervalo de tempo ou outras características de dados, armazenando os arquivos exportados no Amazon S3 e removendo-os do banco de dados. Caso os dados sejam necessários posteriormente, você pode importá-los de volta para o banco de dados primário ou criar uma instância de banco de dados separada para restaurar os dados históricos pelo tempo que for necessário e, em seguida, excluir essa instância quando ela não for mais necessária. O Oracle Data Pump pode exportar os dados, ou você pode usar o Oracle SQLcl ou um procedimento personalizado para exportar os dados diretamente em um documento separado por vírgula (CSV) que, quando armazenado no Amazon S3, pode ser acessado por outras ferramentas, como o Amazon EMR, para análise.

Determine os requisitos de alta disponibilidade e recuperação de desastres por aplicação e implemente soluções de forma granular

As aplicação essenciais para os negócios exigem alta disponibilidade (HA), e praticamente todas as aplicações precisam de um plano de recuperação de desastres (DR). Mas o Ponto Objetivo de Recuperação (RPOs) e os Objetivo do Tempo de Recuperação (RTOs) variam muito de acordo com a aplicação e o ambiente. Com uma arquitetura monolítica executando bancos de dados empacotados, cada núcleo deve ser licenciado para cada opção de banco de dados, independentemente de a opção ser necessária ou não. No Amazon RDS for Oracle, você pode ter cada banco de dados em sua própria instância, permitindo que você habilite recursos de HA, como implantações em várias zonas de disponibilidade e replicação com base no Oracle Data Guard em uma região da AWS ou até mesmo entre regiões com réplicas Oracle, isso de forma granular por instância. Isso permite otimizar a alocação de licenças e despesas para aplicações que realmente exigem esses recursos, enquanto aplicação com requisitos menos exigentes de RPO e RTO podem ser operadas com backups automatizados e até mesmo por backups automatizados entre regiões.

Consolide aplicações menores e relacionadas em um único banco de dados e separe aplicações maiores e não relacionadas em seus próprios bancos de dados

Empacotar bancos de dados ainda é uma prática muito comum: Um pequeno número de servidores físicos, com cada CPU licenciada para o software de banco de dados, e um grande número de pequenos bancos de dados implantados nesses servidores para máxima eficiência de custo de licenciamento. Isso resulta em um número menor de servidores e instalações de banco de dados para gerenciar, mas a desvantagem é que esse modelo apresenta opções reduzidas para manutenção de hardware, sistema operacional ou banco de dados sem afetar vários aspectos do negócio. Comprar um pequeno servidor para um banco de dados é arriscado — E se o banco de dados crescer além das capacidades do servidor? Na AWS, mudar a classe da instância com seus recursos é eficiente e reduz os riscos. As aplicações podem ser agrupadas ou separados de acordo com as necessidades da sua empresa. No cenário atual de microsserviços, faz sentido dividir as aplicações de acordo com suas necessidades individuais de dimensionamento e escala, janelas de manutenção personalizadas e soluções de recuperação de desastres adequadas aos requisitos individuais de RTP e RPO por aplicação. Recomendamos agrupar somente as aplicações que realmente façam sentido serem executadas juntos.

Considere um serviço de cache para solicitações frequentes de objetos

O uso de cache para bancos de dados relacionais com o Amazon ElastiCache é outra área em que um sistema específico pode ajudar a transferir a carga de executar consultas frequentes e solicitações de objetos em um sistema de alto desempenho, com tempos de resposta ainda menores para aplicações e reduzir a carga direta do banco de dados. Esse tipo de alteração exige alterações na aplicação, mas pode ajudar a melhorar os tempos de resposta da aplicação e reduzir a quantidade de infraestrutura alocada ao banco de dados.

Aproveite os serviços e recursos nativos da AWS

Depois de examinar minuciosamente os requisitos de cada aplicação de banco de dados, considere quais funcionalidades podem ser transferidas para um serviço gerenciado. Opcionalmente, o Amazon RDS for Oracle fornece criptografia de armazenamento em bloco para seu banco de dados, faz backup automático do banco de dados na região e pode ser configurado para fazer backup em outras regiões com apenas alguns cliques. Com backups automatizados, você pode realizar recuperação de um instante de tempo (PITR) em uma nova instância de banco de dados com alguns cliques ou uma única chamada de API. Você pode restaurar um ambiente de não produção a partir de um snapshot de produção em minutos. Você também pode usar réplicas para fornecer opções de DR e facilitar implantações blue-green. Várias opções estão disponíveis na AWS para melhorar suas operações em comparação com ambientes locais, fazendo com que elas funcionem mais rápido, com menos esforço e menor custo.

Desligue as instâncias quando elas não estiverem em uso para economizar nos custos da instância

Você pode desligar as instâncias EC2 e instâncias RDS for Oracle conforme necessário e economizar nos custos da instância (o armazenamento alocado ainda é cobrado) até precisar que eles estejam disponíveis novamente.  Você pode usar o AWS Instance Scheduler ou o AWS Lambda para iniciar uma instância no início do dia e desliga-la no final do dia, reduzindo significativamente os custos da instância para ambientes que não precisam de disponibilidade 24 horas por dia, 7 dias por semana.  Para obter mais informações sobre o uso de Lambda com o Amazon RDS, consulte Agendando o desligamento e inicialização do Amazon RDS com o AWS Lambda.  Também temos instâncias escaláveis para aplicação que têm picos ocasionais, e essas instâncias podem ser escaladas para absorver a carga adicional e oferecer maior eficiência de custos em comparação com a atribuição constante de instâncias maiores.

Repita essas melhores práticas

Assim como acontece com o ajuste de desempenho, a otimização de custos raramente é considerada completa. Como resultado, as aplicações mudam, seus requisitos de recursos e volumes de dados flutuam. Na ausência de processos completos do ciclo de vida dos dados, um banco de dados continuará crescendo com o tempo. Embora geralmente recomendemos monitorar o desempenho das aplicações e os requisitos de sistema, você também pode configurar alertas do Amazon CloudWatch para notificar os administradores do banco de dados quando o consumo de recursos ultrapassar os limites superiores ou inferiores, indicando que é hora de pensar em aumentar ou diminuir a escala. Você pode até mesmo configurar uma função Lambda para realizar uma operação de escalonamento quando o alarme for acionado.

Quando houver uma boa ideia dos requisites de sua instância, a compra de uma instância reservada pode reduzir substancialmente os custos operacionais do Amazon RDS for Oracle. Se você puder eliminar a dependência de recursos da versão EE e migrar para o SE2, você também pode considerar a opção de Licença Incluída (LI) para o Amazon RDS for Oracle. No modelo LI, você não precisa comprar licenças Oracle separadamente. A AWS fornece a licença para o software de banco de dados Oracle. Nesse modelo, se você tiver uma conta AWS com suporte técnico, entre em contato com o AWS Support para requerimentos tanto de Amazon RDS quanto de serviço de banco de dados Oracle.

Conclusão

Nesta publicação, analisamos as melhores práticas para otimizar os custos ao migrar bancos de dados Oracle para o Amazon RDS for Oracle. Como cada ambiente é único, algumas de nossas sugestões terão um impacto maior do que outras para seu caso específico.

Se você tiver dúvidas sobre como planejar sua migração ou implementar qualquer uma dessas sugestões, pedimos que você trabalhe com sua equipe de conta para localizar um parceiro de negócios da AWS ou envolver um especialista da AWS para trabalhar diretamente com você.

Este artigo foi traduzido do Blog de AWS en Inglês

Sobre o autor

Nathan Fuzi é o principal arquiteto de soluções especialista em Oracle na AWS. Ele é apresentador frequente na Semana de Modernização de Dados da AWS e no AWS Online Technical Talks. Nathan trabalha diretamente com os clientes da AWS para migrar, executar e otimizar seus aplicativos de banco de dados no Amazon RDS para Oracle. Com mais de 20 anos de experiência em bancos de dados, ele gosta de ajudar os clientes a criar soluções técnicas para resolver problemas de negócios.