Wie die Yandex.Market-Suche funktioniert und was passiert, wenn einer der Server ausfällt

Hallo, mein Name ist Evgeniy. Ich arbeite in der Suchinfrastruktur von Yandex.Market. Ich möchte der Habr-Community von der inneren Küche des Marktes erzählen – und ich habe viel zu erzählen. Zunächst einmal, wie die Marktsuche funktioniert, Prozesse und Architektur. Wie gehen wir mit Notfallsituationen um: Was passiert, wenn ein Server ausfällt? Was wäre, wenn es 100 solcher Server gäbe?

Außerdem erfahren Sie, wie wir neue Funktionen auf mehreren Servern gleichzeitig implementieren. Und wie wir komplexe Services direkt in der Produktion testen, ohne den Anwendern Unannehmlichkeiten zu bereiten. Im Allgemeinen funktioniert die Marktsuche, damit jeder eine gute Zeit hat.

Ein wenig über uns: welches Problem wir lösen

Wenn Sie Text eingeben, nach Parametern nach einem Produkt suchen oder Preise in verschiedenen Geschäften vergleichen, werden alle Anfragen an den Suchdienst gesendet. Die Suche ist der größte Dienst auf dem Markt.

Wir bearbeiten alle Suchanfragen: von den Websites market.yandex.ru, beru.ru, dem Supercheck-Dienst, Yandex.Advisor, mobilen Anwendungen. Wir nehmen auch Produktangebote in die Suchergebnisse auf yandex.ru auf.

Unter Suchdienst verstehe ich nicht nur die Suche selbst, sondern auch eine Datenbank mit allen Angeboten auf dem Markt. Die Größenordnung ist folgende: Mehr als eine Milliarde Suchanfragen werden pro Tag verarbeitet. Und alles sollte schnell und ohne Unterbrechungen funktionieren und immer das gewünschte Ergebnis liefern.

Was ist was: Marktarchitektur

Ich werde kurz die aktuelle Architektur des Marktes beschreiben. Es kann durch das folgende Diagramm grob beschrieben werden:

Nehmen wir an, ein Partnershop kommt zu uns. Er sagt, ich möchte ein Spielzeug verkaufen: diese böse Katze mit Quietscher. Und noch eine wütende Katze ohne Quietscher. Und nur eine Katze. Dann muss das Geschäft Angebote vorbereiten, nach denen der Markt sucht. Der Shop generiert eine spezielle XML mit Angeboten und kommuniziert den Pfad zu dieser XML über die Affiliate-Schnittstelle. Der Indexer lädt diese XML-Datei dann regelmäßig herunter, prüft sie auf Fehler und speichert alle Informationen in einer riesigen Datenbank.

Es gibt viele solcher gespeicherten XML-Dateien. Aus dieser Datenbank wird ein Suchindex erstellt. Der Index wird im internen Format gespeichert. Nach der Erstellung des Index lädt der Layout-Dienst ihn auf Suchserver hoch.

Als Ergebnis erscheint eine wütende Katze mit einem Quietscher in der Datenbank und der Index der Katze erscheint auf dem Server.

Im Teil über die Sucharchitektur erzähle ich Ihnen, wie wir nach einer Katze suchen.

Marktsucharchitektur

Wir leben in einer Welt der Microservices: jede eingehende Anfrage market.yandex.ru verursacht viele Unterabfragen und an deren Verarbeitung sind Dutzende Dienste beteiligt. Das Diagramm zeigt nur einige davon:

Vereinfachtes Schema zur Bearbeitung von Anfragen

Jeder Dienst hat etwas Wunderbares – seinen eigenen Balancer mit einem eindeutigen Namen:

Der Balancer gibt uns mehr Flexibilität bei der Verwaltung des Dienstes: Sie können beispielsweise Server abschalten, was oft für Updates erforderlich ist. Der Balancer erkennt, dass der Server nicht verfügbar ist und leitet Anfragen automatisch an andere Server oder Rechenzentren weiter. Beim Hinzufügen oder Entfernen eines Servers wird die Last automatisch zwischen den Servern neu verteilt.

Der eindeutige Name des Balancers ist nicht vom Rechenzentrum abhängig. Wenn Dienst A eine Anfrage an B stellt, leitet Balancer B die Anfrage standardmäßig an das aktuelle Rechenzentrum weiter. Wenn der Dienst nicht verfügbar ist oder im aktuellen Rechenzentrum nicht vorhanden ist, wird die Anfrage an andere Rechenzentren umgeleitet.

Ein einziger FQDN für alle Rechenzentren ermöglicht es Dienst A, vollständig von Standorten zu abstrahieren. Seine Anfrage an Dienst B wird immer bearbeitet. Eine Ausnahme bildet der Fall, wenn sich der Dienst in allen Rechenzentren befindet.

Aber bei diesem Balancer ist nicht alles so rosig: Wir haben eine zusätzliche Zwischenkomponente. Der Balancer ist möglicherweise instabil und dieses Problem wird durch redundante Server gelöst. Außerdem gibt es eine zusätzliche Verzögerung zwischen den Diensten A und B. In der Praxis beträgt sie jedoch weniger als 1 ms und ist für die meisten Dienste unkritisch.

Umgang mit dem Unerwarteten: Ausbalancierung und Ausfallsicherheit von Suchdiensten

Stellen Sie sich vor, dass es zu einem Zusammenbruch kommt: Sie müssen eine Katze mit einem Quietscher finden, aber der Server stürzt ab. Oder 100 Server. Wie komme ich raus? Werden wir den Benutzer wirklich ohne Katze zurücklassen?

Die Situation ist beängstigend, aber wir sind darauf vorbereitet. Ich erzähle es dir der Reihe nach.

Die Suchinfrastruktur befindet sich in mehreren Rechenzentren:

Bei der Konzeption berücksichtigen wir die Möglichkeit der Abschaltung eines Rechenzentrums. Das Leben ist voller Überraschungen – zum Beispiel kann ein Bagger ein Erdkabel durchtrennen (ja, das ist passiert). Die Kapazität in den verbleibenden Rechenzentren sollte ausreichen, um Spitzenlasten standzuhalten.

Betrachten wir ein einzelnes Rechenzentrum. Jedes Rechenzentrum verfügt über das gleiche Balancer-Betriebsschema:

Ein Balancer besteht aus mindestens drei physischen Servern. Diese Redundanz dient der Zuverlässigkeit. Balancer laufen auf HAProx.

Wir haben uns aufgrund der hohen Leistung, des geringen Ressourcenbedarfs und der breiten Funktionalität für HAProx entschieden. Unsere Suchsoftware läuft auf jedem Server.

Die Wahrscheinlichkeit, dass ein Server ausfällt, ist gering. Wenn Sie jedoch viele Server haben, steigt die Wahrscheinlichkeit, dass mindestens einer ausfällt.

Das passiert in der Realität: Server stürzen ab. Daher ist es notwendig, den Status aller Server ständig zu überwachen. Wenn der Server nicht mehr reagiert, wird er automatisch vom Datenverkehr getrennt. Zu diesem Zweck verfügt HAProxy über einen integrierten Gesundheitscheck. Es geht einmal pro Sekunde mit einer HTTP-Anfrage „/ping“ an alle Server.

Ein weiteres Feature von HAProxy: Mit dem Agent-Check können Sie alle Server gleichmäßig auslasten. Dazu verbindet sich HAProxy mit allen Servern und diese geben ihr Gewicht abhängig von der aktuellen Auslastung von 1 bis 100 zurück. Das Gewicht errechnet sich aus der Anzahl der Anfragen in der Warteschlange zur Verarbeitung und der Auslastung des Prozessors.

Nun geht es darum, die Katze zu finden. Die Suche ergibt Anfragen wie: /search?text=angry+cat. Damit die Suche schnell ist, muss der gesamte Cat-Index in den RAM passen. Selbst das Lesen von der SSD ist nicht schnell genug.

Früher war die Angebotsdatenbank klein und der Arbeitsspeicher eines Servers reichte dafür aus. Als die Angebotsbasis wuchs, passte nicht mehr alles in diesen RAM und die Daten wurden in zwei Teile aufgeteilt: Shard 1 und Shard 2.

Aber das passiert immer: Jede Lösung, auch eine gute, wirft andere Probleme auf.

Der Balancer ging immer noch zu jedem Server. Aber auf der Maschine, auf der die Anfrage kam, war nur die Hälfte des Index vorhanden. Der Rest lag auf anderen Servern. Daher musste der Server zu einem benachbarten Computer wechseln. Nachdem Daten von beiden Servern empfangen wurden, wurden die Ergebnisse kombiniert und neu eingestuft.

Da der Balancer die Anfragen gleichmäßig verteilt, waren alle Server mit der Neuordnung beschäftigt und nicht nur mit dem Senden von Daten.

Das Problem trat auf, wenn ein benachbarter Server nicht verfügbar war. Die Lösung bestand darin, mehrere Server mit unterschiedlichen Prioritäten als „benachbarte“ Server festzulegen. Zunächst wurde die Anfrage an die Server im aktuellen Rack gesendet. Erfolgte keine Antwort, wurde die Anfrage an alle Server in diesem Rechenzentrum gesendet. Und schließlich ging die Anfrage an andere Rechenzentren.
Da die Anzahl der Vorschläge zunahm, wurden die Daten in vier Teile unterteilt. Aber das war nicht die Grenze.

Derzeit wird eine Konfiguration aus acht Shards verwendet. Um noch mehr Speicherplatz zu sparen, wurde der Index außerdem in einen Suchteil (der zur Suche verwendet wird) und einen Snippet-Teil (der nicht an der Suche beteiligt ist) unterteilt.

Ein Server enthält Informationen für nur einen Shard. Um den vollständigen Index zu durchsuchen, müssen Sie daher auf acht Servern suchen, die unterschiedliche Shards enthalten.

Server werden in Cluster gruppiert. Jeder Cluster enthält acht Suchmaschinen und einen Snippet-Server.

Der Snippet-Server führt eine Schlüsselwertdatenbank mit statischen Daten aus. Sie werden benötigt, um Dokumente auszustellen, beispielsweise eine Beschreibung einer Katze mit Quietscher. Die Daten werden speziell auf einen separaten Server übertragen, um den Speicher der Suchserver nicht zu belasten.

Da Dokument-IDs nur innerhalb eines Indexes eindeutig sind, kann es vorkommen, dass die Snippets keine Dokumente enthalten. Nun, oder dass es für eine ID unterschiedliche Inhalte geben wird. Damit die Suche funktioniert und Ergebnisse zurückgegeben werden, war daher Konsistenz im gesamten Cluster erforderlich. Im Folgenden erkläre ich Ihnen, wie wir die Konsistenz überwachen.

Die Suche selbst ist wie folgt aufgebaut: Eine Suchanfrage kann auf jedem der acht Server eingehen. Nehmen wir an, er ist zu Server 1 gekommen. Dieser Server verarbeitet alle Argumente und versteht, wonach und wie gesucht werden muss. Abhängig von der eingehenden Anfrage kann der Server zusätzliche Anfragen an externe Dienste stellen, um die erforderlichen Informationen einzuholen. Einer Anfrage können bis zu zehn Anfragen an externe Dienste folgen.

Nach dem Sammeln der notwendigen Informationen beginnt eine Suche in der Angebotsdatenbank. Hierzu werden Unterabfragen an alle acht Server im Cluster gestellt.

Sobald die Antworten eingegangen sind, werden die Ergebnisse zusammengefasst. Am Ende sind möglicherweise mehrere weitere Unterabfragen an den Snippet-Server erforderlich, um die Ergebnisse zu generieren.

Suchanfragen innerhalb des Clusters sehen wie folgt aus: /shard1?text=angry+cat. Darüber hinaus werden ständig einmal pro Sekunde Unterabfragen des Formulars zwischen allen Servern innerhalb des Clusters durchgeführt: /Status.

Wunsch /Status Erkennt eine Situation, in der der Server nicht verfügbar ist.

Es kontrolliert auch, dass die Suchmaschinenversion und die Indexversion auf allen Servern gleich sind, da es sonst zu inkonsistenten Daten innerhalb des Clusters kommt.

Obwohl ein Snippet-Server Anfragen von acht Suchmaschinen verarbeitet, ist sein Prozessor nur sehr gering belastet. Daher übertragen wir die Snippet-Daten nun an einen separaten Dienst.

Zur Datenübertragung haben wir Universalschlüssel für Dokumente eingeführt. Jetzt ist es unmöglich, dass Inhalte aus einem anderen Dokument mit einem Schlüssel zurückgegeben werden.

Doch der Übergang zu einer anderen Architektur ist noch nicht abgeschlossen. Jetzt wollen wir den dedizierten Snippet-Server loswerden. Und dann ganz von der Clusterstruktur abrücken. Dadurch können wir problemlos weiter skalieren. Ein zusätzlicher Bonus sind erhebliche Eiseneinsparungen.

Und nun zu Gruselgeschichten mit Happy End. Betrachten wir mehrere Fälle von Server-Nichtverfügbarkeit.

Es ist etwas Schreckliches passiert: Ein Server ist nicht verfügbar

Nehmen wir an, ein Server ist nicht verfügbar. Dann können die verbleibenden Server im Cluster weiterhin antworten, die Suchergebnisse sind jedoch unvollständig.

Per Statuscheck /Status Nachbarserver verstehen, dass einer nicht verfügbar ist. Der Vollständigkeit halber werden daher alle Server im Cluster pro Anfrage erfasst /Klingeln Sie beginnen dem Balancer mitzuteilen, dass sie ebenfalls nicht verfügbar sind. Es stellt sich heraus, dass alle Server im Cluster ausgefallen sind (was nicht stimmt). Das ist der Hauptnachteil unseres Cluster-Systems – deshalb wollen wir davon wegkommen.

Anfragen, die mit einem Fehler fehlschlagen, werden vom Balancer auf anderen Servern erneut gesendet.
Der Balancer sendet außerdem keinen Benutzerverkehr mehr an tote Server, überprüft jedoch weiterhin deren Status.

Sobald der Server verfügbar ist, beginnt er zu antworten /Klingeln. Sobald normale Antworten auf Pings von toten Servern eintreffen, beginnen Balancer damit, Benutzerverkehr dorthin zu leiten. Der Clusterbetrieb ist wiederhergestellt, Hurra.

Noch schlimmer: Viele Server sind nicht verfügbar

Ein erheblicher Teil der Server im Rechenzentrum fällt aus. Was tun, wohin laufen? Der Balancer kommt wieder zur Rettung. Jeder Balancer speichert ständig die aktuelle Anzahl der Live-Server im Speicher. Es berechnet ständig die maximale Menge an Datenverkehr, die das aktuelle Rechenzentrum verarbeiten kann.

Wenn in einem Rechenzentrum viele Server ausfallen, stellt der Balancer fest, dass dieses Rechenzentrum nicht den gesamten Datenverkehr verarbeiten kann.

Dann beginnt der überschüssige Datenverkehr zufällig auf andere Rechenzentren zu verteilen. Alles funktioniert, alle sind zufrieden.

Wie wir es machen: Veröffentlichungen veröffentlichen

Lassen Sie uns nun darüber sprechen, wie wir am Dienst vorgenommene Änderungen veröffentlichen. Hier sind wir den Weg der Prozessvereinfachung gegangen: Das Ausrollen eines neuen Release erfolgt nahezu vollständig automatisiert.
Wenn sich im Projekt eine bestimmte Anzahl an Änderungen ansammelt, wird automatisch ein neues Release erstellt und dessen Build gestartet.

Anschließend wird der Dienst zum Testen ausgerollt, wo die Stabilität des Betriebs überprüft wird.

Gleichzeitig werden automatische Leistungstests gestartet. Dies übernimmt ein spezieller Dienst. Ich werde jetzt nicht darüber sprechen – seine Beschreibung wäre einen separaten Artikel wert.

Wenn die Veröffentlichung in Testing erfolgreich ist, wird die Veröffentlichung der Version in Prestable automatisch gestartet. Prestable ist ein spezieller Cluster, über den der normale Benutzerverkehr geleitet wird. Wenn ein Fehler zurückgegeben wird, stellt der Balancer eine erneute Anfrage an die Produktion.

In Prestable werden die Reaktionszeiten gemessen und mit der vorherigen Version in der Produktion verglichen. Wenn alles in Ordnung ist, stellt eine Person eine Verbindung her: überprüft die Diagramme und Ergebnisse der Lasttests und beginnt dann mit der Einführung in die Produktion.

Dem Nutzer gebührt nur das Beste: A/B-Testing

Es ist nicht immer offensichtlich, ob Änderungen an einer Dienstleistung echte Vorteile bringen. Um den Nutzen von Änderungen zu messen, wurden A/B-Tests entwickelt. Ich erzähle Ihnen ein wenig darüber, wie es in der Yandex.Market-Suche funktioniert.

Alles beginnt mit dem Hinzufügen eines neuen CGI-Parameters, der neue Funktionen ermöglicht. Unser Parameter sei: market_new_functionity=1. Dann aktivieren wir im Code diese Funktionalität, wenn das Flag vorhanden ist:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

Neue Funktionen werden in die Produktion eingeführt.

Um A/B-Tests zu automatisieren, gibt es einen speziellen Dienst, der detaillierte Informationen bereitstellt hier beschrieben. Im Dienst wird ein Experiment erstellt. Der Traffic-Anteil wird beispielsweise auf 15 % festgelegt. Prozentsätze werden nicht für Abfragen, sondern für Benutzer festgelegt. Die Dauer des Experiments wird ebenfalls angegeben, beispielsweise eine Woche.

Es können mehrere Experimente gleichzeitig durchgeführt werden. In den Einstellungen können Sie festlegen, ob eine Überschneidung mit anderen Experimenten möglich ist.

Infolgedessen fügt der Dienst automatisch ein Argument hinzu market_new_functionity=1 bis 15 % der Nutzer. Außerdem werden die ausgewählten Metriken automatisch berechnet. Nach Abschluss des Experiments sehen sich die Analysten die Ergebnisse an und ziehen Schlussfolgerungen. Basierend auf den Erkenntnissen wird eine Entscheidung über die Einführung in die Produktion oder die Verfeinerung getroffen.

Die geschickte Hand des Marktes: Testen in der Produktion

Es kommt häufig vor, dass Sie den Betrieb einer neuen Funktionalität in der Produktion testen müssen, aber nicht sicher sind, wie sie sich unter „Kampfbedingungen“ unter hoher Last verhält.

Es gibt eine Lösung: Flags in CGI-Parametern können nicht nur für A/B-Tests, sondern auch zum Testen neuer Funktionen verwendet werden.

Wir haben ein Tool entwickelt, mit dem Sie die Konfiguration auf Tausenden von Servern sofort ändern können, ohne den Dienst Risiken auszusetzen. Es heißt Stop Tap. Die ursprüngliche Idee bestand darin, einige Funktionen ohne Layout schnell deaktivieren zu können. Dann wurde das Tool erweitert und komplexer.

Das Service-Flussdiagramm ist unten dargestellt:

Flag-Werte werden über die API gesetzt. Der Verwaltungsdienst speichert diese Werte in der Datenbank. Alle Server gehen alle zehn Sekunden zur Datenbank, pumpen Flag-Werte aus und wenden diese Werte auf jede Anfrage an.

Im Stopp-Tap können Sie zwei Arten von Werten festlegen:

1) Bedingte Ausdrücke. Anwenden, wenn einer der Werte wahr ist. Zum Beispiel:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

Der Wert „3“ wird angewendet, wenn die Anfrage am Standort DC1 verarbeitet wird. Und der Wert ist „4“, wenn die Anfrage im zweiten Cluster für die Site beru.ru verarbeitet wird.

2) Unbedingte Werte. Standardmäßig anwenden, wenn keine der Bedingungen erfüllt ist. Zum Beispiel:

Wert, Wert!

Wenn ein Wert mit einem Ausrufezeichen endet, erhält er eine höhere Priorität.

Der CGI-Parameterparser analysiert die URL. Anschließend werden die Werte aus dem Stop Tap übernommen.

Es werden Werte mit folgenden Prioritäten angewendet:

1. Mit erhöhter Priorität ab Stop Tap (Ausrufezeichen).
2. Der Wert aus der Anfrage.
3. Standardwert von Stop tap.
4. Standardwert im Code.

Es gibt viele Flags, die in bedingten Werten angegeben werden – sie reichen für alle uns bekannten Szenarien:

• Rechenzentrum.
• Umgebung: Produktion, Test, Schatten.
• Veranstaltungsort: Markt, Beru.
• Clusternummer.

Mit diesem Tool können Sie neue Funktionen auf einer bestimmten Gruppe von Servern aktivieren (z. B. in nur einem Rechenzentrum) und den Betrieb dieser Funktionalität testen, ohne dass ein besonderes Risiko für den gesamten Dienst besteht. Selbst wenn Sie irgendwo einen schwerwiegenden Fehler gemacht haben, alles zusammengebrochen ist und das gesamte Rechenzentrum ausgefallen ist, leiten Balancer Anfragen an andere Rechenzentren weiter. Endverbraucher werden davon nichts merken.

Wenn Sie ein Problem bemerken, können Sie das Flag sofort auf den vorherigen Wert zurücksetzen und die Änderungen werden rückgängig gemacht.

Dieser Dienst hat auch seine Schattenseiten: Die Entwickler lieben ihn sehr und versuchen oft, alle Änderungen in den Stop Tap zu pushen. Wir versuchen, Missbrauch zu bekämpfen.

Der Stop-Tap-Ansatz funktioniert gut, wenn Sie bereits über stabilen Code verfügen, der für die Einführung in die Produktion bereit ist. Gleichzeitig haben Sie immer noch Zweifel und möchten den Code unter „Kampfbedingungen“ überprüfen.

Stop Tap eignet sich jedoch nicht zum Testen während der Entwicklung. Für Entwickler gibt es einen separaten Cluster namens „Shadow Cluster“.

Geheimer Test: Schattencluster

Anforderungen von einem der Cluster werden an den Schattencluster dupliziert. Der Balancer ignoriert jedoch die Antworten dieses Clusters vollständig. Das Diagramm seiner Funktionsweise ist unten dargestellt.

Wir erhalten einen Testcluster, der sich unter echten „Kampfbedingungen“ befindet. Dorthin geht der normale Benutzerverkehr. Die Hardware in beiden Clustern ist gleich, sodass Leistung und Fehler vergleichbar sind.

Und da der Balancer Antworten vollständig ignoriert, sehen Endbenutzer keine Antworten vom Schattencluster. Daher ist es nicht beängstigend, einen Fehler zu machen.

Befund

Wie haben wir also die Marktsuche aufgebaut?

Damit alles reibungslos läuft, unterteilen wir die Funktionalität in separate Dienste. Auf diese Weise können wir nur die Komponenten skalieren, die wir benötigen, und die Komponenten einfacher gestalten. Es ist einfach, eine separate Komponente einem anderen Team zuzuweisen und die Verantwortlichkeiten für die Arbeit daran aufzuteilen. Und die erhebliche Eiseneinsparung ist bei diesem Ansatz ein offensichtliches Plus.

Auch der Schattencluster hilft uns: Wir können Dienste entwickeln, sie dabei testen und stören den Nutzer nicht.

Nun, natürlich Tests in der Produktion. Müssen Sie die Konfiguration auf Tausenden von Servern ändern? Ganz einfach, verwenden Sie den Stop Tap. Auf diese Weise können Sie sofort eine fertige komplexe Lösung ausrollen und bei Problemen auf eine stabile Version zurücksetzen.

Ich hoffe, ich konnte zeigen, wie wir den Markt mit einer ständig wachsenden Angebotsbasis schnell und stabil machen. Wie wir Serverprobleme lösen, eine große Anzahl von Anfragen bearbeiten, die Flexibilität des Dienstes verbessern und dies ohne Unterbrechung der Arbeitsabläufe tun.

Source: habr.com