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、座談会の話がもっとも興味あります。

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

まずは、準備するところから。

1. InsomniaX 1.3.5 をインストールして起動しておく
2. MacBook Pro の Mini Display Port と外付けディスプレイを接続する
3. ディスプレイの表示モードをミラーにする

これで準備完了です。

1. MacBook Pro の Mini Display Port から外付けディスプレイをはずす
2. InsomniaX を有効にする
3. MacBook Pro の LCD を閉じる（このときは、MacBook Pro 本体の LCD は点灯している）
4. MacBook Pro に Mini Display Port <-> VGA 変換ケーブルを接続する

ポイントは、3 と 4 の順番です。この順番を逆にしてしまうと、MacBook Pro 本体の LCD が点灯してしまい、本体側の解像度になってしまうので注意してください。

ちなみに作業を終了するときの手順は、次のとおりです。

1. MacBook Pro の Mini Display Port と外付けディスプレイの接続をはずす
2. InnosomniaX を無効にする
3. InnosomniaX のメニューあるいは、MacBook Pro 本体の LCD を閉じてシステムのスリープ状態にする

MacBook のころは順番に関係なくできていたのですが、MacBook Pro になってからできなくなってしまったのかなぁと思ったのですができる方法が見つかってよかったです。

これでデスクの大きなディスプレイのみで MacBook Pro を使うことができます。

repoview というプログラムも EPEL と同様にはじめて知ったので、さっそく使っていました。

まず、repoview のインストールは、EPEL からパッケージが提供されているので、簡単にインストールすることができます。

$ sudo yum install repoview

repoview をインストールすると、/usr/bin/repoview コマンドがインストールされます。repoview コマンドを使って、yum リポジトリにあるパッケージ一覧を取得してパッケージ一覧ページすることができます。

repoview コマンドの使い方は、次のとおりです。

$ repoview –help

使い方: repoview [オプション] リポジトリディレクトリ

オプション：
–version プログラムバージョンを表示して終了します
-h, –help ヘルプメッセージを表示して終了します
-i IGNORE, –ignore-package=IGNORE “foo-0-1.0-1″のように無視したいパッケージ名を指定します
-x XARCH, –exclude-arch=XARCH “-x src -x ia64″のように無視したいアーキテクチャーを指定します
-k TEMPLATEDIR, –template-dir=TEMPLATEDIR repoviewディレクトリのテンプレートディレクトリを指定します（デフォルトは、/usr/share/repoview/templates です）
-o OUTDIR, –output-dir=OUTDIR repoviewページを生成したときのサブディレクトリ名です（デフォルトは、”repoview” です）
-s STATEDIR, –state-dir=STATEDIR このディレクトリに生成する状態トラッキングデータベースを入れるディレクトリ名です（デフォルトは、出力先ディレクトリに出力します）
-t TITLE, –title=TITLE リポジトリの説明用のタイトルを指定します（デフォルトは、”Repoview” です）
-u URL, –url=URL     RSS Feed を生成するときの URL を指定します、例えば “http://fedoraproject.org/extras/4/i386″ と指定します、指定しない場合は RSS の生成がスキップされます
-f, –force     repmod のチェックサムが変更されていなくても、強制的に再生成します
-q, –quiet    致命的なエラーを除いて、何も出力しないようにします
-c COMPS, –comps=COMPS    comps.xml ファイルを使うときに指定します（デフォルトは、オフです）

例えば、cobbler で管理しているリポジトリの場合は、次のように使います。

$ sudo repoview -t “yum.example.com – x86_64″ -u “http://exmaple.com/cobbler/repo_mirror/hoge-x86_64/repoview/” /var/www/cobbler/repo_mirror/hoge-x86_64

なお、reposync してしまうと repo_mirror ディレクトリがリセットされてしまうので、createrepo したあとは、再度 repoview を実行する必要があります。

独自にローカル yum リポジトリをたてている場合、repoview を使うと提供しているパッケージ一覧がチェックでき、いつどんなパッケージを追加したのか、後から分かるのでとても便利です。

EPEL とは、次のようなリポジトリです（About EPEL から意訳）。

エンタープライズ Linux 用の拡張パッケージ（略して EPEL）は、Fedora プロジェクトからのボランティアベースの貢献によって作成された Red Hat Enterprise (RHEL) 向けの高品質な追加パッケージのリポジトリで、CentOS あるいはその他同等の Linux 互換になっています。Fedora は RHEL の上流であり、EPEL 向けの追加パッケージは Fedora リポジトリを起源にしており RHEL 向けに提供されています。

ということで、高品質な追加パッケージが提供されている便利なリポジトリです。

以前、rpmforge というサードパーティ製のリポジトリを使っていたことがあったのですが、一部のパッケージでトラブルが発生して以来使っていませんが、EPEL は高品質そうなので、さっそく CentOS に導入してみました。

まず、EPEL の RPM をダウンロードします。

$ wget http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noarch.rpm

$ sudo rpm -i epel-release-5-3.noarch.rpm

EPEL パッケージをインストールすると、/etc/yum.repos.d/epel.repo がインストールされて EPEL の yum リポジトリを使うことができます。

例えば、ganglia パッケージを取得してみると、次のようになります。

$ sudo yum info ganglia

Available Packages
Name       : ganglia
Arch       : i386
Version    : 3.0.7
Release    : 1.el5
Size       : 91 k
Repo       : epel
Summary    : Ganglia Distributed Monitoring System
URL        : http://ganglia.sourceforge.net/
License    : BSD
Description: Ganglia is a scalable, real-time monitoring and execution environment
: with all execution requests and statistics expressed in an open
: well-defined XML format.

Name       : ganglia
Arch       : x86_64
Version    : 3.0.7
Release    : 1.el5
Size       : 91 k
Repo       : epel
Summary    : Ganglia Distributed Monitoring System
URL        : http://ganglia.sourceforge.net/
License    : BSD
Description: Ganglia is a scalable, real-time monitoring and execution environment
: with all execution requests and statistics expressed in an open
: well-defined XML format.

EPEL で提供されているパッケージ一覧は、x86_64 の場合はここから確認することができます。提供パッケージ一覧をざっと見たところ、nagios、monit、ganglia、memcached、munin、など公式では提供されていないたくさんのパッケージが提供されています。いずれも品質重視のためか、バージョンが若干古いですが、自分でパッケージを作成する手間を考えると、とても便利な yum リポジトリといえるでしょう。

今後は、EPEL は本番環境でもミラーして使っていきたいと思いますが、何かの事情で新しいバージョンを必要になったときには EPEL から SRPM を取得して改良する方針にしていこうかなと思います。

今回は、次のタイトルで発表がありました。

• PostgreSQL安定運用のコツ2009 永安悟さん
• DBサーバーのパフォーマンスチューニング 松信嘉範さん (Open database life)

個人的には、業務ではほとんど MySQL を使っていますが、すこしだけ業務 PostgreSQL を使ったことがあります。

PostgreSQL の話は、かなりボリュームのある内容を1時間という限られた時間の中で発表してくださいました。PostgreSQL のアーキテクチャーの話、Vacuum、PostgresQL の設定をする上のポイントなど、かなり実践投入向きな説明で勉強になりました。PostgreSQL を使う機会があったら、改めてポイントを確認したいと思います。

次の MySQL の話は、松信さんの話ということで、かなり期待していましたが、期待以上の話でした。

以下、メモになります。

• いかにしてデータベース内のデータサイズにしていくかが重要
• カラムの型は、最低限のものにする
• Blog/Text は、無駄になることが多い
• InnoDB は、ブロック単位の I/O になって、ブロックにはレコードがそれぞれ含まれている
• 違うテーブルは、必ず別のブロックになる
• Falcon は、TEXT 型の列を別領域に保存する
• PBXT は、一定以上の長さの列を別領域に保存する
• Explain の Using Index があると、Index が使われていることになる
• MySQL 5.1.41 に含まれている InnoDB plugin 1.0.5 には、innodb_old_blocks_time というパラメータが追加されているが、これは InnoDB の old という領域に保存していく時間をミリ秒単位で指定することができる（SET GLOBAL innodb_old_blocks_time = 1000; で設定することができる)
• Linux のチューニングのポイントは、次のとおり

/proc/sys/vm/swappiness = 0;

0 ならファイルシステムキャッシュ優先、100 なら A 優先（デフォルトだと 60）

ext3: InnoDB なら writeback でもあり (double buffer)、dir_index, noatime(realtime)

xfs: 実績が少ないとのこと

ext2: あえて ext2 を使う、ジャーナリングが無いための高速（kazuho さんは、ext2 を使っているとのこと）

btrfs(zfs): コピーオンライト

cat /proc/net/dev, mtstat = dstat

• SSD もライトキャッシュが必要だが、RAID コントローラーが SSD に最適化されていないといけないの要注
• PCI-E 型の SSD にも、高価だが注目するとよい
• HDD を使っているときは、あえて full table scan するという選択肢もある
• メモリが何よりも最速

ということで、自分の過去のデータベース設計に後悔したことは言うまでもありませんが、データベースのチューニングまわりは参考になる話ばかりでした。

MySQL を使っている以上、InnoDB ストレージエンジンの構造は理解しておくべきだと思いました。

hbstudy #6 の当日の資料は、それぞれ公開されています。

• PostgreSQL安定運用のコツ2009
• DBサーバーのパフォーマンスチューニング

開毎回必要なパッケージを、メッセージを確認してから手動でインストールするのがかなりめんどうになってきたので、簡単な rpmbuild のラッパースクリプト auto-rpmbuild.sh を書いてみた。

このスクリプトでは、おもに次のような機能を提供します。

• 指定された SPEC ファイルが存在しない場合は、.rpmmaros の topdir/SPECS を自動的に参照する
• rpmbuild –nobuild で RPM のビルドをテストしてエラーだった場合のメッセージが、「** is needed by **」の場合は、必要なパッケージ sudo yum install でインストールする

auto-rpmbuild.sh の使い方は、rpmbuild とまったく同じで、次のように使います。

$ auto-rpmbuild.sh -ba ~/rpmbuild/SPECS/hoge.spec

もしくは、SPEC ファイルのフルパスを指定するのがめんどくさいという場合は、次のように実行します。

$ auto-rpmbuild.sh -ba hoge.spec

実は、このラッパースクリプトを作成する前に、既存のツールでできないかどうか調査したところできない様子だったので、ラッパースクリプトを作成しました。

auto-buildrequires という、まさに * それ * っぽいものを見つけたのですが、これは RPM をビルドしたあとに BuildRequires に指定するべきパッケージ一覧を列挙するツールのようだったので、今回の要件にあいませんでした。

個人的には、あまり野良スクリプトを増やしたくないので、もし既存のツールでできるようであれば、ぜひコメントで教えてください！

CentOS の logwatch を無効にするには、/etc/cron.daily/0logwatch を削除するだけです。

puppet だと、次のように記述します。

file { “/etc/cron.daily/0logwatch”:
ensure => absent,
}

これで、logwatch を毎朝実行しなくなるので、logwatch のメールが受信しなくてすむようになりました。

一人でサーバ運用していると、こういった日々の小さな改善が大事になってくると、しみじみと思いました。

サーバの消費電力を計測するには、クランプメータという機械が必要です。

今回は、小型クランプメータの三和電気計器の DCL10 を購入してみました。これにした理由は、そこそこの精度で、価格も安いからです。あと、あわせてラインセパレーターもあわせて購入しました。ラインセパレーターを使うと、感度倍率を1倍あるいは10倍にして測定することができます。

もちろん、インフラエンジニアたるもの自分で持っていたいということで、自費で購入しました。

さっそく、このクランプメータとラインセパレーターを使って、業務で使用している DELL のサーバの消費電力を測定してみました。

測定方法は、次のとおりに行いました。

• サーバの電源ケーブルとコンセントの間に、上のラインセパレーターを挟んで測定する
• CentOS 5.x x86_64 をインストールした状態で、アイドル時と stress を使って高負荷時（ロードアベレージが CPU コア数と同じくらいなったあたり）で感度倍率 10 倍のところで測定した

DELL サーバの消費電力は、次のとおりです。

DELL PowerEdge R200

• CPU: Xeon X3210 x 1
• RAM: 8GB
• Disk: SATA 160GB x 1
• idle: 1.08A
• max: 1.53A

DELL PowerEdge R300

• CPU: Xeon L5410 x 1
• RAM: 8GB
• Disk: SAS 300GB x 1
• idle: 0.99A
• max: 1.30A

DELL PowerEdge 1950 III（販売終了モデル）

• CPU: Xeon L5410 x 2
• RAM: 8GB
• Disk: SATA 1TB x 1
• idle: 1.60A
• max: 2.36A

DELL PowerEdge SC1435（販売終了モデル）

• CPU: Opteron 2376 x 2
• RAM: 8GB
• Disk: SATA 1TB x 1
• idle: 1.46A
• max: 2.27A

DELL PowerEdge R610

• CPU: Xen L5530 x 2
• RAM: 16GB
• Disk: SATA 500GB x 2 (HW RAID 10)
• idle: 1.32A
• max: 2.06A

所感は、次のとおり。

• Xen 5500  番台の低電圧版（L がついているもの）は、かなり消費電力が少ない
• Xen 3200 番台（今は 3300 番台）は、消費電力が大きいが、Xeon 5400 番台低電圧版もそれほど大きく変わらない

来週には、R410 を試しに導入してみる予定ですが、R610 の CPU と同じなのでほぼ変わらないはずです。

サーバの消費電力をちゃんと測定して、よりよいサーバ運用をめざしたいものですね。

# 2009.11.12 追記

• ディスク情報を追記しておきました

• NOZEROCONF を設定する

余計なネットワーク経路を作らないために、/etc/sysconfig/network に次の設定を追加します。APIPA という仕組みを使う場合は必要です。

NOZEROCONF=yes

• IPv6 を無効にする

IPv6 を使っていないので、/etc/modprobe.conf に次の設定を追加します。

alias net-pf-10 off
alias ipv6 off

• ifdown-eth にバッチをあてる

bonding を使っている場合、ifdown-eth がおかしいので、次のようなパッチをあてます。bonding を使っていない場合は、特にパッチをあてる必要もないです。

/usr/bin/patch /etc/sysconfig/network-scripts/ifdown-eth << EOF
60c60,62
<
—
>     for target in \\$(cat /sys/class/net/\\${DEVICE}/bonding/arp_ip_target) ; do
>         echo “-\\${target}” > /sys/class/net/\\${DEVICE}/bonding/arp_ip_target
>     done
EOF

• SSH デーモンの設定でパスワード認証を無効にして、公開鍵認証のみに設定変更する

/etc/ssh/sshd_config に、次のようなパッチをあてます。

/usr/bin/patch /etc/ssh/sshd_config << EOF
58c58
< #PasswordAuthentication yes
—
> PasswordAuthentication no
60d59
< PasswordAuthentication yes
73,75c72
< #GSSAPIAuthentication no
< GSSAPIAuthentication yes
< #GSSAPICleanupCredentials yes
—
> GSSAPIAuthentication no
EOF

さらに、次の設定を追加します。
#
# local configuration
#
PermitRootLogin without-password
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

• 不要なサービスを無効にする

サーバ用途として、使用しないサービスを無効にします。次のような簡易スクリプトを書いておくと便利です。サービスのリストは、自分の環境で置き換えるとよいでしょう。

#!/bin/sh
function get_cmd() {
echo ‘acpid auditdi autofs avahi-daemon bluetooth cups firstboot gpm hidd ip6tables mcstrans mdmonitor netfs nfslock pcscd restorecond rpcgssd rpcidmapd sendmail xfs yum-updatesd’
}
for cmd in `get_cmd`; do
/sbin/chkconfig $cmd off
/etc/init.d/$cmd stop
done

• OOM Killer を無効にする

Linux には、メモリ不足になってしまったときプロセスを任意で強制終了させる OOM Killer という仕組みがありますが、これを無効にしてプロセスがメモリ不足で落ちるようにします。どちからというと、そのほうがお行儀がよいです。

/etc/sysctl.conf に、次の設定を追加します。

# disable OOM Killer
vm.overcommit_ratio = 99
vm.overcommit_memory = 2

• iptables を有効にして設定する

Linux のファイアーウォールである iptables を有効にして、設定します。

iptables の設定は、通常はコマンドで行うものらしいのですが、オプションがまったく覚えることができないので、/etc/sysconfig/iptables  を 600 で作成して、次の内容で作成します。

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [504:56964]
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 80 -j ACCEPT

上の設定では、内側からの接続はすべて通して、外側からの接続は SSH、SMTP、HTTP ポートだけ許可するという内容になります。

サーバの用途に応じて、開放するポートを設定します。bonding を組んでいる場合は、eth0 ではなく bond0 になります。

• Ctrl + Alt + Del による再起動を無効にする

サーバの操作中に誤って Ctrl + Alt + Del キーを押して、サーバを再起動させないように /etc/inittab に次のようなパッチをあてます。

/usr/bin/patch /etc/inittab << EOF
31c31,33
< ca::ctrlaltdel:/sbin/shutdown -t3 -r now
—
> # Trap CTRL-ALT-DELETE
> #ca::ctrlaltdel:/sbin/shutdown -t3 -r now
> ca::ctrlaltdel:/usr/bin/logger ‘CTRL-ALT-DELETE trap is disabled’
EOF

この設定をしておくと、Ctrl + Alt + Del を押したときにログに残ります。

• デフォルトの yum リポジトリを削除する

ローカルで yum リポジトリをミラーしている場合、デフォルトの yum リポジトリは不要なので設定を削除します。

/bin/rm /etc/yum.repos.d/CentOS-Base.repo
/bin/rm /etc/yum.repos.d/CentOS-Media.repo

• 管理ユーザを作成する

さきほどの SSH の設定で root による SSH 接続ができなくなるので、専用の管理ユーザを作成して SSH 経由でログインできるようにします。

/usr/sbin/useradd -g hoge -s /bin/zsh hoge
/bin/mkdir ~hoge/.ssh
/bin/chmod 700 ~hoge/.ssh
/bin/cat << EOF > ~hoge/.ssh/id_rsa
SSH の秘密鍵
EOF
/bin/chmod 600 ~hoge/.ssh/id_rsa
/bin/cat << EOF >~hoge/.ssh/id_rsa.pub
SSH の公開鍵
EOF
/bin/cat << EOF > ~hoge/.ssh/authorized_keys2
SSH 接続を許可したいサーバの SSH 公開鍵
EOF
/bin/chmod 600 ~hoge/.ssh/authorized_keys2
/bin/cat << EOF > ~hoge/.ssh/config
Host *
Compression yes
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
EOF

• su を無効にする

/etc/pam.d/su に、次のようなパッチをあてます。

/usr/bin/patch /etc/pam.d/su << EOF
6c6
< #auth         required        pam_wheel.so use_uid
—
> auth          required        pam_wheel.so use_uid
EOF

• sudo を可能にする

/etc/sudersを、次の内容で書き換えます。CentOS のデフォルトの suders の設定内容がすこしきつく、若干扱いにくいので次の内容だけにしておきます。

%hoge  ALL=(ALL)       ALL

• シリアルリダイレクトを有効にする

IPMI を SOL 経由で Linux のコンソール画面をみることができるようにシリアルリダイレクトを有効にします。

詳しい設定内容は、こちらを参照してください。

あとは、ウェブサーバ、メールサーバ、データベースサーバ、などサーバの用途に応じた設定を個別で行います。

これには、Puppet を使うとかなり便利なので、実際にどんなふうに使っているかは、別の機会に紹介したいと思います。

facter を拡張して、”hardware_platform” という変数を拡張して作る方法を公開しておきます。
なお、Puppet バージョン 0.24.7 を想定しています。0.25 系は方法が違うので注意してください。

まず、次のような <MODULEPATH>/modules/plugins/facter に “hardware_platform.rb” を作成します。なお、必ず作成する ruby のファイル名と facter の変数名は同じでないといけません。

# hardware_platform.rb
Facter.add(“hardware_platform”) do
setcode do
%x{/bin/uname -i}.chomp
end
end

とは、puppet の設定ファイルがあるディレクトリ、デフォルトは /etc/puppet だけれど、次のコマンドで確認できます。

$ sudo /etc/init.d/puppetmaster genconfig | grep modulepath
modulepath = /etc/puppet/modules:/usr/share/puppet/modules

ちなみにカスタム facter を置く場所はどこでも大丈夫です。
作成したカスタム facter を ruby 側でロードできるように環境編集 RUBYLIB を設定します。

$ export RUBYLIB=<MODULEPATH>/module/plugins

RUBYLIB は、ruby の検索パスなので facter まで設定しないように注意します。
この状態で、次のコマンドを実行すればカスタム facter の動作を確認することができます。

$ facter hardware_platform
x86_64

まずは、この状態でカスタム facter を作りこんでいきます。

次に作成したカスタム facter を Puppet クライアントへ配布するには、Puppet クライアントの設定が必要になります。
具体的には、puppet.conf の main セクションに次の設定を追加して puppet クライアントを再起動します。

pluginsync = true
factpath = $vardir/lib/facter

あとは、Puppet サーバと同期すれば自動的に Puppet サーバからカスタム facter を転送されてきます。転送されてきたカスタム facter は、factdest パラメータにコピーされて自動的にロードされます。デフォルトは、/var/lib/puppet/lib/facter です。

Puppet クライアントで、カスタム facter の動作をテストしたいときは、次のコマンドを実行します。

$ sudo facter -p hardware_platform
x86_64

最後に拡張した Facter は、次のように ruby プログラムから簡単に使うことができます。

require ‘facter’
puts Facter[:hardware_platform].value

0.25 系での方法は、別の機会に紹介したいと思います。

参考資料

• オープンソースなシステム自動管理ツール Puppet 第14回 Facterの拡張
• facter
• facter を拡張する方法
• Plugins in Modules