Uma Filosofia de Otimização Centrada no Usuário

Por Scott Stone

Ao planejar este blog, eu deliberei sobre o título muito mais do que qualquer um deveria deliberar sobre qualquer coisa. Mas eu sabia que o assunto que queria abordar abrangia uma série de ideias. Um nome descritivo era muito longo e um nome sucinto parecia muito vago. As votações foram fortemente a favor do nome sucinto, mas o descritivo tinha alguns defensores (incluindo eu). Então, eu nomeei duas vezes, como Dr. Fantástico ou: Como Aprendi a Parar de Me Preocupar e Amar a Bomba.

Pergunta de Curiosidade: Qual é a penúltima linha em Dr. Fantástico? (Resposta no final e está relacionada ao assunto. Não vale usar o Google para trapacear.)

Por que Centrado no Usuário?

Cada aplicação, cada sistema de entrega, cada peça de hardware ou software intermediário será, em última análise, julgada por quão bem atende às necessidades dos usuários finais. Você não pensaria que essa revelação deveria surpreender alguém, mas pode se surpreender com quantas vezes componentes individuais são ajustados ou otimizados com a suposição de que a soma dos componentes otimizados resulta em um todo otimizado.

É simplesmente mais fácil para as equipes se preocuparem apenas com os componentes que controlam e garantirem que têm um argumento firme de que qualquer problema deve estar claramente fora de sua área. Mas essa abordagem raramente funciona, porque usuários insatisfeitos culpam todos os associados, sem respeito à culpa relativa. Quando os negócios são impactados, as consequências também frequentemente são sentidas por todos.

Por que Colaborativo e Holístico?

Todos os elementos do stack de aplicações estão inextricavelmente relacionados entre si em como eles servem os usuários finais juntos. E, como o design ideal para cada componente considerado isoladamente pode ser contraproducente no pior dos casos e subótimo no melhor; uma abordagem holística para todos os componentes relacionados do stack de aplicações é necessária.

Como diferentes componentes do stack de aplicações são geralmente controlados e gerenciados por diferentes equipes ou até mesmo organizações, uma abordagem colaborativa é necessária para alcançar a otimização do todo.

Reativo versus Proativo

Essas palavras são usadas tanto na gestão de sistemas que quase se tornaram sem significado. Proativo é bom e Reativo é ruim; então todos precisamos ser mais proativos. Mas ser eficiente quando somos obrigados a ser reativos também é crítico, pois todas as contingências não podem ser eliminadas.

Tarefas reativas são mais individuais e exigem diagnóstico eficiente do problema, isolamento para um componente de causa raiz e rápida correção desse problema de causa raiz. Frequentemente nos referimos a estar preparados com sistemas que aumentam a eficiência e precisão desse processo dedutivo como sendo proativo em si. Detectar problemas antes que os usuários sejam impactados e corrigi-los é ser proativo na perspectiva dos usuários finais.

Mas nosso assunto aqui é o ajuste do stack de aplicações como um todo e isso claramente requer uma abordagem proativa. Proativo é metódico e consistente.

O Stack de Aplicações

Para esta discussão, estamos considerando especificamente aplicações de banco de dados com interfaces de linguagem de consulta estruturada (SQL) das aplicações para o banco de dados. Os usuários interagem diretamente com as aplicações que entregam algum serviço ou benefício para eles. As aplicações e bancos de dados rodam em recursos que podem estar em datacenters físicos, ambientes virtuais dentro desses datacenters, ou residindo em recursos de nuvem que podem estar em ambientes variáveis. Mas em todos os casos eles estarão consumindo recursos físicos “em algum lugar” de memória, CPU e largura de banda de E/S.

As equipes responsáveis por essas diferentes camadas do stack de aplicações variam de organização para organização. Muitas vezes, bancos de dados e aplicações são tratados por diferentes equipes, se não por empresas completamente diferentes. E os recursos que hospedam a parte da aplicação ou do banco de dados também podem diferir em ambientes de nuvem híbrida, com partes hospedadas localmente e outras partes na nuvem, ou hospedadas em diferentes ambientes de nuvem ou ambientes parcialmente virtuais.

Interdependência

Como referido anteriormente, a interdependência do stack de aplicações significa que a otimização de componentes isoladamente nunca levará ao desempenho ideal geral. Ajustar e otimizar um banco de dados para uma aplicação com desempenho ruim será necessariamente configurado incorretamente quando esses problemas de aplicação forem resolvidos. E como alguém pode possivelmente dimensionar os ambientes para essas aplicações e bancos de dados ineficientes e em mudança?

Culpar uns aos outros

Aqui é onde a maioria dos produtos de gestão e ajuste de desempenho há muito tempo faz as mesmas reivindicações de “eliminar o jogo de culpa”, mas o efeito real, no melhor dos casos, foi otimizar o jogo de culpa. Os objetivos são identificar as causas raízes dos problemas e também fornecer evidências quando seu componente específico deve ser considerado inocente.

Enquanto ganhar o jogo de culpa pode ser melhor do que perder o jogo de culpa, a solução ideal para todos seria colaborar verdadeiramente nos esforços de ajuste para que todos tenham alguma confiança. Se todas as equipes puderem trabalhar juntas em uma frente unificada, então todos podem ter razoável certeza de que o desempenho resultante é o melhor que pode ser alcançado.

Alguns Mitos sobre Desempenho

Antes de falarmos sobre qualquer abordagem de otimização e ajuste, quero desmascarar alguns mitos que ouvi repetidos frequentemente para racionalizar a não preocupação com o ajuste de desempenho.

“Memória é barata”

“Armazenamento é barato”

“Poder de processamento é barato”

Esses são geralmente ditos quando alguém quer apenas lançar poder bruto em um problema de desempenho de aplicação. Por que desperdiçar esforço otimizando o uso de recursos quando os recursos não são um problema?

Relativamente falando, em comparação com os preços do passado, todas essas afirmações podem ser verdadeiras. Mas qualquer pessoa que tenha que defender um orçamento de capital ou operações sabe que conseguir financiamento é outra história. E, à medida que os recursos ficaram mais baratos, a complexidade das aplicações aumentou, de modo que ainda temos os mesmos problemas de otimização.

Na verdade, o mantra da tecnologia da informação nas últimas décadas tem sido “Faça mais com menos” em vez de explorar recursos ‘baratos’ com ambientes superpotentes.

O ajuste é necessário.

Otimizar por Camadas

Além de encorajar a colaboração entre equipes, o tema unificador dessa abordagem é otimizar por camadas através do stack de aplicações.

A justificativa por trás dessa abordagem é otimizar uma camada de cada vez, mas em uma ordem que assegure que a otimização de outras camadas não desfaça os ganhos que você alcançou.

A abordagem desconectada de otimização por componente independentemente pode facilmente levar a um desagradável jogo de “whack-a-mole” de TI.

Equipes de banco de dados otimizam o desempenho contra uma aplicação mal projetada com declarações SQL mal ajustadas. Então, os recursos físicos são inadequados. Depois, a aplicação é melhorada de uma maneira que sobrecarrega o banco de dados ajustado para a aplicação de desempenho ruim anterior.

Como em qualquer outro cenário de diagnóstico, você quer mudar uma coisa de cada vez para saber quais mudanças levaram à melhoria.

O SQL da Aplicação Vem Primeiro

O SQL da aplicação representa a carga de trabalho no banco de dados. Portanto, antes de fazer qualquer mudança no banco de dados ou no ambiente de recursos, ele necessariamente deve ser otimizado primeiro.

O SQL da aplicação será limitado pela disponibilidade de recursos no próprio banco de dados. O I/O lógico da carga de trabalho do SQL pode ser artificialmente reduzido por contenção dentro do banco de dados por esperas de recursos ou filas. E isso pode fazer com que a utilização de recursos pareça mais favorável do que deveria ser.

Portanto, não podemos realmente usar o tempo de resposta ou o desempenho de I/O físico do SQL para fins de otimização.

A lógica da aplicação e o design do sistema podem certamente ajudar no desempenho do usuário, mas nosso objetivo principal aqui é otimizar a medida de I/O lógico, leituras e gravações lógicas, antes de tentar outras mudanças.

A carga total de trabalho é a preocupação aqui, então o SQL com pior desempenho não é necessariamente o melhor lugar para começar. Melhorias no SQL frequentemente executado podem resultar em uma melhoria total maior do que uma declaração “pior SQL” raramente chamada.

Ajustar a Instância do Banco de Dados para a Carga de Trabalho Ótima de SQL

Agora, podemos ajustar a instância do banco de dados com confiança para atender à carga lógica otimizada da aplicação. Definir alocações de memória, índices e distribuição de armazenamento para aumentar o desempenho agora faz sentido. É importante não depender dos recursos de auto-otimização do banco de dados. Embora essas capacidades automatizadas possam ser muito úteis, em alguns casos a auto-otimização pode causar problemas e pode precisar ser anulada dependendo da aplicação e do SQL.

Alocar Recursos

Somente após as camadas de aplicação e banco de dados do stack de aplicações terem sido otimizadas, você deve determinar os requisitos de recursos para o desempenho desejado para os usuários finais. Os esforços de otimização garantirão que nenhum dinheiro esteja sendo desperdiçado na aquisição de hardware ou taxas de uso da nuvem. E os requisitos adequados de processador, memória e armazenamento para a aplicação podem ser determinados para o desempenho desejado da aplicação e a carga de usuário projetada para a organização em questão.

Monitorar e Repetir

A fase final dessa abordagem de ajuste de aplicação de banco de dados centr

ada no usuário é a mesma que tem sido para a maioria das tarefas de DBA. Monitorar e repetir. As cargas de aplicação mudam e às vezes aumentam drasticamente com mudanças na empresa. A tecnologia muda e novos recursos mais eficientes podem entrar em operação, mudando a abordagem usada para uma aplicação particular.

O monitoramento contínuo é necessário, não apenas para capturar situações anômalas, mas para detectar tendências de mudança de desempenho. Mas o ajuste metódico de cada camada deve ser mantido à medida que é repetido.

As Ferramentas Certas para os Trabalhos Certos

Dependendo da estrutura da sua organização, uma equipe ou até mesmo uma pessoa pode estar realizando todas as tarefas de ajuste através do stack de aplicações. No entanto, na maioria dos casos, esse trabalho será distribuído entre várias equipes.

Embora uma única ferramenta multifuncional possa ser usada para ajudar em todas essas tarefas, certamente seria um exagero para certas equipes de desenvolvimento, por exemplo.

Ferramentas específicas para tarefas e equipes significam que desenvolvedores e DBAs podem se concentrar em suas tarefas dentro dessa colaboração com interfaces de usuário e capacidades apropriadas para essas tarefas.

Resposta da Pergunta de Curiosidade:

“Senhor, eu tenho um plano!”

Então o mundo explode.

Não espere até que o seu mundo esteja explodindo para implementar seu plano de otimização de desempenho de aplicação.