11月 11

さくらのクラウドの料金が発表になり、相対的に他のクラウドサービスより安いと言われています。ところが、実際にAWSなどから置き換えるような用途を考えた場合に、今までの感覚でプランを選ぼうとすると、本当に安いのか疑問になる部分が出てきたので、シミュレーションをしながら考えてみました。

バランスが悪い?CPUがネック?

アプリケーションサーバーの用途などCPUパワーが必要なケースを考えます。
例えば、4コアは欲しいけどメモリは少なくてもいい場合、4コアの最低プランであるプラン7(メモリ16GB)を選択しないといけなくなります。これはAWSでいうCPUに重みを置いたc1.mediumインスタンスのようなプランがないためで、バランスが悪くオーバースペックになってしまいますし、価格も高めになります。

しかし、パフォーマンスは使われているサーバーのスペックやリソース配分が影響を与えるので、元々の能力が違う上でコア数の多寡だけを取り上げても判断材料にはなりません。

実際多くの方が、先行サービスのさくらのVPSとAWS(EC2)のベンチマークを行なっていて、結果は概ねさくらのVPSが優れているというものです。

また、EC2で定義されているECUというCPUの単位は、以下のようなものです。

特定のインスタンスに配分されている CPU 量は、これらの EC2 Compute Unit で明示されます。当社はいくつかのベンチマークとテストを使用して、EC2 Compute Unit のパフォーマンスの安定性と予測可能性を管理します。1つの EC2 Compute Unit は、1つの 1.0-1.2 GHz 2007 Opteron または 2007 Xeon プロセッサの CPU 能力に等しい能力を提供します。

c1.mediumインスタンス(5 ECU(2.5 ECU × 2仮想コア))の場合は2007 Opteronの2.5-3.0GHz × 2仮想コア相当のパフォーマンスだということになります。

この辺りを考慮にいれて、コア数に振り回されないように、実際のアプリケーションでテストを行って最適なプランを選ぶことになりそうです。
現段階では安いとも高いとも言えないところです。

メモリ特化の用途には安い!ではディスクは?

DBサーバーやキャッシュサーバーの用途などメモリが多く必要なケースを考えます。
例えばmemcachedサーバーの用途でメモリが8GBあればCPUもディスク容量も問わないケースだと、プラン5になりAWSのm1.largeインスタンスと比べて半額で済みます。

一方、m1.largeインスタンス並のディスク容量を追加しようとすると、プラン5+750GBで26,150円と高くなります。
これはAWSのディスクが安いとも言えるので、大容量のストレージが必要な場合はさくらのクラウドは安いとは言えないでしょう。

実際、DBサーバーの用途で8GBのメモリを積んだサーバーを運用する場合、850GBものデータを扱うことはパフォーマンスを考えるとありえないので、通常のケースでは問題にならないと思っています。

トラフィック特化の用途では?

大容量コンテンツの配信やストリーミングサービスだけでなく、単純にアクセス数が多いサービスだと転送量に対する課金が全体の半分くらいに達することもあります。
さくらのクラウドは転送量やリクエスト数に応じて従量課金されることがないので、トラフィックに関しては安いと言えます。

スペック・料金シミュレータ

上記を踏まえて、スペックと料金のシミュレータを作って見ました。
利用したいスペックを選択するとマッチする最低ラインのプランが決定されます。
利用したいスペックよりも表記上オーバースペックの場合、該当のスペックが赤くなります。
(※ 料金表記などに誤りがある場合もありますのでご了承の上、ご利用下さい。)

利用したいスペック

選択されたプラン
CPU
メモリ
ディスク
月額料金
日割料金

Tagged with:
11月 07

本日の第4回さくらの夕べで明らかになった情報のメモを整理します。
ほとんどの情報は明日のプレスリリースで公開される情報です。

リリース日

2011年11月15日 15:00に石狩データセンターがオープンし、そのタイミングでリリース予定とのこと。申込みページはこちら[さくらのクラウド] になる予定。

さくらのクラウド プラン別価格表

プラン名 CPU メモリ ディスク 月額料金 日割料金
プラン1 仮想1コア 2GB 20GB ¥2,500 ¥126
プラン2 仮想1コア 3GB ¥3,750 ¥189
プラン3 仮想2コア 4GB ¥5,200 ¥260
プラン4 仮想2コア 6GB ¥7,800 ¥390
プラン5 仮想3コア 8GB ¥10,400 ¥520
プラン6 仮想3コア 12GB ¥15,600 ¥780
プラン7 仮想4コア 16GB ¥20,800 ¥1,040
プラン8 仮想4コア 24GB ¥31,200 ¥1,560
プラン9 仮想6コア 32GB ¥41,500 ¥2,080
プラン10 仮想8コア 48GB ¥52,800 ¥2,640
プラン11 仮想10コア 64GB ¥64,000 ¥3,200
プラン12 仮想12コア 96GB ¥81,600 ¥4,080
プラン13 仮想12コア 128GB ¥96,000 ¥4,800

上記のプランをベースにローカルネットワークで通信をする場合は仮想スイッチ(¥5,250)、ストレージを増やしたい場合は容量に応じて追加料金でディスクを増やす料金体系。転送量は込み込みなので、転送量の多いサービスはAWSなどに比べてさらに料金が圧縮できる。
ベースの料金は1日〜20日までの利用は日割料金、それ以上の利用は月額料金で課金される。

ロケーション

さくらのクラウドのロケーションは新設の石狩データセンターになるので、在庫は潤沢(1,000台でも2,000台でも)。
東京や大阪などのリージョンも要望が多ければ考える予定。
クラウドとVPSや専用サーバーを同一の石狩データセンターで借りれば、レイテンシーが1ms以下で通信できるミクスチャー環境が構築できる。

その他気になったこと

SSD

ストレージとしてSSDやioDriveも選択できるようにする予定とのこと。手軽に利用できるようになれば、I/Oで頭を悩ませなくて済むようになりそう。

オートスケール

オートスケールは実装する予定はないとのこと。
クラウドをコントロールするAPIが用意されるので、サードパーティーが参入できる部分。

Tagged with:
5月 23

はじめに

nginxは頻繁に保守されていてどんどんバージョンが上がっていく一方で、UbuntuやWindows以外ではソースコードからビルドする方法が一般的だと思います。

nginxのバージョンアップ頻度

  • 2011/05/10 1.0.2
  • 2011/05/03 1.0.1
  • 2011/04/12 1.0.0
  • 2011/04/04 0.9.7
  • 2011/03/21 0.9.6

nginx CHANGESより

LinuxやBSDの多くのディストリビューションではNginxがパッケージリポジトリに含まれており、通常のソフトウェアインストール手法でインストールする事ができます。(Debianにおけるapt-getや、Gentooにおけるemerge、FreeBSDにおけるports、Fedora の yum、Vine Linux の apt-get など)

たまにこれらのパッケージは古いものであったりすることがあるので気をつけてください。最新の機能やバグ修正版を求めるなら、ソースコードからビルドすることをお勧めします。…
http://wiki.nginx.org/InstallJaより

上記のようにどのディストリビューションでもパッケージは用意されているものの、バージョンが古いことが多いですし、何よりも各機能を追加するモジュールがApache(httpd)と違ってスタティックな方式を採用しているので、用途に合わせてモジュールを追加したい場合は自分でビルドするしかありません。

そうすると、自分でバイナリを上書きしてアップグレードすることになります。
メンテナンス時間を設けてサービスを止めて保守出来る場合はいいですが、積極的に止めることは避けたいサービスの場合、以下の方法でリクエストを止めることなくアップグレードができます。

オン・ザ・フライで新しいバイナリにアップグレードする

今回は、nginx0.7.67を最新版(1.0.2 2011/5/23現在)にアップグレードした時の手順の確認と結果の検証を行いました。

準備

現在稼動しているバージョンのビルドオプションを確認する

-Vオプションで確認することが出来ます。

$ /usr/local/nginx/sbin/nginx -V
nginx version: nginx/0.7.67
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-48)
TLS SNI support disabled
configure arguments: --with-http_stub_status_module --with-http_ssl_module

configure argumentsがオプション部分です。
サードパーティ製のモジュールを入れている場合(–add-module)は、そのモジュールが新しいバージョンのnginxに対応しているか、対応しているモジュールのバージョンがリリースされていないか、確認する必要があります。

最新バージョンをビルドする

先ほど確認したビルドオプションで新しいバージョンをビルドします。

$ wget http://nginx.org/download/nginx-1.0.2.tar.gz
$ tar vfxz nginx-1.0.2.tar.gz 
$ cd nginx-1.0.2

# ここで先のオプションを使う
$ ./configure --with-http_stub_status_module --with-http_ssl_module
$ make

# 成功すると./objs 以下に新しいバイナリが出来上がるので確認
$ ./objs/nginx -V
nginx: nginx version: nginx/1.0.2
nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50)
nginx: TLS SNI support disabled
nginx: configure arguments: --with-http_stub_status_module --with-http_ssl_module

現行の設定ファイルのままで問題がないか確認する

仕様の変更などで利用できなくなるディレクティブなどがあるかもしれません。現行の設定ファイルでconfig testが通るかチェックします。

$ sudo ./objs/nginx -t -c /usr/local/nginx/conf/nginx.conf
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

アップグレード

バイナリをコピーする

単純にコピーnginxファイルを上書きするか、make installで上書きします。

$ sudo cp objs/nginx /usr/local/nginx/sbin/nginx

or

$ sudo make install

プロセスを確認する

いよいよ本題です。現在動いているnginxのマスタープロセスのpidを確認します。

psコマンド確認する方法
$ ps aux |grep nginx
root      5559  0.0  0.0  40976  1000 ?        Ss   16:36   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     5560  0.0  0.2  42572  3052 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5561  0.0  0.2  42572  3044 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5562  0.0  0.2  42572  2992 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5564  0.0  0.2  42572  2940 ?        S    16:36   0:00 nginx: worker process  
pidファイルで確認する方法

nginx.confにpidディレクティブを設定している場合は設定したパスにpidファイルがあります。

$ cat /var/run/nginx.pid;
5559

pidは5559です。
ワーカープロセス数は、confファイル"worker_processes"の設定に依存します。

新しいバイナリを実行する(USR2シグナル)

USR2シグナルをマスタープロセスに送ります。

$ sudo kill -USR2 5559

すると、古いバージョンのプロセスと新しいバージョンのプロセスが共存する状態になります。

$ ps aux |grep nginx
root      5559  0.0  0.0  40976  1068 ?        Ss   16:36   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     5560  0.0  0.2  42572  3052 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5561  0.0  0.2  42572  3044 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5562  0.0  0.2  42572  2992 ?        S    16:36   0:00 nginx: worker process                                          
nginx     5564  0.0  0.2  42572  2940 ?        S    16:36   0:00 nginx: worker process                                          
root      7962  2.0  0.2  41024  3084 ?        S    19:29   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     7963  0.0  0.2  42732  3060 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7964  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7965  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7966  0.0  0.2  42732  2852 ?        S    19:29   0:00 nginx: worker process 

古いバージョンのワーカーを止める(WINCHシグナル)

WINCHシグナルを古いマスタープロセスに送ります。

$ sudo kill -WINCH 5559

すると、既に受け持っているリクエストの処理が終わり次第、古いワーカープロセスが順次終了していきます。古いプロセスはマスタープロセスだけになり、リクエストは新しいワーカープロセスが受け持っています。

ps aux |grep nginx
root      5559  0.0  0.0  40976  1072 ?        Ss   16:36   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
root      7962  0.0  0.2  41024  3084 ?        S    19:29   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     7963  0.0  0.2  42732  3060 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7964  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7965  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7966  0.0  0.2  42732  2852 ?        S    19:29   0:00 nginx: worker process  

古いバージョンのマスタープロセスを止める(QUITシグナル)

QUITシグナルを古いマスタープロセスに送ります。

$ sudo kill -QUIT 5559

古いマスタープロセスが終了し、新しいマスタープロセスとワーカープロセスだけになりました。

$ ps aux |grep nginx
root      7962  0.0  0.2  41024  3084 ?        S    19:29   0:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx     7963  0.0  0.2  42732  3060 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7964  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7965  0.0  0.2  42732  2860 ?        S    19:29   0:00 nginx: worker process                                          
nginx     7966  0.0  0.2  42732  2852 ?        S    19:29   0:00 nginx: worker process 

検証

検証方法

http_loadを使ってドキュメントルートに置いたテキストファイルをアップグレード作業中にクライアントから毎秒10リクエスト行う。

結果

作業中の2分間、1199リクエストが全て正常に終了したので、問題なくアップグレードができたと思われます。

./http_load -rate 10 -seconds 120  -verbose url_file
--- 60.0062 secs, 600 fetches started, 599 completed, 1 current
--- 120.006 secs, 1200 fetches started, 1199 completed, 1 current
1199 fetches, 1 max parallel, 3597 bytes, in 120.006 seconds
3 mean bytes/connection
9.99115 fetches/sec, 29.9735 bytes/sec
msecs/connect: 0.417418 mean, 0.717 max, 0.248 min
msecs/first-response: 0.353556 mean, 0.605 max, 0.253 min
HTTP response codes:
  code 200 -- 1199
Tagged with:
preload preload preload