WordPress —すべて— EFSに配置します。
私はWordPressサイトを所有しており、現時点では Amazon Lightsail インスタンスで完全に実行しています。適切にバックアップされます。可用性は大丈夫です。セキュリティは良好です。それは維持するための簡単な設定です。大丈夫だよ。
サイトを Amazon Elastic Beanstalk に移動し、サイトのバックエンドに他のいくつかの大きな変更を加えて（サイトデータベースをPHPサーバー、nginxへの移動など）。 EBSはLightsailよりも堅牢なサーバーセットアップにすぎません。
BeanstalkでWordPressサイトを作成するための Amazon提供のチュートリアル では、 Amazon Elasticに_/wp-content/uploads/_のみをマウントすることをお勧めしますファイルシステム 、およびデフォルトの構成スクリプトがお客様のために実行されます。これを行うことの欠点は、コアWordPressファイルがEC2インスタンス間で共有されないことです。代わりにインスタンスごとに複製されるため、サイトでWordPress更新プロセスを実行すると、一部のインスタンスが実際に更新されず、望ましくない動作が発生します。
チュートリアルでは、WordPressの（ベータ）エクスポートツールを使用してすべてのサイトコンテンツをエクスポートして ひどいプロセス を実行し、WordPress（およびプラグイン）を更新して、更新されたWordPressを実行している新しいBeanstalk環境で（ベータ）インポートツールを使用してインポートします。
私はこのプロセスを自動化してWordPressを更新する方が簡単であるように厳密に反対しているわけではありませんが、最新の状態を維持することを重視しているので、それを行うために最適化したいと考えています。私（または任意の顧客）は、システムまたはプラグインの更新プロセスでWordPressのベータインポートおよびエクスポートツールを使用します。
たとえば、これらの更新は、WordPressが自動パッチシステムを提供するセキュリティ更新である場合があります。これは、サイトのセキュリティを最大化するために非常に望ましいものです。ただし、コアWordPressファイルがEC2インスタンス間で共有されていない場合、すでに説明した更新の課題のため、自動パッチは期待どおりに機能しません。
このすべてが言ったと：
_/wp-content/uploads/_ディレクトリだけでなく、すべてのWordPressファイルを共有EFSストレージに配置すると、アーキテクチャまたはシステムのどの問題が発生する可能性がありますか？
もちろん、私は自分のテストを行ってどのように進むかを確認しますが、何を探しているのか、もしあれば、これを行おうとするときに期待をどこに設定すべきかを知りたいのです。
（注意：私は専門家ではありませんが、未回答の質問を探していたので、serverfault.comに返金することができます）
最初にLightsailのスケーリングを追求します。ドキュメント（ https://aws.Amazon.com/lightsail/features/ ）では、ロードバランサーを使用して複数のインスタンスを持つことについて説明しています。試しましたか？ CloudWatchモニタリングをチェックして、インスタンスのビジー状態を確認してください。水平スケーリングを使用すると、応答時間を短縮できます。また、Lightsailを展開してスタンドアロンのデータベースインスタンスを使用することもできます。
私の考えでは、計算の効率に関して言えば、Word Pressは野獣です。 1つのリクエストを実行するために100のスクリプトをロードできます。トリミングすると効果があります。不要なプラグインはありますか？コードをより少ない数のモジュールに組み合わせることができますか？おそらく、サイトの高速化に役立つ最適化/プロファイリングツールがあるでしょう。
また、サイトのどの程度が静的ファイル配信と計算のどちらであるかを検討します。静的ファイルをAWS S3にオフロードすることは、優れたソリューションです。また、CDNキャッシュ（AWS CDNなど）を実装すると、非計算ページのロード時の応答時間が速くなり、コンテンツがユーザーのいる場所の近くに移動する可能性があります。そして、最後に、しかし見過ごされがちなのは、特定のページをロードするためにユーザーが行う必要があるHTTPリクエストの数だけです。ロードする必要がある多くのJSライブラリがありますか？それらを1つのトランザクションでロードできる1つのファイルに統合することを検討してください。 ChromeまたはFirefoxでブラウザ開発ツールを使用すると、遅延の原因を正確に特定するのに役立ちます。
サーバーの管理方法を使用する場合は、更新WPを簡単な方法で実行できます。Dockerコンテナーの使用を開始することをお勧めします。実行するイメージは1つだけです。 N台のサーバーで各サーバーを最新の状態に保ちます。イメージにAWS ECRを使用します。WPまたはプラグインを更新する場合は、新しいコンテナーイメージバージョンをビルドします。次にAWS EKSまたはFargateを使用して、新しいバージョンをローリング方式でロールアウトできます。これはすべて、ペットと牛のトピックの一部です。個々のサーバー（コンテナ）でメンテナンスを行うことはありませんが、変更がある場合は破棄します古いものと新しいものをデプロイします。
しかし、結局のところ、まだ共通ストレージのルートを使いたいのであれば、EFSを使用することはお勧めしません。あなたはそれでセキュリティを得ることができません。代わりに、各サーバーでS3ファイルキャッシュを実行します。ファイルがS3で変更されるたびにローカルでファイルをプルするため、全員が変更を取得します。キャッシュの例は https://github.com/s3fs-Fuse/s3fs-Fuse/wiki/Fuse-Over-Amazon です。
動作中にWPファイルへの書き込みがあるかどうかをテストして確認します。書き込みがインスタンスに依存している場合は、それらのディレクトリをローカルとして保持する必要があります。サーバー上。