Lukas G.Hinweis: Der folgende Artikel hilft Ihnen dabei: Ein moderner Webanwendungs-Stack von Hostinger
Moderne Webanwendungen sind groß, komplex und ressourcenintensiv. Infolgedessen haben sich die Methoden zum Hosten dieser Anwendungen drastisch geändert. Es ist nicht länger ideal, eine moderne Webanwendung einfach auf einem Linux/Apache/MySQL/PHP (LAMP)-Stack zu hosten, da dies die Leistungsfähigkeit moderner Webanwendungen erheblich einschränkt.
Ein Webanwendungs-Stack ist eine Sammlung von Software, die zusammenarbeitet, um eine moderne, sichere und schnelle Anwendungsbereitstellung zu ermöglichen. Diese modernen Anwendungsstacks gehen über einen typischen LAMP-Stack hinaus und umfassen zusätzliche Komponenten wie Nginx und Varnish. Durch umfangreiches Tuning sorgen diese Komponenten für ein optimales Endbenutzererlebnis.
In diesem Artikel werden die verschiedenen Anwendungen und Technologien behandelt, aus denen unser Hostinger Cloud-Webanwendungs-Stack besteht, wobei der Schwerpunkt speziell auf der Anwendungsbereitstellung liegt.
Entdecken Sie den Hostinger Stack
Nginx
Nginx ist ein leistungsstarker Webserver mit vollem Funktionsumfang, den wir als Reverse-Proxy in unserem Webanwendungs-Stack verwenden. Nginx wird von vielen Websites bevorzugt und ist ein beliebter Ersatz für den Apache-Webserver, da es sich durch die Bereitstellung statischer Inhalte auszeichnet.
Nginx macht die Bereitstellung statischer Inhalte zum Kinderspiel, mit verbessertem Objekt-Caching, TLS-Terminierung und HTTP/2-Unterstützung.
Aus diesem Grund verwenden wir Nginx zusammen mit dem Apache-Webserver in unserem Anwendungsstapel. Der Einsatz von Nginx vor Apache als Reverse-Proxy ermöglicht es jedem, sich auf seine jeweiligen Stärken zu konzentrieren.
Objekt-Caching
Nginx enthält einen integrierten Cache, der als Mikro-Cache bezeichnet wird. Während ein Mikrocache viele potenzielle Anwendungen hat, konzentrieren wir uns beim Caching auf kleine statische Objekte wie Bilder, CSS-Vorlagen, JavaScript und andere kleine Dateien.
Dies kommt sowohl Websites mit geringem als auch hohem Datenverkehr zugute, da zwischengespeicherte Objekte verhindern, dass das Objekt bei jeder Anfrage vom Webserver abgerufen werden muss. Viele moderne CMS können weit über 100 statische Objekte pro Seitenladevorgang haben, die alle vom Nginx-Mikrocache bedient werden können. Dies entlastet den Webserver für dynamische Inhalte erheblich, insbesondere während der Spitzenzeiten des Webverkehrs.
TLS-Beendigung
TLS-Terminatoren übernehmen die Entschlüsselung von HTTPS-Verbindungen. Normalerweise übernimmt die Webserveranwendung die TLS-Entschlüsselung, obwohl dies oft nicht ideal ist. Varnish und andere Caching-Proxys unterstützen derzeit keine HTTPS-Verbindungen und erfordern daher eine Entschlüsselung von TLS-Verbindungen, bevor sie Ihre Caching-Ebene erreichen. Lösungen mit Lastausgleich erfordern außerdem die Installation des TLS-Zertifikats auf jedem Anwendungsserver, wenn kein TLS-Terminator verwendet wird.
Eine Lösung für diese Einschränkungen besteht darin, Nginx die TLS-Entschlüsselung übernehmen zu lassen. Es gibt zwar Alternativen wie Pound und HAProxy, Nginx handhabt dies jedoch nativ und kann bei Bedarf auch einen Lastausgleich bereitstellen, sodass keine zusätzlichen Lastausgleichsdienste erforderlich sind.
Moderne TLS-Unterstützung
Transport Layer Security (TLS) ist der Nachfolger des älteren Verschlüsselungsprotokolls Secure Sockets Layer (SSL). TLS sorgt für die Verschlüsselung von HTTPS-Verbindungen, was für alle modernen Websites nahezu eine Voraussetzung ist.
Aktuelle Sicherheitsstandards (vor allem PCI DSS) haben älteres SSL und sogar einige frühe TLS als unzureichend gekennzeichnet, und nur moderne TLS-Verschlüsselungen ermöglichen es, diese sich entwickelnden Standards zu erfüllen.
Wie SSL gibt es auch für TLS mehrere Versionen, die neueste ist TLS 1.3. Als PCI-konformer Hosting-Anbieter ermöglichen wir ausschließlich sichere Verschlüsselungen nach den Mozilla Modern-Standards.
HTTP/2-Unterstützung
Nginx unterstützt vollständig das neueste HTTP/2-Protokoll. HTTP/2 ist eine Überarbeitung des ursprünglichen HTTP 1.1-Protokolls aus dem Jahr 1999. Der Schwerpunkt liegt auf verbesserter Leistung, wahrgenommener Endbenutzerlatenz und der Verwendung einer Multiplexverbindung zwischen Webservern und Browsern. HTTP/2 wird derzeit von allen gängigen Browsern unterstützt und ist in Nginx on Hostinger Cloud-Lösungen standardmäßig aktiviert.
Nginx plant außerdem, das neue Protokoll QUIC – HTTP/3 zu unterstützen, das wir ebenfalls unterstützen werden, sobald es verfügbar ist.
Inhaltskomprimierung
Datenkomprimierung ist keine neue Idee. Wenn Site-Daten schnell auf dem Server komprimiert und im Browser dekomprimiert werden können, reduziert dies die Größe der übertragenen Daten und spart dadurch Zeit.
Webserver und Browser unterstützen seit Jahren mehrere Komprimierungsalgorithmen wie gzip und deflate. Während sich beide in der Vergangenheit gut für die Bereitstellung von Inhalten bewährt haben, gibt es eine moderne und effizientere Option: Brotli.
Komprimierungsalgorithmen wie gzip werden seit Jahren unterstützt, wir unterstützen jedoch eine effizientere Option: Brotli.
Brotli ist eine Datenspezifikation, die einen wörterbuchbasierten Komprimierungsalgorithmus verwendet, der speziell für die Übertragung textbasierter statischer Webanwendungsdateien wie HTML und CSS entwickelt wurde. Aufgrund seiner speziellen Rolle bietet es erhebliche Verbesserungen gegenüber anderen gängigen Webkomprimierungsalgorithmen, sowohl hinsichtlich des Komprimierungsverhältnisses als auch der Komprimierungsgeschwindigkeit. Alle modernen Browser und Webserver unterstützen jetzt Brotli, einschließlich Nginx, das in unserer Konfiguration aktiviert ist.
Apache
Apache ist ein branchenüblicher Open-Source-Webserver, der erstmals 1995 das Licht der Welt erblickte. Mit der Veröffentlichung von Version 2.4 im Jahr 2012 begann die Unterstützung eines bedeutenden Funktionsumfangs, der bis heute kontinuierlich verbessert wird.
Eine der Stärken von Apache ist die Fähigkeit, dynamische Inhalte mit hoher Parallelität über verschiedene Anwendungsschnittstellen wie den FastCGI Process Manager (FPM) bereitzustellen. Wir nutzen PHP-FPM für alle PHP-basierten Anwendungen in unserem Cloud-Anwendungs-Stack. Neben der schnellen Unterstützung dynamischer Anwendungen verfügt Apache 2.4 über mehrere weitere bemerkenswerte Funktionen, die im Folgenden beschrieben werden.
Das Event-MPM
Mit Apache 2.4 wurde das Event-Multiprocessing-Modul (MPM) veröffentlicht, das gegenüber früheren Prefork- und Worker-MPMs früherer Versionen erhebliche Leistungssteigerungen ermöglichte. Das Event MPM macht Apache bei der Speichernutzung wesentlich effizienter und erhöht die Thread-Verarbeitung für eingehende Verbindungen auf ähnliche Weise wie bei Nginx. Hostinger Cloud-Pläne verwenden eine sorgfältig abgestimmte Event-MPM-Konfiguration als Teil unseres Anwendungsstapels.
Webanwendungs-Firewall
Eine Web Application Firewall (WAF) ist ein wesentliches Sicherheitsmerkmal für jede Website. Ihr Zweck besteht darin, einen HTTP-Inhaltsfilter für häufige Schwachstellen bereitzustellen, darunter unter anderem SQL-Injection, Cross-Site-Scripting und Anforderungsfälschungen. WAFs bieten außerdem Schutz vor bekannten Anwendungsschwachstellen und Hintertüren und schützen bekannte Remote-Shells und ungepatchte Software vor der Ausnutzung.
Unser Anwendungsstapel verwendet ModSecurity, eine Open-Source-WAF für den Anwendungsschutz. Die Implementierung von ModSecurity mit Apache bietet zusätzlichen Schutz für Webanwendungen und trägt dazu bei, Sicherheits- und Compliance-Anforderungen wie PCI DSS zu erfüllen.
Inhaltsoptimierung
Mod_Pagespeed wurde von Google entwickelt und ist ein Open-Source-Modul, das darauf ausgelegt ist, Inhalte auf dem Server zu optimieren und die Ladezeiten von Websites zu verkürzen. Dieses Modul führt eine Reihe von Front-End-Optimierungen für statische Inhalte durch, einschließlich HTML, JavaScript, CSS und Bilder. Zu diesen Optimierungen gehören das Inlining, Kombinieren und Minimieren von statischem Code, wodurch die Größe dieser Dateien und die Anzahl der Gesamtanforderungen reduziert werden.
Front-End-Optimierungen sind für die Website-Entwicklung sinnvoll, aber aus Zeitgründen werden sie oft auf der Strecke gelassen. Dann wird Mod_Pagespeed von unschätzbarem Wert.
Während Front-End-Optimierungen für die Website-Entwicklung sinnvoll sind, werden sie aus Zeitgründen manchmal außer Acht gelassen. In diesen Fällen ist Mod_Pagespeed von unschätzbarem Wert.
Während Mod_Pagespeed sowohl für Nginx als auch für Apache verfügbar ist, haben wir es mit dem Apache-Webserver aktiviert. Dadurch kann der Code als Teil von Apache optimiert werden, sodass er dann optimal im Nginx-Mikrocache zwischengespeichert werden kann.
Anwendungskompatibilität
Wie bereits erwähnt, kann jede Webanwendung unter Nginx oder Apache konfiguriert werden, aber die Unterstützung von .htaccess durch Letzteres macht Apache manchmal zu einem geeigneteren Kandidaten. Einige CMS verwenden .htaccess-Konfigurationen, die von Nginx nicht vollständig unterstützt werden. Obwohl die Verwendung von .htaccess-Dateien als Ganzes Vor- und Nachteile hat, ist es im Allgemeinen vorzuziehen, sie verfügbar zu machen, anstatt unsere Kunden zu zwingen, ihre Website an Nginx-Standards anzupassen.
Lack
Varnish ist ein Caching-HTTP-Beschleuniger, der eine leistungsstarke statische und dynamische Inhaltsbereitstellung ermöglicht. Bei Aktivierung und ordnungsgemäßer Konfiguration werden Inhaltsanfragen, die normalerweise von Apache und Nginx verarbeitet werden, jetzt von Varnish verarbeitet, das zwischengespeicherte Assets direkt aus dem Speicher an die Browser der Benutzer liefert. Dynamische Websites mit komplexen Backends, die umfangreiche PHP-Interpretationen erfordern (z. B. Magento), können von der Verwendung von Varnish stark profitieren.
Wenn Sie eine dynamische Website betreiben, die auf PHP-Interpretation basiert – Magento, WordPress, WooCommerce und mehr –, kann Varnish die Ladezeiten für Benutzer erheblich verbessern.
Ein Nachteil von Varnish ist die Komplexität der Implementierung. Die Steuerung der zwischengespeicherten Inhalte kann schwierig sein, insbesondere bei dynamischen Inhalten. Beim Umgang mit sitzungsbasierten E-Commerce-Websites muss besonders darauf geachtet werden, dass die Einkaufswagen ordnungsgemäß aktualisiert werden. Varnish verarbeitet diese Konfigurationen mithilfe seiner Varnish Configuration Language (VCL). Die VCL kann für Websites angepasst werden, und einige Anwendungen wie Magento 2 stellen eine Basis-VCL-Datei bereit, um die Anwendung zum Laufen zu bringen.
Derzeit unterstützt Varnish nur das HTTP-Protokoll, nicht HTTPS. Dies erfordert die Verwendung eines SSL-Terminators vor Varnish, der von Nginx in unserem Webanwendungs-Stack verarbeitet wird.
PHP – Softwaresammlungen
Unser Webanwendungs-Stack nutzt die Software Collections (SCL) von RedHat zur Unterstützung der Anwendungssprache. SCL ermöglicht die sofortige Verfügbarkeit mehrerer Sprachen und Versionen wie PHP, Ruby und Node.js für jede bestimmte Site. SCL erleichtert auch den Wechsel der Sprachversionen. Beispielsweise können unsere Kunden ihre PHP-Version für ein bestimmtes Konto über ihr Kundenportal auf eine beliebige Version zwischen 5.6 und 7.4 einstellen.
PHP Opcache
Opcache ist ein PHP-Caching-Beschleuniger, der die Leistung steigert, indem er vorkompilierten Skript-Bytecode optimiert und im gemeinsamen Speicher speichert. Durch die Integration einer ordnungsgemäß abgestimmten Opcache-Instanz mit PHP können häufig verwendete Skripte direkt aus dem Speicher gelesen werden, wodurch der intensive Kompilierungsprozess entfällt. Dies hat die Ladezeiten für die meisten Anwendungen drastisch verkürzt.
Opcache ist in modernen Versionen von PHP und der neuesten Version von 7.4 enthalten und hat ältere PHP-Skript-Caching-Methoden wie eAccelerator und APC ersetzt. Um die Vorteile von Opcache voll auszuschöpfen, haben wir viel Zeit damit verbracht, die Opcache-Standardvariablen in unserem Anwendungsstapel zu optimieren. Dies wird häufig übersehen, ist aber dennoch kritisch, da die Nichtanpassung der Standard-Opcache-Konfiguration an die Größe der gehosteten Anwendung jegliche Leistungssteigerung zunichte machen kann.
CDN
Obwohl es sich nicht um einen lokalen Teil unseres Anwendungsstapels handelt, profitiert nahezu jede Website von der Verwendung eines Content Delivery Network (CDN). Ein CDN speichert häufig verwendete statische Inhalte auf Servern auf der ganzen Welt zwischen und bietet so den Browsern der Benutzer eine lokale Möglichkeit, Website-Inhalte abzurufen und die Latenz zu reduzieren. Wir bieten mit unseren Cloud-Lösungen eine CDN-Lösung an und empfehlen deren Einsatz dringend.
Alles zusammenfügen
Moderne Webanwendungen sind gigantisch und stellen erhebliche Systemanforderungen für eine optimale Leistung. Es ist zwar möglich, eine Anwendung auf einer einfachen Apache- oder Nginx-Instanz zu hosten, allerdings geht dabei die Leistung aus Bequemlichkeitsgründen verloren. Apache, Nginx und Varnish haben komplementäre Stärken und ihre gemeinsame Verwendung führt zu den besten Ergebnissen hinsichtlich Leistung und Skalierbarkeit.
Obwohl unser Anwendungsstack komplex ist, wurde er mit zwei Jahrzehnten Erfahrung im Einsatz dieser Systeme entwickelt und für eine Vielzahl von Anwendungen getestet und abgestimmt. Es entwickelt sich auch ständig weiter. Sobald neue Technologien und Funktionen für die jeweiligen Komponenten unseres Anwendungsstapels verfügbar werden, testen wir diese neuen Elemente, bevor wir sie einführen.
Die erste dieser Überlegungen betrifft die verschiedenen Header, die in den verschiedenen Diensten verwendet werden und die jeweils sorgfältig verwaltet werden müssen. Nginx, Apace und Varnish stellen jeweils Standard- und benutzerdefinierte Header für die Inhaltskontrolle, Cache-Steuerung und Debugging-Informationen bereit. Header von externen CDN- oder Beschleunigerdiensten können dies noch weiter erschweren. Durch die ordnungsgemäße Konfiguration der Header wird die richtige Platzierung des Cachings sichergestellt und der Datenfluss durch den Stapel optimiert.
Auch die Protokollierung stellt eine Herausforderung dar, sowohl für das Debugging als auch für Compliance-Anforderungen. Jeder Dienst im Stapel generiert ein Protokoll, das alle an einem sicheren Remote-Standort gespeichert werden muss, um die Verfolgung jeder Anfrage und Antwort durch diese verschiedenen Komponenten zu erleichtern.
Threading, Verbindungslimits und Ressourcennutzung müssen ebenfalls berücksichtigt werden. Jede Komponente in diesem Anwendungsstapel kann einen Engpass darstellen, wenn sie nicht richtig abgestimmt ist. Viele dieser Konfigurationen werden in unserem Artikel „The Definitive Guide to Magento 2 Optimization“ beschrieben.
