クラウドサーバーのベンチマーク：クラウドコンピューティング・インサイダーガイド

多くの新規のお客様は、CloudSigmaの利用を開始する際にパフォーマンスをテストしたいと考えます。クラウドサーバーと自社のインフラストラクチャの間でパフォーマンス結果をベンチマークしようとすることが多く、それは理にかなっています。リソースごとの単純な価格比較だけでは、全体像をまったく把握できません。本当に重要なのは最終的な結果であり、特定のコンピューティングタスクを達成するためにどれだけのコストがかかるかということです。

どのような要件であっても、それを達成するために必要なリソースの数はクラウド間で大きく異なる場合があります。これは、価格だけを比較しても意味がないことを意味します。裏を返せば、パフォーマンスだけを単独で比較しても決して良くはありません。有意義な比較を行うには、価格とパフォーマンスの両方を組み合わせて、コンピューティングユニットあたりのコストの尺度を計算する必要があります。この投稿では、当社のクラウドサーバーや他社のクラウドサーバーをベンチマークした結果から得た私の考えをいくつか共有します。また、有用な結果を得るためのヒントと、それが実際に何を意味するのかについても説明します。

注意事項

前もって説明しておくと、私は一般的にベンチマークに対してかなり懐疑的です。ベンチマークが実際の使用状況を真に洞察できることはめったにありません。要するに、プラットフォーム上で使用する予定の実際のアプリケーションを実行することに勝るものはありません。時間的に妥当なコストでこれを達成できるのであれば、そのような取り組みに代わるものはありません。

もう一つの要因は、クラウドベンダーの混雑状況です。クラウドサーバーをベンチマークして優れた結果が得られることがあります。しかし、これは主にその特定のベンダーの使用レベル（または使用されていないこと）によるものである可能性があります。それは必ずしも好ましい兆候とは言えません。運用の難しさ、顧客の減少、過去の可用性や信頼性の問題などを反映している可能性があります。したがって、ベンチマーク結果を解釈する際には、過去の障害やその他の潜在的な問題について、常にそのクラウドベンダーを調査する必要があります。

最後の注意事項として、考慮すべき要因はパフォーマンスだけではありません。多くの場合、パフォーマンスの低さは、その基盤となるより堅牢な（そして冗長な）ハードウェアアーキテクチャを反映している可能性があります。したがって、クラウドがどのようなインフラストラクチャ上に構築されているかを非常に明確に理解しておくことが常に重要です。これにより、結果を公平に比較し、有意義な購入決定を下すことができます。

課題の定義

この投稿の後半では、パフォーマンスのさまざまな側面と、結果を解釈する最善の方法について説明します。ただし、ベンチマークを行う前に、クラウドで行おうとしているコンピューティングの種類を特徴付けることが重要です。これにより、さまざまなパフォーマンス指標の相対的な重要性が決まります。たとえば、データベースサーバーを配置しようとしており、読み取りアクセスは頻繁に行われるが書き込みアクセスは少ない場合、クラウドにおけるディスクパフォーマンス、特に非シーケンシャル読み取りアクセスに注意を払う必要があります。

したがって、クラウドサーバーのベンチマークを開始する前に、クラウドからの優れたパフォーマンスとは何かを実際に明文化してください。どの側面が重要であり、コンピューティングの実際のパフォーマンスに不釣り合いなほど大きな影響を与えるかを判断する必要があります。これについて明確なアイデアが得られたら、ベンチマークの検討を開始できる段階になります。

コンピューティングパフォーマンス

生のコンピューティングパフォーマンスを見る場合、それはCPUとRAMのことを指します。純粋なコンピューティングレベルでのクラウド間のパフォーマンスの違いは、実際にはそれほど大きくありません。しかし、実際の違いを生み出している要因がいくつかあります。

クラウドにおけるコンピューティングパフォーマンスに影響を与える最大の要因は、圧倒的にリソースの競合（コンテンション）です。パブリッククラウドはマルチテナント環境です。RAMとストレージは実際にはオーバーアロケート（過剰割り当て）できませんが（オーバーセリングは可能ですが）、CPUは可能であり、実際にそうなっています。競合のレベルは大きく異なりますが、本質的にパブリッククラウドベンダーは、物理ホストのCPU容量を100%を超えて販売することができます。

最大手ベンダーの一部は、3倍以上のCPU競合比率を使用しています。これは、同一の物理マシン上にあるすべての仮想サーバーの‘販売済み’CPU総容量が、実際のCPU容量の3倍に達する可能性があることを意味します。彼らがこれを行うのは、ほとんどの仮想サーバーがほとんどの時間、割り当てられたCPUの100%近くを利用していないためです。それでも、競合比率はクラウドサーバーのパフォーマンスベンチマークや実際の使用状況に直接影響します。競合が高くなると（つまり、CPU割り当てが200%を超える場合）、クラウドサーバーのパフォーマンスは著しく低下します。

簡単に言えば、物理マシンの負荷が1コアあたり1を超えると、計算タスクがキューに送られ、その仮想マシンがジョブを完了するまでに時間がかかるようになります。ほとんどのクラウドが容量/時間単位で課金していることを考えると、これはそのクラウドの顧客にとって直接的なコスト影響を及ぼします。

計算パフォーマンスに影響を与えるもう一つの重要な要因は、仮想マシンがアクセスできるCPUコアの数です。これはすべてのアプリケーションに当てはまるわけではありませんが、多くの最新アプリケーションはマルチスレッドをサポートしています。事実上、これはアプリケーションやオペレーティングシステムが計算タスクを複数のコアに分散できることを意味します。コンピューティングのパフォーマンスを向上させるための優れたヒントの1つは、アプリケーションがサポートできるスレッド数（つまりコア数）を、仮想マシンがアクセスできるコア数に一致させることです。

残念ながら、多くのパブリッククラウドではこれは不可能です。これは、彼らの仮想化プラットフォームがCPUコアレベルでの仮想化をサポートしていないためです。言い換えれば、各コアは一度に1つの仮想マシンからしか使用できません。CPUコアの仮想化をサポートしているクラウドでは、総CPUサイズを同じに保ちながら、そのマシンのコア数を変えて実験してみる必要があります。

例えば、2GHzのマシンをお持ちの場合、使用するコア数を2つから4つに倍増させることで、ベンチマークにどのような影響があるかを確認できます。これにより、その仮想マシン上で実行されているアプリケーションは、4つのコアを介して同時にタスクを実行できるようになります。当社のサービスでは、Webコンソールのサーバー詳細モーダルにある‘詳細’タブから、仮想マシンが使用するコア数を設定できます。使用するコア数を手動で上書きする前に、クラウドベンダーの標準コアサイズが何であるかを常に確認することを忘れないでください。当社の場合は1コアあたり2.2GHzですが、これはクラウドによって異なります。

クラウドサーバーのパフォーマンスをベンチマークするために、POV-RAY, CoreMark, Dhrystone または Whetstone の使用を検討することをお勧めします。

ストレージ：真のクラウドサーバーパフォーマンスベンチマーク

すべてのパフォーマンスは、ボトルネックが発生する最も弱いリンクによって制限されます。現在、CPUとRAMの使用に関しては、仮想化の分野で技術が大幅に進歩しています。例えば、単一の物理マシンを仮想化し、全体の累積パフォーマンスへの損失を最小限に抑えながら、複数のクラウドサーバーを持たせることができます。残念ながら、ストレージに関しては、まだ多くの進歩の余地があります。最終的な結果として、ほとんどの場合、クラウド内の仮想サーバーのパフォーマンスは、そのクラウドのストレージソリューションのパフォーマンスによって決定されます。

要するに、ストレージは現在、クラウドにおけるほとんどの計算タスクのパフォーマンスを制限する要因となっています。純粋な計算タスクに対してpov-rayやその他のベンチマークがどのような結果を出そうとも、現実は、仮想サーバーが物理ストレージディスクからデータを取得し、そこにデータを書き込む速度が、現在のクラウドサーバーの実際のパフォーマンスを決定するということです。

それを念頭に置くと、クラウドにおけるパフォーマンスの真の違いは、計算タスクに関することであっても、ストレージのパフォーマンスの違いに起因する傾向があります。この投稿で前述したように、計算タスクに応じて顧客のニーズは大きく異なります。これはストレージに関して最も顕著に当てはまります。大規模なシーケンシャルデータ（ストリーミングメディアなど）への高速な読み取りアクセスが必要ですか、それとも（大規模なデータベースなどにあるような）小さな分散した情報へのアクセスが必要ですか？定期的に大きなバーストでアクセスされる、変化の激しいデータに対して、大量の書き込みアクセスを維持する必要がありますか？数多くのシナリオが存在し、同じプラットフォーム上であってもそれぞれ異なるパフォーマンスを示します。

根本的に、パフォーマンスの違いはアーキテクチャに帰着します。これらのアーキテクチャの違いは、通常、データの保存に関する堅牢性の度合い、その冗長性、したがって実際にデータが修復不可能な形で失われる可能性の違いから生じます。大まかに言えば、クラウドは、次の形式の集中型データソリューションを採用するか、Storage Area Network (SAN)または、より分散されたローカルストレージソリューションを採用しています。後者では、ストレージは個々の物理マシン上に配置されます。

優れたSANは、本質的に高いレベルの冗長性が組み込まれています。しかし、計算タスクのためにデータをSANからネットワーク経由で仮想マシンのCPUやRAMに送信する必要があるため、パフォーマンスが低下します。その結果、SANベースのクラウドは、ローカル分散ストレージソリューションを備えたクラウドと比較して、同等の条件でパフォーマンスが低くなる傾向があります。SANのもう一つのデメリットは、非常に大きな単一障害点（SPOF）となることです。SANは極めて信頼性が高いものです。万が一重大な障害が発生した場合（実際に発生したことがあります）、大規模な停止やデータの破損に直面する可能性が高くなります。

SANを使用しているほとんどのクラウドベンダーは、主にコスト上の理由から、エンタープライズ環境で使用されているような完全冗長化されたフェイルオーバーソリューションを採用していません。すべてのSANが同じではないことを認識し、クラウドベンダーがSANでどの程度の冗長性を採用しているかを理解することが重要です。

ローカルストレージベースのクラウドは、ディスクパフォーマンスが優れている傾向があります。しかし、多くの場合、非永続的な形式のローカルストレージしか提供していません。これは永続ストレージとの公平な比較ではありません。一時的なストレージは、永続的なストレージと同じように障害に対して堅牢である必要はありません。意味のある結果を得るためには、常に永続ストレージと永続ストレージを比較することが重要です。

分散ローカルストレージソリューションを備えたクラウドを検討する際は、どのような冗長性を備えているかを知る必要もあります。ハードディスクドライブはかなりの割合で故障するため、ストレージの方法は極めて重要です。ほとんどのベンダーは、何らかの形式のRAIDを使用していますが、安全性のレベルは大きく異なります。ローエンドでは、2台のディスクが実質的に相互にミラーリングするRAID1があります。これは通常、優れたパフォーマンスを発揮します。しかし、1台のディスクが故障した場合、交換用ディスクが古いディスクからすべてのデータをコピーし終えるまでの間に、2台目の（負荷の高い）ディスクが故障すると、データが完全に失われるリスクがあります。また、RAID1アレイの再構築中は、ディスクパフォーマンスが通常よりも大幅に低下する可能性があります。

そのため、多くのベンダーはRAID5（1台のディスク故障に対応）またはRAID6（2台のディスク故障に対応）を使用しています。RAID6はローカルストレージにとって群を抜いて最も安全なソリューションを提供しますが、パフォーマンスに大きなペナルティを伴います。当社のアプローチは、RAID6を使用しつつ、これを最上位クラスのハードウェアRAIDコントローラカードと組み合わせることです。これらは大容量のメモリキャッシュを搭載し、バッテリーバックアップされています。当社が使用しているRAIDコントローラカードは、実際にはディスクアレイ全体よりも大幅に高価です。これにより、RAID6ストレージという非常に大きな安全ネットを提供しながらも、堅牢性の低い構成と同等のパフォーマンスを実現できます。当社のcloud infrastructureのセットアップについて詳しくお読みください。当社はこれについて非常にオープンに公開しています。

ディスクパフォーマンスのベンチマークには、IOzoneやBonnie++の使用をお勧めします。

したがって、ストレージのベンチマーク結果を解釈する際には、以下の情報も必ず確認するようにしてください：

• クラウドはどのようなストレージアーキテクチャ（ローカル、SAN、その他）を使用しているか？
• データに対してどのようなフェイルオーバーおよび冗長化対策が講じられているか？
• ベンチマークを行っているストレージは、一時的なものか、それとも永続的なものか？

これら3つの質問に対する回答とベンチマーク結果を組み合わせることで、実際のストレージパフォーマンスについてかなり優れた洞察を得ることができます。

ネットワーキング

ネットワーキングのパフォーマンスは、計算処理やディスクのパフォーマンスよりも、はるかに簡単かつ明確に測定・判断できます。ネットワーキングのパフォーマンスには、レイテンシ（遅延）と帯域幅（バンド幅）という2つの重要な側面があります。

ニーズに応じて、クラウドベンダーが使用するネットワークのレイテンシが重要である場合と、そうでない場合があります。主に自己完結型の処理にクラウドを使用している場合、レイテンシが優先事項になる可能性は低いです。しかし、クラウドの外部の世界と相互作用するリアルタイムアプリケーションを実行している場合、レイテンシは極めて重要なパフォーマンス決定要因になります。

通常、レイテンシの大部分は純粋な物理的距離に起因します。例えば、ロンドンとサンフランシスコの間のレイテンシのほとんどは、実際には光がその距離を移動するのにかかる時間です。レイテンシの差は、選択されたルートの効率性の違いによって決まります。これこそが、クラウドごとに異なる側面です。ルートの効率性は、クラウドが直接接続しているネットワークプロバイダーに直接起因します。これは、プロバイダーからIP接続を取得するか、ピアリングを行うことによって実現されます。レイテンシを確認する際は、クラウドサーバーに単純にpingを送信してそのパフォーマンスを測定できます。しかし、実際のエンドユーザーとクラウドサーバーの間のパフォーマンスを測定することが重要です。

ユーザーの大部分が特定の地域に拠点を置いている場合、またはアクセスが主に会社の本社から行われる場合は、それらの場所からパフォーマンスをテストすることが重要です。例えば、Pingdom などの商用サービスは、世界中の多数の一般的な場所から同時にレイテンシを測定するための費用対効果の高い方法を提供します。

クラウドサーバーが達成できる実際の 帯域幅 も非常に重要です。従来のホスティングソリューションとは異なり、クラウドベンダーはデータ転送の総量に応じて課金する傾向があります。言い換えれば、24時間365日固定の接続レベルを提供するMbitあたりのような時間依存ではありません。それにもかかわらず、多くのクラウドベンダーは仮想サーバーへの帯域幅を‘制限（スロットル）’します。これは、その制限に達するまでユーザーには見えません。帯域幅の変動が激しい（スパイクが多い）プロファイルをお持ちの場合、これは考慮すべき重要なパフォーマンス要因となる可能性があります。

クラウドサーバーの実際の帯域幅をテストするには、送信元での転送速度制限を行っていないソースからクラウドサーバーにデータをダウンロードしてみることが重要です。利用可能な速度を判断する優れた方法として、私はよく以下のような大手ベンダーから大容量ファイルをダウンロードします。例えば、Microsoft, Ubuntu、あるいはさらに良い方法として、オペレーティングシステムにパッチを適用することです。これにより、さまざまな場所から多くの異なるファイルが同時にダウンロードされる傾向があります。これにより、接続速度をかなり正確に把握することができます。

私は標準的なテストとして、よくメインサイトから Fedora live CD をダウンロードしますが、最低限、常にいくつかの異なるファイルや場所で試してみるべきです。独自の非常に高速な社内ネットワークをお持ちの場合は、代わりにテストとしてクラウドサーバーから自社ネットワークにファイルをダウンロードするとよいでしょう。

料金を加味して結果を再評価する

上記の方法を使用することで、さまざまなクラウドサーバーベンダーのパフォーマンスを十分に把握できるはずです。さらに、特定のニーズにとって最も重要な、どの側面に焦点を当てるべきかも理解できるでしょう。

最後のステップは、ベンチマーク結果に価格の側面を加えることです。これに対する決まった公式はありません。これは上記のさまざまな側面の相対的なパフォーマンスに依存し、それを決定するのはあなた自身です。もしあるクラウドが（あなたの判断で）40%優れたパフォーマンスを提供している一方で、価格が30%しか高くないのであれば、明らかに魅力的に見えます。同様に、帯域幅の需要が大きい場合、計算パフォーマンスが低くても、競争力のあるデータ転送料金プランによってその欠点が補われる可能性があります。正しい意思決定を行うための鍵は、これらすべてのさまざまな要因を考慮に入れることです。

最後に、ベンチマークは、どのクラウドサーバーが自分に適しているかを判断する、より大きなプロセスの一部であるべきです。これには他の側面も含まれるべきです。例えば、サービスレベル契約（SLA）、データやベンダーのロックインに関する考慮事項、物理的な場所、および法的な管轄権などが含まれます。これらすべての側面をまとめることで、クラウドコンピューティングベンダーの正しい選択ができるようになります。