はじめに：AWS環境におけるMagento複数台構成の課題とは

Magento（Adobe Commerce）は非常に強力なECプラットフォームですが、そのアーキテクチャはデフォルトで単一サーバー（シングルインスタンス）向けに構成されています。トラフィックの増加に伴い、AWSのApplication Load Balancer（ALB）などを利用してEC2インスタンスを複数台にスケールアウトする場合、最大の壁となるのが「ステート（状態）の不整合」です。

ユーザーのセッション情報、アップロードされたメディアファイル、キャッシュ、そしてバックグラウンドで動くCronジョブなど、各インスタンスがローカルに保持してしまうデータをいかに切り離し（ステートレス化）、中央集権的に管理するかが、スケーラブルなMagentoインフラ構築の鍵となります。本記事では、AWS環境でMagentoを複数台構成にする際のクリティカルな注意点とベストプラクティスを解説します。

1. メディアファイルの共有と配信（Amazon S3の活用）

ローカルストレージ依存からの脱却

複数台構成において最初に直面するのが、メディアファイル（商品画像やWYSIWYGでアップロードした画像）の不整合です。EC2-Aにルーティングされた管理者が画像をアップロードした場合、その画像はEC2-Aのローカル（pub/media/）にのみ保存されます。その後、エンドユーザーのアクセスがEC2-Bにルーティングされると、画像が存在しないためリンク切れ（404エラー）が発生します。

Amazon EFSをマウントしてpub/media/を共有するアプローチもありますが、Magentoは大量の小さなファイルを頻繁に読み書きするため、EFSではI/Oレイテンシがボトルネックになりパフォーマンスが低下するリスクがあります。

Amazon S3へのオフロードとCDN連携

最適な解決策は、メディアファイルをAmazon S3にオフロードすることです。Magento 2.4以降では、標準でリモートストレージ（AWS S3）への連携機能が提供されています。

env.phpの設定とbin/magento setup:config:set --remote-storage-driver="aws-s3"コマンドを使用して、S3バケットを直接メディアストレージとして指定します。さらに、エンドユーザーへの配信にはAmazon CloudFront（CDN）をS3の前段に配置することで、EC2の負荷を劇的に下げつつ、高速な画像配信を実現できます。

2. セッションとキャッシュの一元管理（Redis / Varnish）

Redisを利用したセッション管理

ALB配下でリクエストが複数のEC2に分散される環境では、セッションをローカルのファイルシステムに保存していると、リクエストを跨ぐたびにユーザーが強制ログアウトされるといった問題が生じます。

これを防ぐため、AWS ElastiCache for Redisを導入し、セッション情報を一元管理します。Magentoのenv.php内のsessionノードをRedisに向けることで、どのインスタンスにアクセスしても同一のログイン状態を維持できるようになります。

フルページキャッシュ（FPC）とバックエンドキャッシュ

Magentoのパフォーマンスを最大限に引き出すためには、キャッシュ戦略が不可欠です。

  • Varnish（FPC）: フロントエンドの高速化には、Varnish Cacheが推奨されます。各EC2インスタンス内にVarnishを同居させるか、Varnish専用のレイヤー（またはAWS CloudFrontの高度なキャッシュ設定）を構築し、動的コンテンツ以外のレスポンスを劇的に高速化します。
  • Redis（バックエンドキャッシュ）: 設定データやレイアウト情報のキャッシュも、ファイルベースではなくRedis（セッション用とは別のデータベース番号や別クラスター）に保存します。これにより、全インスタンスが常に最新のキャッシュ状態を参照し、キャッシュクリア時の不整合を防ぐことができます。

3. データベースのスケーリング戦略（Amazon Aurora / RDS）

スタンバイ構成とリードレプリカの活用

Magentoは、商品カタログの閲覧（Read）が多い一方で、チェックアウトやインデックス処理など、書き込み（Write）も非常に多いシステムです。単一のRDSではI/Oが枯渇する可能性があるため、高可用性とスケーラビリティを兼ね備えたAmazon Aurora MySQLの利用を強く推奨します。

Master-Slave構成（マルチAZ）を基本とし、トラフィック増大時にはリードレプリカをプロビジョニングして読み取り負荷を分散させます。

MagentoのDBコネクション分離設定

Magentoには、データベースの読み書きを分離する機能や、env.phpにてMaster/Slaveのエンドポイントを個別に設定する機能が備わっています。

リードレプリカのエンドポイントをRead用のDB接続として設定することで、カタログ閲覧等の重いクエリをMasterからオフロードし、チェックアウト時のトランザクション性能を担保できます。

4. Cronの二重実行防止（クリティカルな注意点）

複数台構成でCronが重複するリスク

インフラ構築時、最も見落としがちで致命的なトラブルを引き起こすのが「Cronの重複実行」です。MagentoのCronは、インデックス再構築、価格ルールの適用、注文メールの送信、決済ゲートウェイとの同期など、ECサイトの心臓部を担っています。

もしALB配下のすべてのEC2インスタンスでcron:runが同時に実行されると、データベースのデッドロック、同一ユーザーへの注文完了メールの複数回送信、さらには不完全なインデックスによるサイトダウンを引き起こします。

単一ジョブサーバーへの分離戦略

これを防ぐためのベストプラクティスは、「Cron（バッチ）専用のサーバーを1台のみ用意する」ことです。

Webトラフィックを受け付けるAuto Scalingグループ（フロントエンド用EC2）からはCronの設定を完全に削除し、管理画面へのアクセスとCronジョブの実行のみを担当する独立したEC2インスタンス（Admin/Cronノード）を1台固定で稼働させます。これにより、安全かつ確実にバックグラウンド処理を実行できます。

5. Auto Scaling導入と運用面の留意点

デプロイメントとステートレス化の徹底

Auto Scalingを導入する場合、EC2インスタンスは「いつでも破棄・再作成可能な状態（ステートレス）」でなければなりません。これを実現するためには、ソースコードのデプロイを稼働中のサーバーに直接行うのではなく、CI/CDパイプライン（AWS CodePipelineなど）を用いて、事前に最新のMagentoコードとコンパイル済みアセットを含んだ「Golden AMI」を作成するイミュータブルインフラの構築が必要です。

ログの中央集権化（CloudWatch Logs）

インスタンスが動的に増減する環境では、ローカルのvar/log/に保存されたエラーログはインスタンス破棄と共に消失します。Amazon CloudWatch Logsエージェント（またはFluent Bit等）を全インスタンスに導入し、system.logやexception.log、PHP-FPMのログなどをリアルタイムでAWS側に転送・集約する仕組みを必ず構築してください。

まとめ：堅牢でスケーラブルなMagentoインフラの実現

AWSでMagentoを複数台構成にするプロセスは、単なるサーバーの追加ではなく「アプリケーションのステートレス化」というアーキテクチャの変革を意味します。

S3によるメディア共有、Redisによるセッション/キャッシュ管理、AuroraによるDBスケーリング、そして何より「Cronの単一実行」を徹底することで、大規模なトラフィックやセール時のスパイクにも耐えうる、堅牢でエンタープライズレベルのECインフラを実現できます。