Suchmaschinen liefern oft Dutzende Ergebnisse, die nicht genau treffen, weil sie nur nach Wortübereinstimmungen suchen. Semantische Suche versteht die Bedeutung. HubSpot hat eine Infrastruktur aufgebaut, die für über zwanzig Milliarden Vektoren semantische Suche ermöglicht. Dieser Artikel beschreibt ihre Entscheidungen und Skalierung, von der Machbarkeitsstudie bis zur automatisierten Großanlage.
Eine Vektordatenbank ordnet jedes Objekt in einem mehrdimensionalen Raum an, sodass ähnliche Inhalte nahe beieinander liegen. Die Suche findet die nächsten Nachbarn zur Anfrage. Qdrant, das HubSpot einsetzt, ist ein zentraler Baustein moderner KI-Anwendungen, von Chatbots über RAG-Systeme bis zur Dubletten-Erkennung von Kontakten.
Warum eine zentrale Vektor-Plattform?
HubSpot begann vor einigen Jahren mit einem Proof of Concept. Damals reichte eine Handvoll Cluster, die mit Helm verwaltet wurden. Mit dem Wachstum der KI-Nutzung – heute nutzen über 38 Teams die semantische Suche – wurde eine zentrale, verwaltete Plattform notwendig. So entstand VaaS – Vector as a Service. Es ist die Schicht zwischen den Anwendungen und der Vektordatenbank. Sie übernimmt Zugriffskontrolle, generiert Embeddings, verwaltet Versionen und sammelt Feedback. Die Anwendungen rufen eine API auf und müssen sich nicht um die Komplexität kümmern. Schreiboperationen laufen asynchron, Leseanfragen synchron.
Warum Qdrant und warum selbst betrieben?
Die Wahl fiel auf Qdrant, eine quelloffene Vektordatenbank, die sich auf eigenen Servern betreiben lässt. Qdrant bietet eine umfangreiche API: benannte Vektoren, Hybridsuche, mehrstufige Abfragen und gewichtetes Ranking. Als ANN-Algorithmus verwendet es HNSW, das geringe Latenzen ermöglicht, aber mehr Arbeitsspeicher benötigt. Die HubSpot-Ingenieure nutzen Optimierungen wie Quantisierung und plattenbasierte Optionen, um Qualität und Kosten auszugleichen. Der Betrieb im eigenen Haus bietet volle Kontrolle über die Daten, Integration in die bestehende Infrastruktur (Tracing, Kostenverfolgung, Rate Limiting, Auto-Scaling) und Nutzung der eigenen AWS-Konditionen. Die Sicherheitsstandards von HubSpot lassen sich direkt anwenden.
Die aktuelle Dimension: Zahlen
VaaS verwaltet heute über 200 Indizes, verteilt auf mehr als 140 Qdrant-Cluster in fünf Rechenzentren und zwei Umgebungen. Insgesamt sind das über 20 Milliarden Vektoren – der größte einzelne Index umfasst 9,5 Milliarden Vektoren, der Durchschnitt liegt bei 95 Millionen. Die Plattform verarbeitet regelmäßig über 5.000 Schreiboperationen pro Sekunde, mit Spitzen bis zu 100.000. Leseanfragen liegen bei über 1.000 RPS. Besonders herausfordernd sind Traffic-Spitzen, wenn große Backfills gleichzeitig mit Live-Traffic laufen. Die Infrastruktur muss skalieren und zuverlässig bleiben. Eine Cluster-Isolation nach Produktteams stellt sicher, dass ein Ausfall nicht die gesamte Plattform lahmlegt.
Vom Helm-Proof-of-Concept zum Kubernetes Operator
2023 startete man mit Helm und einer Handvoll Cluster. Jeder Cluster bekam eine eigene Konfiguration, die manuell per YAML und Skripten angelegt wurde. Für zehn Cluster war das machbar, aber mit dem Wachstum wurde der Aufwand enorm. Jeder neue Cluster brauchte nicht nur die Qdrant-StatefulSets, sondern auch Kafka-Themen, Worker-Pods und Monitoring-Komponenten. Helm kann keine API-Aufrufe tätigen, kein automatisches Scaling basierend auf externen Metriken durchführen und keine komplexen Lebenszyklus-Management-Schritte ausführen. Deshalb entschied man sich für den Umstieg auf ein hauseigenes Kubernetes-Operator-Framework namens „Kube-operators“. Ein Operator überwacht ständig den gewünschten Zustand des Systems und bringt die Realität dorthin – automatisch.
Die Migration brachte eine wichtige Änderung: Statt eines gemeinsamen Namespace für alle Cluster gibt es jetzt einen Namespace pro Cluster. Das erhöht die Isolation, vereinfacht das Kosten-Tracking auf Teamebene und reduziert den Blast Radius bei Fehlern. Die Konfiguration eines neuen Clusters besteht heute aus genau einer Custom Resource (CR). Ein Translator (eine Komponente des Operators) überwacht diese CR und erzeugt oder aktualisiert daraus alle notwendigen Ressourcen: Namespace, StatefulSet für Qdrant, Indexer-Pods, Kafka-Themen und benutzerdefinierte Ressourcen für die Metadaten der Cluster. Die Plattform entdeckt neue Cluster automatisch, indem sie die entsprechenden CRs beobachtet. Ein zusätzlicher Translator kümmert sich um die Qdrant-Knoten selbst, ein dritter um die Indexer – die Arbeiter, die eingehende Schreiblast puffern und in Qdrant indizieren. Das alles läuft in einem 60-Sekunden-Zyklus, so dass Änderungen schnell wirksam werden.
Automatisierte Wartung – Shard-Evakuierung aus einem Guss
Ein besonders kniffliger Vorgang ist das horizontale Herunterskalieren eines Clusters. Früher waren mehrere manuelle Schritte nötig: zuerst einen Job ausführen, der die Shards von den zu entfernenden Knoten transferiert und diese aus dem Konsens entfernt; dann die Helm-Chart aktualisieren, die Pod-Anzahl reduzieren, und schließlich die PVCs der gelöschten Pods manuell löschen. Bei über hundert Clustern ein unhaltbarer Zustand. Mit dem Operator ist das heute ein einziger Schritt: einfach die Replica-Anzahl in der Cluster-CR reduzieren. Der Translator erkennt die Abweichung, startet automatisch die Evakuierung aller Shards von den zu entfernenden Peers, wartet auf erfolgreichen Transfer und entfernt die Peers dann aus dem Konsens – und zwar in einer strikten Reihenfolge, die Datenverlust und Verletzung der Replikationsfaktoren verhindert. Erst wenn alle Shards sicher umgezogen sind, werden die Pods heruntergefahren und die PVCs gelöscht. Diese Automatisierung ist entscheidend, um bei der Größenordnung von 140+ Clustern operativ effizient zu bleiben.
Die Architektur zeigt, wie Unternehmen KI-Infrastruktur als Dienst für interne Teams bereitstellen können. Die Teams müssen sich nicht um die Datenbank kümmern, sondern können sich auf die Geschäftslogik konzentrieren. Der Schlüssel liegt in der Automatisierung: Ein Kubernetes-Operator, der nicht nur Pods startet, sondern auch die Shard-Verwaltung von Qdrant übernimmt. Ein zentraler Dienst besteht aus mehr als nur einer API vor einer Datenbank. Es sind Komponenten wie Namespace-Isolation, dynamische Cluster-Entdeckung und automatisierte Skalierung mit Sicherheitsgarantien, die den Unterschied zwischen einer Labordemo und einer produktiven Umgebung mit Milliarden von Vektoren ausmachen. Die Zukunft der KI-Suche liegt nicht nur in besseren Algorithmen, sondern auch in der robusten, wartbaren Infrastruktur, die sie trägt.
Quelle: product.hubspot.com
