翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 共有ストレージ (Amazon S3 と Amazon EFS）
<a name="shared-storage-amazon-s3-and-amazon-efs"></a>

 デフォルトでは、 は 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、ウェブサーバーは動的コンテンツのみの生成に集中し、ウェブサーバーあたりのユーザーリクエスト数を増やすことができます。