Windows Server AppFabricの紹介。 キャッシングサービス

アプリケーションを構築するための基本的なルールの1つは、開発者がインフラストラクチャの構築に時間を無駄にしないことです。 各アプリケーションはサービスの形で何らかのサポートを必要としますが、これらのアプリケーションを開発する人々は、ユーザーにとって意味のある機能を作成することにのみ焦点を合わせるべきです。 必要なインフラストラクチャが何であれ、アプリケーションを構築するプラットフォームによって提供される必要があります。



これを念頭に置いて、プラットフォームを改善する1つの方法は、最高のアプリケーションインフラストラクチャを提供することです。 そして、それこそがWindows Server AppFabricの目標です。 マイクロソフトは、Windows Server用の一連の拡張機能を提供することにより、開発者がより速く、よりスケーラブルで管理しやすいアプリケーションを簡単に作成できるようにすることを目指しています。



Windows Server AppFabricの最初のリリースには2つの部分があります（現在、 バージョン1.1には多くの革新的な機能があります。- 注ごと ）。

• 頻繁に使用されるアプリケーションデータへのアクセスを高速化するAppFabricキャッシングサービス
• サービスAppFabricホスティングサービス。WCFに基づいて作成され、特にWindows Workflow Foundationに基づいて作成されたサービスの起動と管理を簡素化できます。

Windows Server AppFabricは、アプリケーションサーバーロールの拡張機能を提供します。これらの拡張機能は、一緒に使用することも個別に使用することも無料です。 この紹介では、AppFabricの両方の部分について説明します。

AppFabricキャッシングサービス

多くのアプリケーションのパフォーマンスとスケーラビリティを改善する1つの方法は、データへのアクセスを高速化することです。 たとえば、ASP.NETアプリケーションの場合、ビジネスロジックを簡単にスケールアップできます。ロジックの複数のコピーを異なるサーバーに配置し、それらの間で負荷を分散するだけです。 アプリケーションパフォーマンスのこの側面の改善は、より多くのサーバーで簡単に実現できます。



ただし、これらすべてのサーバーが1つのデータベースサーバーに依存している場合、データへのアクセスがすぐにアーキテクチャのボトルネックになる可能性があります。 ASP.NETページが必要なデータを待機する必要がある場合、新しいサーバーを追加しても役に立ちません。 ソリューションの1つは、より強力なマシンでデータベースサーバーを起動することです。 これは機能する可能性がありますが、制限があります。サーバーをより強力なマシンに交換することでスケールアウトする必要があり、そのような交換は非常に高価になる可能性があります。 本当に必要なのは、頻繁に要求されるデータを複数のサーバーで利用できるスケーリング方法です。これにより、単一サーバーという形でのボトルネックを回避できます。



これを実現する効果的な方法は、複数のコンピューターにデータを分散する分散キャッシュを作成することです。 各要求を1つのデータベースサーバーに送信する代わりに、ASP.NETアプリケーションは、隣接するマシンの1つから必要なデータを受信できます。 負荷が分散され、アプリケーションの動作が速くなります。 これはまさに、AppFabric Caching Servicesが提供する機能です。

AppFabricキャッシングサービスの仕組み

AppFabric Caching Servicesの主要なコンポーネントは、ASP.NETページなどのキャッシュクライアントであり、多数のキャッシュサーバーを含むキャッシュクラスターにアクセスします。 各キャッシュサーバーはAppFabric Caching Servicesのインスタンスを起動し、キャッシュされたデータのセットへのアクセスを維持します。 各キャッシュクライアントは、AppFabric Caching Servicesで提供される特別なコンポーネントを使用して、ローカルデータキャッシュを維持することもできます。 図1は、すべてのコンポーネントの図を示しています。





図1 AppFabricキャッシングサービス組織図



キャッシュクライアントは、ユーザーがASP.NETアプリケーションに送信した情報やデータベースから読み取った値などのデータを最初に受信すると、この情報をAppFabric Caching Servicesキャッシュクラスター（または後述するASP.NETアプリケーション）に一意の名前で保存できますSessionオブジェクトを通じて情報を透過的に保存できるため、既存のアプリケーションのコードを書き換える必要さえありません）。 クライアントにとって、クラスター内の他のすべてのキャッシュサーバーは1つの大きなストレージのように見えます。クライアントはキャッシュデータがどの物理サーバーに保存されているかを知る必要はありません。 必要に応じて、クライアントはローカルキャッシュにデータを保存することもできます。



クライアントが再び同じデータにアクセスする必要がある場合、指定された一意の名前を使用してそれらを要求します。 この要求は、ローカルキャッシュ（存在する場合）をチェックします。 データが見つかった場合、クライアントはローカルキャッシュのデータを使用します。 ローカルキャッシュにデータがない場合、要求はキャッシュクラスターに送信されます。 データがクラスター内にある場合、クライアントはそれを使用します。 プロセス全体がクライアントに対して透過的であり、リクエストを送信するだけで、残りはAppFabric Caching Servicesが処理します。 キャッシュクラスタでデータが見つからなかった場合、クライアントはデータベースのデータを要求する必要があります。



開発段階のAppFabricキャッシングサービスは「Velocity」というコードネームで、このサーバーの機能を正確に定義する名前です。これにより、データへの繰り返しリクエストを高速化できます。 このサービスでは、データベースに対して同様のクエリを多数作成する代わりに、ローカルメモリまたは分散メモリから直接データを取得できます。 同じデータを頻繁に要求するが、多くのデータがあるアプリケーションの場合、キャッシュによりパフォーマンスとスケーラビリティが大幅に向上します。



AppFabric Caching Servicesは.NETアプリケーションで使用するように設計されているため、キャッシュされたデータを.NETオブジェクトにシリアル化できます。 オブジェクトをキャッシュに配置すると、クライアントはそのオブジェクトを更新したり、キャッシュから削除したりできます。 キャッシュに保存されたアイテムは、保存期間の期限切れや、より関連性の高いデータをキャッシュに配置する必要があるため、サービス自体によってキャッシュから削除することもできます。 ローカルキャッシュ内のデータも古くなる可能性があります。また、ローカルデータを分散キャッシュの同じデータと同期して、変更と同期削除を行うことができます。



複数のキャッシュクライアントが同じキャッシュクラスターを使用できます。 スケーラブルなアプリケーションは、ビジネスロジックを複数のマシンで複製する可能性が高いため、各マシンはキャッシュクラスターへのアクセスを必要とします。 ただし、同じキャッシュクラスターに複数のマシンにアクセスすると、セキュリティ上の問題が発生する可能性があります。 複数のクライアント間で1つのキャッシュクラスターをより安全に分離するために、キャッシュクライアントとクラスター間で転送されるすべてのデータをデジタル署名または暗号化できます。 さらに、管理者には、キャッシュにアクセスできるアカウントのリストを制限するメカニズムがあります。 組織は、同じキャッシュを使用するすべてのクライアントが互いのデータにアクセスする可能性があるため、信頼できると確信する必要があります。



キャッシュは、さまざまなタイプのデータを扱うときに役立ちます。 たとえば、キャッシュは、さまざまなクライアントが要求する時不変データ（オンラインサプライヤディレクトリ情報）を操作する場合に非常に役立ちます。 キャッシュのもう1つの優れたユースケースは、可変データの格納ですが、ASP.NETセッション情報など、1つのクライアントのみが消費します。 また、この例では、キャッシュされたデータの同時アクセス制御の問題が発生しない場合について説明します。



しかし、絶えず変化するデータを多数の顧客が同時に消費しなければならない場合はどうでしょうか？ この場合、キャッシングも使用できますが、注意が1つあります。同時アクセス制御が必要です。 この問題に対処するために、AppFabric Caching Servicesは、バージョン番号割り当てに基づく楽観的同時アクセス制御と明示的ロックを使用した悲観的同時アクセス制御の両方をサポートします。

シナリオ：ASP.NETアプリケーションでのキャッシュの使用

ASP.NETアプリケーションは、AppFabricキャッシングサービスの最も重要なクライアントです。 前述のように、ASP.NETセッションオブジェクトに格納されているデータは、キャッシュの最も明白な候補です。 実際、このサービスにはこれに対する組み込みのサポートがあります。開発者は構成オプションを設定するだけで、セッションオブジェクトはキャッシュクラスターに透過的に保存されます。 注意：これは、ASP.NET開発者がアプリケーションコードを変更せずに分散キャッシュを利用できることを意味します。 これにより、SQL Serverを使用してセッションデータを保存することなく、ASP.NETの実行中のインスタンスを実行するWebサーバーの複数のコピーが可能になります。 図2は、このメカニズムの仕組みを示しています。





図2。 ASP.NETアプリケーションがAppFabricキャッシングサービスと連携する方法



この単純なシナリオは、ASP.NETがユーザーセッションオブジェクトに保存する情報をユーザーが送信することから始まります（ステップ1）。 要求を処理するWebサーバーは、セッションオブジェクトをAppFabricキャッシングサービスクラスターにキャッシュするように構成されているため、ユーザーデータは1つ以上のキャッシュサーバーに書き込まれます（手順2）。 ユーザーからの次のリクエストは、ステップ1で保存されたデータに基づいていますが、このリクエストはすでに別のサーバーで処理されています（ステップ3）。 このサーバー上のASP.NETコードは同じセッションオブジェクトにアクセスします。これは、実際には、データアクセスのためのキャッシュクラスターへの透過的なアクセスを意味します（手順4）。 これにより、手順1で取得した情報をアプリケーションで使用できるようになります。 情報を保存するためにデータベースを操作する必要はなく、ユーザーのリクエストを処理するために同じサーバーを必要としないことに注意してください。 このインフラストラクチャの結果、ASP.NETアプリケーションのパフォーマンスが向上し、スケーラビリティが向上します。

シナリオ：高可用性の使用

AppFabricキャッシングサービスは、すべてのデータをメモリに保存します-データはディスクに書き込まれません。 デフォルトでは、キャッシュされた各オブジェクトはキャッシュクラスター内の1台のマシンにのみ保存されます。 サーバーが利用できなくなったときに信頼性を高めるために、AppFabric Caching Servicesは高可用性メカニズムのサポートを提供します。 このメカニズムにより、キャッシュクラスター内の他のマシン上にキャッシュデータの複製コピーを作成できます。 データのプライマリコピーを保存するキャッシュサーバーが使用できなくなると、データはセカンダリストレージから取得されます。 図3は、全体のアイデアを示しています。





図3 高可用性AppFabricキャッシングサービス



この例では、キャッシュされたデータの各アイテムが2つの異なるキャッシュサーバーに保存されるように、HAメカニズムがオフになっています。 図に塗りつぶされた図として示されているプラ​​イマリコピーは、データのすべての変更を受け入れます。 これらの変更は、空の図として表示されるセカンダリコピーに自動的に複製されます。 ここで、Xデータのプライマリコピーを含むキャッシュサーバーが使用できなくなります（スケジュールまたはランダム、ステップ1）。 キャッシュクライアントがXデータを要求すると（ステップ2）、キャッシュクラスターは要求をセカンダリコピーに慎重にリダイレクトし、値を返します（ステップ3）。



この例はデータの読み取りを示していますが、プライマリデータを備えたキャッシュサーバーが利用できない場合も、更新要求は同じ方法で処理されます。 AppFabric Caching Servicesがプライマリデータを持つサーバーが利用できないと判断すると、セカンダリデータを持つ既存のサーバーがプライマリになり、利用可能なサーバーの1つに新しいセカンダリコピーが作成されます。 これはすべてクライアントに対して透過的であり、サーバーに何も起きていないかのように機能します。



高可用性メカニズムを使用するかどうかに関係なく、AppFabric Caching Servicesを使用すると、頻繁に要求されるデータへのアクセスを高速化できます。 これは、既存のWindows Serverインフラストラクチャを拡張する非常に便利な機能です。



ビジネスロジックのサポートを改善するための提案は、この点に関してWindows Server AppFabricが提供しなければならないことと同じくらい有用です。次のパートで説明します。

開始、継続します。