【IIS7】 ネットワーク機能の提供
それでは Tech・Edセッションの第三部に移ります。
・ネットワーク機能の提供
これを聞くとはぁ？と思ってしまう人もいると思いますが、IIS7の多機能化は多方面にわたっていて、このエリアでもかなり進歩しました。
○負荷分散
マイクロソフトのサーバー製品で負荷分散というと、Windows 2000 Advanced Serverに搭載された NLB=Network Load Balancing（実はWindows NT でも WLBS というのがありました。）、それからそれ以降に登場した Application Center 2000 を思い浮かべる人が多くいると思います。後者には CLB＝Component Load Balancing というアプリケーション層での負荷分散機能を搭載していました。
それ以降 Windows Server 2003、R2、2008、R2 と継続してNLBは搭載され、CLBは搭載されることはありませんでした。これは CLB の負荷分散メカニズムが画一的であったことと、ベースになっているのがクラス毎の実行時間の記録を同期していることで、振り分けが複雑だったことに起因しています。
Application Center 2000 を開発していたチームが実は MOM を開発し、今の System Center の基礎を作ったわけですが、一方でアプリケーション層における負荷分散は実装されずにずっと来ました。
IIS 7.0を出荷後、Application Center の機能の継続を要望するお客様の声を拾い上げたのが実は IIS チームでした。IISのチームは設計思想に立ち戻り、どういう負荷分散機能が便利で使いやすいのかを熟慮した上で Application Request Routing モジュールの開発に取り掛かりました。私の見たところ、キーワードは”Simple”じゃないかと思うぐらいさっぱりとしたわかりやすいモジュールに負荷分散の領域では仕上がっていると思います。
負荷分散機能だけでなく、リクエストを振り分けることが基本原理になっている関係で Application Request Routing あるいは省略して ARR は URL Rewrite モジュールに依存しています。URL Rewrite は Apache で言うところの mod_rewrite に相当するモジュールで、文字通り Apache のリライトルールをインポートする機能も持ちます。
WCATで負荷をかけて2台に振り分けるデモなんぞを本番はやり、パフォーマンスモニターで受け付けているHTTPリクエスト数を棒グラフ上に表示しながら見せることができました。
○リバースプロキシー
私はとても身近なところでこの機能を実装する試験を行うことになったという背景があります。何かというと ReMIX というイベントの基調講演のライブ配信を行う構成を必死に組み上げていた大西が IIJ さんと一緒に難儀しているという状況がありました。そこに飛び入りで入って行って、Application Request Routing モジュールと IIS Media Services 3.0 の設定を調整することになったわけです。私も逆向きの1対1の構成を組むのは初めてだったので IIS 開発チームの Wong Yooさんのヘルプメールに応えてくれた手順を熟読しながら構成をしてみたものでした。
結果は大成功で Application Request Routing を実際に使用して HTTPディスクキャッシュ機能をフル活用して ReMIX の基調講演のライブ配信は実施され、大西は寝れないイベント配信を何度か体験することになったのは言うまでもなく、Tech･Ed の基調講演もこの同じ仕組みで行われたわけです。
ARRの基本的な動作はサーバーグループに対して何らかのロジックをもってリクエストを振り分ける動きをするのは前に書いた通りですが、その宛先のサーバーファームに1台だけ入れる方法で簡単に組むことができます。
まあ結局 とても世界中から質問が多かったんでしょうね。。。Won はブログで記事を書いてしまいました。実は書くようにリクエストしたのではありますけど。
Application Request Routing as a reverse proxy?
○IIS でエッジキャッシュ
IIS でのキャッシュプロキシーの機能をも ARR は提供します。上記の IIS Media Services の Smooth Streaming は HTTP 通信による新しいビデオ配信で、とてもネットワーク内のキャッシュプロキシーが威力を発揮して、元の配信さーばーへの負荷を分散してくれるわけですが、そこにわざわざ ISA Server を持ってくるよりはもっとお手軽な方法論として ARR にそういう機能を搭載してしまったわけです。すごく簡単な設定でどこのフォルダにキャッシュを溜めるかをある意味設定するだけで簡単に動作します。
今だから明かすと ReMIX の配信の構成を組んでいる時に最初 ARR の設定がうまくいかなくて Squid でも組んでみたタイミングがありました。Smooth Streaming がそれでも立派に動いていたのを見て IIS さんと一緒にきちんと標準仕様通り動いている点について驚いていたのですが、ARR の設定は実はもっとシンプルだったわけですね。うまくいっていなかった時、必要の無いマシンにまで IIS Media Servicesを入れていて、それで構成を戸惑ってしまったわけです。結果的に ReMIX 本番は ARR できちんと動作しました。
ここら辺は横浜の本番でもデモする時間がうまくとれなかったのですが、Silver Week中に時間が取れれば全部ビデオ化してお届けしたいと思っています。
○移行とか同期は？
これがネットワーク機能に含まれるかは微妙ですけど、Application Center という製品は実はサーバー間同期の機能を持っていたのでその流れでここに入れています。
実はまったく同じ構成をとるサーバーを複数台用意するだけの場合、同期をしなければいけない構成を採用する前に共有構成という仕掛けを使えば本体は一か所で制御できる、構成とコンテンツをリモートの共有に置く構成がとれます。なのでその選択をするかどうか検討した方がいいと思います。
その上で、やはりコピー、同期で対応したいという設計になった場合に Web Deployment Toolを使用した同期を利用することになると思います。初期の Web Deployment Tool はもっと簡単なもので、コマンドラインで動作するツールだったのですが、どんどん機能が拡張されていっていて、結果的にまだ製品版になっていません。
どう拡張しているかというと、Visual Studio 2010で採用されているアプリケーションの発行機能や展開機能がこのツールの API を叩くようなことにまで発展しているからです。一方で IIS マネージャーの拡張も含まれるようになり、同期処理の一番最初のフェーズでの元サーバーでのアプリケーションのパッケージ化は IIS マネージャー内からウィザード形式でできるようになってきています。それに加えターゲットサーバーでそれをインポートする機能ももちろんあります。
コマンドとAPIとPowerShellのコマンドレットがそろったことで、移行する処理をステップに分解し、それぞれのステップも個別に実行できるとても柔軟なツールに育っています。それぞれのステップとは 元サーバーの検査、パッケージ化、それのコピー、パッケージのインポートという流れです。
同期は IIS6 同士、IIS6とIIS7、IIS7同士 という具合にかなり柔軟に使えるので移行時期でなくてもこのツールのお世話になることもあると思います。移行は IIS6 から IIS7 サーバーへを想定しているのでもっと色々なことが考慮されています。つまり、IIS7 には IIS６に無い機能もあるので元の設定が存在しないそのような機能の場合には このツールが採用する既定値が存在するわけで例えばモジュール化は IIS7 からの機能なのでそこをどう対応するかなどが決まっているわけです。
この Web Deployment Tool はかなり注目度が高いのでこの投稿をご覧になっている皆さんもぜひ一度は使ってみることをお薦めしておきます。何かの状況で役に立つと思います。障害時の緊急コンテンツ退避手順が必要だった時とかにも活躍するかもしれませんね。
第三部はそんな感じです。