Wir haben also eine Anwendung, die nicht threadsicher ist. Einige der Bibliotheken, die es verwendet, machen eine Sperre auf Dateisystemebene. Leider funktioniert es nicht richtig und wird abstürzen und einen Fehler ausgeben, wenn die Bibliothek gleichzeitig genutzt wird. Wir können diese Bibliothek auch nicht wechseln. Um Nebenläufigkeit zu erreichen, welche ist besser? 100 Behälter in einer leistungsstarken Maschine laufen lassen oder in 100 kleine Maschinen aufteilen?
Da wir Amazon verwenden, denke ich über 100 x t2.micro-Instanzen nach, die jeweils einen Container ausführen, wobei ein c4.8x großer Rechner mit 100 Dockercontainern ausgeführt wird. Wir haben kein Problem mit der Erinnerung. Die Aufgaben sind CPU-gebunden. Aber es ist auch nicht so schwer, dass eine t2.micro-Instanz genug ist, um damit umzugehen, solange es nur eins auf einmal verarbeitet.
Ich habe mich mit einem Kollegen darüber unterhalten, welcher besser ist. Ich bevorzuge die 100 Instanzen, weil ich denke, dass die Docker-Isolation einen erheblichen Overhead darstellt. Es ist, als ob Sie nur eine Ressource haben, aber es ist in 100 Personen aufgeteilt, die die Ressource verwenden müssen. Auf der anderen Seite macht mein Kollege einen Punkt, der meiner Meinung nach gültig sein könnte. Das Erstellen eines Linux-Namespace ist leichter als das Starten eines ganzen Betriebssystems. Wenn wir also 100 Maschinen haben, haben wir 100 OS, während wir bei einer großen Maschine nur ein OS haben.
Die Sache ist, ich weiß nicht, welcher der richtige ist. Könnte jemand, der darin Wissen hat, erklären, welches besser wäre und mir einen konkreten Grund geben?
Da mir klar geworden ist, dass ich gerade eine schlechte Frage gestellt habe, werde ich versuchen, hier weitere Informationen hinzuzufügen. Um die Frage präziser zu machen, frage ich nicht wirklich, welche in meinem speziellen Anwendungsfall besser ist oder welche billiger ist. Es ist nur eine Kuriosität, dass man in Bezug auf CPU besser arbeiten wird. Stellen Sie sich vor, wir haben ein sehr großes Berechnungsproblem, und wir müssen 100 davon machen. Wir wollen sie parallelisieren, aber sie sind nicht Thread-sicher. Ist es besser, sie in 100 kleinen Maschinen oder 1 leistungsstarken Maschinen mit 100 Behältern zu machen? Welche wird schneller abgeschlossen und warum?
Wenn wir nur 1 leistungsstarke Maschinen haben, werden all diese 100 Container nicht um Ressourcen kämpfen und den gesamten Prozess verlangsamen? Und wenn es 100 kleine Maschinen sind, wird die Gesamtleistung aufgrund der Betriebssysteme oder anderer Faktoren möglicherweise langsamer sein? Jedenfalls habe ich damit keine Erfahrung. Natürlich könnte ich das versuchen, aber am Ende, da es nicht die ideale Umgebung ist (mit vielen Faktoren), wird das Ergebnis sowieso nicht autorisierend sein. Ich war auf der Suche nach einer Antwort von Leuten, die wissen, wie beide Dinge auf niedrigem Niveau funktionieren und argumentieren könnten, welche Umgebung die Aufgabe schneller erledigen würde.
Die einzige "passende" Antwort auf Ihre Frage ist: Sie müssen beide Optionen testen und herausfinden, welche besser ist. Der Grund dafür ist: Sie führen eine sehr spezifische Anwendung mit einer sehr spezifischen Arbeitslast und sehr spezifischen Anforderungen. Jede Empfehlung ohne tatsächliche Tests ist eine Vermutung. Vielleicht eine "fundierte Vermutung", aber nicht mehr als das.
Lassen Sie mich Ihnen zeigen, was ich bei meiner Analyse für ein solches Szenario beachten würde.
Der Docker-Overhead sollte absolut minimal sein. Das Tool "Docker" selbst macht nichts - es verwendet nur normale Linux-Kernel-Funktionen, um eine isolierte Umgebung für Ihre Anwendung zu erstellen.
Nachdem das Betriebssystem hochgefahren ist, wird etwas Speicher belegt, richtig. Aber der CPU-Verbrauch durch das Betriebssystem selbst sollte vernachlässigbar sein (selbst für sehr kleine Instanzen). Da Sie erwähnt haben, dass Sie keine Probleme mit dem Speicher haben , können wir davon ausgehen, dass dieser "Betriebssystem-Overhead", den Ihr Kollege erwähnte, wahrscheinlich ebenfalls vernachlässigbar wäre.
Wenn Sie die Route als "viele sehr kleine Instanzen" betrachten, können Sie auch den kürzlich veröffentlichten t2.nano -Instanztyp verwenden. Sie müssen testen, ob genügend Ressourcen vorhanden sind, um Ihre Anwendung tatsächlich auszuführen.
Wenn Sie die Route als "eine einzelne sehr große Instanz" betrachten, sollten Sie auch die c4.8xl -Instanz berücksichtigen. Dies sollte Ihnen deutlich mehr CPU-Leistung als die c3.8xl geben.
Kostenanalyse (Preise in us-east-1):
Analysieren Sie nun die Anzahl der Ressourcen, die Sie für jedes Setup zur Verfügung haben. Ich konzentriere mich nur auf CPU und ignoriere Speicher, da Sie erwähnt haben, dass Ihre Anwendung nicht speicherhungrig ist:
Schließlich analysieren wir die Kosten pro Ressource
Wie Sie sehen, bieten größere Instanzen typischerweise eine höhere Rechendichte, die normalerweise weniger teuer ist.
Sie sollten auch die Tatsache berücksichtigen, dass die T2-Instanzen "berstbar" sind, da sie für einige Zeit über ihre Basisleistungen (10% und 5% wie oben) hinausgehen können, je nachdem wie viel "CPU-Credits" sie haben . Sie sollten jedoch wissen, dass, obwohl sie mit einem Guthaben beginnen, es normalerweise ausreicht, um das Betriebssystem hochzufahren, und nicht viel mehr (Sie würden mehr CPU-Credits im Laufe der Zeit sammeln, wenn Sie Ihre CPU nicht über Ihre Baseline hinaus schieben) , aber es scheint, dass dies hier nicht der Fall sein wird, da wir für die Leistung optimieren ...). Und wie wir gesehen haben, ist die "Kosten pro Ressource" fast dreimal so hoch wie die der 8xl-Instanzen. Dieser kurze Burst, den Sie erhalten werden, würde wahrscheinlich diese grobe Schätzung nicht ändern.
Sie sollten auch die Netzwerknutzung in Betracht ziehen. Ist das Anwendungsnetzwerk intensiv? Entweder bei Latenzanforderungen oder Bandbreitenanforderungen oder in der Anzahl der Pakete pro Sekunde?
Was ist nun mit Ausfallsicherheit ? Wie zeitkritisch sind diese Jobs? Was wären die "Kosten, um sie nicht rechtzeitig fertig zu stellen"? Sie können auch einige Fehlermodi in Betracht ziehen:
Um den Effekt von "Ein einziges Mal sterben" auf Ihre Arbeitslast zu reduzieren und dennoch Vorteile durch höhere Dichte zu erhalten (dh große c3- oder c4-Instanzen), könnten Sie andere Optionen in Betracht ziehen, wie zum Beispiel: 2x c4.4xl oder 4x c4.2xl und so weiter. Beachten Sie, dass c4.8xl doppelt so viel wie c4.4xl kostet, aber mehr als zweimal die Anzahl der vCPUs enthält. Die obige Analyse wäre also nicht "linear", Sie müssten einige Kosten neu berechnen.
Wenn Sie davon ausgehen, dass die Instanzen "fehlerhaft" sind und Ihre Anwendung damit umgehen kann, sollten Sie auch Spot-Instanzen verwenden. Bei Spot-Instanzen geben Sie Ihren Preis an. Liegt der "Marktpreis" (geregelt durch Angebot - Nachfrage) unter Ihrem Gebot, erhalten Sie die Instanz und zahlen nur den "Marktpreis". Wenn der Preis über Ihrem Gebot schwankt, werden Ihre Instanzen beendet. Es ist nicht ungewöhnlich, bis zu 90% Rabatt im Vergleich zu On Demand zu sehen. Ab sofort beträgt c3.8xl ungefähr 0.28 $ / h in einem AZ (83% weniger als On Demand) und c4.8xl ist ungefähr gleich in einem AZ (83% weniger). Spotpreise sind für t2-Instanzen nicht verfügbar.
Sie können auch Spotblock in Betracht ziehen, in dem Sie die Anzahl der Stunden angeben, für die Sie Ihre Instanzen ausführen möchten. Sie zahlen normalerweise 30% - 45% weniger als On Demand und es gibt keine Risiko, während des von Ihnen angegebenen Zeitraums "auszufallen". Nach dem Zeitraum sind Ihre Instanzen beendet.
Schließlich würde ich versuchen, meine Serverflotte so zu skalieren, dass sie für eine "volle Anzahl von Stunden" (aber nicht mehr als diese Anzahl) benötigt werden (es sei denn, ich muss die Ausführung beenden ASAP ). Das heißt, es ist viel besser, eine kleinere Flotte zu haben, die die Aufträge in 50 Minuten erledigt, als eine größere, die in der Lage ist, den Auftrag in 10 Minuten zu erledigen. Der Grund ist: Sie bezahlen stundenweise, zu Beginn der Stunde. Außerdem ist es in der Regel wesentlich besser, eine größere Flotte zu haben, die die Arbeit in 50 Minuten erledigt als eine kleinere, die 1h05 Minuten benötigt - wieder, weil Sie stundenweise bezahlen, zu Beginn der Stunde.
Schließlich erwähnen Sie, dass Sie nach "der besten Leistung" suchen. Was genau meinst du damit? Was ist Ihr wichtiger Leistungsindikator ? Möchten Sie optimieren, um die insgesamt verbrachte Zeit zu reduzieren? Vielleicht die Zeit "pro Einheit" / "pro Job" reduzieren? Versuchen Sie, Ihre Kosten zu senken? Versuchen Sie, "energieeffizienter" zu sein und Ihren CO2-Fußabdruck zu reduzieren? Oder vielleicht für den Wartungsaufwand optimieren? Oder konzentrieren Sie sich auf die Vereinfachung, um die Anlaufzeit zu verkürzen, die andere Kollegen, die weniger gut informiert sind, benötigen würden, bevor sie in der Lage wären, die Lösung aufrechtzuerhalten?
Vielleicht eine Kombination vieler der obigen Leistungsindikatoren? Wie würden sie kombinieren? Es gibt immer einen Kompromiss ...
Wie Sie sehen, gibt es keinen clear Gewinner. Zumindest nicht ohne genauere Informationen über Ihre Anwendung und Ihre Optimierungsziele. Aus diesem Grund ist die beste Option für jede Art von Leistungsoptimierung das Testen. Testen ist in der Regel auch kostengünstig: Es würde vielleicht ein paar Stunden dauern, um Ihre Umgebung einzurichten, und dann wahrscheinlich weniger als $ 2 pro Stunde.
Also, das sollte Ihnen genug Informationen geben, um Ihre Untersuchung zu beginnen.
Viel Spaß beim Testen!
Basiert auf EC2-Instanzen-CPU allein
t2.micro haben weniger als 1/3 der CPU-Leistung von c4.8xl
t2.small haben weniger als 2/3 t2.large kommen vielleicht näher. Es ist ziemlich wahrscheinlich, dass c4.8xl viel schneller wäre, aber niemand kann das autoritär sagen. Als beginnt Bruno mit , Sie müssen Ihre Workload durch Ihre App auf beiden Instanztypen laufen lassen. Es gibt 1000 Variablen, die die Ergebnisse beeinflussen könnten. Es gibt keinen unmittelbaren Grund, warum Sie nicht 100 Container / Prozesse auf einem Linux-Host ausführen können, sondern schon seit langer Zeit Multi-Core-, Multi-Prozess. Es kann einige einfache Systemgrenzen geben, die während des Betriebs angepasst werden müssen ( ulimit -a und sysctl -a ). Auf der anderen Seite kann etwas in Ihrer Anwendung in diesem Setup wirklich schlecht sein.
Jeder Docker-Overhead wird praktisch aufgehoben, wenn Sie einen Container sowohl in Ihrem Einzel- als auch in Ihrem Multiinstance-Setup ausführen. Alles, was Sie in diesem Bereich verbessern können, wird dazu beitragen, die Probleme zu begrenzen, die Sie auf dem freigegebenen Host haben. IBM hat einen großartigen Bericht Aktualisierten Leistungsvergleich virtueller Maschinen veröffentlicht und Linux Containers , die Docker Overheads detailliert darstellen.
net=host . Ein großer Unterschied zu vielen Docker-Containern ist, dass die Arbeitslast auf dem Prozess-Scheduler der VM völlig anders ist. Es wird nicht unbedingt schlimmer, wenn Sie mehr Container fahren, aber Sie befinden sich in einem "weniger getesteten" Gebiet. Sie verlassen sich weniger auf den Xen-Hypervisor, der auf der Hardware läuft, und mehr auf den Linux-Kernel, der in der VM zum Planen ausgeführt wird, der zwei völlig unterschiedliche Algorithmen verwendet. Auch hier ist Linux in der Lage, viele Prozesse auszuführen und Konflikte zu lösen, aber Sie werden nur die Antwort für Ihre App finden, indem Sie es testen.
Also bei einer vollständigen Schätzung, die Ihre Anwendung in keiner Weise berücksichtigt, rein auf allgemeine Maschinenspezifikationen und eine CPU-schwere Arbeitslast.
c4.8xl sollte schneller sein als ein t2.nano und t2.micro setup. t2.small s könnte sich schließen. t2.large s mit 2 Containern könnte gleichrangig sein. m3.mediums würde es blitzen. c4.8xl gibt Ihnen den schnellsten Prozessor-Hyper-Thread, der jedem Prozess / Thread Ihrer App gewidmet ist. tl; dr Testen Sie alle. Verwenden Sie die schnellste.
In einem allgemeinen Fall würde ich Docker verwenden. Einfach weil es einfacher und schneller ist, Knoten hinzuzufügen / zu ändern / zu entfernen und Load Balancing durchzuführen. Ich gehe hier davon aus, dass Sie nicht genau 100 Knoten benötigen, sondern eine sich ändernde Anzahl von ihnen.
Es ist auch viel schneller einzurichten. Es gibt etwas, das Docker-Schwarm heißt Ссылка und ich bin mir sicher, dass es sich lohnt, einen Blick darauf zu werfen. Wenn Sie keine 100, 1000 oder 10000 Container auf einer physischen Maschine (VM sogar?) Platzieren können, können Sie sie auch mit dem Overlay-Netzwerk Ссылка
BEARBEITEN: Nachdem Sie die Frage erneut gelesen haben, scheint es, dass Sie eine eher leistungsbezogene Antwort wünschen. Es ist wirklich schwer zu sagen (wenn nicht unmöglich) ohne zu testen. Bei der Performance gibt es immer Vorbehalte und Dinge, an die man nicht denken kann (auf einem einfachen Konto, Mensch zu sein :)). Für das Einrichten von 100 oder 3 oder 999999 Geräten ist es viel mehr Zeit, die gleiche Anzahl an Docker-Containern einzurichten. Ich weiß, dass die Container / Bild-Terminologie immer noch durcheinander gebracht wird, um nur zu verdeutlichen - Sie würden ein Docker-Image erstellen, was ein wenig Arbeit ist, und es dann in N-Instanzen (Container) ausführen. Jemand korrigiert mich bitte für die Terminologie, wenn ich falsch liege - das ist etwas, was ich oft mit Kollegen diskutiere:)
Tags und Links linux concurrency parallel-processing docker amazon-ec2