クラウド

 

比較するクラウドは6つ

idcf cloud: http://www.idcf.jp/cloud/
sakura cloud: http://cloud.sakura.ad.jp/
nifty cloud: http://cloud.nifty.com/
amazon aws: http://aws.amazon.com/jp/※1ドル100円換算、1か月を30日として計算
nttcom cloudn: http://www.ntt.com/cloudn/
g
mo apli cloud: http://cloud.gmo.jp/

自分としてはパブリッククラウド環境を選択する上で一つの指標として使う事にしようかなと考えてます。

ここでは1000円あたりの性能比でも比較します。

参考までに物理サーバの結果も載せています。

ベンチマークソフトはUnixBenchを利用。価格に関しては定価で比較しています。ボリュームやリザーブによるディスカウントについては考慮していません。
また、UnixBenchによるスコアを重要視するのではなく各社が相対的にどの位置づけになるのかだけでも確認できればと考えています。

company type core memory cpu type score 月額 価格性能比
idcf
cloud
s2 1 1G E5-2670 2.60GHz 1012 5,760 175
s4 1 2G E5-2670 2.60GHz 1035 12,240 85
m4 2 4G E5-2670 2.60GHz 1763 15,840 111
m8 2 8G E5-2670 2.60GHz 1786 22,320 80
sakura
no cloud
1 1G E5-2640 2.50GHz 1407 1,900 741
1 2G E5-2640 2.50GHz 1403 2,500 561
1 4G E5-2640 2.50GHz 1403 4,075 344
2 4G E5-2640 2.50GHz 2186 8,145 268
4 8G E5-2640 2.50GHz 3481 11,445 304
12 48G E5-2640 2.50GHz 5897 55,545 106
nifty
cloud
small 1 1G E5-2690 2.90GHz 1636 13,335 123
midium4 2 4G X5680 3.33GHz 2821 35,070 80
extra-large16 6 16G X5680  3.33GHz 5930 106,470 56
amazon
aws
m1.small 1 1.7G E5645 2.40GHz 153 11,160 14
m1.large 2 7.5G E5645 2.40GHz 649 30,168 22
m3.2xlarge 8 30G E5-2670  2.60GHz 1542 107,856 14
ntt com
cloudn
m1.small 1 2G QEMU rhel6 2GHz 1306 3,780 346
m1.midium  2  4G QEMU rhel6 2GHz  1632  7,560  216
m2.4xlarge 16 64G QEMU rhel6 2GHz 5056 87,780 58
GMO
アプリクラウド
XS 1 4G QEMU rhel6 1146 11,970 96
XS
High-CPU
2 4G QEMU rhel6 1676 17,640 95
SS 2 8G QEMU rhel6 1679 23,310 72
SS
High-CPU
4 8G QEMU rhel6 2962 33,690 88
S 16G QEMU rhel6 3063 44,100 69
M 6 30G QEMU rhel6 3519 81,900 43
L 10 60G QEMU rhel6 4362 157,500 28
XL 12 120G QEMU rhel6 4550 258,300 18
物理サーバ
localdisk @DMM
参考ベンチ
 – 32 32G E5-2450L 1.80GHz  6289  11,000 571
 XenServer
iSCSI @DMM
参考ベンチ
–  4G X5650 2.67GHz  1415   3,500 404 

パフォーマンススコアが高い順(1Core)

nifty(1600) > sakura(1400) > ncom(1306) > gmo(1146) > idcf(1000) > aws(153)

niftyが強い。awsは不得意な項目により足を引っ張ってスコアが低いのではなく全体的に低い。
※niftyは3.33GHzなので電気代が半端ないんだろうなあと想像がつきます。

1000円あたりの性能で比較してみよう。
※価格性能比=スコア/月額利用料*1000

sakura(741) > ncom(346) > idcf(175) > nifty(123) > gmo(96) > aws(14)

特筆すべきはniftyではないでしょうか、順位が3つも下がっています。
この基準だとさくらの圧勝で機能を絞ることによって別の顧客層へアプローチできるのではないかと思います。ncomも優秀

では、2Coreではどうでしょうか

nifty(2800) > sakura(2186) > idcf(1763) > gmo(1676) > ncom(1632) > aws(649)

こちらもniftyが強い。awsは1Coreの時と同じような状況です。

1000円あたりの性能も見てみましょう。

sakura(268) > ncom(216) > gmo(112) > idcf(111) > gmo(95) > nifty(80) > aws(22)

基本的にはスペックが上がるとコスパが悪化する傾向ですかね。
先ほどと同様niftyについてはsakura、nttやidcfに逆転されています。ここでもNTTは意外と優秀です。

1コアあたりの性能スコアが1400以下で良いなら、さくらのクラウドが一番コスパが高い

1600以上が必要ならniftyの一択でもいいかな。

ただ、1600以上の性能が必要な環境はあまりないような気もしますので、性能2番手でコスパ1番のsakuraが個人的には好きです。

性能のNIFTYクラウド。コスパのsakuraといったところでしょうか。

 

散布図はこちら。
これを見ると物理サーバはおいておいてsakuraとncomがバランスが良いように見えます。

clouccompare

※ 重要ポイント

最適なサイジングから価格性能比で選択

あとは信頼性、高機能、直観的なインターフェースやサポート体制などで選択するわけですが、
一部を除いて横並びのようにも思います。なのでクラウドストレージプロバイダのNirvanixのように事業停止のリスクが低い会社というのも判断基準としても良いかもしれません。

p.s.

niftyクラウドはゾーンによってCPUの型番が違うようです。

ゾーンが新しければ新しいほど新型のCPUになるようなので、気にされる方はゾーンの選択から考えたほうが良いかもしれません。

古いゾーンは将来的には価格で差別化しないと誰も使ってくれなくなる恐れがあるかも。償却が終われば圧倒的な安さで提供する業者も出てきそうですが。

 

FhGFS, glusterfs, クラウド

始めましたといっても検証しているだけです。すいません

FhGFS、正式にはFraunhoferFSとのことでハイパフォーマンスを想定した分散並列ファイルシステム。

GlusterFSのようにフォールトトレラントな分散並列ファイルシステムではなく、
どこかのサーバが停止すれば障害となります。現状のバージョンでは運用でカバーするしかなさそうです。

特徴としてはストライピングによる高速化とメタデータサーバの分散化による高速化
GlusterFSに比べて小さいファイルでもパフォーマンスを発揮します。
グラフィカルなツールで管理やモニタリングが可能な点もGlusterFSにはない機能です。

とにかく、実際に試してみないとわからないので

インストール&パフォーマンス比較を行ってみます。

まずは役割を確認します。

■役割

5つの役割が存在します。

1.Management service server(fhgfs-mgmt)

management,metadata,storage,clientへシステムコンフィグレーションを提供するサーバ

2.Metadata servers(fhgfs-meta)

メタデータを保管するサーバ

3.Storage servers(fhgfs-storage)

実データを保管するサーバ

4.Graphical administration and monitoring system server(fhgfs-admon)

グラフィカルなJAVAのツールからこのサーバを経由してFhGFSの管理やパフォーマンスグラフのモニタリングを行う

5.Clients(fhgfs-helperd,fhgfs-client)

データをmountするサーバ。

■サーバの準備

パブリッククラウド上でサーバを立ち上げます。すべて下記の環境で立ち上げます。
CentOS-6.4 64bit 20GB 4CPU 4GB

各サーバでrootで公開鍵の登録を行いiptablesとselinuxは切っておきます。

1 * Management server 192.168.0.101
2 * Metadata servers 192.168.0.151-152
8 * Storage servers 192.168.0.201-208
1 * Admon server 192.168.0.251
1 * Clients 192.168.0.51
1 * 作業サーバ(インターネットへのGWにもなっています) 192.168.0.1

の計14台を構築しました。クラウドならこの段階まで10分以内で構築可能です。

作業サーバのhostsを登録します。

すべてのサーバに配布もしておきます。

準備は以上です。

■パッケージインストール

パッケージのインストールはすべて作業サーバから行います。

Management server向け

Metadata servers向け

Storage servers向け

Admon server向け

Clients向け

■InfiniBand用の設定

今回はイーサネット環境ですので設定しません。

■各環境設定(各環境で設定)

Management server向け

Storage server向け

Admon server向け

Clients向け

■サービススタート(作業サーバから)

問題なければこれでclinetでdfすると

このようになっているはずです。mountされ使えるようになっています。

■メタデータとストレージデータの冗長化

メタデータの冗長化(client環境にて)

この設定でメタデータが2重化されます。ただしフォールトトレランスではなく復旧には手動での作業が必要です。

ストレージデータの冗長化

raid10設定とすることでデータの2重化が可能。ただし復旧は手動での作業です。

■admon server

admonサーバは8000番ポートで待ちうけてます。

今回は作業サーバにインターネットからのポートフォワーディングによって自身の環境から繋ぎます。

GWサーバ(eth0:external eth1:internal)にてマスカレードとポートフォワーディングの設定を行っています。

あとは、http://作業サーバのIP:8000

ツールのダウンロードリンクが表示されますのでダウンロード

ダウンロードしたJAVAツールを起動させログインすれば下記のようなモニタリングや各種管理が可能となります。

初期のログインはAdministrator:adminでのログイン

admon

■パフォーマンス比較 GlusterFS(stripe 4 replica 2) vs FhGFS(raid10)

dd、catやlsを利用したパフォーマンス比較です。

 

 filesystem write(1M 1000個) write(1M 10000個) write(5G 1個)  read(5G 1個)  ls(1000個のファイル)  ls(10000個のファイル)
 FhGFS  91s  196s  90s  55s  0.5s  5.6s
 Glusterfs  186s  430s  186s  49s  1.2s  14s

これを見るとFhGFSのほうが書き込みと小さいファイルが得意。

小さいファイルで書き込みパフォーマンスが必要かつ障害がある程度許容されるサービスに限定すれば使いどころはあるかなあ。

Glusterfsのほうがインストールも設定も運用も簡単でバランスは良いように思います。

 

インフラ全般, クラウド, セキュリティ

世の中にはDDoSを防ぐためにいろんな製品やサービスが登場していますが、

そのどれも完璧に防げるとは言い切れないように思います。

ROIを考えても、完璧に防ぐための投資は莫大になりかねず、

リターンに見合わない投資が必要になってくるように思います。

そこで、シンプルな戦略を考えてみました。

まず、保護レベルを4段階ほど設定します。

1.アプリケーションサーバの保護
2.データベースの保護
3.ログイン処理の保護
4.メンテナンスモード

では、それぞれのレベルで対策を考えていきます。
1.アプリケーションサーバの保護

フロントサーバにnginxなどの高速なリバースプロクシサーバを配置。普段はキャッシュしない。

ショートパケットのSyn Floodの攻撃などはこのフロントエンドで吸収する。

また、特定できるパケットがあればそのパケットをiptablesなどで落とす

2.データベースの保護

フロントサーバのリバースプロクシサーバでほぼすべてのページをキャッシュさせるように設定変更

攻撃発生中はダイナミックなページを停止しキャッシュから静的なページを配信。

高速なウェブサーバであれば1台あたり10万リクエスト/秒での配信も可能。

特にhttp get floodに有効
3.ログイン処理の保護

ログインページを閉鎖する。もしくは流量制限を行う。

流量制限はフロントのサーバで行う。

決まった数のリクエストのみアプリケーションサーバへ渡す。それ以上はエラー処理

ポリシーに合わせてログインに失敗したIPをロックアウトする。

http post floodに有効

攻撃時であってもログイン後は通常サービスが提供可能とする

フロントサーバにてクッキーでログインを識別し専用のサーバへスイッチ
4.メンテナンスモード

フロントサーバにメンテナンスページを配置

想定以上の攻撃時はメンテナンスページへ
あとは、このフロントのサーバをどれだけ用意するかになってくると思います。

パブリッククラウドを組み合わせて各社のクラウドでも対応できるよう準備すれば大きな攻撃時に対応ができるかもしれません。

コストはその攻撃時に稼働させていたインスタンス分の支払いだけでよくなります。

以上、シンプルな戦略を考えてみたのですがいかがでしょうか?

ご意見いただけると助かります。

高価な攻撃対策用の製品であっても大規模な攻撃だとダウンしてしまいます。

であれば、こういった機材は検知用に利用することで、必要最低限の投資で最適なリターンが見込めるのではないかと。

いずれにしても、攻撃はサーバで守る。これが一番シンプルで確実じゃないかなあ。

 

 

クラウド

 

CDNでは対応できないような独自開発のアプリケーションでスパイクするトラフィックをさばきたい場合

もしくは

トラフィックをコミットしなくともスパイクする深夜のトラフィックだけを安価に配信したい場合に有用です。

注意するところとしては

例えばdmmでは

サーバ20台で1台あたりのトラフィックが1Gbps

それに合わせてバックボーンが20Gbps以上

がクラウドを利用する条件になるのですが、

このトラフィックがさばけるかどうかを前もって確認しておく必要があるというところになります。

ちょうど先月、各社に確認したのですが現状ではAWS以外は対応不可でした。

インスタンスタイプをc1.xlargeを利用することで1Gbpsのトラフィックの対応が可能となるようで、

バックボーン側の心配もないとの回答をいただきました。

PAGE TOP