✝️ 🏬 👩🏿 HighLoad ++, Mikhail Raichenko (ManyChat): Fast ohne Magie oder wie einfach es ist, Terabit-Videostreams zu verbreiten 😛 🧝 🥡

Die nächste HighLoad ++ - Konferenz findet am 6. und 7. April 2020 in St. Petersburg statt. Details und Tickets hier . HighLoad ++ Moskau 2018. Halle „Delhi + Kalkutta“. 8. November, 14 Uhr Abstracts und Präsentation .

Ich arbeite im VKontakte-Team und entwickle ein Videoübertragungssystem.
In dem Bericht werde ich die Merkmale der Entwicklung des Backends, die Entwicklung unseres Systems und die technischen Lösungen, zu denen wir gekommen sind, erläutern: 

wie wir das Video-Backend gemacht haben und wie der Evolutionsprozess ist;
die Auswirkungen geschäftlicher und betrieblicher Anforderungen auf die Architektur;
"Warten" und "Versuchen Sie es erneut" schlagen fehl.
wie die einfachsten Aufgaben durch die Anzahl der Benutzer kompliziert werden;
wie man die Latenz ohne UDP reduziert;
Wir führen 2 Mal am Tag Stresstests durch oder was Clover uns dabei geholfen hat.

Mikhail Raichenko (im Folgenden - MR): - Ein kleiner Ausflug. Ich erzähle Ihnen von den Leuten, die uns streamen, vom Live (Live), von den Plattformen, auf denen wir den Videostream erhalten und die wir vertreiben. Am Ende werde ich über die aktuelle Architektur von Live sprechen, über ihre Einschränkungen und Fähigkeiten sowie darüber, wie die aktuelle Architektur einen Effekt wie "Clover" überstanden hat.

Über Live-Übertragungen. Berichtsübersicht

Zunächst werde ich ein wenig über die Live-Übertragungen und Streamer selbst sprechen und uns Videoinhalte senden, die wir anderen Zuschauern zeigen.
. ? , , , , - - , - , . , : , – .
. , . . , , .
, , . , . , , , , , 2014-2015 . , .
. , .
, . , . , .
, . .
, , «», .

Alle Rundfunkdienste sehen

ungefähr so aus: Wir haben einen Streamer, er sendet einen RTMP-Stream an uns und wir zeigen das Publikum - nichts Überraschendes, nichts Übernatürliches.

Woher kommt der Videostream? Eine wichtige Verkehrsquelle für uns ist unsere mobile Anwendung VKlife. Was ist gut an ihm? Darin können wir vollständig steuern, wie wir das Video codieren. Wir können auf Client-Seite viele Optimierungen vornehmen, um sie später mit minimalen Verzögerungen unseren Zuschauern zu zeigen.

Von den Minuspunkten: Mobile Anwendungen arbeiten über Netzwerken. Es kann sich um 3G handeln ... In jedem Fall handelt es sich fast immer um Mobilfunknetze, die einige Verzögerungen verursachen. Sie müssen die Daten auf der Anwendungsseite zusätzlich puffern, damit der Stream so reibungslos wie möglich ausgeführt wird.

Die zweite Quelle sind Streamer mit OBS, Wirecast oder solche, die von anderen Desktopanwendungen streamen. Dies ist ein ziemlich großes Publikum. Manchmal sind dies Seminare, manchmal - Spiel-Streams (es gibt besonders viele davon aus solchen Anwendungen). Positiv zu vermerken ist, dass es nur wenige solcher Anwendungen gibt. Wir können unseren Streamern gute Tuning-Empfehlungen geben. Aber gleichzeitig gibt es viele Einstellungen und senden nicht ganz den Stream, den wir wollen.

Die dritte Kategorie ist der RTMP-Stream von Medienservern. Dies können sehr kleine Medienserver sein, dh ein Heimformat: Eine Person überträgt einen Blick auf die Straße oder etwas anderes. Oder ganz ernsthafte Sendungen unserer Partner: Es kann alles geben, es gibt nicht sehr viele solcher Streams, aber im Grunde sind sie für uns sehr wichtig.

Wer passt auf?

Auch dies ist eine mobile Anwendung - hier ist alles klar. Das größte Problem ist die Netzwerklatenz. Von den Profis: Wir können den Player anpassen - es ist praktisch für uns, gut, aber nicht überall stellt sich heraus, dass es 100% ist.

Webplayer bei vk.com. Auch hier ist alles einfach - es ist ein normaler Web-Player, den Sie öffnen können, um ihn anzusehen. Ein ausreichend großes Publikum bei vk.com, viele Zuschauer in den Sendungen. Einige Sendungen hängen in unserem Abschnitt „Video“ - es können Zehntausende (manchmal ohne PR) sein, insbesondere wenn es sich um interessante Inhalte handelt.

Dementsprechend sind die Kanäle groß genug für Zuschauer, die auf einem Web-Player sitzen. Daher gibt es viel Verkehr, auch für eine Sendung.

Der dritte ist der VKontakte-Webplayer auf einer Website eines Drittanbieters. Sie können mit dem Streaming von allem beginnen, was Sie möchten, und einen VKontakte-Webplayer an Ihre Website hängen. Sie können unser Partner werden, wenn Sie interessante Inhalte haben: Sie können sie selbst aufhängen, Sie können bei uns hängen - wie Sie möchten. Sie können Ihre Sendungen auf diese Weise organisieren, und alles wird funktionieren.

Vergleich mit Videoanrufen

Bei Videoanrufen wird eine gewisse Bildverzerrung vergeben. Videoanrufe sind einfacher: Wir können das Bild erheblich verschlechtern, müssen aber gleichzeitig eine sehr gute Latenz aufrechterhalten. Mit einer langen Verzögerung wird es absolut unmöglich sein, den Dienst zu nutzen.

Bei Sendungen in diesem Sinne ist es ein wenig umgekehrt: Wir müssen eine hohe Bildqualität beibehalten, können aber gleichzeitig die Latenz aufgrund vieler Faktoren erhöhen. Zum Beispiel puffert der Player den Fluss auf die eine oder andere Weise (es kann eine Sekunde sein, zwei, um beispielsweise die Verschlechterung des Netzwerks zu überstehen), daher benötigt er in den meisten Fällen keine zweiten Millisekundenverzögerungen. Sie können danach streben, aber Essen ist keine Voraussetzung.

Bei gewöhnlichen Videos ist die Situation genau umgekehrt. Wir brauchen sehr gute Qualität. Gleichzeitig ist es wünschenswert, die Videogröße, das Verhältnis von Bitrate und Qualität zu minimieren, um mit minimalem Durchfluss die beste Lösung zu erzielen. Von den Profis: Wir sind nicht zeitlich begrenzt: Zum Zeitpunkt des Herunterladens des Videos haben wir genug Zeit, um das Video zu optimieren, zu sehen, wie es am besten komprimiert wird, etwas zu tun, es bei Bedarf in die Caches zu ziehen - im Allgemeinen ist alles genug OK.

Im Leben ist die Situation wieder umgekehrt: Wir haben sehr wenig Zeit für die Transcodierung. Gleichzeitig gibt es nur wenige Möglichkeiten, aber es gibt keine Erwartungen für die Sendung. Das Publikum wird uns vergeben, wenn wir Unterstützung haben oder die Qualität nicht sehr gut ist.

Sehr erste Version

Es wird durchaus erwartet:

Eigentlich ist es etwas anders:

"Streamer - Medienserver - Cache-Level - Viewer". Im Prinzip können Sie mit dieser Version sehr stark skalieren. Ich würde sagen, dass es bereits Zehntausenden von Zuschauern standhalten sollte. Es hat andere Nachteile ...

Wenn Sie sich beispielsweise diese Schaltung ansehen (vorherige Folie), können Sie feststellen, dass sie nicht fehlertolerant ist. Wir müssen mit dem Medienserver raten, um das Publikum gut auszugleichen. Wir können nicht viele Caches auf jedem Server hängen - es ist einfach teuer. Daher haben wir nachgesehen und festgestellt, dass es einfach und klar ist, dass es einige Möglichkeiten zur Skalierung gibt, aber offensichtlich fehlt etwas ... Und wir haben begonnen, Anforderungen zu formulieren.

Infrastrukturanforderungen

Was ist wichtig?

. , , . ( ). (, ).
. : -, (, ) ; -, – , , .
Lieferung in die Regionen. Auch ein wichtiger Punkt! Es ist dumm, den gesamten Videoinhalt von Petersburg oder Moskau nach Nowosibirsk, Jekaterinburg oder sogar von St. Petersburg nach Moskau zu ziehen. Dies ist nicht sehr gut, da die Netzwerkverzögerung lang sein wird - es wird Verzögerungen geben, alles wird verzögert, und dies ist nicht gut. Daher muss unsere Infrastruktur berücksichtigen, dass wir Inhalte an die Regionen liefern.
Bequeme Bedienung und Überwachung. Eine wichtige Eigenschaft. Da das System groß ist und viele Betrachter vorhanden sind, ist es wichtig, bei Problemen rechtzeitig Warnungen an Administratoren zu senden, einschließlich der Überwachung von Produkt- und technischen Metriken.

Wie sieht die Broadcast-Infrastruktur jetzt aus?

Als Ergebnis kamen wir zu einer ziemlich einfachen, aber effektiven Infrastruktur ...

– , ( , ). RTMP-, . , .
, , , , . . , , , – : , -, (. . ); -, .
. – , . , , . , ( , ).
, (edge-). , . !
– edge-, , . : , – .

Interessant? Balancieren! In diesem Schema wählen wir Balancing und versuchen, Zuschauer, die denselben Stream sehen, an jeden Edgeserver zu senden. Die Cache-Lokalität ist hier sehr wichtig, da es viele Edgeserver geben kann. und wenn wir nicht sowohl die temporäre als auch die Lokalität des Caches aus der Sicht des Streams beobachten, werden wir die innere Schicht überladen. Das würde uns auch nicht gefallen.

Daher gleichen wir uns folgendermaßen aus: Wir wählen einen bestimmten Edgeserver für die Region aus, an die wir Viewer senden, und senden, bis wir verstehen, dass eine gewisse Füllung aufgetreten ist und an einen anderen Server gesendet werden sollte. Die Schaltung ist einfach und arbeitet sehr zuverlässig. Natürlich wählen Sie für verschiedene Streams eine andere Sequenz von Edgeservern (die Reihenfolge, in der wir Zuschauer aussenden). Dementsprechend funktioniert das Auswuchten ganz einfach.

Wir geben dem Client auch einen Link zu einem verfügbaren Edgeserver. Dies geschieht, damit wir bei einem Ausfall des Edgeservers den Viewer auf einen anderen umleiten können. Das heißt, wenn der Zuschauer die Sendung sieht, erhält er alle paar Sekunden eine Verbindung zum gewünschten Server. Wenn er versteht, dass die Verbindung unterschiedlich sein muss, wechselt er (der Player wechselt) und sieht sich die Sendung weiterhin von einem anderen Server an.

Eine weitere wichtige Rolle von Edgeservern ist der Schutz von Inhalten. Der gesamte Inhaltsschutz findet im Wesentlichen dort statt. Dafür haben wir ein eigenes Nginx-Modul. Es ist etwas ähnlich wie Security Link.

Skalieren und Auswuchten

. , : , . edge-, . . . … , – , -- – , – , , , – ! – .
. , , , , : . ( ) , – , . , , , edge-.
, , , .

?

Eines der Hauptprotokolle war RTMP (nicht nur zur Eingabe, sondern auch zur Verteilung von Inhalten). Der Hauptvorteil ist die geringe Latenz. Es kann eine halbe Sekunde, eine Sekunde, zwei Sekunden sein. Tatsächlich enden die Vorteile dort ...

Dieses Streaming-Protokoll ist schwer zu überwachen - es ist in gewissem Sinne geschlossen, obwohl es eine Spezifikation gibt. Der Flash Player funktioniert nicht mehr (tatsächlich ist es „schon alles“). Benötigen Sie Unterstützung auf CDN-Ebene? Sie benötigen spezielle Nginx-Module oder Ihre eigene Software, um den Stream normal zu übertragen. Es gibt auch einige Schwierigkeiten mit mobilen Clients. Standardmäßig wird es in mobilen Clients nur sehr schlecht unterstützt - spezielle Verbesserungen sind erforderlich, und all dies ist sehr schwierig.
Das zweite Protokoll, das wir verwendet haben, ist HLS. Es sieht ganz einfach aus: Es ist eine Textdatei, die sogenannte Indexdatei. Es enthält Links zu Indexdateien mit unterschiedlichen Berechtigungen, und die Dateien selbst enthalten Links zu Mediensegmenten.

Wie ist er gut Es ist sehr einfach, obwohl es ein bisschen alt ist. Sie können CDN verwenden, dh Sie benötigen nur nginx, um das HLS-Protokoll zu verteilen. Es ist in Bezug auf die Überwachung verständlich.

Hier sind seine Vorteile:

einfache Bedienung - nginx als Proxyserver;
Es ist einfach, Metriken zu überwachen und zu erfassen (es reicht aus, dass Sie ungefähr das überwachen, was Sie auf Ihrer Website überwachen).
Jetzt ist dieses Protokoll das wichtigste für die Bereitstellung von Inhalten.

Signifikantes Minus:

hohe Latenz.

Die HLS-Latenz ist tatsächlich im Protokoll selbst verschachtelt. Da eine lange Pufferzeit erforderlich ist, muss der Player mindestens warten, wenn ein Block geladen ist. In guter Weise muss er jedoch warten, bis zwei Blöcke (zwei Mediensegmente) geladen sind. Andernfalls wird der Client im Falle einer Verzögerung vom Player geladen, was sich nicht sehr gut auswirkt Benutzererfahrung.

Der zweite Punkt, der eine Verzögerung bei HLS verursacht, ist das Caching. Die Wiedergabeliste wird auf der inneren Ebene und auf den Edgeservern zwischengespeichert. Selbst wenn wir relativ gesehen eine Sekunde oder eine halbe Sekunde zwischenspeichern, ist dies ungefähr plus 2-3 Sekunden Verzögerung. Insgesamt stellt sich heraus, dass es 12 bis 18 Sekunden sind - das ist nicht sehr angenehm, offensichtlich ist es besser.

HLS verbessern

Mit diesen Gedanken begannen wir, HLS zu verbessern. Wir haben es auf ziemlich einfache Weise verbessert: Geben wir das letzte, noch nicht aufgezeichnete Mediensegment der Wiedergabeliste etwas früher an. Das heißt, sobald wir mit dem Schreiben des letzten Mediensegments begonnen haben, geben wir es sofort in der Wiedergabeliste bekannt. Was passiert gerade? .. Die

Pufferzeit in den Spielern wird reduziert. Der Spieler glaubt, dass er bereits alles heruntergeladen hat, und beginnt ruhig mit dem Herunterladen der gewünschten Segmente. Auf diese Weise „betrügen“ wir den Spieler ein wenig, aber wenn wir den „Stahl“ (Lasten im Spieler) gut überwachen, macht uns das keine Angst - wir können aufhören, das Segment im Voraus zu geben, und alles wird wieder normal.

Der zweite Punkt: Wir gewinnen insgesamt ca. 5-8 Sekunden. Woher kommen sie? Diese Segmentzeit beträgt 2 bis 4 Sekunden pro Segment plus der Zeit zum Zwischenspeichern der Wiedergabeliste (dies sind weitere 2-3 Sekunden). Darüber hinaus nimmt unsere Verzögerung erheblich ab. Die Verzögerung wird von 12-15 Sekunden auf 5-7 Sekunden reduziert.

Was ist sonst noch gut an diesem Ansatz? Es ist tatsächlich kostenlos! Wir müssen nur prüfen, ob die Spieler mit diesem Ansatz kompatibel sind. Diejenigen, die nicht kompatibel sind, senden wir an die alten URLs und kompatible Player an die neuen URLs. Wir müssen keine alten Clients aktualisieren, die dies unterstützen, was ebenfalls wichtig ist. Wir müssen die Player in mobilen Clients nicht ändern oder freigeben. Wir müssen keinen Web-Player entwickeln. Es sieht gut genug aus!

Von den Minuspunkten - die Notwendigkeit, den eingehenden Videostream zu steuern. Im Fall eines mobilen Clients können wir dies ganz einfach tun (wenn der Stream von einem mobilen Client stammt) oder ohne Fehler transkodieren, da der Player wissen muss, wie lange es für ein Mediensegment dauert. Und da wir es ankündigen, bevor es tatsächlich aufgenommen wird, müssen wir wissen, wie viel Zeit es dauern wird, wenn wir es aufnehmen.

Qualitätsmetriken

Somit haben wir HLS verbessert. Jetzt möchte ich sagen, wie wir überwachen und welche Qualitätsmetriken wir aufnehmen:

Eine der wichtigsten Qualitätsmetriken ist die Startzeit. Im Idealfall scrollen Sie vor der Übertragung durch den mobilen Client, drücken die Taste und es wird sofort gestartet. Es wäre ideal, wenn es vor dem Drücken der Taste startet, aber leider nur, wenn Sie drücken.
Der zweite Punkt ist die Signalverzögerung. Wir glauben, dass ein paar Sekunden sehr gut sind, 10 Sekunden erträglich sind, 20-30 Sekunden sehr schlecht sind. Warum ist es wichtig? Für Konzerte und einige öffentliche Veranstaltungen ist dies beispielsweise eine absolut unwichtige Metrik. Es gibt kein Feedback. Wir zeigen nur den Stream - es ist besser, nicht zu verzögern als eine leichte Verzögerung. Und für einen Stream, in dem eine Art Konferenz stattfindet oder eine Person etwas erzählt und ihm Fragen stellt, wird dies wichtig, da sie in den Kommentaren viele Fragen stellt und ich möchte, dass das Publikum so früh wie möglich Feedback erhält.

Eine weitere wichtige Metrik sind Pufferung und Verzögerungen. Tatsächlich ist diese Metrik nicht nur aus Sicht des Kunden und der Qualität wichtig, sondern auch aus der Sicht, wie stark wir die Bereitstellung von HLS „strecken“ können und wie viel wir Daten von unseren Servern komprimieren können. Daher überwachen wir sowohl die durchschnittliche Pufferzeit in den Spielern als auch den „Stahl“.

Die Wahl der Qualität bei den Spielern ist verständlich: Unerwartete Änderungen sind immer ärgerlich.

Dementsprechend ist dies auch eine wichtige Metrik.

Überwachung

Wir haben viele Überwachungsmetriken, aber hier habe ich die Metriken ausgewählt, die immer funktionieren, wenn etwas schief geht:

-, . - , . , – , ( , – ).
/ . , , , , , . .
edge-. , , edge- .

«», ?

Jetzt erzähle ich Ihnen, wie wir mit einer Anwendung wie "Player" umgegangen sind, als wir unsere Infrastruktur zum Senden eines Videostreams mit Fragen und Antworten verwendet haben.

Clover ist ein Online-Quiz. Der Gastgeber sagt etwas, fragt: Fragen fallen heraus - Sie antworten. 12 Fragen, 10 Minuten des Spiels, am Ende - eine Art Preis. Was ist so kompliziert? Das ist Wachstum!

Rechts ist dieses Diagramm: Der

Peak [im Diagramm] ist die Belastung der Server in Bezug auf die API zum Zeitpunkt des Starts von „Clover“. Der Rest der Zeit ist der übliche Sendungsstrom. Dies kann nicht mit der Anzahl der Zuschauer gleichgesetzt werden. Vielleicht ist dies die Anzahl der Anfragen und die Last.

Es ist schwer: In 5 Minuten kamen eine Million Zuschauer auf dem Gipfel zu uns. Sie beginnen, die Sendung anzusehen, sich zu registrieren, eine Aktion auszuführen, ein Video anzufordern ... Es scheint ein sehr einfaches Spiel zu sein, aber dies geschieht in sehr kurzer Zeit (alle Aktionen, einschließlich des letzten Spiels) - dies ergibt eine ziemlich hohe Belastung.

Vor welchen Fragen und Herausforderungen standen wir?

Schnelles Wachstum. Manchmal waren es + 50% pro Woche. Wenn Sie zum Beispiel am Mittwoch 200.000 Menschen haben, dann könnten es am Samstag oder Sonntag bereits 300 gewesen sein. Das ist viel! Es treten Probleme auf, die zuvor nicht sichtbar waren.
2 . . , . , , , , , .
12 . , , , , , - , , …
, . , , 200-300 , 400-500.
- , , , 3-5 . ? «», , , , .

( 3 , ), , 3-5 . ? – , – exponential backoff, .

exponential on backoff: – , 2 , 4, 8. backend-.

«»?

-, . , – .
« ». , , , , «». , , -, , -, .
, – , «» . «». , , , … – . 10% «» – , 10% «» 100 – .
«» , , «» . – - . 100 – , 1 15 – .
. «» , , , . , , .
. , . , latency, .
. – , .
«» 1 . , , . . , , . .

?

Architektur passt perfekt zu uns und ich kann sie nur empfehlen. HLS bleibt bei uns das Hauptprotokoll für mindestens die Website und mindestens das Sicherungsprotokoll für alles andere. Vielleicht wechseln wir zu MPEG-DASH.

Verlassenes RTMP. Trotz der Tatsache, dass es eine geringere Verzögerung gibt, haben wir beschlossen, das HLS zu optimieren. Ziehen Sie möglicherweise andere Lieferfahrzeuge in Betracht, einschließlich DASH als Alternative.

Wir werden das eingehende Gleichgewicht verbessern. Wir möchten auch ein nahtloses Failover für den eingehenden Ausgleich durchführen, damit bei Problemen auf einem der Medienserver für den Client die Umschaltung vollständig unsichtbar ist.

Vielleicht entwickeln wir Liefersysteme vom Edgeserver zum Client. Höchstwahrscheinlich wird es eine Art UDP sein. Welches - wir denken jetzt und befinden uns in der Forschungsphase.

Eigentlich ist das alles. Danke an alle!

Fragen

Frage des Publikums (im Folgenden - A): - Vielen Dank für den Bericht! Nur der Sprecher von Odnoklassniki sprach und er sagte, dass sie den Streamer, den Encoder, den Encoder neu schreiben müssten ... Verwenden Sie solche Lösungen oder die Standardlösungen auf dem Markt (wie Harmonic usw.)?

MR: - Jetzt haben wir Lösungen von Drittanbietern. Von den von uns verwendeten Open-Source-Lösungen hatten wir (lange Zeit) nginx, das RTMP-Modul. Einerseits hat er uns gefallen, weil er ganz einfach gearbeitet hat. Wir haben sehr lange gekämpft, damit er stabil arbeitet. Jetzt wechselt er von Nginx-RTMP zu seiner eigenen Lösung. Wir denken jetzt mit einem Transcoder. Der Empfänger, nämlich der empfangende Teil, wurde ebenfalls von Nginx-RTMP in seine Lösung umgeschrieben.

UND:- Ich wollte eine Frage zum Schneiden von RTMP auf HLS stellen, aber so wie ich es verstehe, haben Sie bereits geantwortet ... Sagen Sie mir, sind Ihre Lösungen Open Source?

MR: - Wir erwägen, es in Open Source zu veröffentlichen. Wir möchten es lieber veröffentlichen, aber die Frage ist der Zeitpunkt der Veröffentlichung in Open Source. Stellen Sie einfach die Quelle ins Internet - das reicht nicht aus. Sie müssen überlegen, einige Beispiele für die Bereitstellung erstellen. Und zu welchem Zweck fragst du? Möchte benutzen?

A: - Weil ich auch auf Nginx-RTMP gestoßen bin! Es wird, gelinde gesagt, sehr lange nicht unterstützt. Der Autor beantwortet nicht einmal bestimmte Fragen ...

MR: - Wenn Sie möchten, können Sie an die Mail schreiben. Für den Eigenbedarf geben? Wir können uns einigen. Wir haben wirklich vor, es zu öffnen.

UND:- Sie sagten auch, dass Sie von HLS zu DASH wechseln können. HLS passt nicht?

MR: - Dies ist eine Frage darüber, was wir können oder vielleicht nicht. Es hängt stark davon ab, worauf wir bei der Erforschung alternativer Übermittlungsmethoden (d. H. UDP) eingehen werden. Wenn wir etwas „völlig“ Gutes finden, werden wir HLS wahrscheinlich nicht berühren. Wenn es scheint, dass MPEG-DASH komfortabler ist, verschieben wir es möglicherweise. Es scheint nicht sehr schwierig zu sein, aber wir sind uns nicht sicher, ob es notwendig ist oder nicht. Die Synchronisation zwischen Streams, zwischen Qualitäten und anderen Dingen ist dort deutlich besser. Es gibt Pluspunkte.

A: - In Bezug auf Warnungen. Sie haben darüber gesprochen, dass wenn Streams nicht mehr gestreamt werden, dies sofort eine Warnung ist. Und Sie haben nichts Unabhängiges von Ihnen gefangen: Der Anbieter ist gefallen, Megafon ist gefallen, und die Leute haben aufgehört zu streamen? ..

MR:- Sagen wir einfach, dass etwas, das von uns unabhängig ist, im Grunde alle Arten von Feiertagen ist und so weiter. Ja das taten sie. Ja, das haben sie. Die Administratoren schauten - heute sind die Feiertage, der Rest der Merkmale ist in Ordnung - sie beruhigten sich.

A: - Und über Skalierung. Auf welcher Ebene skaliert es? Ich habe zum Beispiel nach einem Stream vom Telefon gefragt - erhalte ich sofort einen bestimmten Link mit dem richtigen Ascheserver?

MR: - Ein Link wird sofort hergestellt und wechselt Sie bei Bedarf (wenn auf einem bestimmten Server Probleme auftreten).

A: - Wer wechselt?

MR: - Mobile Player oder Web Player.

A: - Er wird den Stream neu starten oder was?

MR: - Ein neuer Link wird zu ihm kommen, wo er live streamen soll. Er wird dorthin gehen und den Strom erneut fragen.

UND:- Auf welcher Ebene haben Sie Caches? Und Wiedergabelisten und Chunks oder nur das? ..

MR: - Und Playlists, Chunks! Es wird ein wenig anders zwischengespeichert, sowohl in Bezug auf die Zeit als auch in Bezug auf die Rückkehr der Zeit, aber wir zwischenspeichern beide.

A: - In Bezug auf die Schaffung von Ascheservern? Hatten Sie eine solche Situation, dass Sie 2 Millionen Zuschauer in einer Sendung sehen, keine Zeit für etwas haben und schnell einen Ascheserver abholen? Oder erhöhen Sie alles im Voraus mit einer Marge?

Herr:- Vielleicht war das nicht. Erstens ist der Bestand immer klein oder groß - es spielt keine Rolle. Zweitens kommt es nicht vor, dass eine Sendung plötzlich sehr beliebt wird. Wir können die Anzahl der Zuschauer gut vorhersagen. Grundsätzlich müssen wir uns anstrengen, um viele Menschen zu haben. Dementsprechend können wir die Anzahl der Zuschauer der Sendung anpassen, je nachdem, welche Anstrengungen unternommen werden.

A: - Sie sagten, dass Sie instrumentelle Verzögerungen seitens des Spielers messen. Wie?

MR: - Sehr einfach. In Chunks (in den Mediensegmenten) haben wir einen Zeitstempel im Namen des Mediensegments - im Player geben wir ihn einfach zurück. Wenn er überhaupt nicht explizit ist, kehrt er zurück.

A: - Ich erinnere mich, dass ich versucht habe, Peering auf WebRTC auszuführen. Warum abgelehnt?

Herr:"Ich kann diese Frage nicht für dich beantworten - es ist ohne mich passiert." Ich kann nicht sagen, warum ich es versucht habe und ich kann nicht sagen, warum ich es abgelehnt habe.

A: - In Bezug auf den Empfänger und den Medienserver. So wie ich es verstehe, hatten Sie früher Nginx-RTMP, jetzt haben Sie sowohl dort als auch dort selbst erstellte Lösungen. Tatsächlich ist dies ein Medienserver, der andere Medienserver als Proxy verwendet, und diese befinden sich bereits im Cache und am Rand.

MR: - Also nicht wirklich. Dies ist eine selbst erstellte Lösung, die sich jedoch sowohl in Bezug auf einen Medienserver als auch in Bezug auf einen Empfänger unterscheidet. Nginx-RTMP - es war eine Art Harvester, der beides konnte. Unsere Innenräume des Empfängers und des Medienservers sind sehr unterschiedlich - sowohl nach Code als auch durchgehend. Das einzige, was sie verbindet, ist die RTMP-Verarbeitung.

A: - Bezüglich des Ausgleichs zwischen den Kanten. Wie kommt es dazu?

MR: - Wir messen den Verkehr und senden ihn an den gewünschten Server. Ich habe die Frage nicht ein wenig verstanden ...

A: - Ich erkläre: Der Benutzer fordert eine Wiedergabeliste über den Player an. - Er gibt die relativen Pfade zu Manifesten und Chunks oder absoluten Pfaden zurück, z. B. nach IP oder Domain? ..

MR: - Die Pfade sind relativ.

A: - Das heißt, es gibt keinen Ausgleich, wenn ein Stream von einem Benutzer angezeigt wird?

MR: - Es passiert. Tricky genug. Wir können die 301. Umleitung verwenden, wenn wir den Server überlasten. Wenn wir sehen, dass dort alles völlig schlecht ist, können wir es für Segmente an einen anderen Server senden.

A: - Aber es sollte in die Logik des Spielers eingebunden werden?

Herr:- Nein, nur dieser Teil sollte nicht vernäht werden. 301. Weiterleitung! Der Spieler sollte einfach in der Lage sein, den 301. Link zu verlassen. Wir können es zum Zeitpunkt der Überlastung von der Serverseite an einen anderen Server senden.

A: - Das heißt, er fragt den Server und der Server gibt es ihm?

MR: - Ja. Dies ist nicht sehr gut, daher wird die Logik des Spielers verwendet, um Links auf den Fall eines Ausfalls eines der Server zu retweeten - dies ist bereits in der Logik des Spielers enthalten.

A: - Und Sie haben nicht versucht, nicht relativ, sondern absolut zu arbeiten: Wenn Sie den Spieler auffordern, etwas zu zaubern, finden Sie heraus, wo Ressourcen vorhanden sind und wo nicht, und geben Sie bereits Wiedergabelisten mit einem bestimmten Server an?

Herr:- Eigentlich sieht es nach einer funktionierenden Lösung aus. Wenn Sie dann gekommen wären, hätten wir beide gewogen! Die aktuelle Lösung funktioniert aber auch, sodass ich nicht wirklich von einer zur anderen springen möchte, obwohl dies möglicherweise auch wie eine funktionierende Lösung aussieht.

A: - Sag mir, ist das irgendwie freundlich zu Multicast? HLS, so wie ich es verstehe, absolut nichts ...

MR: - In der aktuellen Implementierung haben wir wahrscheinlich nichts im System mit dem Multicast in Live. Das Multicast-Konzept wird dort nicht berücksichtigt. Vielleicht gibt es irgendwo in den Tiefen der Admin-Magie etwas im Netzwerk, aber es ist vor allen verborgen und niemand weiß ...

Ein bisschen Werbung :)

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie, wie Sie eine Infrastruktur aufbauen Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?

HighLoad ++, Mikhail Raichenko (ManyChat): Fast ohne Magie oder wie einfach es ist, Terabit-Videostreams zu verbreiten