ここしばらく Apollo や Silverlight など、クライアントサイドの新技術が登場しています。Rails のブログを見ていたら、Slingshot という製品が紹介されていました。

Slingshot goes public
http://weblog.rubyonrails.com/2007/5/2/slingshot-goes-public

この製品は、Rails で開発したアプリを、オンラインでもオフラインでもシームレスに切り替えて使えるようにするもののようです。ただ、この製品が筋のいい製品かどうかはわかりません。コンセプトは納得できます。ネットがつながっていないと、Web アプリはまったく役に立たなくなるので、オフラインでも使える Web アプリができたら便利ですね。

ここしばらくのクライアント技術の傾向を思いつくままに上げてみます。
・ Web アプリとデスクトップアプリの境目をなくす（共通）
・ Web アプリとデスクトップアプリの技術的な隔たりをなくす（Apollo、Silverlight）
・ クライアント／サーバの技術的な隔たりを（割と）なくす（Silverlight）
・ アプリのインストールを意識する必要が無い
・ マルチプラットフォーム
・ 一応リッチになってきた（？）

究極的には、コードオンデマンドでインストールを意識することはなく、オンラインオフラインを意識することなく、Web / デスクトップを意識することなく、ブラウザの種類も OS の種類もデバイスの種類も意識することなく、アプリケーションというものは使えるようになるということでしょうか。

すばらしい夢の世界・・・といいたくなるところですが、IT エンジニアにとってはしんどい時代になりそうだなぁ。。。

今日は、Kodougu 公開に向けて、Apache2.2 で mod_proxy_balancer を使ってロードバランスを実現させるということをしていました。つまり、フロントエンドを Apache（mod_proxy, mod_proxy_balancer）、バックエンドは Mongrel という Rails の世界では割と一般的な構成にしました。役割としては、Apache がロードバランスして、Mongrel がリクエストを処理します。Mongrel とは Ruby で書かれた Web サーバで、Rails アプリを動作させることに適しています。

なぜこのようなことをしているのかというと、理由は二つあります。ひとつはパフォーマンスとスケーラビリティに関係するものです。Mongrel は Rails アプリを動作させるには非常によい Web サーバ（Rails と相性がよくて高パフォーマンス）です。しかし、Apache と同じく 1 プロセス 1 コネクションであるため、クライアント（ブラウザ）に直接接続させてしまうと、大量のリクエストが発生したときに（Kodougu では大量のリクエストが発生する）、Web サーバがビジーになって、リクエストを受け付けるまでラグが発生する可能性があります。そこで、複数の Mongrel プロセスを起動して負荷を分散します。Mongrel はロードバランスはしてくれないので、Apache にロードバランスさせているというわけです。
もうひとつの理由は、Mongrel は Rails に特化した Web サーバなので、フロントには別のサーバをおいておきたいという思いがあります。そこで、普段使い慣れている（＋ロードバランス機能を持った）Apache をフロントに置き、Mongrel をバックに配置しました。

さて、設定は楽勝なのですが、mod_proxy_balancer で一点はまりました。mod_proxy_balancer を使うために httpd.conf には以下のような記述を追加します。（実際にはもっとたくさんのバランサメンバがいます。）

ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
<Proxy balancer://mycluster/>
  BalancerMember http://127.0.0.1:3000 loadfactor=20
  BalancerMember http://127.0.0.1:3001 loadfactor=20
</Proxy>

balancer://mycluster/ の最後のスラッシュ（/）を書かなかったがために、ルート以外の URL にアクセスしたときにパーミッションエラーになってしまいました。
# これで何時間もはまってました。。。

気をつけませう。。。orz