というわけで（なんで？）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とかのコンテンツはぶっちゃけてあんまり面倒見たくない。
こんな場合の策なんていうとぶっちゃけ２通りしかない。
- どっかに入れれば各サーバに勝手に反映されるようにする
- 中央ストレージにおいてそれを返す
うちの会社のCMSはどっちかというと２のアプローチなんですが、２にはキャッシュ機構をちゃんとかましてストレージ負荷をフロント負荷と切り離さないとストレージがボトルネックになりかねないという面でお手軽さはアレでございます。
１のアプローチが今回の Sync Framework を使って Web Farming するって方法。
という訳でSync Framework によってネットワークフォルダからローカルフォルダに同期をする方法。
結構大変な手順を踏む事になります。
- Sync Framework 2.1 をインストールする
- Microsoft.Synchronization v2.1 と Microsoft.Synchronization.Files v2.1 を参照設定する
- 以下コードを必死に書く
コピペできない様に画像にしてやったぜ（ぇ
後は設定で同期元ディレクトリ、同期先ディレクトリを指定できるようにして、タスクスケジューラなりサービスプロセスなにがしで同期元、同期先に権限のあるアカウントで定期的に実行する。なんらかの異常があればそれを管理者が察知できるようにエラーレポート機構を組み込む諸々の処置をすれば良いわけですな。
セキュリティ的な注意事項
同期元はさておき、同期先の権限が厄介で、これを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 重要。
