Arquitetura de Logging da TrueFoundry para Gateway de IA

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Introdução: O Custo Oculto da Análise de Dados
Todo Gateway de IA no mercado oferece logs e análises. À primeira vista, parecem um recurso padrão. Mas as escolhas arquitetônicas feitas nos bastidores têm consequências enormes e ocultas para sua confiabilidade, segurança e resultado final. O como é um detalhe crítico que separa uma plataforma verdadeiramente de nível empresarial de uma proposta arriscada.
Quando começamos a fornecer aos nossos clientes análises rápidas e escaláveis, enfrentamos este exato desafio. O objetivo era claro: entregar insights poderosos através da nossa camada de gateway de IA sem criar um pesadelo operacional para as equipes de plataforma dos nossos clientes.
Percebemos desde cedo que, para construir uma solução digna dos nossos clientes empresariais, tínhamos que inovar além da abordagem padrão da indústria. Esta publicação detalha nossa jornada do poderoso, mas problemático, ClickHouse para uma arquitetura nativa de S3 e sem manutenção, um sistema que oferece aos nossos clientes uma vantagem competitiva poderosa e duradoura.
O Problema: Por que implantar ClickHouse é um negócio arriscado
Nossa escolha inicial, como muitas outras na indústria, foi o ClickHouse. É uma peça fenomenal de tecnologia de código aberto, reconhecida por sua incrível velocidade em consultas analíticas. No entanto, seu poder vem com um alto custo operacional.
O problema central é este: gerenciar um banco de dados com estado, de missão crítica, como o ClickHouse dentro do ambiente de nuvem de um cliente é um campo minado operacional. Para fazer isso corretamente, você precisa gerenciar:
- Alta Disponibilidade (HA): O que acontece se o ClickHouse cair? Você tem um plano de failover contínuo?
- Recuperação de Desastres (DR): Você está realizando backups regulares e verificados? Qual é o objetivo de tempo de recuperação (RTO) se algo der catastróficamente errado?
- Manutenção: Quem é responsável por atualizações de versão, aplicação de patches de segurança e otimização de desempenho?
Isso não é apenas teórico. Um comando simples e equivocado de kubectl delete pv poderia acidentalmente apagar o volume persistente de um cliente, apagando para sempre todos os seus logs históricos e dados de métricas. Para qualquer empresa, este nível de risco é simplesmente inaceitável. Estávamos efetivamente nos tornando um provedor gerenciado de ClickHouse, o que nos desviava da nossa missão principal.
Analisamos o cenário dos concorrentes
Pesquisamos e descobrimos que a maioria das plataformas no espaço de LLM Gateway optou por uma de três soluções de compromisso falhas.
- A Abordagem "Caixa Preta": Eles resolvem o problema de gerenciamento executando um banco de dados ClickHouse em seu próprio serviço de nuvem.
O Compromisso: Os clientes perdem a soberania dos dados. Para usar a plataforma, você é forçado a enviar seus dados de log/métricas — que podem conter Informações de Identificação Pessoal (PII) ou informações comerciais proprietárias — para fora do seu ambiente de nuvem seguro. Ao conversar com clientes corporativos, percebemos que era de suma importância que seus dados estivessem seguros e permanecessem dentro de seu ambiente de nuvem ou isolado (air-gapped), e não dentro do plano de controle do gateway de IA.
- A Abordagem "Faça Você Mesmo": Algumas plataformas fornecem um Helm chart ou um modelo e tornam o cliente totalmente responsável por executar sua própria instância do ClickHouse.
O Compromisso: Todo o complexo ônus operacional é transferido diretamente para a equipe de plataforma do cliente, que já está ocupada. Eles são deixados para descobrir a alta disponibilidade, backups e manutenção por conta própria.
- A Abordagem de "Escala Limitada": Isso implica em usar um banco de dados transacional padrão (como o Postgres) que não escala para cargas de trabalho analíticas exigentes, ou depender de uma rede confusa de exportadores de terceiros.
O Compromisso: Isso resulta em desempenho persistentemente fraco, uma experiência de usuário fragmentada e uma incapacidade de fornecer insights profundos e integrados.
Rejeitamos todas as três. Precisava haver uma forma de oferecer desempenho, segurança, e nenhuma carga operacional. Então, nós o criamos.
Nossa Arquitetura
Nosso princípio orientador era simples, mas poderoso: desacoplar armazenamento e computação. Os dados devem residir de forma segura e durável no próprio armazenamento de objetos do cliente (como o S3), enquanto um motor sem estado e escalável processa as consultas.

A Camada de Armazenamento: Seu S3 + Delta Lake
Eliminamos completamente o servidor de banco de dados e tornamos o bucket S3 do cliente a fonte da verdade.
- Por que S3? Ele resolve instantaneamente os problemas de HA, DR e backup. AWS, GCP e Azure investiram bilhões para tornar seus serviços de armazenamento de objetos incrivelmente duráveis e disponíveis. Seus dados são automaticamente protegidos dentro do seu próprio ambiente.
- Por que Delta Lake? Este é o nosso molho secreto de engenharia. S3 é apenas um armazenamento de chave-valor; ele não entende inerentemente transações de banco de dados. É aqui que o Delta Lake entra. É um framework de armazenamento de código aberto que traz transações ACID (a atomicidade e consistência de um banco de dados tradicional) para o seu data lake S3. É a "mágica" que permite ao ingestor gravar dados concorrentemente sem corrupção.
- Por que o formato Parquet? Todos os dados são armazenados no formato Apache Parquet, um formato de armazenamento colunar altamente eficiente, que é o padrão da indústria para análise de dados. Isso garante que você realmente possua e possa acessar seus dados com qualquer ferramenta que desejar — seja Spark, DuckDB ou a biblioteca Polars. Isso elimina completamente o vendor lock-in.
O Motor de Consulta: DataFusion da Apache
Usamos DataFusion, um motor de consulta do projeto Apache. É um motor moderno e sem estado que lê ficheiros Parquet diretamente do S3. Para superar a latência de rede inerente do S3, construímos uma sofisticada camada de cache multinível (em memória e em disco) que mantém os dados "quentes" prontos para consulta, proporcionando uma experiência de UI rápida e responsiva.
Quais são as vantagens
A nossa arquitetura traduz-se em valor claro e convincente que impacta diretamente o seu negócio.
- Custo Operacional Zero: Nunca terá de se preocupar em gerir, aplicar patches, escalar ou fazer backup de uma base de dados para os seus registos e métricas. Simplesmente funciona, poupando inúmeras horas à sua equipa de plataforma.
- Soberania Completa dos Dados: Os seus registos e métricas nunca saem da sua conta na cloud. Você mantém total propriedade e controlo, satisfazendo os mais rigorosos requisitos de segurança e conformidade empresariais.
- Menor Custo Total de Propriedade (TCO): O armazenamento S3 é dramaticamente mais barato do que os SSDs provisionados necessários para uma base de dados de alto desempenho. A nossa pegada de computação sem estado e otimizada reduz ainda mais a sua fatura da cloud.
- Observabilidade Inigualável e Padrões Abertos: Construímos o nosso pipeline de ingestão com base no OpenTelemetry (OTel) padrão. Isso permite-nos fornecer insights incrivelmente granulares ao nível do rastreamento — como ver a latência exata de uma verificação de Guardrail versus a própria chamada LLM. Também lhe dá a liberdade de encaminhar estes dados padronizados para qualquer outra plataforma de observabilidade, como o Datadog, com facilidade.

Elevando o Nível da Observabilidade Empresarial com o AI Gateway da TrueFoundry
A jornada para fornecer análises prontas para empresas com o nosso AI Gateway foi repleta de atalhos tentadores e compromissos fáceis. Enfrentámos um desafio operacional crítico, rejeitámos as soluções padrão da indústria e projetámos uma arquitetura superior a partir dos princípios básicos. Pronto para ver como é um Gateway de IA verdadeiramente sem manutenção, seguro e com latência sub-ms? Agende uma demonstração conosco hoje.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI

















.webp)






.webp)

.webp)
.webp)





.png)



