Fuel様は電設資材の販売するECサイトを運営されている。

旧Webサイトにはたくさんの問題点が存在する。

お話をお聞きすると、今までお使いだったサイトはスクラッチで構築されたそう。

スクラッチ構築する場合、細かいところまで思いのままで開発ができるためかゆいところまで手の届くシステムになっているはずだ。

しかし事情は少々違う。

管理画面が用意されておらず、TOPページの文言一つかえるにもPHPファイルレベルで更新をする必要がある。

構築時に様々な理由でそうなったと思われるが、更新などは自社内で行いたいとのことである。

また、古いサイトなのでレスポンシブに対応してなかったり、SSL化も対応していないため昨今ではSEO的なパフォーマンスも上がってきていなく、コンバージョンが下がってきている。

再度スクラッチで構築し直すことが最も良いのだが、大きな壁として立ちはだかったのは費用の問題だ。

削れるところはできる限り予算を削る工夫をしてほしいとご依頼を頂いた。

ECサイトを構築するには

・ASPを使う

・オープンソースをベースに追加開発する

・スクラッチで構築する

ことが一般的だ。

それぞれ一長一短である。

今回はオープンソースを選択して構築を考える。

オープンソースを選択する際、以下の点を考慮した。

・管理画面が日本語に対応していること

・SKUの点数

・コミュニティの成熟度

これらを鑑み、安定しているEC-Cubeを使うことを決定。

お客様からの要望で、ランニング費用を抑える形で構築する。

今回はAWSでの構築なのだが、構築を進めるに連れて問題点が出てきた。

構築を終え、お客さまのデータを流し込む。

お客様の当初のSKUは40,000点。これだけでもそこそこ多い。

しかし現在のt2.smallのスペックでこれぐらい処理できるだろうとたかをくくっていたのだが、利用に耐えられないほど遅い。

徐々にスペックを上げていく。しかし全ておそすぎる。

EC2,RDSともにt3.2xlargeほどにスペックを上げても改善しない。

これはH/Wレベルの問題ではないということである。

EC-Cubeのデータ処理のチューニングを行う必要が出てきた。

EC-Cubeの動作を見た場合、検索などでそのカテゴリに属している商品をDBから取得してフィルターを掛けているようだった。

これでは数万の点数を処理するには非常に非効率である。

これらにおいてカスタマイズを行った。

その結果劇的なパフォーマンス改善が行われ、 t2.smallスペック程度でも問題なく処理が可能となった。

今後は更に点数を増やすそうだ。

流石に50万点以上の処理をt2.smallスペックで行う訳にはいかないが、おそらくかなりのコストパフォーマンスが出ると考えている。