Wann sollte man über Skalierbarkeit nachdenken? [geschlossen]

Ich habe ein lustiges, aber auch schreckliches Problem. Ich bin dabei, eine neue (iPhone) App zu starten. Es ist ein rundenbasiertes Multiplayer-Spiel, das auf meinem eigenen Backend läuft. Aber ich habe Angst zu starten.

Aus irgendeinem Grund denke ich, dass es etwas Großes werden könnte und dass seine Popularität meine arme einsame Einzelserver- + MySQL-Datenbank töten wird.

Einerseits denke ich, dass ich besser vorbereitet sein und eine skalierbare Infrastruktur bereits haben sollte, wenn es wächst.

Auf der anderen Seite möchte ich es einfach in die Welt bringen und sehen, was passiert.

Ich lese oft Dinge wie "Vorzeitige Optimierung ist die Wurzel allen Übels" oder Leute, die sagen, Sie sollten jetzt einfach Ihr Killerspiel mit den vorhandenen Tools erstellen und sich später um andere Dinge wie Skalierbarkeit kümmern.

Ich würde gerne einige Meinungen dazu von Experten oder Leuten mit Erfahrung damit hören. Vielen Dank!

Es ist eigentlich eine ziemlich einfache Wahl.

Im Moment haben Sie keine Benutzer und die Skalierbarkeit ist kein Problem.

Idealerweise möchten Sie den Punkt erreichen, an dem Sie Millionen von Benutzern haben, und die Skalierbarkeit wird zu einem Problem.

Im Moment haben Sie kein Skalierbarkeitsproblem. Sie haben ein Problem mit der Anzahl der Benutzer. Wenn Sie an dem Skalierbarkeitsproblem arbeiten, können Sie das Problem mit der Anzahl der Benutzer nicht beheben. Dies bedeutet, dass Sie ein Problem gelöst haben, das Sie noch nicht haben, und dass Sie das Problem, das Sie haben, nicht gelöst haben. Das wahrscheinlichste Ergebnis ist, dass Ihr Produkt es nicht schafft und Ihre gesamte Arbeit umsonst ist.

Wenn Sie auf die Nummer-of-Benutzer Problem zu umgehen, lösen Sie ein Problem , das Sie jetzt haben, und dann können Sie sich auf das nächste Problem konzentrieren, die Skalierbarkeit sein könnte.

Das Schöne an Skalierbarkeitsproblemen ist, dass per Definition normalerweise das Geschäft verdammt gut läuft, und dies bedeutet wiederum, dass Sie es sich leisten können, Geld für die Optimierung der Skalierbarkeit auszugeben. Sie wechseln nicht über Nacht von null auf zehn Millionen Benutzer, und wenn Sie die Leistung des Systems im Auge behalten, haben Sie genügend Zeit, um die Zeit zu optimieren.

Natürlich hilft es, die Skalierbarkeit beim Schreiben des Codes zu berücksichtigen, den Sie gerade benötigen, aber es macht nicht viel Sinn, Dutzende oder sogar Hunderte von Arbeitsstunden für eine Funktion aufzuwenden, von der Sie nicht wissen, ob Sie es sind Ich werde es jemals brauchen, und das wahrscheinlichste Szenario ist, dass Sie es nicht tun werden. Im Moment ist Ihr Hauptanliegen der Versand. Was passiert danach? Nun, darüber können Sie sich später Sorgen machen.

Es gibt keinen Grund zur Optimierung, bis Sie wissen, dass eine Optimierung erforderlich ist. Woher wissen Sie, dass eine Optimierung erforderlich ist? Sie messen.

Angenommen, Ihr Server verfügt über eine webbasierte Oberfläche, können Sie viele Benutzer mithilfe von Tools wie Apache JMeter simulieren . Erfahren Sie, wie Sie das Tool verwenden, und beginnen Sie dann mit dem Stresstest Ihres Backends. Sie sollten in der Lage sein, genug zu lernen, um die Grenzen Ihres Systems zu kennen. Sie können diese Informationen dann mit der Anzahl der Benutzer und der durchschnittlichen Anzahl der gleichzeitig ausgeführten Benutzer kombinieren, um zu entscheiden, wann die Skalierung erfolgen soll.

TL; DR Sie sollten über die Skalierbarkeit nachdenken, bevor die erste Codezeile geschrieben wird.

Das wichtigste zuerst. Skalierbarkeit! = Optimierung

Sie sollten über die Skalierbarkeit nachdenken, bevor die erste Codezeile geschrieben wird. Dies bedeutet nicht, dass Sie eine massive Infrastruktur aufbauen, wenn die Wahrscheinlichkeit gering ist, dass Ihr Spiel ein Hit wird. Über Skalierbarkeit nachzudenken bedeutet:

• Stellen Sie sicher, dass der Code so geschrieben ist, dass er skaliert. Ich habe viele Projekte gesehen, bei denen nicht daran gedacht wurde, skaliert werden zu müssen. Das Ergebnis ist eine Codebasis, die unabhängig von der Hardware, die Sie verwenden, nicht skaliert werden kann oder deren Skalierung unerschwinglich teuer ist.
• Finden Sie Ihre Skalierungsstrategie heraus. Planen Sie, wie Sie alle Benutzer unterstützen können. Sie haben eine MySQL-Datenbank, werden Sie sie oder einen Cluster oder etwas anderes sharden. Strategien wie Sharding erfordern einige Überlegungen, da sie Anforderungen an die Architektur stellen. Clustering, weniger. Unterstützen Sie Sitzungen und wie reagieren Sitzungen mit mehreren Front-End-Servern? Benötigen Sie Sticky Sessions in Ihrem Load Balancer?
• Implementieren Sie die Implementierungsstrategie. Verwenden Sie AWS für die Skalierung? Können Sie Produkte oder Dienstleistungen nutzen, die Ihnen sofort eine dynamische Skalierung ermöglichen? Dazu gehört auch das Verständnis Ihrer Kosten.

ABER es hört sich so an, als hätten Sie bereits eine Codebasis. Die Frage ist nun, wann mit der Skalierung begonnen werden soll. Dies hängt vollständig von Ihrem Code ab.

Wenn sich Ihr Code für die Skalierung eignet, haben Sie den schwierigen Teil erledigt. Sie können ein AWS-Konto einrichten, Server nach Bedarf hochfahren und loslegen.

Wenn Ihr Code nicht skaliert oder Engpässe aufweist , müssen Sie noch arbeiten. Sie müssen Ihre Engpässe identifizieren und beheben. Das "Wann" ist wirklich schwer zu wissen. Einige Dienstleistungsplateaus, andere steigen stetig an und andere explodieren. Die Entscheidung, wann Ressourcen auf so etwas wie Skalierung geworfen werden sollen, hängt normalerweise vom Geschäft und der Bewertung der Risiken ab.

In Ihrer Position könnte ich als "Beta" veröffentlichen und die Benutzererwartungen verwalten. Auf diese Weise kann ich das Produkt herausholen und sehen, wie es sich entwickelt.

Es gibt also zwei Fälle, in denen Sie über Skalierbarkeit nachdenken sollten.

Zuerst sollte vorsichtig darüber nachgedacht werden, bevor Sie eine einzelne Codezeile schreiben. Dies soll sicherstellen, dass Sie sich nicht in ein Skalierbarkeitsloch schreiben und dass Ihr Code so instrumentiert ist, dass Sie die Messungen erhalten, die Sie zum zweiten Mal benötigen.

Das zweite Mal, um die Skalierbarkeit in Betracht zu ziehen, ist genug, um die Dinge unannehmbar langsam voranzutreiben. Das heißt, Sie müssen wissen, was "zu langsam" bedeutet und wie Ihr Ding unter Last reagiert. Wenn Sie einen Dienst haben, dessen Treiber (wahrscheinlich qps) um N% pro Monat zunimmt, haben Sie andere Zeiten als "95% der verbrauchten Maschinenressourcen", wenn Ihre Ressourcennutzung im Quadrat oder linear ist.

Bei einem rundenbasierten Spiel sollten Sie einen angemessenen Sicherheitsspielraum haben (Sie haben wahrscheinlich keine einzige Spielwelt, und wenn Sie dies tun, gibt es wahrscheinlich eine interne Geometrie, was bedeutet, dass Sie nicht haben, dass "jeder mit jedem interagiert" drehen "Probleme).

Ohne Einzelheiten zu kennen, würde ich ein oder zwei Tage brauchen, um darüber nachzudenken, wo Sie Skalierungsprobleme haben und welche möglichen Strategien Sie haben, um diese zu lösen. Aber das ist wichtig, denken Sie darüber nach. Nicht tun, nur denken (und dokumentieren). Sofern Sie keine Skalierbarkeitsprobleme haben, die sich bei einigen hundert Benutzern manifestieren, sollten Sie Zeit haben, die Last zu überprüfen und mehr Back-End-Ressourcen zu starten.

Aus Ihrer Beschreibung geht hervor, dass es zwei mögliche Ergebnisse gibt:

• Das Spiel ist ein Fehlschlag und dann ist es dir egal.
• Das Spiel ist erfolgreich und dann kann Ihr Backend die Last nicht bewältigen und das Ergebnis wäre ein Fehler.

Hmmm.

Hier sind einige Fragen, die Sie sich stellen sollten:

• Wie viele Benutzer kann Ihr aktuelles Backend mit akzeptabler Leistung verarbeiten?
• Haben Sie einen Plan, um die Auswirkungen auf aktuelle Benutzer zu begrenzen, wenn Sie ein schnelles Wachstum feststellen (z. B. das Spiel vorübergehend aus dem App Store ziehen)?
• Wie schnell können Sie ein besseres Backend finden, wenn Sie erfolgreich sind?
• Was sind die geschäftlichen Auswirkungen des Wartens? Kannst du dich selbst ernähren? Was sind die Risiken?
• Welche geschäftlichen Auswirkungen hat die Veröffentlichung angesichts der Antworten auf die obige Frage?

Die Antwort auf Ihre Frage sollte offensichtlich werden, wenn Sie diese berücksichtigen. Kein Experte kann Ihnen sagen, was Sie ohne weitere Informationen tun sollen, da jedes System anders ist und jedes Unternehmen anders ist.

Ihr Server wird von Benutzern interaktiv verwendet. Dies bedeutet, dass die Latenz die Benutzererfahrung auf sehr tiefgreifende Weise beeinflusst. Eine schlechte Latenz führt immer zu einer schlechten Benutzererfahrung.

Führen Sie zumindest einige Ad-hoc-Lasttests durch, wie von Bryan beschrieben.

Ein ernsthafterer Ansatz

Führen Sie einige Simulationsläufe durch und finden Sie heraus, wie sich die Latenz auf Ihre Benutzererfahrung auswirkt (entweder mithilfe einer Netzwerkverzögerungssimulation oder einfach mit sleep () in Ihrer Anwendung). Finden Sie heraus, bei welcher Latenz es spürbar, nervig und unbrauchbar wird.

Dann kommt der erste Schritt in Richtung Optimierung. Entscheiden Sie sich für eine SLA für Ihren Server: zB im schlimmsten Fall 10% Anrufe mit lästiger Latenz und 1% Anrufe mit unbrauchbarer Latenz. Mit diesen Grenzwerten können Sie mithilfe von Lasttests herausfinden, wie viele Benutzer Ihr Server unterstützen kann.

Reine Durchsatztests ohne Messung der Latenz (oder zumindest manuelle Verwendung des Servers während des Auslastungstests) sind nicht so nützlich, da Sie nicht wissen, ob die gemessenen Durchsatzzahlen zu einer erträglichen Benutzererfahrung führen.

Eine sehr schöne Präsentation über das Messen der Latenz von Gil Tene: http://www.infoq.com/presentations/latency-pitfalls

In der Phase der Geschäftsanforderungen, die dann verwendet wird, um ein gemeinsames Verständnis für die Leistung aller nachgelagerten Elemente wie Architektur, Betrieb, Entwicklung, Qualitätssicherung und Überwachung in Prod. Wenn Sie kein gemeinsames Verständnis für die Anforderungen im Vorfeld haben, müssen alle Teile der Organisation Annahmen über die Leistung treffen (oder überhaupt nicht darüber nachdenken), wenn Sie bestimmte Aufgaben über den gesamten Lebenszyklus des Unternehmens ausführen Anwendung. Dies gilt unabhängig davon, ob Sie sich mit Wasserfällen, kurzen Wasserfällen, agilen Aktivitäten oder mit der aktuellen Entwicklungsmethode beschäftigen.

Leistung und Skalierbarkeit sind schwierig. Funktionalität ist einfach. Schlechter Skalierungscode wächst, um den Ressourcenpool zu füllen, den Sie ihm zur Verfügung stellen. Wenn Sie also die Kostenblase durch den Kauf größerer Hardware verschieben, müssen Sie nur so weit gehen, bis Sie entweder den ineffizienten Code reparieren oder immer mehr Hardware kaufen müssen. Dies vorrangig zu belassen, ist ebenfalls sehr kostspielig. Es gibt Architektur- und Designentscheidungen, die zu Beginn des Lebenszyklus der Anwendung getroffen werden und möglicherweise vollständig rückgängig gemacht werden müssen, um eine spät eintreffende Leistungsanforderung zu erfüllen. Stellen Sie sich einen Hochleistungssportwagenhersteller vor, der von Aluminium auf Aluminium umsteigen muss Kohlefaser spät im Konstruktionszyklus, um ein Leistungsgewicht in Bezug auf die Leistung und die Auswirkungen auf Werkzeuge, Training, Konstruktion des Autos usw. zu erreichen.

Fragen Sie die Architekten, Entwickler und Mitarbeiter in Ihrem Unternehmen nach den Leistungsanforderungen für die Anwendung. Wenn diese nicht aus dem Geschäft erfasst werden, wundern Sie sich nicht, wenn Sie auch innerhalb derselben Gruppe unterschiedliche Antworten (oder keine Antworten) von verschiedenen Personen erhalten. Diese "Annahmen" kommen immer wieder zurück, um die Organisation bei der Bereitstellung zu schlagen.