ソニーペイメントサービスの2つの決済モジュール

Welcart のデータ仕様の変更について

Welcart は初回リリースから11年が経ちました。長くご利用いただいていますユーザーの皆様から、データが増えてきてレスポンスが悪くなってきたというご意見を多数いただいております。そこで、遅ればせながらですが、データベースの仕様変更を計画しています。もっと早くから検討されてきた課題でありますが、この仕様変更はこれまで行ってきたカスタマイズに影響が出るものとなり、ユーザーの皆様にもリスクが発生することになるので、中々決断できていませんでした。リスクは伴いますが得るものが大きいという判断で今回仕様変更に踏み切ることになりました。ここでは、この仕様変更で得られるメリットとリスク、そしてカスタマイズへの影響と対策について説明させていただきたいと思います。

なぜ仕様変更が必要か

WordPress のデータ構造は、posts テーブルと postmeta テーブルに分かれており、posts は記事データそのものを格納しており、postmeta にはその記事に付随する情報を保存しています。Welcart の商品情報もこの仕様を使っていて、商品説明は posts 商品コードやその他のメタ情報は postmeta に保存しています。

一つの商品で保存されるメタデータは環境にも依りますが約30個ほどがあります。これはつまり、1万点の商品を登録した時、単純計算で postmeta のデータが30万行増えるということになります。さらに商品画像もデータベースに保存されるので、相当のデータ数になることが考えられます。 例えば、1商品につきSKUが2つ、商品画像が2つの構成で1万点の商品を登録した場合のデータ数は下記のようになることが推定されます。

メモ

1商品につきSKUが2つ、商品画像が2つの構成で1万点の商品の場合

  • posts テーブル 3万行以上
  • postmeta テーブル 40万行以上

実際には他のデータも入れてもっと多いと思われます。 特にカスタムフィールドを駆使しているサイトでは、この数字よりもはるかに多い数となります。

問題はこの膨れ上がる postmeta のデータで、これがデータベースに負荷をかけ、商品取得のレスポンスが低下する原因となります。これらバラバラに保存されているメタ情報を一つにまとめて、新たなデータテーブルを作ることで postmeta のデータ数を減らすことが必要です。

仕様変更で何が得られるか

特にレスポンスの改善が体感できるのは管理画面の商品リストになります。商品点数約4万点のサイトであれば、通常商品リストのレスポンスは8秒から10秒もかかりますが、このテスト検証では約10分の1にまで改善できることがわかりました。フロント側では管理画面ほどレスポンスが悪くはないのですが、PageSpeed Insights で「最初のサーバー応答時間を速くしてください」といったメッセージが出ている場合はこれを改善できる可能性は高いと思われます。

また、管理画面で商品CSVでの更新を行っていらっしゃる方にも、更新スピードの改善により十分な恩恵があると考えています。

リスクとその対策

データ移行処理失敗というリスク
アップグレード時にデータの移行処理が走ります。(Version2.7 予定)この移行処理では、大量データでもメモリーオーバーやタイムオーバーが起こらないよう十分に対策を考えていますが、環境によってはデータ移行に失敗する場合もあるかもしれません。移行処理を行う前に必ずバックアップを取って、元に戻せるようにしておく必要があります。 バックアップを取る一例を紹介いたします。

BackWPup でバックアップ

バックアップを簡単に行ってくれるプラグイン「BackWPup」を紹介します。
インストール有効化できましたら、メニュー「設定」の中に「BackWPup ダッシュボード」というメニューができますのでクリックします。 すると「データベースのバックアップをダウンロード」というボタンが見えますのでそれをクリックします。 データが多い場合は相当な時間がかかりますが、終わるまでそのままじっとお待ちください。
バックアップが完了したらアップグレード作業に入っても大丈夫です。  
 
残念なことに、このプラグインの無償版にはリストア機能が付いていません。簡単にリストアしたい場合は有償版が必要となります。


カスタマイズが動かなくなるというリスク
カスタマイズを行っているサイトでは、そのカスタマイズ手法によっては影響が出る可能性があります。V2.7 のデータ移行後は商品情報のメタデータが削除されます。適切な関数を使って商品情報を取得している場合はほとんど問題はありませんが、下記のようなデータの取得方法を行っていると正常にデータを取得できなくなります。

$item_name = get_post_meta( '_itemName', ture );
$item_code = get_post_meta( '_itemCode', ture );
この様な場合、次の関数を使って取得することになります。
この関数はVersion 2.6 から使えるようになります。
$product   = wel_get_product( $post_id );
$item_name = $product['itemName'];
$item_code = $product['itemCode'];
この関数によって取得できる情報についてはリファレンスにありますのでご参照ください。Welcart の商品情報ではないカスタムフィールドのデータは get_post_meta() を使っていて構いません。また「カスタム・アドバンスフィールド」プラグインを使用して登録しているデータの取得は、そのプラグインの指定関数を引き続き使うことになります。


リリーススケジュール

この様に大きな仕様変更となるため、準備期間を設けて事前に対策ができるよう段階を踏んでリリースしていきたいと思います。

  • Welcart 2.6(2022年4月4日リリース済)
    このバージョンではまだデータの移行処理は走りません。新しい関数を入っていますので、これらの関数を使ってカスタマイズの修正を次のv2.7 がリリースされるまでに行ってください。
    この V2.6 では、商品画像登録の新様式が採用されています。また、商品CSV のアップロード更新の改善が行われています。古い商品CSVは使えませんので、新たにダウンロードしてから編集を行うようにしてください。V2.6 のご案内はこちらもご参照ください。
  • Welcart 2.7(2022年7月下旬リリース済)
    このバージョンでいよいよデータの移行を行います。弊社でカスタマイズをご依頼のお客様は、ここから遡って1年以内の案件であれば、弊社にて修正対応させていただきます。ただ大変混みあうことが想定されますので、v2.6 がリリースされた時点でお問い合わせいただくと慌てなくても済むかと思います。
  • Welcart 2.8(2022年9月中旬リリース済)
    PHP8.0に対応します。
  • Welcart 2.9
    REST API フェーズ1
  • Welcart 3.0
    商品データの次に注文データ、会員データの最適化に入ります。商品同様まずは新しい関数を用意して移行準備期間を設けます。この間に影響のあるカスタマイズは対策を取っておく必要があります。
  • Welcart 3.1
    注文データと会員データの移行処理が走ります。これにてデータの移行アップデートは終了となります。


Welcart の今後

Welcartをご利用のショップもかなり成長してきており、管理側の改善が求められています。カスタマイズ対応で実装させていただいた機能も、一般的なショップ運用では必要な機能と判断されるものに関してはどんどん標準装備していこうと考えています。その一つとして他のサービスとの連携があります。どのサービスにでも汎用的に連携ができるよう連携APIの期待の声が高くなってきています。これができればスマホアプリでの運用という事も可能になってくるでしょう。このマイルストーンは既に開発計画に入っています。また、フロント側の改善にも力を入れていきたいと考えています。チェックアウト遷移をもっとシンプルに、わかりやすく使いやすいしていかなくてはいけないと思っています。 これからまだまだ進化していくWelcart を今後ともよろしくお願いいたします。