本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 彈性部署 在許多情況下，單一伺服器部署可能不足以用於您的網站。在這些情況下，您需要多伺服器、可擴展的架構。 **Topics** + [ # 參考架構 ](reference-architecture.md) + [ # 擴展 Web 層 ](scaling-the-web-tier.md) + [ # 無狀態 Web 層 ](stateless-web-tier.md) # 參考架構 上的 GitHub[參考AWS架構 WordPress 託管](https://github.com/awslabs/aws-refarch-wordpress)概述了在 WordPress 上部署的最佳實務，AWS並包含一組 AWS CloudFormation 範本，可讓您快速啟動和執行。下列架構是以該參考架構為基礎。本節其餘部分將檢閱架構選擇背後的原因。 AMI 中 的 GitHub 已於 2021 年 7 月從 Amazon Linux1 變更為 Amazon Linux2。不過，S3 的部署範本尚未變更。 GitHub 如果 S3 使用範本部署參考架構時發生問題，建議您在 使用範本。 ![\[WordPress 用於託管的參考架構 AWS\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-wordpress/images/image4.png) * WordPress 用於託管的參考架構 AWS * **架構元件** 參考架構說明 上 WordPress 網站的完整最佳實務部署AWS。 + 它從 **Amazon CloudFront **（1） 中的邊緣快取開始，以快取接近最終使用者的內容，以加快****交付速度。 + CloudFront 從 Web 執行個體前面的 **S3 儲存貯**體 （2） 提取靜態內容，並從 **Application Load Balancer** （4） 提取動態內容。 + Web 執行個體在 **Auto Scaling 群組**中的 **Amazon EC2****執行個體 **（6） 中執行。 + ** ElastiCache **叢集 （7） 會快取經常查詢的資料，以****加快回應速度。 **Amazon Aurora** MySQL 執行個體 （8） WordPress託管資料庫。 + 執行個體會透過每個可用區域中的**EFS掛載目標** WordPress EC2（9） 存取 **Amazon EFS** 檔案系統上的共用 WordPress 資料。 + **網際網路閘道** （3） 可啟用 VPC和網際網路中資源之間的通訊。 + 每個可用區域中的**NAT閘道 **（5） 可讓私有子網路 （應用程式和資料） 中的EC2執行個體存取網際網路。 在 **Amazon VPC** 中有兩種子網路類型：公有 （**公有****子網路） **和私有 （**應用程式子網路**和**資料子網路）**。部署到公有子網路的資源將會收到公有 IP 地址，並將在網際網路上公開可見。**Application Load Balancer** （4） 和用於管理的 Bastion 主機部署在此處。部署到私有子網路的資源只會收到私有 IP 地址，因此不會在網際網路上公開顯示，從而提高這些資源的安全性。**WordPress Web** **伺服器執行個體** （6）、**ElastiCache叢集執行個體** （7）、**Aurora MySQL 資料庫執行個體** （8） 和**EFS掛載目標 **（9） 都部署在私有子網路中。 本節的其餘部分更詳細地涵蓋了這些考量。 # 擴展 Web 層 若要將單一伺服器架構演變為多伺服器、可擴展的架構，您必須使用五個關鍵元件： + Amazon EC2執行個體 + Amazon Machine Images （AMIs） + 負載平衡器 + 自動調整規模 + 運作狀態檢查 AWS 提供各種EC2執行個體類型，讓您可以選擇效能和成本的最佳伺服器組態。一般而言，運算最佳化 （例如 C4） 執行個體類型可能是 WordPress Web 伺服器的最佳選擇。您可以在 AWS 區域內的多個可用區域部署執行個體，以提高整體架構的可靠性。 由於您可以完全控制EC2執行個體，因此您可以使用根存取權登入，以安裝和設定執行 WordPress 網站所需的所有軟體元件。完成後，您可以將該組態儲存為 AMI，您可以使用它來啟動具有所有自訂項目的新執行個體。 若要將最終使用者請求分發至多個 Web 伺服器節點，您需要負載平衡解決方案。AWS 透過 [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)提供此功能，這是一種高可用性服務，可將流量分散至多個EC2執行個體。由於您的網站透過 HTTP或 為使用者提供內容HTTPS，因此我們建議您使用 Application Load Balancer 、具有內容路由的應用程式層負載平衡器，以及在必要時在不同網域上執行多個 WordPress 網站的能力。 Elastic Load Balancing 支援在AWS區域內多個可用區域之間分發請求。您也可以設定運作狀態檢查，讓 Application Load Balancer 自動停止將流量傳送至失敗的個別執行個體 （例如，由於硬體問題或軟體當機）。AWS 建議使用 WordPress 管理員登入頁面 （`/wp-login.php`） 進行運作狀態檢查，因為此頁面會確認 Web 伺服器正在執行，以及 Web 伺服器已設定為正確提供PHP檔案。 您可以選擇建置自訂運作狀態檢查頁面，以檢查其他相依資源，例如資料庫和快取資源。如需詳細資訊，請參閱 *Application Load Balancer* *指南* 中的[目標群組運作狀態檢查](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)。 彈性是 AWS Cloud 的關鍵特徵。您可以在需要時啟動更多運算容量 （例如 Web 伺服器），而不需要時則執行更少。[Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 是一項 AWS 服務，可協助您自動化此佈建，根據您定義的條件來擴展或縮減 Amazon EC2容量，而不需要手動介入。您可以設定 Amazon EC2 Auto Scaling，以便在需求激增期間無縫增加使用中的EC2執行個體數量，以維持效能並在流量減少時自動減少，以將成本降至最低。 Elastic Load Balancing 也支援動態新增和移除負載平衡輪換中的 Amazon EC2 主機。Elastic Load Balancing 本身也會動態增加和減少負載平衡容量，以適應流量需求，而無需手動介入。 # 無狀態 Web 層 若要在自動擴展組態中利用多個 Web 伺服器，您的 Web 層必須是無狀態的。無狀態應用程式是不需要了解先前互動且不會儲存工作階段資訊的應用程式。對於 WordPress，這表示所有最終使用者都會收到相同的回應，無論哪個 Web 伺服器處理了其請求。無狀態應用程式可以水平擴展，因為任何可用的運算資源 （即 Web 伺服器執行個體） 都可以為任何請求提供服務。當不再需要該容量時，任何個別資源都可以安全地終止 （在已耗盡執行中的任務之後）。這些資源不需要知道同事的存在，只需要將工作負載分發給他們。 在使用者工作階段資料儲存方面， WordPress 核心完全無狀態，因為它依賴存放在用戶端 Web 瀏覽器中的 Cookie。除非您安裝了任何自訂程式碼 （例如 WordPress 外掛程式），而這些程式碼完全依賴原生PHP工作階段，否則工作階段儲存就不是問題。 不過， WordPress 最初的設計是要在單一伺服器上執行。因此，它會在伺服器的本機檔案系統上存放一些資料。在多伺服器組態 WordPress 中執行 時，這會產生問題，因為 Web 伺服器之間存在不一致。例如，如果使用者上傳新映像，則只會儲存在其中一個伺服器上。 這說明了為什麼我們需要改進預設 WordPress執行中組態，才能將重要資料移至共用儲存體。最佳實務架構具有資料庫作為 Web 伺服器外部的個別層，並使用共用儲存來存放使用者上傳、主題和外掛程式。 # 共用儲存 （Amazon S3 和 AmazonEFS） 根據預設， 會將使用者上傳 WordPress 存放在本機檔案系統上，因此 不是無狀態。因此，我們需要將 WordPress 安裝和所有使用者自訂 （例如組態、外掛程式、主題和使用者產生的上傳） 移至共用資料平台，以協助減少 Web 伺服器的負載，並讓 Web 層無狀態。 [Amazon Elastic File System](https://aws.amazon.com/efs/details/) （Amazon EFS） 提供可擴展的網路檔案系統，可與EC2執行個體搭配使用。Amazon EFS 檔案系統分散在不受限制的儲存伺服器數量，讓檔案系統彈性成長，並允許從EC2執行個體進行大規模平行存取。Amazon 的分散式設計可EFS避免傳統檔案伺服器固有的瓶頸和限制。 透過將整個 WordPress 安裝目錄移動到EFS檔案系統上，並在啟動時將其掛載到每個EC2執行個體，您的 WordPress 網站及其所有資料會自動存放在不依賴於任何一個EC2執行個體的分散式檔案系統上，讓您的 Web 層完全無狀態。此架構的優點是您不需要在每次新執行個體啟動時安裝外掛程式和主題，而且可以大幅加快 WordPress 執行個體的安裝和復原速度。在 中部署外掛程式和主題的變更也比較容易 WordPress，如本文件的[部署考量](appendix-a-cloudfront-configuration.md)一節所述。 若要確保從EFS檔案系統執行時網站的最佳效能，請檢查適用於 Amazon EFS和 [AWS 參考架構 WordPress](https://github.com/awslabs/aws-refarch-wordpress#opcache)OPcache的建議組態設定。 您也可以選擇將所有靜態資產，例如映像、 CSS和 JavaScript 檔案，卸載至 S3 儲存貯體，同時 CloudFront 快取在前面。在多伺服器架構中執行此操作的機制與單一伺服器架構完全相同，如本白皮書的[靜態內容](accelerating-content-delivery.md)章節所述。優點與單一伺服器架構相同：您可以將與為靜態資產提供服務相關聯的工作卸載至 Amazon S3 和 CloudFront，藉此讓您的 Web 伺服器僅專注於產生動態內容，並為每個 Web 伺服器提供更多使用者請求。 # 資料層 （Amazon Aurora 和 Amazon ElastiCache） 透過存放在分散式、可擴展、共用網路檔案系統的 WordPress 安裝，以及從 Amazon S3 提供的靜態資產，您可以將注意力集中在剩餘的具狀態元件：資料庫。與儲存層一樣，資料庫不應依賴任何單一伺服器，因此無法託管在其中一個 Web 伺服器上。而是在 Amazon Aurora 上託管 WordPress 資料庫。 [Amazon Aurora](https://aws.amazon.com/rds/aurora) 是為雲端建置的 MySQL 和 PostgreSQL 相容關聯式資料庫，結合了高階商業資料庫的效能和可用性，以及開放原始碼資料庫的簡單性和成本效益。Aurora MySQL 透過緊密整合資料庫引擎與由 支援的專用分散式儲存系統，來提高我的SQL效能和可用性SSD。它具有容錯性和自我修復功能，可跨三個可用區域複寫六份資料，旨在實現超過 99.99% 的可用性，並在 Amazon S3 中持續備份您的資料。Amazon Aurora 旨在自動偵測資料庫當機和重新啟動，而不需要當機復原或重建資料庫快取。 Amazon Aurora 提供多種[執行個體類型](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html)，以適應不同的應用程式設定檔，包括記憶體最佳化和爆量執行個體。若要改善資料庫的效能，您可以選擇大型執行個體類型，以提供更多 CPU和 記憶體資源。 Amazon Aurora 會自動處理主要執行個體和 [Aurora 複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html)之間的容錯移轉，讓您的應用程式可以盡快恢復資料庫操作，而無需手動管理介入。容錯移轉通常需要不到 30 秒的時間。 建立至少一個 Aurora 複本後，請使用叢集端點連線至您的主要執行個體，以允許應用程式在主要執行個體失敗時自動容錯移轉。您可以在三個可用區域中建立最多 15 個低延遲僅供讀取複本。 隨著資料庫擴展，您的資料庫快取也需要擴展。如先前在[資料庫快取](database-caching.md)章節中所述， ElastiCache 具有將快取擴展到 ElastiCache 叢集中多個節點，以及區域中多個可用區域的功能，以提高可用性。當您擴展 ElastiCache 叢集時，請確定您設定快取外掛程式以使用組態端點進行連線，以便 WordPress 可以在新增叢集節點時使用新的叢集節點，並在移除舊叢集節點時停止使用它們。您也必須設定 Web 伺服器以使用 [ElastiCache 的叢集用戶端PHP](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html)，並更新 AMI以存放此變更。