CentOS5.5のISOを落としてDVD化

ISOはこちらから落としました。
http://ftp.riken.jp/Linux/centos/5.5/isos/i386/CentOS-5.5-i386-bin-DVD.iso

DVDでブートして上書きインストール

ブートして通常通りインストールを進めていくと、インストーラーが既存のOSをチェックして「CentOS4.8に上書き」 or「再インストール」とたずねてくるので、上書きを指示します。

その後、DVDからハードディスクへファイルのコピーが始まります。コピーするファイル数、合計のバイト数、その途中経過を表示しながら進んでいきます。

トラブル1「インストール途中で止まる」

残り40ファイル、50MBくらいあるファイルをコピーした直後、インストーラーがフリーズしてしまいました。この時点で上書きされたファイルとそうでないファイルが同居しているという気持ち悪い状況でしたが、迷わずCtrl+Alt+Delで強制再起動。
再度DVDブートして進めていくと、ちゃんと途中から始まりました。賢いインストーラーです。
（途中で上書き or 再インストール？の質問時にラベルが「CentOS5.5」になってしまっていましたが、ここも上書きを選びます。）

トラブル2「Grubで止まる」

無事インストールが終わって、DVDを取り出して再起動すると、「GRUB loading stage 2 」とGRUBのところでストップ。
どうもブートローダーが正しく上書きされなかったようです。再度DVDを入れDVDブートします。
起動コマンド入力プロンプトで「linux rescue <enter>」と入れてレスキューモードに入り、シェルのプロンプトが表示されたら、

chroot /mnt/sysimage
grub-install /dev/sda

とGRUBを再インストールします。インストール先のデバイス（/dev/sdaの部分）は環境によって変わるのでdfコマンドなどで確認します。

無事起動

DVDを取り出して再起動すると、無事起動しました。
ところが、

トラブル3「yumがエラーで起動しない」

yumを実行すると、

There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   No module named sqlite

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.4.3 (#1, Sep  3 2009, 15:37:12)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)]

If you cannot solve this problem yourself, please go to
the yum faq at:

http://wiki.linux.duke.edu/YumFaq

とエラーが表示されて起動できません。

python-sqliteはすでにインストールされているのですが、このエラーが表示されます。

yumが使えないのでrpmファイルを落としてきて、強制的に上書きします。

wget http://mirror.centos.org/centos-5/5.5/os/i386/CentOS/python-sqlite-1.1.7-1.2.1.i386.rpm
rpm -Uvh python-sqlite-1.1.7-1.2.1.i386.rpm --force

（–forceを付けないとすでにインストールされている！と取り合ってくれません。）

yumでアップデート

4系から5系にアップデートしたので不具合が起こらないようにyumのキャッシュを消してからアップデートします。

sudo yum clean all
sudo yum update

以上で、現在も正常に動いています。

#Apache
sudo yum install httpd.x86_64

#PHPのコンパイルに必要（パラメータによる）
sudo yum install httpd-devel.x86_64
sudo yum install libxml2-devel.x86_64
sudo yum install openssl-devel.x86_64
sudo yum install curl-devel.x86_64

#最新版PHP取得→コンパイル→インストール
wget http://ve2.php.net/get/php-5.3.3.tar.gz/from/jp2.php.net/mirror
tar vfxz php-5.3.3.tar.gz
cd php-5.3.3
./configure \
--enable-mbstring \
--with-apxs2=/usr/sbin/apxs \
--with-curl \
--with-openssl \
--with-config-file-path=/etc  \
--enable-dom \
--with-libdir=lib64
meke
sudo make install

#symfonyのインストール
sudo pear channel-discover pear.symfony-project.com
sudo pear install symfony/symfony

#PHP拡張のインストール
sudo pecl install apc
sudo pecl install mongo

#PHP拡張の反映
sudo vi /etc/php.ini

extension = mongo.so
extension = apc.so
apc.enabled=1

PHPもRemiのリポジトリを利用すると簡単に最新版がインストールできますが、cli版がバックグラウンドで実行できない不具合があるのでソース版を利用しました。

参考

• CentOS 5.2上でPHP 5.2.6にアップグレード
• CentOS 5.3 に php-5.2.9, mysql-5.1.35 をインストール(remi レポジットリより)

MongoDBをインストール

下記URLを参考にMongoDBのリポジトリを設定してインストールします。
参考：CentOS and Fedora Packages

sudo vi /etc/yum.repos.d/10gen.repo 

[10gen]
name=10gen Repository
baseurl=http://downloads.mongodb.org/distros/centos/5.4/os/x86_64/
gpgcheck=0

sudo yum install mongo-stable* --enablerepo=10gen

最新のstableバージョン1.6.1がインストールされます（2010年8月19日現在）。デフォルトの設定は以下の通りです。
設定ファイル：/etc/mongod.conf
ログファイル：/var/log/mongo/mongod.log
データディレクトリ：/var/lib/mongo/

起動は起動スクリプトでOK

sudo /etc/init.d/mongod start

1. はじめに
2. さくらのVPS
3. Twitter Streaming API
4. MongoDB
5. 使い方

はじめに

さくらのVPSをベータ*1として使わせてもらっているのに何もしないのはもったいない＆申し訳ないので、Twitter Client Ranking by Streaming APIというのを、さくらのVPSのパフォーマンスとMongoDBのパフォーマンス・使用感をテーマに実験的に作ってみました。

TwitterのStreaming APIからツイートを取得、保存、解析してどんなクライアントが使われているかをランキング形式に表示するという単純なものです。

解析結果をブログで公開している例があるものの、なかなか直近で連続的なデータを公開しているところがなかったので、勢いで作りました。

さくらのVPS

さくらのVPSの仕様は以下の通りです。

データを継続的に保存するのにHDDが20GBと心許ないので古くなったデータはどんどん削除していく必要がありそうです。一方でデータ転送量が無制限となっているので、APIからの取得に（料金的な意味で）気を使う必要はなさそうです。
OSは最新のCentOS5.5で、サービスはsendmailとssh以外は何も入っていないので、httpdなどを自由に追加して利用します。また、ポートはすべて公開状態なのでiptablesを設定、有効にすることも必要です。

Twitter Streaming API

Twitter Streaming APIのstatuses/sampleメソッドを利用します。sampleメソッドは公開タイムラインの1%未満がサンプリングされたデータとなります。実際にアクセスをしてみると1分間に350〜650ツイート取得でき、量にかなりムラがあることがわかりました。
HDDの容量を考えて、データはcronで6分毎に1分間取得することにしたので、サンプルは1/6%、全ツイートの約0.167%未満になりそうです。数日間取得してみたところ、1日で約10万〜12万ツイートをサンプリングできています。

MongoDB

MongoDBはドキュメント指向DBと呼ばれる仲間で、Key-Value StoreにRDBMSの色を少し足したようなイメージです。スキーマはダイナミックに変更できる一方で、SQLこそ使えないものの、where, sort, limit, group(by), max, min,などが用意されていて、RDBMSに慣れている人にもとっつきやすいと思います。
さらに、スケールアウトを容易にするSharding機能を標準装備していて、分散したデータベースから複雑な集計ができるMap/Reduceが利用できます。

RDBMSでDBやテーブルにデータを入れようと思った時はあらかじめCREATEしておく必要がありますが、MongoDBは必要ないので存在しないDBやコレクション（RDBMSでいうテーブル）にいきなりデータを投入してもエラーは出ず、コレクションやDBすらダイナミックに作られます。この辺りの挙動はファイル操作に近いので、日付ごとにダイナミックにコレクションを作ることもでき、今回のログの保管などの用途にも適しています。

日付ごとにコレクションを作り、値にはtimestamp, date, source, source_url, time_zone, utc_offset, langを保存することにしました。Sharding環境ではないのでMap/Reduceの力を発揮することもできないのですが、実験的な意味で、データの集計にはMap/Reduce*2を利用しています。

使い方

デフォルトは1日前のサンプリングしたすべてのデータが表示されます。そこから、日付、Lang、Time zone、UTC offsetで絞り込みすることで様々な形で抽出することができます。
例えば、「8月12日のツイートの中から東京（time_zone=Tokyo）で日本語（lang=ja）のツイートをするのに利用されているクライアント」などを抽出・集計することができます。

ランキングだけでは味気ないので、TOP10を円グラフで表すのと、各クライアントが時間ごとにどのくらい利用されているのか3つまで比較出来る機能を用意してみました。住んでいるところやクライアントの種類で利用されている時間外が全然違うのがわかります。

現状、なかなかもっさりとした感じなので、イライラするかもしれません。
実験なので、負荷の問題でサービスを終了するかもしれませんし、逆に、作っただけではなくMongoDBのTipsやチューニングなどで改善し、それをさらにネタにして行きたいとも思っています。

*1 7月15日〜8月31日までクローズドベータとして会員限定でプレリリースされたホスティングサービス。2010年9月1日から初期費用無料、月額980円の「さくらのVPS 980」として正式リリースされる。

*2 今回の実験ではmapReduce()よりgroup()を使った集計の方が速度が速いことが多かったので、当日分のリアルタイム集計ではgroup()を利用しています。mapReduce()の結果は新しくコレクションとして保存することができるので、過去分に関してはmapReduce()で抽出→コレクションとして保存→そこから再集計という実装にしています。

config/databases.yml

all:
  master:
    class: sfDoctrineDatabase
    param:
      dsn:      mysql:host=localhost;dbname=test
      username: root
      password:
      attributes:
        default_table_charset: utf8
        default_table_collate: utf8_general_ci

config/doctrine/schema.yml

Users:
  connection: master
  tableName: users
  actAs:
    Timestampable: ~
  options:
    collation: utf8_general_ci
    charset: utf8
    type: INNODB
  columns:
    id:
      type: integer(4)
      primary: true
      unsigned: true
      autoincrement: true
    name:
      type: string(255)
      notnull: true

cloudrop発のアウトプットとして開発に取り組んだもので、初めてのリリースとなります。
タイトルにはsymfonyと書きましたが、開発には数多くのオープソースソフトウェアのお世話になっています。

できる事ならyubitterもソースを公開したいのですが、利用しているライブラリのライセンスの確認、環境依存部分の抽象化、symfony1.4系への対応、ドイヒーなコードの修正などを行う必要があり、今は難しいところです。
最終的にはそういう諸々を乗り越えての公開を目指して行きたいと思っています。

事実上のモバイル向けクライアントの標準であるモバツイッターや、多機能でアジャイルなMovatter、さらには公式の携帯版がある中で、いまさら感の否めないサービスですから、サービス自体による貢献というよりも、サービスやシステムの内部を公開することによる貢献を目指していくつもりです。

そういう意味でも、開発・運用をするにあたっての裏話はどんどん公開していきたいと思います。

もちろん、魅力のないサービスは、システムとしても魅力がないのと同じなので、
サービスとしておざなりにするということではありません。

サービスに関する質問や不具合の報告などは、Twitterで受け付けております。
お気軽にお問い合わせください。（@ms76）

最後に、利用させていただいているサービスやソフトウェアを紹介いたします。（順不同）
この場を借りて、感謝いたします。ありがとうございます。

インフラ

Rackspace Cloud Servers

Webサーバー、アプリケーションサーバー、DBサーバー、セッションサーバーとして利用。

• Cloud Servers – Powerful Cloud Computing Servers by Rackspace

Amazon S3

メールによる写真アップロードを受け取るストレージサーバーとして利用。

• Amazon Simple Storage Service (Amazon S3)

Amazon CloudFront

ストレージサーバーのフロントエンドとして利用。

• Amazon CloudFront

OS・サーバー・ミドルウェア

CentOS 5.3

Rackspace Cloud Serversにて標準で選択できるOSを利用。

• www.centos.org – The Community ENTerprise Operating System

Apache 2.2.13、PHP 5.3.0

Webサーバー、アプリケーションサーバー（mod_php）として利用。

• Welcome! – The Apache HTTP Server Project
• PHP: Hypertext Preprocessor

MySQL 5.0.77

DBサーバーとして認証用ユーザー情報、設定情報などの保存に利用。

• MySQL :: The world’s most popular open source database

Squid 2.6.STABLE21

外部API接続時のプロキシキャッシュサーバーとして利用。

• squid : Optimising Web Delivery

Postfix 2.3.3

メール投稿、メール登録、メール送信時のメールサーバーとして利用。

• The Postfix Home Page

flare 1.0.8

セッションサーバーとして利用。

• Flare – GREE Labs

PHP、PEARライブラリ

symfony 1.2.10

Webフレームワークとして利用。

• symfony | Web PHP Framework

携帯向けに下記プラグインを利用。

• sfMobileIPPlugin
• sfPictogramMobilePlugin

Mail_Mime 1.5.2、Mail_mimeDecode 1.5.1

受信したメールの処理に利用。

• Mail_Mime
• Mail_mimeDecode

Net_IPv4 1.3.1

IPアドレスが特定のネットワークアドレスの範囲にあるかどうかの計算に利用。

• Net_IPv4

Net_UserAgent_Mobile 1.0.0

携帯電話のUser Agentの取得に利用。

• Net_UserAgent_Mobile

Amazon S3 PHP class 0.4.0

Amazon S3 APIとの通信に利用。

• amazon-s3-php-class – Project Hosting on Google Code

qdmail 1.2.6b

メール送信に利用。

• PHP高機能日本語メール送信ライブラリ・文字化けフリー – Qdmail – PHP::Mail Library , Quick and Detailed for Multibyte

TwitterOAuth library

Twitter APIのOAuth認証に利用。

• Twitter-OAuth-PHP

QRcode image PHP scripts version 0.50g

QRコード生成に利用。

• ＱＲコード CGI & PHP scripts – QRcode generator for perl & php

HTML_CSS_Mobile

外部CSSをインラインCSSに変換する際に利用。

• HTML_CSS_Mobile – Openpear

1. アクセス解析の実態
2. Google Analyticsで測る
3. 内部アクセスの排除
   1. フィルタ マネージャを設定する
   2. IPアドレスで除外する
   3. クッキーで除外する
   4. 番外編：Apacheのアクセスログで応用する

アクセス解析の実態

ネット業界では、ページビュー数（以下PV）やユニークユーザー数が企業やサービスの指標にされる一方で、そのアクセスを計測する方法が業界内で統一されておらず、ロボットやRSSへのアクセスもPVに加える上場企業があったり、酷いところでは画像やCSSのロード（アクセス）までをもPVに加えて水増し、バリューがあるかのように見せかけてるケースもあります（気をつけて！）。

Google Analyticsで測る

そんな中、Google Analyticsは導入が簡単・高性能、しかも無料ということでPCサイトのアクセス解析ではもはや業界標準になっていると思います。多くの人が使っているということは、例え計測方法がブラックボックスだったとしても「Google Analyticsで計測した値」同士を比較することで、相対的な数字として信頼のできる結果を導くことができます。

内部アクセスの排除

ところが、簡単に導入できる反面Google Analyticsでも設定を行わないと正確な値を取ることができません。それは、自分たちの内部アクセスを排除する設定です。

設定を知らないのか、少しでもPVを稼ぎたいのか、内部アクセスを含めてしまっているケースを多々見かけるので、啓蒙を兼ねて設定方法を書きたいと思います。

正しい戦略は正しい数字から。正しい数字は正しい設定から。

参考サイト

• 社内からのアクセスを除外するにはどうすればよいですか？ – Analytics ヘルプ

上記参考サイトの通りなのですが、ヘルプなのに全然優しくないのがGoogleっぽいです。

フィルタ マネージャを設定する

Google Analyticsで解析方法をカスタマイズするには、フィルタ マネージャでフィルタを設定します。トップページ右下の「フィルタ マネージャ」をクリックします。（クリックで拡大）

次に「フィルタを追加」をクリックします。（クリックで拡大）

以下、順次フィルタ追加画面でフィルタを設定していきます。

IPアドレスで除外する

社内からなどの内部アクセス元のIPアドレスが固定の場合や、開発環境・テスト環境のアクセス元IP
アドレスがあらかじめ分かっている場合に設定しておく方法です。

既定のフィルタ ＞ IPアドレスからのトラフィック を設定します（クリックで拡大）

上の設定画面ではIPアドレスをサブネットマスクなどを使って範囲で指定することができないので、その場合はカスタムフィルタ（ユーザーのIPアドレス）を使って正規表現で頑張る必要があります。

例えばアクセス元のIPアドレスが192.168.0.0/24だった場合は、
^192\.168\.0\.([1-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-4]))$
となります。

この正規表現を生成してくれるツールはGoogleのヘルプにあるので、それを利用しましょう。

• IP アドレスの範囲を指定して、そこからのトラフィックを除外するにはどうしたらよいですか？

カスタムフィルタ ＞ ユーザーのIPアドレス を設定します（クリックで拡大）

開発環境やテスト環境でのアクセスを除外する方法は、IPアドレス以外にもドメイン名でルールを決めたり（テスト環境のホスト名にはtest.example.comなどのように必ずtest.を付けるとか）、アプリケーション内でGoogle Analyticsコードを出力しないようにプログラマーが頑張ったりする方法もありますが、Google Analyticsを管理する部門と開発部門が同じとも限りませんし、変更が少なく管理が分離しやすいアクセス元IPアドレスで処理する方法がいいと思います。

クッキーで除外する

これは管理が煩雑でお勧めはできません。
アクセス元IPアドレスで除外しきれいないアクセス数が全体から見て無視できる程少なければ、IP
アドレスだけでいいと思います。

完璧主義の人や、出先の無線LANスポットやイーモバイル、iPhoneなどから無視できない程頻繁に中の人がアクセスする場合は、クッキーを利用して除外します。

原理としては、除外したいクライアント（ブラウザー）に目印となる保存期間の長いクッキーを送信しておき、そのクッキーを持っているクライアントからアクセスがあった場合に除外をします。

まず目印となるキーワードを「ユーザー定義」というフィールドに設定しておきます。ここではキーワードを「self_access」としておきます。（クリックで拡大）

次にクッキーを送信する方法を用意します。

Googleのヘルプには、

<body onLoad="javascript:pageTracker._setVar('self_access');">

とbodyタグにJavascriptを埋め込んだコードを書き、除外対象と同じドメインにアップロードしてアクセスするように説明があります。

要は解析用のコードで実行している_gat._getTracker()で取り出したオブジェクト「pageTracker」内の_setVar()にキーワードを渡して実行すると、setCookie()が実行される仕組みです。
ちなみにこのクッキーは「__utmv」という名前で2年間の有効期限で発行されます。

管理が大変だというのは、除外対象のドメインごとにクッキーを発行する仕組みを用意して、さらにクライアントにアクセスさせないといけないというところです。

実践しようしたら、中の人が必ずアクセスする管理ページなどにiframeで除外対象の各ドメインにおいてあるクッキーを発行するURLを読み込ませるなどの力技になってしまいそうです。

間違って一般のユーザーがアクセスできるページでこのクッキーを発行してしまうと、アクセス数がゼロになるので慎重に。

番外編：Apacheのアクセスログで応用する

アクセス元IPアドレスやクッキーで解析結果から除外する方法は、Apacheのアクセスログにも応用できます。

この設定をすることで、access_logには内部アクセスのログは書き込まれず、内部アクセスのログはlocal_access_logへ書き出されるようになります。

# 必要なモジュール
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule log_config_module modules/mod_log_config.so

<IfModule setenvif_module>
    # アクセス元IPアドレスで判断
    SetEnvIf Remote_Addr 127.0.0.1 local_log no_log
    SetEnvIf Remote_Addr 192.168.0. local_log no_log

    # Google Analyticsで設定したCookieで判断
    SetEnvIf Cookie "__utmv=[0-9]+\.self_access" local_log no_log

    # （番外）ロボット系もこの程度の設定でだいぶ省けるんですけどね
    SetEnvIf User-Agent "[bB]ot" no_log
    SetEnvIf User-Agent "[sS]pider" no_log
    SetEnvIf User-Agent "[cC]rawler" no_log
    SetEnvIf User-Agent "[rR][sS][sS]" no_log
    SetEnvIf User-Agent "[fF]eed" no_log
</IfModule>

<IfModule log_config_module>
    CustomLog logs/access_log combined env=!no_log
    CustomLog logs/local_access_log combined env=local_log
</IfModule>

サーバーのログを見ることが多い方はこっちの方が効果です。

無料版である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レコードが５つ設定されているのがわかります。

SPFレコードを設定する

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

• Sender ID：送信者側の設定作業 − ＠IT

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

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というファイルが生成されます。）

参考サイト

• Postfix から Gmail 経由でメールを送る linux.matchy.net: 〜Linuxで遊ぼう！〜

この設定を行うと自サーバーから送信することはなくなるのですが、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して活用するメリットはなさそうです。

これを解消するために、最近Googleによって開発・公開された新しいプロトコルPubSubHubbubに対応させました。

PubSubHubbubとは

PubSubHubbubは、今までの配信者（Publishers。以下、ブログ）と購読者（Subscribers。以下、RSSリーダー）が直接やり取りをしていたその間に、ハブ（Hubs）と呼ばれる中間サーバーを配置して、そのハブを介してメッセージのやり取りをWeb Hooksの仕組みで行うものです。
Web Hooksはある決められたアクション（たとえば、「ブログの公開ボタンを押す」など）をきっかけに動作して、決められたデータを決められたURLに決められた方法で送信する仕組みです。

いままで「更新されました？」「いや、まだです。」と304の繰り返しだったフィードの世界に、「更新したしました」きっかけで、購読者に一斉に通知が行くわけですから、こんなエコな仕組みはないと思います。

WordPressで対応するには

簡単です。プラグインを入れるだけです。
現在PubSubHubbubに対応させるためのプラグインは2つ出ていて、どちらも最新の2.8.4に対応していますし、機能的には同じですので好みで導入しましょう。

• PubSubHubbub
• WP Pubsubhubbub

ハブのURLを登録するだけの簡単な設定画面で、しかもすでに2つのハブが登録されているので特に設定することはありません。

プラグインを有効にすると、出力されたAtomに
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com"/>
<atom:link rel="hub" href="http://superfeedr.com/hubbub"/>
とハブへのリンクが追加されます。

ここから以下の流れで更新の通知がされるようになります。

1. この新しいフィードを取得したPubSubHubbubに対応したRSSリーダーがハブへのリンクを読み取って、ハブに購読の依頼を行います。
2. ハブは本当にRSSリーダーが依頼してきたのか確認します。確認ができたら次回の更新から通知するように動作します。
3. WordPressで新しく記事が公開されたタイミングで、プラグインがハブに対して公開の通知を送信します。
4. ハブは本当に記事が公開されたのか確認します。確認ができたら購読の依頼があったRSSリーダーへ通知を行います。

PubSubHubbubの実力

実際に前回の投稿がどのようになったかを追ってみました。

まず投稿後、ハブからチェックがきます（apacheのログ）。

64.233.172.18 - - [12/Sep/2009:18:42:23 +0900] "GET /feed HTTP/1.1" 200 14246 "-" "AppEngine-Google; (+http://code.google.com/appengine; appid pubsubhubbub)"

ハブのデバッグツールでハブにどのように登録されているか確認してみると、

無事登録されているようです。（クリックで拡大）

ではFriendFeedの方はというと、

WordPressの投稿ボタンを押して、登録が終わってから一拍おいてすぐ画面に現れたくらいの感覚です。

さて、本題のTwitterは

素晴らしい！画面の更新タイミングに影響していますがが、ほぼリアルタイム。

その他のPubSubHubbub対応サービス

FriendFeed以外にも、Google ReaderやGoogle Alerts、livedoor Readerなどが対応していて、確認できるGoogle Readerとlivedoor Readerでも確認してみました。

Google Reader

PubSubHubbubへの対応という記事は共有機能からということだったので、対応していないかもしれないと思ったんですが、

時差なしできっちり更新に上がってきました。（クリックで拡大）

livedoor Reader

こちらは更新がされず…。

PubSubHubbub対応後にlivedoor Readerのクローラが来ていることは確認しているので、腑に落ちないところです。

(※ 最初の更新でLDRがそのブログのpubsubhubbub対応を検出し，次の更新から更新情報を受けるようになるので，二回目の更新から反映が最速になります。)
PubSubHubbub で最速に更新を通知しつつ，舌をかまないためのテスト ： nabokov7; rehash – livedoor Blog

ということなので、この更新から反映されるようになるかもしれません。
今回は確認できず。

2009/9/15 追記
やはりlivedoor Readerではすぐに更新されませんでした。
時間が経ってからの更新だとクロールによる更新なのか、ハブからの通知によるものなのか判断できないので、やはり確認できず。
livedoor Readerでちゃんとリアルタイムで更新されてるというパブリッシャーはいらっしゃるんでしょうか。livedoor Blog以外で。
ざっと調べてみたところ実践している方はいらっしゃいましたが、やはりリアルタイムでの更新は確認できていないようです。

• 昨日のPubSubHubbub記事がどのように反映されたか – blog.nomadscafe.jp

わかりにくいPubSubHubbub

読み方の話ではなく。
複数の要素が絡まっているため、仕様が明らかとは言え、ブログ側からするとハブやRSSリーダーの挙動がわからず、更新が通知されない場合に理由がわかりにくい側面があります。

例えば、ハブへ購読依頼をするRSSリーダーが、エントリーが更新されているかどうかにかかわらず、フィード内にハブへのリンクを検出したらハブへ購読依頼をする仕様なのか（FriendFeedはこちらのようです）、エントリーが更新されたタイミングで検出・通知する仕様なのか（livedoor Readerはこちらのようです）、などです。

FriendFeedは前者のようなので、PubSubHubbub対応を行った後に、1度フィードを手動で読み込ませれば次のポストから反映されるはずです。

まだまだ新しい仕組みなので、確立されるまでもう少し時間がかかるかもしれませんが、多くのサービスが対応してさらに便利になることを望みます。

参考サイト

FriendFeed→Twitterの詳しい説明が載っています。

• ブログの更新情報は『Friendfeed』で流すことにした – IDEA*IDEA ～ 百式管理人のライフハックブログ

PubSubHubbubに関する参考サイト

• pubsubhubbub – Project Hosting on Google Code
• ウノウラボ Unoh Labs: PubSubHubbubとは
• 自宅でPubsubhubbubのPub,Sub,Hub一式を動かしてみた – 今日もスミマセン。
• PubSubHubBubのpubに対応する : ryo.com
]]> http://cloudrop.jp/wordpress/pubsubhubbub_twitter/feed 1 http://cloudrop.jp/cloud/apache_setting?utm_source=rss&utm_medium=rss&utm_campaign=apache_setting http://cloudrop.jp/cloud/apache_setting#comments Sat, 12 Sep 2009 09:42:22 +0000 sekine http://cloudrop.jp/?p=177 クラウドのホスティングサービスは、一定リソースの時間極課金＋通信トラフィックの従量課金が一般的です。

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

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

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

1. キャッシュ機能を最大限利用する
   1. Expires
   2. Last-Modified、Etag
2. コンテンツは基本、圧縮
3. 使える外部リソースを使う

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

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-ModifiedとEtagフィールドをセットしたヘッダーを送信します。
この値を受け取っているブラウザーは、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が違い、毎回無駄にコンテンツを返してしまいます。

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

• 堀愚霊瑠の指摘で気付いた、はてなスターの静的ファイルとか想像以上にアレな件 – にぽたん研究所
• Webサイトの高速化 ルール13　ETagを正しく設定する! (Yahoo! developer netoworkより翻訳) | 株式会社インターオフィス | インターオフィス
• DSAS開発者の部屋:負荷分散環境でブラウザキャッシュが効かないときは – 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は外部のリソースと協調する方向へと進んでいますから、利用できるリソースをどんどん活用するのもトラフィック節約になります。
flickrやYouTubeなどをホスティング的に利用するのはもちろん、JavaScriptのライブラリはGoogleのAJAX Libraries API、アバターアイコンはGravatarなど、目的に合わせて使える外部リソースを使っていきましょう。

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

ご利用は計画的に。

]]> http://cloudrop.jp/cloud/apache_setting/feed 0 http://cloudrop.jp/cloud/rackspace_vs_ec2?utm_source=rss&utm_medium=rss&utm_campaign=rackspace_vs_ec2 http://cloudrop.jp/cloud/rackspace_vs_ec2#comments Tue, 08 Sep 2009 16:32:29 +0000 sekine http://cloudrop.jp/?p=135 このサイトは（本日現在）、Rackspace US社の「Cloud Servers」サービス上で
稼働しています。

Cloud ServersはAmazon EC2相当のサービスで、Slicehostなどを買収したRackspaceが運営するXenベースのホスティングサービスです。

EC2ではなくCloud Serversを選んだ理由を、使用感を元にレポートしたいと思います。

目次

1. 安い（=スペックの選択肢が多い）
2. 自動バックアップサービスが無料
   1. 2009/9/12 追記
3. スケールアップ、スケールダウンが簡単
4. DNSが無料、しかも逆引きにも対応
5. その他、補足
   1. 帯域の料金
   2. 回線の応答速度
   3. セキュリティー
   4. 参考

安い（=スペックの選択肢が多い）

もうこれに尽きます。

EC2はスモールインスタンスが$0.1/時間で、これ以下のラインナップがありません。
メモリ1.7GB/ディスク160GBのスペックがオーバースペックだとしても、
選ばなければなりません。

1ヶ月（720時間換算）利用すると$72となり、サーバーの能力を生かしきれない場合どうしても割高な印象になってしまいます。

以下にEC2とCloud Serversのスペックと料金を表にまとめました。
ディスク容量やCPU数なども含め同じスペックとは言えないので
あくまで参考としてご覧ください。青文字の行がEC2の標準的なインスタンスです。

メモリ	ディスク	論理CPU数	アーキテクチャ	料金/時間	備考
256MB	10GB	-	64bit	$0.015	Cloud Servers
512MB	20GB	-	64bit	$0.030	Cloud Servers
1GB	40GB	-	64bit	$0.060	Cloud Servers
1.7GB	160GB	1	32bit	$0.100	EC2(Small)
2GB	80GB	-	64bit	$0.120	Cloud Servers
4GB	160GB	-	64bit	$0.240	Cloud Servers
7.5GB	850GB	4	64bit	$0.400	EC2(Large)
8GB	320GB	-	64bit	$0.480	Cloud Servers
15GB	1690GB	8	64bit	$0.800	EC2(Extra Large)
15GB	620GB	-	64bit	$0.960	Cloud Servers

Cloud Serversは、メモリ256MB/ディスク10GBのインスタンスから用意されていて、
このミニマムのインスタンスが$0.015/時間で借りることができます。1ヶ月利用で$10.8。
256MB以上のインスタンス、例えばメモリ1GB/ディスク40GBのインスタンスでも$0.06/時間。

ディスク容量がネックになる用途以外では魅力的なラインナップではないでしょうか。

特にテスト機や実験機として一時的に利用したいようなケースでは、ロースペック・ローコストはとても助かります。

自動バックアップサービスが無料

バックアップと言ってもデータ自体のバックアップではなく､LVMのスナップショットベースのバックアップになります。
ファイルを個別に取り出すことはできませんが、データを復元する上では全く問題ありません。

このスナップショットがインスタンスごとに3つまでストックできるようになっていて、Web管理ツールから日次/週次でスケジューリングすることが（しないことも）できます。

日次バックアップは「daily」、週次は「weekly」という名前が自動的につけられ、バックアップが実行される度に上書きされていきます。つまり、日次と週次の両方をセットしてもバックアップの枠が1つ余るようになっています。

実は任意のタイミング、任意の名前でもスナップショットがとれ、なおかつスナップショットから新たなインスタンスをつくる（クローンをつくる）こともできるので、EC2で言うところのAMIと同じ用途でバックアップサービスが利用できるわけです。しかも無料で！

現在はミニマムのメモリ256MBのインスタンスから、512MB、1GB、2GBまでのインスタンスがバックアップに対応していて、今後全てのインスタンスに対応する予定だそうです。
EC2と比較してディスク容量が少ないのはこういうところにあるかもしれません。

さらに、Amazon S3相当のサービスであるRackspace Cloud Filesにバックアップイメージを無料で転送できるようにもなるようです。
これが利用可能になって、Xenのゲストイメージが出し入れできるようになれば、例えば自社サーバーのXen環境をそのままクラウドに移したり、逆に戻したり、インフラに縛られることなく簡単にサービス環境を移すことができるようになりそうです。

2009/9/12 追記

重要なことを書き忘れたので追記します。
バックアップはインスタンスに結びついているものなので、インスタンスを削除すると消えてしまいます（インスタンスを停止するという操作はありません）。
つまり、EC2のようにインスタンスをイメージ化して保存することが現時点でできないため、インスタンスのクローンを作成しようとすると、インスタンスを立ち上げ続けておかなければなりません。
バックアップの保存が待ち望まれます。

スケールアップ、スケールダウンが簡単

EC2で、サービス稼働中のスモールインスタンスをラージインスタンスにスケールアップさせようとしたら、別途ラージインスタンスを立ち上げて、そこに環境を乗せ変える必要があります。
稼働中のスモールインスタンスのAMIを生成して、そのAMIからラージインスタンスを立ち上げる方法ができそうですが、これはアーキテクチャ(i386/x86_64)が違うためできません。
できたとしても、どちらも別途インスタンスを用意する必要があります。

Cloud Serversのアーキテクチャは全てx86_64なので、ミニマムからマックスまで自在にリサイズ可能です。
インスタンスのリサイズはWeb管理ツール上でほぼ自動でできます。

それでもダウンタイムが発生するので、それが許容できない場合はスナップショットから別途インスタンスを立ち上げる方法もあります。ただし、EC2のElastic IP相当の機能はないので、IPアドレスが変わることを考慮する必要があります。

DNSが無料、しかも逆引きにも対応

EC2ではサポートされていないので、外部にDNSサーバーを用意する必要があります。

Cloud ServersではWeb管理ツールでDNSレコードが登録できます。
dns1.stabletransit.comとdns2.stabletransit.comをレジストラーに登録すれば、このDNSサーバーが利用できるようになりますので、別途DNSサーバーを用意する必要は（とりあえず）ありません。
ライトユーザー向けのサービスかもしれませんが、嬉しいサービスです。

それからIPアドレスからドメイン名を引く「逆引き」をした場合に返すドメイン名の変更にも対応しています。

あまり関係ないかもしれませんが、スパム対策でメールサーバーなどが逆引きをしてドメイン名を確認する場合などがありますので、そういうケースにも安心して利用できます。

その他、補足

帯域の料金

	IN	OUT
EC2	$0.10	$0.17
Cloud Servers	$0.08	$0.22

帯域の料金は、サーバーからみてダウンロードはCloud Serverの方が安いんですが、アップロードはEC2の方が安くなっています。
EC2のように利用量によって単価がさがるプランもないので、動画配信やストリーミングなどの用途では高くつく可能性があるので注意が必要です。

回線の応答速度

気になる回線の応答速度は、同時刻にそれぞれのサーバーから日本のサーバーへpingを飛ばした平均で、EC2が193.592ms、Cloud Serverが152.008ms でした。体感としては同じで、日本からだと遅く感じるのは否めません。

セキュリティー

EC2の場合はSecurity Groupを設定することでサーバーより前でポートを閉じることができますが、Cloud Serversには用意されていません。
インスタンスがDMZに展開されますので、iptablesなどでしっかり対策する必要があります。
ちなみにCentOS5.3で起動した直後はiptablesによって22ポート以外は閉じられていました。

セキュリティーがらみで気になったのは、インスタンスのrootパスワードの発行です。
EC2ではあらかじめ用意した鍵をセキュアな通信で送信し、その鍵を使ってログインする仕様ですが、Cloud ServersではSSL通信のWeb管理ツール上にrootパスワードとIPアドレスが表示されるだけではなく、メールでも同じ内容が送られてきます。これには頭を抱えてしまいました。
自動発行されたrootパスワードはログイン後即効変更しましょう。

参考

http://www.rackspacecloud.com/cloud_hosting_products/servers/compare
http://aws.amazon.com/ec2/
http://www.rackspacecloud.com/cloud_hosting_products/servers/pricing

]]> http://cloudrop.jp/cloud/rackspace_vs_ec2/feed 2