Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Elastischer Einsatz Es gibt viele Szenarien, in denen eine Bereitstellung auf einem einzelnen Server für Ihre Website möglicherweise nicht ausreicht. In diesen Situationen benötigen Sie eine skalierbare Architektur mit mehreren Servern. **Topics** + [ # Referenzarchitektur ](reference-architecture.md) + [ # Skalierung der Webebene ](scaling-the-web-tier.md) + [ # Zustandslose Webebene ](stateless-web-tier.md) # Referenzarchitektur Die [AWSReferenzarchitektur für Hosting WordPress auf](https://github.com/awslabs/aws-refarch-wordpress) der Website GitHub beschreibt bewährte Methoden für die Bereitstellung WordPress auf AWS und enthält eine Reihe von AWS CloudFormation Vorlagen, mit denen Sie schnell loslegen können. Die folgende Architektur basiert auf dieser Referenzarchitektur. Im Rest dieses Abschnitts werden die Gründe für die architektonischen Entscheidungen untersucht. Die Basis AMI in GitHub wurde im Juli 2021 von Amazon Linux1 auf Amazon Linux2 geändert. Die Bereitstellungsvorlagen bei S3 wurden jedoch noch nicht geändert. Es wird empfohlen, Vorlagen unter zu verwenden, GitHub falls bei der Bereitstellung der Referenzarchitektur mit Vorlagen in S3 ein Problem auftritt. ![\[Referenzarchitektur für das Hosting WordPress auf AWS\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/best-practices-wordpress/images/image4.png) *Referenzarchitektur für das Hosting WordPress auf AWS* **Architekturkomponenten** Die Referenzarchitektur veranschaulicht eine vollständige Best-Practice-Implementierung für eine WordPress Website aufAWS. + Es beginnt mit Edge-Caching in **Amazon CloudFront** (1), um Inhalte in der Nähe der Endbenutzer zwischenzuspeichern und so eine schnellere **** Bereitstellung zu ermöglichen. + CloudFront ruft statische Inhalte aus einem **S3-Bucket** (2) und dynamische Inhalte von einem **Application Load Balancer** (4) vor den Webinstanzen ab. + Die Web-Instances laufen in einer **Auto Scaling Scaling-Gruppe** von **EC2**Amazon-Instances**** (6). + In einem ** ElastiCache **Cluster (7) werden häufig abgefragte Daten zwischengespeichert, um Antworten zu **** beschleunigen. Eine **Amazon Aurora** My SQL Instance (8) hostet die WordPress Datenbank. + Die WordPress EC2 Instances greifen über ein **EFSMount Target** (9) in jeder Availability Zone auf gemeinsam genutzte WordPress Daten in einem **EFSAmazon-Dateisystem** zu. + Ein **Internet Gateway** (3) ermöglicht die Kommunikation zwischen Ressourcen in Ihrem VPC und dem Internet. + **NATGateways** (5) in jeder Availability Zone ermöglichen EC2 Instances in privaten Subnetzen (App und Data) den Zugriff auf das Internet. Innerhalb des **Amazon VPC** gibt es zwei Arten von Subnetzen: öffentlich (**öffentliches** **Subnetz**) und privat (**App-Subnetz und **Datensubnetz****). Ressourcen, die in den öffentlichen Subnetzen bereitgestellt werden, erhalten eine öffentliche IP-Adresse und sind im Internet öffentlich sichtbar. Der **Application Load Balancer** (4) und ein Bastion-Host für die Administration werden hier bereitgestellt. Ressourcen, die in den privaten Subnetzen bereitgestellt werden, erhalten nur eine private IP-Adresse und sind daher im Internet nicht öffentlich sichtbar, wodurch die Sicherheit dieser Ressourcen verbessert wird. Die **WordPress **Webserver-Instances**** (6), **ElastiCacheCluster-Instances** (7), **Aurora My SQL Database-Instances** (8) und **EFSMount Targets** (9) werden alle in privaten Subnetzen bereitgestellt. Im Rest dieses Abschnitts werden alle diese Überlegungen ausführlicher behandelt. # Skalierung der Webebene Um Ihre Einzelserver-Architektur zu einer skalierbaren Architektur mit mehreren Servern weiterzuentwickeln, müssen Sie fünf Hauptkomponenten verwenden: + EC2Amazon-Instanzen + Amazon Machine Images (AMIs) + Load Balancers + Auto Scaling + Health checks (Zustandsprüfungen) AWSbietet eine Vielzahl von EC2 Instance-Typen, sodass Sie die beste Serverkonfiguration im Hinblick auf Leistung und Kosten wählen können. Im Allgemeinen kann der für die Datenverarbeitung optimierte Instance-Typ (z. B. C4) eine gute Wahl für einen WordPress Webserver sein. Sie können Ihre Instances in mehreren Availability Zones innerhalb einer AWS Region bereitstellen, um die Zuverlässigkeit der Gesamtarchitektur zu erhöhen. Da Sie die vollständige Kontrolle über Ihre EC2 Instance haben, können Sie sich mit Root-Zugriff anmelden, um alle Softwarekomponenten zu installieren und zu konfigurieren, die für den Betrieb einer WordPress Website erforderlich sind. Wenn Sie fertig sind, können Sie diese Konfiguration als speichernAMI, um sie zum Starten von neuen Instances mit allen von Ihnen vorgenommenen Anpassungen zu verwenden. Um Anfragen von Endbenutzern auf mehrere Webserverknoten zu verteilen, benötigen Sie eine Load-Balancing-Lösung. AWSbietet diese Funktion über [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/), einen hochverfügbaren Service, der den Traffic auf mehrere EC2 Instances verteilt. Da Ihre Website Ihren Benutzern Inhalte über HTTP oder bereitstellt, empfehlen wir IhnenHTTPS, den Application Load Balancer zu verwenden, einen Load Balancer auf Anwendungsebene mit Content-Routing und der Möglichkeit, bei Bedarf mehrere WordPress Websites auf verschiedenen Domains auszuführen. Elastic Load Balancing unterstützt die Verteilung von Anfragen auf mehrere Availability Zones innerhalb einer AWS Region. Sie können auch eine Integritätsprüfung so konfigurieren, dass der Application Load Balancer das Senden von Datenverkehr an einzelne Instances, die ausgefallen sind (z. B. aufgrund eines Hardwareproblems oder eines Softwareabsturzes), automatisch stoppt. AWSempfiehlt, die WordPress Admin-Anmeldeseite (`/wp-login.php`) für die Zustandsprüfung zu verwenden, da auf dieser Seite sowohl bestätigt wird, dass der Webserver läuft als auch, dass der Webserver für die korrekte Bereitstellung von PHP Dateien konfiguriert ist. Sie können sich dafür entscheiden, eine benutzerdefinierte Integritätsprüfungsseite zu erstellen, auf der andere abhängige Ressourcen wie Datenbank- und Cacheressourcen überprüft werden. Weitere Informationen finden Sie unter [Gesundheitschecks für Ihre Zielgruppen](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) im *Application Load Balancer* *Guide*. Elastizität ist ein wesentliches Merkmal der AWS Cloud. Sie können mehr Rechenkapazität (z. B. Webserver) bereitstellen, wenn Sie sie benötigen, und weniger Rechenkapazität ausführen, wenn Sie sie nicht benötigen. [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) ist ein AWS Service, der Ihnen hilft, diese Bereitstellung zu automatisieren, um Ihre EC2 Amazon-Kapazität gemäß den von Ihnen definierten Bedingungen zu erhöhen oder zu reduzieren, ohne dass manuelles Eingreifen erforderlich ist. Sie können Amazon EC2 Auto Scaling so konfigurieren, dass die Anzahl der EC2 Instances, die Sie verwenden, bei Bedarfsspitzen nahtlos ansteigt, um die Leistung aufrechtzuerhalten, und automatisch sinkt, wenn der Verkehr abnimmt, um die Kosten zu minimieren. Elastic Load Balancing unterstützt auch das dynamische Hinzufügen und Entfernen von EC2 Amazon-Hosts aus der Load-Balancing-Rotation. Elastic Load Balancing selbst erhöht und verringert zudem dynamisch die Load-Balancing-Kapazität, um sich ohne manuelles Eingreifen an die Datenverkehrsanforderungen anzupassen. # Zustandslose Webebene Um mehrere Webserver in einer Konfiguration mit automatischer Skalierung nutzen zu können, muss Ihre Webebene statusfrei sein. Eine statusfreie Anwendung benötigt keine Kenntnis früherer Interaktionen und speichert auch keine Sitzungsinformationen. Im Fall von bedeutet dies WordPress, dass alle Endbenutzer dieselbe Antwort erhalten, unabhängig davon, welcher Webserver ihre Anfrage bearbeitet hat. Eine statuslose Anwendung kann horizontal skaliert werden, da jede Anfrage von allen verfügbaren Rechenressourcen (d. h. Webserver-Instanzen) bearbeitet werden kann. Wenn diese Kapazität nicht mehr benötigt wird, kann jede einzelne Ressource sicher beendet werden (nachdem die laufenden Aufgaben aufgebraucht wurden). Diese Ressourcen müssen sich der Anwesenheit ihrer Kollegen nicht bewusst sein — alles, was benötigt wird, ist eine Möglichkeit, die Arbeitslast auf sie zu verteilen. Wenn es um die Speicherung von Benutzersitzungsdaten geht, ist der WordPress Kern völlig zustandslos, da er auf Cookies angewiesen ist, die im Webbrowser des Kunden gespeichert werden. Der Sitzungsspeicher ist kein Problem, es sei denn, Sie haben benutzerdefinierten Code (z. B. ein WordPress Plugin) installiert, der stattdessen auf systemeigenen PHP Sitzungen basiert. WordPress War jedoch ursprünglich für die Ausführung auf einem einzelnen Server konzipiert. Daher speichert es einige Daten im lokalen Dateisystem des Servers. Bei WordPress der Ausführung in einer Konfiguration mit mehreren Servern führt dies zu einem Problem, da es zu Inkonsistenzen zwischen den Webservern kommt. Wenn ein Benutzer beispielsweise ein neues Bild hochlädt, wird es nur auf einem der Server gespeichert. Dies zeigt, warum wir die Standardkonfiguration für die WordPress Ausführung verbessern müssen, um wichtige Daten in den gemeinsam genutzten Speicher zu verschieben. Die Best-Practice-Architektur hat eine Datenbank als separate Ebene außerhalb des Webservers und nutzt gemeinsam genutzten Speicher, um Benutzer-Uploads, Themes und Plugins zu speichern. # Gemeinsamer Speicher (Amazon S3 und AmazonEFS) WordPress Speichert Benutzer-Uploads standardmäßig im lokalen Dateisystem und ist daher nicht zustandslos. Daher müssen wir die WordPress Installation und alle Benutzeranpassungen (wie Konfiguration, Plugins, Designs und benutzergenerierte Uploads) auf eine gemeinsam genutzte Datenplattform verschieben, um die Belastung der Webserver zu reduzieren und die Webebene zustandslos zu machen. [Amazon Elastic File System](https://aws.amazon.com/efs/details/) (AmazonEFS) bietet skalierbare Netzwerkdateisysteme für die Verwendung mit EC2 Instances. EFSAmazon-Dateisysteme sind auf eine unbegrenzte Anzahl von Speicherservern verteilt, sodass Dateisysteme elastisch wachsen können und ein massiver parallel Zugriff von Instances aus möglich ist. EC2 Das verteilte Design von Amazon EFS vermeidet die Engpässe und Einschränkungen, die mit herkömmlichen Dateiservern einhergehen. Indem Sie das gesamte WordPress Installationsverzeichnis in ein EFS Dateisystem verschieben und es beim Booten in jede Ihrer EC2 Instances einbinden, werden Ihre WordPress Site und all ihre Daten automatisch auf einem verteilten Dateisystem gespeichert, das nicht von einer EC2 Instanz abhängig ist, wodurch Ihre Web-Tier komplett statusfrei wird. Der Vorteil dieser Architektur besteht darin, dass Sie keine Plug-ins und Themes bei jedem Start einer neuen Instance installieren müssen und dass Sie die Installation und Wiederherstellung von WordPress Instances erheblich beschleunigen können. Es ist auch einfacher, Änderungen an Plugins und Themes in zu implementieren WordPress, wie im Abschnitt [Überlegungen zur Bereitstellung](appendix-a-cloudfront-configuration.md) dieses Dokuments beschrieben. Um eine optimale Leistung Ihrer Website zu gewährleisten, wenn sie von einem EFS Dateisystem aus ausgeführt wird, überprüfen Sie die empfohlenen Konfigurationseinstellungen für Amazon EFS und OPcache auf der [AWSReferenzarchitektur für WordPress](https://github.com/awslabs/aws-refarch-wordpress#opcache). Sie haben auch die Möglichkeit, alle statischen Ressourcen wie Bilder und JavaScript Dateien in einen S3-Bucket mit CloudFront Caching im Vordergrund auszulagern. CSS Der Mechanismus hierfür in einer Multi-Server-Architektur ist genau derselbe wie bei einer Einzelserver-Architektur, wie im Abschnitt [Statischer Inhalt](accelerating-content-delivery.md) dieses Whitepapers beschrieben. Die Vorteile sind dieselben wie bei der Einzelserver-Architektur: Sie können die Arbeit, die mit der Bereitstellung Ihrer statischen Ressourcen verbunden ist, an Amazon S3 auslagern CloudFront, sodass sich Ihre Webserver auf die Generierung dynamischer Inhalte konzentrieren und mehr Benutzeranfragen pro Webserver bearbeiten können. # Datenebene (Amazon Aurora und Amazon ElastiCache) Da die WordPress Installation auf einem verteilten, skalierbaren, gemeinsam genutzten Netzwerkdateisystem gespeichert ist und statische Ressourcen von Amazon S3 bereitgestellt werden, können Sie sich auf die verbleibende statusbehaftete Komponente konzentrieren: die Datenbank. Wie bei der Speicherebene sollte die Datenbank nicht von einem einzelnen Server abhängig sein, sodass sie nicht auf einem der Webserver gehostet werden kann. Hosten Sie die WordPress Datenbank stattdessen auf Amazon Aurora. [Amazon Aurora](https://aws.amazon.com/rds/aurora) ist eine My SQL - und SQL Postgre-kompatible relationale Datenbank, die für die Cloud entwickelt wurde und die Leistung und Verfügbarkeit kommerzieller hochwertiger Datenbanken mit der Einfachheit und Kosteneffizienz von Open-Source-Datenbanken kombiniert. Aurora My SQL verbessert die SQL Leistung und Verfügbarkeit von My durch die enge Integration der Datenbank-Engine in ein speziell entwickeltes verteiltes Speichersystem, das von SSD Es ist fehlertolerant und repariert sich selbst, repliziert sechs Kopien Ihrer Daten in drei Availability Zones, ist für eine Verfügbarkeit von mehr als 99,99% konzipiert und sichert Ihre Daten kontinuierlich in Amazon S3. Amazon Aurora erkennt Datenbankabstürze automatisch und startet neu, ohne dass eine Wiederherstellung nach einem Absturz oder die Neuerstellung des Datenbank-Caches erforderlich ist. Amazon Aurora bietet eine Reihe von [Instance-Typen für unterschiedliche Anwendungsprofile, einschließlich speicheroptimierter und burstfähiger Instances](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html). Um die Leistung Ihrer Datenbank zu verbessern, können Sie einen großen Instance-Typ auswählen, um mehr CPU Speicherressourcen bereitzustellen. Amazon Aurora führt den Failover-Prozess zwischen der primären Instance und [Aurora Replicas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html) automatisch durch, sodass der Datenbankbetrieb so schnell wie möglich und ohne manuellen Verwaltungseingriff wieder aufgenommen werden kann. Im Normalfall weniger als 30 Sekunden. Nachdem Sie mindestens eine Aurora Replica erstellt haben, stellen Sie über den Cluster-Endpunkt eine Verbindung zu Ihrer primären Instance her, damit Ihre Anwendung automatisch ein Failover durchführen kann, falls die primäre Instance ausfällt. Sie können bis zu 15 Lesereplikate mit niedriger Latenz in drei Availability Zones erstellen. Wenn Ihre Datenbank skaliert wird, muss auch Ihr Datenbank-Cache skaliert werden. Wie bereits im Abschnitt [Datenbank-Caching beschrieben, ElastiCache verfügt er über Funktionen zur Skalierung des Caches](database-caching.md) über mehrere Knoten in einem ElastiCache Cluster und über mehrere Availability Zones in einer Region, um die Verfügbarkeit zu verbessern. Stellen Sie bei der Skalierung Ihres ElastiCache Clusters sicher, dass Sie Ihr Caching-Plugin so konfigurieren, dass die Verbindung über den Konfigurationsendpunkt hergestellt wird, sodass neue Clusterknoten verwendet werden WordPress können, sobald sie hinzugefügt werden, und alte Clusterknoten nicht mehr verwendet werden, wenn sie entfernt werden. Sie müssen auch Ihre Webserver so einrichten, dass sie den [ElastiCacheCluster-Client](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html) verwenden, PHP und Ihre Server aktualisierenAMI, um diese Änderung zu speichern.