この記事でわかること
「最近、EC-CUBEの表示が遅い気がする」「セール時にアクセスが集中したら落ちないか不安」「BtoBで同時ログインが増えそうだ」——EC-CUBEを運用していると、こうした負荷やパフォーマンスの不安が出てくることがあります。この記事では、負荷が高まる要因と、インフラ・アプリケーション・データベース・キャッシュといった各層で確認したいポイント、そしてスケール設計の考え方を解説します。
この記事を読むと分かること
- EC-CUBEで負荷が高まる要因
- 負荷対策を「4つの層」で考える枠組み
- スケール設計・負荷テストの考え方
EC-CUBE4系全体の構造については、EC-CUBE4系のアーキテクチャ解説もあわせてご覧ください。
なぜEC-CUBEで負荷対策を考えるのか
ECサイトで負荷が高まる要因には、次のようなものがあります。
- アクセス集中（広告・セール・メディア露出など）
- 商品数・SKUの増加
- 受注件数の増加
- BtoBでの同時ログイン
- API連携の増加
表示の遅さやアクセス集中時の不安定さは、利用者の離脱や、機会損失につながることがあります。EC-CUBEは自由度の高いEC基盤であり、その分、負荷への対策も設計の一部として考える必要があります。
EC-CUBE4系の構造と、負荷対策の考え方
EC-CUBE4系はSymfonyをベースに構築されており、アプリケーション・データベース・キャッシュといった要素が分離された構成になっています。この構成のもとで、負荷対策は、次の4つの層に分けて考えると整理しやすくなります。
- インフラ層
- アプリケーション層
- データベース層
- キャッシュ層
どこか一つを対策すれば十分、というものではありません。ボトルネックがどの層にあるかは、サイトの状況によって異なります。以下、層ごとに確認したいポイントを見ていきます。
① インフラ層
サーバー構成には、大きく単一サーバー構成と、分散構成があります。
| 構成 | 概要 |
|---|---|
| 単一サーバー構成 | 1台のサーバーで運用する。構成がシンプルで、コストを抑えやすい |
| 分散構成 | Webサーバー・DBサーバーを分けたり、ロードバランサーで複数台に分散したりする。アクセス増加や可用性の要件に対応しやすい |
どちらが適しているかは、想定するアクセス量、可用性の要件（止まってはいけない度合い）、運用体制、予算によって変わります。分散構成が常に正解というわけではなく、規模や要件に見合った構成を選ぶことが大切です。AWSなどのクラウド環境では、状況に応じてサーバーを増減する構成も選択肢になります。
② アプリケーション層
アプリケーション層では、次のような点が、処理の重さに影響します。
- 使っていないプラグインが残っていないか
- 本体（コア）を直接改修していないか
- 重いクエリを発行している処理がないか
- カスタマイズの実装方式（イベント・DIなどの拡張方式か、コア直接改修か）
プラグインや独自カスタマイズの実装内容によっては、追加の処理やデータベースアクセスが発生し、負荷の要因になることがあります。特にBtoBサイトでは、顧客別価格の計算など、業務ロジックが処理の負荷に影響することがあります。カスタマイズの実装方式については、プラグイン設計で確認したい9つのポイントもご覧ください。
③ データベース層
データベースは、負荷の要因になりやすい層の一つです。次のような点を確認します。
- 検索・絞り込みに使うカラムのインデックス設計
- 不要なJOINや、重いクエリの見直し
- スロークエリ（時間のかかるクエリ）の解析
商品数や受注数が増えると、検索の速度に影響が出ることがあります。ただし、速度は商品数だけで決まるものではなく、SKU数、検索条件、JOIN、カスタマイズ、インデックス、インフラなど、複数の要因が関係します。実際のクエリの実行状況を確認したうえで、対策を検討することが大切です。データ構造の設計については、DB構造・Entity設計の解説もご覧ください。
④ キャッシュ層
キャッシュは、負荷対策で有効な手段の一つです。EC-CUBE4系では、SymfonyやDoctrineのキャッシュ機構が利用されています。サイトの構成や要件に応じて、Redisなどの外部キャッシュやCDNを組み合わせることも検討できます。次のようなものがあります。
- HTTPキャッシュ（ページ単位のキャッシュ）
- アプリケーションキャッシュ・Doctrineのキャッシュ
- Redisなどのインメモリキャッシュの利用
- CDNの活用（静的ファイルの配信）
商品一覧や、頻繁に変わらないページは、キャッシュの効果が出やすい部分です。一方で、ログイン状態や、顧客別価格が関わる部分は、キャッシュの扱いに注意が必要です。何をキャッシュし、何をキャッシュしないかを、サイトの要件に応じて設計することが大切です。
BtoBサイト特有の負荷要因
BtoBサイトでは、次のような処理が、負荷の要因になることがあります。
- 顧客別価格の計算
- 大量のSKUの表示
- 一括注文の処理
- 多数の同時ログイン
顧客別価格の判定で、追加のデータベース参照や計算が発生する実装では、負荷の要因になることがあります。BtoBサイトでは、こうした業務ロジックを、設計の段階から負荷の観点も含めて検討しておくことが役立ちます。BtoB固有の設計論点は、EC-CUBEでBtoBサイトを構築する際の注意点9選で整理しています。
API・基幹連携と負荷
リアルタイムの在庫更新や、基幹システムとの連携は、その頻度や方式によって、負荷の要因になることがあります。すべてをリアルタイムで連携するのか、一定間隔でまとめて連携するのかは、負荷の観点からも検討する部分です。連携の方式選定については、基幹・在庫システムを連携する方法で解説しています。
スケール設計の考え方
アクセスやデータが増えたときに、システムを拡張する方法には、大きく2つあります。
| 方法 | 概要 |
|---|---|
| 垂直スケール（スケールアップ） | サーバーの性能（CPU・メモリなど）を上げる。構成を変えずに対応しやすい |
| 水平スケール（スケールアウト） | サーバーの台数を増やす。ロードバランサーや冗長構成とあわせて設計する |
どちらが適しているかは、負荷の性質や、可用性の要件、予算によって変わります。まず垂直スケールで対応し、規模の拡大に応じて水平スケールを検討する、という進め方もあります。将来の拡大を見据える場合は、早い段階でスケールの方針を考えておくと、選択肢を広げやすくなります。
複数台のWebサーバーで構成する場合は、ロードバランサーを配置するだけでなく、セッションなど、サーバー間で共有が必要な状態の扱いも確認します。インフラ構成に応じて、セッションの保存先などを含めて設計する必要があります。
負荷テストの考え方
アクセス集中が想定される場合や、大規模な商品・受注処理がある場合は、負荷テストで、事前に挙動を確認しておくことが役立ちます。感覚ではなく、数値で確認できる点がメリットです。
- 同時アクセスのシミュレーション
- 注文処理の負荷確認
- ピーク時のトラフィックを想定した確認
すべてのサイトに大規模な負荷テストが必要というわけではありません。想定されるアクセスや、扱うデータの規模に応じて、どの程度の確認をするかを検討します。
SaaSとの違い
ShopifyなどのSaaS型のサービスでは、インフラの運用やスケールの多くを、サービス提供側が担います。一方、EC-CUBEは、採用するインフラや構成も含めて、自社（または開発会社）で設計する範囲が広いという特徴があります。自由度が高い分、負荷やスケールの設計も、自社側で考える必要があります。これは、EC-CUBEの短所ではなく、要件に合わせて構成を選べるという特徴の裏返しでもあります。
EC-CUBEの負荷・スケール設計を、ご相談ください。
「表示速度が気になる」「セールやメディア露出でのアクセス集中に備えたい」「BtoBで同時ログインが増えそう」といったご相談に対応しています。現在の構成や、想定される負荷を伺ったうえで、対策の方針をご提案します。
よくある質問
EC-CUBEは、アクセスが増えても大丈夫ですか？
構成と設計によります。EC-CUBEでは、採用するインフラ構成やアプリケーション、データベース、キャッシュの設計を要件に応じて見直すことで、アクセス増加への対応を検討できます。想定されるアクセス量に対して、サーバー構成やキャッシュ設計などが適しているかを確認することが重要です。自由度が高い分、負荷対策も設計の一部として考える必要があります。
表示速度を改善するには、何から見ればよいですか？
まず、どこがボトルネックになっているかを確認することをおすすめします。表示の遅さは、データベースのクエリ、キャッシュの設定、プラグインの処理、インフラなど、複数の要因が関係します。実際のクエリの実行状況や、ページの読み込み状況を確認したうえで、影響の大きい部分から対策を検討します。原因を特定せずに対策を進めると、効果が出にくいことがあります。
商品数が増えると、遅くなりますか？
商品数だけで速度が決まるわけではありません。SKU数、検索条件、JOIN、カスタマイズ、インデックス設計、キャッシュ、インフラなど、複数の要因が関係します。商品数が増える場合は、検索まわりのインデックス設計や、キャッシュの活用などを、実際のクエリの状況を見ながら検討することが役立ちます。
負荷テストは、必ず必要ですか？
すべてのサイトに必須というわけではありません。アクセス集中が想定される場合（大規模なセール、メディア露出など）や、大量の受注処理がある場合には、事前に負荷テストで挙動を確認しておくことが役立ちます。想定される負荷の規模に応じて、どの程度の確認をするかを検討します。
まとめ
EC-CUBEの負荷対策は、インフラ・アプリケーション・データベース・キャッシュという4つの層で考えると整理しやすくなります。大切なのは、どこか一つの対策で済ませようとせず、ボトルネックがどこにあるかを確認したうえで、サイトの規模や要件に見合った対策を選ぶことです。商品数や受注件数といった数字だけで判断するのではなく、実際の状況を踏まえて設計することが役立ちます。
私たちサンクユーは、EC-CUBEの構築だけでなく、表示速度の改善や、アクセス集中に備えた構成の設計、BtoBサイトの負荷対策に対応しています。現在のサイトの状況を確認したうえで、対策の方針をご提案します。負荷やパフォーマンスが気になる方は、お気軽にご相談ください。
投稿者プロフィール
- サンクユーのEC-CUBE担当。15年以上にわたりEC-CUBE開発に従事し、2系・3系・4系すべてに精通。難易度の高いカスタマイズや、他社構築サイトの改修・再設計も多数対応しています。
Javaでの業務システム開発を起点に、PHP・Perl・フロントエンド・CMSまで横断的に対応。基幹システム連携や業務フローを踏まえた設計を得意とし、複雑な要件にも柔軟に対応可能です。
ChatGPT CODEXを活用し、開発スピードと品質の両立を実現しています。
