.Net Remoting をスケーラブルにするための９つのルール

原文は、thinktecureのサイトの記事です。
http://www.thinktecture.com/resourcearchive/net-remoting-faq/remotingusecases

スケールアウト可能な構成で.Net Remotingを使用するための９つのルールというトピックです。補足説明付きで訳してみます。

Use only server-activated objects configured as SingleCall

サーバオブジェクトは、シングルコール呼び出しにすること。シングルコールだとサーバの処理を呼び出して返ってくるという一連の処理で接続が即時切断されるので、サーバ側のコネクションリソースが残ったままにならないというメリットがあります。毎回接続だと処理コストが大きいと考えがちですが、不特定多数の大量のクライアントから、少数のトランザクションを処理する場合に接続を維持すると、あっという間にコネクションリソースが枯渇します。（少数のクライアントから大量のトランザクションを処理する場合は逆ですが。）

ウェブサーバでKeepAliveを必ずFalseにする理由と一緒です。ステートレス（接続情報を維持しない）で問題ないアーキテクチャにしておくと、ロードバランサーによる負荷分散の恩恵を受けることができるメリットもあります。

Use the HttpChannel with the BinaryFormatter. Host your components in IIS if you need scalability, authentication and authorization features.

ベストな組み合わせはHTTPでバイナリフォーマットを使用してIISにホストさせて使用すること。IISを使用することで認証機能を利用することもできるし、HTTPという汎用のプロトコルであれば、ロードバランサなどとの相性も心配ないという事だと思います。

Use IIS' ability to deactivate HTTP KeepAlives for maximum scalability.

IIS使うならKeepAliveはオフに設定すること。最初のルールと関連しています。

Use a Network Load Balancing cluster of servers during development if you want to achieve scalability. Make sure to deactivate any client affinity and make sure that you deactivate http keepalives during development!

ロードバランサを使うときでも、開発中はKeepAliveをFalseにすると自分が繋がっているサーバが良く分からなくなるのでオフにした方が良い。

Do not use client-activated objects and don't pass any MarshalByRefObject over a remoting boundary. You will easily trap this if you use the .NET Framework version 1.1 which will throw a SecurityException or a SerializationException in this case. (Yes, you could change this setting - but you shouldn't!)

クライアントアクティベートオブジェクトは使ってはいけない。セキュリティやシリアライズの例外に悩まされる事になる。

Do not use events, callbacks and client-side sponsors.

イベントやコールバック、クライアント側スポンサーを使ってはならない。どの技術もクライアントとサーバの接続を維持する必要があるので、使ってはいけない。

Do not use static fields to hold state. Instead put ALL state information in your database. If you keep state in memory, you will run into problems if you try to scale your application out to a cluster of servers. Cache information only if it's not going to change (like a list of states or cities) - else you will run into cache-synchronization nightmares on your cluster.

状態をメモリに持たずに必ずデータベースに保持すること、スケールアウトして数十台のサーバで負荷分散している環境だと、メモリをサーバ間で同期する仕組みが必要になってしまう。

Do not use Remoting for anything else apart from .NET to .NET communications. Use ASP.NET Web Services and the Web Services Enhancements (WSE) for anything related to SOAP, Service Oriented Architectures and platform independence.

.Netリモーティングは、ASP.NETのようなプラットフォーム独立の汎用性のあるプロトコルではないので、JavaやUnixなどとの通信に使う異機種混在環境で使ってはならない。

Do not try to fit distributed transactions, security, and such into custom channel sinks. Instead, use Enterprise Services if applicable in your environment. .NET Remoting isn't a middleware, it is just a transport protocol - if you need services, use a service-oriented framework!

分散トランザクションサービスやセキュリティを.Netリモーティングに求めてはいけない。それはトランスポートレベルのミドルウェアの仕事で、.Netリモーティングの仕事ではない。.Netリモーティングはサービス志向フレームワークだ！

ということで、難しい使い方をせずにシンプルに使おう！という内容の理解で良さそうです。WCFでも基本的には同じでKeepAliveやSingleCall、イベント・コールバックの考え方は、スケールアウトするシステムでは考慮が必要になってきます。ただし、分散トランザクションは.NETリモーティングではサポートされていませんでしたが、WCFではサポートされているのでそのあたりの事情は変わってきています。