TrueFoundry's Logging-architectuur voor AI Gateway

‍Introductie: De verborgen kosten van analytics

Elke AI Gateway op de markt biedt logs en analytics. Op het eerste gezicht lijken ze een standaard functionaliteit. Maar de architecturale keuzes die achter de schermen worden gemaakt, hebben enorme, verborgen consequenties voor je betrouwbaarheid, beveiliging en het eindresultaat. Het hoe is een cruciaal detail dat een echt enterprise-grade platform onderscheidt van een risicovol voorstel.

Toen we ons er voor het eerst toe zetten om onze klanten van snelle, schaalbare analytics te voorzien, stonden we voor precies deze uitdaging. Het doel was helder: krachtige inzichten leveren via onze AI Gateway-laag zonder een operationele nachtmerrie te creëren voor de platformteams van onze klanten.

We realiseerden ons al snel dat we, om een oplossing te bouwen die onze enterprise-klanten waardig is, verder moesten innoveren dan de industriestandaard aanpak. Deze blogpost beschrijft onze reis van het krachtige maar problematische ClickHouse naar een onderhoudsvrije, S3-native architectuur—een systeem dat onze klanten een krachtig en duurzaam concurrentievoordeel geeft.

Het probleem: Waarom het meeleveren van ClickHouse een risicovolle zaak is

Onze initiële keuze was, net als bij vele anderen in de sector, ClickHouse. Het is een fenomenaal stuk open-source technologie, bekend om zijn ongelooflijke snelheid bij analytische queries. De kracht ervan brengt echter hoge operationele kosten met zich mee.

Het kernprobleem is dit: het beheren van een stateful, missiekritieke database zoals ClickHouse binnen de cloudomgeving van een klant is een operationeel mijnenveld. Om het goed te doen, moet je het volgende afhandelen:

• Hoge Beschikbaarheid (HA): Wat gebeurt er als ClickHouse uitvalt? Heb je een naadloos failover-plan?
• Disaster Recovery (DR): Voer je regelmatig gecertificeerde backups uit? Wat is de recovery-time-objective (RTO) als er iets catastrofaal misgaat?
• Onderhoud: Wie is verantwoordelijk voor versie-upgrades, security patching en performance tuning?

Dit is niet alleen theoretisch. Een enkel, verkeerd kubectl delete pv commando zou per ongeluk het persistent volume van een klant kunnen wissen, waarmee al hun historische logs en metrics-data voorgoed verloren gaan. Voor elke enterprise is dit risiconiveau simpelweg onacceptabel. We werden in feite een beheerde ClickHouse-leverancier, wat afleidde van onze kernmissie.

We hebben gekeken naar het landschap van concurrenten

We hebben onderzoek gedaan en ontdekten dat de meeste platformen in de LLM Gateway-markt genoegen hebben genomen met een van de drie gebrekkige compromissen.

1. De "Black Box"-aanpak: Ze lossen het beheerprobleem op door een ClickHouse-database in hun eigen cloudservice te draaien.
   Het compromis: Klanten verliezen datasoevereiniteit. Om het platform te gebruiken, ben je verplicht om je logdata / metrics—die Personally Identifiable Information (PII) of intellectueel eigendom kunnen bevatten—buiten je beveiligde cloudomgeving te sturen. Tijdens gesprekken met enterprise-klanten kwamen we erachter dat het van het grootste belang is dat hun data veilig is en binnen hun eigen cloud of air-gapped omgeving blijft, en niet in het control plane van de AI Gateway.

2. De "DIY"-aanpak: Sommige platformen bieden een Helm chart of een template en maken de klant volledig verantwoordelijk voor het draaien van hun eigen ClickHouse-instance.
   Het compromis: De gehele, complexe operationele last wordt rechtstreeks verschoven naar het toch al drukke platformteam van de klant. Zij moeten zelf maar uitzoeken hoe ze de hoge beschikbaarheid, backups en het onderhoud regelen.

3. De "Beperkte Schaal"-aanpak: Dit omvat het gebruik van een standaard transactionele database (zoals Postgres) die niet kan schalen voor zware analytische workloads, of het vertrouwen op een rommelig netwerk van externe exporters.
   Het compromis: Dit leidt tot chronisch slechte prestaties, een gefragmenteerde gebruikerservaring en het onvermogen om diepgaande, geïntegreerde inzichten te bieden.

We hebben ze alle drie afgewezen. Er moest een manier zijn om prestaties, beveiliging én nul operationele last te leveren. Dus hebben we het gebouwd.

Onze Architectuur

Ons leidende principe was eenvoudig maar krachtig: scheid opslag en compute. De data moet veilig en duurzaam in de eigen object storage van de klant staan (zoals S3), terwijl een stateless, schaalbare engine de queries afhandelt.

De Opslaglaag: Jouw S3 + Delta Lake

We hebben de databaseserver volledig geëlimineerd en de S3 bucket van de klant de 'source of truth' gemaakt.

• Waarom S3? Het lost de HA-, DR- en backup-problemen direct op. AWS, GCP en Azure hebben miljarden geïnvesteerd om hun object storage-diensten ongelooflijk duurzaam en beschikbaar te maken. Je data is automatisch beschermd binnen je eigen omgeving.
• Waarom Delta Lake? Dit is onze geheime engineering-formule. S3 is slechts een key-value store; het begrijpt van nature geen databasetransacties. Dit is waar Delta Lake in beeld komt. Het is een open-source storage framework dat ACID-transacties (de atomiciteit en consistentie van een traditionele database) naar je S3 data lake brengt. Het is de "magie" die de ingestor in staat stelt om gelijktijdig data te schrijven zonder corruptie.
• Waarom het Parquet-formaat? Alle data wordt opgeslagen in het Apache Parquet-formaat, een zeer efficiënt, kolommengeoriënteerd opslagformaat dat de industriestandaard is voor analytics. Dit zorgt ervoor dat je echt eigenaar bent van je data en er toegang toe hebt met elke gewenste tool—of het nu Spark, DuckDB of de Polars-library is. Dit elimineert vendor lock-in volledig.

De Query Engine: Apache's DataFusion

We gebruiken DataFusion, een query engine van het Apache-project. Het is een moderne, stateless engine die Parquet-bestanden rechtstreeks vanuit S3 leest. Om de inherente netwerklatentie van S3 te overwinnen, hebben we een geavanceerde multi-level cachinglaag (in-memory en on-disk) gebouwd die 'hete' data gereedhoudt voor queries, wat een snelle en responsieve UI-ervaring oplevert.

Wat zijn de voordelen

Onze architectuur vertaalt zich in duidelijke, overtuigende waarde die direct invloed heeft op je organisatie.

• Nul Operationele Overhead: Je hoeft nooit meer na te denken over het beheren, patchen, schalen of maken van backups van een database voor je logs en metrics. Het werkt gewoon, wat je platformteam ontelbare uren bespaart.
• Volledige Datasoevereiniteit: Je logs en metrics verlaten nooit je cloudaccount. Je behoudt het volledige eigendom en de controle, wat voldoet aan de strengste enterprise beveiligings- en compliance-eisen.
• Lagere Total Cost of Ownership (TCO): S3-opslag is drastisch goedkoper dan de geprovisioneerde SSD's die nodig zijn voor een hoogwaardige database. Onze stateless, geoptimaliseerde compute-footprint verlaagt je cloudrekening nog verder.
• Ongeëvenaarde Observability & Open Standaarden: We hebben onze ingestie-pipeline gebouwd op de OpenTelemetry (OTel)-standaard. Hiermee kunnen we ongelooflijk gedetailleerde inzichten op trace-niveau bieden—zoals het zien van de exacte latentie van een Guardrail-check ten opzichte van de LLM-call zelf. Het geeft je ook de vrijheid om deze gestandaardiseerde data eenvoudig door te sturen naar elk ander observability-platform zoals Datadog.

De lat hoger leggen voor Enterprise Observability met TrueFoundry's AI Gateway

De reis om enterprise-ready analytics te bieden met onze AI Gateway zat vol met verleidelijke kortere wegen en gemakkelijke compromissen. We stonden voor een kritieke operationele uitdaging, wezen de standaardoplossingen in de markt af en ontwierpen vanaf de basis een superieure architectuur. Klaar om te zien hoe een echt onderhoudsvrije, veilige AI Gateway met een latentie van minder dan een milliseconde eruitziet? Plan vandaag nog een demo met ons.