Discussions
Categories
Oracle Cloud Infrastructure : オラクルのオブジェクトストレージサービスの性能は？
オンプレミスからクラウドストレージ(オブジェクトストレージ)へのアップロード、ダウンロード性能を見積もることはなかなか難しいですよね。
- 対象ファイルサイズは小さいのか、大きいのか？
- ファイル数は？
- サーバーのNICの帯域はどれくらいあるのか？
- サーバーの上位スイッチはどの程度の帯域があるのか？
- 契約しているインターネット回線の帯域はどの程度なのか？
- そもそもクラウドベンダーのオブジェクトストレージサービスってどの程度の性能がでるんだろ？
など、ぱっと思いつくだけでもいろいろと考えなければいけないなぁという感じです。上記ほとんどが、そのときそのときの状況によって変わってくるので事前に性能テストをしてもあまり意味がなさそうです。ただ、「そもそもクラウドベンダーのオブジェクトストレージサービスってどの程度の性能がでるんだろ？」は事前のテストデータは参考になりそうです。なので簡単な性能測定をしてみようと思います。
テスト概要
オラクルクラウド内に作成したComputeインスタンスからオブジェクトストレージにラージファイルをアップロードダウンロードした際のスループットを計測。つまりインターネット回線のボトルネックの影響を気にせず純粋にオブジェクトストレージの性能(特にスループット)を計測してみます。
環境情報
以下のような環境でテストしてみました。リージョンはPhoenixです。
スペック的には以下のようになっており、特筆すべきは、物理コア52コア104スレッド、かつNICは25Gbpsという大規模なベアメタルのインスタンスでオブジェクトストレージに負荷をかけいく点です。NICの限界までスループットが伸びればいいなぁという思いがあります。
- Computeインスタンス：BM.Standard2.52
- CPU : 52コア(104スレッド)
- メモリ : 768 GB
- NIC : 25 Gbps
- Bucket : Standard Bucket
単一ラージファイルのアップロードとダウンロード性能
まずはラージファイル一つをアップロード、ダウンロードしてみます。
1GBのラージファイルをメモリ上(/dev/shm)に作り、これをアップロード、ダウンロード用のテストデータにします。ストレージ上にテストデータを作ると、ストレージIOまで考慮しなければならず面倒です。一般的なシステムですと、ストレージIOよりもネットワークIOが速くなる構成はあまりありませんが、今回は何といっても25 GbpsのNICを搭載しているインスタンスを使いますのでストレージIOに引っ張られないようにメモリにテストデータを置きます。パフォーマンスログもストレージIOを見る必要がなくなるので一石二鳥です。
アップロード、ダウンロードはocicliというoracle cloud用のツールを使います。ocicliとはなんだろ？という方はこちら。
下記のようなコマンドでアップロードしてゆきます。コマンドの簡単な説明としては、-nsでテナント名を指定、-bnでバケット名を指定、--fileでアップロード対象のファイルを指定という感じです。このコマンドはマルチパートアップロードとなり、下記ログからわかるように1GBのラージファイルを8つのパーツに分けて並列アップロードを行います。
$ oci os object put -ns OracleSonoda -bn SonodaBucket --file /dev/shm/data_1GB
Upload ID: b6156b09-7eb4-ae1c-617b-9c9bd3a5a37d
Split file into 8 parts for upload.
Uploading object [####################################] 100%
{
"etag": "fac242b7-28ca-429b-9a10-de1eb5835d2a",
"last-modified": "Wed, 27 Feb 2019 06:40:08 GMT",
"opc-multipart-md5": "KKRDS43OuPhjAwVlwXJM+A==-8"
}
ダウンロードは以下のように実行します。アップロード違う点は、--nameでオブジェクトストレージ上のオブジェクト名を指定し、--fileでダウンロードしたときにつけるファイル名を指定するところくらいです。
$ oci os object get -ns OracleSonoda -bn SonodaBucket --name data_1GB --file /dev/shm/down_1GB
Downloading object [####################################] 100%
結果としては以下のようなグラフになりました。まあ、こんなもんでしょうか。スループットとしてはアップロード時、ピークで80MB/s、ダウンロード時、ピークで40MB/sしか出ていません。CPUの使用率も1.5%以下と非常に低い。予想通り、負荷が低すぎて、スループットはあまり伸びないですね。
アップロードの結果
ダウンロードの結果
複数ラージファイルのアップロードとダウンロード性能
せっかく25 GbpsのNICがついているインスタンスなので、これで終わってはもったいない。もっと負荷を上げていきたいと思います。NICの限界が先か、オブジェクトストレージサービスの限界が先か。
負荷を上げるアプローチは単純です。要は複数ファイルを同時並行でアップロードすればよいだけ。本来はmulti processingのライブラリを使って行儀よくやったほうがいいのですが、少し面倒なのでアップロードコマンドに「&」をつけてfor文でブン回します。
ということでメモリ上に1GBのファイルをとりあえず50個作りました。
↓こんな感じ。
for i in `seq 1 50`; do
dd if=/dev/zero of=/dev/shm/data/data_1GB_${i} bs=1G count=1
done
で、この1GB x50個のファイルを50多重で一気にアップロードします。
↓こんな感じ。
for i in `seq 1 50`; do
oci os object put -ns OracleSonoda -bn SonodaBucket --file /dev/shm/data/data_1GB_${i} &
done
当然、ダウンロードも50多重で一気にダウンロード。
↓こんな感じ。
for i in `seq 1 50`; do
oci os object get -ns OracleSonoda -bn SonodaBucket --name data_1GB_${i} --file /dev/shm/data/down_1GB_${i} &
done
で、結果のグラフがこちら。
アップロードはピーク時、約3GB/sec(＝約24Gbps)も出ました。CPU使用率もだいぶ上がりました。
ダウンロードもピーク時、約2.5GB/sec(＝約20Gpbs)まで上がりました。
しかし、クラウドって本当に便利ですね。。。簡単なテストとは言えオンプレミスでテストしようとするとそれなりに手間と時間がかかりますが、クラウドだとわずか30分足らずで完了です。
考察
- 今回のテストケース(ラージファイル50多重)ではオブジェクトストレージはボトルネックとならず、NICの限界性能に近い値がでているといっていいと思います。
- アップロードに関しては25Gbps NICに対して24Gbpsと95%も帯域を使えている
- ダウンロードに関しては25Gbps NICに対して20Gbpsと80%の帯域を使えている
- ダウンロードに関してはもうちょっとでてもいいかなと思います。おそらくファイル数がもっと多くて同時ダウンロード数が多い場合はスループットがもっと伸びるのだろうと思います。
- つまり、この程度ではオブジェクトストレージがボトルネックになることはないということがわかりました。
- 今回は一つのインスタンスから負荷をかけましたが、複数インスタンスから同時に負荷をかけるともっとスループットが伸びそうですね。(また機会がありましたら実施したいと思います。)
しかし、CPUを使い切ってくれるツールってなかなかないですよね。。。
どなたかいいツールをご存知でしたらコメント欄で教えていただけると幸甚です。。。
最後に、賢明な読者の方々にはご理解いただいていると思いますが、上記は参考値ですのでくれぐれもこの値をベースに実システムのサイジングをすることは避けてくださいね。