かばだんなさん かく語りぬ

社内システムなんかで、表題のような要望が出た事はありませんか？

まぁRails自体が下位非互換でまくりでビジネスユースが減ってしまった（少なくとも日本国内では）ので、需要はあまりないのかもしれません（苦笑。ですが公開されている情報も少ないですし、新たにDMZにApacheサーバーを立てるのは運用管理者的には抵抗があるでしょうから、ここにメモを公開します。

まず「Rails on IIS」の構成というと下図のようなイメージを持たれるのではないでしょうか？

これはFastCGI的には（確か）正確な図ではありません。あくまで概念的なイメージ図です。PHP + CakePHP の最小構成だとこうなりますよね。

でもRailsの場合これが最適とは私には思えません。少なくともビジネスユースでは。

今日はこんなお話し。

何で「最適とは思えません」なんて明言するかと言うと、いくつか理由があります。

（いや、繰り返しますけど「ビジネスユースの場合」ですよ？）

１．Ruby For IIS が行方不明。

Ruby For IIS がサイトごと無くなっているのは結構有名な話です。まぁ元から挙動も不安定という話でしたし、逃げた女を追いかけてもろくな事はありませんしね（苦笑。

少なくともIIS・Ruby・Railsが日々更新されている以上、更新されていないモジュールを採用するのは危険すぎるというものです。（構築だけして保守もバージョンアップもしないなら採用してもいいですけど、かばだんなさんのシャル・システムサービスはそういうスタンスで仕事しないので。）

２．システムの拡張性に乏しい

上記の構成は１台（DBサーバーを分離したとしても２台）のマシンで全処理を行う構成ですが、Railsのアプリってメモリを食いやすいので、どうしても構築時に将来のサーバー多重化を意識しておく必要があります。

もちろん上記の構成でも多重化は可能なんですけど、実導入の時にアプリケーションセッションの共有から全部テストしないといけません。このテスト工数はデカいです。どうせできるならシステムの構成物も「モジュール」と考え、「疎結合」を目指したいですよね。

（あ、クラウドコンピューティング的にリソース拡張はもっと下のレイヤで対処するっていうのはアリです。）

という事で、どうも私には最適な構成とは思えないのです。（ホントはさらに「DMZに業務アプリが乗ってる」っていうのが恐ろしいのですが、これは私の考え過ぎかもしれませんので大書きしません。）

じゃあDMZのWWWサーバとしてIISを使用している会社はRailsアプリを公開できないのか！？わざわざRailsアプリのためにApacheを立てなきゃいけないのか！？と言われると、そんな事はありません。

あくまでサンプルですが、いくつか例を挙げます。共通する設計思想は、「DMZに新たにサーバーを立てるのは危険なので、ファイアーウォールの内側に１つ立てましょう」というものです。

で、どの案を選択するかはその会社ごとに変わります。

プランＡ ： 内部セグメントにWindowsでサーバーを立てる

この場合、下記のようなイメージになります。

この場合、IISでは先日紹介した「URL Rewrite Module」を使ってリクエストを転送し、FireWallの内側に新たにRailsに特化したAPサーバーであるMongrelを導入します。mongrelにはWindowsサービスとして稼働する「mongrel_service」もありますので、管理も容易です。

あ、静的コンテンツをIIS上に残したのはただの私の趣味です（笑。少しでもMongrelの負荷が減るならそれに越したことはないな、と。

この構成と最初の構成を比較した時のメリット・デメリットは下記の通りです。

【メリット】

・DMZが膨らまないのでセキュリティ的にも（ちょっと）安心。

・DMZサーバーの処理内容を「httpセッションの管理」「SSLの暗号化・複合化」「静的コンテンツ（画像・CSS）の応答・キャッシュ済み（３０４）かの確認」に限定する事で、サーバーの負荷を大幅に軽減。

・DMZサーバーの負荷が軽減する事で、「Keep-Alive」のタイムアウト値等、レスポンス速度向上ための設定が可能になる。（IIS7.0のタイムアウトは120秒だけど、単独機だとリソース的にあまり大きな値を設定するとサイトによってはキツいかも。）

・ＡＰサーバーがメモリパンクなどでダウンしても、影響が局所的範囲に収まる。（例えばＤＭＺに置いてある会社のホームページなどは影響なし）

・APサーバのリソースを増強する際、動作確認がAPサーバー周りだけで済むので、テスト工数が小さくなる。

他にもたくさんありますが、いわゆるWeb３層構造のメリットばかりですね。３層構造というとJavaのアプリが一般的ですが、別にJavaである必要はありませんから、どんどんいいトコ取りです。

【デメリット】

・APサーバとしてもう１台サーバーを購入しなければならない。（でもDMZにIISを立てているような会社であれば、社内サーバとしてもWindowsサーバーを立てている所が多いでしょうから、アクセス数が少ない間はそのサーバーをAPサーバーにする事も考えられますね。）

・Mongrelの作者が１年ほど前にRubyコミュニティに愛想をつかして心の旅に出ている。（これも困った問題ですが、そのうち代わりが名乗りを上げるような気がします。あくまで予感ですが・・・。）

プランＢ ： 内部セグメントにLinuxでサーバーを立てる

この場合、下記のようなイメージになります。

 このプランではDMZは変わりません。ただAPサーバーがLinux＋Apacheになっただけです。何でLinuxにするかというと、このPassengerというのがWindowsで稼働しないからです。なんか頑なに拒否しているようにさえ見えます。ま、他人の趣味はどうこう言いますまい（笑。

この構成のメリット・デメリットは、上記プランＡと比較しましょう。

【メリット】

・MongrelよりPassengerの方が１リクエストあたりの処理が早い。（これはPassengerがアプリケーションプールを作って、メモリ上で使い回しをするためのようです。確かに早い。）

ちなみにPassengerと一緒に「Ruby Enterprise Edition」というのも公開されています。Rubyの亜種みたいですが、半年ほど前にCentOSで試してみたけどあんまり速くなった気はしませんでしたので、私は採用を見送りました。うむ、スタンダードは美しい。

【デメリット】

・WindowsとLinuxの２種類のサーバーが混在するので、運用管理者の管理コストが増す。（特にセンター運用なら倍増です）

・Passengerは起動時にアプリケーションプールを作成するため、アクセスがない状態でも設定したプール数分だけメモリを消費する。

と、まぁ、こんな２プランを考えてみました。個人的には多少速度的に劣っても、複数OSを運用する手間を考えたらプランＡの方がいいような気がします。Mongrelの作者が旅に出たのは大ダメージですが、ほら、Mongrelサーバーをファイアーウォールの内側に置く事で、多少枯れても何とか騙し騙し動かせるかな、と（苦笑。

以上、本日はシステムのグランドデザイン的な話になってしまいました。ほら、春だし新人さんの季節だから（笑。

タグ：rails iis windowsserver