CS-Cart - HTTP 500 エラー対策 | SBWorks社員ブログ!

1. 本記事について

CS-Cart のレスポンス（サイト応答）が極端に劣化し、HTTP 500 エラーが発生するケースがあったため、確認すべき箇所と、その対処方法を記事にします。

本記事は CS-Cart 導入済みの方向けのため、
CS-Cart についての説明は割愛致します。
詳しくは公式サイトをご確認ください。

公式サイト
開発者ドキュメント

2. 環境情報

– OS/ソフトウェア
EC2（Amazon Linux 2, SSD, 64 ビット, t3.large）
RDS（MySQL 8.0.17, マルチAZ, db.r3.large）

CS-Cart マーケットプレイス版（4.9.2_JP_1）
PHP（7.2.30）
PHP-fpm（7.2.30）
Apache（2.4.39）

– AWS環境（ロードバランサ + EC2 + RDS のシンプル構成です）

3. 問題発生時のリソース状況

以下は CloudWatch ダッシュボードで表示したメトリクスです。
※ 表示されている値は 5 分間隔の平均値です。

問題が発生した 19:00 前後の状況を確認すると、

①EC2
　1. CPUUtilization（CPU 使用率）は特に問題なし
　2. CpuWait（CPU 待ち時間）が上がっている

②ApplicationELB（ロードバランサ）
　1. TargetResponseTime（ユーザへリクエストが返却されるまでの時間）が上がっている
　2. NewConnectionCount（新規接続数）は遅延が発生した時間帯以外と比較する限り問題なし

③RDS
　1. DatabaseConnections（DBコネクション数）が上がっている
　2. CPUUtilization（CPU 使用率）は特に問題なし
　3. ReadLatency（SelectSQLの待ち時間）が上がっている

上記のため、

・WEB サーバが忙しい訳ではない。
・DB コネクション数が上がっている時間帯に処理待ちが多く発生し、レスポンスタイムが遅くなっている。

という状況でした。

4. 原因

RDS の Performance Insights を確認したところ、問題が発生した時間帯で「Table_locks_waited（テーブルロックによる処理待ち）」が多数発生していました。

「Table_locks_waited MySQL」で調べると、テーブルのストレージエンジンが「MyISAM（マイアイサム）」の場合はテーブルロック方式という記述が、、

CS-Cart テーブルのストレージエンジンを確認したら「lock_keys」テーブルを除き、全て「MyISAM(マイアイサム)」でした。

※ 詳しい内容は後述致します。

テーブルのストレージエンジンを確認するためのSQLは以下です。

select TABLE_NAME, ENGINE from information_schema.TABLES where TABLE_SCHEMA like '%cscart%';

テーブルロックの原因となっているストレージエンジンの変更を検討したいですが、CS-Cart が MyISAM 以外に対応していない可能性があるため、「CS-Cart MyISAM」で調べたところ、
CS-Cart は InnoDB（イノディービー）にも対応しているので問題ない。という情報と、
CS-Cart 開発者が高速化の方法について説明している記事の中で InnoDB への変換を推奨している情報が見つかりました。

MySQLストレージエンジン
How to speed up CS-Cart. Server details

これで裏付けが取れましたので、以降の対処を行いました。

5. 対処内容

それぞれ以下の作業を行いました。

①RDS
　CS-Cart テーブルのストレージエンジンを「MyISAM(マイアイサム)」から「InnoDB(イノディービー)」へ変更

②EC2
　OPcache と APCu を導入
　※ こちらはテーブルロックへの対処ではないですが、高速化の観点で CS-Cart 開発者から推奨されているため、実施しました。

①RDS

CS-Cart テーブルのストレージエンジンを「MyISAM(マイアイサム)」から「InnoDB(イノディービー)」へ変更

MyISAM はテーブルロックの方式なので、参照クエリや更新クエリが多くなるにつれ、処理待ちが発生します。

共有ロック（READロック)	他のプロセスは読み込みはできるが、書き込みができなくなる
排他ロック (WRITEロック)	他のプロセスは読み込みも書き込みもできない

本件の問題が発生した際はテーブルロックが多く発生しておりましたので、
処理待ちが発生した結果、ユーザへ HTTP 500 エラーが返却されてしまいました。

この問題を解消するため、テーブルエンジンを InnoDB へ変更します。

InnoDB を採用した理由は行ロック方式であることと、
CS-Cart は InnoDB でも適切に動作する旨、公式サイトに明記されているためです。
MySQL のテーブルエンジンは MyISAM や InnoDB の他にもありますが、特殊なユースケースで使用するタイプのため検討しておりません。
気になる方は公式サイトの「第16章代替ストレージエンジン」リンクを辿ってください。

公式サイト
第16章代替ストレージエンジン

MyISAM から InnoDB への変更は、

ALTER TABLE cscart_addon_descriptions ENGINE=InnoDB;

このように「ALTER TABLE」SQL で行います。
ひとつひとつ SQL を書くのが大変なので、以下のように一括で作成します。

select
  concat('ALTER TABLE ', TABLE_NAME, ' ENGINE=InnoDB;') as 'sql'
from
  information_schema.tables
where
  table_schema like '%cscart%'
  and
  engine = 'MyISAM';

CS-Cart の全テーブルを MyISAM から InnoDB へ変更したら RDS への対処は完了です。

②EC2

OPcache と APCu を導入

PHP はインタプリタ言語のため、呼び出される度にプログラムの解析/解釈が行われ、オーバーヘッドがあります。
今回はクライアントへのレスポンス速度を改善する必要があるため、PHP の速度改善に寄与する「OPcache」と「APCu」をインストールします。

— 解説
OPcache を導入すると、コンピュータが解析済みの「バイトコード」をキャッシュして再利用してくれるため、処理が高速になります。
APCu は PHP が動的に作成したデータをキャッシュしてくれるので、ページの表示速度が改善されます。

本環境の PHP は「remi」リポジトリでインストールされているため、
インストールコマンドは以下になります。

$ sudo yum install --enablerepo=remi,remi-php72 php-opcache php-pecl-apcu

※ OPcache が php-opcache です。
※ APCu が php-pecl-apcu です。

インストールが終わりましたら、Apache を再起動しましょう。

$ sudo systemctl restart httpd

以下の表示となれば完了です。

OPcache（with Zend OPcache … の記述が追加されます）

$ php -v

PHP 7.2.30 (cli) (built: May  5 2020 18:04:45) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.30, Copyright (c) 1999-2018, by Zend Technologies

APCu（apcu が表示されます）

$ php -i | grep apc
 /etc/php.d/40-apcu.ini,
 apcu
 MMAP File Mask => /tmp/apc.XXXXXX
 apc.coredump_unmap => Off => Off
 apc.enable_cli => Off => Off
 apc.enabled => On => On
 apc.entries_hint => 4096 => 4096
 apc.gc_ttl => 3600 => 3600
 apc.mmap_file_mask => /tmp/apc.XXXXXX => /tmp/apc.XXXXXX
 apc.preload_path => no value => no value
 apc.serializer => php => php
 apc.shm_segments => 1 => 1
 apc.shm_size => 32M => 32M
 apc.slam_defense => On => On
 apc.smart => 0 => 0
 apc.ttl => 0 => 0
 apc.use_request_time => On => On
 apc.writable => /tmp => /tmp

本来、性能問題を解決するにあたっては、1つ1つ対応を試し、原因箇所の特定をし、対策をし、効果を確認するのが鉄則ですが、本記事では「それぞれどの程度効果があったのか」についての測定結果がありません。
急を要したため、テーブルのストレージエンジン変更とPHPのキャッシュ化を同時に行い解決を優先しました。

6. 対処後のリソース状況

※ 表示されている値は 5 分間隔の平均値です。

対応前後の状況を比較すると、

– ApplicationELB（ロードバランサ）
　1. TargetResponseTime（ユーザへリクエストが返却されるまでの時間）
　　 6.87　→　0.8
　2. NewConnectionCount（新規接続数）
　　 6.87　→　395

レスポンスタイムが改善されていることが確認できます。

本記事は以上です。
問題が発生した際に CS-Cart についての情報をインターネットで検索したのですが、なかなか欲しい情報が見つからず苦労したため、掲載致しました。
解決への一助となりましたら幸いです。

CS-Cart – HTTP 500 エラー対策

目次