分散キャッシングを使用したスケーラブルなWCFアプリケーション

著者：イクバルカーン

トラフィックの多い使用に対応するためのWebアプリケーションの爆発的な増加の後、次の大きな波はサービス指向アーキテクチャー（SOA）になりました。 SOAは、アプリケーション開発と統合の展望を変えました。これは、非常にスケーラブルなアプリケーションを開発するための標準的な方法になる運命にあり、WindowsAzureやWindowsCommunication Foundation（WCF）などのクラウドコンピューティングプラットフォームは、SOAをこの目標の達成に向けて大きく飛躍させるものです。 SOAは主に、スケーラビリティを実現し、それに投入される負荷と同じ量の負荷を維持して、俊敏性の向上と生産性の向上を実現することを目的としています。

ただし、真のSOAアプリケーションは、アプリケーションアーキテクチャに関する限り、簡単に拡張できるはずです。ただし、真のスケーラビリティを実現するには、対処する必要のあるパフォーマンスのボトルネックが多数あります。

アプリケーションデータは、WCFサービスで最も大量のデータ使用量であり、そのストレージとアクセスは、リレーショナルデータアクセスの副産物として発生する遅延のため、スケーラビリティの主要なボトルネックになります。
高度に分散された異種のデータソースを備えた環境は、SOAのパフォーマンス目標を達成するための最大の課題をもたらします。アプリ層は適切に拡張できますが、サービス指向アーキテクチャー（SOA）に残っている主な懸念事項のXNUMXつは、参加しているデータサービスのパフォーマンスです。
データ層は、トランザクション処理能力の観点から直線的に拡張できないため、全体的な応答時間にかなりの遅延が発生する可能性があります。
さらに、SOAサービスは他のサービスに依存しており、ローカルでは利用できない可能性があるため、別のサービスへのWAN呼び出しが別のボトルネックになる可能性があります。
さらに、SOAがデータ仮想化レイヤーの実装で使用されている場合、データサービスのパフォーマンスは非常に重要です。この場合、アプリケーションのパフォーマンスは、基になるデータのフェッチにかかる時間に正比例します。データサービスは、リレーショナルデータと非リレーショナルデータの両方にアクセスしている可能性があり、多くの場合、地理的に分散した複数のデータセンターに分散しているため、応答の遅延が発生し、アプリケーション全体のパフォーマンスが低下する可能性があります。

分散キャッシュ（NCache）サービスのスケーラビリティ

ソリューション全体の応答待ち時間を短縮するための包括的なアプローチは、高性能キャッシングシステムを利用して、データサービスと連携して、またはデータ仮想化レイヤーで使用することです。 SOAサービスはXNUMX種類のデータを処理します。 XNUMXつはサービス状態データであり、もうXNUMXつはデータベースに存在するサービス結果データです。どちらもスケーラビリティのボトルネックを引き起こします。

キャッシングは、サービスを同時にスケールアウトできるようにすると同時に、サービス状態とアプリケーションデータの両方にアクセスする速度を向上させる上で非常に重要な役割を果たすことができます。キャッシングは、キャッシュを使用するサービスと基盤となるデータプロバイダー間のトラフィック量と遅延を最小限に抑えることでこれを実現します。図1は、 NCache これを実現するための分散キャッシング。

認定条件 NCache 分散キャッシングは、データソースへのプレッシャーを軽減できます — 図1：方法 NCache 分散キャッシングは、データソースへのプレッシャーを軽減できます

アプリケーションデータのキャッシュ

のような分散キャッシュ NCache は、WCFサービスが数時間の小さなウィンドウで必要とするものに基づいて、データベースにあるデータのサブセットのみをキャッシュするために使用されます。分散キャッシュは、SOAアプリケーションのスケーラビリティを大幅に向上させることができます。理由は次のとおりです。

分散キャッシュは、採用しているアーキテクチャの結果としてスケールアウトできます。
複数のサーバーに分散された状態を維持し、SOAアプリケーションにXNUMXつの論理ビューを提供するため、XNUMXつのキャッシュであると考えることができます。ただし、キャッシュは実際には複数のサーバー上に存在するため、キャッシュを実際に拡張できます。
次のような分散キャッシュを使用する場合 NCache サービスレイヤーとデータベースの間では、時間のかかるデータベーストリップを大幅に節約できるため、サービスレイヤーのパフォーマンスとスケーラビリティが大幅に向上します。

実装する基本的なロジックは、データベースに移動する前に、キャッシュにすでにデータが含まれているかどうかを確認することです。含まれている場合は、キャッシュから取得します。それ以外の場合は、データベースに移動してデータをフェッチし、次回のためにキャッシュに入れます。図2に例を示します。

using System.ServiceModel;
using Alachisoft.NCache.Web.Caching;

namespace MyWcfServiceLibrary {
  [ServiceBehavior]
  public class EmployeeService : IEmployeeService {
    static string _sCacheName = "myServiceCache";
    static Cache _sCache = 
      NCache.InitializeCache(_sCacheName);

    public Employee Load(string employeeId) {
// Create a key to lookup in the cache.
      // The key for will be like "Employees:PK:1000".
      string key = "Employee:EmployeeId:" + employeeId;

      Employee employee = (Employee)_sCache[key];
      if (employee == null) {// item not found in the cache. 
        // Therefore, load from database.
        LoadEmployeeFromDb(employee);

        // Now, add to cache for future reference.
       _sCache.Insert(key, employee, null,
          Cache.NoAbsoluteExpiration,
          Cache.NoSlidingExpiration,
          CacheItemPriority.Default);
      }

      // Return a copy of the object since ASP.NET Cache is InProc.
      return employee;
    }
  }
}

図2-使用するWCFサービス NCache -分散キャッシング

重要なキャッシング機能

サービスのキャッシュ設計では、基になるデータが変更される頻度、キャッシュされたデータを更新する必要がある頻度、データがユーザー固有かアプリケーション全体か、キャッシュを示すために使用するメカニズムなどの問題を考慮する必要があります。更新、ダーティデータのアプリケーションの許容レベルなどが必要です。したがって、キャッシングソリューションには、このようなすべての要件を並べ替えるために必要な機能が必要です。

分散キャッシングを使用したデータサービスによるデータのスケーラブルな管理の主な機能のいくつかを以下に簡単に説明します。

キャッシュされたデータの期限切れ

有効期限を使用すると、キャッシュがデータを自動的に削除する前に、データをキャッシュに保持する期間を指定できます。指定できる有効期限にはXNUMXつのタイプがあります NCache：絶対時間の有効期限とスライディング時間またはアイドル時間の有効期限。

キャッシュ内のデータがデータベースにも存在する場合、このデータは、キャッシュにアクセスできない可能性のある他のユーザーまたはアプリケーションによってデータベース内で変更される可能性があることを知っています。その場合、キャッシュ内のデータは古くなりますが、これは望ましくありません。このデータをキャッシュに保持するのが安全であると考える期間を推測できる場合は、絶対時間の有効期限を指定できます。さらに、スライディング有効期限は、セッションを分散キャッシングに保存するセッションベースのアプリケーションに非常に役立ちます。

キャッシュとデータベースの同期

データベースは実際には複数のアプリケーション間で共有されており、それらのアプリケーションのすべてがキャッシュにアクセスできるわけではないため、データベースの同期が必要になります。 WCFサービスアプリケーションがデータベースを更新する唯一のアプリケーションであり、キャッシュも簡単に更新できる場合は、データベース同期機能はおそらく必要ありません。

しかし、実際の環境では、常にそうであるとは限りません。サードパーティアプリケーションがデータベース内のデータを更新すると、キャッシュがデータベースと不整合になります。キャッシュをデータベースと同期することで、キャッシュはこれらのデータベースの変更を常に認識し、それに応じて自身を更新できるようになります。

データベースと同期するということは、通常、関連するキャッシュアイテムをキャッシュから無効にすることを意味します。そのため、次にアプリケーションで必要になったときに、キャッシュにアイテムがないため、データベースからアイテムをフェッチする必要があります。

キャッシュ内のデータ関係の管理

ほとんどのデータはリレーショナルデータベースから取得され、リレーショナルデータベースから取得されていない場合でも、本質的にリレーショナルです。たとえば、顧客オブジェクトと注文オブジェクトをキャッシュしようとしていて、両方のオブジェクトが関連しているとします。顧客は複数の注文をすることができます。

これらの関係がある場合は、キャッシュでそれらを処理できる必要があります。つまり、キャッシュは顧客と注文の関係を知っている必要があります。顧客を更新するか、キャッシュから削除する場合は、キャッシュで注文オブジェクトをキャッシュから自動的に削除することができます。これは、多くの状況でデータの整合性を維持するのに役立ちます。

キャッシュがこれらの関係を追跡できない場合は、自分でそれを行う必要があります。これにより、アプリケーションがより煩雑で複雑になります。

まとめ

したがって、SOAアプリケーションは、使用するデータが頻繁なトランザクションに対してスケーラブルではないストレージに保持されている場合、効果的に拡張できません。これは、次のような分散キャッシングが行われる場所です。 NCache 本当に役立ちます。エンタープライズ環境では、SOAベースのアプリケーション環境は、真の分散キャッシングインフラストラクチャを採用せずに真に拡張することはできません。従来のデータベースサーバーも改善されていますが、分散キャッシングがなければ、サービスアプリケーションは、今日の複雑なアプリケーション環境におけるスケーラビリティに対する爆発的な需要を満たすことができません。

著者：イクバル・カーンの勤務先 Alachisoft 、.NETおよびJava分散キャッシング、O / Rマッピング、SharePointストレージ最適化ソリューションを提供する大手ソフトウェア会社。あなたは彼に到達することができます iqbal @alachisoft.COM.