IDCFクラウドの性能を、ベンチマークツールを使って簡易に検証。パフォーマンスの特徴や料金面での比較なども行っています。検証時のChefレシピも公開します。
前回はIDCFクラウドについて、ざっと機能的な特徴を紹介しました。今回はベンチマークツールを使って、性能や特性を検証していきます。ぜひ、利用時の参考としてください。なお、数値や価格は本稿執筆時点(2014年11月)でのものです。クラウドサービスは価格などが変動しますので、ご利用の際には本稿を参考にご自身でも追検証されることをお勧めします。
IDCFクラウドの仮想マシンを起動して、ディスクのI/Oとゾーン内転送速度を計測してみます。対象には月額利用料が特に抑えられている「light.S1」を選びました。今回は同価格帯との比較のため、Amazon EC2の「t2.micro」インスタンスおよび周辺サービスの結果と料金目安を併記します。なお、参考料金にはインスタンスそのものの使用量は含んでいません。
まず、ディスクI/Oの性能を見ていきましょう。ここでは、vdbench*を使用し、次の条件でブロックデバイスに対してベンチマークを行いました。
ファイルシステム測定で使用したvdbenchの設定は次の通りです。
fsd=fsd1,anchor=/bench,depth=1,width=1,files=1000,size=128k fwd=default,xfersize=4k,fileio=random,fileselect=random,threads=8, stopafter=100 fwd=fwd1,fsd=fsd1,operation=read fwd=fwd2,fsd=fsd1,operation=write rd=rd1,fwd=fwd*,fwdrate=max,format=yes,elapsed=300,interval=60
ベンチマーク結果は次の表の通りとなりました。
VM | ボリュームサイズ/プラン | IOPS 1回目 | IOPS 2回目 | IOPS 3回目 | 平均レスポンスタイム | ボリューム月額参考料金(税別) |
---|---|---|---|---|---|---|
ICDF light.S1 | 15GB ルートディスク | 81,068 | 80,003 | 75,826 | 0.03s | 300円 |
EC2 t2.micro | 15GB EBSボリューム gp2 | 77,932 | 76,003 | 81,010 | 0.01s以下 | 約200円 |
ブロックデバイス測定で使用したvdbenchの設定は次の通りです。
sd=sd1,lun=/dev/{デバイス名},openflags=o_direct wd=wd1,sd=sd*,seekpct=random,rdpct=50,xfersize=8192 rd=rd1,wd=wd*,elapsed=300,interval=60,iorate=max
ブロックデバイスへのベンチマークは事前に数回実施し、結果が安定するようになってからの計測を開始しました。
結果は次の表の通りとなりました*。
VM | ボリュームサイズ/プラン | IOPS 1回目 | IOPS 2回目 | IOPS 3回目 | 平均レスポンスタイム | ボリューム月額参考料金(税別) |
---|---|---|---|---|---|---|
ICDF light.S1 | 200GB データディスク (High I/O) | 1999.13 | 2066.13 | 2166.05 | 3.854ms | 4000円 |
EC2 t2.micro | 200GB EBSボリューム gp2(制限時は上限IOPS600※) | 3059.69 | 3059.79 | 3059.73 | 2.613ms | 約2400円 |
EC2 t2.micro | 200GB EBSボリューム io1 (3000) | 3059.73 | 3059.72 | 3059.78 | 2.613ms | 約2万8000円 |
* EC2のgp2ボリュームはIOPSが高い状態が1時間程度続くと、1GB当たり3IOPSの容量に応じた制限がかかります。
IDCFクラウドのディスクは価格の割に高性能で制限もありませんが、EBSと比較するとレスポンスタイムにばらつきが多く、限界近くで高負荷を続けるとスパイクが発生しました。
通常の利用では問題になる範囲ではない印象ですが、アプリケーションの要求が非常にシビアなケースではハードウェア専有タイプ(記事作成時は未提供)という選択肢も用意されるため、そちらを検討することになるかもしれません。
なお、今回使用したvdbenchをリモートサーバーにインストールするChefのCookbookをGitHub上で公開しています。
本稿のベンチマーク結果について、IDCフロンティアの技術担当の方から、いくつかコメントをいただきました。ここでは、それらの情報を紹介しておきましょう。
IDCFクラウドで使用しているバックエンドのストレージは、ボリュームのアクセス頻度に応じてブロックをSSDへ再配置するそうです。
再配置は午前2時に実行されるとのことでしたので、技術担当の方に一言伝えた上で、ベンチマークをかけっぱなしにしてみました。実際のIOPS推移が下のグラフです。条件は本文中で実施したものと同じ、対象は200Gバイトの追加ディスクです。
グラフからは午前2時を境に、じわじわとIOPSが向上していく様子が見て取れます。午前4時を過ぎたころには平均的に3000IOPSを上回っています。この段階で、Amazon EBSのgp2より高い性能が得られています。
このベンチマーク結果から(過信は禁物ですが)、バックエンドを含めた性能面に十分余裕があることがうかがえます。
コントロールパネルからディスクを追加し、マウントした直後にベンチマークを実施すると、しばらく200IOPS程度のスコアが続きます。
これはボリュームの確保にシンプロビジョニングを用いており、サイズの拡張を行いながらベンチマークを処理していることが理由だということです。
容量を多く使い、高いIOPSが求められるデータベースなどの用途に利用する場合は、事前に必要な大きさのファイルを作成して拡張しておくとよいでしょう。
また、バックエンドのストレージについては、4Kバイト単位のファイルシステムのフォーマットの場合には、明示的に4Kバイトを指定するとよい、というアドバイスも受けました。
ただし、ここで挙げたバックエンドストレージについての話は、サービスの仕様ではありません。ストレージシステムの刷新などで変更される可能性があることは留意しておきましょう。
Copyright © ITmedia, Inc. All Rights Reserved.