Cloudn \ 技術ブログ tech blog

クラウド・エヌの活用方法についてご紹介していきます。
Cloudn Information

前の記事・次の記事

Cloudnの性能を徹底検証!!(前編)

ブログ記事

こんにちは。Cloudnで開発を担当している今村です。

Cloudnの開発チームでは、NTT OSSセンタの協力のもと、実際に仮想サーバーにWEBシステムを構築し、処理できたリクエスト数を測定いたしました。今回は、その結果をお伝えします!

(※)本検証結果はあくまで参考値であり、性能を保証するものではありません。

1. 性能測定規格 TPC-W

性能測定の実施において、公正な試験を行うために重要な観点のひとつが「基準」です。基準に従うには、前回ご紹介したUnixBenchなどのツールを用いる、あるいは何らかの検証規格に準拠するなどの方法が考えられます。
Cloudnの性能を測定するにあたり、今回はTPC-W規格に沿った検証を行いました。”TPC”とは”Transaction Processing Performance Council”の略称で、実際のシステムに近い性能測定規格を立案するために設立された団体です。なかでもTPC-Wは、eコマース(電子商取引)のシステムの性能評価を想定した規格になります。

試験には、eコマース用途を想定したWEBシステムをサーバーに配置します。配置するWEBシステムについては、その内容によって性能測定結果が変わらないよう、厳密に仕様が策定されており、TPC-W規格の仕様書は200ページ近くにも及びます(参考:TPC-W Specification)。

こちらが配置するWEBシステムの画面の一例です。

832_spec_4

内容としては、購入したい書籍をショッピングカートに入れて買い物をするような、一般的なECサイトになります。当然、アカウント情報や注文履歴、商品の管理等を行う必要がありますので、WEBサーバー、APサーバー、DBサーバー、いわゆるWEB3層モデルのシステム構築が求められます。

性能検証は、ここで構築したシステムに対し大量のアカウント(今回は24,000名まで)から40分間アクセスがあったというシナリオで行われます。アカウントが行う操作は、書籍の情報を閲覧する処理など参照系の操作(SQL)が7割、書籍を購入するといった更新系の操作(SQL)が3割と規定されています。また、実際のECサイト利用者の動線を模倣するため、あるアカウントが次の操作に移るまで、思考遅延の時間として7秒間待機するよう定められています。

2. 性能指標値 WIPS

WIPSとは、TPC-W規格における性能指標値で、”Web Interaction Per Second”の略称です。これは、WEBシステムにアクセスしているすべてのアカウントが、1秒間に正常に遷移できた画面の総数を表します。「正常に遷移できた」場合なので、400番台や500番台などのHTTPレスポンスが帰ってきた場合は、画面数に含めません。
具体例を考えてみましょう。例えば、1000名のアカウントがWEBシステムにアクセスし、20秒間に1アカウントあたり2回正常に画面遷移できたと仮定します。この場合、総画面遷移数は 1000(名) × 2(回) = 2000(回)になります。これを20秒で割ると 2000(回) ÷ 20(秒) = 100となり、測定結果は100(WIPS)となります。

ややこしいと感じられるかもしれませんが、要するにWIPSとは「1秒に正常に遷移できた画面の数」と考えていただければ十分かと思います。このWIPSが高いほど、スループット性能が良いWEBシステムといえますので、より多くのアクセスを処理できたことになります。

3. 環境構成

こちらが実際に性能検証を行った環境構成になります。

832_spec_1性能検証はすべて東日本FLATリージョンで実施いたしました。

WEB/APサーバにはCloudn Computeを用い、DBサーバにはCloudn RDBを利用しています。また大量のアクセスを複数の仮想サーバーに振り分けるため、Cloudn LBAを利用しています。

この環境でWEB/APサーバーの台数やスペックを変化させ、どの程度の性能が発揮できるか調査いたしました。また、DBサーバーについても、スペックを変化させた場合、またはMulti-AZ(※)を有効・無効にした場合で、どのように性能が変化するか検証いたしました。

その他、OSやミドルウェアなどの具体的なパラメータは、NTT OSSセンタが提示するOSSVERTモデルに準拠して検証しています。

(※)Multi-AZ:DBサーバーが故障したときに、拠点をまたいで用意しておいたホットスタンバイ状態の別のDBサーバーへ自動的に切り替える機能です。ホットスタンバイですので、拠点間で常にデータを同期しています。

4.検証結果

前置きが長くなりましたが、検証結果を見ていきましょう!

まずは、Cloudn RDBのMulti-AZ機能を使わない場合の結果からお届けします。

832_spec_2

1vCPUは1.6GHzに相当します。最も小規模な構成であるNo.1の例でも、1秒間に平均で966.57件のリクエストを正常に処理できていることが分かります。また、サーバープラン(スペック)や台数を変動させると、WIPSも同時に向上していることが分かります。

次に、Cloudn RDBのMulti-AZ機能を利用し、フェイルオーバー可能な冗長構成を採用した場合の結果です。Web/APサーバープランにPlan vQ(※)を採用し、コストミニマムな形の構成もあわせて検証しました。

(※)Plan vQの場合、1vCPUは0.4GHz相当になります。

832_spec_3

Multi-AZを有効にした場合、データが更新される際に、ホットスタンバイしている別のDBサーバーと拠点間でデータを同期する必要があるため、無効にした場合と比較して性能差が生じます。

このように冗長構成を採用した場合でも、最大で1秒間に1531.14リクエストが正常処理できていることが分かります。

5.最後に

今回性能検証を行うにあたり採用した規格TPC-Wは、一般的な書籍のECサイトを想定しておりますので、処理できたリクエスト数は参考値としてご利用いただけますが、仮想サーバーに対してどのようにWEBシステムを構築するかによって、処理できるリクエスト数は大きく変動することをご理解ください。

Cloudn利用者の皆様が、システム構成を考える際の一助となれば幸いです。

次回の記事では、性能検証(後編)をお届けします。CPU、ディスク、メモリ性能など、単体のリソースに着目した性能検証結果をお届けする予定です。どうぞ、お楽しみに!

※本記事の内容は、Cloudnの活用方法の一例を示したものであり、お客様の環境・構成において動作することをお約束するものではありません。 従いまして、本記事の内容によって生じたトラブルや損害についても、弊社では責任を負いかねますのでご了承ください。
また、本記事の内容に関してのサポートは行っておりませんので、予めご了承ください。

ブログフッダ

投稿日:

カテゴリ:

前の記事・次の記事

サイドニュー

カテゴリー

最近の記事

バックナンバー