kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

タグアーカイブ: IIS

Sync Framework で Web Farming


というわけで(なんで?)Sync Framework ですよ。

Sync Framework の現状バージョンは 2.1 なんですが、DBの同期とか難しい事についての話が中心になってるようで、案外みんなノーマーク?ってぐらいに国内情報が薄いですな。

Microsoft からは Web Farm Framework がIIS拡張として提供されていて、これを使って複数のWebサーバにアプリケーションの展開とかできるわけなんですが、前提としてARRが入ってたりして敷居はかなり高いです。(Azure上の Full IIS にARR乗せた上で Web Farm Framework を展開するとか激しく人柱っぽいですよね、うまくいってるって人が出てもちっとやりづらいっていうか、Azureの仕組みとどこでかちあうかと考えるとガクブル)

さて、将来にクラウドに乗せるか等はさておき、Webサーバ数台にコンテンツを展開するのは必要な事です。

プログラムの機能に関わるようなdll類を展開するのはちゃんと管理してやりたいんで勝手に同期とかしちゃまずいよなーって思うんですが、画像とかHTML、CSSとかのコンテンツはぶっちゃけてあんまり面倒見たくない。

こんな場合の策なんていうとぶっちゃけ2通りしかない。

  1. どっかに入れれば各サーバに勝手に反映されるようにする
  2. 中央ストレージにおいてそれを返す

うちの会社のCMSはどっちかというと2のアプローチなんですが、2にはキャッシュ機構をちゃんとかましてストレージ負荷をフロント負荷と切り離さないとストレージがボトルネックになりかねないという面でお手軽さはアレでございます。

1のアプローチが今回の Sync Framework を使って Web Farming するって方法。

という訳でSync Framework によってネットワークフォルダからローカルフォルダに同期をする方法。

結構大変な手順を踏む事になります。

  1. Sync Framework 2.1 をインストールする
  2. Microsoft.Synchronization v2.1 と Microsoft.Synchronization.Files v2.1 を参照設定する
  3. 以下コードを必死に書く
    image

コピペできない様に画像にしてやったぜ(ぇ

後は設定で同期元ディレクトリ、同期先ディレクトリを指定できるようにして、タスクスケジューラなりサービスプロセスなにがしで同期元、同期先に権限のあるアカウントで定期的に実行する。なんらかの異常があればそれを管理者が察知できるようにエラーレポート機構を組み込む諸々の処置をすれば良いわけですな。

セキュリティ的な注意事項

同期元はさておき、同期先の権限が厄介で、これをWebアプリケーション内のコードにすると、コンテンツフォルダに書き込み権限をつける必要が出てしまいアプリケーションが陥落した場合にアプリケーション実行ユーザーでサイトの改ざんが可能になってしまいますので権限設計は慎重に。

Sync Framework はマークしとけ

実際にWeb Farming に使うかはさておき、ファイルシステムフォルダをリモートと同期するのは比較的簡単です。同期プロバイダを書けばファイルシステム以外と同期する事もできます。

Azure等の場合にはマスタデータを持った参照用の SQL Server Compact のデータベースファイルとかをローカルストレージに同期してから使うとかすれば SQL Azure を使って課金額が跳ね上がるとか、テーブルストレージに対するクエリの制約とかに悩む必要もありません。SQL Server Compact は LINQ to SQLでのクエリで利用できますし。Synclonizeメソッドは同期の結果サマリーを返しますんで同期受け入れ用のローカルストレージに向かっての同期を定期的にかけてなんかのファイルが同期されたらアプリケーションをリスタートして新しいマスタに乗り換えてとかの制御も出来ないわけではありません。

こうすると参照用データとかは同期でローカルにとられた物を使う事が結構できますんで、本当に多数のノードの間での一貫性や整合性が要求されるデータについてそれをちゃんと制御すれば良いという事になりますね。もちろんのことですが、ローカルストレージは課金なんてありません。そのうえでトランザクションは Queue介してシーケンシャル処理が保障されちゃう仕組みに投げちゃうと一貫性の為のトランザクションもあんまり要りません。

クラウドでKVS重要と色々言われてきました、一番重要なのはローカルストレージの使いこなしと、ローカルストレージをいかに外部と同期させるかだと思います。

まとめ

http://togetter.com/li/92062

Sync 重要。

広告

MS10-070 をインストールすると携帯向けのURL セッションが通らない


表題のとおりなんですが、皆さまご注意ください。

この現象は URL セッションで使われるセッションキーが URL 中に埋め込まれる時に MS10-070での暗号化方式の変更により IIS の下回りで動いているカーネルモードHTTPハンドラ(HTTP.sys)でのURLの規制値に引っかかってしまう事で発生します。

通常、携帯向けで URL session を使うと URL は以下の構造を持ちます。

http:// ホスト.ドメイン / セッションキー / サイト内URL

このセッションキーはご覧の通りで / に挟まれる区間ですので、その長さは KB 820129 IIS 用の Http.sys レジストリ設定 で解説されている UrlSegmentMaxLength によって最大長が制限されます。そして、この長さを超える場合には bad request となります。

HTTP.sys によってリクエストが不正として扱われる為、基本的に IIS W3C Log にも出力されず(Bad RequestなんだからMulformed Requestの可能性もあり、ログに出す項目のどこまで信頼できるか解らない&そもそもIISにリクエストが渡されないからIISログに乗り様がない)、アプリケーションをいっくら疑ってもその手前で弾き飛ばされるので厄介で、IISログや、イベントログをベースにエラー監視しているとすりぬけます(弊社のお客様サイトにおいて、数日間携帯での買い物ができない状態というのに気付かなかった罠、もうしわけございません。)

んで、UrlSegmentMaxLength がいくつなら引っかからないのさって事になると思いますが、弊社実績値で MS10-070適用以前に226バイトのキーが MS10-070の適用で 296バイトに伸びたという事で、少なくとも70バイト程度は増加すると言えます。むやみに大きな値を指定するとカーネルモードにデカイバッファを持っていかれたり、通常の制限値に依存してる他の何かがバッファオーバーフロー攻撃にさらされる危険も考えられるので無意味に大きな値を設定する事はお勧めできませんが、通常運用では既定値260の倍で520もあれば十分ではないでしょうか。

なお、この設定値の変更後はシステムの再起動が必要となります。IISの再起動ではカーネルモード HTTP.sys の再ロードおよび設定の再読み込みはされないっぽいです。

という訳で、携帯系で利用される Web サイトを開発、運用されている皆さま、ご注意ください。

追記:

この blog の内容は弊社で起こった問題事象を MS サポートに問い合わせ解決に至るまでの結果を元に弊社内での事象を含めて記述させて頂いております。
MSサポートの迅速な対応に感謝すると共に、経緯結果についての公開を承諾頂いた事に感謝します。