Forem: Pedro Kiefer

Hacking My Own AWS Account: A Tale of Legacy Systems and Modern Solutions

Pedro Kiefer — Tue, 07 Jan 2025 21:00:03 +0000

In the shadowy world of cloud security, sometimes you have to break things to fix them. That's exactly what happened when our enterprise-grade AWS infrastructure hit a critical authentication wall. The culprit? A legacy SAML provider that was holding our KMS keys hostage.

The company I work for has navigated the turbulent waters of AWS for nearly a decade. Over the years, we've transitioned from AWS user accounts (a security faux pas) to a sleek SSO solution, which was later migrated and integrated with a new identity provider and SSO solution. The journey wasn't without its challenges, and our engineering and security teams worked tirelessly to remove all user accounts — a story for another day. This week, however, we faced a new conundrum: a team discovered they couldn't use a KMS key critical to some of our data systems.

Despite the hiccup, our systems continued to hum along, thanks to a role that still had access to kms:GenerateDataKey, kms:Decrypt, and kms:Encrypt. No data was lost, and we could decrypt and use the data. However, the role lacked permission to update the key policy (kms:PutKeyPolicy), effectively locking us out from assigning other roles to the key.

In a stroke of luck, we found another role from our previous SSO solution with full permissions on the KMS key. This revelation came only after opening a support ticket with AWS. The role was created by AWS IAM Identity Center, and that comes with the down side that the trust policy cannot be updated. AWS IAM Identity role have the following format: arn:aws:iam::123456789012:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_profilename_somehexdigest and the trust policy looks like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456789012:saml-provider/AWSSSO_somehexrandomnumbers_DO_NOT_DELETE"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "SAML:aud": "https://signin.aws.amazon.com/saml"
                }
            }
        }
    ]
}

Here's where it got interesting. The SAML provider was still there, pointing to a digital ghost — a server that no longer existed. Can we update that to another server that we can control? And the answer is yes, we can! We will hijack our own infrastructure by spinning up a new SAML provider. This is exactly the same technique used by black-hat hackers for gaining AWS persistence access on an account. You just need an IAM Role and a SAML Provider.

After a quick dive into the depths of the internet, we stumbled upon some straightforward, step-by-step guides on leveraging Keycloak, an open-source Identity and Access Management solution. This tool, running locally, would become the SAML provider we desperately needed.

This post laid out all the necessary steps for setting it up. We opted to run Keycloak inside a container, eliminating the need for extensive installation and configuration.

docker run -p 8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.0.7 start-dev

To log in to AWS, you need two specific SAML attributes, and it's crucial not to include any extraneous attributes that AWS can't process:

Session Name: This can be any random value, such as the username. The attribute name is https://aws.amazon.com/SAML/Attributes/RoleSessionName
Session Role: a list of roles that the user can assume. The attribute name is https://aws.amazon.com/SAML/Attributes/Role

The role must follow this format:

arn:aws:iam::<account-number>:role/<role-name>,arn:aws:iam::<account-number>:saml-provider/<provider-name>

Once Keycloak was set up, the next step was updating the IAM Identity Provider to use the generated metadata file. The new Issuer URL was something like http://localhost:8080/realms/aws, and the SSO Service location was updated to http://localhost:8080/realms/aws/protocol/saml. Running inside Docker in development mode meant no SSL was configured, which was acceptable for initializing the SAML flow.

By accessing http://localhost:8080/realms/aws/protocol/saml/clients/keycloak-sso and authenticating with the user we had previously created, we were seamlessly redirected to the AWS console, assuming the role we had lost access to. With the regained access, it was a straightforward task to update the KMS Key policy, add the new principal, and remove outdated role references from the policy.

Key takeaways from this experience:

Maintain a concise list of IAM Identity Providers, including only the necessary SAML providers.
Restrict access to updating and creating new Identity Providers.
Monitor changes to SAML providers.

The team gained invaluable insights from the experience, understanding the tactics hackers employ and the simplicity of executing certain maneuvers. We are eager to explore further opportunities to ethically test our systems for deeper learning.

To AB or not AB?

Pedro Kiefer — Tue, 05 Nov 2024 13:08:16 +0000

Outro dia me contaram sobre um teste AB que foi realizado num grande site e não melhorou a usabilidade do site. O teste trocava uma lista de cidades para selecionar uma por uma em uma caixa com autocomplete. As pessoas procuraram tudo menos cidades na caixa e o teste AB falhou. Isso me fez pensar sobre o quanto algumas decisões não fazem sentido de serem tomadas devido a média de quem acessa um produto.

Otimizar o texto de um botão, para conseguir mais cliques e aumentar as vendas, um ótimo AB, com métricas claras de sucesso e fácil de fazer. Agora decidir se a cor do site vai ser azul, roxa, lilás, vai da preferência de cada um, nunca teremos um consenso. E se tivermos, talvez não seja o que os responsáveis pelo produto queiram. Teremos a média da cor esperada para um determinado tipo de serviço. Mas não queremos que cor, design, arquitetura, arte, código, sejam definidos pela média. Às vezes, precisamos – às vezes, devemos ousar.

Apesar de todos termos um discurso forte sobre inovação, melhoria contínua, uso de dados para otimizar processos, se ficarmos olhando apenas para o que a média quer (e em processos estatísticos sempre haverá uma média) não faremos nada inovador, será mais do mesmo – o que todos, na média, dizem querer: ser iguais a tantos outros produtos. Ignorar um teste AB que não converteu, mas que sabemos que melhora a vida do usuário, é um jeito de inovarmos, de afirmarmos que queremos aquilo dessa forma.

Precisamos aprender a interpretar os dados, ler nas entrelinhas deles, decidir o que queremos – e aqui, muitas vezes é uma decisão individual sim, também pode ser de um pequeno time, mas nunca será um consenso entre a empresa inteira. Tomar decisões é difícil, em qualquer assunto, mas precisamos saber dizer sim para o que vemos valor e não para o que sabemos que não será proveitoso. Algumas pessoas não ficarão satisfeitas com nosso posicionamento e isso faz parte do viver em sociedade, não iremos agradar a todos.

Vamos continuar com nossos ABs, mas precisamos entender que eles falham e representam a média do nosso público. Diferentes públicos terão diferentes resultados para um mesmo teste. Temos que balancear os testes com nossa crença intrínseca de que aquilo irá funcionar melhor. Ousar para inovar.

Imagem de capa gerada por IA.

The Internet

Pedro Kiefer — Sun, 28 Apr 2024 16:49:09 +0000

No meu trabalho temos um programa de recompensas para pessoas que encontram problemas de segurança nos nossos sistemas. Isso é bom para a empresa porque em geral recebemos bons relatórios com os passos para reproduzirmos e a partir daí mantemos uma relação com o pesquisador até conseguirmos sanar o problema apontado. É um ótimo programa, tanto para melhorarmos os produtos da empresa quanto para aumentarmos o conhecimento dos diversos times sobre segurança — afinal, escalar segurança não é uma tarefa simples. Mas hoje não vamos falar de segurança, vamos falar sobre internet. E por que essa introdução? Bom, às vezes recebemos alguns relatórios que não são problemas de segurança, é simplesmente algo que faz parte de como a internet funciona. Como alguém confunde o funcionamento da internet com segurança? A tecnologia da informação tem tantas áreas e requer tanto conhecimento que é impossível alguém saber tudo, especialmente pessoas que estão começando, ou que mudaram de área.

A imagem da capa é uma piada da série IT Crowd, no capítulo em que o time de TI diz para a nova gestora, que não sabia nada de TI, que a internet era aquela caixa preta com uma luz vermelha piscando. Se algo acontecer com a caixa será uma catástrofe mundial. A série é ótima para quem é da área, rende muitas risadas. Se alguém pode acreditar que uma caixa que pisca é a internet então tentar entender melhor como a internet funciona pode ser um conhecimento útil.

O relato que me fez escrever este texto falava sobre um problema do nosso servidor contatar o servidor do cliente depois de fazer a inscrição no site. No fluxo de inscrição, logo após o cadastro de uma nova conta, enviamos um email de confirmação da criação dessa conta. Então essa conexão com o servidor deles faz parte e não é um problema de segurança. Para ser um problema de segurança seria algo mais na linha de acessar alguma página usando dados que foram enviados pelo cliente, permitindo um atacante controlar esse fluxo — mas isso não é assunto para esse artigo.

A internet é uma grande rede com diversos tipos de equipamentos, computadores, servidores, dispositivos móveis, etc. Todos falam a mesma língua entre si: IP (Internet Protocol!) — ok, não é uma língua, é um protocolo de comunicação, mas fiquem com a poesia de pensar que as máquinas conversam entre si. Como o IP exige que se decore diversos números para chegar a um determinado servidor e nós humanos não gostamos de decorar números (alguns sim, mas não é a regra), foi inventado outro sistema para nos ajudar nisso e podermos usar nomes: DNS (Domain Name System).

DNS é o sistema que nos permite decorar “google.com” ou “nytimes.com” ou “g1.globo.com” e não nos preocuparmos em saber que google pode ser 142.251.132.46 ou 142.251.129.142 ou … — sistemas grandes como o google podem responder por diversos IPs diferentes, impossível de decorar. O DNS resolve esse problema muito bem com diversos servidores espalhados pelo mundo, basta mandar uma pergunta para ele e receber de volta o IP correspondente. São diversos tipos de perguntas possíveis, uma delas é para descobrir qual o servidor de email de um determinado domínio. Sabendo qual o endereço do servidor de email podemos usar um outro protocolo em cima de IP para mandar uma mensagem — nossa confirmação da criação da conta.

O que um sistema de envio de email faz é basicamente descobrir qual o IP do servidor de destino, perguntando para o DNS essa informação, e depois é feita uma conexão entre os servidores e o email é transferido para o servidor de destino. Falando assim parece super simples e realmente o conceito é simples — depois foram adicionadas camadas de segurança, criptografia, assinaturas para garantir que só um servidor possa enviar email para um dado domínio, etc.

Outros sistemas que formam a internet são muito similares quando focamos no essencial, como por exemplo como a Web (http) funciona. O que acontece quando abrimos um navegador e digitamos www.amazon.com? Inclusive essa é uma pergunta muito usada em entrevistas, dá para responder de muitas formas, cada pessoa vai acabar focando no que sabe mais. Um desenvolvedor de navegador pode falar sobre como conexões são abertas, memórias que são alocadas, interações com o sistema operacional, bibliotecas para renderizar, etc. Um engenheiro de redes pode falar sobre roteadores, como as rotas são distribuídas e quão dinâmica uma rede é. Alguém que trabalhe com frontend pode falar sobre como o navegador exibe a página, como o estilo da página é interpretado, como os scripts são executados. Mas respondendo a pergunta de forma muito concisa e abstraindo que vivemos cercados de estilo, scripts e imagens:

O navegador descobre para qual IP o endereço digitado aponta. (Olha o DNS aparecendo aqui).
O navegador abre uma conexão para o IP na porta 80 (sim, estou ignorando criptografia).
Navegador manda alguns dados para o servidor (página, identificação do navegador, versão do protocolo, etc)
Servidor verifica o que foi recebido e procura se o arquivo existe. Se existir, manda o arquivo de volta. Caso contrário retorna erro.
Navegador recebe o arquivo e exibe na tela.

Simples, não? Claro que para realmente funcionar temos um mundo de outras coisas acontecendo. Milhares de detalhes estão escondidos e são, em geral, irrelevantes para a maioria das pessoas. Dependendo da curiosidade ou da necessidade do trabalho podemos explorar cada uma das partes. Mas é necessário termos os conceitos básicos de forma clara, pois a partir deles conseguimos entender o resto ou até mesmo criar novas tecnologias.

A internet é formada por várias caixinhas pretas que piscam, mas não é uma única que controla tudo. Pode-se dizer que os conceitos fundamentais são simples. A soma de muitos conceitos simples é que tornam o todo extremamente complexo. Isolando e removendo as partes não essenciais conseguimos entender muito melhor como qualquer coisa funciona, não só a internet.

Custos nas Nuvens

Pedro Kiefer — Mon, 24 Apr 2023 20:01:45 +0000

Como membro do time de segurança, parte do meu trabalho é criar e manter regras de conformidade na nuvem, que garantem um padrão mínimo de qualidade e segurança para os diversos serviços que uma nuvem oferece. Obviamente as regras não saem de graça e são um custo que os times de segurança acabam arcando com – entretanto essa é a forma mais fácil de escalar boas práticas de segurança no ambiente. Uma das formas de implementar essas regras é utilizando o serviço AWS Config, um serviço da AWS capaz de verificar, auditar e avaliar configurações e relacionamentos entre recursos na nuvem. Com o AWS Config pagamos por evento de configuração gerado e também pela execução das regras.

Outro dia, enquanto olhava os custos das contas, notei que o AWS Config era o segundo maior gasto de uma conta, logo abaixo dos custos de EC2 – o normal é encontrar custos de rede, EBS, S3, RDS nessa posição. Algo não estava certo e fui investigar o que estava causando esse comportamento, afinal uma conta de testes não deveria gastar mais em AWS Config do que uma conta de produção.

Depois de encontrar alguns textos sobre o assunto e alguns exemplos de query para utilizar no AWS Athena, comecei a investigação. O primeiro achado foi que gerávamos entre 28 e 36 mil itens de configuração por dia, em um ambiente muito pequeno e com baixo nível de mudanças – as maiores mudanças vêm da utilização de um agendador para ligar e desligar o sistema durante as horas de trabalho, que gera uma ótima economia de EC2 e RDS.

Escolhi um dia qualquer e olhei o agregado de eventos agrupados por tipo de evento que foi gerado. Outro espanto: o primeiro colocado eram alterações de subnet! O que estava alterando a rede tantas vezes em um dia? Na sequência tinham alterações em interfaces de rede e grupos de segurança, o que faz sentido se o primeiro colocado for alterações de subnet. Mais algumas conversas com colegas, outras queries rodadas e identificamos que a maioria das alterações vinham de uma subnet só. Para nossa sorte, essa subnet só tinha 12 EC2s rodando, o que permitiria até uma exploração manual olhando cada uma das 12 máquinas, mas não foi necessário. Uma das EC2s tinha o mesmo nome de um dos grupos de segurança que aparecia no topo da lista de eventos gerados por dia – uma ótima correlação!

Investigando a EC2 logo chegamos a conclusão que ela fazia parte de um grupo de autoscale, e olhando os eventos deste grupo vimos que havia uma falha sistemática na verificação da saúde da instância criada. Resumindo, o grupo de autoscale estava criando uma instância, tentava verificar a saúde, falhava, destruía a instância, criava uma nova… eternamente preso num ciclo de falhas. Em um ambiente sem AWS Config habilitado isso teria um custo mínimo associado ao valor da EC2, de um balanceador de carga ocioso e de armazenamento não utilizado. Mas, quando habilitamos o Config passou a gerar diversos itens de configuração, quase um ataque de amplificação de custos. Cada ligar / desligar de uma máquina, criar / destruir interfaces de rede, vincular / desvincular grupos de segurança, etc. geraram novos itens de configuração.

Com esse achado, resolvemos investigar os outros grupos de autoscale para ver se existia o mesmo comportamento errôneo e encontramos mais alguns. Fazendo os ajustes necessários, seja desligando o sistema que claramente não estava em uso pois falhava sempre ou resolvendo a saúde do sistema, o custo da conta caiu rapidamente.

Se os custos estão altos, ou fora de um padrão esperado, invista um tempo na investigação da causa, converse com os times que utilizam a conta, proponha novas arquiteturas e veja quais trocas são possíveis em cada sistema. Gerir custos na nuvem não é simples, requer um trabalho constante de todos – e não somente do time de FinOps. Não deixe os custos da nuvem ficarem nas nuvens.

Mergulhos profundos ou investigando sistemas

Pedro Kiefer — Tue, 10 Jan 2023 17:29:28 +0000

Eu sempre gostei de investigar coisas, qualquer coisa. Quando criança queria saber como os brinquedos funcionavam, desmontava e montava os carrinhos, bicicletas, aparelhos de som, computadores... Vivia tentando entender as partes mecânicas, depois os circuitos e eventualmente os softwares. Cresci com isso, algo muito pessoal e sempre uma grande diversão para mim. Nem todas as pessoas curtem, inclusive talvez a exceção sejam as pessoas que gostam de entender tudo, então não se sinta culpado ou mal por não gostar ou não querer fazer esse tipo de investigação; chame a pessoa que você conhece e sabe que gosta disso para te ajudar, vai ser um prazer para ela. Pra mim, fazer esse tipo de trabalho é tão natural e divertido que às vezes esqueço que também é trabalho!

Toda essa introdução para chegarmos no assunto que quero contar: uma investigação para otimizar custos na AWS. Mas não é só sobre isso, é uma tentativa minha de mostrar que investigar coisas não é linear e não tem fórmula mágica. Bom, vamos ao causo!

Temos uma conta na AWS que rodam alguns sistemas e o custo de NAT Gateway estava um tanto elevado. NAT Gateway é a peça mágica que traduz as conexões que vem de uma rede privada para uma rede pública (ie. a internet). Toda a rede privada tem isso, na sua casa é o roteador que faz esse papel, na AWS temos o NAT Gateway como serviço gerenciado, pagamos e a AWS resolve os problemas de escala, mantém o sistema atualizado, etc — também dá pra fazer direto numa EC2 mas não é o objetivo aqui. Outra peça legal que a AWS fornece são os VPC Endpoints, que permite conectar serviços de múltiplas contas sem integrar a rede ou conectar diretamente com serviços da AWS (que não deixam de ser outras contas, só que gerenciadas pela própria AWS).

A rede em questão só tinha NAT Gateway e nenhum VPC Endpoint, então todos os serviços da AWS que estavam em uso passavam pelo gateway para conseguir chegar na internet e no serviço. Funciona, mas tem um custo elevado perto do custo de um VPC Endpoint (0.045 usd / GB¹ contra 0.01 usd / GB² do VPC Endpoint). Investiguei rapidamente quais os serviços estavam em uso na conta: SQS, S3, SNS, EC2... talvez os serviços mais comuns da AWS. Criei o VPC Endpoint para o SQS e magicamente o tráfego da NAT Gateway despencou — bateu aquele momento de pânico, será que fiz algo tão errado assim? Mas não, foi só olhar as métricas do endpoint que o tráfego estava todo lá, ufa!

Só isso já deu uma ótima economia, mas não tava feliz e tinha sido fácil demais, zero aprendizados. Resolvi investigar um pouco mais, pra isso fui atrás de outro serviço da AWS: VPC Flow Logs. Habilitando isso dentro de um VPC temos acesso a todas as conexões que existem na rede, de onde elas surgem, para onde vão, quando começaram, quantos bytes trafegaram em cada conexão. Uma ferramenta ótima para investigar redes, porém pode ter um custo elevado dependendo da rede. Para evitar surpresas liguei o serviço, coletei dados por alguns minutos e desliguei. Cada arquivo gerado tinha cerca de 10Mb, compactados, com algo em torno de 1 milhão de entradas. Hora de trazer a ferramenta de análise de dados (que sempre esqueço como usar, obrigado Google por me salvar): pandas.

Primeiro passo era carregar um tanto dos dados e olhar o formato deles, temos várias colunas: IP de origem, IP de destino, porta de origem, instância, serviço da AWS, IP de origem do pacote. Todas as informações necessárias para identificar os fluxos de dados. A documentação da AWS tem alguns exemplos de fluxos e seus significados: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples.html, com isso já sabia qual seria o primeiro passo: como não tinha interesse em saber de onde tinha vindo o pacote, só que ele tinha saído de um NAT Gateway e estava indo para a internet, então filtrei os dados com o IP interno do gateway. Agora fiquei com bem menos linhas para trabalhar, mas ainda assim um volume grande para olhar manualmente.

Agrupei os IPs de destino, filtrei alguns que eu já conhecia e não tinha interesse. Mas ainda estava com um monte de IPs que não diziam muita coisa para mim. Duas ferramentas vieram a mente: curl e host. A primeira ferramenta faz chamadas HTTP e a segunda resolve DNS e DNS Reverso. Tentei a segunda ferramente primeiro e não tive muito sucesso, só indicava que era uma máquina da AWS (isso eu já sabia, AWS é dona do bloco 3.128.0.0/9).

host 3.239.232.234
234.232.239.3.in-addr.arpa domain name pointer ec2-3-239-232-234.compute-1.amazonaws.com.

Isso não me ajuda a descobrir qual o sistema, então vamos para o curl. Mas como HTTP vai me ajudar a identificar um IP? Bom, estamos em 2023, maioria dos sistemas tem um certificado e trabalham com HTTPS. No certicado sempre temos o nome comum que aquele sistema responde.

curl -v https://3.239.232.234
...
* Server certificate:
*  subject: CN=queue.amazonaws.com
...

Ótimo, agora eu sei que o IP 3.239.232.234 é o SQS. Opa! Como assim? Eu criei um VPC Endpoint para ele, não deveria passar mais pelo NAT Gateway. Fiz algo errado? o que está acontecendo? Muitas perguntas... mas tinha mais serviços para identificar e usar host e curl manualmente não escala. Hora de escrever um código³ que imite o funcionamento das ferramentas em python para passar a coluna do DataFrame e deixar trabalhando. Algumas tentativas depois tenho o que eu preciso, rodo em cima dos IPs de destino de tabela, agrupo pelo nome encontrado e tá lá em primeiro lugar o SQS, mas também tem outros serviços da AWS. Vejo quais fazem sentido adicionar VPC Endpoints, crio eles e vou ser feliz na próxima tarefa? Não consigo, preciso saber por que o SQS continua passando no Gateway. Antes disso dou uma olhada nos gráficos e os VPC Endpoints novos fizeram sentido e vão realmente diminuir os custos.

Posso voltar a tentar entender o que aconteceu com o SQS. Olho o nome queue.amazonaws.com e vejo que é diferente do sqs.<region>.amazonaws.com que estou acostumado a ver, olho a documentação da AWS: https://docs.aws.amazon.com/general/latest/gr/sqs-service.html e entendo o problema, temos aplicações usando o endereço legado do serviço. Uma chuva de perguntas passa pela minha cabeça: Quais aplicações? Onde elas estão? Quais linguagens? Será que são sistemas legados que queremos desligar?

Primeiro passo é investigar se temos algum repositório com código chamando direto esse endereço. Rápida pesquisa no sistema de versionamento e nada relevante, então hora de fazer uma análise mais profunda. Enquanto levantava a relação de serviços acessados já tinha gerado uma lista de nome e IPs, então só filtrei a lista e obtive todos os IPs que atendem queue.amazonaws.com; sim, são vários, é um serviço da AWS com altíssima disponibilidade. Agora posso filtrar os flows procurando os endereços de origem que chegam em algum dos IPs dessa lista, o que resultou numa pequena lista de IPs internos — algo em torno de 25 endereços.

Filtro as instâncias EC2 que temos rodando com essa lista de IPs internos, e surpresa, são todos nós de um cluster kubernetes. "É, não vai ser tão fácil encontrar a aplicação" penso eu enquanto procuro como listar os pods de um dado nó do cluster. Mais uma linha de comando gigante e obtenho a lista de aplicações e são muitas! Tento alguns filtros na linha de comando mesmo cat | cut | sort | unique -c, vejo alguns sistemas que rodam em todos os nós: coisas padrão do kube, umas duas aplicações grandes e uma lista enorme de aplicações pequenas. Vou atrás do código fonte das maiores aplicações e nada fora do comum e nem usam SQS! Vou seguindo a lista, mas sem muita esperança de encontrar uma aplicação só. Um padrão começa a surgir: muitas aplicações são escritas em python, mas isso não me diz muito ainda. Nesse momento, quase desisto da investigação, versão do boto3 (biblioteca python para acesso aos serviços da AWS) era relativamente nova em todos os projetos; nada com cara de sistemas legados e sem manutenção; parecia um beco sem saída, então voltei atrás mas retive algumas informações: "python", "endereços legados SQS".

Peguei as poucas informações que tinha e voltei pro Google, mesmo sem esperanças de achar algo. Eis que encontro uma issue no Github do botocore (biblioteca que faz o grosso das coisas para a boto3): https://github.com/boto/botocore/issues/1418 e tá ali o problema, reportado em 2018! A biblioteca gera e usa os endereços antigos por causa de alguma incompatibilidade do python 2.6, que está há muitos anos descontinuado. Cheguei na solução, não tem solução! Mas não fiquei feliz com isso e fui olhar issues relacionadas, algumas duplicadas, outras com mais informações e encontrei outra: https://github.com/boto/botocore/issues/2705 essa tinha um pull request de 1º de novembro e falava que o problema estava resolvido na botocore >= 1.29.0. Vou direto pro terminal, instalo a biblioteca e testo. Problema resolvido! Provavelmente eu não precisava ter olhado para todas as aplicações que estavam rodando — mesmo que por amostragem como eu fiz, uma pesquisa mais certeira poderia ter resolvido meu problema de forma mais rápida. Mas como eu poderia ser mais certeiro se não sabia o que estava procurando?

Depois de tantas idas e vindas, tudo o que me restava fazer era comunicar os times que as bibliotecas botocore e boto3 deveriam ser atualizadas para a última versão e que isso ajudaria na redução de custos. Foi uma grande montanha russa, cheia de voltas, mas no final deu tudo certo. Em outros casos simplesmente não conseguimos achar a causa, seja por falta de tempo (ie. a causa raiz não vale o esforço da investigação) ou por falta de conhecimento do problema que estamos lidando. Sempre peça ajuda! Um outro par de olhos (ou orelhas) ajudam muito. Às vezes só de explicar em qual parede chegamos e como chegamos lá já nos ajuda a pensarmos em outras soluções para o problema.

https://aws.amazon.com/vpc/pricing/ ↩
https://aws.amazon.com/privatelink/pricing/ ↩
Parte do código python utilizado na análise https://gist.github.com/pedrokiefer/3e8f4103f1094de6018256e0088cf8d8 ↩

Logging, o quê, quando e como?

Pedro Kiefer — Fri, 18 Mar 2022 20:32:31 +0000

"Vou logar tudo, ligar debug em produção" - quem nunca teve vontade de fazer isso? ou que já fez isso? Eu já fiz, me arrependi; me arrependi porque o sistema ficou muito mais lento, criando impacto nos usuários finais e o volume de logs foi tão grande que ficou impossível achar o que eu queria. Durante o desenvolvimento muitas vezes criamos diversas mensagens de log, elas ajudam muito a entender como o sistema está funcionando. Mas todos esses logs quando em produção fazem pouco sentido e só geram pressão no sistema de logs. Precisamos de mensagens de log que façam sentido numa investigação, por exemplo um stacktrace faz sentido ser logado, mas todos os If's que tomamos no meio do caminho não fazem.

Os logs tem que fazer sentido para o negócio também. Alguns logs podem ser em função de uma exigência legal. Outros para auditoria interna. Logue coisas que não façam sentido ter uma métrica, mas que são importantes para entender o que aconteceu na aplicação. Lembre-se: logs não substituem métricas, podem até auxiliar em alguns momentos quando estamos voando às cegas, mas adicione as métricas necessárias assim que possível.

Com leis em vigor como LGPD (Lei Geral de Proteção de Dados) no Brasil e GDPR (General Data Protection Regulation) na Europa, precisamos ter um cuidado extra com os dados que são logados. Um dos artigos da lei menciona o fato de um usuário poder pedir a remoção de seus dados pessoais dos sistemas que a empresa gerencia. Caso tenhamos logado esses dados, vamos ter que percorrer um enorme volume de logs para encontrar e remover os dados pessoais. Em geral, logs não devem ser alterados depois de escritos por requisitos jurídicos, portanto temos um grande problema do ponto de vista legal caso precisarmos alterar algum valor neles. Evite escrever qualquer dado pessoal em mensagens de log.

Dependendo da importância dos logs, eles podem (devem) inclusive ficar armazenados em infraestruturas diferentes, com acesso muito restrito, evitando ao máximo que eles sejam alterados.

Garanta que todos os sistemas adicionem e repassem um header de Request-Id. O seu sistema não trabalha sozinho, existem diversas peças de software envolvidas pare ele funcionar. Com um RequestId passando entre sistemas, fica fácil isolar na busca dos logs onde foi a falha. É um sistema de tracing bastante rudimentar, mas que dá muita informação para o caso de problemas. Se puderes, tente adicionar e instrumentar as aplicações para um sistema de tracing completo. Instrumentar é fundamental.

E o mais importante de tudo: SEMPRE leia os logs.

Mensagens de log

Outro aspecto importante é como escrever as mensagens de log. Quais informações são pertinentes e qual a ordem que devemos apresentá-las? Neste trabalho os autores exploram esses aspectos e propõe o seguinte modelo do que uma mensagem de log deve conter:

Quando?
Onde?
Severidade
O quê?
Por quê?
O quê irá acontecer?
Outro detalhes

Os três primeiros são metadados sobre o log: data, servidor, arquivo e linha de código, severidade. Os outros trazem informações concretas do que aconteceu. Os autores ainda definem quais campos são necessários dependendo da severidade.

Não precisamos seguir à risca o que diz o artigo, mas precisamos ter uma noção de que estruturar as mensagens em volta de um padrão torna mais fácil o nosso trabalho. Queremos as informações necessárias para uma boa investigação.

Formato de logs

Dê preferência para logs estruturados, isto é não logue texto puro, mas algo que o sistema de logging consiga entender e simplificar a busca. Em um log estruturado fica fácil definir campos customizados, dados que são de interesse do time na hora de realizar uma pesquisa. Usando o exemplo abaixo, temos os campos referentes ao comportamento do upstream claramente definidos no log estruturado. Na versão somente texto não temos todas essas informações.

Exemplo de log em formato de texto

173.234.238.142 - - [04/Oct/2021:17:18:35 +0000] "GET /?param=a HTTP/2.0" 200 5316 "https://mysite.com/?param=a" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36" "2.75"

Exemplo de log estruturado:

{
    "@timestamp": "2021-10-04T17:18:35+0000",
    "host": "nginx01.mysite.com",
    "remote_addr": "173.234.238.142",
    "vhost": "mysite.com",
    "request_method": "GET",
    "request_uri": "/?param=a",
    "server_protocol": "HTTP/2.0",
    "http_referer": "",
    "status": "200",
    "body_bytes_sent": "5316",
    "request_time": "2.75",
    "upstream_addr": "internal.mysite.cloud",
    "upstream_status": "200",
    "upstream_response_length": "5316",
    "upstream_response_time": "2.73",
    "upstream_cache_status": "MISS",
    "uri": "https://mysite.com/?param=a",
    "http_user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36",
    "http_x_forwarded_for": "mysite.com"
}

Sistemas de logs

Outro aspecto muito importante de logs é o sistema que faz o gerenciamento deles — faz a coleta, prepara os dados, armazena e disponibiliza para busca. Normalmente só olhamos para nossas aplicações e os logs que elas geram, mas entender o que está do outro lado nos ajuda a escrever logs melhores. Abaixo temos um desenho esquemático de como funcionam a maioria dos sistemas de logs. Vamos seguir o fluxo de um log, da aplicação até a busca que foi realizada.

As aplicações geram seus logs durante seu ciclo de vida. Estes logs podem ir diretamente para um sistema de ingestão ou podem ser escritos na saída padrão. Quando vão para a saída padrão tem mais uma peça no desenho que faz o envio para o sistema de ingestão. O sistema de ingestão vai fazer um pré-processamento dos logs, transformar texto em json e possivelmente ajustar a data de recebimento.

Para sistemas que geram uma quantidade massiva de logs, normalmente, temos uma fila, que serve de armazenamento temporário e não deixa saturar o sistema de indexação, evitando perdas de logs. Aqui podemos ver qual o impacto que uma aplicação gerando uma quantidade excessiva de logs pode ter em outras aplicações. Se tivermos uma aplicação com muitos logs e outra com poucos logs, a fila irá encher e ambas demorarão para chegar na indexação. Por isso o conselho de gerar uma quantidade menor de logs quando em produção.

Do outro lado da fila, temos um sistema de indexação que fará o processamento necessário no log para adicioná-lo a um índice. É nesse momento que um campo de data é reconhecido como tal e que todos os outros campos ganham significado¹ para que possamos realizar buscas. O log agora está dentro de um conjunto enorme de outros logs, todos devidamente identificados e preparados para pesquisas.

A pessoa desenvolvedora normalmente utiliza uma interface gráfica para fazer as buscas, limitando os logs para serem de uma só aplicação, no espaço de tempo de interesse, etc. A maioria dos sistemas têm uma linguagem de busca extremamente poderosa, permitindo acharmos a agulha no meio do palheiro. Esse sistema de query busca os dados que foram previamente indexados e retorna todas as linhas de log relacionadas. A sugestão de repassar um Request-Id entre as aplicações vem justamente para facilitar no momento de busca.

O principal sistema de logs open-source é a combinação de ElasticSearch, Logstash e Kibana, conhecido comumente por ELK. Seu funcionamento é bastante similar ao que acabei de descrever.

Liberdade poética, não estou falando de semântica. ↩

Segurança

Pedro Kiefer — Tue, 16 Nov 2021 12:21:32 +0000

Segurança é um dos temas mais em voga no momento, especialmente depois dos grandes ataques de ransomware que aconteceram no Brasil e no mundo. Segurança deve permear todos os passos do desenvolvimento de software e não ser uma camada que jogam por cima. Claro, em sistema legados talvez seja a única solução possível e mesmo assim será um cobertor curto — algum pedaço vai ficar desprotegido.

Quando estamos começando um projeto novo, devemos olhar para a segurança desde o princípio. Algumas escolhas simples podem fazer toda a diferença. Isso é parte do príncipio de shift left, isto é, trazer segurança para dentro dos times e deixar de ser uma responsabilidade de um time só de segurança.

Todos são responsáveis pela segurança — incluíndo as pessoas não técnicas, ou talvez especialmente elas. Imaginem se a portaria deixa entrar alguém que não deveria? De nada adianta dez camadas de segurança no software se qualquer um entra no prédio e tem acesso a rede local, ou se deixamos as senhas anotadas na mesa. Temos que balancear o nível paranóia com o bom senso. Nenhum dos extremos funciona bem.

Olhando para o compilado de vulnerabilidades feito pela OWASP temos um ótimo panorama de quais sãos os problemas mais comuns. A maioria é evitável simplesmente se prestarmos atenção e entendermos que vulnerabilidades existem. Por exemplo, ataques de injeção são conhecidos desde 1998 e praticamente todas as bibliotecas para acesso de banco de dados possuem funções que evitam esse tipo de ataque. Basta uma simples escolha para resolver uma classe inteira de problemas. Outros são um pouco mais complexos, mas nada de outro planeta. Com a ajuda de uma equipe de segurança qualquer time está apto a sanar todos.

Existem diversas ferramentas que prometem milagres, fazem análise de código, análise em tempo de execução, filtram requisições maliciosas, etc., mas o mais importante é ter uma cultura que entenda que segurança vem primeiro e faz parte da qualidade do software entregue. As ferramentas podem auxiliar, indicando onde devemos olhar, mas são só ferramentas. Um time com conhecimento vai sempre se sair melhor que ferramentas — especialmente se as ferramentas não forem totalmente compreendidas pelo time. Criar uma cultura é bem mais demorado, envolve treinamentos e participação de todos, mas os benefícios são incrivelmente maiores.

Código e Linguagens

Quando olhamos para segurança sob a ótica do código precisamos ter em mente que aquele software deve atender algum usuário. Se criarmos algo super seguro, mas de difícil uso, poucas pessoas irão usar ou encontrarão formas de burlar a burocracia da segurança — especialmente se forem desenvolvedores. Então é necessário encontrar um meio termo entre segurança e uso. Aceitar que o risco sempre existirá, mas estamos minimizando ele ao máximo. Todo o software é inseguro por natureza. O único software totalmente seguro é aquele que ainda não foi escrito — depois de escrito ele será inseguro, ou rodará num ambiente inseguro. Encontre o balanço de segurança / utilidade ideal para o contexto do negócio.

Nunca é demais repetir, mas valide todas as entradas — inclusive aqueles headers HTTP que parecem inofensivos.

Não deixe chaves de acesso, senhas, ou qualquer dado sensível no meio do código fonte ou configuração. Gerencie as senhas com um sistema próprio para isso. Tenha cuidado redobrado se o projeto for público, uma senha vazada pode ser a porta de entrada para diversos tipos de ataques.

As linguagens de programação evoluíram muito nos últimos 20 anos e surgiram algumas linguagens com modelos de memória mais seguros — Rust sendo o melhor exemplo. Escolher uma linguagem com um modelo de memória seguro dá diversos benefícios e barra muitos tipos de ataques. Um modelo de memória seguro é tão importante que diversos projetos opensource estão reescrevendo partes em Rust para justamente não terem mais problemas com o comportamento indefinido do C — a biblioteca de criptografia do python, ou mais recentemente o próprio kernel do linux. Go adicionou suporte nativo a fuzzing para justamente facilitar testes e aumentar a segurança das aplicações que adotam essa prática — fuzzing consiste em testar diversos tipos de dados para uma entrada qualquer, se o teste falha temos uma potencial falha de segurança ou somente um bug.

Criptografia

Use e abuse de soluções de criptografia, mas não tente inventar a sua. Todos os algoritmos envolvidos na geração de chaves criptográficas fortes são difícies de implementar. Um pequeno erro pode fazer que um gerador de números aleatórios vire uma máquina de repetição, um atacante facilmente criaria uma chave igual. Existem ótimas bibliotecas prontas e seguras para criptografia.

Use criptografia no trânsito de dados, mesmo que seja entre sistemas internos — a maioria dos protocolos já possuem uma versão com TLS. Garanta que os dados estejam cifrados quando em repouso, todos os sistemas operacionais e banco de dados como serviço suportam.

Infraestrutura

Uma das camadas fundamentais para um sistema seguro é a infraestrutura onde rodamos nossos sistemas. Se utilizamos um provedor de nuvem, eles garantem a segurança física dos servidores, mas cabe a nós garantir que o sistema está seguro. Assuma sempre que o ambiente está comprometido — mesmo não estando —, defina o mínimo de privilégios necessários para cada parte da infraestrutura. Não é simples aplicar esse tipo de pensamento em um ambiente já existente, então começe pequeno, garanta que novos sistemas já surjam com os acessos mínimos. Aqui estamos aplicando os princípios de Zero Trust.

Para quem trabalha mais com frontend, ou mobile, troquem nuvem por navegador ou dispositivo móvel. Os mesmos conceitos se aplicam e alguns casos de uso podem inclusive fazer parte das ferramentas de desenvolvimento.

Debugging; Deu ruim, e agora?

Pedro Kiefer — Fri, 12 Nov 2021 10:20:12 +0000

Debugar sistemas distribuídos não é uma tarefa simples. Uma das primeiras ferramentas que precisamos é um modelo mental de como o sistema se comporta (ou como desejamos que ele se comporte). Tente desenhar num esquema simples o fluxo das interações, onde chegam as requisições, quais bancos de dados estão envolvidos, quais subsistemas são consultados. Não precisa ser um modelo extremamente detalhado, mas um que fique fácil identificar as partes.

⚠️ Spoiler: Se você está com dificuldades de fazer um modelo, ou se a interações estão ficando extremamente complexas e acopladas, talvez seja um sinal de que está na hora de simplificar o sistema. Repensar subsistemas, agrupá-los quando possível, mantendo domínios de informações similares nesses grupos.

No modelo acima conseguimos facilmente ver as partes envolvidas sem entrar nos detalhes do que seriam os subsistemas. Será que temos OpenId Connect para autenticação? Será que é um ES com muitos nós atendendo a busca? Do nosso ponto de vista tanto faz, só precisamos entender que os sistemas existem e que podem ser eventuais pontos de falha — com sorte existem outros times cuidando dessas partes. Com o modelo em mãos, temos que ver se temos métricas que possam indicar falhas em qualquer uma das relações, depois verificamos se há logs interessantes ou, melhor ainda, se temos um sistema de tracing com instrumentação adequada. Agora, com sorte, já temos informações suficientes para fazer qualquer investigação no nosso sistema.

Começamos olhando as métricas e vendo se algo fugiu do padrão. Por exemplo, se o sistema de busca ficar lento, vamos notar latências aumentando no nosso sistema. Se o sistema de vídeos sair do ar, vamos encontrar erros 500 nas métricas e logs. Será que o nosso sistema saiu do ar por alguma dessas dependências? Se for uma dependência forte, temos que lidar adequadamente, retornar uma informação de erro para nossos usuários. Talvez possamos degradar a qualidade do serviço pelo período que o subsistema ficou fora do ar. Se fizermos isso, precisamos de uma métrica indicando quantas vezes estamos degradando a nossa qualidade — para eventualmente conversar com o time responsável e mostrar o impacto aos usuários.

⚠️ Métricas: leia o texto de métricas para uma discussão maior sobre o assunto.

Os logs terão informações mais detalhadas sobre o problema, um stacktrace pode permitir que você ache a linha exata onde o sistema quebrou. Correlacionando os logs de outros subsistemas ajudará a entender qual foi o dado que gerou o erro. Tente isolar ao máximo a fonte causadora do problema, isso vai tornar o processo de correção muito mais fácil pois você já terá um caso de uso para implementar um novo teste!

Não culpe a infraestrutura antes de verificar os logs e entender o que está acontecendo. Se é um problema de infraestrutura, provavelmente outras aplicações também serão afetadas, não somente a sua. Investigue e aprenda sobre as peças de infraestrutura, pergunte aos colegas sobre as escolhas que foram feitas e proponha outras caso a atual não atenda mais o produto.

Passada a turbulência do incidente é hora de reunir os times envolvidos e fazer um postmortem. Aqui não queremos só ver causa-efeito, mas queremos uma análise ampla e profunda do que gerou o problema. A partir disso conseguimos traçar ações de melhoria contínua, e não só resolver o problema pontualmente. Tente aplicar a técnica dos cinco porquês. Essa técnica consiste em ficar perguntando repetidas vezes "Por quê?", sempre tentando buscar a causa raiz, que pode não ser um problema de código, mas uma falta de conhecimento do time, ou um problema de comunicação entre times. Nos aprofundando na causa conseguimos crescer como time e evitar que uma classe de problemas similares se repita.

Deploy, release the kraken!

Pedro Kiefer — Tue, 09 Nov 2021 14:33:48 +0000

Chegou a hora de mandar para produção o trabalho dos últimos dias ou do dia! É só jogar para cima do time de operações e deu, né? Claro que não, é hora de vermos e ajustarmos uma esteira de entrega que atenda os requisitos do produto. É um trabalho em conjunto entre operação e desenvolvimento, ambos precisam conhecer sobre o sistema, a infraestrutura, a escalabilidade, o código. Essa troca de informações é essencial para um crescimento escalável do sistema.

Hoje em dia as opções de deploy são praticamente infinitas: kubernetes, diferentes PaaS, máquinas virtuais, docker, infraestrutura serverless, etc. Escolha a que tem melhor custo-benefício para o produto. Evite fazer escolhas da moda ou só por quê você quer aprender algo. Entenda os pontos de falha da infra escolhida – é impossível entender todos, mas saiba que eles existem e que vão eventualmente acontecer. Redes vão se particionar, pacotes vão se perder, DNS vai demorar para atualizar, VMs vão morrer, armazenamento será corrompido, configurações ficarão fora de sincronismo. O software e a esteira de entrega devem levar todos esses pontos em consideração.

Não faça deploys manualmente. Entenda manualmente como qualquer prática que dependa do ambiente local de desenvolvimento ou conhecimento que só existe na cabeça do desenvolvedor. Garanta uma esteira de entrega completa que permita reprodutibilidade do build e testes do sistema. Queremos evitar o clássico problema "funciona na minha máquina" então reprodutibilidade é uma peça chave de qualquer esteira de entrega.

Estratégias

Discuta e planeje estratégias de entrega do software, levando em conta pelo menos os seguintes pontos:

Os modelos de dados são compatíveis?
Como iremos atuar em caso de problemas?
É simples voltar para a versão anterior?
Temos uma linha base das métricas pra conseguir detectar anomalias?

Durante o desenvolvimento, pense nas alterações nos modelos de dados e modificações nas assinaturas de funções. A maioria dos sistemas atualmente são distribuídos e na maioria das estratégias de deploy as instâncias novas começam a trabalhar antes de desligarmos todas as antigas. Será que remover um atributo vai quebrar as units antigas? Se quebrar, como iremos voltar para a versão anterior em caso de falha? Tente manter a retrocompatibilidade dos modelos de dados. No caso de APIs que são consumidas por outros sistemas, não quebre o modelo até que todos consigam atualizar. Dê preferência para criar novas rotas com os modelos novos se a atualização for totalmente incompatível — isso acontece, é normal.

Defina um plano de ação simples, que todos no time saibam executar, para quando tivermos problemas não gastarmos tempo tentando lembrar aquele comando mágico ou a sequência correta de passos. Se possível, tenha um ambiente que permita exercitar essas ações. Um plano de ação simples é voltar para a versão anterior, basta garantir retrocompatibilidade nas alterações que fizermos ao sistema.

As métricas do sistema vão definir uma linha base do seu comportamento ao longo do tempo. Se familiarize com isso para entender melhor quando algo foge do padrão. As métricas vão fugir do padrão quando temos algum evento especial, por exemplo Black Friday ou a final de um campeonato. Elas também podem fugir da linha base quando subirmos uma alteração com problema, e às vezes só conseguimos ver um problema quando está em produção com uma carga bem mais alta do que no sistema de teste.

Existem diversas estratégias que ajudam nos pontos citados: blue-green, canary deployment, feature flags, rolling update, etc. Estude com o time qual faz mais sentido para o sistema. Particularmente, gosto muito de canários e feature flags. Abaixo irei exemplificar algumas dessas estratégias, são apenas esboços sem detalhes de implementação.

Blue-Green

Uma estratégia simples de deploy é usar Blue-Green, onde criamos em paralelo uma nova infraestrutura completa com a nova versão do sistema. Na figura acima estamos apontando os acessos para o lado green. No próximo deploy iremos recriar o lado blue, daí podemos testar a aplicação utilizando o endereço interno antes de trocarmos o apontamento do endereço principal. Caso tenhamos algum problema, basta voltar o apontamento para o lado green.

Normalmente as bases de dados são as mesmas para ambos os lados, então tome cuidado com migrações nos modelos de dados.

Prós:

Facilidade de voltar a aplicação

Contra:

Custo de manter duas infraestruturas em paralelo por um tempo. Em ambientes não cloud isso pode ter um custo considerável.

Rolling Update

As instâncias da aplicação vão sendo substituídas aos poucos, em um número fixo de instâncias por vez. Somente depois que as novas instâncias estão respondendo corretamente é feita a remoção das instâncias antigas. Na figura temos a instância A como sendo a nova, e a instância 1 marcada para remoção. É a estratégia padrão do Kubernetes.

Prós:

Resiliente caso a aplicação falhe

Contra:

Pode ser demorado para fazer um rollback

Canary Deployment

A ideia por trás de canários é subir uma aplicação que possa ser sacrificada caso tenha problemas. O nome vem justamente dos canários que os mineiros utilizavam no passado para indicar a qualidade do ar. Quando o canário para de cantar é porque o ar não está respirável e os mineiros devem sair daquele túnel. Aqui é a mesma coisa, colocamos uma pequena carga na nova versão da aplicação e olhamos o seu comportamento. Conforme temos confiança que o comportamento está dentro do esperado vamos aumentando a quantidade de instâncias e o volume servido. Em caso de problemas, basta tirar a nova versão do ar. Minimizamos qualquer tempo de indisponibilidade e sensação de problemas por parte dos usuários. Existem ferramentas que automatizam esse processo de deployment. O livro The Site Reliability Workbook tem um capítulo inteiro dedicado sobre a prática.

Para aplicações que processam dados, deve-se usar outras formas, mas o princípio é sempre o mesmo: olhar o comportamento das métricas e os resultados gerados e ir trocando de forma incremental as instâncias.

Um amigo gosta de dizer que a única forma de deploy deveria ser canários. A grande maioria dos problemas em sistemas poderiam ser evitados se canários fossem utilizados.

Prós:

Fácil de detectar problemas
Minimiza o impacto com os usuários

Contra:

Complexidade para criar o ambiente de deploy

Feature Flags

O princípio por trás de feature flags é permitir ligar ou desligar comportamentos do sistema de forma dinâmica. Podemos utilizar alguma das outras estratégias descritas para atualizar as instâncias, e depois controlamos quando vamos habilitar a funcionalidade. O controle pode ser só ligado ou desligado, ou ser probabilístico — 5% das execuções chamam a funcionalidade nova. Normalmente temos métricas associadas à flag para podermos acompanhar o comportamento novo. Também podemos usar esse sistema para controles dinâmicos, por exemplo: desligar um subsistema durante um momento de pico de acessos.

Prós:

Facilidade de uso

Contra:

Requer um sistema para gerenciar as flags

Métricas - the good, the bad, and the ugly

Pedro Kiefer — Sun, 07 Nov 2021 23:52:00 +0000

Métricas são a forma que você consegue observar o estado atual do sistema. Existem infinitas coisas para se medir num sistema, então o difícil é separar o que eu realmente devo medir das coisas que eu posso medir — lembrando que elas são a janela para um início de debug.

No livro de SRE do Google são citadas 4 métricas básicas (golden signals): latência, trâfego, erros e saturação. Em cada sistema, essas métricas são coisas distintas. O importante é pensar no que importa para os usuários: latência de 20s é ruim para servir uma página, mas pode ser ótima para o processamento de um vídeo.

Pense no seu sistema e no que importa para ele, meça isso. Adicione outras métricas para facilitar o debug e entender o comportamento: métricas de caches, métricas para acessos a outros sistemas, métricas de banco de dados, métricas de conexões. Evite usar essas métricas específicas para alertas, elas servem para o debug. A saúde do sistema deve ser vista nas quatro principais, crie alertas em cima delas.

Conheça as métricas de sua aplicação: como ela se comporta ao longo do dia; qual o pico de acessos que já serviu; qual o crescimento dos acessos/dos dados. Saber o comportamento padrão permite identificar de forma rápida um problema. Às vezes o desvio da linha base é pequeno, talvez não gere um alarme, mas pode despertar a curiosidade da pessoa que está acostumada a olhar aqueles valores.

Se você adicionar métricas demais pode acabar sobrecarregando a aplicação e gastar mais tempo de CPU com elas do que com o serviço em si.

Observabilidade tem que fazer parte da cultura dos times, assim como segurança e qualidade. A thread do tweet abaixo fala justamente sobre isso.

// Detect dark theme var iframe = document.getElementById('tweet-1448373809631817734-213'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1448373809631817734&theme=dark" }

The Good

Existem diversos tipos de sistemas, de métricas de aplicação à métricas de comportamento dos usuários. Cada um tem caraterísticas diferentes, volumes de dados diferentes, e muitos usos distintos (às vezes de uma mesma métrica), mas todos os sistemas podem ser classificados em duas grandes categorias: push ou pull. Isto é, alguns sistemas vão até as aplicações buscar métricas (pull), outros recebem a métrica (push).

Exemplo mais comum de sistema que utiliza pull: Prometheus
Exemplo mais comum de sistema que utiliza push: Newrelic, Datadog

Um sistema de métricas nada mais é do que um banco de dados com facilidade de gerar agregações temporais, afinal, queremos ver como as coisas se comportam ao longo do tempo. Um modelo mental bastante simples é o da figura abaixo, onde temos várias entradas para cada momento de tempo e dentro desta estrutura estão guardados metadados sobre a métrica (qual a instância, qual a rota, etc) e o valor que foi lido (ou recebido). Com isso podemos fazer agregações como "qual foi a taxa de requisições por minuto da rota '/'" e apresentar um gráfico com esses valores.

Cardinalidade merece um tópico à parte, mas vou tentar ser breve sobre. Cardinalidade fala da quantidade de variações que uma mesma métrica pode ter. Usando uma requisição http como exemplo podemos ter: rota, status, user agent, headers, hosts, etc. Cada termo pode receber diversos valores, alguns podem receber valores que não controlamos — isso dá margem para ataques de negação de serviço, não da aplicação que recebe as requisições mas do sistema de métricas. Se temos tantas variações, e fazemos a combinação (na real é o produto cartesiano) entre todas as variações possíveis temos uma cardinalidade enorme. Alguns sistemas de métrica não foram planejados para suportar isso. Portanto é necessário sempre saber se o sistema em questão atende aos requisitos de cardinalidade que a sua métrica precisa. Aqui vale resaltar que você também deve pensar se todas as variações são necessárias para a sua aplicação.

Alertas são essenciais em qualquer sistema de monitoração. É através deles que vamos mobilizar os times para atuarem. Como não queremos mobilizar pessoas por alarmes falsos, temos que entender porque um alerta está gerando falsos positivos, isto é, alarmando quando não deveria. Quando temos muitos falsos positivos temos a tendência de ignorar todos os alertas, pois assumimos que são sempre os mesmos, mas eventualmente será um alerta real que ficará esquecido por mais tempo do que deveria. Mais tempo com problemas, gera impacto com os usuários e definitivamente não queremos que o nosso sistema de alerta vire trending topics no Twitter.

O time precisa ter conhecimento de como medir e o que medir, afinal são as pessoas mais capazes de entender o que o sistema faz. Um time de observabilidade vai auxiliar mantendo o sistema de métricas e dando dicas de como utilizar as ferramentas. Em um time de frontend é bastante provável que a stack de observabilidade não atenda aos requisitos de volume de métricas e de cardinalidade, mas um sistema de injestão de métricas para Big Data consiga absorver sem problemas o volume necessário. Por isso, a necessidade do time saber o que quer medir e qual a finalidade dessa medição.

Para quem quiser se aprofundar em alertas recomendo fortemente o livro Site Reliability Engineering.

The Bad

Métricas geram muitas discussões e observabilidade é um campo de constante melhorias. Ficar atento ao que as empresas grandes estão fazendo e o que surge na comunidade é fundamental. Dito isso, é comum nos depararmos com as seguintes frases e vou dar meus 5 centavos sobre elas.

"Ah, mas aqui nós usamos o XPTO" — troque XPTO por Newrelic, Datadog, Prometheus, etc. As métricas não dependem do sistemas escolhido, entenda o que cada um desses sistemas oferece. Newrelic e Datadog oferecem instrumentação automágica, adicionam vários hooks em várias partes do teu software para conseguir medir. Verifique se as métricas realmente te atendem, não é por ser automágico que você terá as melhores métricas para o sistema.

"Adotamos o apdex para todas nossas apps" se todas as aplicações possuem um volume alto de acesso, ótimo. Apdex vai dar um cheiro do que está acontecendo. Mas aquela aplicação que recebe pouco tráfego vai estar sempre alarmando, ou aquela que demora para responder porque realmente está processando um grande volume de dados. Métricas são dos times e eles que vão saber o que importa, se for para normalizar algum métrica, normalize as quatro básicas e deixe os times definirem seus SLOs.

"Correlation does not imply causation" - Correlação não implica em causalidade. Leve isso para vida! Só por quê você viu uma métrica não infira que ela é a causa. Para fazer essa inferência levante mais dados, outras métricas, logs, etc. com tudo isso, crie uma hipótese da causa e teste! Sim, nós usamos o método científico para entender o que acontece nos sistemas.

The Ugly ou The good?

Se você gosta de matemática essa parte será The Good novamente, caso contrário provavelmente The Ugly. Mas vou tentar deixar da forma mais simples possível, afinal métricas são pura matemática e estatística. E aqui não quero dizer que é requisito saber muita matemática para trabalhar com TI, mas ter algumas noções básicas ajuda bastante.

Métricas precisam ser agregáveis, isto é, posso reuni-las dentro de uma janela de tempo e conseguir fazer operações matemáticas. Por exemplo, um contador de chamadas de uma rota HTTP é agregável, podemos somar todos os valores das diversas instâncias dentro de uma janela de tempo e dizer que atendemos 300 req/min.

Agora imagine que a aplicação entregue uma métrica que é o tempo médio de requisição dos últimos 30s. Dá para agregar essa métrica? Até dá e tu poderias ter uma média do tempo médio entre instâncias, mas não faz sentido tentar agregar o tempo máximo; afinal será o tempo máximo do tempo médio das requisições, não é um valor que tenha utilidade prática. Fazer média de médias é aceitável, inferir outras coisas em cima de médias começa a ser uma zona perigosa. Por isso, para tempos o ideal é utilizarmos histogramas, que são agregáveis e explicam melhor o que acontece com as requisições do que uma média.

Histogramas nada mais são do que diversos contadores, cada um responsável por um pequeno intervalo de tempo (ou do que você quiser, usei tempo por que é fácil de imaginar). Mas para entender um histograma vamos falar sobre probabilidade e estatística, começando com a curva normal, ou gaussiana, aquela que tem formato de um sino. Vou usar os exemplos como variáveis contínuas, ao invés das discretas que temos nos sistemas de métricas, só para ficar mais fácil de desenhar. Na imagem abaixo vemos a curva normal, com as marcas da média e dos desvios padrão. Ao lado temos alguns outros exemplos de distribuições que lembram uma curva normal — o tipo de análise que precisamos entender se aplica a toda a família de curvas.

O que precisamos entender como funciona, e levar para todas as métricas de latência, é que se só olharmos para a média provavelmente estamos errando feio. Nenhum sistema se comporta exatamente igual à uma gaussiana, então a média não vai estar ali no centro da figura, mas pode estar mais no início, ou final da curva. Para termos um entendimento comum entre todos, medimos a área que está abaixo da curva em alguns intervalos de interesse como 50% da área, ou 75%, ou 90%, 99%. O ponto onde termina essa área é o valor do percentil 50, percentil 75, percentil 90 e percentil 99.

E o que isso significa para a latência? Significa que quando pegamos a latência 90% de todas as requisições que o sistema recebeu, tivemos uma latência de 100ms. Só 10% dos usuários tiveram uma latência maior, o que é ótimo. Se quisermos ser mais exigentes podemos olhar o P99 onde vemos a latência que levou para atender 99% das requisições, isto é só 1% dos usuários pode ter sofrido com latências maiores do que o valor P99. Evite entrar na paranoia de querer garantir algo para 99,9999% das requisições, os custos para adicionar um 9 a mais vão se tornando proibitivos e não existe chegar a 100%.

Cachear ou não cachear, eis a questão

Pedro Kiefer — Mon, 25 Oct 2021 18:09:23 +0000

Você realmente precisa de um cache? A operação do sistema é tão demorada assim? Ou o problema são as dependências do sistema? Existem muitas justificativas para se usar um cache e com ele vem diversos benefícios e malefícios, então antes de dizer "Coloca um cache aí que resolve" analise a situação.

Benefícios

Entrega rápida para as consultas realizadas (milisegundos)
Diminui uso de CPU: por que recalcular a mesma coisa se posso servir o que já calculei.

Malefícios

Invalidação de cache
Invalidação de cache
Invalidação de cache
Arquitetura começa a ficar complexa

Sim, eu repeti "Invalidação de cache" três vezes, e poderia repetir mais umas vezes. Invalidar cache é difícil. Se eu invalido muito seguido, o cache deixa de ser efetivo. Se eu não invalido nunca, estou servindo dados ruins. Como isso depende do contexto do sistema não existe receita de bolo pra saber se o cache é bom ou ruim. Então o jeito é medir.

Se você tem um cache, você deve medir pelo menos a taxa de cache hit e cache miss. Se a taxa de cache miss for maior do que a de hits, então provavelmente esse cache não serve para muita coisa. Se o cache mistura diversos tipos de dados diferentes, meça por tipo de chave e não globalmente.

Básico

Talvez isso seja básico, mas não custa revisar. Na figura acima temos um cache com poucos objetos guardados. Cada objeto tem uma etiqueta A, B, C, e um tempo de vida ttl — nem todo o cache tem um ttl associado, por exemplo caches de cpu. Podemos recuperar um objeto de forma rápida utilizando a etiqueta adequada. Conforme a aplicação roda, outros objetos vão sendo adicionados até o momento em que o cache está cheio. E agora? o que e eu faço para adicionar outro objeto? E se o objeto for muito maior do que os outros?

Nesse momento o comportamento do cache vai depender da implementação, existem diversas formas de lidar com esse momento — a Wikipedia lista 19 políticas diferentes. Saber como a biblioteca ou sistema de cache vai funcionar nessas situação é extremamente importante, pode ser o diferencial entre um cache sendo bem utilizado de um que não serve para nada.

Ainda há outras classes de problemas se o cache for distribuído, como o modelo de consistência que o cache utiliza, ou o fato de que duas instâncias da aplicação tentem atualizar uma mesma chave. Não tenho a pretensão de tentar explicar isso, mas é importante saber que esses problemas existem. O livro Designing Data-Intensive Applications explica todos esses detalhes de uma forma muito clara. Vale a leitura para os que querem conhecer mais sobre dados em sistemas distribuídos.

Ter ideia desses conceitos facilita muito na hora de discutirmos estratégias e melhorias nos sistemas. Evitamos que uma melhoria na verdade tenha um impacto negativo por uma má escolha de cache.

Usando caches

Seu time já entendeu as vantagens, desvantagens, diferenças da arquitetura e é hora de usar um cache, mas não conversamos sobre os dados que vamos armazenar lá. Será que existe alguma relação entre dados e cache? Será que o ciclo de vida dos dados tem alguma relação com o cache? Quais os impactos ao produto se servimos um conteúdo antigo?

Diferentes tipos de dados têm requisitos de caches diferentes. Para dados com um ciclo de vida muito curto não faz sentido colocar um tempo de vida extremamente alto. Agora, se o dado só é alterado poucas vezes na semana, um tempo de vida de um dia pode ser interessante — caso exista um volume de acesso que justifique isso, obviamente. Aqui temos que levar em conta os requisitos do produto. Em um sistema de bolsa de valores, exibir um conteúdo antigo pode significar uma perda de muito dinheiro. Entender a dinâmica do conteúdo servido é importante, até para definir se é necessário um mecanismo (bom o suficiente) de invalidação de cache.

Numa página web, com baixa taxa de alterações no HTML servido, você quer cachear o máximo possível nos servidores de borda e nos navegadores dos clientes. Por máximo possível entende-se o maior tempo que não gere impacto negativo ao negócio — seja por uma falha encontrada, ou porque às alterações tem que ser vistas de forma mais rápida. O negócio vai dizer o que fazer. E aqui, obviamente, entram custos: menos cache na borda significam mais requests em todo o backend e mais tráfego nos subsistemas — o impacto pode ser brutal dependendo da arquitetura.

Onde fica o cache?

Podemos ter diversos tipos de cache: dentro da aplicação, num sistema separado, ou ainda remoto no browser ou aplicativos dos clientes. Os caches ainda podem ser persistidos ou em memória. São muitas escolhas e muitos sistemas usam mais de um tipo. Mas independente de onde vamos deixar o cache, temos que lembrar de qual será o comportamento do sistema quando o cache estiver zerado, isto é o que acontece quando temos um cold cache.

Uma aplicação que utiliza um cache em memória dentro de cada instância vai perder essas informações quando uma reiniciar, ou fizermos um novo deploy. Será que isso afetará o sistema? Bem provável que sim. Se for um impacto pequeno, dentro do esperado pelo negócio, estamos bem. Caso contrário devemos estudar um outro método, ou rever a necessidade desse cache. Outro aspecto que surge num cache em memória dentro da aplicação é o sincronismo de dados: todas as instâncias possuem o mesmo valor para um determinada chave? Qual a percepção do usuário se apresentarmos diferentes dados? Um cache rodando num sistema separado pode resolver esse problema.

Não há bala de prata

Caches não resolvem tudo.
São uma ótima ferramenta, ajudam bastante a melhorar o desempenho do sistema. Te levam até um certo patamar de escalabilidade — que pode estar bem além da sua escala atual. Para ultrapassar essa barreira temos que repensar os sistemas, o modelo de dados, o consumo desses dados, os algoritmos utilizados. Só pense nessa barreira quando a hora chegar, não crie um sistema mais complexo do que a sua escala atual.

Arquitetura Escalável

Pedro Kiefer — Wed, 20 Oct 2021 14:15:20 +0000

Atualmente todos falam em arquiteturas e software escaláveis: "it webscales!"; mas você realmente precisa de tudo isso no dia a dia? Seu sistema recebe 1M req/s para justificar complexidades e abstrações desnecessárias? Provavelmente a resposta é não. Então começe do básico, garanta ótima qualidade desde o príncipio e se um dia for necessário atender 1M req/s será muito mais fácil refatorar o sistema.

"Ah, mas eu preciso fazer micro serviços, porque todo mundo faz e isso escala!" Beleza, faça micro serviços mas não faça femto-serviços (minha definição para um serviço que é absurdamente pequeno; femto é 10^-15, enquanto micro é só 10^-6.). Um serviço de processamento de fotos não precisa ser 10 serviços diferentes com 10 filas separadas. Faça um serviço que englobe todo o processamento e escale esse serviço. Fica mais fácil de manter, dá para manter na cabeça todo o sistema, o deploy fica mais simples. "Ah, mas daí é um monólito", não, não é, só é um conjunto mínimo de funcionalidades reunidas em um local.

Se vocês tem muitos micro serviços para compor uma funcionalidade fica muito díficil coordernar uma atualização no payload usado entre os serviços. Será que todos vão entender a mensagem nova? Será que preciso atualizar tudo ao mesmo tempo? Se isso for necessário, agrupe tudo sob um sistema só.

Código

Abstraia e crie interfaces somente do que faz sentido no momento, não gaste tempo e energia criando uma arquitetura mega flexível que nunca será usada. Se o código estiver simples e bem testado fica simples refatorar para adicionar mais possibilidades.

Algumas linguagens em nome de "arquiteturas enterprise" ~~(algo para C-level achar bacana, eu acho?)~~ acabam criando diversos padrões de projeto que geram só níveis de indireção e abstrações que são pouco úteis para a entrega de valor.

Configurações

Evite juntar configurações do sistema com regras de negócio. Por exemplo, se você tem um sistema dinâmico para facilitar que outros times desenvolvam serviços em cima, deixe em arquivos separados as configurações que fazem o sistema funcionar e as configurações que são do negócio. O intuito aqui é diminuir os problemas em caso de uma configuração errada. Se temos um arquivo só e quebramos a configuração podemos tirar do ar todo o sistema. Quando separamos podemos continuar servindo conteúdo stale até arrumarmos a regra de negócio. Pense sempre em dois planos: controle e dados.

Versione todas as configurações do sistema - exceto senhas e dados sensíveis - junto com o código fonte. Configurações são tão importantes quanto o código. Evite alterar configurações manualmente, crie pipelines de entrega adequados para fazer as mudanças necessárias a partir do repositório.

Dependências

Evite dependências externas, especialmente as que você tem zero controle. Se você precisa usar serviços externos entenda do princípio que eles vão falhar e sua aplicação provavelmente não deveria falhar junto – claro, se for algo essencial da aplicação não dá para ficar sem. Mas um sistema de métricas ou de logging não deveria tirar a aplicação do ar. Nem um deploy em outro sistema deveria ter um impacto enorme na sua aplicação.

Use retentativas, circuit-breakers ou ainda service mesh, para facilitar a gestão das dependências. Se as aplicações estão muito acopladas, então não há benefícios de ter micro serviços e um grande monólito faria um trabalho muito melhor. Pense em micro serviços como peças que possam ser trocadas quando necessário — e talvez dê para continuar voando sem elas.

Exemplo

Para exercitar as ideias apresentadas vamos criar um caso de uso real: um sistema de vendas de ingressos para um cinema. O sistema consiste em usuários podendo escolher qual filme querem assistir, em qual dia e horário, e todo o fluxo de compra e emissão do ingresso. A arquitetura inicial é conforme a figura abaixo.

Essa arquitetura pode ser considerada um monólito. Uma única aplicação é responsável por todos os comportamentos do sistema: a autenticação dos usuários que desejam comprar ingressos, o sistema de pagamentos, a gestão de quais filmes estão sendo exibidos em quais salas, entre outras funcionalidades que desejarmos para um sistema como esse.

Você pode se perguntar: se isso é um monólito, como podemos afirmar que essa aplicação é escalável? Ninguém especificou qual o volume de acessos, quantas salas de cinema o sistema gerencia, nem quantos filmes diferentes estarão disponíveis e onde eles estarão.

Do ponto de vista de escalabilidade da aplicação, é perfeitamente aceitável começarmos com uma arquitetura dessas. No entanto, existe um pulo do gato para que o código não pareça um novelo de lã depois de um encontro com unhas afiadas: criarmos o sistema levando em conta os domínios necessários para seu funcionamento, garantindo que eles são independentes entre si e se comunicam atráves de interfaces bem definidas.

Nessa figura mostramos os domínios existentes, deixando claro o que está agrupado em cada um deles: autenticação, filmes, salas, ingressos, pagamentos. Se a arquitetura começa com uma boa separação de conceitos, fica fácil escalar. E, dependendo do contexto, essa arquitetura é a única necessária! Se formos pensar em uma cidade com poucos habitantes, que possui um único cinema com 4 salas que exibem apenas 4 filmes, temos quase certeza de que nunca teremos um volume de acessos maior do que esse sistema consegue aguentar.

No entanto, vamos exercitar nosso raciocínio para o outro lado. O sistema foi um sucesso, revolucionou a gestão de ingressos na cidade. A empresa, obviamente, quer estender o lucro e o sucesso obtido com o software. Para tanto, decidiu criar outro sistema para vender artigos relacionados a cinema.

De modo a facilitar o uso para os atuais usuários, resolveram ter uma solução única de autenticação. Como essa responsabilidade já estava totalmente separada na estrutura do código, bastou um refactor para tirar a gestão de usuários do sistema de ingressos e criar um sistema separado. Agora esse sistema pode atender os fluxos de venda de ingressos e de souveniers. Qualquer melhoria na gestão de usuários é propagada para todos os sistemas que o utilizam, e também conseguimos escalar só essa parte do sistema se precisarmos.

O sucesso foi estrondoso! A empresa continuou faturando e, logo em seguida, surgiu uma grande oportunidade de negócio: comprar outras salas na cidade vizinha. Além disso, em uma pesquisa de satisfação com os seus clientes, a empresa viu que a grande dor de seus usuários era uma falta de lugares marcados nos ingressos.

O sistema atual não dava conta - era preciso escalar melhor suas partes internas. Como os domínios não mudaram, basta uma reorganização e criação de novos subsistemas responsáveis por uma dada área. A gestão de ingressos ganha seu próprio subsistema, que escala independemente da gestão de salas e filmes. Lá também temos toda a lógica necessária para gerir a escolha de assentos, o tempo máximo de uma reserva, etc.

Podemos ver como o sistema cresceu, outra fontes de dados surgiram, pequenas partes tornaram-se escaláveis. O sistema está pronto? Provavelmente não, sempre haverá novas oportunidades de negócio: aumentar o alcance de cidades, incorporar a gestão de teatros; depende da evolução do negócio. Mas tendo os domínios bem separados, conseguimos escalar na medida certa para não gerar sistemas super complexos. Internamente alguns domínios podem ainda se desdobrar em mais partes, mas o ponto principal é conseguirmos ver a arquitetura como um todo. Qualquer pessoa consegue manter um modelo mental conforme a última figura.

"Ah, mas esse exemplo é todo de backend, não dá pra aplicar em front." É possível sim, basta imaginar que temos todo o código de front-end como uma Single Page Application (SPA). Ter uma SPA é perfeitamente aceitável e permite o compartilhamento de componentes entre páginas, poupando o retrabalho! No entanto, imagine que essa SPA faz o roteamento para todas as páginas e componentes da aplicação - autenticação, pagamentos, visualização dos filmes disponíveis, escolha de sala, entre outras.

À medida em que a necessidade do sistema vai evoluindo, o número de páginas, componentes e comportamentos complexos vai crescendo. O desempenho e agilidade da página ficam comprometidos; a experiência é degradada para o usuário, que fica esperando até que todo o programa seja executado pelo navegador. Podemos pensar em separar em partes a aplicação, só carregando o necessários conforme a necessidade. Se o usuário nunca entrar na parte de pagamentos, por que gastar tempo deixando ela disponível?

O mesmo conceito e ideia de micro serviços pode ser aplicado a micro frontends, que entregarão pequenos comportamentos ou componentes que serão adicionados apenas quando estritamente necessário para a página, melhorando o desempenho e a experiência do usuário. Esses componentes podem ter a atenção devida de UXs e desenvolvedores dedicados que cuidarão e melhorarão a experiência, o que faz com que todos ganhem - usuários e empresa.