【ITニュース解説】You Don't Need Adobe Commerce Cloud to Survive Black Friday

Black Fridayのような大規模なオンラインセール期間中、多くのECサイトは膨大なアクセス集中によってシステムダウンの危機に直面する。この事態を乗り切るために、Adobe Commerce Cloud Proのような高額なプラットフォームが唯一の解決策だと考える企業も少なくない。しかし、このニュース記事は、Adobe Commerce Cloud Proがその堅牢性を実現している仕組みは、実は一般的なクラウド技術とアーキテクチャパターンに基づいていることを明確に解説している。

Adobe Commerce Cloud Proの生産環境は、ブランド名を取り除いてみれば、AWS（Amazon Web Services）上で構築されたマネージドサービスであることがわかる。その基本的な構成は、ロードバランサーの背後に配置された3台の仮想マシン（VM）であり、これらがAWSの3つの異なるアベイラビリティゾーン（地理的に離れた独立したデータセンター群）に分散されている。これが、万が一特定のデータセンターに障害が発生してもサービスが継続できるよう設計された「要塞」の正体だ。

この3台のVMは、単にメインサーバーと予備のサーバーという構成ではなく、「アクティブ-アクティブ」という方式で稼働する。これは、すべてのVMが同時にリクエストを処理し、データベースへの読み書きを受け入れる状態を指す。具体的には、Galeraクラスターという技術を採用したMariaDBデータベースが使われており、どのVMが停止しても、残りのVMがサービスを継続できるように設計されている。これは、伝統的なマスタースレーブ構成とは異なり、障害発生時の切り替え（フェイルオーバー）の必要がなく、高い可用性を提供する。

各VMには、ECサイトを運営するために必要な様々なソフトウェアコンポーネントがフルスタックで搭載されている。まず、顧客からのリクエストが最初に到達するのはFastlyというサービスで、これはCDN（コンテンツ配信ネットワーク）として機能し、Webページのキャッシュ、Webアプリケーションファイアウォール（WAF）によるセキュリティ、画像の最適化などをエッジ（ユーザーに近い場所）で行う。その背後には、WebサーバーであるNGINXとPHP-FPMが連携して動作し、ユーザーからのリクエストを処理する。データベースとしては先述のGalera / MariaDBが各VMに1インスタンスずつ配置され、顧客データや商品カタログなどの情報を管理する。セッション情報やカートの内容などを高速に扱うためのキャッシュとしてはRedis（新しいバージョンではValkey）が、商品検索機能のためにはElasticsearchまたはOpenSearchが使われる。さらに、サイトの画像ファイルや静的なアセットといった共有ファイルを3つのVM間で同期させるために、GlusterFSという共有ファイルシステムが利用されている。よく「6ノード」という話が聞かれるが、これは大規模なサイト向けの「Pro 48クラスター」以上の構成であり、デフォルトのPro環境は3ノードが標準である。

Black Fridayのようなアクセス急増にAdobe Commerce Cloud Proが耐えうる理由は、特定の魔法ではなく、以下の4つの確立されたアーキテクチャパターンに集約される。

1. エッジでのフルページキャッシュ: FastlyのようなCDNが、Webページ全体を世界中のエッジサーバーにキャッシュする。これにより、ほとんどのユーザーはキャッシュされたコンテンツを受け取り、実際のWebサーバーやデータベースへのアクセスが大幅に減るため、サーバーの負荷が劇的に軽減される。
2. アクティブ-アクティブデータベース: 3つのGaleraノードが同時に書き込みを受け入れるため、データベースの単一障害点がなくなる。これにより、高い可用性が保証され、購入手続きなどが途中で停止するリスクが低減される。
3. ステートレスなWebサーバー層: NGINXとPHP-FPMは、ユーザーのセッションやカートの状態をサーバー自身が保持しない「ステートレス」な設計になっている。これにより、トラフィックが増加した際に、Webサーバーのインスタンス数を容易に増やして負荷を分散できる（水平スケーリング）。
4. マルチAZによる耐障害性: 3つのアベイラビリティゾーンに分散配置することで、1つのデータセンター全体が機能不全に陥っても、他のゾーンのシステムが稼働し続ける。これはパフォーマンス向上というより、システムが「生き残る」ための非常に重要な機能である。

これらのアーキテクチャは、AWSのサービスを利用して自社で構築することも可能である。AWS自身もMagento（Adobe Commerceの基盤）をAWSに移行するためのリファレンスアーキテクチャを公開しており、その構成はAdobe Commerce Cloudとサービスレベルで類似している。

• CDN: Amazon CloudFront
• フルページキャッシュ: EC2インスタンス上のVarnishをAuto Scaling Groupで管理
• ロードバランシング: Application Load Balancer
• Web / PHP層: EC2インスタンスをAuto Scaling Groupで運用（ECSやEKSのようなコンテナサービスも選択肢にある）
• データベース: Amazon RDS for MySQLやAuroraのMulti-AZ構成。AdobeのGaleraのようにアクティブ-アクティブではないが、同期レプリケーションと自動フェイルオーバーによって高い可用性を実現する。
• キャッシュ: Amazon ElastiCache (Redisエンジン)
• 検索: Amazon OpenSearch Service
• メッセージキュー: Amazon MQ
• 共有メディア: Amazon S3またはAmazon EFS これらのコンポーネントは、Terraformのようなツールを使えば、数行のコードでデータベースのMulti-AZ設定やWebサーバーのAuto Scaling Group設定として記述し、自動でデプロイすることが可能だ。これはクラウドの世界では標準的な手法である。

では、Adobe Commerce Cloudを選択することと、自社で構築することの違いは何だろうか。Adobe Commerce Cloudを選ぶことで得られる最大のメリットは、「運用」の負担が軽減されることである。OSのパッチ適用、Galeraクラスターの管理、Fastlyとの連携、監視ツールの提供、ステージング環境の管理、そして何よりも、システム障害発生時にAdobeが責任を持って対応してくれるという安心感は大きい。Black Fridayのような正念場で、自社のエンジニアが夜中に呼び出される事態を避けたい企業にとっては、これは非常に合理的な選択となる。また、Fastlyの利用料、ミラーされたステージング環境、マネージドWAF、サポートSLAなど、様々な便利機能やサービスがパッケージとして提供される点もメリットだ。

一方で、自社で構築・運用する場合には、「制御」と「経済性」という大きなメリットがある。自社の要件に合わせてAWSリージョンを選択でき、サーバーにルートアクセスして自由に構成を変更できる。特定のコンポーネントだけを柔軟にスケールさせたり、Adobeのプランに縛られずにリソースを最適化したりすることも可能だ。そして、ある程度の規模を超えると、Adobeの高額なライセンス費用と比較して、AWSの純粋な利用料金は大幅に安価になる場合が多い。

結論として、Black Fridayのようなトラフィック急増に耐えうるECサイトのインフラ構築は、特別な秘密や独自技術を必要としない。それは、エッジキャッシュ、高可用性データベース、ステートレスなWebサーバー層、マルチAZによる冗長化といった、確立されたクラウドアーキテクチャパターンを組み合わせることで実現できる。Adobe Commerce Cloudは、これらの「自分たちで構築可能な」インフラを、運用管理の負担を軽減するサービスとして提供しているのだ。したがって、ECサイト運営企業が本当に問うべき問いは、「Adobe Commerce CloudなしでBlack Fridayを乗り切れるか」ではなく、「このインフラを自社で運用するか、それとも専門のベンダーに運用を任せるか」という選択である。もし自社のエンジニアチームがクラウドインフラの構築や運用、オンコール対応に慣れているならば、自社構築はより多くの制御とコスト削減をもたらす。逆に、エンジニアが新機能開発に集中し、インフラ運用をプロに任せたいのであれば、Adobeに運用を委託することも合理的な判断となる。重要なのは、Adobe Commerce Cloudが、決して自社では構築できないような「要塞」ではないことを理解しておくことだ。それは、一般的なクラウド技術で再現可能な、3つのVMがロードバランサーの背後にあり、3つのアベイラビリティゾーンに分散されたアーキテクチャなのである。