5つのクラウドプラットフォームを計測し比較する

作者 Abel Avram , 翻訳者 徳武 聡 投稿日 2010年8月8日

セクション

運用/インフラ,

設計/アーキテクチャ

トピック

クラウドコンピューティング ,

マネジメント ,

パフォーマンス&スケーラビリティ

タグ

Amazon Webサービス

原文(投稿日：2010/07/23)へのリンク

BitcurrentとWebmetricsは5つの異なったクラウドプラットフォーム上でいくつかのテストを実施した。対象となったのは、Amazon、Google、Rackspace、Salesforce.com、そしてTerremarkだ。実施したのはこれらのプラットフォームの性能を計測するためのテストだ。このテストの結果のひとつから言えるのは、アプリケーションのタイプによって各プラットフォームの性能は違うということだ。

このテストの報告書の作者たちは性能テストするのために4つの種類のテストを選んだ。そして5つのクラウド上で5つのネイティブアプリケーションを実行してベンチマークをとった。

テスト

1. 小さなオブジェクトをリクエストする – 1x1ピクセルのGIF
2. 多くなオブジェクトをリクエストする – 2MBのイメージ
3. CPU負荷の高いタスクを実行する – 1,000,000回の正弦計算と合計計算を実施。Salesforce.comではプラットフォームの制限があるので、100,000回の処理を実施。
4. IO負荷の高い処理を実行する – Amazon、Rackspace、Terremarkに対してはキャッシュをクリアした状態でMySQLに対して500,000行の問い合わせを実施。Salesforce.comではデータストアに対して、GoogleではBigTableに対して実施。

ネイティブアプリケーション

ネイティブアプリケーションのベンチマークをとるために、各クラウド向けに開発された5つの実在のウェブサイトを選んだ。Salesforce.com上のApexで作られたウェブサイト、GAE上のJavaとPythonで作られたウェブサイト、AmazonとRackspaceのXenサーバ上で動いているLinuxサーバのウェブサイト、そしてTerremarkのVMwareのVM上で動いているウェブサイト。これら5つのサイトでテストを行ったが、名前は公表されていない。

テスト結果を計測するためにWebMetricsのサービスを利用して、一ヶ月間、世界中の様々な場所から不定期的にリクエストを送り続けた。

Salesforce.com とGAEはPaaSサービスを提供している。一方での残りの3つ、
Amazon、RackspaceとTerremarkはIaaSサービスを提供している。

結果

5つのプラットフォームで4つのテストを行った場合の遅延は下記の通りだ。

小さなオブジェクトを取得するテストでは、どのプラットフォームでも高性能で動作する。一方で大きなオブジェクトの場合は、IaaSプラットフォームよりPaaSプラットフォームの方が高性能だ。他のプラットフォームで行った操作の10%のテストしか行っていないにも関わらず、CPU負荷に対するSalesforce.comの性能は悪い。GoogleとRackspaceはIOのテストでは最も優れていた。

ネイティブアプリケーション実行のテスト結果は下記の通りだ。

ふたつのPaaSプラットフォームの動作が優れている。その次はAmazonとRackspaceだ。レスポンスに12秒かかっているパーセントが大きいTerremarkは最下位になった。

結論

このテスト報告書の作者たちはこれらのテストから得られた教訓をいくつか要約している。

• 隣人を観察すること 同じクラウド上の複数のアプリケーションが同時に遅くなるはっきりとした証拠を見つけました。同じクラウド上の他のアプリケーションに影響を受けているのは間違いありません。
• 利用するクラウドのデータを理解すること 上記の棒グラフはそれぞれのクラウドに得意な仕事があるということを示しています。したがって、優れた性能を提供するにはCPUやメモリなどを考慮しながら、バーチャルマシンのサイズを調整する必要があります。
• 内部にエージェントを送り込んでおくこと 監視を計画するとき、問題の優先順を素早く決めるためにバックエンドの機能を実行するカスタムコードを導入しておく必要があります。
• 意図する作業にを考慮してPaaSを使うかIaaSを使うか決めること Bigtableのような“ビックデータ”システムの仕組みを利用するために、既存のアプリケーションを再コーディングするつもりであれば、PaaSクラウドの方がスケールしやすいでしょう。一方で個別のマシンが必要であれば、IaaSの構成機能を使って柔軟性を構築したほうがいいでしょう。
• ビックデータには副作用がある 巨大な共有データストアは素晴らしいかもしれませんが、そこにデータを保存するには時間がかかります(Googleの場合は37時間も!)。アプリケーションの使い方によってはこの時間は適切ではないかもしれません。
• 使い方と速度制御機構を監視すること PaaSで速度制限を超えている場合は、ユーザがエラーになっているでしょう。
• トラブルシューティングは難しくなる 問題の優先順を適切に決めるためには、インターネット全体の情報が必要ですし、利用しているクラウド全体の情報や個々のアプリケーションのそれぞれの層についての情報が必要です。クラウドではなく専用の環境でアプリケーションを実行している場合はこのようなサードパーティの問題(共有帯域の競合やI/Oのブロッキングなど)を見積もるために多くの時間を割く必要はありませんでした。
• PaaSの場合は皆同じバスケットに入っている PaaSを使っている場合、クラウドが遅くなればすべてのアプリケーションが遅くなることがわかりました。IaaSの場合、CPUやサーバの応答性についてはPasSに比べて分離されていますが、共有ストレージや共有帯域は競合します。

完全な報告書にはこのベンチマークテストで収集した詳細な情報が記載されている。

注: 報告書の作者たちはこのテスト結果をガイドラインとしてだけ利用するよう助言している。テスト結果は実際のテスト作業やコード、準備や実際の配置環境など多岐にわたる要因に依存しているからだ。また、この研究は他のクラウドプラットフォームを差し置いて特定のクラウドプラットフォームを推奨する目的で行われたのではない。

• 次へ >