アークウェブのブログ

2016年1月26日

Zen Cartで構築した予約システムの負荷対策(2)：インスタンスの変更によるパフォーマンス向上と費用対効果

投稿者 金田

• Tweet
• 

エンジニアの金田です。今回は前章に引き続き大量アクセスのある顧客の負荷対策例の続きを紹介します。

概要

前章 でのDBサーバーが高負荷でダウンする件については、SQL文の発行部分を最適化することによってDBサーバーへの負荷を減らすことに成功した。そのため当面の課題であったDBサーバーのダウンは発生しなくなった。
しかし、その分HTTPサーバー側のアプリケーションが多くのメモリーを必要とするようになってしまい、また、そもそものZen Cart自体のパフォーマンスの問題もあって、フロントの挙動が遅くなる事象が新たに発生した。ソースコードの書き換えによるこれ以上のパフォーマンス向上は難しいと判断し、AWSのインスタンスタイプを高性能化することにより解決した。以下にその経緯を述べる。

目的

サイトのHTTPフロントのレスポンスが悪いため、原因を追究しレスポンス速度の向上を図る

青線がWebフロント、オレンジがDBサーバーである。DBサーバーの負荷は減らすことに成功したがWebフロントの負荷が高くなっていることがうかがえる。

調査

今回もソースレビューを行ったが、特にボトルネックになる部分は発見できなかった。
この時点でカレンダー部分（前章で最も負荷が高いと計測された）の表示に、負荷分散の有無に関わらず約3.5秒掛かっている。PHPのメモリは128MB確保しており充分、I/Oは調査・改善済みなのでCPUの処理速度がネックになっている可能性が高い。
この場合、一番簡単で効果が期待できるのはインスタンスの変更である。なぜならこの時点で利用しているインスタンスはm1.smallであり、アクセスが殺到するサイトのインスタンスタイプにしては貧弱だと思われるからである。そこで、ひとまずインスタンスタイプをm1.smallからm1.mediumへアップグレードした場合の効果測定をすることにした。

• カレンダー画面へのアクセス
• small(現状)が秒間20アクセス（負荷）で平均14.2秒、mediumが同条件で平均6.2秒

• 注文ステップ（カレンダーの次の画面）
• 高負荷状態でsmall 39.9秒、medium18.1秒

• 低負荷状態でもカレンダーの表示はsmallとmediumで倍くらい差が出る

想定以上の効果があることが分かったので、他のインスタンスタイプも比較・検討することにしたが、m1.largeやc3.mediumなどはx86_64しか選択できず、現在のインスタンスとCPUアーキテクチャが違うため、まずはm1.small, m1.medium, c1.mediumの3つで比較検討することにした。
調査対象は利用中のm1.smallとm1.medium, c1.mediumである。調査にはJmeterを使用し、意図的に高負荷状態を創りだして効果測定したため、レスポンス速度は平常時の4倍程度遅くなっている。

 m1.small カレンダー    14.1937秒
 m1.small チェックイン  39.9463秒

 m1.medium カレンダー    6.2217秒
 m1.medium チェックイン 18.1285秒

 c1.medium カレンダー    3.0467秒
 c1.medium チェックイン  8.1833秒

結果は歴然であり、c1.mediumが圧倒的に早いことが判明した。
そこでインスタンスタイプを段階的にc1.mediumに切り替えたところ、早速効果が見られた。ここまでの対策でひとまず高負荷状態は回避できたので、次にx86_64アーキテクチャも含めた最適なインスタンスタイプの選定にとりかかった。

上の図では、ベンチマークの結果を統計し、Amazonが提示しているインスタンスの料金などと照らし合わせ、費用対効果を算出したものである。そのインスタンスを使った場合の月額料金比較もできるようにしている。
これを見ると、c3.largeの費用対効果の高さが突出している。費用としては月額が倍を少し超えてしまうが、パフォーマンスは6倍近く出ることが判明した。

結果

これまでの試験結果やコストの試算を顧客に提示し、相談ののちインスタンスタイプの変更を実施することにした。インスタンスタイプをm1.smallから段階的にc3.largeにインスタンスを変更したところ、本番サーバーでもCPU負荷が激減し、インスタンス変更の効果が高いことが実証された。

上の図ではオレンジがWebサーバー、緑がDBサーバーである。瞬間的にはWebフロントに10％程度の負荷は発生するが、ほとんどの時間帯でほぼ負荷のない状態で運用できるようになっていることが確認できる。繁忙日はあらかじめある程度予測可能なため、その日はインスタンス数を増やすなど対応を取った結果、高負荷状況は解消された。
CPUアーキテクチャを変えた影響か、バックエンドでNFSでのファイルアクセスに障害が出るなど多少のトラブルに見舞われたが最終的には解決した。
その後も顧客にヒアリングを続けるなどして実証を進めたが、アクセス集中による支障はほぼ解消されたことが確認された。

繁忙期はフロントWWWを5台体制にするなどスケール面でも対策をしたが、去年10月に入り繁忙期が収束したため現在は3台体制で特にトラブルもなく運用できている。

結論

今回の負荷対策により、プログラムのチューニングによる負荷軽減も当然重要であるが、案件規模に対するインスタンスの選定も重要であることが認識された。
またインスタンスの選定にあたり、単純に料金が高ければよいわけではなく、インスタンスタイプにより費用対効果が大きく異なることも判明した。特にm1.mediumとc3.largeは料金はそれほど変わらないのに性能差は3倍近く開いていた。このようにインスタンスタイプの選定もサーバー構築の重要な要素であることが再認識される形となった。
安易なインスタンスの高性能化は運用コストと売上のバランスを悪くすることもあるが、高負荷状況が続くことそれ自体もサイトの売上にも影響することであり、バランスの良いインスタンス構成を選定することは特に負荷の高いサイトにおいて重要な要素の１つであると考えられる。

カテゴリー: Zen Cart(オンラインショップ構築)

タグ： AWS , 負荷対策 , Zen Cart

« 前の記事：Zen Cart：WebPay（クレジットカード決済サービス）を利用した支払いモジュールを開発しました
» 次の記事：会員管理プラグインA-Member：ミニ機能アンケートのお願い