rsyslog 4.6.1 の前のバージョンであるバージョン 4.5.6 では、僕がパッチを送ったデータを圧縮したときのメモリリークが修正されています。おそらく rsyslog を使っている人で圧縮を有効にしている人は少ないと思いますが、もし使っている人は激しくメモリリークするので、最新版の 4.6.1 にアップグレードしましょう。

bugfix: memory leak when sending messages in zip-compressed format
Thanks to Naoya Nakazawa for analyzing this issue and providing a patch.

こんな感じで rsyslog の CHANGELOG に自分の名前が掲載されているなんて感無量です。

現在、rsyslog バージョン 4.4.2 を本番サーバで使っているのバージョンアップする予定です。

あと、rsyslog を使っていますが、たとえばかなりの容量の Apache のアクセスログを rsyslog へ送っているとき、まれに rsyslog が落ちてしまう問題が一回発生したのですが、再現していません。再現したら、解析して、またパッチを送ってみようと思います。

rsyslog は、現在でもかなり活発に開発が進められているので、今後も進化を続けると思います。

# 今後は、rsyslog バージョン 5.x 系の開発に注力するようです。

• コンパイルにかなりの時間がかかる
• コンパイル後の、テストが必ず失敗する(SSL まわりのエラーなので、テストは必ずしないように変更していた)
• なぜか、InnoDB plugin が無効になってしまって、InnoDB plugin を普通に試せない

ということで、QA もちゃんとされている MySQL の公式 RPM に切替えてみることにしました。

まず、現在の MySQL 5.1 の最新バージョンは 5.1.44 です。MySQL の公式サイトでは RHEL5 用の x86_64 の RPM が用意されています。
RHEL5 x86_64 用の RPM は、次のものをダウンロードすることができます。

• MySQL-client-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-community-5.1.44-1.rhel5.src.rpm
• MySQL-community-debuginfo-5.1.44-1.rhel5.x86_64.rpm
• MySQL-devel-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-embedded-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-server-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-shared-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-shared-compat-5.1.44-1.rhel5.x86_64.rpm
• MySQL-test-community-5.1.44-1.rhel5.x86_64.rpm

次のそれぞれの RPM に、どんなものが含まれているか調査してみました。

MySQL-client-community-5.1.44-1.rhel5.x86_64.rpm
/usr/bin/mysql など、MySQL クライアントようのコマンドが含まれています。

MySQL-community-5.1.44-1.rhel5.src.rpm
SRPM です。mysql-5.1.44.rhel5.spec と mysql-5.1.44.tar.gz が含まれています。

MySQL-community-debuginfo-5.1.44-1.rhel5.x86_64.rpm
MySQL のデバッグシンボル情報です。

MySQL-devel-community-5.1.44-1.rhel5.x86_64.rpm
mysql_config コマンドと MySQL のヘッダーファイルが含まれています。

MySQL-embedded-community-5.1.44-1.rhel5.x86_64.rpm
MySQL の組み込む用途に使われる /usr/lib64/mysql/libmysqld.a が含まれています。

MySQL-server-community-5.1.44-1.rhel5.x86_64.rpm
mysql の sysinit スクリプト、my.cnf 設定ファイルなど MySQL サーバに必要なプログラムが含まれています。

MySQL-shared-community-5.1.44-1.rhel5.x86_64.rpm
/usr/lib64/libmysqlclient.so と libmysqlclient_r.so が含まれています。

MySQL-shared-compat-5.1.44-1.rhel5.x86_64.rpm
MySQL-shared-community の複数のバージョンが含まれています。

MySQL-test-community-5.1.44-1.rhel5.x86_64.rpm
mysql_client_test コマンドが含まれています。

次に、CentOS で提供されているパッケージ名と MySQL 公式のパッケージ名の対応は、次のとおりになります。さらに詳しい RPM の説明は、MySQL 公式サイトを参照しましょう。

mysql:               MySQL-client-community + MySQL-shared-community
mysql-bench:   該当なし
mysql-devel:    MySQL-devel-community
mysql-server:  MySQL-server-community
mysql-test:      MySQL-test-community

MySQL 公式の RPM を使うには、既存の CentOS から提供されているパッケージを上書きするようなダミーパッケージを作成したほうが便利だろうと考えました。なぜなら、既存の MySQL 以外のパッケージで、mysql や mysql-devel のパッケージ依存関係が設定されているときにやっかいだからです。具体的には、このような現象が想定されるからです。

一度ダミーパッケージを作って、公式の RPM もローカルの yum リポジトリに入れてインストールとすると、どうも不思議な感じになってしまいました。具体的には、mysql パッケージをインストールすると、なぜか MySQL-server-community パッケージがインストールされてしまいました。

公式の RPM をよく見てみると、なんと Provides が設定されているじゃありませんか!
公式の RPM では、次のようにちゃんと Provides が設定されています。

MySQL-client: mysql-client MySQL-client
MySQL-server-community: msqlormysql mysql-server mysql MySQL MySQL-server
MySQL-test-community: mysql-test MySQL-test
MySQL-devel-community: mysql-devel MySQL-devel
MySQL-shared-community: mysql-shared MySQL-shared
MySQL-embedded-community:  mysql-embedded MySQL-embedded
MySQL-test-community: mysql-test MySQL-test

なので、mysql パッケージ名を指定すると MySQL-server-community パッケージがインストールされるんですね。。。ということで、小文字のパッケージ名でもちゃんとインストールできます。。。ダミーパッケージを作成したのが無駄になってしまいました、お恥ずかしい。。。

一点だけ注意点があって、mysql というパッケージ名は MySQL-server-community で Provides されているので、MySQL サーバが入ってしまうということです。もし、あるパッケージに mysql というパッケージの依存関係があると MySQL-server-community パッケージがインストールされてしまうので注意しましょう。

まとめると、ダミーパッケージは必要なく、MySQL の公式パッケージだけで、次のコマンドで MySQL の最新バージョンを手軽に使うことができます。

$ sudo yum install mysql-client mysql-shared mysql-server

上のコマンドで MySQL をインストールする場合、MySQL の公式 RPM の方がバージョンが新しいので必ず MySQL 5.1.44 がインストールされるはずです。

ですが、正しくバージョンを指定して、MySQL のバージョンをインストールした場合は、次のようにします。

$ sudo yum install mysql-client-5.1.44 mysql-shared-5.1.44 mysql-server-5.1.44

ただし、RPM に登録されるパッケージ名は、MySQL-*** となるので注意しましょう。mysql* という小文字のパッケージでは登録されていないので気をつけてください。

また、mysql の設定ファイル(/etc/my.cnf と /etc/mysqlmanager.passwd)は、インストールされていないので自分で設置しましょう。
デフォルトの /etc/my.cnf は、このあたりの情報をもとにして設定を追加するといいと思います。

ちなみに MySQL の公式 RPM は、cobbler でローカルの yum リポジトリにミラーしていますが、こんな感じで設定してあります。

$ sudo cobbler repo report –name=mysql-MySQL-5.1

repo: mysql-MySQL-5.1
arch: x86_64
breed: rsync
comment:
created: Tue Feb  9 22:34:22 2010
createrepo_flags: -c cache -d
environment: {}
keep updated: True
mirror: rsync://ftp.jaist.ac.jp/pub/mysql/Downloads/MySQL-5.1/
mirror locally: True
modified : Tue Feb  9 22:34:22 2010
owners: ['admin']
priority: 99
rpm list:
yum options: {}

こうしておけば、MySQL 5.1 系の最新バージョンがでたとき、cobbler reposync すればすぐに最新版の RPM をローカルの yum リポジトリにミラーできるので、とても便利です。

さて、これで MySQL をメジャーアップグレードする準備が整いました。

オープンソースカンファレンス2010 Tokyo/Spring – イベント案内 | 2010-02-27 (土): LinuxからBSDへ – reallyenglishのインフラとネットワーク

以下、講演内容のメモです。

• reallyenglish のサービス紹介、おもに BtoB 向けの英語学習サービスを提供
• データセンターは、日本と香港に二つ借りている
• サーバ台数 50 台、30 台の L2/L3 スイッチ、10 の IPsec-VPN くらいの規模、L2/L3 レベルですべて冗長化されている
• OS は、ルータにはすべて OpenBSD、サーバには FreeBSD 7.x を使っている
• nagios の監視レベルで、100 個のホスト死活監視、400 のサービス監視
• サーバは、PXE 経由でインストールしている、VLAN を設定してあって、管理コンソールは HP の iLO2 を使っている(つまり HP 製のサーバだということ)
• 香港のデータセンターは、有料で OS のセットアップまで行ってくれるが、自分たちでなるべくやっている
• smokeping を使って、ネットワークのレイテンシーをみている
• ローカルネットワークにパッケージのビルドサーバ、パッケージリポジトリをもっていて、port ツリーを一部カスタマイズしたりしている
• freebsd-update もローカルのサーバ経由で行っている
• Marcuscom Tinderbox を使って、パッケージのビルドなどを管理している(かなり便利とのこと)
• Jail を多用している、雑用系のサーバには 10 くらいの Jail が起動していた、他の仮想化技術と違って仮想化によるオーバーヘッドがほとんどないとのこと、Jail から ZFS も扱えるとのこと
• Jail の設定はかなりめんどうだったが、ezjail – Jail administration framework というツールでかなり簡単に設定できるようになった
• LDAP を使っている
• ZFS を本番環境で使っている

Version 13 が RELENG_8 に入っている

ほぼ本番環境でも使えるクオリティに仕上っている

ZFS の運用では、パーティションやスライスを切らないのが普通とのこと

ルートパーティションは、UFS2 にして USB メモリに入れてブートしている

ハードディスクは、すべて ZFS に割り当てている

SSD 上で ZFS L2ARC : Brendan Gregg にある L2ARC(read), ZIL(write) という仕組みを使うと SSD をキャッシュとして使うことができる

Dedup という実装が進んでいる(詳細は調べてみたが分からず)

• HAST – FreeBSD Wiki という Linux でいうところの DRBD のようなものが開発が進められている
• HAST + ZFS + iSCSI という夢の組合せができるかもしれないとのこと
• nagios version 3.0.6 を使って監視しているが、Template Engine を使ってテンプレートで生成している(mixi と同じ方式だと理解しました)
• reallyenglish では、現在開発エンジニアとインフラエンジニアを絶賛募集中とのこと

その他、貴重な本番の nagios の監視画面や smokeping の画面やネットワーク構成図も見ることができました。

BSD 系のインフラの話は、あまり話を聞く機会がなかったのでかなり参考になりました。

まずは、自分個人の FreeBSD サーバで ZFS や Jail を使ってみたいと思います。

今回の講演のスライドは、おそらく公開されるのではないかと思いますが、今回の hbstudy #8 ではツール以前にインフラエンジニアとしてどんなところを目指すか、どのような姿勢でインフラを管理するかといった精神論的な考えというか思想が、とても勉強になりました。

まず、インフラにかかわらず、何言にも共通する思想は、

楽をすること

につきると思います。楽をするための苦労は惜しまずに、楽をするためのツールを自作したり、オープンソースのツールを使ったり、楽をするにはいろいろな方法があります。まず考えることは、楽をするために何をすることなのかなぁと思います。楽をするというと、なんだか怠け者のような印象をもたれることもあると思いますが、楽をするために新しい手法を取り入れていることは大事だと思います。

その次は、インフラエンジニアとしての大切だったと思った思想は、次のとおりです。

• インフラに導入するツールは、なるべくシンプルなものにする
• 自作ツールの場合、なるべく同じ技術を使ったツールで統一する
• ある程度、基本知識がある人なら、自分が管理しているインフラを管理することができるようにする

まず、前提となる知識を習得するのが困難だったり、使い方は複雑なツールは使わないということです。やはり、とても便利なツールでも複雑なツールを導入してしまうと、自分はいいのですが他の人に引き継ぐことになったときなどに説明する手間がかなりかかると思います。また、決してオープンソースのツールだけに選択肢をおかずに機会損失や管理コストなどを総合的に比較して商用ツールも検討するといったこともあるかと必要な場面があると思います。

その次ですが、kazuho さんが基本的にとてもシンプルな自作ツールでインフラを管理しているという話の中で登場してきたツールはほとんど perl で書かれていました。自作ツールでも、シェルスクリプトだったり、C++ だったり、ruby だったり、と実装している技術はバラバラだと、すべての知識が必要になってきます。こうした自作ツールは、perl など１つの実装にまとめることで perl さえ分かれば自作ツールのメンテナンスや改良もできます。最近の Linux の場合、Linux Standard Base (LSB) | The Linux Foundation という規格があるこの規格によると perl や python は最初からインストールされています。残念ながら、ruby や PHP は入っていないので、ruby や PHP で作るときにはパッケージのインストールが必要になります。最近のサーバは、とても早いのでわざわざ C++ などで作成するよりも LL で十分なことも多くなってきていると思います。個人的には、ruby を愛用していますが、python にしたほうが標準インストールされているという観点でみるとありかなと思っています。

最後に、自作ツールでもあまりオレオレ仕様的なツールは作らずに、他のツールの思想や考えたにのとった自作ツール、定番といえるオープンソース、だけをできるだけ組み合わせて、かつシンプルに形でインフラを管理しておくということです。シンプルにしておけば、日常業務の中でも毎日やることが単純になったり、業務レベルで他の担当者と共有することも比較的容易なのでないかと思います。

今回の hbstudy では、このような考え方というか思想が大事なのではないかと感じました。僕が管理しているインフラも、この思想に基づいていけるように日々改善を重ねいたいと思いました。

このバージョンでは、CHANGELOG をみて分かるようにバグフィックスの他にいくか機能拡張がされています。

その中で、個人的に大きいのは httpd のサービスチェックのときに HOST ヘッダーを指定できるようになったことです。例えば、次のようなに HOST ヘッダーを指定して httpd サービスの監視をすることができます。

if failed host localhost port 80 protocol http and request ‘/ testing’ hostheader ‘example.com’ with timeout 20 seconds for 2 cycles then restart

hostheader という識別子で手軽に指定することができます。

さっそく試そうと RPM を作ってみることにしました。monit には、RPM を作成するための SPEC ファイルが同梱されているので、次のコマンドでさくっと RPM を作成することができます。

$ rpmbuild -ta monit-5.1.tar.gz

しかし、いくつか不用なファイルの設定が原因で RPM をビルドできないので SPEC ファイルを、次のように修正しました。この修正は、本家に連絡してすでにコミットしてもらってあります。

— monit.spec-org      2010-02-18 10:48:56.000000000 +0900
+++ monit.spec  2010-02-18 10:49:09.000000000 +0900
@@ -51,7 +51,7 @@

%files
%defattr(-,root,root)
-%doc CHANGES.txt CONTRIBUTORS COPYING FAQ.txt LICENSE README README.SSL
+%doc CHANGES.txt COPYING LICENSE README README.SSL
%config /etc/monitrc
%config /etc/init.d/%{name}
%{_bindir}/%{name}

RPM を作成して、さっそく monit をアップグレードして、次のような設定で試してみます。

check process httpd with pidfile /var/run/httpd/httpd.pid
start program = “/etc/init.d/httpd start”
stop program = “/etc/init.d/httpd stop”
if failed port 80 protocol http
and request “/” hostheader “example.com”
with timeout 2 seconds for 2 cycles
then restart

動作確認するために、sudo monit -Iv してみると、hostheader の syntax エラーになります。ソースコードをみてみると、不具合っぽいのでさっそく連絡してみると、作者の Martin さんから、次のようなパッチが送られてきました。

Index: p.y
===================================================================
— p.y (revision 128)
+++ p.y (working copy)
@@ -1077,7 +1077,7 @@
;

hostheader      : /* EMPTY */
-                | hostheader STRING {
+                | HOSTHEADER STRING {
portset.request_hostheader = $2;
}
;

monit バージョン 5.1 の不具合のようです。さっそく、上のパッチとあわせて本家に掲載されている FTP のパッチをあわせて RPM を作成しました。パッチをあてて作成した RPM は、ここに置いておきます。

パッチをあてた monit でさっそく動作確認してみると、hostheader 識別子をちゃんと認識して問題なく動作しました。

これからの修正は、CHANGELOG をみてみると、おそらく近いうちに monit バージョン 5.1.1 でリリースされるのでないかと思います。hostheader のバグレポートを報告したので、CHANGELOG になんと僕の名前が掲載されています。こんな小さな報告でも CHANGELOG に追加されるんですね。

Fix the HTTP protocol test’s hostheader option which was added in 5.1.
Thanks to Naoya Nakazawa for report.

httpd のサービスチェックで HOST ヘッダーを指定できると、かなり便利になるので、monit を愛用している人はバージョン 5.1.1 を待つか、パッチをあてたバージョンにアップグレードするといいと思います。

monit は、なんといっても設定ファイルが書きやすい、メーリングリストで質問やバグレポートをすると翌日にはすぐに返信があるのでかなり活発なプロジェクトなので、使っていない人はぜひ使ってみるといいと思います。

# 2010.02.25: 追記

monit バージョン 5.1.1 がリリースされました。バグフィックスのみのリリースです。

Release checksums
=================
md5:    4bbd3845ae1cbab13ec211824e0486dc
sha256: bf789e0660410e8c63f4b3dc2eeab9889347e6494a6dc1c0e764343cae0dc1ba

Release information:
====================
Bug fixes
* Fixed FTP protocol test. Thanks to Axel Reinhold for report.
* Fixed the hostheader option in the HTTP protocol test, which was
added in Monit 5.1. Thanks to Naoya Nakazawa for report.
* Removed an erroneous warning message about missing system service check.
* Improved manual page formatting. Thanks to Stefan Alfredsson for report.

僕の名前があって、ちょっとうれしいです(笑)。

iptstate は、netfilter の接続をトラックキングしているテーブルの情報を top のように表示してくれるコマンドです。

CentOS の場合は、すでに iptstate バージョン 1.4.1 が提供されていて、普通にインストールすると iptstate パッケージがインストールされています。

さっそく、試してみます。iptstate は、netfilter つまり iptables の接続トラックキングテーブルの情報を表示してくれるので、iptables が動作している必要があります。

$ sudo /usr/sbin/iptstate

IPTables – State Top
Version: 1.4          Sort: SrcIP           s to change sorting
Source                  Destination             Proto   State        TTL
127.0.0.1:33005         127.0.0.1:8020          tcp     ESTABLISHED  119:59:58
127.0.0.1:52326         127.0.0.1:8021          tcp     ESTABLISHED  119:59:56
192.168.161.1:60730     192.168.161.125:22      tcp     ESTABLISHED  119:59:12
192.168.161.1:54619     192.168.161.125:22      tcp     ESTABLISHED  119:59:55
192.168.161.1:17500     192.168.161.255:17500   udp                    0:00:09

な感じで、接続元の IP アドレス、経路情報、プロトコル、状態、TTL、を表示してくれます。

もちろん、top のように並び替えもできます。iptstate では、次の並び替えのキーが定義されています。

d   カラムのサイズを動的に変更して、古いデフォルトのサイズを使用する

f   loopback でフィルタリングする

l   IPアドレスの中で DNS を探している順にする

m   ホスト名を切り取った形でフィルタリングする

n   DNS に関連した表示にする

q   終了する

r   逆順に並び替える

space   表示をすぐに更新する

昔から存在するコマンドですが、どこから接続があるので、どのポートに接続しているのか、などがすぐに分かるので、とても便利なコマンドです。

Puppet Dashboard とは、ノード管理とレポートツールを提供してくれる Puppet のウェブアプリケーションです。ノード情報はYAML 形式でエクスポートすることができて、ダッシュボードから外部ノードツールとして使うこともできるようです。

まず、最初にPuppet Dashboard を動作させるために、次のものが必要です。

• ruby >= 1.8.1
• rake >= 0.8.4
• mysql
• puppet
• rubygems >= 1.3.2
• rails >= 2.3.4

さっそくインストールしてみましょう。

$ git clone git://github.com/reductivelabs/puppet-dashboard.git

$ cd puppet-dashboard

$ rake install

rake install すると、dashboard_development というデータベースが作成されてテーブルがいくつか作成されるので、localhost に mysql が起動している必要があります。

Rails アプリケーションなので、さっそく起動します。

$ ./script/server

http://localhost:3000 にアクセスすると、次のような Puppet Dashboard トップ画面が表示されます。

ノードの例として、「sample node」が定義されています。さっそく、ユーザ登録してみます。ユーザ登録は、ユーザ名とパスワードを入力するだけのシンプルな形です。

ユーザ登録できたところで、実際のノードを追加してみます。Nodes タブをクリックして、ノードを追加します。

この他にも、ノードクラス、ノードグループ、レポート、の機能があります。

まず、レポートの機能は、現在の puppet レポートの実行結果が /var/puppet/lib/reports にある場合は、次のコマンドで Puppet Dashbaord へインポートできます。

$ rake reports:import

また、puppet レポートの実行結果が、他の場所にある場合は、次のコマンドで Puppet Dashboard へインポートすることができます。REPORT_DIR という環境変数に Puppet レポートの実行結果を格納してあるディレクトリを指定するだけです。

$ rake reports:import REPORT_DIR /path/to/your/reports

Importing 1 report from /path/to/your/reports
Importing:     100% |##########################################| Time: 00:00:00
1 of 1 report imported

試しに1件レポートデータをインポートした画面は、次のようになっています。

毎回、レポートをインポートするのが面倒なので、Puppet サーバと連携する方法も用意されています。Puppet サーバと連携するには、puppetmasterd に、次のように –reports オプションを指定するだけです。

–reports <puppet_bashboardのサーバ名>

ただし、Puppet Dashboard は、localhost:3000 で動作するようにハードコーディングされています。これを変更するには、lib/puppet/puppet_dashboard.rb を変更する必要があります。

次に Puppet Dashboard には、Puppet 互換の外部ノード情報と連携することができます。Puppet 互換の外部ノード情報は、YAML 形式で出力しますが、Puppet Dashboard に付属している bin/external_node プログラムを使います。このプログラムも、localhost:3000 でハードコーディングされているので、環境に応じて変更するとよいでしょう。

今のところ、僕が Puppet を投入している本番環境ではレポート機能をオフにして、エラーログのみチェックしていますが、比較的少ない台数で運用している場合は、Puppet Dashboard 管理画面からレポートの実行結果をチェックすることができるので、便利なツールと言えそうです。

将来的には、次の機能が実装予定とのことです。

• LDAP と ActiveDirectory 認証
• 管理者の権限によるアクセス制御
• データをよりよく可視化して、情報にアクセスしやすくする
• さらに多くのノード状態情報(オフライン状態、通信エラー、など)
• リソースの変更を報告して、トラックキングする
• Puppet の実行スケジューリング
• その他のコミュニティからのリクエスト機能

まだ、Puppet Dashboard は登場したばかりなので、これから期待できるツールにもなりますね。

さっそく、CentOS で試してみると、iptables の libipt_statistic モジュールがないというエラーになってしまった。次に RedHat のページを調べていると、Bug 215361 – iptables is missing /lib/iptables/libipt_statistic.so というまさにぴったりな情報が見つかった。その情報では、iptables バージョン 1.3.6 から追加されたとあったので、さっそく netfilter iptables バージョン 1.3.6 のページの変更点を調べてみると、たしかに次のような記載があった。

- Add support for statistic match (needs kernel >= 2.6.18)
  [ Patrick McHardy ]

CentOS 5.3 x86_64 の iptables のバージョンは、iptables-1.3.5-4.el5 なので一つバージョンが古いのが原因のようだ。Linux カーネル 2.6.18 が必須とのことなので、CentOS でもおそらく使えるそうだ。

さっそく、iptables バージョン 1.3.6 を導入するために、RPM を作成にとりかかった。

まず、iptables-1.3.5-4.el5 の SRPM をダウンロードして、このバージョンの iptables.spec ファイルをパッチなどはすべて正しくあてるように、かつ libipt_statistic をビルドして組み込むように RPM を作成した。

libipt_statistic は、iptables バージョン 1.4.0 以降から標準で組み込まれるようになっているが、バージョン 1.3.6 では標準では組み込まれない。ちょうど、該当のコミットログがあったので、コミットログを参照しながら RPM を作成した。

作成した RPM は、ここにアップロードしてある。あわせて、SRPM もアップロードした。他に作った人がいないかも調べてみたが、見つからなかった。

iptables を現時点での最新版であるバージョン 1.4.6 ではなく、バージョン 1.3.6 にしようとした理由は RPM のおそらくメジャーアップグレードになるので RPM の作成が大変であること、安定性の面で経験がまったくないのでなるべる標準にインストールされるバージョンに近いものにしたいと思ったからだ。

作成した RPM で、CentOS にインストールされている既存の iptables をバージョンアップして、さっそく試してみた。

まず、外側のネットワークのデバイスに IP エイリアスを設定する。次の例は、ifconfig eth0 の出力結果だが、不要な情報は省いてある。

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.161.125  Bcast:192.168.161.255  Mask:255.255.255.0

eth0:0    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.161.124  Bcast:192.168.161.255  Mask:255.255.255.0

eth0:1    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.161.123  Bcast:192.168.161.255  Mask:255.255.255.0

eth0:2    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.161.122  Bcast:192.168.161.255  Mask:255.255.255.0

次の iptables の設定で NAT チェインを、次のように設定する。(スマイルアイコン対策のため、PREGROUTING と POSTROUTING の前のセミコロンは省いてある)

*nat
PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.125
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.124
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.123
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.122
COMMIT

iptables を再起動して、さっそく接続先のサーバに Apache HTTPD を起動して、アクセスログを確認してみると、次のような結果になった。

192.168.161.125 – - [11/Feb/2010:23:17:07 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.124 – - [11/Feb/2010:23:17:08 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.123 – - [11/Feb/2010:23:17:09 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.122 – - [11/Feb/2010:23:17:09 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:17:10 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:17:11 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.124 – - [11/Feb/2010:23:17:12 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:17:13 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:17:14 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.123 – - [11/Feb/2010:23:17:14 +0900] “GET / HTTP/1.1″ 200 44

完全にはラウンドロビンにはなっていないが、リクエストごとにアクセス元の IP アドレスが毎回変更されている。

最後に libipt_statistic のモジュールとはどんなモジュールかソースコードを読んでみた。libipt_statistic モジュールとは、ある状態になっているかを調べることができるモジュールのようである。

設定内容は、次のような設定が可能。

–mode mode: マッチモード (random あるいは nth)

–probability p: 確立

–everyn: n 番目のパケットに毎回マッチする

–packet p: 初期値のカウント値(p は、0 以上 p – 1 以下)、デフォルトは 0

どうやらこのモジュールは、ある状態ごとに iptables の設定を変更できるモジュールのようだ。

いろいろと試した結果、完全なラウンドロビンにするには、次のような設定でいけるようだ。(スマイルアイコン対策のため、PREGROUTING と POSTROUTING の前のセミコロンは省いてある)

*nat
PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.125
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 3 -j SNAT –to-source 192.168.161.124
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 2 -j SNAT –to-source 192.168.161.123
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 1 -j SNAT –to-source 192.168.161.122
COMMIT

上の設定のときの Apache アクセスログは、次のようになった。

192.168.161.122 – - [11/Feb/2010:23:27:29 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:27:30 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.124 – - [11/Feb/2010:23:27:31 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.123 – - [11/Feb/2010:23:27:32 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.122 – - [11/Feb/2010:23:27:32 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:27:33 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.124 – - [11/Feb/2010:23:27:34 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.123 – - [11/Feb/2010:23:27:34 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.122 – - [11/Feb/2010:23:27:35 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:27:36 +0900] “GET / HTTP/1.1″ 200 44

どうして、この設定だと、完全にラウンドロビンになるのか、よく分かっていない。。。

iptables には、こんなこともできるのかと感動した。

以下、動画からのメモです。

• CPU の高い使用率が問題になっていた
• 10,000 台のウェブサーバ
• それぞれのリクエストに 800 ミリ秒かかっている
• コードベースが巨大になるにつれて、さらに遅くなる
• ハードウェアは、フリーではない
• 言語ごとのベンチマークした結果の CPU の使用率
• CPU の使用率が低い順 No1: C++, No2: Java, No3: C#, No4: Erlang, No5: Python, No6: Perl,  No7: PHP
• PHP と Perl は同等、C++ や Java に比べると10 倍くらい遅いという結果
• 高いメモリ使用率が問題
• - 150M
  for ($i = 0; $i < 1000000; $i++) {
  $a[] = $i;
  }
• - 750MB
  for ($i = 0; $i < 5000000; $i++) {
  $a[] = $i
  }
• HipHop for PHP では、次の問題点を解消するために作った
• 高い CPU の使用率を解消するため
• 多くのメモリの使用率を解消するため
• 他のシステムで既存の PHP のロジックを再利用するため
• 拡張は、ほとんどの PHP 開発者には書くことが難しい作業
• HipHop for PHP は、2年間の成果で、ソースコードの最適化された C++ コード(g++ を使う)の変換機
• 効果は、ウェブサーバは 50% 以下に下がった、API は 2 倍のトラフィックに対して 30% 以下に下がった(APC を使った PHP コードベースと比べた結果)
• 7つのステップを通して、コードを変換する
• 本番環境でのデプロイは、通常の PHP コードでのデプロイとは異なっている
• 複数のスレッドで一つのプロセスを起動している
• 再起動している間のダウンタイムがない(port takeover… ポートを乗っ取り?)
• 巨大なバイナリを置く
• HipHop は、現在とてもシンプルなウェブサーバ上で使っている
• これからのロードマップ
• 現在、PHP 5.2 をサポートしているが、5.3 もサポートしたい
• ウェブサーバのオプションとして Apache をサポートしたい
• Facebook では、Apache 1.3 Prefrok で使っているとのこと
• 同時にデータベースのコネクションも減っている
• PHP の拡張はスレッドセーフでない問題は解決できていないとのこと

まだ、ちゃんと試していないのでよく分かりませんが、PHP なウェブサービスで PHP が CPU ボトルネックになっている場合には、物理サーバを減らすための有効なソリューションの一つになるかもしれないイメージをうけました。ただし、Facebook では、まだとても単純なウェブサーバ上でしか使っていないそうので、実際のサービスに使うにまだまだ時間がかかりそうです。

あと、個人的には Java は C++ と同様のベンチマーク結果だということも注目です。

なお、HipHop for PHP のソースコードは、github でもうすぐ公開予定とのことです。

sudo コマンドはなくてはならないコマンドですが、同時に危険なコマンドでもあります。

今まで、ずっとデフォルトの sudo の設定で使っていたのですが、改めて設定を見直してみました。

sudo の公式ページをみてみると、頻繁にバージョンアップされているのがよく分かります。/etc/sudoers の設定方法も詳しいドキュメントがあっていい感じです。

次の2点ほど設定を見直しました。

• デフォルトのパスワードのキャッシュ時間を 0 にする
• パスワードプロンプトにホスト名を表示する

まず、最初の設定はデフォルトだと 5 分間、パスワードがキャッシュされます。そうすると、連続で sudo コマンドを実行するとき、パスワードを聞かれないためオペミスを起こしてしまう可能性が高まります。そこで、キャッシュ時間を 0 にすることにより、必ず毎回パスワードを聞くように設定します。この設定は、visudo コマンドを使って、次の行を追加します。

Defaults timestamp_timeout = 0

次にパスワードを聞かれるときのプロンプトにホスト名を表示して、念のためどのホストで sudo を実行しようとしているのか表示します。次の行を追加します。

Defaults passprompt = “%u@%h Password: “

この設定をすると、例えば hoge というユーザ名で、s1 というホスト名の場合、次のようなパスワードプロンプトになります。

hoge@s1 Password:

デフォルトのパスワードプロンプトに比べると、かなり分かりやすい表示になりました。

最新版の sudo バージョン 1.7.1 以降からは、次のような構文で別の設定ファイルも読み込めるようになっています。

これを使えば、ホストごとに異なった設定も管理しやすくなります。ただし、CentOS の場合、バージョン 1.6.8 なので対応していません。すこしはまってしまいました。。。

#includedir /etc/sudoers.d/hoge

最新版の sudo に入れ替えようと思いましたが、今のところそれほど困っていないので最新版は使っていません。

普段何気なく使っている sudo。もちろん、なるべく本番サーバ上では使わないのが賢明ですが、メンテナンスのときなど使う機会があるので、なるべくオペミスのリスクを減らしたいものです。

さらに、僕は sudo をコマンド補完履歴に追加しないようにしています。

# 2/5 追記

ちなみに、sudo のパスワードキャッシュをクリアするときは sudo -k あるいは -K オプションで行います。

NEC サーバの 1U サーバの NEC Express 5800 シリーズの 2 種類の消費電力を測定する機会があったので、計測結果を紹介します。

計測方法は、前回の DELL サーバのときと同じクランプメーターで測定しました。

NEC Express 5800/R120a-1

• CPU: Intel Xeon X5570 2.93GHz x 2
• Memory: 32GB
• HDD: Seagate Savvio ST973452SSS SAS 60GB x 6 (ハードウェア RAID 0)
• Power: 冗長電源付き(2系統に電源が入っている場合、方側の電源を抜くともう片側に2倍の電力がかかる)
• 消費電力 idle: 0.86A
• 消費電力 max: 1.74A

NEC Express 5800/120Rh-1

• CPU: Intel Xeon E5420 x 1
• Memory: 8GB
• HDD: Western Digital SATA 160GB x 1
• Power: 冗長電源なし
• 消費電力 idle: 1.76A
• 消費電力 max: 2.10A

Xeon E5420 は、Intel のホームページを見ると 80w ですが、かなり消費電力が高いのが、特徴的でした。

サーバ本体の価格、消費電力、どちらをとるのか、サーバの用途によって決めていくのが重要だと思う今日この頃です。

DELL スイッチには、いくつか種類がありますが、PowerConnect 54XX より上位のモデルは、telnet 接続してスイッチの設定をする機能があるので、telnet 接続することでサービスタグを確認することができます。

例えば、switch1.example.com というスイッチがあった場合には、次のように設定します。

$ telnet switch1.example.com

User name: admin

Passowrd: スイッチの管理パスワード

switch1.example.com# show system

System Description:                                        PowerConnect 5448
System Up Time (days,hour:min:sec):       237,08:32:02
System Contact:
System Name:                                                 switch1.example.com
System Location:
System MAC Address:                                  XX:XX:XX:XX:XX:XX
System Object ID:                                         1.3.6.1.4.1.674.10895.1234
Type:                                                               Ethernet Switch
Asset tag:
Service tag:                                                    1234567

Main Power Supply Status:    OK
Fan 1 Status:                             OK
Fan 2 Status:                             OK
Fan 3 Status:                             OK

Unit            Temperature (Celsius)            Status
———————— ———————— ————————
1                        52                       OK

上の出力にある Service  tag: という欄で、DELL スイッチのサービスタグを確認することができます。あわせて、スイッチの電源状態、ファンの状態、などもチェックすることができるので、とても便利です。時間があいたときにでも、スイッチの状態を確認する Nagios プラグインでも書いてみようかと思います。

なお、もっとも安価な PowerConnect 28xx シリーズには、その機能がないので注意してください。ただし、ウェブの管理画面があるので、そこから確認することができます。

ちなみに、DELL スイッチにはエクスプレスコードはありません。サービスタグのみで、問い合わせすることが可能です。

この ID は、1u サーバだと筐体の正面にシールで張り付けされています。R410 などのちょっとよい 1U サーバの場合、正面の LCD にもスクロールされて標準されています。

RX1Xの場合: www.dell-faq.com -Q&A検索- FAQ詳細

何らかの問い合わせがあるとき、このサービスタグとエクスプレスコードを確認する必要がありますが、いちいち筐体の前に行って確認するのはめんどうです。

DELL から、このサービスタグとエクスプレスコードを確認するための RHEL 用のコマンドが配布されているので、これを利用すると便利です。

まず、DELL 非公式の yum リポジトリを追加します。

$ wget -q -O – http://linux.dell.com/repo/community/bootstrap.cgi | sudo bash

bootstrap.cgi は、ソースコードをみて分かるとおり、CentOS もしっかりサポートされています。上のコマンドを実行すると、DELL 非公式の yum リポジトリが追加されますので、あとはプログラムをインストールします。

$ sudo yum install libsmbios-bin

そうすると、/usr/sbin/getSystemId というコマンドを python で書かれたコマンドラインツールがインストールされます。次のように、このコマンドを使うと簡単にサービスタグとエクスプレスコードを確認することができます。

$ sudo /usr/sbin/getSystemId

Libsmbios version:        2.2.17
Product Name:               PowerEdge R300
Vendor:                            Dell Inc.
BIOS Version:                 1.2.0
System ID:                       0×0123
Service Tag:                     1234567
Express Service Code:   1234567890
Asset Tag:
Property Ownership Tag:

–help すると詳しいコマンドの使い方が分かりますが、例えばサービスタグだけ取得したいときは、次のように実行します。

$ sudo /usr/sbin/getSystemId –service-tag

これを応用すれば、サービスタグとエクスプレスコード用のカスタム facter も書けますし、資産管理のときにもまとめて集められるので、とても便利です。

僕の場合は、管理している本番サーバ上で getSystemId を使ってすべてのサービスタグとエクスプレスコードを集めて、社内 wiki に一覧としてまとめてあります。

元ネタ: 漢(オトコ)のコンピュータ道: それでも私が MySQL を使いつづける理由または、Why I still use MySQL? 的な。

同じくノリが楽しそうだったので CentOS で便乗してみました。

Fast Enough

正直なところ、特に速いと思ったことはあまりない。

Stable

商用版をベースにしているため、安定している。ちゃんと対応しているプログラムが多い。

バージョンアップが枯れ過ぎているので、かなり安定している。

Easy to install

Live CD ですぐに試せたり、インストール CD を使えば、すぐに分かりやすいグラフィカルなインストーラでインストールすることができる。インストール CD をダウンロードするのがめんどうだという人向けにネットワークインストール用のインストールイメージも用意されている。

Gnome/KDE や仮想環境 (KVM) やクラスタリング環境がすぐにセットアップできるのが便利。

さらにインストール後に、root ユーザのホームディレクトリに生成される kickstart ファイルを使えば、同じ設定で何度もインストールすることが可能なところも魅力である。

CentOS have enough users.

RHEL のユーザを含めば、恐らく Linux ディストリビューションのユーザ規模では最大規模になると思う。そのため、日本語の書籍やインターネット上の情報が豊富である。

まとめ

以上に述べた点に比べると、プロジェクトが崩壊の危機にあったとか、Linux Kernel のバージョンが 2.6.18 云々とかは些事にすぎない。

改訂第二版 CentOSサーバ構築バイブル

posted with amazlet at 10.01.20

平 初 伊藤 幸夫 上鍵 忠志 中澤 直也 面 和毅 館林 綾ノ介 高安 洋輝 宇野 素史 坂井 恵
毎日コミュニケーションズ
売り上げランキング: 55121

Amazon.co.jp で詳細を見る

せっかくなので、その写真の一部を紹介します。大きな写真は、元記事から見てください。

まずは、日立のグリーンデータセンター。これは、実物ではなく構想上の写真のみです。

次に Facebook のデータセンター。これは貴重な写真だと思います。ネットワークのケーブリングまわりも要チェックです。サーバ一台あたりに、2本から3本くらいのケーブルが接続されているのが分かりますね。おそらく冗長化目的というより、ネットワークを分離しているような気がします。

そして、昨年大きな話題になった Google。Google サーバのケーブルは、各サーバに一本ずつです。シンプルな構成で、かなり割り切った構想のようです。

そして、Microsoft のデータセンター。

Planet  データセンター。DELL サーバだらけです。よくこれで1ラックに詰め込むができますね。ラックの上部にスイッチを配置しているのが新鮮です。

美しいネットワークのケーブリング。

次のケーブリングは、僕の方式とかなり近いです。

次のようなスパゲッティな状態も、別の意味で美しいです。

一度、Facebook か Google か Amazon の巨大データセンターを見てみたいものですね。

Hadoop は、CDH のバージョン 0.18.3 を使っています。

まず、/usr/lib/hadoop/bin/hadoop-daemon.sh で、log4j の logger 環境変数を使えるように次のように変更します。次のパッチでは、念のためローカルのログファイル名も変更できるようにしてあります。

/usr/lib/hadoop/bin/hadoop-daemon.sh
28a29,30> #   HADOOP_LOGFILE  The log file name. Default is hadoop-$HADOOP_IDENT_STRING-$command-$HOSTNAME.log
> #   HADOOP_ROOT_LOGGER   The root appender. Default is INFO,console
84a87,94
> # log configuration
> if [ "$HADOOP_LOGFILE" = "" ]; then
>   export HADOOP_LOGFILE=hadoop-$HADOOP_IDENT_STRING-$command-$HOSTNAME.log
> fi
> if [ "$HADOOP_ROOT_LOGGER" = "" ]; then
>   export HADOOP_ROOT_LOGGER=”INFO,DRFA”
> fi
>
86,87d95< export HADOOP_LOGFILE=hadoop-$HADOOP_IDENT_STRING-$command-$HOSTNAME.log
< export HADOOP_ROOT_LOGGER=”INFO,DRFA”

次に、/etc/hadoop/conf/hadooop-env.sh に、次のように追加します。

export HADOOP_ROOT_LOGGER=”INFO,SYSLOG,DRFA”

最後に、/etc/hadoop/conf/log4j.properties に syslog で出力するための log4j の appender を追加します。

#
# syslog
#
log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
log4j.appender.SYSLOG.facility=local0
log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
log4j.appender.SYSLOG.layout.ConversionPattern=%p %c{2}: %m%n
log4j.appender.SYSLOG.SyslogHost=127.0.0.1
log4j.appender.SYSLOG.threshold=INFO
log4j.appender.SYSLOG.Header=true
log4j.appender.SYSLOG.FacilityPrinting=true

あとは、Hadoop を再起動すれば、127.0.0.1 のサーバに 514 番ポート、UDP、local0 ファシリティ、にて Hadoop のログが転送されます。どうやら、TCP にすることができないみたいです。

hadoop-daemon.sh の方は、本家でバージョン 0.21 で対応予定のようです。

参考資料

• HowToConfigure – Hadoop Wiki
• Re: syslog-ng and hadoop

まずは、syslog-ng。

syslog-ng の本家サイトをみると、次のような3種類のバージョンがあります。

• オープンソース版: フリー、syslog-ng のオープンソースブランチ
• プレミアム版: いくつかの追加機能をオリジナルのオープンソース版 syslog-ng からフォークした商用版
• ストアボックス版: ログのライフサイクル管理の中央ログサーバアプライアンス

次に CentOS では、バージョン 2.1.4 が EPEL のリポジトリから提供されています。本家サイトでは、次のバージョンが stable として提供されています。

• 3.0.5 – 3.0.1
• 2.1.4 – 2.1.3
• 2.0.10

EPEL で提供されているのは、2.1 系の最新版ということになります。最新版のバージョン 3 系の changelog は、ここで確認できます。おもな変更は、次の内容になります。

• IETF によって策定された新しい syslog プロトコルの標準に対応した、具体的な仕様はこことここを参照してください
• Log ステートメントに他の複雑なログのパスを組み込むことができるようになった
• 元ファイルの文字コードを設定することが可能になった(内部的には、syslog-ng はすべてのメッセージを UTF-8 として記憶している)
• syslog-ng のアプリケーションは、すべてのログメッセージに対してユニークなメッセージ識別子を付与できるようになった
• syslog-ng のアプリケーションは、テンプレートや正規表現を使って構造化されたメッセージを読み込んだり、処理できたり、書き直すことができるようになった(例えば、Apache のウェブサーバログ)。フィールドサイズを変更することとデリミッターで区切られているフィールドの両方のメッセージをサポートした

それほど大きな変更点はないようなので、EPEL で提供されているものを十分だと思われます。EPEL が利用できるなら、インストールは次のコマンドでできます。

$ sudo yum install syslog-ng

インストールすると、制御スクリプトが /etc/syslog-ng、設定ファイルが /etc/syslog-ng/syslog-ng.conf にインストールされます。

実際に使用する前に、syslog-ng のおもな特徴をまとめておきます。

• 既存の syslog の設定ファイルと互換性がない(デフォルトでインストールされている設定ファイルがデフォルトの syslog の設定と同じになっています)
• facility などで細かく出力するログの内容を設定することができる
• 出力するログファイル名に、日付などを設定することができる(これによりログローテート入らずになります)
• UDP/TCP によって、任意のサーバへログ転送することができる(デフォルトのポートは、514)
• facility、priority、ホスト名、アプリケーション名、などで自分のプログラムを起動することができる

syslog-ng と rsyslog は、従来の syslog を置き換えるものなので、事前に syslog を必ず止めて起動しないようにしておきます。(さようなら syslog、今までありがとう syslog…)

$ sudo /etc/init.d/syslog stop

$ sudo chkconfig syslog off

今回は、Apache のアクセスログを syslog-ng と rsyslog でシスログ転送する方法をそれぞれ紹介します。

Apache のアクセスログは、パイプで logger コマンドを指定すると syslog へ出力することができます。

CustomLog “|/usr/bin/logger -i -p local4.info -t httpd” combined

syslog-ng の設定は、次の内容を /etc/syslog-ng/syslog-ng.conf に追加します。

filter f_httpd {
facility(local4) and level(info);
};

destination d_httpd {
file(“/var/log/syslog_httpd_access_log”);
udp(“192.168.1.2″);
};

log { source(s_sys); filter(f_httpd); destination(d_httpd); };

上のように設定しておくと、/var/log/syslog_httpd_access_log にアクセスログが出力されて、かつ 192.168.1.2 のサーバにログを UDP で転送するという設定になります。

192.168.1.2 の syslog-ng の設定は、s_sys source のコメントをはずします。なお、UDP/TCP の 514 ポートが iptables でブロックされていないか確認しておきましょう。tcp にしたい場合には、udp を tcp に置き換えます。

udp(ip(0.0.0.0) port(514));

syslog-ng を起動する前に、設定ファイルに記述ミスがないかどうか調べてみます。

$ sudo /etc/init.d/syslog-ng checkconfig

Checking Configuration:                                    [  OK  ]

問題がなければ起動してみます。

$ sudo /etc/init.d/syslog-ng start

Starting syslog-ng:                                        [  OK  ]

これで、httpd へのアクセスログがローカルのディスクに出力されて、かつ 192.168.1.1 のサーバにも同じ内容が転送されてアクセスログとして出力されます。

syslog-ng の設定項目は、膨大なので公式ドキュメント(PDF 形式)を参考にしたほうがよいと思います。

次に rsyslog。

rsyslog は、CentOS の base リポジトリで、バージョン 2.0.6 が提供されています。rsyslog にも、いくつかのバージョンが stable として提供されています。

• v5 stable: 5.2.0 [2009-11-02] -  変更履歴 – ダウンロード
• v4 stable: 4.4.2 [2009-10-09] – 変更履歴 – ダウンロード
• v3 stable: 3.22.1 [2009-07-02] – 変更履歴 – ダウンロード
• v2 stable: 2.0.7 [2009-04-14] – change log – ダウンロード

四系統もバージョンがあり、かなり複雑な印象をうけます。v2 と v3 では、互換性がないようで専用の互換モードが用意されています。それぞれのバージョンでも互換モードが用意されています。v2 は、すでにサポートされていないので、v3 stable 以降を使うといいと思います。

ちなみに、Fedora では Fedora 8 から、syslog のかわりに rsyslog を採用しています。最新版の Fedora 12 では、rsyslog のバージョンは 4.4.1 でした。

なので、v4 stable のバージョン 4.4.2 を使うのがよさそうです。このバージョンは、RPM では提供されていないので、Fedora プロジェクトのものを使って RPM を作成するといいと思います。Fedora プロジェクトのもので RPM を作成すると、sysklogd パッケージと /etc/logrotate.d/syslog がコンフリクトしてしまいますが、従来の /etc/logrotate.d/syslog の内容と同じもので rsyslog の RPM を作成すればコンフリクトを解消することができます。設定ファイル内のスペースとタグも区別するので、まったく同じ内容になるように作成してください(僕はここですこしはまりました…)。

rsyslog をインストールすると、制御スクリプトが /etc/init.d/rsyslog、設定ファイルが /etc/rsyslog.conf、にインストールされます。rsyslog.conf をみて分かるとおり、従来の syslog の設定ファイルとほぼ同じ内容になっています。

rsyslog のおもな特徴は、次のとおりです。これらの機能は、syslog-ng では提供されていない機能だと思われます。特に圧縮転送はうれしい機能の一つです。マクロは、syslog-ng と同じようなものが提供されています。その他の詳しい機能は、本家サイトで確認してください。

• MySQLやPostgreSQLをモジュールなどで拡張することなく、ネイティブでサポート
• libdbiを使用すれば、Firebird／Interbase／MS SQL／SQLLite／Oracleなどに対応可能
• 圧縮転送が可能
• stunnelを使ったシスログのセキュアな転送が可能
• シスログのディスク書き込みで、I/Oの処理が間に合わない場合など、スプールを使用することができる。特にバックエンドにデータベースを使用している場合に有効に機能する

Apache のアクセスログを出力している側の rsyslog の設定は、次の内容を追加します。

local4.info @@192.168.1.2

たったこれだけです。@@ というのは、TCP でログを転送するという意味になります。UDP で転送したい場合は、@ と指定します。

syslog-ng と rsyslog、どちらも試してみましたが、どちらもほぼ同じ機能が提供されています。設定ファイルの書き方が、まったく違うので、どちらかを常用するべきか決めたほうがいいと思います。

僕の場合、CentOS であること、Fedora が rsyslog を標準採用したということで、RedHat もそろそろ標準採用しそうか感じがあるので、rsyslog を本番環境へ本格的に投入してみることしました。

rsyslog を本番環境へ投入するにあたりかなりはまったので、この内容は別にエントリする予定です。

個人的な 2010 年のおおよその目標は元旦に決めましたが、今年はいろいろと自分の環境を変えていく年になりそうです。

ということで、今年 2010 年も Carpe Diem をよろしくお願い致します。

—

Naoya Nakazawa

まず、モバゲーの規模を知るために、 月次推移のご報告（平成21年10月度）を見てみましょう。この資料から、2009 年 10 月時点での PV は、次のようになっています。

• 会員数: 1527 万人
• 月間 PV: 約 238 億 PV
• 単純平均して、日間にすると約 8 億 pV、秒間にすると約 9,259 PVになります

次に、モバゲーの成長速度を計るため、月次推移のご報告（平成21年8月度）を見てみましょう。この資料から、2009 年 8 月時点での PV は、次のようになっています。

• 会員数: 1220 万人
• 月間 PV: 約 198 億 PV
• 単純平均して、日間にすると約 6.6 億 PV、秒間にすると約 7,638 PVになります

そうすると、2009 年 10 月から三ヶ月前経過した 2010 年 1 月には、最低でも次の数字になっていると推測されます。

• 会員数: 1800 万人
• 月間 PV: 約 280 億 PV
• 単純平均して、日間にすると約 9.3億 PV、秒間にすると約 10,802 pv になります

さすがは、モバゲーというだけあって、mixi のモバイル版よりはかなり規模が大きいです。

モバゲーの場合も夜の時間帯に約 3 倍のリクエストがあるとなると、モバゲー本体で秒間あたり約 3 万 PV になります。

モバゲーアプリはまだ公開されていないので、モバゲーの会員数のうちいったいどのくらいのユーザがモバゲーアプリが使うかは分かりませんが、すべての会員がアプリを使うことは当り前ですがありません。

おそらく、約 2 割のユーザが使って、アクセスが集中する時間帯で約 3 倍になると仮定すると、おおよそ次のくらいの規模になりそうです。

• 会員数: 約 350 万人
• 月間 PV: 約 60 億 PV
• 日間 PV: 約 2 億 PV
• 秒間最大 PV: 約 6,000 PV

モバゲーも mixi 版と同様にかなりの規模になることが分かりました。

いよいよ今年から、日本でも OpenSocial 対応を表明していたサイトが続々と実際にそれぞれのプラットフォームを公開してきました。OpenSocial 対応のアプリを開発しているのは、前でもエントリしたとおりいわゆるベンチャー企業が多いので、これだけの大きなトラフィックをいかに低コストでかつ確実にさばけるかがアプリの成功の鍵を握っていると思います。

個人的には、このような大きなトラフィックをさばくということに、とても大きな関心と興味があるので、来年はさらにもうすこし踏み込んでいかにして低コストでかつ確実にさばくか考えていきたいと思います。

それでは、よい年をおむかえください!

今日現在、PC 版とモバイル版の2種類が提供されており、PC 版は企業と個人、モバイル版は企業のパートナー契約を結んだ会社のみ開発して公開できるようになっています。

さて、mixi のモバイル版が公開された直後は、アクセス殺到にて軒並みモバイル版のアプリケーションを提供しているパートナー企業のサーバに大きな負荷がかかって、ほとんどの mixi のモバイルアプリが使えない状況になったのは記憶に新しいです。3日で約60万人ユーザも集める人気アプリも数多く登場した様子です。

今日は、もし仮に僕が 2010年1月1日に mixi モバイル版アプリを提供することになったことを想定して、インフラ面からどのくらいのアクセスをさばくことができれば問題がないかどうか調べてみました。

まず、そのために mixi の規模感を知るために、mixi から提供されている 2009年度第2四半期 決算説明資料 を参考にしてみると、次の数字が分かります。

• ユーザ数: 1792 万人
• モバイル版月間 PV: 114.4 億 PV

とても大規模な環境です。

そして、先月のニュースで「mixi利用時間急増、Yahoo！に次ぐ2位に　mixiアプリ効果 – ITmedia News」というものがありました。このニュースによれば、利用時間が2倍になって、ユニークユーザ数がそれほど変わっていないことが分かります。

mixi のユーザ数、モバイル版の PV の伸び率を調べるために、2009年度第1四半期 決算説明資料をみてみると、次の数字が分かります。

• ユーザ数: 1741 万人
• モバイル版月間 PV: 109.9 億 PV

この数字から、四半期あたりの伸び率が次のように分かります。

• ユーザ数: +約50 万人
• モバイル版月間 PV: +約5 億 PV

これらの情報から、2010 年 1 月の mixi モバイル版本体は次のような規模感になります。さきほどのニュースからユーザ数はそのまま比例して増えていく、月間 PV は2倍で増えていくことを想定しています。

• ユーザ数: 約 1817 万人
• モバイル版月間 PV:  約 120 億 PV

mixi モバイルアプリなので、mixi モバイル版本体より月間 PV は増えないはずです(当り前ですが…)。

モバイル版月間 PV を、日/秒あたりの PV にすると、次のようになります。

• モバイル版日間 PV: 約 4 億 PV
• モバイル版秒間 PV: 約 4,629 PV

mixi のユーザが全員モバイル版アプリを利用することにはなりません。現在、モバイル版アプリで一番ユーザ数の多いアプリはまちつく！mixi版 (2,258,452)で約 230 万人くらいになっています。そうすると、モバイル版アプリの利用者は、現時点で多くても約 1/9 くらいになります。

これらの情報から、mixi モバイル版アプリの場合、急激に人気になったことを想定すると、次のくらいの規模感になります。

• モバイル版日間 PV: 約 4,500 万 PV
• モバイル版秒間 PV: 約 520 PV

上の秒間は平均的な値です。mixi などのウェブアプリケーションは、必ずもっとも利用される時間帯があるはずです。おそらく、22時から24時あたりでないかと勝手に想像して、なんとなく直感で通常の3倍のリクエストが来ると想定すると、次のような規模感になります。

• モバイル版日間 PV: 約 4,500 万 PV
• モバイル版秒間 PV: 約  1,500 PV

この数字が、もっとも人気になった場合の数字になりそうです。mixi モバイル版アプリは、いわゆる人数の少ないベンチャー企業が開発しているのがほとんどなので、最初から上の規模感をさばける環境を準備するにはけっこうなコストがかかりそうです。とはいっても、上の数字はもっとも人気になった場合の数字なので、必ずしも最初から上の規模感をさばけるインフラを準備しておく必要はないはずですが、最高で上のぐらいの規模感になりそうだということがおおよ想像できます。もちろん、実際に公開してみないことには人気が出るのか出ないのか、どのくらいのリクエストが来るのかは分かりませんが、こうして mixi から提供されている情報やニュースなどでおおよその規模感を把握することができるので、とりあえずなんとなくすこしのインフラを準備して公開するよりはよっぽどましだと思います。

次は、同じようにモバゲーも調べてみたいと思います。

自分のサービスで、自作サーバを使うメリットとデメリットを考えてみました。

まずは、メリットは、id:stanaka さんのオープンニングキーノートで述べられていますが、この点について考えてみます。

• 自分のサービスにあった自分好みの自作サーバとしてカスタマイズできる

この点についてはまさにそのとおりで、自作サーバをするうえでの最大のメリットであると言えるでしょう

たしかにベンダー製サーバは、BTO である程度、搭載部品を選択できても、無駄な部品が搭載されていることは確かなことです

• SSD を搭載して大胆な構成がとれる

例えば最近 DELL でも SSD を搭載できるモデル（PowerEdge R510）が登場してきているため、SSD だけでは自作サーバを使うメリットはなくなってきている状況だと思います

• 複数の NIC、冗長電源、IPMI （一部のサーバには必要）は不要

たしかにほとんどのサーバには複数の NIC は不要なケースが多いです

僕は DELL サーバをメインで使っていますが、たしかに NIC 4 つとか搭載されていても使っていませんし

冗長電源は、DELL の場合はカスタマイズでなしにすることができます

IPMI は個人的にはないと困る機能です、もしサーバに何らかのトラブルが発生してデータセンター現地にいって該当のサーバにディスプレイをつないで作業する工数と IPMI 経由で作業する工数を比べると、はるかに後者の工数のほうが少ないはずです

• コスト安

はてなさんのウェブサーバスペックで、サーバ1台あたりの単価は8万円程度

それ以外に発生するコストとしては、サーバの部品調達と組み上げコストが発生します

さらに台数が増えることで管理コストが増大します、台数が増えてもある程度管理コストを増やさない仕組みが必要そうです

次に、デメリットを考えてみましょう。

• 1台あたりのスペックが低い

はてなさんのサーバスペックは、CPU Core2Duo 4core、8GB RAM(ECCなし)、ハードディスク x 1、のスペックで 1U ハーフ、消費電力は 1.1A くらいになっています

1U あたりで考えると、この2倍のスペックになりますが、この2倍のスペックになってやっと現在のベンダー製サーバと低標準スペックになりますし、消費電力は 2.2A になることを考えると若干消費電力が大きくなるといえます

自作サーバの場合は、ラックあたりに多くの自作サーバを詰め込む傾向になってきます

• 自分達でトラブルを解決する必要がある

ハードウェアの相性トラブルなどを自分達で解決できなければなりません

例えば DELL なら、無料電話サポートでエンジニアを派遣して解決してもらうこともできますし、部品(CPU やマザーボードなど)が壊れた場合は通常で3年間は無料で交換してくれます(部品は、都内だと5時間くらいで配達してくれます)

メリットとデメリットがあるので、あとはどちらを選択するのかが大事だと思う。

個人的には、自作サーバを導入するなら、次の環境が必須だと思った。

• インフラチームなる、サーバだけ見ている人たちがいる
• 自作サーバでのサービス運営を容認してくれる企業文化

ということで、今の僕の環境は一人でアプリケーション開発とインフラを見ているので、インフラチームがないという点でとても不可能だと思った。

最後に、個人的に自作サーバを入れるところは、やっぱりストレージサーバかなと思う。ストレージサーバは、容量を増やすことでいっきに価格も変わってくるし、管理ツールはベンダー独自のものを使わなければならないという状況が多い様子だから。

いずれにしても、自作サーバだけではやっぱり無理な部分もあって、自作サーバとベンダー製サーバあるいはクラウド、要所要所でもっとも適したものを使っていくというが大事だと思う。

例えば、はてなさんはかなりベンダー製サーバとのコストも気にしている様子だったので、自作サーバだけに特化せずに大きな視点で物事を見ることも、とても大切だと思う。

僕は、ベンダー製サーバを選定して運用している経験しか今のところないので、これからも情報共有できるととても幸せだと思う。

かなり遅くなりましたが、個人的な自作サーバカンファレンスを振り返っての感想でした。サーバって、本当に奥が深いですね。

約36分ほどと、Google TechTalk の中では短い部類に入りますので、興味のある人はチェックしてみるとよいでしょう。

# wordpress 2.9 では、YouTube などの動画サイトの URL を張り付けるだけで動画をブログに貼ることができるので、とても便利ですね。

architecture: ハードウェアの種類です。hardwaremodel の値を利用して、ハードウェアの種類を取得します(i386 or x86_64 or amd64)

Cfkey: /usr/local/etc/cfkey.pub の値です(おそらく、CfEngine  のときに使われていた値だと思われます)

domain: ドメイン名です。hostname の値から取得しています。

ec2: EC2 のシンボル名(ID) です。

facterversion: Facter のバージョンです。

fqdn: FQDN(ホスト名.ドメイン名)です。

hardwareisa: プロセッサーの種類です。uname -p の出力です。

hardwaremodel: ハードウェアの種類です。uname -m の出力です。

hostname: ホスト名です。hostname コマンドの出力です。

id: id です。whoami コマンドの出力です。interfaces: NIC の種類です。eth0,eth1 のように取得できます。

ipaddress: ip アドレスです。ifconfig コマンドの出力から 127. で始まる以外の最初の IP アドレスを取得します。その他の IP アドレスは、「ipaddress_NIC」で取得できます。

iphostnumber: OSX のみ有効な値で、MAC アドレスを取得しているようですが具体的な値は不明です。

kernelmajversion: カーネルのメジャーバージョンです。例えば、「2.6」のような値になります。

kernel: カーネルの種類です。uname -s の出力です。

kernelrelease: カーネルのバージョン+リリース番号です。uname -r の出力です。

kernelversion: カーネルのバージョンです。kernelrelease の – の前の値を取得しています。

lsbmajdistrelease: ディストリビューションのメジャーバージョンです。

lsb: LSB(Linux Standard Base) の値です。

macaddress: MAC アドレスです。

macosx: Mac OS X のシステムプロファイラから取得できる値です。具体的な値は不明です。

manufacture: ハードウェアの製造業者です。dmidecode コマンドから Manufacturer: の値を取得しています。

memoryfree: メモリと空き容量です。

memorysize: メモリのサイズです。

netmask: サブネットマスク値です。各 NIC ごとのサブネットマスク値は「netmask_NIC」で取得できます。

network: ネットワークアドレスです。各 NIC ごとのネットワークアドレスは「network_NIC」で取得できます。

operatingsystem: オペレーティングシステムの種類です。/etc にオペレーティングシステムのリリース情報から判断しています。

operatingsystemrelease: オペレーティングシステムのバージョンです。

path: 環境変数 PATH の値です。

physicalprocessorcount: 物理的な CPU の数です。/proc/cpuinfo から算出しています。

processor: プロセッサの種類です。具体的な値は不明です。

productname: 機種名です。

ps: ps コマンドです。Linux だと、ps -ef となっておかしい値になります。

puppetversion: インストールされている Puppet  クライアントのバージョンです。

rubysitedir: site_ruby の場所です。

rubyversion: ruby のバージョンです。

selinux: SELinux の状態です。無効なときは、false になります。

sshdsakey/sshrsakey: SSH のホスト鍵です。

swapfree: スワップの空き容量です。

swapfize: スワップのサイズです。

timezone: システムのタイムゾーンです。

uniqueid: 一意な ID です。hostid コマンドの出力です。

uptime: システムの起動時間です。/proc/uptime の内容です。

uptime_days: 起動日数です。

uptime_hours: 起動時間数です。

uptime_seconds: 起動秒数です。

virtual: 仮想環境の種類です。仮想環境ではないときは「false」になります。Xen、OpenVZ、VMware に対応しています。

こうしてみると、facter ではかなりの値を取得できるようになっています。

facter 変数だと、puppet 以外にもシェルスクリプトや ruby プログラムから簡単に参照できるので重宝しそうです。

資料の中で、次のようなカスタム facter を定義していましたが、なんと facter 1.5.7 には manufacture 変数が用意されていました。

if $bios_vendor == “dXXX Inc.” {

include dell

}

用意されている manufacture を使うと、次のようにまったく同じにできます。

if $manufacture == “dXXX Inc.” {

include dell

}

facter の該当のソースコードを読むと、僕が作ったカスタム facter と dmidecode(8) コマンドを使っていたので処理的にはまったく同じです。

ただし、仮想環境上の場合、manufacture 変数すら表示されないので要注意しましょう。

とはいっても上のコマンドはまったく問題なくとおりますが、facter コマンドで facter 変数一覧の中では表示されないので気がつかない可能性もあるという意味です。

デフォルトに組み込まれていることは知らなかったのが恥ずかしい限りなので、次回は facter 一覧をまとめてみます。

1. cobbler のサーバで DomU として使う system を作成する

$ sudo cobbler system add –name=<仮想マシン名> –profile=<プロファイル名> –virt-type=xenpv –virt-cpus=1 –virt-ram=2048 –virt-file-size=200 –virt-path=/var/lib/xen/images/<仮想マシン名>.img –virt-bridge=xenbr0

上の例では、準仮想化ドメインとして CPU 数 1、搭載メモリ容量 2048MB、ハードディスク容量 200GB、仮想ブリッジを xenbr0 とした仮想マシンを構築するという意味になる。

2. Dom0 上に koan をインストールする

$ sudo yum instal koan

3. koan コマンドを使ってコマンド一発で仮想マシンをインストールする

$ sudo koan –server= –system=<仮想マシン名> –virt –nogfx –virt-path=/var/lib/xen/images/<仮想マシン名>.img

なぜか system に virt-path が設定されている状態でも koan コマンドに virt-path を指定しないとエラーでインストールできなかった。

4. DomU をインストール後、DomU が自動的にシャットダウンしてしまうので、DomU を起動する

$ sudo virsh start <仮想マシン名>

koan コマンドのパラメータは、次のとおり。

koan –server=hostname [--list=type] [--virt|--replace-self|--display]
[--profile=name] [--system=name] [--image=name] [--add-reinstall-entry]
[--virt-name=name] [--virt-path=path] [--virt-type=type] [--nogfx]
[--static-interface=name] [--kexec]

–virt-name 作成する仮想マシンの名前(省略した場合はプロファイル名が使われる)
–virt-type 作成する仮想マシンの種類(xenpv or xenfv or qemu or vmware)
–virt-ram メモリ容量(MB 単位)
–virt-bridge ブリッジデバイス名
–virt-path 仮想マシンファイルを保存する場所(パーティション、ディレクトリ、LVM ボリュームの設定が可能)
–no-gfx VNC グラフィックスを使用しない(Xen のみ)

koan 超便利です。

# 先日の techlife@cookpad の内容は、これを応用した Xen DomU の自動インストールの仕組みです

僕は、基本的にシェルスクリプトでがんばって作成しています。次のようなシェルスクリプトの雛型を準備しています。

#!/bin/sh

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2
STATE_UNKNOWN=3
STATE_DEPENDENT=4

echo “Status is OK”

exit $STATE_OK

exit する前に echo すれば、その情報を Nagios の管理画面の Status Information で確認することができます。

この雛型シェルスクリプトを使って、DELL 製サーバのハードウェア RAID の確認とその BBU の状態を監視しているスクリプトを作成しました。

• check_dell_storage_battery
• check_dell_storage_pdisk

実はかなり前(Velocity が終わった直後)に翻訳したものなのですが、すっかり公開するのも忘れていたので、LT にあわせて公開しました。

Puppet によるインフラ管理入門

原本は、次のワークショップです。

Introduction to Managed Infrastructure with Puppet: Velocity 2009 – O’Reilly Conferences, June 22 – 24, 2009, San Jose, CA

このワークショップでは、Puppet を実際に触りながら Puppet  の理解を深めていくという内容のワークショップです。

とても Puppet 入門に適している内容だと思いますので、ぜひ会社の中などで Puppet 入門勉強会の資料として使ってもらえばうれしいです!

僕も自分の会社で Puppet 入門勉強会を開催して、そこで資料として使いました。

monit の logfile を設定すると、monit でチェックしている対象のプロセスを再起動したときなどにログに情報がたくさん出力されているので、logrotate しておいたほうがいいでしょう。

monit の logfile を /var/log/monit に設定した場合は、次のような内容で /etc/logrotate.d/monit を作成します。

/var/log/monit {
missingok
notifempty
size 100k
create 0644 root root
postrotate
/bin/kill -HUP `cat /var/run/monit.pid 2>/dev/null` 2> /dev/null || true
endscript
}

今回は、実際に puppet を本番サーバへ導入するにあたって、puppet + cobbler で Xen DomU の初期設定まで自動化しているのですが、その内容について話しました。puppet は便利なのですが、まだまだ自分のインフラでいけていないところばかりなので、引き続き改善し続けていきたいと思います。

動画もそのうち公開されているようですので気になる人はクックパッド開発者ブログや @techlifecook を参考にするとよいでしょう。

また、mizzy さんの資料もアップロードされていますので、チェックしておきましょう。mizzy さんの発表にもあった exec 脳には、自分も sysctl.conf の変更をまったく同じふうにしていたので file リソースを使うように変更しておきたいと思います。

# 追記:

puppet の情報を日本語に翻訳したい文章があるので、パペウィキ の編集アカウントがほしい！

この Velocity のオンラインカンファレンスですが、今年は次の内容で開催されるということで、さっそく申し込んでみました。

• パフォーマンスの影響度：ウェブのスピードをオンラインビジネスにどのような影響があるのか(Performance Impact: How Web Speed Affects Online Business KPIs + Q&A)
• SPDY の紹介(Introduction to SPDY)
• 延期された JavaScript の評価を通して高速なロード時間にする(Faster Load Times Through Deferred JavaScript Evaluation)
• デフォルトで Rails を高速にする(Making Rails Even Faster by Default)
• ロードバランシングと Varnish を使ったリバースプロキシ(Load Balancing & Reverse Proxies with Varnish & More + Q&A)
• ブラウザスコープ: よいブラウザにプロファリングする方法(Browserscope: Profiling the Way to a Better Browser)
• 10,000フィートからの CouchDB(CouchDB from 10,000 ft + Q&A)
• オペレーションの座談会(Operations Roundtable)

日時は、US-PST（太平洋標準時）で 12/8（火）9:00am – 12:40am なので、日本時間にすると 12/9（水）午前 2:00 – 5:40 になります。かなり深夜から早朝にかけて行われることになります。

料金は、$149 なのですが、通常で $25 の割引があります。また、過去の Velocity の参加者は $50 の割引があります。僕は、過去の Velocity 参加者なので、メールして特別なクーポンコードを発行してもらいました。さらに今回の Velocity Online Conference Fall 2009 の参加者には、次回の Velocity の 25% 割引という得点もあるので次回 Velocity に参加する人は参加するとよいと思います。

今回のオンラインカンファレンスの中では、Rails、Varnish、座談会の話がもっとも興味あります。

今から、とても楽しみです！