Server Archtikturempfehlungen für spezialisierte Social Community

[derwunner]

Hallo,

ich plane für ein neues Projekt und bräuchte da bitte etwas Beratung hinsichtlich der Server Architektur. Es handel sich dabei um eine auf einen Themenbereich spezialisierte Social Community. Es kann gut ankommen, muss aber nicht. Dementsprechend möchte ich auf großen Ansturm vorbereitet sein.

Mir stellt sich allerdings die Frage, ob dafür eine MySQL/Postgre SQL Datenbank ausreichend ist. Falls nicht, stellt sich widerrum die Frage, wie das mit Slave und verteilten Knoten über das Internet mit der Sicherheit, bzw. generell mit der Handhabung beschert ist. Weiterhin habe ich gelesen, dass Apache Cassandra also NoSQL Datebank genau für solche Fälle Daten hochverfügbar zur Verfügung stellt (bzw. stellen kann). Meine einzige Idee diesbezüglich wäre mir von meinen Anbieter einen weitern Server bzw. VServer zu holen, der im gleichen Rechenzentrum steht und übers LAN zu erreichen ist.

Für Ideen, Anregungen usw. wäre ich sehr dankbar. Ich wüsste auch nicht, was ich noch dazu ausführen sollte, denn diese paar Zeilen erklären bereits meine Herausforderung.


MFG derwunner

[rkr]

Kommt drauf an
Da gibt es dieses CAP-Theorem. Sagt in deinem Fall aus, dass du nicht gleichzeitig Datenkonsistenz und Skalierbarkeit bei deiner gewünschten maximalen Verfügbarkeit über mehrere Knoten haben kannst. Welche Kante du nimmst ist eine Entscheidung, die du schon sehr früh treffen solltest.

Wenn in deiner Umgebung um Größenordungen häufiger gelesen als geschrieben wird, dann kann das mit einem Master-Slave-Setup auf Basis von PostgreSQL oder MySQL durchaus klappen. Wenn dein System auch für viele Schreibzugriffe ausgelegt sein muss, dann musst du dir ggf. eine andere Datenhaltung überlegen. MongoDB ist da eine beliebte Lösung. Fühlt sich aber in etwa so an, als würdest du von Windows 10 auf Windows 3.1 downgraden: Deine Möglichkeiten sind begrenzt, das System ist aber schnell auf moderner Hardware.

[derwunner]

rkr So weit so gut. Wie es denn unabhängig vom Datenspeichersystem um die Sicherheit beschert? Ich hätte nämlich Koliken damit (starke Magenschmerzen ist kein Ausdruck mehr dafür) den Datenaustausch zwischen den Knoten unverschlüsselt übers Internet zu übertragen. Starke Magenschmerzen hätte ich hingegen immer noch mit dem unverschlüsselten Datenaustausch über das LAN in einem Rechenzentrum. Bezüglich Datenschutz ist das Thema nicht gerade unerheblich und verdient meiner Meinung nach besonderer Aufmerksamkeit.

Ich bin noch recht unerfahren mit verteilten Systemen. Diese Technik ist allerdings nichts Neues. Es sollte sich hier also der ein oder andere finden, der mir in Punkto Sicherheit mehr erzählen kann. Ich freue mich auf weitere hilfreiche Antworten.

rkr Ja, es müssen auch viele Schreibzugriffe getätigt werden, besonders Tagsüber. Datenkonsistenz wäre nur bei Stammdaten wichtig. Skalierbarkeit ist eher Nebensache. Die Community soll Stück für Stück entstehen. Also wenn neue Komponenten hinzukommen, dann nimmt das eh Zeit in Anspruch. Aber ist das bei Webanwendungen überhaupt noch die Frage was von den drei Eigenschaften ausschlaggebend ist? Schließlich kommt es doch immer bei Webanwendungen auf Performance an, besonders bei öffentlich zugänglichen. Also ja, Hochverfügbarkeit wäre mir durchaus recht.

[rkr]

Du solltest dich grundlegend mehr mir der Architektur verteilter Systeme beschäftigen. Und du wirst lange mit einem einzelnen Server auskommen. Ab und an mal Backups machen und gut is...
Das Thema Verteilte Systeme geht WEIT über den Konfigurationsaspekt hinaus!

So weit so gut. Wie es denn unabhängig vom Datenspeichersystem um die Sicherheit beschert? Ich hätte nämlich Koliken damit (starke Magenschmerzen ist kein Ausdruck mehr dafür) den Datenaustausch zwischen den Knoten unverschlüsselt übers Internet zu übertragen. Starke Magenschmerzen hätte ich hingegen immer noch mit dem unverschlüsselten Datenaustausch über das LAN in einem Rechenzentrum. Bezüglich Datenschutz ist das Thema nicht gerade unerheblich und verdient meiner Meinung nach besonderer Aufmerksamkeit.

autossh [1] [2]
SSL [1] [2]
VPN

[Gast]

"Dementsprechend möchte ich auf großen Ansturm vorbereitet sein."
Ich sage Dir ganz ehrlich: Der wird nicht kommen - außer Du schaltest einen TV-Spot zur Prime Time.

Die Frage allein in Kombination mit der konkreten Situation zeigt, dass Du besser in die von Dir genannte Herausforderung hineinwachsen solltest, als alles auf Krampf auf größtmögliche Performance, Skalierbarkeit und was sonst noch in diese Richtung geht, auszulegen. Da macht es mehr Sinn, die eigentlich Applikation sauber zu implementieren. Aus meiner Erfahrung heraus vermute ich ganz stark, dass das Dein viel größeres Problem ist.

Und bevor jetzt einer sagt, dass ich das ja nicht wissen kann: Doch, kann ich.

[rkr]

... aber Zuckerberg
Und ja, stimme dir da voll zu.

[Perry Staltic]

Bezüglich Datenschutz ist das Thema nicht gerade unerheblich und verdient meiner Meinung nach besonderer Aufmerksamkeit.

Ich bin noch recht unerfahren mit verteilten Systemen. Diese Technik ist allerdings nichts Neues.
Datenkonsistenz wäre nur bei Stammdaten wichtig.
Skalierbarkeit ist eher Nebensache.
Die Community soll Stück für Stück entstehen.

Aber ist das bei Webanwendungen überhaupt noch die Frage was von den drei Eigenschaften ausschlaggebend ist? Schließlich kommt es doch immer bei Webanwendungen auf Performance an, besonders bei öffentlich zugänglichen.

Also ja, Hochverfügbarkeit wäre mir durchaus recht.

Vorweg, ich bin kein Web-, Performance-, Security, .. Hochverfügbarkeits-Profi, aber hier gehen einige Dinge zumindest dem Namen nach etwas durcheinander oder?
Datenkonsistenz ist immer wichtig, meinst Du vielleicht asynchrone Daten, bedingt durch mehrere Knoten?
"Skalierbarkeit ist Nebensache", das verstehe ich gar nicht. Wenn ich weiß, dass ich immer nur 1000 Nutzer hab, brauch ich kein skalierendes System / Architektur und kann mir diesen Thread sparen?
Die Community wird Stück für Stück entstehen-wenn überhaupt-, alles andere wäre ein Weltwunder. (Kann natürlich sein, dass Du Zuckerberg den Deal in Indien weggeschnappt hast und nun schnell liefern musst )
Performance, Robustheit und intuitive Bedienung ist m.E. am wichtigsten, mal abgesehen vom Nutzen führt es zu Akzeptanz und wachsenden Benutzerzahlen.
Sicherheit ist der Mehrheit vermutlich egal, sieht und spürt man (erstmal) nicht. Im Gegenteil es kostet nur Rechenpower und Performance (HTTPS,..). Außer Du bist groß geworden, hast entsprechende Bekanntheit und Fallhöhe und hostest sensible Daten.
Hochverfügbarkeit ist m.E. nicht primär eine Performancefrage, sondern primär eine Frage von 24x7 Betrieb, Ausfallsicherheit und Ausfalldauer (wie lange dauert es, Backups am Start zu haben und wie jung sind die Backups).

Sicherheit und Datenschutz kann soweit gehen, dass einzelne Server soweit "abgespeckt" sind, dass Du nur noch per Terminal Console drauf kommst. Nur um mal eine physikalische Maßnahme zu nennen.
Ansonsten gibt es tonnenweise Anforderungen, die von Architektur über Modulkonfiguration bis auf Code Ebene gehen. Auf Code Ebene ist es dann wohl zunächst mal am relevantesten. Das entwickelst Du ja nun. Konfiguration kann man immer ändern und verbessern.

Letztlich würde ich aber sagen, einfach machen -natürlich nicht mit abgeschaltetem Hirn- und hoffen, dass das System so schnell wächst (Zugriffe), dass Du dafür Leute extra einstellen musst und kannst. Ansonsten bist Du pleite, bevor Du 10 User hast. Bei der Entwicklung des Automobils hat es auch ein paar Jahre gedauert, bis der Airbag Grundausstattung war.

[rkr]

Datenkonsistenz ist immer wichtig, meinst Du vielleicht asynchrone Daten, bedingt durch mehrere Knoten?

Tatsächlich nicht. Sie wird sehr geschätzt. Wenn du bei Youtube ein Video hochlädst und in diesem Moment der Server, der dieses Video entgegennimmt ausfällt, dann ist das für den einzelnen User ärgerlich. Die Seite reagiert aber beim nächsten Klick wieder, weil sofort ein anderer Rechner einspringt. Das gleiche gilt für 90% der Informationen, die Facebook verarbeitet. Wenn Daten verloren gehen (Bilder, Kommentare, Postings), dann ist das vielleicht ärgerlich, hat jedoch keine besonderen Auswirkungen auf das Gesamtsystem.

Performance, Robustheit und intuitive Bedienung ist m.E. am wichtigsten, mal abgesehen vom Nutzen führt es zu Akzeptanz und wachsenden Benutzerzahlen.

Sehe ich ähnlich.

Sicherheit ist der Mehrheit vermutlich egal, sieht und spürt man (erstmal) nicht. Im Gegenteil es kostet nur Rechenpower und Performance (HTTPS,..). Außer Du bist groß geworden, hast entsprechende Bekanntheit und Fallhöhe und hostest sensible Daten.

Das sehe ich anders. Wenn man Sicherheit nicht schon von Anfang an prominent in das Gesamtsystem einwebt, dann hat man hinterher nur Ärger damit.

Hochverfügbarkeit ist m.E. nicht primär eine Performancefrage, sondern primär eine Frage von 24x7 Betrieb, Ausfallsicherheit und Ausfalldauer (wie lange dauert es, Backups am Start zu haben und wie jung sind die Backups).

Wenn eine Webseite 15 Sekunden zum Laden braucht, dann ist das für viele User gleichbedeutend mit einer Nicht-Verfügbarmachung der Leistung.

Auch wenn es prominente Beispiele gegeben hat, die aus wenig Fullstackkenntnis viel Erfolg generiert haben, sind das meiner Ansicht nach krasse Ausnahmebeispiele, die fast einem Lottogewinn gleichkommen. Wir haben hier in D auch nicht so eine Gründer- oder Finanzierungskultur wie in den Staaten. Wenn man nicht genau weiß, was man da tut und entsprechend viel Erfahrung hat (als Entwickler braucht man für das Erreichen der gleichen Güte einer PHP-Anwendung mindestens so viel Erfahrung wie ein Scala- oder C#-Entwickler), dann sehe ich da kaum Chancen, dass so eine Anwendung etwas wie Facebook oder StudiVZ werden könnte - und das nur aus der Perspektive der Architektur betrachtet.

[Perry Staltic]

"..Datenkonsistenz.."
Tatsächlich nicht. Sie wird sehr geschätzt. Wenn ..in diesem Moment der Server .. ausfällt, dann ist das für den einzelnen User ärgerlich. Die Seite reagiert aber .. Wenn Daten verloren gehen (Bilder, Kommentare, Postings), dann ist das vielleicht ärgerlich, hat jedoch keine besonderen Auswirkungen auf das Gesamtsystem.

Hab ich glaube ich nicht ganz verstanden, was Du da schreibst. Dateninkonsistenz sind für mich erstmal unvollständige oder widersprüchliche Daten, also an Deinem Beispiel ein Datensatz für das Bild, aber das Bild selbst fehlt (wegen Abbruch). In einem verteilten System sind dagegen vielleicht nicht immer adhoc alle Daten auf allen Knoten synchron, das würde ich aber nicht als Inkonsistenz bezeichnen.

"..Sicherheit.."
Das sehe ich anders. Wenn man Sicherheit nicht schon von Anfang an prominent in das Gesamtsystem einwebt, dann hat man hinterher nur Ärger damit.

Ich meinte an der Stelle eher die Benutzerperspektive. Ich glaube es kümmert nur wenige und vielen sind technische Zusammenhänge und Sicherheitsprobleme nicht bewusst. Und klar, wenn mein Code bspw. nicht gegen Injektion gefeit ist, hab ich irgendwann ein Problem.

Wenn eine Webseite 15 Sekunden zum Laden braucht, dann ist das für viele User gleichbedeutend mit einer Nicht-Verfügbarmachung der Leistung.

Wir haben hier in D auch nicht so eine Gründer- oder Finanzierungskultur wie in den Staaten. Wenn man nicht genau weiß, was man da tut, ... dann sehe ich da kaum Chancen, dass so eine Anwendung etwas wie Facebook oder StudiVZ werden könnte - und das nur aus der Perspektive der Architektur betrachtet.

Ok, ein überlastetes System führt natürlich auch zu einer Nichtverfügbarkeit (erst Recht ein schlecht gemachtes). Ich wollte verdeutlichen, dass Hochverfügbarkeit mehr als Performance ist.

Die Finanzierungsthematik in D ist leider ein Kapitel für sich. Ich glaube aber nicht, dass es so sehr im Vordergrund steht. Ich sehe in D vergleichsweise zu USA schon eine ausgeprägte Bedenkenträger / Sicherheitsmentalität, mit der man sich mehr selbst im Weg steht, als wirkliche technische (oder auch Finanzierungs-) Probleme zu haben. Oder andersrum, im Land der unbegrenzten Möglichkeiten wird eher einfach gemacht. Und wenn man dann damit groß wird, dann kann man mit der ganzen verdienten Kohle z.B. ein Büro gegenüber vom Regierungssitz mieten und dort Schönwetter machen, und klammert das Datenschutzthema weiter aus und wenn dann irgendwann Millionen Daten gestohlen werden, dann entschuldigt man sich halt und köpft öffentlichkeitswirksam irgendeinen Bauern aus der 2. Führungsetage... .

[Blar]

Es kann gut ankommen, muss aber nicht. Dementsprechend möchte ich auf großen Ansturm vorbereitet sein.

Wenn du das sicherstellen möchtest, auch wenn es nicht gut ankommt, hast du zuviel Geld.

Mir stellt sich allerdings die Frage, ob dafür eine MySQL/Postgre SQL Datenbank ausreichend ist.

Kann ausreichend sein, muss aber nicht. Bei mir hat es funktioniert.

Meine einzige Idee diesbezüglich wäre mir von meinen Anbieter einen weitern Server bzw. VServer zu holen, der im gleichen Rechenzentrum steht und übers LAN zu erreichen ist.

Ein vServer ist bestimmt nicht ausreichend. Entweder startest du mit einem richtigen Server, kannst später vielleicht sogar ein komplettes Rack mieten oder du versuchst es mir "richtiger" Virtualisierung, die du im Gegensatz zur einem vServer (so wie ich das noch von vor 10 Jahren kenne) genauer steuern kannst.

[derwunner]

Wenn du das sicherstellen möchtest, auch wenn es nicht gut ankommt, hast du zuviel Geld.

Damit hast du vielleicht recht, ich werde meine Anforderungen etwas zurück schrauben.

Ein vServer ist bestimmt nicht ausreichend. Entweder startest du mit einem richtigen Server, kannst später vielleicht sogar ein komplettes Rack mieten oder du versuchst es mir "richtiger" Virtualisierung, die du im Gegensatz zur einem vServer (so wie ich das noch von vor 10 Jahren kenne) genauer steuern kannst.

Nein, so meinte ich das nicht. Ich meinte einen zusätzlichen Datenbankserver in Form eines vServer. Dementsprechend als slave oder als Cluster.

So, nach der CeBIT weiß ich jetzt diesbezüglich mehr. MariaDB klang ganz gut, denn Sie versprechen das selbe wie der neue Microsoft SQL Server: Durchgängige Verschlüsselung, das heißt zwischen den Server Instanzen und im Arbeitsspeicher (also gecachte Querys usw.). Dafür kann man bei beiden auch Verschlüsselungshardware verwenden, wenn man es ganz sicher haben will.

Fazit: Als Datenbank werde ich erstmal MariaDB im Cluster verwenden von verschiedenen Hostern/Rechenzentren um Ausfallsicherheit zu haben. Zwei Server reichen völlig. Des Weiteren denke ich in Kombination mit MariaDB über Elasticsearch nach, weil ich eine in der Nähe Suche brauche. Es wird zwar kein Suchfeld geben, aber es müssen viele Spots performant gefunden werden.

[Gast]

Man möge mich schelten aber nach diesen großspurigen Ankündigungen würde mich interessieren, ob der TE berichten kann, wie es seitdem gelaufen ist.

[SirSnyder]

Starte mit einem vServer oder SingleServer. Und dann wachse Stück für Stück. Solltest du irgendwann an dem Punkt sein, an dem du zu einem (Hadoop) Cluster in InMemoryGrid wechseln musst, wirst du den finanziellen Spielraum haben um Leute dafür zu bezahlen. Richte den Fokus auf wichtigere Dinge.

[JaMa]

Ich werfe mal noch Cloud-Hosting in die Runde.

Bietet eine extrem hohe Skalierbarkeit bei geringen Einstiegskosten. Und wenn dann mal mehr Ressourcen von Nöten sind ist Cloud-Hosting recht günstig dank der Nutzungsbasierten Preisgestaltung. So kannst du z.B. nachts wenn weniger Ressourcen benötigt werden überflüssiges Abschalten und sparst dir den Betrieb in der Zeit.
Weiterer Vorteil von speizell großen Anbietern (AWS, Azure, Google) ist die globale Verfügbarkeit, also sehr einfach sind schnelle Zugriffszeiten über die Welt möglich.

Datenschutztechnisch ist das natürlich etwas bedenklich und auch von der Sicherheit her.
Mit Verschlüsselung ist das aber nicht mehr so schwerwiegend.

Wichtig ist dort eben dass man gut abstrahiert. Insbesondere z.B. die AWS API, da du dir sonst später sehr schwer tust bei einem Umstieg.

[meta02]

Hier wird mit so viel wagen argumentiert, ich komme gar nicht mehr mit:

Perry Staltic Was meinst Du mit Hochverfügbarkleit AEC-4 beispielswesei hat ca ne Sunde Ausfall pro Jahr.?

m Gegenteil es kostet nur Rechenpower und Performance (HTTPS,..).

What ? ja, alles kostet Rechenpower, aber das meinst Du nicht so, oder?

derwunner

Dementsprechend möchte ich auf großen Ansturm vorbereitet sein.

Was - in Zahlen - ist für dich ein grosser Ansturm; Durchschnitt und Peeks.

An wann hat man genug Zugriffe um Fehlimplementierungen mit Rechenleistung zu erschlagen, was ja wohl immer üblicher wird?
Alle sehen einen potentiellen Flaschenhals nur bei der DB, wieso?