翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ステートレスウェブ層
自動スケーリング設定で複数のウェブサーバーを利用するには、ウェブ層がステートレスである必要があります。ステートレスアプリケーションは、以前のインタラクションに関する知識を必要とせず、セッション情報を保存しないアプリケーションです。の場合 WordPress、これは、どのウェブサーバーがリクエストを処理したかに関係なく、すべてのエンドユーザーが同じレスポンスを受け取ることを意味します。ステートレスアプリケーションは水平方向にスケーリングできます。これは、利用可能なコンピューティングリソース (つまり、ウェブサーバーインスタンス) によってリクエストを処理できるためです。その容量が不要になった場合、個々のリソースを安全に終了できます (実行中のタスクがドレインされた後）。これらのリソースは、ピアの存在を認識する必要はありません。必要なのは、ワークロードを分散する方法だけです。
ユーザーセッションデータストレージの場合、 WordPress コアはクライアントのウェブブラウザに保存されている Cookie に依存するため、完全にステートレスです。代わりにネイティブセッションに依存するカスタムコード ( WordPress プラグインなど) をインストールしない限り、PHPセッションストレージは問題ではありません。
ただし、当初 WordPress は 1 つのサーバーで実行されるように設計されています。その結果、一部のデータはサーバーのローカルファイルシステムに保存されます。マルチサーバー設定 WordPress で を実行すると、ウェブサーバー間で不整合があるため、問題が発生します。例えば、ユーザーが新しいイメージをアップロードした場合、そのイメージはいずれかのサーバーにのみ保存されます。
これは、重要なデータを共有ストレージに移動するために、デフォルトの WordPress実行設定を改善する必要がある理由を示しています。ベストプラクティスアーキテクチャには、データベースがウェブサーバー外の別のレイヤーとしてあり、共有ストレージを使用してユーザーアップロード、テーマ、プラグインを保存します。
# 共有ストレージ (Amazon S3 と Amazon EFS）
デフォルトでは、 は WordPress ユーザーアップロードをローカルファイルシステムに保存するため、ステートレスではありません。したがって、ウェブサーバーの負荷を軽減し、ウェブ層をステートレスにするには、 WordPress インストールとすべてのユーザーカスタマイズ (設定、プラグイン、テーマ、ユーザー生成アップロードなど) を共有データプラットフォームに移動する必要があります。
[Amazon Elastic File System](https://aws.amazon.com/efs/details/) (Amazon EFS) は、EC2インスタンスで使用できるスケーラブルなネットワークファイルシステムを提供します。Amazon EFS ファイルシステムは、無制限の数のストレージサーバーに分散されているため、ファイルシステムは伸縮自在に成長し、EC2インスタンスからの大規模な並列アクセスが可能になります。Amazon の分散設計は、従来のファイルサーバーに固有のボトルネックや制約EFSを回避します。
WordPress インストールディレクトリ全体をEFSファイルシステムに移動し、起動時に各EC2インスタンスにマウントすることで、 WordPress サイトとそのすべてのデータは、1 つのEC2インスタンスに依存しない分散ファイルシステムに自動的に保存され、ウェブ層が完全にステートレスになります。このアーキテクチャの利点は、新しいインスタンスの起動ごとにプラグインやテーマをインストールしなくても、 WordPress インスタンスのインストールと復旧を大幅に高速化できることです。また、このドキュメントのデプロイ[に関する考慮事項](appendix-a-cloudfront-configuration.md)セクションで説明されているように WordPress、 のプラグインとテーマに変更をデプロイする方が簡単です。
EFS ファイルシステムから実行するときにウェブサイトのパフォーマンスを最適化するには、 のリファレンスアーキテクチャOPcacheで Amazon EFSおよび の推奨設定を確認してください。 [AWS WordPress](https://github.com/awslabs/aws-refarch-wordpress#opcache)
また、イメージ、、CSS JavaScript ファイルなどのすべての静的アセットを、 CloudFront キャッシュを前にして S3 バケットにオフロードすることもできます。マルチサーバーアーキテクチャでこれを行うメカニズムは、このホワイトペーパーの[静的コンテンツ](accelerating-content-delivery.md)セクションで説明されているように、単一サーバーアーキテクチャの場合とまったく同じです。利点は、単一サーバーアーキテクチャの場合と同じです。静的アセットの提供に関連する作業を Amazon S3 および にオフロードできるため CloudFront、ウェブサーバーは動的コンテンツのみの生成に集中し、ウェブサーバーあたりのユーザーリクエスト数を増やすことができます。
# データ階層 (Amazon Aurora と Amazon ElastiCache）
Amazon S3 から提供される分散されたスケーラブルな共有ネットワークファイルシステムおよび静的アセットに WordPress インストールを保存すると、残りのステートフルコンポーネントであるデータベースに注意を払うことができます。ストレージ層と同様に、データベースは単一のサーバーに依存しないため、いずれかのウェブサーバーでホストすることはできません。代わりに、Amazon Aurora で WordPress データベースをホストします。
[Amazon Aurora](https://aws.amazon.com/rds/aurora) は、クラウド用に構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。ハイエンドの商用データベースのパフォーマンスと可用性と、オープンソースデータベースのシンプルさとコスト効率を兼ね備えています。Aurora MySQL は、データベースエンジンを にバックアップされた専用の分散ストレージシステムと緊密に統合することで、パフォーマンスSQLと可用性を向上させますSSD。耐障害性と自己修復性を備え、3 つのアベイラビリティーゾーンに 6 つのデータのコピーをレプリケートし、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 秒未満です。
少なくとも 1 つの Aurora レプリカを作成したら、クラスターエンドポイントを使用してプライマリインスタンスに接続し、プライマリインスタンスが失敗した場合にアプリケーションが自動的にフェイルオーバーできるようにします。3 つのアベイラビリティーゾーンで最大 15 個の低レイテンシーリードレプリカを作成できます。
データベースがスケールすると、データベースキャッシュもスケールする必要があります。[データベースキャッシュ](database-caching.md)セクションで前述したように、 には、可用性を向上させるために、 ElastiCache クラスター内の複数のノードとリージョン内の複数のアベイラビリティーゾーンにキャッシュをスケーリングする機能 ElastiCache があります。 ElastiCache クラスターをスケーリングするときは、設定エンドポイントを使用して接続するようにキャッシュプラグインを設定し、 が新しいクラスターノードを追加時に WordPress 使用できるようにし、古いクラスターノードを削除時に使用を停止します。また、 [ElastiCache のクラスタークライアントPHP](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html)を使用するようにウェブサーバーを設定し、この変更を保存するAMIように を更新する必要があります。