Einrichten Ihrer Anwendung: Wie Sie das beste Server-Setup auswählen?

Einführung

Technologie und das Internet sind zu zentralen Bestandteilen unseres alltäglichen, akademischen und beruflichen Lebens geworden. Deshalb ist die schiere Anzahl an Websites und Anwendungen, die gleichzeitig existieren, keine Überraschung. Wenn Sie ein Unternehmen sind, möchten Sie eine zugehörige Webplattform haben. Eine Anwendung ermöglicht es Ihnen, Ihre Dienstleistungen mühelos an Ihre Zielkunden zu vermarkten und zu liefern.

Unabhängig vom Grund, warum Sie eine Webanwendung erstellen, müssen Sie bestimmen, wie Sie sie aufbauen. Es stehen Ihnen viele Optionen zur Verfügung, wenn es darum geht, das beste Server-Setup auszuwählen. Die von Ihnen gewählte Serverarchitektur bestimmt, wie Sie alles in Ihrer Umgebung ausführen und verwalten. Deshalb muss diese Entscheidung nach sorgfältiger Überlegung getroffen werden.

So wählen Sie das richtige Server-Setup aus

Wie entscheiden Sie also, welche Architektur für Ihre Anwendung „richtig“ ist? Dazu müssen Sie sich zunächst überlegen, welche Anforderungen Ihre Webanwendung hat. Es muss bestimmte Funktionen geben, die Sie integrieren müssen, damit sie für Ihren spezifischen Anwendungsfall effizient funktioniert. Vielleicht streben Sie beispielsweise eine Anwendung an, die sich leicht skalieren lässt. Oder vielleicht muss Ihre Anwendung sowohl in Browsern als auch auf Mobilgeräten reibungslos funktionieren. Gleichzeitig kann auch Ihr Budget Ihr Hauptanliegen sein.

Unabhängig von Ihren Anforderungen sollten Sie wissen, dass Sie eine maßgeschneiderte Lösung für Ihre Anwendung erstellen können. In diesem Tutorial werden wir die verschiedenen Servertypen untersuchen, die viele Menschen üblicherweise für ihre Webanwendungen verwenden. Wir werden über die verschiedenen Anwendungsfälle sprechen und darüber, wann ein bestimmtes Setup am besten geeignet ist. Um Ihnen bei der Entscheidung zu helfen, ob es für Sie geeignet ist, werden wir Ihnen auch einige Vor- und Nachteile jeder Serverarchitektur aufzeigen.

1. Alles auf einem Server

Wie der Name schon sagt, laden Sie die gesamte Umgebung auf einen einzigen Server. Die Umgebung umfasst Ihren Webserver, Ihren Anwendungsserver sowie den Datenbankserver. Es funktioniert beispielsweise auf der Linux, Apache, MySQL, und PHP-Stack-Konfiguration (LAMP). Sie können unseren Tutorials folgen, wie Sie den LAMP-Stack auf einem Ubuntu-Server installieren und wie Sie den LAMP-Stack auf CentOS installieren.

Wann man es verwendet:

Diese Art der Anordnung funktioniert am besten, wenn Sie wenig Zeit haben. Sie ist einfach und schnell einzurichten. Deshalb eignet sie sich für einfache Webanwendungen.

Vorteile:

• Einfach und leicht zu verstehen und zu implementieren.
• Es dauert nur wenig Zeit, um es vollständig einzurichten.

Nachteile:

• Ermöglicht keine horizontale Skalierbarkeit.
• Bietet nur sehr wenig in Bezug auf die Isolierung von Komponenten.
• Anwendung und Datenbank konkurrieren im Wesentlichen um dieselben Ressourcen, da sie sich auf einem einzigen Server befinden.
• Infolgedessen kann es zu einer schlechten Leistung kommen.

2. Separater Datenbankserver

Das Hauptproblem bei der Verwendung eines einzelnen Servers ist die Konkurrenz um begrenzte Ressourcen. Dieses Setup zielt darauf ab, dieses Problem zu lösen. Hier wird das Datenbankmanagementsystem oder das DBMS vom Anwendungsserver getrennt gehalten. Der Datenbankserver befindet sich in einem privaten Netzwerk und verfügt über eigene Ressourcen. Dies führt zu einer besseren Leistung und erhöhter Sicherheit.

Wann man es verwendet:

Auch hier gilt: Wenn Sie ein schnelles Setup bereitstellen möchten, ist dies ziemlich einfach zu konfigurieren. Es ist die ideale Lösung, wenn Sie befürchten, dass die Datenbank und die Anwendung um dieselben Ressourcen konkurrieren.

Vorteile:

• Separate, dedizierte Systemressourcen für die Anwendung und die Datenbank, einschließlich CPU, Arbeitsspeicher, I/O usw.
• Mehr Potenzial für Skalierbarkeit sowohl in der Anwendungs- als auch in der Datenbankebene.
• Sie können Ressourcen nach Bedarf hinzufügen und entfernen.
• Wenn Sie die Datenbank aus dem öffentlichen Internet entfernen, können Sie auch Ihre Sicherheit erhöhen.

Nachteile:

• Etwas komplexer als ein Setup mit einem einzigen Server.
• Eine geringe Bandbreite oder eine Netzwerkverbindung mit hoher Latenz zwischen den beiden Servern kann zu Leistungsproblemen führen.

3. Reverse-Proxy oder Load-Balancer

Hier kommen Load-Balancer ins Spiel. Load Balancer werden typischerweise in Serverumgebungen eingesetzt, um die Leistung und Zuverlässigkeit zu verbessern. Dies geschieht durch den „Lastenausgleich“, d. h. die Verteilung der Arbeitslast auf eine Reihe von Servern.

Wann man es verwendet:

Load Balancer sind äußerst nützlich, wenn Sie eine horizontale Skalierung durchführen müssen. Horizontale Skalierung bedeutet im Grunde, dass der Umgebung weitere Server hinzugefügt werden. Sie können auch einen Reverse-Proxy auf Anwendungsebene verwenden, um mehrere Anwendungen gleichzeitig über eine einzige Domain und einen einzigen Port bereitzustellen. HAProxy, Nginx, und Varnish sind Beispiele für Software, die einen Reverse-Proxy-Lastenausgleich ermöglichen.

Vorteile:

• Falls ein Server in der Reihe ausfällt, kompensieren die anderen Server seine Funktion, indem sie die Arbeitslast ausgleichen.
• Ermöglicht Ihnen die Durchführung einer horizontalen Skalierung, um die Kapazität der Umgebung zu erhöhen oder zu verringern.
• Es begrenzt auch die Client-Verbindungen, was Schutz vor DDOS-Angriffen bietet.

Nachteile:

• Falls die Systemressourcen nicht ausreichen, kann der Load Balancer die Leistung Ihrer Anwendung einschränken.
• Eine ordnungsgemäße Konfiguration ist erforderlich, um eine angemessene Leistung zu gewährleisten.
• Deutlich komplexer als Setups mit einem einzelnen Server oder separaten Servern.
• Sie müssen Faktoren wie die SSL-Terminierung und Anwendungen, die Sticky Sessions benötigen, berücksichtigen.
• Der Hauptschwachpunkt bei der Verwendung von Load Balancern ist, dass sie einen Single Point of Failure darstellen. Das bedeutet: Wenn der Load Balancer ausfällt, bricht Ihr gesamter Dienst zusammen.

4. HTTP-Beschleuniger oder Caching-Reverse-Proxy

Dies ist ein Setup, mit dem Sie die Geschwindigkeit erhöhen können, mit der Sie Inhalte an einen Benutzer Ihrer Anwendung ausliefern. Es nutzt verschiedene Techniken, um diese Zeit zu verkürzen. Die wichtigsten davon ist das Zwischenspeichern (Caching) der Antwort vom Anwendungsserver. Der Beschleuniger speichert den Inhalt in seinem Speicher, wenn ein Benutzer ihn zum ersten Mal anfordert. Wenn also in Zukunft ähnliche Anfragen eingehen, stellt er den Inhalt schnell bereit, ohne mit dem Anwendungsserver zu interagieren. Sowohl Nginx, Varnish als auch Squid sind in der Lage, eine HTTP-Beschleunigung.

Wann man es verwendet:

Verständlicherweise eignet sich dieses Setup am besten für Dateien und Inhalte, die von Benutzern sehr häufig angefordert werden. Es funktioniert auch sehr gut für dynamische Webanwendungen mit hohem Content-Anteil.

Vorteile:

• Caching und Komprimierung erhöhen die Geschwindigkeit der Anwendung und der Anfrageverarbeitung erheblich.
• Die Verringerung der CPU-Last verbessert ebenfalls die Leistung der Website.
• Sie können dies auch als Reverse-Proxy-Load-Balancer verwenden.

Nachteile:

• Sie müssen es gut abstimmen, um die beste Leistung herauszuholen.
• Bei einer niedrigen Cache-Hit-Rate kann es zu einer schlechten Leistung kommen.

5. Primary-Replica-Datenbankreplikation

Ein Primary-Replica-Datenbankreplikations-Setup ist in der Regel sehr nützlich für Systeme, die mehr Lese- als Schreibzugriffe durchführen. Beispielsweise können Content-Management-Systeme eine solche Architektur hervorragend nutzen. Für die Replikation benötigen Sie einen Primary- und einen oder mehrere Replikationsknoten. Die Lesezugriffe werden auf alle Knoten verteilt. Die Aktualisierungen gehen nur an den Primary-Knoten.

Wann man es verwendet:

Wie bereits erwähnt, trägt ein replikationsbasiertes Datenbank-Setup dazu bei, die Leseleistung eines Systems zu verbessern. Sie können es für Anwendungen wie CMS verwenden.

Vorteile:

• Es verbessert die Leseleistung der Datenbank, da diese auf die Replikate verteilt wird.
• Wenn Sie den Primary-Knoten nur für Aktualisierungen verwenden, können Sie auch die Schreibleistung verbessern.

Nachteile:

• Jede Anwendung, die versucht, auf die Datenbank zuzugreifen, muss in der Lage sein, zu entscheiden, an welchen Knoten sie Aktualisierungen und Leseanfragen sendet.
• Falls das Primary-Replikat ausfällt, werden die Aktualisierungen gestoppt. Sie müssen das Problem beheben, damit die Aktualisierungen fortgesetzt werden können.
• Es gibt keinen Failover-Mechanismus, um einen potenziellen Ausfall des Primary-Knotens abzufangen.

Kombination der Server-Setups

Glücklicherweise ist es für Sie auch möglich, verschiedene Techniken zu kombinieren, um das gewünschte Ergebnis zu erzielen. Das bedeutet, dass Sie die Lastverteilung der Anwendungsserver mit den Caching-Servern in einer einzigen Umgebung durchführen und die Datenbank replizieren können. Auf diese Weise können Sie die Funktionalität beider Server optimal nutzen. Es macht die Einrichtung jedoch nicht komplizierter oder mühsamer.

Beispiel:

Wir werden versuchen, eine solche Umgebung anhand eines Beispiels zu verstehen:

In einer solchen Umgebung leitet der Load Balancer statische Anfragen an die Caching-Server weiter. Statischer Inhalt umfasst unter anderem CSS, Bilder und Javascript. Alle anderen Arten von Inhaltsanfragen werden stattdessen an die Anwendungsserver weitergeleitet.

Nehmen wir an, ein Benutzer fordert statische Inhalte aus der Umgebung an. Folgendes würde passieren:

• Der Load Balancer ermittelt zunächst, ob es sich bei dem Inhalt um einen Cache-Hit oder einen Cache-Miss handelt. Cache-Hit-Inhalte sind im Cache vorhanden, während Cache-Miss-Inhalte nicht vorhanden sind. Dies geschieht durch eine Überprüfung mit dem Cache-Backend.
• Im Falle eines Cache-Hits sendet der Load Balancer den Inhalt an den Benutzer.
• Im Falle eines Cache-Miss leitet der Cache-Server die Anfrage an das Backend der Anwendung weiter.
• Das App-Backend sucht und sendet den Inhalt aus der Datenbank.
• Das Cache-Backend empfängt den Inhalt vom Load Balancer. Es speichert diesen Inhalt auch im Cache, bevor es ihn an den Load Balancer zurückgibt.
• Letzterer leitet die Antwort dann an den Benutzer weiter.

Andererseits passiert Folgendes, wenn der Benutzer dynamische Inhalte anfordert:

• Die Anfrage geht vom Benutzer beim Load Balancer ein.
• Diese Anfrage geht an das App-Backend.
• Das App-Backend lokalisiert den angeforderten Inhalt und gibt ihn an den Load Balancer zurück.
• Der Benutzer erhält den Inhalt.

Einer der Hauptvorteile einer solchen kombinierten Umgebung ist ihre höhere Zuverlässigkeit. Darüber hinaus bietet sie auch eine überlegene Leistungsfähigkeit. Es gibt jedoch immer noch zwei Single Points of Failure – den Load Balancer und den primären Datenbankserver.

Fazit

Sie können jedes Server-Setup einzeln in Ihrer Umgebung verwenden. Andererseits können Sie auch einige davon miteinander kombinieren, um eine personalisierte Lösung zu erstellen. Es gibt keine „richtige“ Antwort. Es hängt alles von der Funktionalität ab, die Sie aus der Architektur herausholen möchten.

Ein grundlegendes Verständnis der Funktionsweise der einzelnen Server-Setups wird Ihnen helfen, die Entscheidung für Ihre eigene Anwendung zu treffen. Am besten fängt man klein und einfach an. Sie können die Komplexität Ihres Setups im Laufe Ihrer Erfahrung weiter steigern.

Viel Spaß beim Computing!