検索
連載

IDCFクラウドのベンチマーク評価（2014年11月）：技術者視点のクラウドサービスレビュー（2）（1/2 ページ）

IDCFクラウドの性能を、ベンチマークツールを使って簡易に検証。パフォーマンスの特徴や料金面での比較なども行っています。検証時のChefレシピも公開します。

[澤登亨彦，HiganWorks LLC] PC用表示 関連情報
Share
Tweet
LINE
Hatena

　前回はIDCFクラウドについて、ざっと機能的な特徴を紹介しました。今回はベンチマークツールを使って、性能や特性を検証していきます。ぜひ、利用時の参考としてください。なお、数値や価格は本稿執筆時点（2014年11月）でのものです。クラウドサービスは価格などが変動しますので、ご利用の際には本稿を参考にご自身でも追検証されることをお勧めします。

検証の前提環境と比較内容

　IDCFクラウドの仮想マシンを起動して、ディスクのI/Oとゾーン内転送速度を計測してみます。対象には月額利用料が特に抑えられている「light.S1」を選びました。今回は同価格帯との比較のため、Amazon EC2の「t2.micro」インスタンスおよび周辺サービスの結果と料金目安を併記します。なお、参考料金にはインスタンスそのものの使用量は含んでいません。

検証（1）ディスクI/Oの評価

　まず、ディスクI/Oの性能を見ていきましょう。ここでは、vdbench*を使用し、次の条件でブロックデバイスに対してベンチマークを行いました。

  • マウント済ルートブロックボリュームへのファイルシステムベンチマーク（4k）
  • 増設ブロックボリュームへRAWアクセス（8k）
  • ランダムRead／Write（50対50）
  • IOPSはベンチマーク（5分間実行）を3回計測

* vdbench http://www.oracle.com/technetwork/server-storage/vdbench-downloads-1901681.html



ファイルシステム測定

　ファイルシステム測定で使用した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上で公開しています。

Column：“中の人”に聞いた特徴、利用のヒント

　本稿のベンチマーク結果について、IDCフロンティアの技術担当の方から、いくつかコメントをいただきました。ここでは、それらの情報を紹介しておきましょう。

バックエンドストレージは最適化を行う

　IDCFクラウドで使用しているバックエンドのストレージは、ボリュームのアクセス頻度に応じてブロックをSSDへ再配置するそうです。

　再配置は午前2時に実行されるとのことでしたので、技術担当の方に一言伝えた上で、ベンチマークをかけっぱなしにしてみました。実際のIOPS推移が下のグラフです。条件は本文中で実施したものと同じ、対象は200Gバイトの追加ディスクです。


使用率に応じてIOPSの上限が変更される

　グラフからは午前2時を境に、じわじわとIOPSが向上していく様子が見て取れます。午前4時を過ぎたころには平均的に3000IOPSを上回っています。この段階で、Amazon EBSのgp2より高い性能が得られています。

　このベンチマーク結果から（過信は禁物ですが）、バックエンドを含めた性能面に十分余裕があることがうかがえます。

ディスクはシンプロビジョニングで作成される

　コントロールパネルからディスクを追加し、マウントした直後にベンチマークを実施すると、しばらく200IOPS程度のスコアが続きます。

　これはボリュームの確保にシンプロビジョニングを用いており、サイズの拡張を行いながらベンチマークを処理していることが理由だということです。

　容量を多く使い、高いIOPSが求められるデータベースなどの用途に利用する場合は、事前に必要な大きさのファイルを作成して拡張しておくとよいでしょう。

ブロックサイズは4Kバイトがベスト

　また、バックエンドのストレージについては、4Kバイト単位のファイルシステムのフォーマットの場合には、明示的に4Kバイトを指定するとよい、というアドバイスも受けました。

　ただし、ここで挙げたバックエンドストレージについての話は、サービスの仕様ではありません。ストレージシステムの刷新などで変更される可能性があることは留意しておきましょう。


Copyright © ITmedia, Inc. All Rights Reserved.

　　　　　　 | 次のページへ
ページトップに戻る