2009年、いよいよ始まりました。

今年の豊富は、次のとおりです。

• 人への思いやりを持てるようにする
• 行動力を発揮する
• モテる

今年もよろしくお願いします！

そこで、ゲスト OS を固定 IP にしてみた。

まず、ホスト OS で DHCP のレンジを見るには、 ”/Library/Application Support/VMware Fusion/vmnet8/dhcpd.conf” をみると分かる。僕の環境では、”range 172.16.123.128 172.16.123.254″ になっていた。ということで、ゲスト OS の IP アドレスを 172.16.123.127 にしてみることにした。

以下は、ゲスト OS での設定方法

• /etc/resolv.conf の nameserver を 172.16.123.2 に変更する
• eth0 のネットワーク設定 (/etc/sysconfig/network-scripts/ifcfg-eth0) を、BOOTPROTO を static に、IPADDRESS を 172.16.123.127 に変更する
• /etc/sysconfig/network の GATEWAY を 172.16.123.2 に変更する
• /etc/init.d/network restart して、設定を反映させる

1. sudo chown postgres /opt/local/var/db/postgresql83
3. sudo su postgres -c ‘/opt/local/lib/postgresql83/bin/initdb –no-locale -D /opt/local/var/d
4. b/postgresql83/defaultdb’
5. /opt/local/lib/postgresql83/bin/createuser -P -U postgres で、任意のユーザを作る
6. /opt/local/lib/postgresql83/bin/createdb -h localhost -U postgres -E EUC_JP <データベース名>

ポイントは、–no-locale を指定するところ。

• グラフィカルインストーラーでないと、Software RAID 1 + LVM の環境をセットアップできない
• cobbler でグラフィカルインストーラーにする方法は、Grapical Installs に書かれているがこの方法だとうまくいかなった、最新安定版の 1.4.0 だと /etc/cobbler/settings になるはずだけれど
• そこで、VMware Fusion にインストールしようとしたところ、メモリが 256MB にすると anaconda がメモリ不足で落ちる（最低でも 512MB 以上設定すること）
• CentOS をデフォルトでインストールすると、4GB はすぐに使いきってしまうので注意（10GB くらいはあったほうがいいかもしれない）

といろいろはまったけれど、ようやく CentOS をインストールして、Cobbler 1.4 で Software RAID 1 + LVM な kickstart インストールをできるようにする予定です。Cobbler の開発が激しく、機能も充実してきているのであとでエントリしたいと思う。

OSX を再インストールしたあとは、仕事に必要なソフトウェアをいくつかインストールするついで、今日はそのソフトウェアたちを紹介します。

次に紹介するのは、実際にインストールした順番です。

• teleport: 一言でいうと Synergy for OSX です、Synergy も OSX で動作すると思いますが teleport は OSX 専用でシステム設定から簡単に設定できるのが特徴
• InsomniaX: OSX では MacBook を閉じると必ず Sleep 状態に入ってしまうが、InsomniaX を有効にすることでそれを解除することができる、22インチの外付けディスプレイを接続してミラーディスプレイ設定をして InsomniaX を有効にしてから MacBook を閉じてディスプレイの検出をすると MacBook 側の液晶はオフになって外付けディスプレイのサイズにあわせてくれるのでかなり便利、さらに teleport と組み合わせることで HHK や Logicool マウスを使えるのがかなり便利
• iTerm: Terminal.app は 256 色対応していないので、重宝しているターミナルプログラム、アップデートがまだまだ激しいのでまだまだ開発が進んでいる、iTerm は開くデスクトップを固定して使っている、設定を外部に保存できないのが不便
• Emacs: エディタ、OSX 向けには Carbon Emacs などいろいろな Emacs があるけれど、僕はほぼ公式の Emacs をビルドしたものを使っている理由は my .emacs が Carbon Emacs で動作せずに対応するのがめんどうだったから、定期的にアップデートされているのでチェックしたほうがいいかも
• KeyRemap4MacBook: キーリピートは速くないと効率が悪いので重宝している、Initial Wait を 200ms、Wait を 20ms に設定している、最近のバージョンからタスクバーに表示されるようになった
• MacUIM: ATOK を買う前に試してみましょう、Leopard でも動作します、Prime を使っていたけれどたまに重くなる傾向があったので今では Authy を使っています、トグルキーは Shift-Space を愛用しているので Spotlight のショートカットキーとかぶってしまうので無効にしている
• Quicksilver: アプリケーションの起動やローカルにあるヘルプファイルの参照に使っている
• SIMBL: これがないと始まらないです
• visor: 基本的には iTerm だけれど、日本語の文字コードを設定を切り替えるのがめんどうなので Terminal.app だけ EUC-JP にしている、visor を使うとコマンド一発で起動できるので便利
• TerminalCopyOnSelect: iTerm だとデフォルトで実現しているけれど、かんり便利なのでインストールしている
• TerminalColoreopard: 個人的に ANSI カラーが見にくいのでインストールしている
• iPhone SDK: Xcode 単体でもよいけれど、開発には必須
• MacPorts: 仕事に必要な MySQL や PHP などをインストールするのに必須、ない場合は手軽に自分で作れるのも便利 … インストールする ports: zsh-devel, screen, SSHKeychain, mysql5-devel, postgresql83, apache2, php5, svk などなど
• Ruby Enterprise Edition: rails アプリを開発しているので、passenger も自動的にインストールされて便利
• macfuse, sshfs-static-leopard: SSHFS は超絶便利、まとめて sshfs でマウントできるように簡単な autometer アプリケーションを書いている
• StartupSound: OSX の起動音を制御できるソフト、あの起動音はびびることが多いのでオフにしている
• iStat menus: CPU、メモリなどの使用状況をリアルタイムにチェックできるプログラム

あとは、Firefox、Opera、Adium、Skype、OpenOffice の定番ソフトをインストールした。

MacPorts にある zsh にシェルを切り替えるには、/etc/shells に /opt/local/bin/zsh を追加して chsh -s /opt/local/bin/zsh で OK。

引き続き、Safari、Firefox のウェブ開発環境を整えるとする。

Windows の IE も必要だが、Corssover を試してみる。

CentOS 5.2 x86_64 の場合、 /etc/sysconfig/sysstat の HISTORY を次のように書き換えればいい。

# How long to keep log files (days), maximum is a month

HISTORY=28

デフォルトだと、最大1週間分しか保有されないので一ヶ月分にしておくと何かあったときに便利になる。なぜ、28 なのかは /usr/lib64/sa/sa2 のシェルスクリプトを見ると分かります。

1. 9/22: 導入 - Introduction
2. 9/24: フロントエンド側のパフォーマンスの重要性について - The Importance of Frontend Performance
3. 9/26: HTTP ウェブサイトの 100 のパフォーマンスプロファイル - HTTP Web 100 Performance Profile
4. 9/26: 開かれたウェブのパフォーマンス挑戦 - Performance Challenges for the Open Web
5. 10/1: フロントエンドカンフー - Front End Kung Fu
6. 10/3: 高いパフォーマンスのウェブページ - Netflix のケースで考える実例 - High Performance Web Pages - Real World Examples: Netflix Case Study
7. 10/6: Alexa ランキングトップ 100 のウェブサイト - Class Project: Improving a Top 100 Web Site
8. 10/8: HTTP リクエストを少なくする - Make Fewer HTTP Requests
9. 10/10: CDN を使う - Use a Content Delivery Network
10. 10/13: Expires ヘッダーを追加する - Add an Expires Header
11. 10/15: Gzip コンポーネント - Gzip Components
12. 10/17: 先頭にスタイルシートを配置する - Put Stylesheets at the Top
13. 10/20: 末尾にスクリプトを配置する - Put Scripts at the Bottom
14. 10/22: DNS 検索を減らす - Avoid CSS Expressions Reduce DNS Lookups
15. 10/24: 外部に JavaScript と CSS を作る - Make JavaScript and CSS External
16. 10/27: JavaScript を最小化する - Minify JavaScript
17. 10/29: リダイレクトを無効にする - Avoid Redirects
18. 10/31: 中間試験 - MIDTERM EXAM
19. 11/3: Ajax のパフォーマンス - Ajax Performance
20. 11/5: 重複している Script を削除する - Remove Duplicate Scripts
21. 11/7: ETags の設定 - Configure ETags
22. 11/10: Ajax をキャッシュされる＆初期ロードを分割させる - Make Ajax Cacheable & Split the initial Payload
23. 11/12: ブロックせずにスクリプトをロードする - Load Scripts Without Blocking
24. 11/14: インラインスクリプトをばら撒かない - Don’t Scatter Inline Scripts
25. 11/17: 大規模環境での高速なデータのスケール - Facebook から学ぶ - Fast Data at Massive Scale - lessons learned at Facebook
26. 11/19: 主要なドメインを共有する - Shared Dominant Domains
27. 11/21: イメージの最適化、Iframe を控えめに使う、ドキュメントを早めにフラッシュする - Optimize Images, Use Iframes Sparingly, Flush the Document Early
28. 12/1: クッキーを自由にして固定リソースを出す、クッキーの重みを減らす - Serve Static Resouces Cookie-Free, Reduce Cookie Weight, To WWW or not to WWW
29. 12/3: CSS 子孫セレクタで、圧縮を強制する - CSS Descendant Selectors, Forces Compression
30. 12/5: パフォーマンスの状態 - State of Performance
31. 12/9: 最終試験 - FINAL EXAM
32. 12/12: 最終試験 - FINAL EXAM

ということで、Yahoo! から公開されている有名なウェブサイトのパフォーマンス Tips を含めた各テクニックを1つの講義で行ったり、実例から学んだりと、とても面白そうな講義になっている。それぞれの講義には、必ず宿題があったり、試験も公開されていて、かなり興味深い。

資料はほとんど公開されているけれど、数が多いので自分の興味のあるものをみてみるといいと思う。

僕は、とりあえずすべての資料に目を通してみたので、講義ごとにメモしておこう。

Intoroduction では、Yahoo! から Google に移籍した「ハイパフォーマンスWebサイト」の著者でもある Steve Sounders 氏の講義。ハイパフォーマンスの 14 のルール、Y! Slow などを紹介している。

The Importance of Frontend Performance では、iGoogle を例にあげて 8 割から 9 割のエンドユーザへの応答時間は、フロントエンド側で費やされていることをあげて、HTTPWatch という Windows 専用のパケットスニッファ、Firebugs、Y Slow を紹介している。

HTTP Web 100 Performance Profile では、HTTP の基礎的な解説のみで、宿題が5つのウェブサイトについて Y Slow などでパフォーマンスを計測するというもの。そのときのシートも公開されている。

Performance Challnges for the Open Web では、Plaxo でやっている OpenID や Google Social Graph API や OpenSociel などについての解説。これはゲスト講義だったようだ。

High Performacne Web Pages - Real World Examples: Netflix Case Study では、Netflix という実際のウェブサイトでのパフォーマンスを向上させたときの事例が解説されている。Firebugs にクライアント側のパフォーマンスデータを計測するプラグインがあることは初めて知った。

さらに Jiffy Firebug の拡張を使うと、onLoad の時間などより詳しい計測ができるようになるらしい。

43 ページ目の Gzip 圧縮、Expire ヘッダーの追加、Etags を設定したことによってネットワークトラフィックが約半分になったという結果はとても興味深い。

Class Project: Improving a Top 100 Web Site では、これまでの講義を振り返りつつ、Alexa ランキングトップ 100 のパフォーマンスを改良するクラスプロジェクトを行ったらしい。

Make Fewer HTTP Requests では、HTTP リクエストを減らすために CSS sprites、base64 でエンコードしたインラインイメージデータ、のテクニックが解説されている。

Use a Content Delivery Network では、リバースプロキシとして CDN を使うことについて解説されている。

Add an Expires Header では、Expires ヘッダーを追加することについて解説されている。Expires ヘッダーを使うと、ブラウザ側にキャッシュを持たせることができるので、HTTP リクエストを減らすことにつながるのは既知のとおり。

個人的な体験では、Expires ヘッダーをはじめて追加したとき、それほど大規模サイトではないのでいきなり長い期間を設定してしまって大きな失敗をしたことがある。特に Expires ヘッダーを後から追加するときは、短い期間（たとえば1時間など）からゆっくりと設定しながら伸ばしていくのがいいと思う。

Gzip Components では、Gzip 圧縮について解説されている。Gzip と Deflate の比較表は、とても参考になった。若干 Gzip の方は圧縮率が高い。1K 未満のリソースは圧縮しないほうがいいらしい。トップサイトでは、ほぼ Gzip 圧縮されている。Gzip 圧縮はいいことだけど、古い一部のブラウザ IE 5.5 & 6.0、Netscape 3.x & 4.x では問題があるので注意して、BrowerMatch は設定した方がいいとのこと。これは忘れがちなので要注意。Apache 2.0 では、次のように設定する。

# BrowserMatch ^MSIE [6-9] gzip
# BrowserMatch ^Mozilla/[5-9] gzip

Put Stylesheets at the Top では、CSS を先頭におくことで体験速度が上がる。実際に、IE や Firefox で計測した例が紹介されている。

Put Scripts at the Bottom では、スクリプトブロックについて解説されている。ブラウザごとの挙動や、IE8 & Safari 4 & Firefox 3.1 & Chrome では並列にスクリプトをロードすることができるようになるらしい。それでも、IE6 & 7 はしばらくの間使われ続けるはずなので、「put scripts at the bottom」を心に刻めということ。

Avoid CSS Expressions Reduce DNS Lookups では、Steve 氏の講義で CSS の表記によってはページをダウンロードするのが遅くなること、DNS による検索を減らすルールについて解説されている。トップサイトの TTL は、ほとんど 1 分など短く指定している。ブラウザの DNS キャッシュは IE7 では 30 分、Firefox 2 では 1 分であるらしい。

Make JavaScript and CSS External では、JavaScript と CSS は inline としてページ内で定義するのがいいのか、それとも external として外部で定義するのがいいかについて解説されている。

• inline: 高速だが、HTML ドキュメントが大きくなる
• external: HTTP のリクエスト数が増えるが、キャッシュされる

ということで external がほとんどの場合よさそうということ。

Minify JavaScript では、JavaScript のコードからスペースなど余計な文字を除去して転送するデータ量を少なくする方法が解説されている。JSMin や YUI Compressor や DoJo Compressor を使うことで簡単に圧縮できるとのこと。トップサイトを調べた結果、約2割くらい転送するデータ量を削減できているとのこと。

Avoid Redirects では、リダイレクトについて解説されている。ヘッダーではなく、HTML ドキュメントの中にリダイレクトを挿入することはスクリプトでリダイレクトすることはよくないとのこと。HTTP ステータスコード 301 だとキャッシュされないが、一部のブラウザでは Expires を設定することがキャッシュされる。

Ajax Performance では、Ajax にまとをしぼったパフォーマンス向上 Tips について解説されている。

Remove Duplicate Scripts では、重複したスクリプトの除去として、aol.com では adsonar.jp が 6 回ロードされていることが紹介されて、Steve 氏のサイトでは同じスクリプトを 10 回ロードされるページが公開されている。

Configure ETags では、ETags の設定方法について解説されている。

Make Ajax Cacheable & Split the Initial Payload では、Ajax のリクエストにも Expires ヘッダーをつけることでキャッシュさせる方法について解説されている。Ajax のリクエストは動的なものが多いのでキャッシュさせることはあまりないことだが、URL に timpestampをつけると有効であるとのこと。Google Calendar はそうなっているとのこと。

Load Scripts Without Blocking では、スクリプトブロックについて解説されている。<script src=”A.js”> という記述では、並列ダウンロードや描画をブロックするとのこと。MSN では、script タグを動的に作ることでブロックを回避している。

Don’t Scatter Inline Scripts では、広告や非同期スクリプトを外部から読み込みときの Tips が解説されている。いわゆる、外部スクリプトの遅延ロードについての解説。IE だと、script タグに defer と追加すると Google Analytics のスクリプトを非同期に読み込めるとのこと。Firefox だと、createElement で動的に script タグを作る。

Fast Data at Massive Scale - lessons learned at Facebook は、ゲスト講義で Facebook の Robert Johnson 氏の講義。Facebook のインフラのアーキテクチャーが公開されているかなり貴重な資料。Facebook のパフォーマンスを計測した結果として、1/2 が PHP の実行時間、1/4 が memcached、1/8 がデータベースとのこと。ただし、1ねん前はほとんど memcached であったとのこと。そのころはスイッチ経由で PHP クライアントと memcached のやりとりをしたのをクラスタリングにした。もうすこし具体的な情報がほしかったな。

Shard Dominant Domains では、ドメインをわけることで並列ダウンロードしてページの表示時間を短くする方法について解説されている。Steve 氏のサイトでは、実際のデモとして同じドメイン版、別のドメイン版、と用意されている。ブラウザによって、実装が異なっているが、HTTP 1.1 だと 1 サーバあたり 2 接続でダウンロードできるらしい。DNS のルックアップ回数を減らすルールと矛盾しそうなルールだが、イメージなどの固定なコンテンツには有効とのこと。

Optimize Images, Use Iframes Sparingly, Flush the Document Early では、イメージの最適化、iframe を控えめに使う、ドキュメントは早めにフラッシュすることについて解説されている。イメージの最適化では、さまざなツールが紹介されておりが CSS Sprites Generator というツールがあるとは知らなかった。

Serve Static Resources Cookie-Free, Reduce Cookie Weight, To WWW or not to WWW では、クッキーのサイズによってレスポンスタイムが変わることについて解説されている。

CSS Descendant Selectors, Forced Compression では、CSS のパフォーマンス向上に的を絞った解説がされている。ユニバーサルセレクタを使わない、DIV #navbar ではなく #navbar と指定する、LI .tight ではなく .li-tight と指定する、#navbar A ではなく .a-navbar と指定する。CSS 子孫セレクタによってはパフォーマンスに影響してくるというテスト結果も公開されていた。

State of Performance では、今までの講義のまとめて的なものであった。

ということで、ウェブサイトのパフォーマンスを向上させるテクニックがこれほど詳細にスタンフォード大学で講義があった。

このテクニックは、ブラウザ依存だったり、比較的大規模にならないと効果が目に見えないテクニックだけれど、とても勉強になった。

スタンフォード大学は、やっぱりすばらしい。

今回は、しばらく init-admin-plus を使っていて、いくつか不便なことに遭遇したため改良してみた。具体的には、次のとおり。

• 入力値をチェックする validator(ファイルでいうと validator/edit.yml) で、最大文字数のチェックを自分で毎回指定するのがめんどう
• 同じく validator で、必須のパラメータを指定するのがめんどう
• 同じく validator で、特定のカラム型に対応する validator を指定するのがめんどう
• config/generator.yml で、フィード名をデータベースの構造を見ながら指定するのがめんどう
• 同じく generator.yml で、各画面ごとに表示する項目を指定する display をデータベースの構造をみながら指定するのがめんどう

これらは指定しわすれて不具合につながっていた状況を改善するべく、自動生成して楽をしたいというのが改良のきっけかです。

というわけで、指定されたモデルに対応するテーブル構造を取得するいい方法はないかなと symfony の propel まわりのソースコードを読んでみたところ、config/schema.yml を読むことでいけるということが分かったので、myPakePropelAdminGeneratorPlus に追加してみた。

やっていることはとても単純なので、coderepos にアップしたソースコードをみてもらうことにして、config/generator.yml と validator/edit.yml の雛型を準備する必要がある。

これらの雛型は、sfConfig::get(’sf_root_dir’) の  data/generator/sfPropelAdmin/テーマ名/skeleton に格納されているので、これを変更する。

config/generator.yml の雛型は、次のようにします。次のファイルは、list のみですが create, edit も同様に指定します。

generator:
class: sfPropelAdvancedAdminGeneratorPlus
param:
model_class: ##MODEL_CLASS##
theme: admin
css: admin

#
# 共通フィールド名の設定
#
fields:
##GEN_FIELDS##

#
# TITLE一覧
#
list:
  title: “TITLE一覧”
  display: ##GEN_DISPLAY##
  fields:
  actions:
    _create: -
  filters:
  max_per_page: 20
  sort: id

具体的には、##GEN_DISPLAY## のところが [カラム名1, カラム名2,...] に置換される。

次に、validator/edit.yml の雛型は、次のようにします。

methods: [post]

fillin:
enabled: on

#
# バリデータ設定
#
fields:
##VALIDATOR##

具体的には、##VALIDATOR## のところがいっきに展開されます。これはカラムによって展開される内容が変わってくるけれど、例えば次のようになる。

methods: [post]

fillin:
  enabled: on

#
# バリデータ設定
#
fields:
  hoge{name}:
    required:
      msg: “name is required.”
  sfStringValidator:
    max: 255
    max_error: “This field is too long.”
     myDateValidator:
hoge{created_at}:
  myDateValidator:
hoge{updated_at}:
  myDateValidator:

この例だと、hoge というテーブルがあって name というカラムは必須で長さが 255 まで、created_at と updated_at は timestamp 型であるのでそのチェックを行うという設定で自動的に生成される。

これで、かなり symfony で管理画面系を生成するのが楽になって、validation を入れ忘れるというミスもなくなるはず。管理画面系は、けっこう作るのがめんどうなので、できるかぎり自動化を進めていきたいところです。

なお、symfony 1.0.18 で動作確認済で、sfPropelAdvancedAdminGeneratorPlus というプラグインは、知人から拝借した sfPropelAdvancedAdminGenerator という独自のプラグインを自分好みで変更したプラグインなので、もしかするともしかするとそのうち公開されるかもしれませんので毎日ググりながら楽しみに待つことにしましょう!

CentOS でのインストールは、rpm が Ganglia から配布されているのでダウンロードしてインストールする。Ganglia は、PHP で書かれていて GD を使っている。データベースは使っていない。
Ganglia の構成をざくっとまとめておくと、Ganglia は次の 3 種類のプログラムで構成されている。

• Ganglia Monitoring Daemon (gmond)

  • クライアント側にインストールするプログラム
  • 監視するクライアントにインストールするホスト、Ganlia は SNMP ではなくマルチキャストで通信する
  • gmond が /proc 以下から CPU、メモリの状況を XML 形式で出力してくれる
  • ポートは 8649 を使っているが、設定ファイルで変更することができる

• Ganglia Meta Daemon (gmetad)

  • サーバ側にインストールするプログラム
  • クライアントのデータを収集するデーモン
  • gmetad が起動していないと、Ganglia の Web UI を表示することができないので注意

• Ganglia PHP Web Frontend

  • サーバ側にインストールするプログラム
  • 監視するメイン画面、rrdtool などで可視化して表示する
  • イメージは、ライブデモを見ると分かる

何はともあれ、まずはインストールしてみる。

• SourceForge から、次の 3 種類の rpm をダウンロードする
  • ganglia-gmetad-3.0.7-1.i386.rpm
  • ganglia-gmond-3.0.7-1.i386.rpm
  • ganglia-web-3.0.7-1.noarch.rpm
• ダウンロードした rpm を、それぞれインストールする、その都度必要なパッケージがあったらインストールする
• Ganglia の Web UI が、/var/www/html/ganglia へインストールされるので、Apache などでアクセスできるようにする

今回は、Ganglia のサーバとクライアントは同じコンピュータにインストールしている。

次に gmond の設定をしてみる。gmond の設定ファイルは、/etc/gmond.conf を編集する。変更する箇所は、次のとおり。

cluster {
name = “My cluster”
owner = “unspecified”
latlong = “unspecified”
url = “unspecified”
}

udp_send_channel {
mcast_join = 224.0.0.1
mcast_if = eth0
port = 8649
ttl = 1
}

udp_recv_channel {
mcast_join = 224.0.0.1
mcast_if = eth0
port = 8649
bind = 224.0.0.1
}

マルチキャストの設定をする。CentOS 5.1 では、次の内容で /etc/sysconfig/static-routes を作成して、sudo /etc/init.d/network reload する。

any net 224.0.0.0/4 dev eth0

マルチキャストの設定が正しいかどうかは、netstat -rn を実行して確認することができる。

$ netstat -rn
…
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0
…

gmond を起動してみる。

$ sudo /etc/init.d/gmond start

とここで、次のようなエラーがでた。

slurpfile() open() error on file /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory

なんか、このあたりの問題のようだ。trunk ではすでに修正されているらしいが、上のエラー以外にも変更が加わっているので、次のようなパッチにしてみた。

— ./libmetrics/linux/metrics.c-org 2008-07-17 17:33:40.000000000 +0900
+++ ./libmetrics/linux/metrics.c 2008-07-17 17:49:56.000000000 +0900
@@ -39,6 +39,8 @@
#endif
char proc_cpuinfo[BUFFSIZE];
char proc_sys_kernel_osrelease[BUFFSIZE];
+
+#define SCALING_MAX_FREQ “/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
”
char sys_devices_system_cpu[32];
int cpufreq;

@@ -169,13 +171,20 @@
{
g_val_t rval;
char * dummy;
+ struct stat struct_stat;

num_cpustates = num_cpustates_func();

- cpufreq = 1;
- rval.int32 = slurpfile(”/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_fre
q”, sys_devices_system_cpu, BUFFSIZE);
- if ( rval.int32 == SYNAPSE_FAILURE )
- cpufreq = 0;
+ /* scaling_max_freq will contain the max CPU speed if available */
+ cpufreq = 0;
+ if ( stat(SCALING_MAX_FREQ, &struct_stat) == 0 )
+ {
+ rval.int32 = slurpfile(SCALING_MAX_FREQ, sys_devices_system_cpu, BUFFS
IZE);
+ if ( rval.int32 == SYNAPSE_FAILURE )
+ cpufreq = 0;
+ else
+ cpufreq = 1;
+ }

パッチをあてたバージョンをインストールしたいので、SRPM をインストールして SPEC ファイルを書き換えてパッチをあてた RPM を初めて作ってみた。パッチを作るときには、diff コマンドを使うけれど、ソースコードのファイル名の先頭に ./ と書いた方がいい。書かないと、rpmbuild したときにパッチを当てるファイル名を入力が必要になってしまう。

$ diff -uNr ./libmetrics/linux/metrics.c.org ./libmetrics/linux/metrics.c > ~/rpm/SOURCES/ganglia_metrics.c.patch

これで、gmod はちゃんと起動した。確認するには、telnet localhost 8649 して XML データが返ってくれば問題なし。

次に gmetd の設定をする。gmetd の設定は、/etc/gmetd.conf を編集すればいい。次の行を変更する。

data_source “My hoge” localhost

ローカルホストだけ監視対象に追加する。

gmod を設定したら、gmod を起動する。

$ sudo /etc/init.d/gmod start

無事起動した。

現在、収集する情報の種類は、次のコマンドで確認することができる。

$ /usr/sbin/gmod -m

Ganglia の Web UI を見てみると、Ganglai のウェブ管理画面で PHP のエラーが出るので、次の二つのパッチを書いて対策した。

— ./web/get_context.php-org   2008-04-08 15:45:09.000000000 +0900
+++ ./web/get_context.php       2008-04-08 15:46:26.000000000 +0900
@@ -42,9 +42,10 @@
$clustergraphsize = isset($_GET["z"]) && in_array( $_GET[ 'z' ], $graph_sizes_keys ) ?
escapeshellcmd($_GET["z"]) : NULL;
# A stack of grid parents. Prefer a GET variable, default to cookie.
+$gridstack = “:”;
if (isset($_GET["gs"]) and $_GET["gs"])
$gridstack = explode(”:”, clean_string( rawurldecode($_GET["gs"] ) ) );
-else
+else if (isset($_COOKIE["gs"]))
$gridstack = explode(”:”, clean_string( $_COOKIE["gs"] ) );

# Assume we are the first grid visited in the tree if there are no CGI variables,

— ./web/header.php-org        2008-04-08 15:46:32.000000000 +0900
+++ ./web/header.php    2008-04-08 15:48:16.000000000 +0900
@@ -53,8 +53,7 @@
{
# Use cookie so we dont have to pass gridstack around within this site.
# Cookie values are automatically urlencoded. Expires in a day.
-      $gscookie = $_COOKIE["gs"];
-      if (! isset($gscookie))
+      if (! isset($_COOKIE["gs"]))
setcookie(”gs”, $gridstack_str, time() + 86400);
}

さらにロードアベレージのグラフをみると、なぜか縦軸のメモリに m がついていて気になるので、これも修正した。rrdtool のパラメータを調整すればいいので、次のようなパッチを書いた。

— ./web/graph.php-org 2008-07-22 14:21:25.000000000 +0900
+++ ./web/graph.php 2008-07-22 15:06:04.000000000 +0900
@@ -14,6 +14,13 @@
# ATD - TODO, should encapsulate these custom graphs in some type of container,
then this code could check list of defined containers for valid graph labels.
$graph = isset($_GET["g"]) && in_array( $_GET['g'], array( ‘cpu_report’, ‘mem_r
eport’, ‘load_report’, ‘network_report’, ‘packet_report’ ) ) ?
$_GET["g"] : NULL;
+if (isset($_GET["m"])) {
+ $m_value = $_GET["m"];
+ if (substr($m_value, 0, 5) === “load_”) {
+ $graph = “load_report”;
+ }
+}
+
$grid = isset($_GET["G"]) ?
escapeshellcmd( clean_string( rawurldecode( $_GET["G"] ) ) ) : NULL;
$self = isset($_GET["me"]) ?

ようやく、Ganglia にアクセスできる環境が整った。そろそろ、修正版をリリースしてほしい…。><

Ganglia を自分でビルドするときは、Web UI の RPM(noarch) も必要なので、64 ビット環境ときは次のコマンドでビルドする。32 ビット環境の場合は、x86_64 を i386 に変更する。

$ rpmbuild -ba –target noarch,x86_64 ~/rpm/SPECS/ganglia.spec

Ganglia の SPEC ファイル、パッチ 3 種類、ビルドした 64 ビット用の RPM をおいておくので、よかった使ってください。

あとは、各クライアントへ gmod デーモンを動かすだけで自動的に Ganglia のウェブ管理画面に反映されるようになる。

また、ganglia のウェブ管理画面はテンプレートして切替えられるようになっている。設定は、/var/www/html/ganglia/conf.php の $template_name を変更するだけ。デフォルトのテンプレートの他には Rock というテンプレートが入っている。

テンプレートも、tpl という拡張子の PHP ファイルなので変更も簡単なところはいいところか。

そのときの、ネットワーク構成は次のようになっている。

[macbook]

 |

(インターネット)

|

(ルータ)

|

[proxy]

|

[s1]

s1 は、物理的にインターネット回線にはつながっていない。

作業マシンの macbook から、s1 にログインして開発をするには、次の手順を踏む必要がある。

1. [macbook] $ ssh proxy
2. [proxy] $ ssh s1
3. [s1] $ vi …

[macbook] $ ssh s1

この本は、Book review などの情報源がたくさんあって、Flickr のオペレーションエンジニアの John Allspaw 氏が書いたいわゆるサーバの増強計画をどのように行うかについて書かれた本であるとのこと。

最近、仕事でも急にサーバを増やすように言われて四苦八苦している僕にとっては、かなりタイムリーな本だ。O’Reilly で紹介されている記事から含まれているトピックスを訳すと、次のような内容が含まれている。

• 計測、デプロイツールを評価する方法
• ストレージ、データベース、アプリケーションサーバへのキャパシティ解析とその予測
• 簡単に（サーバを）追加できるアーキテクチャーのデザイン方法、キャパシティの計測方法
• 突発的なアクセスへの対処方法
• 急上昇と爆発的な成長の予測
• EC2 のようなクラウドサービスは、どのような内部的なキャパシティストレージに合うか（ちょっと意味不明）

どのような紹介が highscalability.com にも紹介されていた。highscalability.com は、ずっと購読していたが RSS の URL が変わったようでまったく更新をチェックしていなかった。。。インフラまわりをやっている人は、highscalability.com をチェックすることは必須であると思う。このサイトは、大規模なサイトがどのような技術を使っているかの情報源をまとめた貴重なサイトです。

John Allspan 氏は、1999 年からニュースマガジンや SNS のサイトを担当してきた経歴の持ち主らしいので、かなり勉強になりそう。John Allspan 氏のブログは、Kichen Soap として公開されている。同氏は、昨年の MySQL コンファレンス 2007 や Web 2.0 Expo や Velocity でも講演していた。これらのスライドは、すでに公開されていて、チェックするのを忘れていたので、メモしておく。

まずは、MySQL Conf 2007 の「Capacity planning for LAMP」から。スライドは、PPT あるいは PDF で公開されている。PDF の方は、スライドの他にもメモが書いてあるので、PDF の方をチェックするといいと思います。

• 自分のサービスには、どのくらいのデータベースサーバ、ウェブサーバサーバ、共通ストレージ、スイッチなどが必要かついて問い正している
• Flickr の数字が公開されていて、squid キャッシュに合計 35M（この M はミニオンという意味かな…）とすると 3,500 万枚くらいの写真があって、squid のメモリに 2M くらいの写真があって、470M くらいの写真がそれぞれ 4 〜 5 くらいのサイズあって、38k req/sec くらいの memcached にアクセスがあって 12M くらいのオブジェクトをもっている、2PB(!) の物理的なストレージがある
• このプレゼンでは、MySQL、squid、memcached について焦点をあてて話すとのこと
• サーバのキャパシティを考えるにあたって、計画（何を？なぜ？いつ？）、デプロイ（インストール、設定、管理）、計測（グラフ化）の3つの主パートについて考えてみる
• MySQL は disk I/O、squid は disk I/O あるいは CPU、memcached は CPU あるいはネットワークの上限をを把握することが重要
• Flickr では、Ganglia を使っている、貴重なスクリーンショットが公開されている
• Ganglia で、iostat で計測した結果をグラフにするためのシェルスクリプトが公開されている
• memcached の Gets/sec もグラフにしている、スライドで紹介されていた addon のページ http://wtf.ath.cx/ はデッドリンクだったが、別のものがあった
• GraphClick という 8 ドルの MRTG グラフを解析するためも OSX 用のシェアウェアが便利
• Flickr の MySQL サーバで使っている、DELL Power Edge 2950に 6 個のディスク 15K RPM の SCSI、RAID10、16GB RAM、クアッドコアCPU、というスペックの MySQL のクエリーグラフが公開されている、グラフをみると秒間 1.3K くらいの SELECT クエリーを捌けているが、CPU は 2% までいかないとのこと
• 次に MySQL Disk IO のグラフが公開されている、グラフをみると iowait が 10% くらいになっているが日々変わるのでよく監視している
• Squid へのリクエストとヒット数やヒット率、LPU の reference age、レスポンスタイムを ganglia のグラフにしている、80% くらい squid キャッシュにヒットしていて、レスポンスタイムは 50ms 以内くらい
• OSS のデプロイツールとして、SystemImager/SystemConfigurator、CVSup、Subconが紹介されている

かなり勉強になった、昨日でも mixi や楽天はなんでもグラフ化していると言っていたが、Flickr でも ganglia でさまざまなものをグラフ化している、僕も ganglia を使っているけれど MySQL とか memcached などのカスタムグラフは追加していないでやらないとけないと思った。レスポンスタイムもかなり重要なので、僕が管理しているサービスのレスポンスタイムもグラフに出してみたいと思った。Subcon は便利そうだと思ったがまだ開発中っぽい。

次に web 2.0 expo での「Capacity Planning for Web Operations」の資料に目を通してみた。Slideshare でも同じ内容が公開されていた。

• あるクリスマスの Yahoo! トップページの爆発的なトラフィックのグラフが紹介されていた
• 同氏の来年何台のサーバが必要かについてファイナンス部と相談した
• どのくらいサーバ必要か判断するには、計測することが重要
• 前と同様に ganglia での Flickr でメール経由で1分あたりどのくらいの写真がアップロードされているかを示すグラフが公開されていた、グラフをみると1分あたりメールで40から50くらい写真がアップロードされていた！
• 写真がアップロードされてからの写真の処理枚数や処理時間（おそらくリサイズの処理だと思われる）のグラフが公開されていた
• ベンチマークをとって、上限を見つけることが重要、そのときにはできるだけ本番のデータを使うこと
• サーバごとにどの部分が重要か示されている、ロードバランサーは前後のネットワーク、ウェブサーバは CPU とメモリとディスク使用量と disk I/O
• ベンチマークツールとして、Siege、httperf/autobench、sysbenchが紹介されている
• 67台の CPU のコア数 2 のウェブサーバを 18台の 8 コアに交換したときのロードアベレージのグラフが公開されている、グラフをみるとロードアベレージが半分くらいまで下がっている！さらにさまざまな数字の比較も公開されていて、消費電力が 70% 削減されて、49U のラックスペースが開いたのこと！でかつ負荷も半分になったと！！！
• 最後に Flickr の数字が紹介されちえる、ピーク時で 1 秒あたり 32,000 枚の写真が保存されている！、1日あたり 6-8TB のディスクを使用する！、Yahoo! Photos から統合に 1 日あたり 34TB くらいのディスクを使っている、1日あたり 3M のアップロードがあって、ピーク時に 1 秒あたり 60 枚の写真のアップロードがある！

ここで紹介されたベンチマークが使ったことがないので試してみる。httperf や sysbench が便利そう。コア数の多い CPU にリプレイスする意味は充分になることが分かった。僕の管理しているサーバの CPU は、全部 4 コアなので、すでに稼働している 2 コアのサーバは半分の台数で 8 コアのサーバとして充分に置き換え可能なことが分かった。

最後に Velocity での「Capacity Management」の資料に目を通してみた。正確なタイトルは、Capacity Management for Web Operations。

• キャパシティとパフォーマンスは、別の意味
• ベンチマークをとて限界を見つけることの重要性を強調している
• MySQL のレプリケーション遅延のグラフ(mysql_slave_secs)を公開して、あるとき 50 秒くらいのレプリケーション遅延が行ったことで、データベースの上限を見つける例として紹介している、さらにそのときの disk iowait(diskio_iowait)のグラフを示して disk I/O wait が 40% くらいになるとレプリケーション遅延が発生しているとのこと
• ウェブサーバの CPU グラフを紹介て、85% くらいまでを安全な上限としてみるのがいいとのこと
• キャパシティ状態の数字が公開されいて、12,628 の nagios による死活監視、1314 台のホスト、6 つのデータセンター、4 つの farms（おそらく、flickr の写真の URL にある farmX.flickr.com の数）、farm は東西に二つのデータセンターがある
• Squid のリクエストで下限あるいは上限でアラートを設定している
• 写真の変換処理を行っていた DELL PowerEdge 860s を HP DL140 G3s に置き換えた（CPU のコア数は 4 から 8 にした）が、CPU の使用率は変わらなかったが1分あたり処理できる写真の数の上限が 45 から 140 にくらいなったというピーク時のグラフが紹介されている！
• そのときの数字として、サーバの台数が 23 台から 8 台、消費電力が三分の一、75% くらい高速化した、23U から 8U のラックでよくなった
• dshという複数台のサーバに同時にコマンドを実行するツールが紹介されている

これもかなりためになった。写真の加工などいわゆる CPU を使うサーバはコア数を倍にすると、なんと三分の一で済んでしまうことが分かった。CPU の使用率はそのまだけれど、パフォーマンスが向上することも分かった。

あと、さまざまなグラフを一つのツールで統合して、そのグラフからシステムのパフォーマンスの上限を見極める重要さを実感できた。

ということで、かなりためになるので、思い切って本を購入してみた。初めての技術洋書になるけれども、ゆっくりでもいいから頑張って読んでみようと思う。

Mac Ports で Apache をインストールすると、/opt/local/apache2 以下にすべてインストールされます。Passenger の Apache Module をビルドするコマンドである passenger-install-apache2-module は、環境変数 APXS2 と PATH をみるようなので、事前に export するだけで問題なし。

$ export APXS2=/opt/local/apache2/bin/apxs

$ export PATH=/opt/local/apache2/bin:$PATH

$ sudo /opt/ruby-enterprise-1.8.6-20080810/bin/passenger-install-apache2-module

あとは、次のような感じでいつもどおり LoadModule などを設定するだけ。

LoadModule passenger_module /opt/ruby-enterprise-1.8.6-0080810/lib/ruby/gems/1.

8/gems/passenger-2.0.3/ext/apache2/mod_passenger.so

PassengerRoot /opt/ruby-enterprise-1.8.6-20080810/lib/ruby/gems/1.8/gems/passenger-2.0.3

PassengerRuby /opt/ruby-enterprise-1.8.6-20080810/bin/ruby

ちなみに、ruby-enterprise 1.8.6-20080810 のバージョンは同梱されている rubygems が 1.2.0 なので、gem list –installed コマンドに不具合があります。

ruby-enterprise に同梱されている rubygems を差し替えるには、次のように rubygems ディレクトリを差し替えるだけです。

$ wget http://rubyforge.org/frs/download.php/41040/ruby-enterprise-1.8.6-20080810.tar.gz

$ tar zxf ruby-enterprise-1.8.6-20080810.tar.gz

$ cd ruby-enterprise-1.8.6-20080810 

$ rm -fr rubygems

$ wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz

$ tar zxf rubygems-1.3.1

$ mv rubygems-1.3.1 rubygems

$ sudo ./installer

ついでに、gem の mysql バインディングも普通にはインストールできないので、mysql_config を指定する必要がある。

$ sudo /opt/ruby-enterprise-1.8.6-20080810/bin/gem install mysql — –with-mysql-config=/opt/local/bin/mysql_config5

環境は、OSX 10.5。

まず、svk を mac ports 経由でインストールする.

1. $ sudo port -d sync
2. $ sudo port install svk

Error: Target org.macports.activate returned: Image error: /opt/local/lib/perl5/5.8.8/Getopt/Long.pm is being used by the active perl5.8 port.  Please deactivate this port first, or use the -f flag to force the activation.

$  sudo port deactivate perl5.8

$ svk depotmap –init

Repository /$HOME/.svk/local does not exist, create? (y/n) y

$ svn help

$ svk mirror svn+ssh://example.com/myproject/trunk //mirror/myproject

Mirror initialized.  Run svk sync //mirror/myproject to start mirroring.

$ svk sync //mirror/myproject

Committed revision 1 from revision 1.

…

$ svk mirror –list

Path           Source

========================================================================

//mirror/myproject   svn+ssh://example.com/myproject/trunk

$ svk sync //mirror/myproject

$ svk sync –all

$ svk mkdir //work

Waiting for editor…

Waiting for Emacs…

$ svk copy //mirror/myproject //work/myproject

Waiting for editor…

Waiting for Emacs…

Committed revision X.

$ svk checkout //work/myproject $HOME/myproject

…

$ cd $HOME/myproject

$ svk info

Checkout Path: $HOME/myproject

Depot Path: //work/myproject

Revision: X

Last Changed Rev.: X

Copied From: /mirror/myproject, Rev. X

Merged From: /mirror/myproject, Rev. X

$ svk smerge -C //mirror/myproject //work/myproject

$ svk smerge -l //mirror/myproject //work/myproject

それは、

• mod_proxy_balancer: Add ‘bybusyness’ load balance method. [Joel Gluth , Jim Jagielski]
• mod_proxy: Add connectiontimeout parameter for proxy workers in order to be able to set the timeout for connecting to the backend separately.PR 45445. [Ruediger Pluem, rahul ]

の二つです。

まず、最初の mod_proxy_balancer に「bybusyness」というロードバランサの振り分けメソッドが追加されたという内容です。mod_proxy_balancer といえば、Apache HTTPD Server でかかせない L7 ロードバランサのモジュールです。mod_proxy_balancer の該当ドキュメントをみると、ProxyPass ディレクティブに次のように振り分けメソッドを定義できます。

ProxyPass / balancer://hotcluster/lbmethod=bybusyness

lbmethod のデフォルト値は、byrequests となっていて、byrequests とはバックエンドのウェブサーバにリクエスト回数で重み付けする振り分け方法が選択されます。その他の選択肢には、bytraffic があります。bytraffic は、転送量で重み付けする振り分け方法です。そこに、2.2.10 から bybusyness という選択肢が追加されました。bybusyness は、ドキュメント原文では「perform pending request balancing」となっているので処理待ちのリクエスト数で重み付けする方法のようです。

ProxyPass を使っている場合は上の設定でいいですが、mod_rewrite を使っている場合は Proxy ディレクティブの中で設定することができます。

<Proxy balancer://neoad>
balancermember http://web1.example.com loadfactor=10 keepalive=off retry=2
balancermember http://web2.example.com loadfactor=10 keepalive=off retry=2
ProxySet lbmethod=bybusyness
</Proxy>

設定したら、ちゃんと lbmethod が確認されるが知るために、次のような感じで balancer-manager を設定します。

ProxyPass /balancer-manager !
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Location>

Allow from は、自分がアクセスする接続元の IP アドレスを書くか、認証をかけるようにしてください。

設定したら、Apache HTTPD Server を再起動して、/balancer-manager にアクセスします。アクセスしたページに次のようななっていれば設定はできています。

LoadBalancer Status for balancer://example
StickySession Timeout FailoverAttempts Method
-                   0            1                         bybusyness

さっそく、bybusyness の動作確認をみてみる。

接続したバックエンドのサーバが分かるように s1、s2 と出力するようにしておいて、curl を 10 回連続で実行させてみる。

bybusyness の前に、byrequest で確認する。

通常稼働時

s1
s2
s1
s2
s1
s2
s1
s2
s1
s2

順番にラウンドロビンされている。

意図的に s1 をダウンさせたとき。

s2
s2
s2
s2
s2
s2
s2
s2
s2
s2

あたりまえだが、s2 のみ。s1 を復帰させて retry 時間がたったあと。

s2
s1
s2
s1
s2
s1
s2
s1
s2
s1

ちゃんと s1 が復帰した。

次に bybusyness で同じように試してみる。

s1
s2
s1
s2
s1
s2
s1
s2
s1
s2

次に s1 をダウンさせる。

s2
s2
s2
s2
s2
s2
s2
s2
s2
s2

次に s1 を復帰させて、retry 時間待つ。

s2
s2
s2
s2
s2
s2
s2
s2
s2
s2

あれ？おかしい、s1 が復帰しない。しばらく待ってみたが、プロキシを再起動しない限り、s1 は復帰しなかった。balancer-manager をみてみても Status が OK のままになっているにもかかわらず、s1 にはまったく振られない。

理由を知りたいと思ったので、ソースコードをみてみた。modules/proxy/mod_proxy_balancer.c の 1100 行目に find_best_bybusyness という static 関数がある。おそらく、この関数で行っている処理だと思うので念入りに観てみた。とても短く、シンプルな関数だが、Apache のソースコードをみるのは初めてなのでよく分からないが、関数の最後にデバッグログを出力していること、バックエンドのサーバが選ばれるところは、次のようになっていた。

if (!mycandidate
|| worker->s->busy < mycandidate->s->busy
|| (worker->s->busy == mycandidate->s->busy && worker->s->lbstatus > mycandidate->s->lbstatus))
mycandidate = worker;

この busy と lbstatus の内容はデバッグログで出力されているので、デバッグログを出力するようにしてみた。デバッグログは、LogLevel debug を追加する。LogLevel は、ErrorLog ディレクティブの前に設定したほうがよい。

通常稼働時のログでは、次のように出力されている。

[Tue Nov 18 01:42:33 2008] [debug] mod_proxy_balancer.c(1173): proxy: bybusyness selected worker “http://s1/” : busy 0 : lbstatus 0

[Tue Nov 18 01:43:03 2008] [debug] mod_proxy_balancer.c(1173): proxy: bybusyness selected worker “http://s2/” : busy 0 : lbstatus 10

busy がどちらとも 0 なのでラウンドロビンされている。

s1 を落として、デバッグログをみてみる。

[Tue Nov 18 01:44:20 2008] [debug] mod_proxy_balancer.c(1173): proxy: bybusyness selected worker “http://s2/” : busy 0 : lbstatus 10

s1 を復帰させてみる。

[Tue Nov 18 01:46:00 2008] [debug] mod_proxy_balancer.c(1173): proxy: bybusyness selected worker “http://s2/” : busy 0 : lbstatus 0

s1 を復帰させて、接続したとき s1 が復帰したデバッグログは出力されるが、lbstatus がマイナスになっていた。

[Tue Nov 18 01:51:05 2008] [debug] mod_proxy_balancer.c(1173): proxy: bybusyness selected worker “http://s2/” : busy 0 : lbstatus -30

そのあと、s1 のオフオンを繰り返すたびに s2 の lbsatus が -10 ずつ減っていって、s1 を復帰させた直後の接続しても s1 が復帰したというデバッグログが出力されない。

byrequests で試してみると、s1 が復帰した直後の接続すると、次のようなログが出力される。s1 の lbstatus は 0、s2 の lbstatus は 10 になっている。

[Tue Nov 18 01:56:51 2008] [debug] mod_proxy_balancer.c(1008): proxy: byrequests selected worker “http://s1/” : busy 0 : lbstatus 0
[Tue Nov 18 01:56:51 2008] [debug] mod_proxy_balancer.c(543): proxy: BALANCER (balancer://test) worker (http://s1/) rewritten to http://x1/
[Tue Nov 18 01:56:51 2008] [debug] mod_proxy.c(988): Running scheme balancer handler (attempt 0)
[Tue Nov 18 01:56:51 2008] [debug] mod_proxy_http.c(1924): proxy: HTTP: serving URL http://s1/

busy という変数の意味を調べ観ると、どうやらリクエストを振り分ける前に ++ されて、リクエストが終わったあとに — されるという単純な整数値のようです。lbstatus という変数は、Balancermember ディレクティブの値がそのまま使われているようです。

とここまで調べて、Apache のバグとして上がっているかなと思って調べてみたが、すでにあがっていた。

というわけで、bybusyness を使うとバックエンドのサーバが復帰しないという問題があるので使うのはやめておくことにしました。修正されるまでは、byrequests でいこうと思います。

mod_proxy_balancer のソースコードをすこし読んで、keepalived のように一定時間おきにチェックするのではなくて、HTTP リクエストがあったときに調べてどのサーバにリクエストを振り分けているということが分かりました。

振り分けを決めている find_best_XXX 関数は自分でも独自のルールで定義できそうです。

次に気になった connectiontimeout というのは、mod_proxy の ProxyPass 変数で定義できる値です。原文を要約すると、バックエンドのサーバに接続するまでのタイムアウト時間を秒単位で指定する設定です。すでに、timeout や retry という設定があって同じような意味で困惑しますが、timeout はバックエンドのサーバに / リクエストを送ったときのタイムアウト時間、retry はバックエンドのサーバが復帰させるときのリトライ時間です。

ということで、次のように設定することにしました。

<Proxy balancer://test>
balancermember http://s1/ loadfactor=10 retry=7 connectiontimeout=2
balancermember http://s2/ loadfactor=10 retry=7 connectiontimeout=2
</Proxy>

サーバの設定は、一度稼働したらメンテナンスを計画しない限りずっとそのままなので、最初に気合いを入れてしっかりと設定したいものです。

最初の方は、富の格差について具体的な数字を上げながら紹介されていて、後半は教育環境からアメリカ人の考え方や筆者の体験談などが紹介されていた。

アメリカという社会に興味のある人は、必読の一冊だと思う。

環境は、CentOS 5.2 x86_64 です。

• ソースコードを sourceforge からダウンロードする
• ソースコードを展開する
• ./configure && make する、問題なくコンパイルが通る
• init スクリプトがないっぽいので、作ってみた
• RPM にしたかったので、SPEC も作ってみた
• init スクリプトを追加したまるおさんの tarball を作って、_topdir/SOURCES に入れる
• rpmbuild -ba makuosan.spec して、RPM を作る
• 作った RPM をインストールする
• /etc/sysconfig/makuosan に、ベースディレクトリ (BASE_DIR) の設定をする
• sudo /etc/init.d/makuosan start する（sudo しているのはかなり微妙かもしれないが、lock ファイルを作っているので必要）

これでまくおさんを起動したので、さっそく動作確認

$ /usr/bin/msync –members

1.0.0: s1.example.com  192.168.1.1
Total: 1 members

認識している。さっそくファイルを転送してみる。

$ /usr/bin/msync -r

-v を指定しないと、何も表示されないが確認してみるとちゃんとコピーされている。ちょっと試した感じだと非常に便利なので、実際のシステムで使うように引き続き検証をしておく予定。あと、FreeBSD でも動かせないか調べてみたい。

今までは、社内の自作シェルスクリプトで rsync していたので、サーバ情報の管理がかなりめんどうだったけれど、まくおさんを使うとファイルをコピーするということに限ってはかなりシンプルになりそう。

せっかくなので、作った RPM を公開しておきます。ダウンロードした RPM のファイル名がおかしいので、なおしてください。正しくは、makuosan-1.0.0-1.x86_64.rpm です。

init スクリプトと SPEC がソースコードに含まれることに期待しています。

こんな素敵なツールを作って公開してくださった KLab Inc. の安井さんに感謝！！！

# 追伸

設定している途中で、「まくおさん」なのか「まるおさん」なのか、自分の中で勝手に混乱しまった。。。個人的には「まるおさん」の方が覚えやすい＞＜

• 収録語数
• Native の発音を聞くことができることか
• 米国英語、英国英語、の発音記号を表示できるか

こんな感じでした。すべて有料なので気軽に試せなかったので、上から検討した結果「Cambridge Advanced Talking Dictionary」を初の iPhone 有料アプリとして購入してみました。

米国、英国、両方の発音記号と実際の発音を iPhone で見れて聞けるのでこれからも重宝しそうです。

その他にも和英や英和もかなり充実しているし、無料の英英辞典も english とか dictionary とかで検索するとたくさんあるので使ってみるといいかもしれません。カテゴリでいうと、Reference、Education、などに属していますね。

追伸：
iPhone アプリのアイコンは、どうやってブログに張るのだろうか。。。

応募方法は、近いうちに JTPA のサイトで案内がでると同時に上のバナーも変わると思います。

使い方は、次のとおりでとても簡単で自宅にプリンタがない僕の場合はかなり重宝するサービスになった。

• ネットプリントにユーザ登録（無料）する
• ネット プリントのプリントしたいファイルをアップロードする（エクセルや PDF などに対応している、対応している用紙サイズでないと自動的にエラーになるのでとても親切）
• ファイルをアップロードすると発行される登録キーをメモする
• あとは、全国のセブンイレブンで登録キーを入力するだけで印刷をすることができる
• 料金は、ここに書いてあるとおりで、モノクロA3やA2で1枚20円というリーズナブル、さらに実際に印刷してみると会社のプリンタよりもきれいに鮮明にきれいに印刷できる

こういう身直に精通しているウェブサービスは、本当に便利だと思うが、こういったサービスは普通の人たちが使うので簡単に使えなければならない。

自分への誕生日プレゼンとして、もうすでに祭りは終わっているけれど iPhone を買った。iPhone は、電話というより、個人的にアプリケーションを本格的に作りたくなったからだ。iPhone を新規契約したが、何の問題もなく在庫もあって、運転免許証と運転免許証の住所と現住所が違う場合は公共料金の領収書と月々の支払いに必要なクレジットカードだけで問題なく契約ができた。契約時間は、店員さんが慣れていたということもあって、約30分ほどで終わった。iPhone のパッケージは自分で開封するのだけれど、みごとに箱の一部をはがしてしまった。箱は必要なのかよく分からないが、ちょっとやってしまったと思った。わざわざ自分で開封させる意味が、ちゃんと理解できてよかった。

全損がかなり怖いので、Apple Care には加入しておいた。白か黒かすこし迷ったが、16GB の黒にした。

購入した直後の iPhone は、バージョンが 2.0系でバッテリーもほとんどない状態がだったが、USB 電源アダプターは新しいものに交換されていた（あたりまえか）。

家に帰ってから、iPhone をバージョンアップしようとして、ファームウェアをダウンロード開始したところで寝て朝起きたら iPhone にロックがかかってしまい、緊急電話しか使えないただの箱になってしまった。

近くのソフトバンクショップに修理のお願いに行ったら、iPhone テクニカルサポートに確認しないと交換できませんと言われてしまう。ちょうど行ったのが土曜日の5時すぎということで、タイミングよくテクニカルサポートが終了していた。ショップから交換品を取り寄せておくので、翌日テクニカルサポートに確認して、それでもダメならまた来てくださいと言われた。今日みたいな日も日割で料金が発生しているんだよなと不満をかかえつつも、翌日テクニカルサポートに午前10時頃に問い合わせしてみた。テクニカルサポートで、確認されたことが次のとおり。ちなみに、前日にすべて自分で試していた。

• OSX のバージョンは最新ですか？ -> 最新の 10.5.5 です
• iTunes のバージョンは最新ですか？ -> 最新の 8.0.1 です
• SIM カードを抜き差しして症状が変わらないですか？ -> （すでに5回くらいやっていたが、念のためちゃんとやって）症状が変わりません

これだけかと思いつつも、予想通りロックがかかりっぱなしだったので、ショップに行った。ショップに行ったら、Apple Care から交換品が届いて SIM カードをショップで用意されているものに交換してみたが症状が変わらないということで本体を無料で交換してもらった。もし、Apple Care に入っていない場合は、90日を過ぎると有償になるとのこと。Apple Care に入っていると、それが2年に延長されるとのこと。

新品に交換しても、iPhone のバージョンは 2.0 系のままだったので家に帰ってからバージョンアップしたら、今度はすんなりとバージョンアップすることができた。

今まで、ずっと iPod Touch 1G を持っていたが、いろいろと違っていることが多いので、同梱はされていないが iPhone の説明書を一通り読みながら実際に操作してみた。このあたりの情報は、iPhone 3G Wiki によくまとまっている。

この説明書も、iPhone のアプリとして入れてくれればいいのにと思ったが、もし作ったら確実に Reject されそうだが PDF を iPhone の表示用にフォーマットしなおさないといけないでできるかどうか調べてみたい。

一通り操作をしてあと、いろいろとアプリを入れて遊んでみた。日本製のはブログなどでかなり紹介されているが、海外製のは適当に探しながら入れてみた。ユニクロのアプリは Wifi を使ってもダウンロードに時間がかかりすぎなのと、起動や動作も重いので速攻で削除した。アプリを作るときには、アプリサイズも重要なポイントになるだろうと実感した。

海外製でよくできたアプリとしては、 SmugShot というサイトが提供しているアプリ。 iPhone のカメラで撮影した写真をアップロードできたり、iPhone からアカウントを登録できたりと、かなり使いやすかった。iPhone のカメラで撮影した写真をアップロードするアプリを作るときには、このアプリを参考にしたいと思った。

iPhone を堪能したあと、iPod Touch 1G を JB してみようと iPod Touch を初期化してから、Pwnagetool なるものを使ってみたが DFU モードに入ってもカスタムファームウェアをインストールすることができなかった。そろそろ、2.2 が登場しそうなので、また機会をみて試したいと思う。iPhone は、JB するリスクがけっこうありそうなのでやめ�