Mergulhos profundos ou investigando sistemas

Eu sempre gostei de investigar coisas, qualquer coisa. Quando criana queria saber como os brinquedos funcionavam, desmontava e montava os carrinhos, bicicletas, aparelhos de som, computadores... Vivia tentando entender as partes mecnicas, depois os circuitos e eventualmente os softwares. Cresci com isso, algo muito pessoal e sempre uma grande diverso para mim. Nem todas as pessoas curtem, inclusive talvez a exceo sejam as pessoas que gostam de entender tudo, ento no se sinta culpado ou mal por no gostar ou no querer fazer esse tipo de investigao; 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 to natural e divertido que s vezes esqueo que tambm trabalho!

Toda essa introduo para chegarmos no assunto que quero contar: uma investigao para otimizar custos na AWS. Mas no s sobre isso, uma tentativa minha de mostrar que investigar coisas no linear e no tem frmula mgica. 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 pea mgica que traduz as conexes que vem de uma rede privada para uma rede pblica (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 servio gerenciado, pagamos e a AWS resolve os problemas de escala, mantm o sistema atualizado, etc tambm d pra fazer direto numa EC2 mas no o objetivo aqui. Outra pea legal que a AWS fornece so os VPC Endpoints, que permite conectar servios de mltiplas contas sem integrar a rede ou conectar diretamente com servios da AWS (que no deixam de ser outras contas, s que gerenciadas pela prpria AWS).

A rede em questo s tinha NAT Gateway e nenhum VPC Endpoint, ento todos os servios da AWS que estavam em uso passavam pelo gateway para conseguir chegar na internet e no servio. 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 servios estavam em uso na conta: SQS, S3, SNS, EC2... talvez os servios mais comuns da AWS. Criei o VPC Endpoint para o SQS e magicamente o trfego da NAT Gateway despencou bateu aquele momento de pnico, ser que fiz algo to errado assim? Mas no, foi s olhar as mtricas do endpoint que o trfego estava todo l, ufa!

S isso j deu uma tima economia, mas no tava feliz e tinha sido fcil demais, zero aprendizados. Resolvi investigar um pouco mais, pra isso fui atrs de outro servio da AWS: VPC Flow Logs. Habilitando isso dentro de um VPC temos acesso a todas as conexes que existem na rede, de onde elas surgem, para onde vo, quando comearam, quantos bytes trafegaram em cada conexo. Uma ferramenta tima para investigar redes, porm pode ter um custo elevado dependendo da rede. Para evitar surpresas liguei o servio, coletei dados por alguns minutos e desliguei. Cada arquivo gerado tinha cerca de 10Mb, compactados, com algo em torno de 1 milho de entradas. Hora de trazer a ferramenta de anlise de dados (que sempre esqueo como usar, obrigado Google por me salvar): pandas.

Primeiro passo era carregar um tanto dos dados e olhar o formato deles, temos vrias colunas: IP de origem, IP de destino, porta de origem, instncia, servio da AWS, IP de origem do pacote. Todas as informaes necessrias para identificar os fluxos de dados. A documentao 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 no tinha interesse em saber de onde tinha vindo o pacote, s que ele tinha sado de um NAT Gateway e estava indo para a internet, ento 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 no tinha interesse. Mas ainda estava com um monte de IPs que no 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 no tive muito sucesso, s indicava que era uma mquina da AWS (isso eu j sabia, AWS dona do bloco 3.128.0.0/9).

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

Isso no me ajuda a descobrir qual o sistema, ento 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, no deveria passar mais pelo NAT Gateway. Fiz algo errado? o que est acontecendo? Muitas perguntas... mas tinha mais servios para identificar e usar host e curl manualmente no escala. Hora de escrever um cdigo³ 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 tambm tem outros servios da AWS. Vejo quais fazem sentido adicionar VPC Endpoints, crio eles e vou ser feliz na prxima tarefa? No consigo, preciso saber por que o SQS continua passando no Gateway. Antes disso dou uma olhada nos grficos e os VPC Endpoints novos fizeram sentido e vo 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 documentao da AWS: https://docs.aws.amazon.com/general/latest/gr/sqs-service.html e entendo o problema, temos aplicaes usando o endereo legado do servio. Uma chuva de perguntas passa pela minha cabea: Quais aplicaes? Onde elas esto? Quais linguagens? Ser que so sistemas legados que queremos desligar?

Primeiro passo investigar se temos algum repositrio com cdigo chamando direto esse endereo. Rpida pesquisa no sistema de versionamento e nada relevante, ento hora de fazer uma anlise mais profunda. Enquanto levantava a relao de servios acessados j tinha gerado uma lista de nome e IPs, ento s filtrei a lista e obtive todos os IPs que atendem queue.amazonaws.com; sim, so vrios, um servio da AWS com altssima disponibilidade. Agora posso filtrar os flows procurando os endereos de origem que chegam em algum dos IPs dessa lista, o que resultou numa pequena lista de IPs internos algo em torno de 25 endereos.

Filtro as instncias EC2 que temos rodando com essa lista de IPs internos, e surpresa, so todos ns de um cluster kubernetes. ", no vai ser to fcil encontrar a aplicao" 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 aplicaes e so muitas! Tento alguns filtros na linha de comando mesmo cat | cut | sort | unique -c, vejo alguns sistemas que rodam em todos os ns: coisas padro do kube, umas duas aplicaes grandes e uma lista enorme de aplicaes pequenas. Vou atrs do cdigo fonte das maiores aplicaes e nada fora do comum e nem usam SQS! Vou seguindo a lista, mas sem muita esperana de encontrar uma aplicao s. Um padro comea a surgir: muitas aplicaes so escritas em python, mas isso no me diz muito ainda. Nesse momento, quase desisto da investigao, verso do boto3 (biblioteca python para acesso aos servios da AWS) era relativamente nova em todos os projetos; nada com cara de sistemas legados e sem manuteno; parecia um beco sem sada, ento voltei atrs mas retive algumas informaes: "python", "endereos legados SQS".

Peguei as poucas informaes que tinha e voltei pro Google, mesmo sem esperanas 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 endereos antigos por causa de alguma incompatibilidade do python 2.6, que est h muitos anos descontinuado. Cheguei na soluo, no tem soluo! Mas no fiquei feliz com isso e fui olhar issues relacionadas, algumas duplicadas, outras com mais informaes 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 no precisava ter olhado para todas as aplicaes que estavam rodando mesmo que por amostragem como eu fiz, uma pesquisa mais certeira poderia ter resolvido meu problema de forma mais rpida. Mas como eu poderia ser mais certeiro se no 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 verso e que isso ajudaria na reduo de custos. Foi uma grande montanha russa, cheia de voltas, mas no final deu tudo certo. Em outros casos simplesmente no conseguimos achar a causa, seja por falta de tempo (ie. a causa raiz no vale o esforo da investigao) ou por falta de conhecimento do problema que estamos lidando. Sempre pea 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 solues para o problema.

1. https://aws.amazon.com/vpc/pricing/

2. https://aws.amazon.com/privatelink/pricing/

3. Parte do cdigo python utilizado na anlise https://gist.github.com/pedrokiefer/3e8f4103f1094de6018256e0088cf8d8