この記事は 2024.3.8 に最新記事として更新されています。
マレントを開発した経緯にもありますように、当初マレントでも
CtoCサービスの開発をWordPressやEC-CUBEをベースに進行していました。
しかし、開発が進むにつれてリプレイスしなければならない要件が多すぎて、もう一から作ったほうが早いという決断に至りました。
マッチングサイトをWordPressやEC-CUBEではなぜつくってはいけないのか？
WordPressやEC-CUBEで作れないということはないとおもいます。
しかし、これらで構築を粘り強く進行して完成したとしても下記の点で運用時に懸念がでてくる事項をまとめました。
①脆弱性（WordPress）
昔からですが、WordPressは手軽にしかもソースコードが開示されているものですので
そのセキュリティホールなどの脆弱性を突かれてしまう可能性がありました。
そのため、ワードプレス側では世界からの報告をもとに改修を進めてアップデートを通知する仕組みになっています。
しかし、このアップデートの頻度が年々多く
その度にカスタマイズを入れているサイトではシステムがフックしないかを見なければなりません。
この作業はエンジニアがいない企業では保守をどこかのシステム会社に依頼しなければならず、ランニングコストが結局発生してしまうということになります。
結局のところ割高になってしまったというケースです。
また、アップデート自動更新などを止めるということも意図的に可能ですが
この場合は脆弱性の観点から非常に危険であるということになります。
WordPressだけでなく、すべてのシステムにいえますが
一般的に普及しているCMSを使う場合は、上記の懸念点が一番にあげられると思われます。
②ボトルネック（EC-CUBE）
まずEC-CUBEでは構造上リプレイスしなければならない部分が多すぎました。
もちろんEC-CUBEはECサイトとして 運営 VS コンシューマー（消費者）（BtoC）の形式では最高峰のCMSかとおもいます。
しかし、これらを無理やり コンシューマー（消費者） VS コンシューマー（消費者）（CtoC）の形式にした場合はシステムとしてはいまひとつなところが多くなりました。
2010年ほどにEC-CUBEを無理やり改修したモール型パッケージが販売されていましたが
こちらもデモサイトで非常に使い勝手が悪く、実用的ではありませんでした。
リプレイス要件に合わせてボトルネックも原因となります。
システムとして円滑に運営するには計測などを検証する必要性もありました。
通信による遅延の影響をなくすためサーバ上での動作確認と別のサイトからの動作確認をしました。
（エックスサーバー：朝6時ごろとEC-CUBEでの実証を3回に分けて行いました）
検証方法
以下のページを生成し、応答時間を機械的に測定しました。
・静的HTML
・起動するだけのPHPプログラム
・データを送信するPHPプログラム
また、既存ページについては以下のページの応答時間を測定しました。
・トップページ（認証あり、なし）
・一覧ページ（認証あり）
・詳細ページ（認証あり、なし）
結果
トップページ 2049ms
一覧ページ 1528ms
詳細ページ 1458ms
HTTPサーバの応答 4ms
PHPプログラムの起動 1ms
EC-CUBEプログラムコア部分 300ms 程
EC-CUBE個別ページ部分 1200-1700ms 程
その内データベースへのクエリ 900-1400ms
測定するタイミングにより、
さらに時間がかかる場合がありますがデータベースの処理が時間かかるケースがみられるのでおそらくデータベース周りが原因でした。
またプログラムの中で時間がかかっている箇所を分析すると１ページの表示の内、
8-10箇所が特に処理に時間がかかっており、処理時間の85％を占めており、下記の項目での改修が必要でした。
・データベースのクエリ
・エックスサーバー性能
・セッション処理
・その他ファイル操作等
これらをもとに
項目別でボトルネックの切り分けが必須になります。
第一段階チューニング
・データベースのインデックスの調整等
・EC-CUBEのクエリキャッシュの実装
第二段階チューニング
・特に負荷の高いクエリについては、クエリの組み方そのものを調整
・極端に頻度の高いクエリに対しては、キャッシュの動作を確認し、調整
このように確認事項だけでも山のようにあり
この結果一から作った方が良いという結論に至りました。
③頻繁なアップデート（WordPress）
これは、アップデートに関していうとWordPressの場合4ヶ月など数ヶ月に1回のペースでアップデート更新が本家サイトからあります。
これはかなり年間でいうと多い回数になります。
また、WordPressで作っている以上は、アップデートのたびにデザイン崩れやセキュリティ部分の見直しをしなければならないことが多く、
WordPressではある程度のテストサービスレベルまでは作れますが、本格的なサービス運営には向かないという結論に至っています。
まとめ
マレントでは、この上記の観点からこれらをクリアしたCMSパッケージからのサービスローンチを推奨しております。
マレントの存在意義は、ワードプレスやEC-CUBEと高額なパッケージとの中間地点にあるからこそ、汎用性の効きやすい使い勝手のよいパッケージとして認識していただいております。
独自CMS（マレント製品）をこちらからぜひご覧ください。
