クラウド

Googleクラウド(Google compute engine)にアジアリージョンが開設されたという事で早速試してみました。

価格表

では進めます。

https://cloud.google.com/products/compute-engine/?hl=ja

今すぐ試すをクリック

新しいプロジェクトを作成

プロジェクト名「tsuchinoko project」
プロジェクトID「自動で表示されているものをそのまま利用」
プロジェクトを作成

先ほど作成したプロジェクトにページが遷移します。

そのページ上でcompute engineを選択

課金を有効にするかどうかを促されますので、課金を有効にしてクレジットカード情報を登録して先に進みます。

こちらで準備は完了です。

あとは、vmインスタンス⇒インスタンスの作成でそのまま直観的にインスタンスを作成してみてください。

一つ注意点としては、課金を有効にしたすぐ後はインスタンス作成がエラーとなることがあります。その場合は15分くらい待ってから再度作成してみてください。

では、インスタンスにログインしてみます。
※ほかのクラウドとは一線を駕しています。

google comupte engineやgoogle apps用のgoogle製のRESTなpythonツールからログインを行います。

まずはログイン元のサーバもしくはPCにこのツールのインストールする必要があります。

前準備としてpythonの2.7以降をインストールします、ただし自分の環境では2.6.6でも入りました。

前準備が終われば下記コマンドでツールがインストールされます。
いろいろ聞かれますが、GoogleApps用のツールを入れるかどうかだけ気にすればあとはすべてEnterで問題ないでしょう。

つぎに認証設定を行います。google compute engineではOAuth2での認証を行っておりここでtokenの設定を行います。

上記のコマンドを打つとtokenを取得するためのURLが表示されます。このURLをそのままコピペでブラウザに打ち込むとtokenが表示されます。
表示されたtokenを先ほどのターミナルに貼り付けてEnter
次にプロジェクト作成の時に必要になったプロジェクトIDを記入しEnterを押せばOAuth2での認証は完了です。
あとは先ほどいれたツール経由でログインすればログインが可能となります。

これでログインができたかと思います。

ログインもできたという事で早速ディスクのベンチマークを取ってみます。

作成したインスタンスは

Standard

Instance type Virtual Cores Memory Price (US$)/Hour
(US hosted)
Price (US$)/Hour
(Europe hosted)
Price (US$)/Hour
(APAC hosted)
n1-standard-1 1 3.75GB $0.070 $0.077 $0.077

月額:6000円程度になります。

過去の価格性能比と比較するとこのようになりました。

HP Cloud(2815) > sakura1(2412) > sakura2(2307) > ncom2a(515) > ncom1a(179) > nifty11(155) > nifty12(129) > nifty13(109) > idcf(53) > googleクラウド(51)
※参考http://tsuchinoko.dmmlabs.com/?p=940

他と比べて価格性能比が著しく悪い

台湾にGoogleのアジアリージョンがあるようですが、
日本、台湾間は38ms程度で品質は安定しています。

最後に

今回使ってみての感想、

登録、クレジットカード登録、インスタンス作成、ログインまで直観的だと感じました。

また、IPを指定せずにログインが可能なあたりは秀逸。ログイン経由を忘れちゃうことがあるのですが、そういうのが無くなります。かなり便利

海外でのDRするならネットワーク的に近いここが良いように思います。

価格も安いわけではないので急いで使いだすこともないと思います。

とりあえず、まだまだ触りですのでいろいろ試していきます。

それにしても楽ちんだったなあ。

クラウド, 勉強会, 小ネタ, 雑談

IBM Open Cloud Summit Japan が定員いっぱいで現地参加できなかったので、ライブ中継環境を作りました。

ソファーを持ち込んで、お菓子を食べつつ、適当に雑談しながら見れるのはなかなか良いです。
良いスピーカーが欲しくなりました。

public_viewing

クラウド

 

※言葉の定義や認識違いを修正しました。

HP Public Cloud

http://www.hpcloud.com

HPが提供するパブリッククラウドでOpenStackです。取り敢えず、扱ってみたいという方には良いかと思います。

今なら各月100ドル分の利用が無料(3ヶ月間で300ドルまで)になりますので早速申し込んで使ってみました。

申し込みの流れはこのようになります。

全部乗せのセキュリティーをかいくぐって、ここまでくるとようやくHPのクラウドが利用できるようになります。

使用感としては一応直感的で使いやすくなっていると思います。

別のツチノコスタッフいわくスタンダードなhorizonインターフェースって印象のようです。

早速、Instanceを作りfioを動かしてみます。

コスト面を考えると主力は

Standard Instance Type Description Local Disk(LocalDisk) Ephemeral Disk(LocalDisk) Price
Standard Extra Small 1virtualcore, 1GB RAM, 20GB disk 10GB 10GB $0.03/hr ($21.90/mo.)*
Standard Small 2virtualcore, 2GB RAM, 40GB disk 30GB 10GB $0.06/hr ($43.80/mo.)*
Standard Medium 2virtualcore, 4GB RAM, 80GB disk 30GB 50GB $0.12/hr ($87.60/mo.)*
Standard Large 4virtualcore, 8GB RAM, 160GB disk 30GB 130GB $0.24/hr ($175.20/mo.)*

このあたりになると思います。

awsと同じような感覚でインスタンスの作成が可能です。
リージョンはいまのところ日本にはなくアメリカの東と西海岸だけのようです。

他のパブリッククラウド環境と違う点としてはディスク構成があげられると思います。

立ち上げたVMは起動用のroot diskとデータ用のephemeral diskが存在しています。

具体的には

root disk : /dev/vda1
ephemeral disk : /dev/vdb

root diskはsnapshotでバックアップが取れるようですが、ephemeral diskはsnapshotが取れませんので外部ボリュームを取り付けてそこへ自身でバックアップする必要があるようです。

パフォーマンスについては同じサーバ内臓のディスクを利用していますので同等となります。

とりあえず、一番小さいインスタンスでのIOPSの結果です。

 

調査ディスク 容量 iops Latency
Root Disk 10GB 6756 0.250msec 50% 0.1msec 35% 0.05msec 12%
Ephemeral Disk 10GB 6914 0.250msec 48% 0.1msec 47% 0.05msec 3%
Volume Disk 10GB 148 50msec 79% 20msec 16% 10msec 2%

ここでVolumeDiskという項目が出てきました。このボリュームは外部ストレージで、
起動用にもデータ用にもどちらの利用も可能です。

ただし、パフォーマンスがまったく違います。
将来的にIOPSを保証するようなサービスが出てくるんだと思います。

価格性能比については圧倒的でsakuraのクラウドの2412をも超え2815となります。

ボリュームディスク(IOPS:148)を使ったとしてもデータディスクをEphemeralにしておけばパフォーマンスで問題とはならないように思います。

過去の価格性能比と比較するとこのようになりました。

HP Cloud(2815) > sakura1(2412) > sakura2(2307) > ncom2a(515) > ncom1a(179) > nifty11(155) > nifty12(129) > nifty13(109) > idcf(53)
※参考http://tsuchinoko.dmmlabs.com/?p=940

p.s.

そういえば24時間365日、オンラインでチャットで質問が可能です。ここでEphemeralDiskについて確認してました。かなり使えるサービスだと思います。

 

linux, インフラ全般, クラウド

現状の仮想環境ではマルチキューが利用できません。したがってmemcachedなどのミドルウェアを仮想上で動作させると必ず一つのCPUに偏ります。これを回避するためにはrhelの7系のカーネルを待つしかありません。

と思っていたところ、

RPS/RFSの設定でCentOS6.xで仮想環境でCPUの偏りをなくすことができるようです。
RPS/RFSを使用するとソフトウェア的にNICの割り込みに使用するCPUを分散してくれます。
dmmで利用しているmemcachedのサーバで設定してみたところ、
実際にCPUコアの偏りが無くなったことが確認できました。

入れ替え前のmemcachedサーバのCPU負荷
cpuの1に偏っています。

RPS/RFS設定を行ったmemcachedサーバのCPU負荷
cpuの0,1,2,3と綺麗に分散されています。

設定例

/sys/class/net/eth0/queues/rx-0/rps_cpus は使用するCPUを指定します。
各コアを使用するかのフラグと2進数で各ビットを立て、16進数に変換します。
1,2コアを使用する場合は
2進数で 11 → 16進数に変換して3を設定。
1,2,3,4コアを使用する場合は
2進数で 1111 → 16進数に変換してfを設定。

これにより、ネットワーク系のエラーやmemcachedのレスポンスタイムが改善しています。

・入れ替え前
before_rps

・入れ替え後
after_rps

クラウド

パブリッククラウドの環境にmemcachedをインストールしmemslapで負荷試験を行ってみました。

下記コマンドでの評価です。

memslap –servers=x.x.x.x –concurrency=32 –flush –test set –execute-number=50000

  memcached
Client
月額費用 memcached
Server
月額費用 処理時間 RTT(avg)
server – client
nifty      2Core 4GB 35,070 1Core 2GB 18,144 24sec 0.249ms
4Core 8GB  66,528 24sec 0.288ms
8Core 32GB  183,435 23sec 0.152ms
1Core 2GB 18,144 8Core 32GB 183,435 27sec
2Core 4GB 35,070 29sec
4Core 8GB 66,528 30sec
localhost 183,435 15sec
idcf  2Core 8GB 13,600 1Core 2GB 5,300 32sec 0.228ms
1Core 2GB 5,300 2Core 8GB 13,600 32sec
locahost 13,600 28sec
ncom        2Core 4GB 7,560 1Core 2GB 3,780 51sec 0.610ms
 4Core 8GB 15,120 50sec 0.579ms
 8Core 16GB 30,240 50sec 0.684ms
 16Core 64GB 87,780 43sec 0.349ms
1Core 2GB 3,780 16Core 64GB 87,780 50sec
2Core 4GB 7,560 46sec
4Core 8GB 15,120 50sec
8Core 16GB 30.240 47sec
localhost 87,780 40sec
sakura      2Core 4GB 5,145 1Core 2GB 2,500 172sec 0.294ms
4Core 8GB 11,445 165sec 0.364ms
12Core 48GB 55,545 162sec 0.349ms
1Core 2GB 2,500 12Core 48GB 55,545 150sec
2Core 4GB 5,145 66sec
4Core 8GB 11,445 46sec
localhost 55,545 19sec

※1Coreサーバでのlocalhostはチェックしていません。1Coreしかないのでmemslap側の処理の負荷により参考になる値が取れないため。

パッと見だと

nifty > idcf > ncom > sakura

各社間の比較というよりは各クラウド環境の中でmemcachedをどのようなスペックで構成すればいいのかの指標にできるような気がします。

これを見れば余剰なスペックを抑制しコスト的なメリットが見えてくるかも。もちろん速度重視の場合はこの限りではないですが。sakura以外は低めのスペックでも十分でコストを抑制できそうです。

それにしても特筆すべきはsakuraの各社と比較しての処理時間の遅さとサーバスペックによる処理時間の差です。

LinuxではRescheduling interruptsにより非常に忙しい状態にあるときアイドル状態にあるCPUへ処理を割り振るようになるようなんですが、sakuraのサーバはこの状態への移行が他社と比べて早いためコア数の変化によりリニアに処理時間が早くなっていたように見える。

逆にスペックを上げればパフォーマンスの改善が見込まれるので望ましい形のような気もしますが基本性能が低いだけになんとも言えないような気もします。

このあたり、いいリファレンスないですかね?

兎にも角にもご参考までに

PAGE TOP