はじめに
弊社では、MagentoのサーバをAmazon Web Service(以後、AWS)のEC2で構築することが多いです。そこでAWS環境でMagentoがどの程度の性能なのかを測りたいと思います。これまでもMagentoを導入して商品一覧や商品詳細ページの表示の性能の測定を行いました。今回はそのときの課題でも挙げた、注文の処理の性能を測定してみました。
小規模ECサイトを構築するという想定で Magentoを1台のサーバにオールインワンでインストールして、性能を計測を行いたいと思います。
また参考に、１ヶ月常時サーバを稼働させるといくらになるのかについても再掲します。
測定するサーバのスペック
今回比較に用いたサーバのスペックは下記の様になります。
■Amazon Web Service
-
EC2のサーバのスペック
EC2では、世界の複数箇所にデータセンター（リージョン）があり、各リージョンで通信遅延などや利用出来るインスタンスの種類、料金が違います。 今回は以前に測定したm1のインスタンス1種類とm3のインスタンス2種類について測定してみました。
リージョン：東京
ストレージ： Amazon EBS スタンダードボリュームサーバのタイプ スペック EC2: m1.small vCPU 1 ECU 1 メモリ 1.7GB EC2: m3.medium vCPU 1 ECU 3 メモリ 3.75GB EC2: m3.large vCPU 2 ECU 6.5 メモリ 7.5GB ※vCPUとは：インスタンスの仮想 CPUの数
※ECUとは：Amazon EC2 コンピュートユニット。Amazon 独自の計算能力を示す指標。大きいほど性能が高い。
-
料金の考え方
EC2ではインスタンスを立ち上げている時間に対して従量課金になります。サーバのタイプ 費用 EC2: m1.small $0.061/1時間(2013年3月まで $0.08 /1 時間) EC2: m3.medium $0.101/1時間(2013年3月まで $0.171/1 時間) EC2: m3.large $0.203/1時間(2013年3月まで $0.342/1 時間) また、インスタンスを予約する費用を払うと、従量課金の金額を下げることができます。予約には１年予約と3年予約があります。
サーバのタイプ 1年予約費用(重度使用リザーブドインスタンス) 1年予約の場合の従量課金の費用 EC2: m1.small $135(2013年3月まで $194) $0.017/1時間(2013年3月まで $0.025 /1 時間) EC2: m3.medium $244(2013年3月まで $365) $0.03/1時間(2013年3月まで $0.046/1 時間) EC2: m3.large $487(2013年3月まで $730) $0.061/1時間(2013年3月まで $0.092/1 時間) サーバのタイプ 3年予約費用(重度使用リザーブドインスタンス) 3年予約の場合の従量課金の費用 EC2: m1.small $207(2013年3月まで $297) $0.014/1時間(2013年3月まで $0.02/1 時間) EC2: m3.medium $375(2013年3月まで $563) $0.025/1時間(2013年3月まで $0.037/1 時間) EC2: m3.large $750(2013年3月まで $1125) $0.05(2013年3月まで $0.075/1 時間) ※EBSではストレージの容量を確保している間、別途料金が発生します。（$0.085 : 1 か月にプロビジョニングされたストレージ 1 GB あたり）
またI/Oリクエストにも課金されます。（$0.085 /100 万 I/O リクエスト）※インターネットへのデータ転送送信（アウト）について別途料金が発生します。(最初の 1 GB/月 $0.000/GB、10 TB まで/月 $0.201/GB)
計測内容
今回は店舗側ですでに会員登録を終えているユーザが注文をする想定で、単位時間あたりの注文の処理件数を計測しました。
測定方法
測定時の詳細な条件は下記となります。
- 店舗：単位時間あたりの注文の処理件数
今回は、負荷測定ツールであるApache Jmeterを利用して、注文の処理速度を計測しました。以前に計測した商品一覧や商品詳細ページの表示の性能測定では、1回の表示処理あたりPHPリクエスト1回でしたが、注文の場合、商品をカートに追加して、注文を確定するまでの一連のPHPリクエストを順番に実行していく必要があります。注文の処理の流れは下記の様になります。
- 商品詳細ページの表示
- カートへの商品追加
- カートページの表示
- ワンページチェックアウトの表示
- ログイン
- 購入者住所の入力
- 配送先住所の入力
- 配送方法のの入力
- 決済方法のの入力
- 注文の確認の表示
- 注文確定
- 注文成功ページの表示
- ログアウト
- ログアウト成功の表示
今回の計測では、これ以外にも細かい処理を呼び出しているために、1注文あたり17回のPHPのリクエストを呼んでいます。 この一連の流れの処理を順番に呼び出して、注文を完了させるまでを注文処理1件として同時接続数を変えて、処理時間を計測しました。 同時接続の各購入者は10回つづけて購入を行い全体にかかった時間で、注文処理件数を割ることで処理速度[注文件数/分]を求めます。
測定結果
下記が単位時間当たりの注文の処理速度です。単位時間が分であることに注意してください。注文の処理速度[注文件数/分]
| サーバ | 同時接続数 | ||||||
|---|---|---|---|---|---|---|---|
| 1 | 2 | 5 | 10 | ||||
| EC2 m1.small | 1.42 | 1.44 | 1.44 | 1.48 | |||
| EC2 m3.medium | 2.09 | 2.31 | 2.41 | 2.41 | |||
| EC2 m3.large | 3.95 | 5.10 | 5.91 | 5.92 | |||
サーバの月額費用のシミュレーション
| サーバ | 月額費用[円] | m1.smallを基準とした料金の比率 |
|---|---|---|
| EC2 m1.small | 2378(4465) | 1 |
| EC2 m3.medium | 4235(7385) | 1.8 |
| EC2 m3.large | 8523(14831) | 3.6 |
※20GBストレージを1ヶ月間利用した場合の想定。
※I/Oリクエスト費用、ネットワークのデータ転送送信（アウト）の費用は含めない。
※価格は重度使用リザーブドインスタンスの１年予約の場合の1年の費用を12ヶ月で割った価格で、括弧内の価格は、リザーブドインスタンスを利用しない場合の価格。
※$1-100円のレートで費用を計算。
考察
店舗の注文の処理速度の比較
注文の処理速度をグラフで見てみると、
EC2 m3.large > EC2 m3.medium > EC2 m1.samll
の順で性能が高いといえます。
m3.mediumはm1.smallに比べて約1.4〜1.6倍の件数の処理ができました。m3.largeはm1.smallに対して約2.7〜4倍の件数の処理ができました。
サーバの種類の違いとしては、同時接続数を増やした場合には、サーバのスペックが高い方が単位時間当たりに処理できる注文件数が伸びていることがわかります。
今回の中でもっともスペックの低いm1.smallでは同時接続数を変化させてもほとんど変化がありませんでした。測定中サーバの負荷を調べたところロードアベレージが1以上の高い値を示していたので、同時接続数が1の時点でCPUの処理能力が飽和しているため増やしても件数に変化が無かったと考えられます。
m3.mediumやm3.largeの場合も、同時接続数を増やしていくとある時点でサーバの負荷が上がり、処理できる件数が向上しなくなります。例えば、m3.largeで同時接続数が１から5の間では処理速度が向上しているのに5から10の間では向上していません。
店舗の注文処理性能と料金の関係
月額料金のシミュレーションでは月額料金はm3.mediumがm1.smallの約1.8倍、m3.largeが約3.6倍となっていて、単位時間当たりに注文を処理できる件数の能力とほぼ比例していることがわかりました。
サーバの種類を選択する場合には、ピーク時に単位時間あたりにどれくらの注文を処理できなければならないのかを考えてサーバのスペックを選択する必要がありますが、この情報が参考になれば幸いです。
今後の課題
- より同時接続数を増やしたときに、処理しきれずサーバタイムアウト等が発生するか、発生する場合はどの時点で発生するかについて調べたいと思います。
- 他のクラウドサービスについても同様に測定を行っていきたいと思います。