[和訳]WordPress ベストプラクティス on AWS

こんにちは、タカフです。

AWSの提唱している、
「WordPress:Best Practices on AWS」
を和訳してみました。

以下からです。

スケーラブルなWordPress搭載Webサイトのリファレンスアーキテクチャ

2019年10月

概要

このホワイトペーパーは、システム管理者にアマゾンウェブサービス（AWS）でWordPressを開始する方法と、展開のコスト効率とエンドユーザーエクスペリエンスの両方を改善する方法に関する具体的なガイダンスを提供します。
また、一般的なスケーラビリティと高可用性の要件に対応するリファレンスアーキテクチャの概要も示します。

はじめに

WordPressは、PHPとMySQLをベースにしたオープンソースのブログツールおよびコンテンツ管理システム（CMS）であり、個人のブログからトラフィックの多いWebサイトまであらゆるものに使用されます。

WordPressの最初のバージョンが2003年にリリースされたとき、最新の弾力的でスケーラブルなクラウドベースのインフラストラクチャを念頭に置いて構築されていませんでした。
WordPressコミュニティの作業とさまざまなWordPressモジュールのリリースにより、このCMSソリューションの機能は常に拡大しています。
現在、AWSクラウドの多くの利点を活用するWordPressアーキテクチャを構築することが可能です。

シンプルなデプロイ

厳密な高可用性要件のない低トラフィックのブログまたはWebサイトには、単一サーバーの単純な展開が適している場合があります。
この展開は、最も復元力のある、またはスケーラブルなアーキテクチャではありませんが、Webサイトを稼働させるための最も迅速で経済的な方法です。

考慮事項

単一のWebサーバーの展開から始めます。
あなたはそれを成長させる機会があるかもしれません、例えば：

• WordPress Webサイトが展開されている仮想マシンは、単一障害点です。
  このインスタンスに問題があると、Webサイトのサービスが失われます。
• リソースをスケーリングしてパフォーマンスを向上させるには、「垂直スケーリング」、つまりWordPress Webサイトを実行する仮想マシンのサイズを大きくする必要があります。

利用可能なアプローチ

AWSには、仮想マシンをプロビジョニングするためのさまざまなオプションがあります。

AWSで独自のWordPressウェブサイトをホストするには、主に3つの方法があります。

• Amazon Lightsail
• Amazon Elastic Compute Cloud（Amazon EC2）
• AWSマーケットプレイス

Amazon Lightsailは、WordPressウェブサイトをホストする仮想プライベートサーバー（Lightsailインスタンス）をすばやく起動できるサービスです。
高度に設定可能なインスタンスタイプや高度なネットワーク機能へのアクセスが必要ない場合、Lightsailは最も簡単な方法です。

Amazon EC2は、サイズ変更可能な計算能力を提供するウェブサービスであるため、数分以内に仮想サーバーを起動できます。
Amazon EC2は、Lightsailよりも多くの設定および管理オプションを提供します。これは、より高度なアーキテクチャに適しています。
EC2インスタンスへの管理アクセス権があり、WordPressなど、選択したソフトウェアパッケージをインストールできます。

AWS Marketplaceは、AWSで実行されるソフトウェアを見つけて購入し、すばやく展開できるオンラインストアです。
1-Clickデプロイを使用して、事前設定されたWordPressイメージを数分でAWSアカウントのAmazon EC2に直接起動できます。
すぐに実行できるWordPressインスタンスを提供する多くのマーケットプレイスベンダーがあります。

単一サーバーのWordPress Webサイトの推奨実装として、Lightsailオプションについて説明します。

Amazon Lightsail

Lightsailは、開発者、中小企業、学生、およびシンプルな仮想プライベートサーバー（VPS）ソリューションを必要とするその他のユーザーにとって、AWSを開始する最も簡単な方法です。

このサービスは、インフラストラクチャ管理のより複雑な要素の多くをユーザーから切り離します。したがって、インフラストラクチャの経験が少ない場合、またはWebサイトの実行に集中する必要があり、ニーズに応じて簡素化された製品で十分な場合は、理想的な出発点です。

Amazon Lightsailを使用すると、WindowsまたはLinux / Unixオペレーティングシステム、およびWordPressを含む一般的なウェブアプリケーションを選択し、事前設定されたテンプレートからワンクリックでデプロイできます。

ニーズが大きくなると、最初の境界の外にスムーズに出て、追加のAWSデータベース、オブジェクトストレージ、キャッシュ、コンテンツ配信サービスに接続できるようになります。

Amazon Lightsail料金プランの選択

Lightsailプランは、WordPress Webサイトのホストに使用するLightsailリソースの月額費用を定義します。さまざまな用途をカバーするために利用可能な多くの計画があります。

さまざまなレベルのCPUリソース、メモリ、ソリッドステートドライブ（SSD）ストレージ、およびデータ転送を使用したAWSでのWordPressのAmazon Webサービスのベストプラクティス。

ウェブサイトが複雑な場合、より多くのリソースを備えたより大きなインスタンスが必要になる場合があります。
これを実現するには、Webコンソールを使用するか、Amazon Lightsail CLIドキュメントの説明に従って、サーバーをより大きなプランに移行します。

WordPressのインストール

Lightsailは、WordPressなどの一般的に使用されるアプリケーションのテンプレートを提供します。
このテンプレートは、必要なソフトウェアのほとんどが事前にインストールされているため、独自のWordPress Webサイトを実行するのに最適な出発点です。
ブラウザ内端末または独自のSSHクライアントを使用するか、WordPress管理Webインターフェイスを使用して、追加のソフトウェアをインストールしたり、ソフトウェア構成をカスタマイズしたりできます。

Amazon LightsailはGoDaddy Pro Sites製品とパートナーシップを結んでおり、WordPressのお客様がインスタンスを無料で簡単に管理できるようにしています。

Lightsail WordPress仮想サーバーは、高速なパフォーマンスとセキュリティのために事前に構成および最適化されており、WordPressサイトをすぐに立ち上げて実行することが容易になります。
複数のWordPressインスタンスを実行しているお客様は、すべてのサイトを更新、維持、管理するのが難しく、時間がかかることに気付きます。
この統合により、数回クリックするだけで、複数のWordPressインスタンスを数分で簡単に管理できます。

LightsailでのWordPressの管理の詳細については、Amazon LightsailインスタンスからWordPressの使用を開始するをご覧ください。

WordPress Webサイトのカスタマイズが完了したら、インスタンスのスナップショットを取ることをお勧めします。

スナップショットは、Lightsailインスタンスのバックアップイメージを作成する方法です。
これはシステムディスクのコピーであり、元のマシン構成（メモリ、CPU、ディスクサイズ、データ転送速度）も保存します。
スナップショットを使用して、不適切な展開またはアップグレード後に既知の適切な構成に戻すことができます。

このスナップショットにより、必要に応じてサーバーを回復できますが、同じカスタマイズで新しいインスタンスを起動することもできます。

障害からの回復

単一のWebサーバーは単一障害点であるため、Webサイトのデータがバックアップされていることを確認する必要があります。
前述のスナップショットメカニズムもこの目的に使用できます。障害から回復するには、最新のスナップショットから新しいインスタンスを復元できます。
復元中に失われる可能性のあるデータの量を減らすために、スナップショットはできるだけ新しいものにする必要があります。

データ損失の可能性を最小限に抑えるために、スナップショットが定期的に取得されていることを確認してください。
Lightsail Linux / Unixインスタンスの自動スナップショットをスケジュールできます。手順については、「Amazon Lightsailのインスタンスまたはディスクの自動スナップショットを有効または無効にする」を参照してください。

Lightsailアカウント専用の固定のパブリックIPアドレスである静的IPを使用することをお勧めします。インスタンスを別のインスタンスに置き換える必要がある場合は、静的IPを新しいインスタンスに再割り当てできます。
この方法では、インスタンスを置き換えるたびに新しいIPアドレスを指すように外部システム（DNSレコードなど）を再構成する必要はありません。

パフォーマンスとコスト効率の改善

最終的には、単一サーバー展開よりも成長する可能性があります。
この場合、ウェブサイトのパフォーマンスを改善するためのオプションを検討する必要があります。
マルチサーバーのスケーラブルな展開に移行する前に（このホワイトペーパーで後述します）、適用できるパフォーマンスとコスト効率がいくつかあります。
これらは、マルチサーバーアーキテクチャに移行した場合でも、とにかく従うべき優れたプラクティスです。

以下のセクションでは、WordPress Webサイトのパフォーマンスとスケーラビリティの側面を改善できる多くのオプションを紹介します。
単一サーバーの展開に適用できるものもあれば、複数サーバーのスケーラビリティを利用するものもあります。
これらの変更の多くは、1つ以上のWordPressプラグインの使用を必要とします。
さまざまなオプションを利用できますが、W3 Total Cacheは、これらの変更の多くを単一のプラグインに組み合わせた一般的な選択肢です。

コンテンツ配信の加速

WordPress Webサイトは、静的コンテンツと動的コンテンツの両方を提供する必要があります。
静的コンテンツには、画像、JavaScriptファイル、またはスタイルシートが含まれます。
動的コンテンツには、WordPress PHPコードを使用してサーバー側で生成されたものすべてが含まれます。
たとえば、データベースから生成されたサイトの要素や、各ビューアにパーソナライズされた要素などです。
エンドユーザーエクスペリエンスの重要な側面は、以前のコンテンツを世界中のユーザーに配信する際のネットワーク遅延です。
以前のコンテンツの配信を加速すると、エンドユーザーエクスペリエンス、特に地理的に世界中に広がるユーザーのエクスペリエンスが向上します。
これは、Amazon CloudFrontなどのコンテンツ配信ネットワーク（CDN）で実現できます。

Amazon CloudFrontは、世界中の複数のエッジロケーションを介して、低レイテンシーかつ高速のデータ転送速度でコンテンツを配信するための簡単で費用対効果の高い方法を提供するウェブサービスです。
待ち時間を短縮するために、ビューアーのリクエストは適切なCloudFrontエッジロケーションに自動的にルーティングされます。
コンテンツを（数秒、数分、または数日間）キャッシュでき、特定のエッジロケーションに既に保存されている場合、CloudFrontはすぐに配信します。
コンテンツがキャッシュされるべきではない、期限が切れている、または現在そのエッジの場所にない場合、CloudFrontは1つ以上の真実のソースからコンテンツを取得します。
このソースは、オリジン（この場合はLightsailインスタンス）と呼ばれますCloudFront構成。
この取得は、最適化されたネットワーク接続を介して行われ、Webサイト上のコンテンツの配信を高速化するために機能します。
エンドユーザーエクスペリエンスの向上とは別に、ここで説明したモデルは、オリジンサーバーの負荷を軽減し、大幅なコスト削減をもたらす可能性があります。

静的コンテンツオフロード

これには、CSS、JavaScript、および画像ファイル（WordPressテーマの一部であるもの、またはコンテンツ管理者によってアップロードされたメディアファイル）が含まれます。
これらのファイルはすべて、W3 Total Cacheなどのプラグインを使用してAmazon Simple Storage Service（Amazon S3）に保存し、スケーラブルで可用性の高い方法でユーザーに提供できます。
Amazon S3は、REST APIを介してアクセス可能な、拡張性が高く、信頼性が高く、低レイテンシのデータストレージインフラストラクチャを低コストで提供します。
Amazon S3は、複数のデバイスだけでなく、AWSリージョンの複数の施設にもオブジェクトを冗長的に保存するため、非常に高いレベルの耐久性を提供します。

これには、Lightsailインスタンスからこのワークロードをオフロードし、動的コンテンツ生成に集中させるというプラスの副作用があります。これにより、サーバーの負荷が軽減され、ステートレスアーキテクチャ（自動スケーリングを実装する前の前提条件）を作成するための重要なステップになります。

その後、Amazon S3をCloudFrontのオリジンとして設定して、これらの静的アセットの世界中のユーザーへの配信を改善できます。
WordPressはそのままではAmazon S3およびCloudFrontと統合されていませんが、さまざまなプラグインがこれらのサービスのサポートを追加します（W3 Total Cacheなど）。

動的コンテンツ

動的コンテンツには、サーバー側のWordPress PHPスクリプトの出力が含まれます。
WordPress Webサイトをオリジンとして設定することにより、CloudFrontを介して動的コンテンツを提供することもできます。
動的コンテンツにはパーソナライズされたコンテンツが含まれるため、特定のHTTP CookieとHTTPヘッダーをリクエストの一部としてカスタムオリジンサーバーに転送するようにCloudFrontを構成する必要があります。
CloudFrontは、転送されたCookie値を、キャッシュ内の一意のオブジェクトを識別するキーの一部として使用します。
キャッシュの効率を最大限に高めるには、コンテンツを実際に変更するHTTP CookieとHTTPヘッダーのみを転送するようにCloudFrontを構成する必要があります（クライアント側またはWebなどのサードパーティアプリケーションでのみ使用されるCookieではありません） 分析）。

図1：Amazon CloudFrontを介したWebサイト全体の配信

図1には、静的コンテンツ用と動的コンテンツ用の2つのオリジンが含まれています。
実装の詳細については、付録A：CloudFrontの構成 および 付録B：プラグインのインストールと構成を参照してください。

CloudFrontは標準のキャッシュ制御ヘッダーを使用して、特定のHTTPレスポンスをキャッシュするかどうか、およびキャッシュする期間を特定します。
同じキャッシュコントロールヘッダーは、より最適なエンドユーザーエクスペリエンスのためにコンテンツをローカルにキャッシュするタイミングと時間を決定するためにWebブラウザーでも使用されます（たとえば、既にダウンロードされた.cssファイルは毎回再ダウンロードされません 再訪問者がページを表示します）。
Webサーバーレベルでキャッシュ制御ヘッダーを構成する（たとえば、.htaccessファイルまたはhttpd.confファイルの変更を介して）か、WordPressプラグイン（たとえば、W3 Total Cache）をインストールして、両方のヘッダーの設定方法を指定できます。
静的および動的コンテンツ。

データベースキャッシュ

データベースキャッシュは、WordPressなどの読み取りが多いアプリケーションワークロードのレイテンシを大幅に削減し、スループットを向上させることができます。アプリケーションのパフォーマンスは、頻繁にアクセスされるデータを低レイテンシアクセス用のメモリに格納することで改善されます（たとえば、I / O集中型データベースクエリの結果）。クエリの大部分がキャッシュから提供されると、データベースにヒットする必要があるクエリの数が減り、データベースの実行に関連するコストが削減されます。

WordPressにはすぐに使用できるキャッシング機能が制限されていますが、さまざまなプラグインが、広く採用されているメモリオブジェクトキャッシングシステムであるMemcachedとの統合をサポートしています。
W3 Total Cacheプラグインは良い例です。
最も単純なシナリオでは、MemcachedをWebサーバーにインストールし、結果を新しいスナップショットとしてキャプチャします。この場合、キャッシュの実行に関連する管理タスクを担当します。

もう1つのオプションは、Amazon ElastiCacheなどのマネージドサービスを利用して、運用上の負担を回避することです。
ElastiCacheを使用すると、クラウド内の分散インメモリキャッシュを簡単にデプロイ、操作、およびスケーリングできます。
ElastiCacheクラスターノードに接続する方法に関する情報は、Amazon ElastiCacheのドキュメントで見つけることができます。
Lightsailを使用していて、AWSアカウントのElastiCacheクラスターにプライベートにアクセスする場合は、VPCピアリングを使用してアクセスできます。
VPCピアリングを有効にする手順については、「Amazon VPCピアリングを設定してAmazon Lightsailの外部のAWSリソースと連携する」を参照してください。

バイトコードキャッシング

PHPスクリプトが実行されるたびに、解析およびコンパイルされます。
PHPバイトコードキャッシュを使用すると、PHPコンパイルの出力がRAMに保存されるため、同じスクリプトを何度もコンパイルする必要がありません。
これにより、PHPスクリプトの実行に関連するオーバーヘッドが削減され、パフォーマンスが向上し、CPU要件が低くなります。

バイトコードキャッシュは、WordPressをホストする任意のLightsailインスタンスにインストールでき、負荷を大幅に削減できます。
PHP 5.5以降では、そのPHPバージョンにバンドルされている拡張機能であるOPcacheの使用をお勧めします。

OPcacheはBitnami WordPress Lightsailテンプレートでデフォルトで有効になっているため、これ以上のアクションは不要です。

伸縮自在なデプロイ

単一サーバーの展開ではWebサイトに十分でない可能性のある多くのシナリオがあります。
これらの状況では、マルチサーバーのスケーラブルなアーキテクチャが必要です。

参照アーキテクチャ

GitHubで利用可能なAWSでのWordPressのホスティングリファレンスアーキテクチャでは、AWSでWordPressをデプロイするためのベストプラクティスを概説し、すぐに使用できるAWS CloudFormationテンプレートのセットが含まれています。
次のアーキテクチャは、その参照アーキテクチャに基づいています。
このセクションの残りの部分では、アーキテクチャの選択の背後にある理由を検討します。

図2：WordPressをAWSでホストするための参照アーキテクチャ

アーキテクチャコンポーネント

イラストの参照アーキテクチャは、AWS上のWordPressウェブサイトの完全なベストプラクティス展開を示しています。

Amazon CloudFrontのエッジキャッシング（1）から始まり、エンドユーザーの近くでコンテンツをキャッシュして配信を高速化します。
CloudFrontは、S3バケットから静的コンテンツをプルし（2）、Webインスタンスの前にApplication Load Balancerから動的コンテンツを取得します（4）。
Webインスタンスは、Amazon EC2インスタンスのAuto Scalingグループで実行されます（6）。
ElastiCacheクラスター（7）は、頻繁にクエリされるデータをキャッシュして、応答を高速化します。
Amazon Aurora MySQLインスタンス（8）は、WordPressデータベースをホストします。
WordPress EC2インスタンスは、各アベイラビリティーゾーンのEFSマウントターゲット（9）を介してAmazon EFSファイルシステム上の共有WordPressデータにアクセスします。インターネットゲートウェイ（3）を使用すると、VPCのリソースとインターネット間の通信が可能になります。各アベイラビリティーゾーンのNATゲートウェイ（5）により、プライベートサブネット（アプリとデータ）のEC2インスタンスがインターネットにアクセスできます。

Amazon VPC内には、パブリック（パブリックサブネット）とプライベート（アプリサブネットおよびデータサブネット）の2種類のサブネットがあります。パブリックサブネットに展開されたリソースは、パブリックIPアドレスを受け取り、インターネット上で公開されます。
Application Load Balancer（4）と管理用のBastionホストがここにデプロイされます。プライベートサブネットに展開されたリソースはプライベートIPアドレスのみを受け取るため、インターネット上で公開されないため、これらのリソースのセキュリティが向上します。
WordPress Webサーバーインスタンス（6）、ElastiCacheクラスターインスタンス（7）、Aurora MySQLデータベースインスタンス（8）、およびEFSマウントターゲット（9）はすべてプライベートサブネットにデプロイされます。

このセクションの残りの部分では、これらの各考慮事項について詳しく説明します。

Web層のスケーリング

シングルサーバーアーキテクチャをマルチサーバーでスケーラブルなアーキテクチャに進化させるには、Amazon EC2インスタンス、Amazon Machine Image（AMI）、ロードバランサー、自動スケーリング、ヘルスチェックの5つの主要コンポーネントを使用する必要があります。

AWSは、さまざまなEC2インスタンスタイプを提供しているため、パフォーマンスとコストの両方に最適なサーバー構成を選択できます。一般的に、WordPress Webサーバーには、コンピューティングに最適化された（たとえば、C4）インスタンスタイプが適しています。
AWSリージョン内の複数のアベイラビリティーゾーンにインスタンスをデプロイして、アーキテクチャ全体の信頼性を高めることができます。

EC2インスタンスを完全に制御できるため、rootアクセスでログインして、WordPress Webサイトの実行に必要なすべてのソフトウェアコンポーネントをインストールおよび構成できます。完了したら、その構成をAMIとして保存できます。これを使用して、行ったすべてのカスタマイズで新しいインスタンスを起動できます。

エンドユーザーのリクエストを複数のWebサーバーノードに配布するには、負荷分散ソリューションが必要です。
AWSは、複数のEC2インスタンスにトラフィックを分散する高可用性サービスであるElastic Load Balancingを通じてこの機能を提供します。
WebサイトはHTTPまたはHTTPSを介してユーザーにコンテンツを提供しているため、コンテンツルーティングと、必要に応じて異なるドメインで複数のWordPress Webサイトを実行する機能を備えたアプリケーション層ロードバランサーであるApplication Load Balancerを使用することをお勧めします。

Elastic Load Balancingは、AWSリージョン内の複数のアベイラビリティーゾーンにわたるリクエストの分散をサポートしています。
Application Load Balancerが（ハードウェアの問題やソフトウェアのクラッシュなどにより）失敗した個々のインスタンスへのトラフィックの送信を自動的に停止するように、ヘルスチェックを構成することもできます。このページはWebサーバーが実行されていることと、WebサーバーがPHPファイルを正しく提供するように構成されていることの両方を確認するため、ヘルスチェックにはWordPress管理ログインページ（/wp-login.php）を使用することをお勧めします。データベースやキャッシュリソースなど、他の依存リソースをチェックするカスタムヘルスチェックページを作成することもできます。詳細については、Application Load Balancer Guideのターゲットグループのヘルスチェックを参照してください。

弾力性はAWSクラウドの重要な特徴です。必要に応じてより多くの計算能力（たとえば、Webサーバー）を起動し、不要な場合は実行を減らすことができます。
AWS Auto Scalingは、このプロビジョニングを自動化して、手動の介入を必要とせずに定義した条件に従ってAmazon EC2の容量を拡大または縮小するのに役立つAWSサービスです。
AWS Auto Scalingを設定して、使用中のEC2インスタンスの数が需要の急増時にシームレスに増加してパフォーマンスを維持し、トラフィックが減少すると自動的に減少して、コストを最小限に抑えることができます。

Elastic Load Balancingは、ロードバランシングローテーションに対するAmazon EC2ホストの動的な追加と削除もサポートしています。
Elastic Load Balancing自体も、手動で介入することなくトラフィックの需要に合わせて負荷分散能力を動的に増減します。

ステートレスWeb層

自動スケーリング構成で複数のWebサーバーを利用するには、Web層がステートレスでなければなりません。ステートレスアプリケーションは、以前の相互作用の知識を必要とせず、セッション情報を保存しないアプリケーションです。
WordPressの場合、これは、どのWebサーバーがリクエストを処理したかに関係なく、すべてのエンドユーザーが同じ応答を受け取ることを意味します。リクエストはすべての利用可能なコンピューティングリソース（つまり、Webサーバーインスタンス）によって処理されるため、ステートレスアプリケーションは水平方向に拡張できます。その容量が不要になったら、個々のリソースを安全に終了できます（実行中のタスクが排出された後）。これらのリソースは、ピアの存在を認識する必要はありません。必要なのは、ワークロードをそれらに分散する方法だけです。

ユーザーセッションのデータストレージに関して言えば、WordPressコアは完全にステートレスです。これは、クライアントのWebブラウザーに格納されているCookieに依存しているためです。代わりにネイティブPHPセッションに依存するカスタムコード（WordPressプラグインなど）をインストールしていない限り、セッションストレージは問題になりません。

ただし、WordPressはもともと単一のサーバーで実行するように設計されていました。その結果、サーバーのローカルファイルシステムにデータを保存します。マルチサーバー構成でWordPressを実行する場合、Webサーバー間で不整合があるため問題が発生します。たとえば、ユーザーが新しい画像をアップロードした場合、サーバーの1つにのみ保存されます。

これは、重要なデータを共有ストレージに移動するためにデフォルトのWordPress実行設定を改善する必要がある理由を示しています。ベストプラクティスアーキテクチャでは、Webサーバーの外部に別のレイヤーとしてデータベースがあり、ユーザーのアップロード、テーマ、およびプラグインを保存するために共有ストレージを使用します。

共有ストレージ（Amazon S3およびAmazon EFS）

デフォルトでは、WordPressはユーザーのアップロードをローカルファイルシステムに保存するため、ステートレスではありません。したがって、Webサーバーの負荷を軽減し、Web層をステートレスにするために、WordPressインストールとすべてのユーザーカスタマイズ（構成、プラグイン、テーマ、ユーザー生成アップロードなど）を共有データプラットフォームに移動する必要があります。

Amazon Elastic File System（Amazon EFS）は、EC2インスタンスで使用するスケーラブルなネットワークファイルシステムを提供します。
Amazon EFSファイルシステムは、制約のない数のストレージサーバーに分散されているため、ファイルシステムを柔軟に拡張でき、EC2インスタンスからの超並列アクセスが可能になります。
Amazon EFSの分散設計は、従来のファイルサーバーに固有のボトルネックと制約を回避します。

WordPressインストールディレクトリ全体をEFSファイルシステムに移動し、起動時に各EC2インスタンスにマウントすることにより、WordPressサイトとそのすべてのデータは、1つのEC2インスタンスに依存しない分散ファイルシステムに自動的に保存されます、ウェブ層を完全にステートレスにします。このアーキテクチャの利点は、新しいインスタンスを起動するたびにプラグインとテーマをインストールする必要がなく、WordPressインスタンスのインストールと復旧を大幅に高速化できることです。このドキュメントの「導入に関する考慮事項」セクションで概説されているように、WordPressのプラグインとテーマへの変更を導入するのも簡単です。

EFSファイルシステムから実行するときにウェブサイトの最適なパフォーマンスを確保するには、WordPress用AWSリファレンスアーキテクチャでAmazon EFSおよびOPcacheの推奨構成設定を確認してください。

また、画像、CSS、JavaScriptファイルなどのすべての静的アセットを、CloudFrontキャッシュを前面に持つS3バケットにオフロードするオプションもあります。このホワイトペーパーの静的コンテンツのセクションで説明されているように、マルチサーバーアーキテクチャでこれを行うメカニズムは、シングルサーバーアーキテクチャの場合とまったく同じです。利点は、単一サーバーアーキテクチャの場合と同じです。静的アセットの提供に関連する作業をAmazon S3およびCloudFrontにオフロードできるため、Webサーバーは動的コンテンツのみの生成に集中し、Webサーバーごとにより多くのユーザーリクエストを処理できます。

データ層（Amazon AuroraおよびAmazon ElastiCache）

分散されたスケーラブルな共有ネットワークファイルシステムに保存されたWordPressインストール、およびAmazon S3から提供される静的アセットを使用すると、残りのステートフルコンポーネントであるデータベースに注意を集中できます。ストレージ層と同様に、データベースは単一のサーバーに依存するべきではないため、いずれかのWebサーバーでホストすることはできません。代わりに、Amazon AuroraでWordPressデータベースをホストします。

Amazon Auroraは、クラウド向けに構築されたMySQLおよびPostgreSQL互換のリレーショナルデータベースであり、ハイエンドの商用データベースのパフォーマンスと可用性と、オープンソースデータベースのシンプルさと費用対効果を兼ね備えています。
Aurora MySQLは、データベースエンジンをSSDを使用した専用の分散ストレージシステムと緊密に統合することにより、MySQLのパフォーマンスと可用性を向上させます。耐障害性と自己修復性を備え、3つのアベイラビリティーゾーンにデータの6つのコピーを複製し、99.99％を超える可用性のために設計され、Amazon S3のデータを継続的にバックアップします。
Amazon Auroraは、クラッシュの復旧やデータベースキャッシュの再構築を必要とせずに、データベースのクラッシュを自動的に検出して再起動するように設計されています。

Amazon Auroraは、メモリに最適化されたバースト可能なインスタンスなど、さまざまなアプリケーションプロファイルに合わせて多数のインスタンスタイプを提供します。データベースのパフォーマンスを向上させるために、より大きなCPUおよびメモリリソースを提供する大きなインスタンスタイプを選択できます。

Amazon Auroraは、プライマリインスタンスとAuroraレプリカの間のフェイルオーバーを自動的に処理するため、管理者が手動で介入しなくても、アプリケーションがデータベース操作をできる限り迅速に再開できます。通常、フェイルオーバーにかかる時間は30秒未満です。

少なくとも1つのAuroraレプリカを作成したら、クラスターエンドポイントを使用してプライマリインスタンスに接続し、プライマリインスタンスに障害が発生した場合にアプリケーションが自動的にフェールオーバーできるようにします。
3つのアベイラビリティーゾーンで最大15個の低レイテンシーリードレプリカを作成できます。

データベースが拡張されると、データベースキャッシュも拡張する必要があります。データベースキャッシュのセクションで前述したように、ElastiCacheには、ElastiCacheクラスター内の複数のノード間、およびリージョン内の複数のアベイラビリティーゾーンにわたってキャッシュをスケーリングして、可用性を向上させる機能があります。
ElastiCacheクラスターをスケーリングする場合、構成エンドポイントを使用して接続するようにキャッシュプラグインを構成し、WordPressが追加されると新しいクラスターノードを使用し、削除されると古いクラスターノードの使用を停止できるようにします。また、PHP用のElastiCacheクラスタークライアントを使用するようにWebサーバーを設定し、AMIを更新してこの変更を保存する必要があります。

AWSクイックスタートでのBitnamiによる高可用性WordPress

クイックスタートは、AWSソリューションアーキテクトとパートナーによって構築され、セキュリティと高可用性に関するAWSのベストプラクティスに基づいて、AWSで人気のあるテクノロジーを展開するのに役立ちます。
これらのアクセラレータは、数百の手動手順をわずか数ステップに削減するため、実稼働環境を迅速に構築し、すぐに使用を開始できます。
各クイックスタートには、デプロイを自動化するAWS CloudFormationテンプレートと、アーキテクチャについて説明し、ステップごとのデプロイ手順を提供するガイドが含まれています。

AWSクイックスタートでのBitnamiによるWordPress高可用性は、AWSで次の構成可能な環境をセットアップします。

• 2つのアベイラビリティーゾーンにまたがる高可用性アーキテクチャ。*
• AWSのベストプラクティスに従ってパブリックおよびプライベートサブネットで構成された仮想プライベートクラウド（VPC）。
  これにより、展開にネットワークインフラストラクチャが提供されます。*
• インターネットへのアクセスを提供するインターネットゲートウェイ。
  このゲートウェイは、要塞ホストがトラフィックを送受信するために使用します。*
• パブリックサブネットでは、プライベートサブネットのリソースへのアウトバウンドインターネットアクセスを許可する管理されたNATゲートウェイ。*
• パブリックサブネットでは、Auto ScalingグループのLinux要塞ホストが、パブリックおよびプライベートサブネットのEC2インスタンスへのインバウンドセキュアシェル（SSH）アクセスを許可します。*
• HTTPおよびHTTPSリクエストを複数のWordPressインスタンスに分散するElastic Load Balancing。
• プライベートサブネットでは、データベースクエリをキャッシュするためのMemcachedノード用のAmazon ElastiCache。

*クイックスタートを既存のVPCにデプロイするテンプレートは、アスタリスクでマークされたタスクをスキップし、既存のVPC設定のプロンプトを表示します。

図3：BitnamiによるWordPress高可用性アーキテクチャ

AWSでのBitnamiによるWordPress高可用性のデプロイの詳細な説明は、このドキュメントの範囲外です。
設定とオプションについては、AWSでのBitnamiによるWordPress高可用性を参照してください。

結論

AWSは、WordPressを実行するための多くのアーキテクチャオプションを提供します。
最も単純なオプションは、トラフィックの少ないWebサイト用の単一サーバーインストールです。
より高度なWebサイトの場合、サイト管理者は他のいくつかのオプションを追加できます。各オプションは、可用性とスケーラビリティの点で段階的な改善を表しています。
管理者は、要件と予算に最も近い機能を選択できます。

貢献者

このドキュメントの貢献者は次のとおりです。

• アマゾンウェブサービス、ソリューションアーキテクト Paul Lewis
• アマゾンウェブサービス、ソリューションアーキテクト、Ronan Guilfoyle
• アマゾンウェブサービス、ソリューションアーキテクトマネージャー、Andreas Chatzakis
• アマゾンウェブサービス、テクニカルアカウントマネージャー、Jibril Touzi

ドキュメントの変更履歴

付録A：CloudFrontの構成

WordPressウェブサイトでAmazon CloudFrontを使用する際に最適なパフォーマンスと効率を得るには、提供されるさまざまなタイプのコンテンツに合わせてウェブサイトを正しく設定することが重要です。

オリジンとビヘイビアー

オリジンは、CloudFrontがエッジロケーションを通じて配信するコンテンツのリクエストを送信するロケーションです。
実装に応じて、1つまたは2つの起源を持つことができます。
カスタムオリジンを使用する動的コンテンツ（単一サーバー展開オプションのLightsailインスタンス、または弾性展開オプションのApplication Load Balancer）用の1つ。
静的コンテンツのためにCloudFrontを誘導する2番目のオリジンが存在する場合があります。
前述のリファレンスアーキテクチャでは、これはS3バケットです。
ディストリビューションのオリジンとしてAmazon S3を使用する場合は、バケットポリシーを使用して、コンテンツをパブリックにアクセスできるようにする必要があります。

ビヘイビアーを使用すると、CloudFrontがコンテンツをキャッシュする方法を管理するルールを設定し、キャッシュの有効性を決定できます。
ビヘイビアを使用すると、WebサイトにアクセスできるプロトコルとHTTPメソッドを制御できます。
また、HTTPヘッダー、Cookie、またはクエリ文字列をバックエンドに渡すかどうか（もしそうなら、どの文字列か）も制御できます。
動作は特定のURLパスパターンに適用されます。

CloudFrontディストリビューションの作成

ディストリビューションに従ってCloudFrontウェブディストリビューションを作成します。自動的に作成されたデフォルトのオリジンと動作が動的コンテンツに使用されます。
4つの追加の動作を作成して、静的要求と動的要求の両方の処理方法をさらにカスタマイズします。
次の表は、5つの動作の構成プロパティをまとめたものです。
この手動設定をスキップして、付録B：プラグインのインストールと設定で説明されているAWS for WordPressプラグインを使用することもできます。これは、WordPressサイトを高速化するためにCloudFrontを設定する最も簡単な方法です。

表1：CloudFront動作の構成プロパティの概要

デフォルトの動作では、次の構成をお勧めします。

• オリジンプロトコルポリシーがビューアーに一致するようにします。これにより、ビューアーがHTTPSを使用してCloudFrontに接続する場合、CloudFrontもHTTPSを使用してオリジンに接続し、エンドツーエンドの暗号化を実現します。
  これには、信頼できるSSL証明書をロードバランサーにインストールする必要があることに注意してください。
  詳細については、CloudFrontとカスタムオリジン間の通信にHTTPSを要求するを参照してください。
• Webサイトの動的な部分にはGET要求とPOST要求の両方が必要なので（たとえば、コメント送信フォームのPOSTをサポートするため）、すべてのHTTPメソッドを許可します。
• wordpress _ 、wp-settings-、comment_ *など、WordPress出力を変更するCookieのみを転送します。
  リストにない他のCookieに依存するプラグインをインストールした場合は、そのリストを拡張する必要があります。
• ホスト、CloudFront-Forwarded-Proto、CloudFront-is-Desktop-Viewer、CloudFront-is-Mobile-Viewer、CloudFront-is-Tablet-Viewerなど、WordPressの出力に影響するHTTPヘッダーのみを転送します。
  • ホストでは、複数のWordPress Webサイトを同じオリジンでホストできます。
  • CloudFront-Forwarded-Protoでは、HTTPまたはHTTPSのどちらでアクセスするかに応じて、異なるバージョンのページをキャッシュできます。
  • CloudFront-is-Desktop-Viewer、CloudFront-is-Mobile-Viewer、CloudFront-is-Tablet-Viewerでは、エンドユーザーのデバイスタイプに基づいてテーマの出力をカスタマイズできます。
• WordPressはこれらに依存しているため、値に基づいてすべてのクエリ文字列をキャッシュに転送します。また、キャッシュされたオブジェクトを無効にするために使用することもできます。

カスタムドメイン名（つまり、*。cloudfront.netではない）でWebサイトを提供する場合は、[配布設定]の[代替ドメイン名]に適切なURIを入力します。
この場合、カスタムドメイン名のSSL証明書も必要です。
AWS Certificate Managerを介してSSL証明書をリクエストし、CloudFrontディストリビューションに対して設定できます。

次に、動的コンテンツのキャッシュビヘイビアをさらに2つ作成します。1つはログインページ用（パスパターン：wp-login.php）、もう1つは管理ダッシュボード用（パスパターン：wp-admin / *）です。
これらの2つの動作には、次のようにまったく同じ設定があります。

• HTTPSのみのビューアプロトコルポリシーを適用します。
• すべてのHTTPメソッドを許可します。
• すべてのHTTPヘッダーに基づいたキャッシュ。
• すべてのCookieを転送します。
• すべてのクエリ文字列に基づいて転送およびキャッシュします。

この設定の背後にある理由は、ウェブサイトのこのセクションが高度にパーソナライズされており、通常は数人のユーザーしかいないため、キャッシュの効率が主な関心事ではないためです。
焦点は、すべてのCookieとヘッダーをオリジンに渡すことにより、インストールされているプラグインとの最大の互換性を確保するために、構成をシンプルに保つことです。

付録Bで説明したAWS for WordPressプラグインは、前述の構成を満たすCloudFrontディストリビューションを自動的に作成します。

デフォルトでは、WordPressはすべてをWebサーバーにローカルに保存します。これは、単一サーバー展開の場合はブロックストレージ（Amazon EBS）、エラスティック展開の場合はファイルストレージ（Amazon EFS）です。
ストレージおよびデータ転送のコストを削減することに加えて、静的アセットをAmazon S3に移動すると、スケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスが提供されます。
静的コンテンツをAmazon S3に簡単に移動できるようにするプラグインがいくつかあります。
それらの1つはW3 Total Cacheであり、付録B：プラグインのインストールと構成でも説明されています。

付録B：プラグインのインストールと構成

AWS for WordPressプラグイン

AWS for WordPressプラグインは、AWSが作成し、積極的に保守している唯一のWordPressプラグインです。これにより、顧客はWordPressウェブサイトにAmazon CloudFrontとAWS Certificate Manager（ACM）を簡単に設定して、パフォーマンスとセキュリティを強化できます。プラグインは、Amazon Machine Learningサービスを使用してコンテンツを1つ以上の言語に翻訳し、各翻訳の音声バージョンを生成し、Amazon Alexaデバイスを介してWordPress Webサイトを読み取ります。

プラグインのインストールと構成

プラグインをインストールするには、

1. WordPressプラグインマーケットプレイスにアクセスします。
2. AWS for WordPressを検索し、[インストール]を選択します。
3. WordPressプラグイン管理パネルで、WordPress用のAWSを選択し、[設定]タブの手順に従ってプラグインをセットアップします。
4. AWSアカウントの認証と承認を制御するには、AWS Identity and Access Management（IAM）ロールまたはIAMユーザーが必要です。
   IAMロールを使用することをお勧めします。IAMロールは、AWSが自動的に作成、配布、ローテーションする一時的なセキュリティ認証情報をAmazon EC2で実行するアプリケーションで使用できるようにすることで、AWSリソースへのアクセスを管理するより良い方法を提供するためです。
5. AWS for WordPressプラグインページの[設定]タブにあるIAMポリシーをコピーし、IAMロールにアタッチします。このポリシーにより、WordPressプラグインは、プラグイン内で使用されるサービスを作成および更新するために必要なコマンドのみを実行できます。

すべてのAWS for WordPress設定の詳細な説明は、このドキュメントの範囲外です。設定とオプションについては、AWS for WordPressをご覧ください。

Amazon CloudFrontおよびAWS Certificate Manager

CloudFrontとAWS Certificate Managerをセットアップするには：

1. プラグインメニューで、CloudFrontを選択し、次のパラメーターを入力します。
   • オリジンドメイン名：CloudFrontがウェブサイトのコンテンツを取得するHTTPオリジンサーバーのDNSドメイン（example.comなど）。
   • 代替ドメイン名（CNAME）：ウェブサイトの高速化のために訪問者が使用するドメイン名。ドメインの前に「www」を使用することをお勧めします（www.example.comなど）。
2. [セットアップの開始]を選択して、構成を開始します。
   プラグインはACMを介してCNAMEのSSL証明書を自動的に要求します。CNAMEエントリでDNSレコードを更新してACMトークンを検証すると、プラグインは付録Aで定義されたベストプラクティスを満たすCloudFrontディストリビューションを作成します。

WordPressプラグインでは、CloudFrontとカスタムオリジン間の通信にHTTPSが必要です。オリジンにオリジンドメイン名に対して有効なSSL証明書があることを確認してください。詳細については、「CloudFrontでHTTPSを使用する」を参照してください。

コンテンツを翻訳して声を出す

AWS for WordPressプラグインを使用すると、テキストをさまざまな言語で自動的に翻訳し、記述されたコンテンツを多言語オーディオ形式に変換できます。これらの機能は、Amazon Machine Learningサービスによって強化されています。

Amazon Pollyは、テキストをリアルなスピーチに変換するサービスです。さまざまな言語で多数の音声を使用して、理想的な音声を選択し、さまざまな国で機能する魅力的な音声対応アプリケーションを構築できます。プラグインを使用して、Amazon Pollyでサポートされている任意の音声と言語でオーディオファイルを作成します。訪問者は、インラインオーディオプレーヤーとモバイルアプリケーションを使用して、都合の良いときにオーディオをストリーミングできます。

デフォルトでは、プラグインは新しいオーディオファイルをWebサーバーに保存します。
Amazon S3またはAmazon CloudFrontにファイルを保存することを選択できます。オーディオファイルの保存場所に関係なく、ユーザーは同じリスニングエクスペリエンスを利用できます。ブロードキャストロケーションのみが変更されます。

• WordPressサーバーに保存されているオーディオファイルの場合、ファイルはサーバーから直接ブロードキャストされます。
• S3バケットに保存されているファイルの場合、ファイルはバケットからブロードキャストされます。
• CloudFrontを使用する場合、ファイルはAmazon S3に保存され、CloudFrontでブロードキャストされます。

図4：ブロードキャストロケーション

Amazon Translateは、高速で高品質で手頃な価格の言語翻訳を提供する機械翻訳サービスです。
多言語コンテンツを提供することは、サイト所有者にとって大きなチャンスです。
英語はウェブの主要言語ですが、英語を母国語とする人はオンラインの全視聴者のわずか26％です。

WordPressコンテンツの書面および音声バージョンを複数の言語で提供することにより、より多くの国際的な視聴者のニーズを満たすことができます。
以下を実行するようにプラグインを構成できます。

• 異なる言語に自動的に翻訳し、公開時に新しいコンテンツの各翻訳の音声録音を作成するか、個々の投稿の翻訳を作成して録音を選択する
• さまざまな言語に翻訳し、アーカイブされたコンテンツの翻訳ごとに録音を作成します
• Amazon Pollycast RSSフィードを使用してオーディオコンテンツをポッドキャストする

図5：コンテンツの翻訳と音声のテキストの概要

Amazon Pollycastによるポッドキャスティング

Amazon Pollycastフィードを使用すると、訪問者は標準のポッドキャストアプリケーションを使用してオーディオコンテンツを聴くことができます。
RSS 2.0準拠のPollycastフィードは、iTunesなどの一般的なモバイルポッドキャストアプリケーションやポッドキャストディレクトリによるポッドキャストの集約に必要なXMLデータを提供します。

AWS for WordPressプラグインをインストールすると、「Podcast」設定タブでXMLフィードの生成を有効にするオプションが表示されます。また、複数のオプションプロパティを設定するオプションもあります。機能を有効にすると、フィードを実行するリンクを受け取ります。

Amazon Alexaデバイスを介してコンテンツを読む

Alexaデバイスを介してWordPress Webサイトおよびブログを拡張できます。これにより、Webサイトの作成者および作成者がさらに幅広いユーザーにリーチできる新しい可能性が開かれます。また、Alexaに読んでもらうだけで、お気に入りのブログを簡単に聞くことができます！

WordPress WebサイトをAlexaに公開するには、次を有効にする必要があります。

• AWS for WordPressプラグイン。
• テキスト読み上げとAmazon Pollycastの機能。これらの機能は、Amazon Alexaによって消費されるRSSフィードをWordPressサイトに生成します。
• テキスト読み上げのファイルのデフォルトストレージとしてのAmazon S3。ウェブサイトが安全なHTTPS接続を使用してフィードをAlexaに公開することが重要です。

次の図は、Alexaを介してWebサイトを公開するために必要な相互作用とコンポーネントのフローを示しています。

図6：Alexaを介してWordPress Webサイトを公開するために必要なインタラクションのフロー

1. ユーザーが新しいAlexaスキルを呼び出します。たとえば、次のように言います。Alexa、デモブログに最新のアップデートを依頼します。
   スキル自体は、Alexaスキルブループリントの1つを使用して作成されます。
   これにより、高度な技術知識がなくても、Alexaデバイスを通じてスキルを公開できます。
2. Alexaスキルは、AWS for WordPressプラグインによって生成された呼び出しとRSSフィードを分析し、最新バージョンの音声バージョンへのリンクを返します。
3. フィードが提供するリンクに基づいて、AlexaはAmazon S3に保存されたオーディオファイルを再生して記事を読み取ります。

プラグインとその機能をインストールおよび構成するための詳細な手順ガイドについては、WordPressマーケットプレイスのプラグインページを参照してください。

静的コンテンツの構成

デフォルトでは、WordPressはすべてをWebサーバーにローカルに保存します。これは、単一サーバー展開の場合はブロックストレージ（Amazon EBS）、エラスティック展開の場合はファイルストレージ（Amazon EFS）です。ストレージおよびデータ転送コストの削減に加えて、静的資産をAmazon S3に移動すると、スケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスが提供されます。

この例では、W3 Total Cache（W3TC）プラグインを使用して、Amazon S3に静的アセットを保存します。ただし、同様の機能を備えたプラグインは他にもあります。別の方法を使用する場合は、それに応じて次の手順を調整できます。手順では、この例に関連する機能または設定のみを参照しています。すべての設定の詳細な説明は、このドキュメントの範囲外です。詳細については、wordpress.orgのW3 Total Cacheプラグインページを参照してください。

IAMユーザーの作成

Amazon S3に静的アセットを保存するには、WordPressプラグイン用のAWS Identity and Access Management（IAM）ユーザーを作成する必要があります。手順については、「AWSアカウントでのIAMユーザーの作成」を参照してください。

注：IAMロールはAWSリソースへのアクセスを管理するより良い方法を提供しますが、執筆時点では、W3 Total CacheプラグインはIAMロールをサポートしていません。

ユーザーのセキュリティ認証情報をメモして安全な方法で保存します。これらの認証情報は後で必要になります。

Amazon S3バケットの作成

まず、選択したAWSリージョンにAmazon S3バケットを作成します。手順については、「Amazon S3バケットの作成」を参照してください。ウェブサイトホスティング用のバケットを設定するためのガイドに従って、バケットの静的ウェブサイトホスティングを有効にします。

IAMポリシーを作成して、指定されたS3バケットへの以前のアクセスを作成したIAMユーザーに提供し、ポリシーをIAMユーザーにアタッチします。次のポリシーを作成する手順については、「IAMポリシーの管理」を参照してください。

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"Stmt1389783689000",
         "Effect":"Allow",
         "Principal":"*",
         "Action":[
            "s3:DeleteObject",
            "s3:GetObject",
            "s3:GetObjectAcl",
            "s3:ListBucket",
            "s3:PutObject",
            "s3:PutObjectAcl"
         ],
         "Resource":[
            "arn:aws:s3:::wp-demo",
            "arn:aws:s3:::wp-demo/*"
         ]
      }
   ]
}

WordPress管理パネルからW3TCプラグインをインストールしてアクティブ化します。
プラグインの設定の[一般設定]セクションを参照し、ブラウザキャッシュとCDNの両方が有効になっていることを確認します。
CDN構成のドロップダウンリストから、[Origin Push：Amazon CloudFront]を選択します（このオプションでは、Amazon S3がオリジンになります）。

プラグインの設定のブラウザキャッシュセクションを参照し、有効期限、キャッシュ制御、エンティティタグ（ETag）ヘッダーを有効にします。
また、設定が変更されたときに新しいクエリ文字列が生成され、オブジェクトに追加されるように、[設定変更後のオブジェクトのキャッシュを防ぐ]オプションをアクティブにします。

プラグインの設定のCDNセクションを参照し、前に作成したIAMユーザーのセキュリティ認証情報とS3バケットの名前を入力します。
CloudFront URL経由でWebサイトを提供している場合、関連するボックスに配信ドメイン名を入力します。
それ以外の場合は、カスタムドメイン名に1つ以上のCNAMEを入力します。

最後に、W3TCプラグインを使用して、メディアライブラリをエクスポートし、wp-includes、テーマファイル、およびカスタムファイルをAmazon S3にアップロードします。
これらのアップロード機能は、CDN構成ページの[全般]セクションで利用できます。

静的オリジン作成

静的ファイルがAmazon S3に保存されたので、CloudFrontコンソールでCloudFront構成に戻り、静的コンテンツのオリジンとしてAmazon S3を構成します。これを行うには、その目的のために作成したS3バケットを指す2番目のオリジンを追加します。次に、動的コンテンツのデフォルトのオリジンではなく、S3オリジンを使用する2つのフォルダー（wp-contentおよびwp-includes）のそれぞれに1つずつ、さらに2つのキャッシュ動作を作成します。同じ方法で両方を構成します。

• HTTP GET要求のみを提供します。
• Amazon S3は、CookieまたはHTTPヘッダーに基づいて出力を変更しないため、CloudFrontを介してオリジンに転送しないことで、キャッシュの効率を改善できます。
• これらの動作は静的なコンテンツ（パラメータを受け入れない）のみを提供するという事実にもかかわらず、クエリ文字列をオリジンに転送します。これは、クエリ文字列をバージョン識別子として使用して、たとえば、新しいバージョンを展開するときに古いCSSファイルを即座に無効にできるようにするためです。詳細については、Amazon CloudFront開発者ガイドを参照してください。

注：CloudFrontディストリビューションに静的オリジンの動作を追加した後、順序を確認して、wp-admin / *およびwp-login.phpの動作が静的コンテンツの動作よりも高い優先順位を持っていることを確認します。そうしないと、管理パネルにアクセスしたときに奇妙な動作が見られる場合があります。

付録C：バックアップと復元

AWSでの障害からの回復は、従来のホスティング環境と比較して、より速く簡単に実行できます。
たとえば、ハードウェア障害に対応して数分で交換インスタンスを起動したり、多くのマネージドサービスで自動フェールオーバーを使用して、定期的なメンテナンスによる再起動の影響を無効にしたりできます。

ただし、データを正常に回復するには、適切なデータをバックアップしていることを確認する必要があります。
WordPress Webサイトの可用性を再確立するには、次のコンポーネントを回復できる必要があります。

• オペレーティングシステム（OS）およびサービスのインストールと構成（Apache、MySQLなど）
• WordPressアプリケーションのコードと構成
• WordPressのテーマとプラグイン
• アップロード（たとえば、投稿用のメディアファイル）
• データベースコンテンツ（投稿、コメントなど）

ホワイトペーパー「アマゾンウェブサービスを使用したバックアップと復元のアプローチ」で詳しく説明されているように、AWSはウェブアプリケーションのデータとアセットをバックアップおよび復元するためのさまざまな方法を提供します。

以前に、Lightsailスナップショットを使用して、インスタンスのローカルストレージに保存されているすべてのデータを保護することについて説明しました。
WordPress WebサイトがLightsailインスタンスのみで実行されている場合、WordPress Webサイト全体を復元するには、通常のLightsailスナップショットで十分です。ただし、スナップショットから復元すると、最後のスナップショットが取得されてから、Webサイトに適用された変更は失われます。

マルチサーバー展開では、さまざまなメカニズムを使用して、前述の各コンポーネントをバックアップする必要があります。各コンポーネントには、バックアップ頻度の要件が異なる場合があります。たとえば、OSとWordPressのインストールと構成は、ユーザーが生成したコンテンツよりも頻繁に変更されないため、回復時にデータを失うことなくバックアップの頻度を減らすことができます。

OSとサービスのインストールと構成、およびWordPressアプリケーションのコードと構成をバックアップするには、適切に構成されたEC2インスタンスのAMIを作成できます。
AMIには2つの目的があります。インスタンス状態のバックアップとして機能することと、新しいインスタンスを起動するときにテンプレートとして機能することです。

WordPressアプリケーションのコードと構成をバックアップするには、AMIとAuroraバックアップも利用する必要があります。

ウェブサイトにインストールされているWordPressテーマとプラグインをバックアップするには、Amazon S3バケットまたはそれらが保存されているAmazon EFSファイルシステムをバックアップします。

• S3バケットに保存されているテーマとプラグインの場合、クロスリージョンレプリケーションを有効にして、プライマリバケットにアップロードされたすべてのオブジェクトが別のAWSリージョンのバックアップバケットに自動的に複製されるようにすることができます。クロスリージョンレプリケーションでは、ソースバケットとデスティネーションバケットの両方でバージョニングが有効になっている必要があります。これにより、追加の保護レイヤーが提供され、バケット内の任意のオブジェクトの以前のバージョンに戻すことができます。
• EFSファイルシステムに保存されたテーマとプラグインの場合、AWS Data Pipelineを作成して、本番EFSファイルシステムから別のEFSファイルシステムにデータをコピーできます（ドキュメントページのEFSファイルシステムのバックアップを参照）。使い慣れたバックアップアプリケーションを使用してEFSファイルシステムをバックアップすることもできます。
• ユーザーのアップロードをバックアップするには、WordPressのテーマとプラグインをバックアップするための前述の手順に従う必要があります。
• データベースコンテンツをバックアップするには、Auroraバックアップを使用する必要があります。
  Auroraはクラスターボリュームを自動的にバックアップし、バックアップ保持期間の間、復元データを保持します。
  Auroraのバックアップは連続的かつ増分的であるため、バックアップ保持期間内の任意の時点にすばやく復元できます。バックアップデータの書き込み中に、パフォーマンスへの影響やデータベースサービスの中断は発生しません。
  1〜35日間のバックアップ保持期間を指定できます。手動のデータベーススナップショットを作成することもできます。これは、削除するまで保持されます。手動のデータベーススナップショットは、長期のバックアップとアーカイブに役立ちます。

付録D：新しいプラグインとテーマの展開

静的なWebサイトはほとんどありません。ほとんどの場合、公開されているWordPressのテーマとプラグインを定期的に追加するか、新しいWordPressバージョンにアップグレードします。また、独自のカスタムテーマとプラグインをゼロから開発する場合もあります。

WordPressのインストールに構造的な変更を加えると、予期しない問題が発生するリスクがあります。少なくとも、重要な変更（新しいプラグインのインストールなど）を適用する前に、アプリケーションコード、構成、およびデータベースのバックアップを作成してください。ビジネスまたは他の価値のあるWebサイトの場合、最初にこれらの変更を別のステージング環境でテストします。
AWSを使用すると、運用環境の構成を簡単に複製し、展開プロセス全体を安全な方法で実行できます。テストが完了したら、テスト環境を破棄して、それらのリソースへの支払いを停止できます。後で、WordPress固有の考慮事項について説明します。

一部のプラグインはwp_optionsデータベーステーブルに構成情報を書き込む（またはデータベーススキーマの変更を導入する）一方で、他のプラグインはWordPressインストールディレクトリに構成ファイルを作成します。データベースとストレージを共有プラットフォームに移動したので、これらの変更は、実行中のすべてのインスタンスですぐに利用できるようになります。

WordPressで新しいテーマを展開するとき、もう少し手間がかかる場合があります。すべてのWordPressインストールファイルを保存するためにAmazon EFSのみを使用している場合、実行中のすべてのインスタンスで新しいテーマをすぐに使用できます。ただし、静的コンテンツをAmazon S3にオフロードする場合は、これらのコピーを適切なバケットの場所に処理する必要があります。
W3 Total Cacheのようなプラグインは、そのタスクを手動で開始する方法を提供します。または、ビルドプロセスの一部としてこのステップを自動化できます。

テーマアセットはCloudFrontとブラウザでキャッシュできるため、変更をデプロイするときに古いバージョンを無効にする方法が必要です。これを実現する最善の方法は、オブジェクトに何らかのバージョン識別子を含めることです。この識別子は、日時スタンプ付きのクエリ文字列またはランダムな文字列です。
W3 Total Cacheプラグインを使用する場合、メディアファイルのURLに追加されるメディアクエリ文字列を更新できます。