2月 07

Osukini Cloudとは

クラウドサービス「Osukini クラウド」|クラウドならSaaSes

Osukini Cloudは日本ラッドが提供するSaas/Paasサービスのブランド「SaaSes」の1商品です。
Cloudと銘打ってはいるものの、サーバーのスナップショットイメージを保存して再利用したり、稼働済みのサーバーのクローンを立ち上げたりする、スケールアウト向けの機能はありません。

簡単に言うと、CPU・メモリ・ハードディスクを動的にスケールアップ・ダウンできる機能が付いたXenベースのVPSサービスです。
仮想サーバーの仕組みをそのままサービスにしたイメージです。

Osukini Cloudの使いどころ

上述のように急激なアクセス増が予想されるスケールアウト必至のサービスには向いていないので、使いどころとしては

  • 当面は低スペックで構わないが後々のアクセス増対応に不安
  • 既存の格安VPSでどのプランで契約していいかわからない

ようなケースが当てはまるかもしれません。

さくらのVPSが価格の割に品質がよく、満足できるVPSサービスだと思いますが、現時点でスペックが固定なので、もう少し高スペックで同様に低価格なサービスを探している方にはOsukini Cloudはおすすめだと思います。

スペックと価格

一般的なVPSサービスのようにプランごとにスペックが決まるのではなく、1プランでスペック変更が可能というところが特徴ですので、最低スペックで始めて運用しながら随時変更することができます。(スケールアップ・ダウンには再起動・サービスダウンが伴うようです。)

料金とスペックをまとめると以下のようになります。(全て月額)

  1CPU+1GB 2CPU+2GB 3CPU+3GB 4CPU+4GB
80GB ¥1,000 ¥2,200 ¥3,800 ¥5,800
160GB ¥1,900 ¥3,100 ¥4,700 ¥6,700
240GB ¥2,800 ¥4,000 ¥5,600 ¥7,600
320GB ¥3,700 ¥4,900 ¥6,500 ¥8,500

CPUとメモリは連動で、4×4の16パターンの料金体系があり、月途中でスペックを変更した場合は、その月で最もハイスペックだった料金が請求される仕組みです。
転送量に対する課金もありませんし、稼働時間に対する課金もありませんので、料金が非常に明確になります。

利用可能なOSは以下の通りです。

  • CentOS ver5.5 32bit
  • CentOS ver5.5 64bit
  • Ubuntu ver10.04 32bit
  • Debian ver5.0(lenny) 32bit
  • Debian ver5.0(lenny) 64bit
  • Debian ver6.0(squeeze) 32bit
  • Debian ver6.0(squeeze) 64bit

実際に使ってみて

現在、4CPU/4GB+80GB(¥5,800)、CentOS5.5 64bitのサーバーを3台契約しています。
ホームページ上では最短5分以内でスタートできると書いてありますが、1台目を契約した際は在庫がないとのことで、サービスの利用開始まで丸1日かかり、2台目・3台目は14、5分でした。必ずしも契約後すぐに利用できるわけではないので、注意が必要です。

参考までに、サーバーの基本的なスペック情報は以下の通りです。

システム情報

$ uname -a
Linux hostname 2.6.18-194.32.1.el5xen #1 SMP Wed Jan 5 18:44:24 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

CPU情報

$ cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 9
model name	: AMD Opteron(tm) Processor 6128
stepping	: 1
cpu MHz		: 2000.154
cache size	: 512 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
bogomips	: 5003.13
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 9
model name	: AMD Opteron(tm) Processor 6128
stepping	: 1
cpu MHz		: 2000.154
cache size	: 512 KB
physical id	: 1
siblings	: 1
core id		: 0
cpu cores	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
bogomips	: 5003.13
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]

processor	: 2
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 9
model name	: AMD Opteron(tm) Processor 6128
stepping	: 1
cpu MHz		: 2000.154
cache size	: 512 KB
physical id	: 2
siblings	: 1
core id		: 0
cpu cores	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
bogomips	: 5003.13
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]

processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 9
model name	: AMD Opteron(tm) Processor 6128
stepping	: 1
cpu MHz		: 2000.154
cache size	: 512 KB
physical id	: 3
siblings	: 1
core id		: 0
cpu cores	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
bogomips	: 5003.13
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc [6] [7] [8]

メモリ情報

$ cat /proc/meminfo
MemTotal:      4194304 kB
MemFree:         67556 kB
Buffers:         59036 kB
Cached:        3588160 kB
SwapCached:          0 kB
Active:        2048284 kB
Inactive:      1838268 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      4194304 kB
LowFree:         67556 kB
SwapTotal:     8393952 kB
SwapFree:      8393880 kB
Dirty:            1064 kB
Writeback:           0 kB
AnonPages:      239332 kB
Mapped:          11304 kB
Slab:           115088 kB
PageTables:       8744 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:  10491104 kB
Committed_AS:   332088 kB
VmallocTotal: 34359738367 kB
VmallocUsed:      4340 kB
VmallocChunk: 34359734027 kB

ディスク性能(Read)

$ sudo hdparm -Tt /dev/xvda3

/dev/xvda3:
 Timing cached reads:   9604 MB in  1.99 seconds = 4818.05 MB/sec
 Timing buffered disk reads:  340 MB in  3.01 seconds = 113.05 MB/sec

ディスク性能(Write)

$ dd if=/dev/zero of=/tmp/test.tmp bs=1M count=256
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 0.63945 seconds, 420 MB/s

$ dd if=/dev/zero of=/tmp/test.tmp bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 2.70829 seconds, 396 MB/s

最後に

運用して1週間程立ちましたが、スペック通り十分なパフォーマンスを安定して発揮してくれています。リプレース元のサーバーでは転送量課金もかかっていたので、だいぶコストを圧縮することが出来ました。

格安VPSではスペックがネックになって利用シーンが限られていたと思いますが、Osukini Cloudはスペックの自由度が高いので、格安VPSと専用サーバーの間の領域を柔軟にカバーしてくれる数少ない優れたVPSサービスだと思います。

Tagged with:
9月 25

セキュリティーの問題がクリアできれば、独自ドメインでメールアドレス(サーバー)を運用するのにGoogle Apps(Gmail)を利用しない理由はないと思います。

無料版であるStandard Editionでは

  • 無料(広告が表示されるだけ) で1アカウント7GBのメールボックスが独自ドメインで作成できる
  • 50アカウントまで作成可能
  • Gmailと同じUI、同等の機能(検索、スパムフィルター、POP/IMAP対応、携帯・iPhone対応など)

といった目に見える特徴と、なんと言ってもサーバーを保守する必要がないという絶大なメリットがあります。

そこで、メールサーバーとしてGoogle Appsを利用する際に行った設定(主にDNS)と、自戒を込めて、アプリケーションサーバーでメールを送信する場合のポイントを書きたいと思います。

Google Apps の導入手順のステップ 4: ユーザー アカウントの作成以降の説明となります。

MXレコードを設定する

利用するドメインを管理しているDNSサーバーにMXレコードを追加します。

MX レコードの設定 – Google Apps ヘルプ
に設定すべきメールサーバーと、プライオリティーが記されているので、この通り設定します。cloudropではxxxxxx@cloudrop.jpというメールアドレスを利用するので、cloudrop.jpに対してMXレコードを以下のように設定しました。

bindの設定ファイル

cloudrop.jp.	900	IN	MX	1 aspmx.l.google.com.
cloudrop.jp.	900	IN	MX	5 alt1.aspmx.l.google.com.
cloudrop.jp.	900	IN	MX	5 alt2.aspmx.l.google.com.
cloudrop.jp.	900	IN	MX	10 aspmx2.googlemail.com.
cloudrop.jp.	900	IN	MX	10 aspmx3.googlemail.com.

上記ヘルプはたびたび更新されていて、参考にしたタイミングによっては載っているプライオリティーの値やサーバーのアドレスが増減していることがあるようです。サーバーのアドレスがいきなり変わることはないと思いますが、リスクを考えてTTLはなるべく少なくして運用します。
メールサーバーの台数を見ても、同じように自前で5台用意して運用するコストを考えると、メリットは歴然ですね。

ちなみに、digコマンドを利用するとメールサーバーにGoogle Appsを利用しているかどうかがわかります。例えば、有名な事例となっている東急ハンズのドメインを引いてみると

dig tokyu-hands.co.jp MX

; <<>> DiG 9.6.0-APPLE-P2 <<>> tokyu-hands.co.jp MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54632
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 3, ADDITIONAL: 5

;; QUESTION SECTION:
;tokyu-hands.co.jp.		IN	MX

;; ANSWER SECTION:
tokyu-hands.co.jp.	900	IN	MX	5 ALT1.ASPMX.L.GOOGLE.COM.
tokyu-hands.co.jp.	900	IN	MX	5 ALT2.ASPMX.L.GOOGLE.COM.
tokyu-hands.co.jp.	900	IN	MX	10 ASPMX2.GOOGLEMAIL.COM.
tokyu-hands.co.jp.	900	IN	MX	10 ASPMX3.GOOGLEMAIL.COM.
tokyu-hands.co.jp.	900	IN	MX	1 ASPMX.L.GOOGLE.COM.

;; AUTHORITY SECTION:
tokyu-hands.co.jp.	900	IN	NS	ns02.tokyu-hands.co.jp.
tokyu-hands.co.jp.	900	IN	NS	dns2.broadcenter.jp.
tokyu-hands.co.jp.	900	IN	NS	ns01.tokyu-hands.co.jp.

;; ADDITIONAL SECTION:
ASPMX.L.GOOGLE.COM.	131	IN	A	209.85.223.23
ALT1.ASPMX.L.GOOGLE.COM. 127	IN	A	209.85.210.80
ALT2.ASPMX.L.GOOGLE.COM. 211	IN	A	74.125.93.114
ASPMX2.GOOGLEMAIL.COM.	858	IN	A	209.85.135.27
ns02.tokyu-hands.co.jp.	900	IN	A	59.84.175.199

と、TTL900でGoogle AppsのMXレコードが5つ設定されているのがわかります。

SPFレコードを設定する

次に、SPFレコードを設定します。
SPFレコードについては、

が詳しいので、ご覧下さい。
この設定をしておくとことで、スパムフィルターに引っかかる確率が下がります。

SPF レコードの設定に詳細が載っていて、DNSのTXTレコードに設定をすれば済むのですが、そのドメイン内で何かしらサービスを動かしている場合、Gmailのサーバー以外からメールを送る可能性があるので、そのサーバーのアドレスも合わせてSPFレコードに登録するべきです。

例えば、Web上から入力されたフォームをinfo宛にメールで飛ばしたり、各サーバーでLogwatchのレポートメールを飛ばしたりする場合です。

cloudrop.jpでは、アプリケーションサーバー(67.23.44.103)も@cloudrop.jpとしてメールを送信するので、以下の設定をしています。

bindの設定ファイル

cloudrop.jp.	600	IN	TXT	"v=spf1 ip4:67.23.44.103 include:aspmx.googlemail.com ~all"

これを設定することで、アプリケーションサーバーが送信するメールのヘッダーが以下のように変ります(Gmailの場合)。

設定前

Received-SPF: neutral (google.com: 67.23.44.103 is neither permitted nor denied by best guess record for domain of example@cloudrop.jp) client-ip=67.23.44.103;
Authentication-Results: mx.google.com; spf=neutral (google.com: 67.23.44.103 is neither permitted nor denied by best guess record for domain of example@cloudrop.jp) smtp.mail=example@cloudrop.jp

設定後

Received-SPF: pass (google.com: domain of example@cloudrop.jp designates 67.23.44.103 as permitted sender) client-ip=67.23.44.103;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of example@cloudrop.jp designates 67.23.44.103 as permitted sender) smtp.mail=example@cloudrop.jp

MTAの設定(Postfix)

後はアプリケーションサーバーのMTAの設定です。
サーバー導入当初、Postfixの設定を間違えてメールが配送されないというミスをしてしまったので、自戒を込めて。

Postfixは受け取ったメールの送信先ドメインが/etc/postfix/main.cfの$mydestinationに設定したドメイン(FQDN)のリストに含まれているかどうかを判定します。含まれていた場合は自分自身のユーザーへ配信、含まれていない場合は該当するサーバーまで配送します。

Google Appsで設定したドメイン宛のメールはGmailのサーバーへ配送しなければいけないので、$mydestinationに含んではいけません。Google Appsに限らずメールゲートウェイでないサーバーでは当たり前の設定なんですが…。

Gmailにrelayするという選択肢

いちいちSPFレコードを追加するのも面倒くさいし、いっそのことGmailのサーバーへrelayしてしまえばいいという考えもあります。Postfixでは設定ファイルに数行追加し、パスワードファイルを作成することで簡単にrelayさせることができます。

Postfixの設定ファイルに追加します。(以下、CentOS5の場合)

> sudo vi /etc/postfix/main.cf

relayhost = [smtp.gmail.com]:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_tls_security_options = noanonymous

設定ファイルで追加したパスワードファイルを作成し、ハッシュ化します。

> sudo vi /etc/postfix/sasl_passwd

[smtp.gmail.com]:587    example@cloudrop.jp:password

> sudo postmap /etc/postfix/sasl_passwd
> sudo /etc/init.d/postfix restart

(ハッシュ化するとsasl_passwd.dbというファイルが生成されます。)

参考サイト

この設定を行うと自サーバーから送信することはなくなるのですが、Gmailの仕様に引っ張られてしまい、使いにくい面が多々あります

まず、送信元がGmailのアカウントに上書きされてしまいます。例えば、example@cloudrop.jpというアドレス所有者としてrelayした場合、envelope fromをinfo@cloudrop.jpで送信したとしても、example@cloudrop.jpに上書きされ送信されてしまいます。アプリケーションや用途によって送信元を変えたいのが普通ですので、この仕様では使いにくいところです。

また、relayしたメールは該当メールアドレスのGmail送信箱に保存されていきます。1ユーザーのアカウントでrelay設定をした場合、システムが送ったものと人間が送ったものが混ざってしまうということです。

逆に、システム専用のアドレスを用意し、そのアドレスでrelayすればGmailの送信箱にメールが残り、検索しやすくなるなどのメリットもありそうですが、そのサーバーが送信するメールの送信元が全てrelayしたユーザーのアドレスになることを前提にシステムを構築しないといけませんし、Gmailで検索するのにシステム専用のアカウントでログインする必要があるなど、やはり使いにくさは否めません。

Gmailのメリットを享受しようとするならば、Gmailの自分宛にCC(BCC)してラベルを付けるなどした方が楽で、残念ながらrelayして活用するメリットはなさそうです。

Tagged with:
9月 12

クラウドのホスティングサービスは、一定リソースの時間極課金+通信トラフィックの従量課金が一般的です。

CPUやメモリなどのリソースは、1%しか使わなくても100%使っても時間内の料金は同じです。
一方で通信料は使った分だけGB単位などで段階的に課金される仕組みです。

この料金体系では、なるべくリソースを使い切って、且つ通信料を抑えることが最も費用対効果のある利用方法となります。

サーバーからクライアントへのレスポンス、特にブラウザーのロードとレンダリングを高速化させるために、Yahoo!のYSlowやGoogleのPage Speedを使ってチューニングを行うのと同じようなアプローチで、なるべくCPUに仕事をさせて、トラフィックを減らしてみたいと思います。

キャッシュ機能を最大限利用する

Expires

Apacheのmod_expiresを有効にすることで、レスポンスヘッダーにExpiresフィールドが出力され、最初のアクセス以降設定した期間が経過するまでブラウザーはローカルのキャッシュを利用し続けます。
この設定は強力で、ローカルのキャッシュがなくなるか、強制リロードをしない限り、サーバーへアクセスすらしません。
(逆に、更新をかける余地のあるファイルには設定しない方がいい項目です。)

LoadModule expires_module     modules/mod_expires.so
ExpiresActive On
ExpiresByType application/javascript "access plus 1 days"
ExpiresByType application/x-javascript "access plus 1 days"
ExpiresByType text/javascript "access plus 1 days"
ExpiresByType text/css "access plus 1 days"
ExpiresByType image/jpeg "access plus 3 days"
ExpiresByType image/png "access plus 3 days"
ExpiresByType image/gif "access plus 3 days"
ExpiresByType image/x-icon "access plus 3 days"

有効期間の設定には以下の単位も利用できます。

  • years
  • months
  • weeks
  • days
  • hours
  • minutes
  • seconds

Last-Modified、Etag

次に、キャッシュが切れていよいよブラウザーがアクセスをしてきた時のための設定を施しておきます。

特段設定をしないとApacheはLast-ModifiedEtagフィールドをセットしたヘッダーを送信します。
この値を受け取っているブラウザーは、Last-Modifiedの値をIf-Modified-Sinceに、Etagの値をIf-None-Matchに含めてリクエストを送信します。
受け取ったサーバーは値を比較して変更が無ければコンテンツの中身は返さず、304 Not Modifiedを応答します。

コンテンツを返さない分トラフィックは抑えられるわけですが、この二つのフィールドはコンテンツを返すか、返さないかを判断するという意味では同じで、解釈の仕様によって動きが変わってきます。

Apacheにおいては、If-Modified-SinceよりもIf-None-Matchが優先されます。
If-Modified-SinceはIf-None-Matchがない場合にだけ利用され、If-Modified-Sinceの値が同じでも、If-None-Matchの値が変更されていた場合には、コンテンツを返します。

これだけ優先されるIf-None-Matchなので、ETagの値を間違ってセットするとサーバーが毎回コンテンツを返してしまいます。
この辺りでよく問題にされるのは、負荷分散環境下で複数のサーバーが同一コンテンツを返しているような場合です。
クラウドのホスティングサービスを選択するようなケースでは、スケールアウトする仕組みが期待されることが多いので、あらかじめ設定しておくべき項目です。

Apacheがデフォルトで出力するETagが「ファイルの inode番号、ファイルサイズ、更新時刻」を元に生成するので、inode番号がサーバーによって変わってしまう環境では、せっかくIf-None-Matchを送っていても受け取るサーバーごとで比較するETagが違い、毎回無駄にコンテンツを返してしまいます。

以下のサイトに解説や実例があります。

これを回避するために、ETag自体を出力しない方法と、ETagの生成にinode番号を利用しないようにする方法と2通りあります。

ETag自体の出力をしない

FileETag None

ETagの生成にinode番号を利用しない

FileETag MTime Size

どちらにせよ、これらの設定では「最終更新日」が重要な要素になってきます。
ETagを出力しない場合はLast-Modified(最終更新日)での判定が有効になり、inode番号を利用しない場合はファイルサイズと最終更新日がベースとなったEtagでの判定になるからです。

最終更新日が全てのサーバーで同じになるように、ファイルをコピーする時、同じタイムスタンプになるように注意してコピーしなければなりません。rsyncであれば-tオプションを付けてコピーします。

ETagを出力しない場合は、内容に変更があったファイルでもタイムスタンプが同じであれば同一ファイルと見なされるリスクがあります。
inode番号を利用しないでETagを出力した場合は、その分リクエスト・レスポンスヘッダーともに微増し、トラフィックに若干影響があります。

トラフィックを抑えることが最優先であれば出力しない、ファイルの管理を厳密に行いたいのであれば出力する、ETagの設定をどちらにするかは状況によって変わってくると思います。
今回の趣旨では、ETagは出力しない方がいいということになります。

コンテンツは基本、圧縮

mod_deflateモジュールを有効にすると、設定に従ってレスポンスをgzipで圧縮して送信してくれます。
Deflateによる圧縮はCPUに働かせ、トラフィックを減らす、クラウド環境にもってこいの設定です。

LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/javascript

Webで利用される画像フォーマットはそもそも圧縮されている場合が多いので、圧縮効率の高いテキストファイルを対象にします。(WordPressの場合、WP Super Cacheを使うことで、記事自体もgzip圧縮して送信できるようになります。)

使える外部リソースを使う

これは番外編です。
RSS、各種APIなどのWebサービスからOpenIDやOAuthなどのリモート認証、Webは外部のリソースと協調する方向へと進んでいますから、利用できるリソースをどんどん活用するのもトラフィック節約になります。
flickrYouTubeなどをホスティング的に利用するのはもちろん、JavaScriptのライブラリはGoogleのAJAX Libraries API、アバターアイコンはGravatarなど、目的に合わせて使える外部リソースを使っていきましょう。

もちろん外部リソースに依存することはリスクでもあるので、いい面ばかりでもありません。1ページに複数ドメインへのリソースがあると、名前解決に時間がかかりページのロードが遅くなるなどの問題もあります。

ご利用は計画的に。

Tagged with:
preload preload preload