分散キャッシュを使用して Microsoft Azure で .NET アプリを拡張する
録画されたウェビナー
ロン・フセイン
Microsoft Azure の .NET アプリのスケーラビリティのボトルネックは何か、また分散キャッシュを使用してスケーラビリティを向上させる方法について説明します。
このウェビナーの内容は次のとおりです。
- .NET アプリケーションのパフォーマンスのボトルネックの概要
- 分散キャッシュとは何ですか? Azure で分散キャッシュが解決策となるのはなぜですか?
- アプリケーションのどこで分散キャッシュを使用できますか?
- 分散キャッシュの重要な機能は何ですか？
- Azure で分散キャッシュを使用する実践的な例
ご参加いただきまして誠にありがとうございます。 ウェビナーについて簡単に説明しましょう。 まず最初に、私の名前はロン・フセインです。 私は次の技術専門家の一人です。 Alachisoft そして私が今日のウェビナーのプレゼンターを務めます。 インメモリ分散キャッシュ システムを利用して Microsoft Azure で .NET アプリケーションをスケールアウトするために必要な技術的な詳細をすべて説明します。 NCache この製品の例として。 これが分散キャッシュに関する当社の主力製品です。 私たちは誇り高きメーカーです NCache それをサンプル製品として使用します。 このウェビナーは、聞くだけの内容になります。つまり、ほとんどの話を私が担当しますが、いつでも参加できます。 必要なだけ質問することができます。 画面の右側に、この質問と回答のタブがあります。 [質問] タブを展開すると、必要なだけ質問を投稿できます。先ほども言いましたが、私はこれに注目し、このウィンドウに投稿されるすべての質問に回答します。 ですので、確認のため、同じ質問と回答タブで確認できる場合は、私の画面が見えるか、私の声がよく聞こえるかどうかを確認してください。 すぐに始めることができます。 わかった。 すでにいくつかの質問が投稿されているのが確認できます。 それでは、ご確認いただきまして誠にありがとうございます。
まずはこれから始めましょう。 みなさん、こんにちは。先ほども言ったように、私の名前はロン フセインです。私は、 Alachisoft そして私が今日のウェビナーのプレゼンターを務めます。 今日私たちが選んだトピックは、インメモリ分散キャッシュ システムを利用した Microsoft Azure での .NET アプリケーションのスケールアウトです。 で Alachisoft いろいろな商品がありますが、一番人気があるのは NCache.NET および Java アプリケーション用のインメモリ分散キャッシュ システムです。 NCache がメインの製品になります。これを例として使用しますが、Microsoft Azure の基本に固執します。 使い方 NCache Microsoft Azure の (分散キャッシュ システム) を利用し、スケーラビリティ、アプリケーション パフォーマンス、およびシステム全体の信頼性の点でアーキテクチャに組み込んでください。 では、画面が表示されることが確認できたので、早速始めさせていただきます。
スケーラビリティとは何ですか？
わかった！ 実際のトピックに移る前に。 いくつかの基本的な概念について説明します。まず、スケーラビリティとは何でしょうか?ということから始めます。 スケーラビリティとは、アプリケーションのトランザクション負荷を増加させると同時に、アプリケーションの速度を低下させない機能です。 たとえば、この時点で 1,000 リクエストを処理している場合、アプリケーションの負荷が増加すると、より多くのユーザーがログインし、アプリケーションの使用が負荷よりも重くなり、たとえば、1,000 秒あたり 10,000 リクエストから 10,000 リクエストに増加します。 ここで、その増加した負荷に対応し、その増加した負荷を処理すると同時に、個々のリクエストのパフォーマンスを低下させたくないと考えています。 20,000 つのリクエストが完了を待っていて、XNUMX つのリクエストが完了の途中で、他のリクエストがそれを待っているというような状況は発生すべきではありません。 これらのリクエストは、以前にかかっていたのとまったく同じ時間で処理される必要があります。 しかし同時に、スケーラビリティ、つまり XNUMX 秒あたり XNUMX リクエストまたは XNUMX リクエストを読み込む、より多くのリクエストを処理できる機能も必要です。 したがって、パフォーマンスを損なうことなく、アプリケーションのトランザクション負荷を増やすことができれば、それがスケーラビリティと呼ばれます。 今日はそこに焦点を当てます。
線形スケーラビリティとは何ですか?
関連用語として「無制限のスケーラビリティ」があります。 それは線形スケーラビリティです。 線形スケーラビリティとは、XNUMX 秒あたりの読み取りおよび書き込み容量が線形に増加することです。 たとえば、さらにサーバーを追加する場合です。 したがって、サーバーを XNUMX つ追加すると、読み取りおよび書き込み操作のリクエストを処理できるようになります。 別のサーバーを追加した後、さらにサーバーを追加した場合はどうなりますか? サーバーを追加できる機能、およびサーバーを追加することによってスケーラビリティの数値が増加し、アプリケーション アーキテクチャによって処理される容量がますます増加します。これを私たちは線形スケーラビリティと呼んでいます。
スケーラビリティが必要なアプリケーションはどれですか?
今！ 次の疑問は、どのような種類のアプリケーションにスケーラビリティが必要になるかということです。 答えはとても簡単です。 ユーザーからの何百万ものリクエストを処理する必要があるアプリケーション。 巨大なトランザクション負荷を処理している場合。 通常、ASP.NET アプリケーションがあります。 たとえば、電子商取引アプリケーションや航空予約アプリケーションなど、一般公開されているもののトラフィックが多いフロントエンドがある場合、そのアプリケーションはスケーラビリティの最有力候補となります。
そうすれば、.NET Web サービスとサービス指向アーキテクチャ用の WCF を使用できるようになります。 それは戻ってくる可能性もあれば、フロントエンド Web サービスである可能性もあり、Web アプリケーションや内部アプリケーションによって消費される可能性もあります。 これらは膨大な量のリクエストを処理する必要がある場合があり、膨大な量のデータを取得して呼び出し側プログラムに配信する必要があります。 したがって、この種のアプリケーションにはスケーラビリティも必要です。 そして、リクエストの負荷量を処理できる何らかのインフラストラクチャを導入することもできます。
次に、ビッグデータ アプリケーションがあります。 これは最近よく使われる流行語です。 多くのアプリケーション、多くのアーキテクチャがそれに向けて移行しており、さまざまなモジュール、さまざまなプロセスに分散するために大量のデータを処理する必要があるかもしれませんが、最終的には大量のデータ、大量のデータを扱うことになります。これを処理するためのリクエスト。
そして、複数の安価なサーバーに分散して膨大な量の計算を処理する必要がある、優れたコンピューティング アプリケーションもあります。それがアプリケーションです。 そのため、一般に、ユーザーまたはバックエンド プログラムからの XNUMX 万件のリクエストを処理する必要がある .NET アプリケーションまたは Java アプリケーションは、アーキテクチャにスケーラビリティが必要な主な候補です。
そして、一度これらのいくつかに焦点を当ててから、ユースケースにも進みます。 そして、皆さん、このウェビナーはまだ始まったばかりです。参加したばかりの方のために、分散キャッシュの観点からいくつかの基本概念を説明します。 直面する可能性のあるさまざまな問題とその解決策について説明し、次のような分散キャッシュの展開についても説明します。 NCache Microsoft Azureで。 ご質問がございましたら、お気軽に「質問と回答」タブにご入力ください。 また、いつでもフィードバックをお寄せください。 参加したい場合は、同じ質問と回答タブを再度使用できます。
スケーラビリティの問題とは何ですか?
次に、スケーラビリティを定義したら、スケーラビリティとは何でしょうか? 線形スケーラビリティとは何ですか?また、どのような種類のアプリケーションにスケーラビリティが必要ですか? このウェビナーの次の最も重要なポイントは、アプリケーションがどのような種類のアプリケーション、またはどのようなスケーラビリティの問題に直面するかということです。 スケーラビリティの問題は一体どこにあるのでしょうか?
さて、アプリケーション アーキテクチャとしては、ASP.NET アプリケーションや WCF サービスが考えられますが、これらは非常にうまくスケールアウトされ、すでに直線的にスケールされています。 ロード バランサーを前面に配置し、アプリ サーバーや Web サーバー、Web フロント エンド サーバーをさらに追加するだけで、アーキテクチャからすでに線形のスケーラビリティが得られます。 したがって、そこには問題はありません。 データ ストレージに関する実際の問題、これらのアプリケーション サーバーや Web サーバーは、常にデータベース状態サービスなどのバックエンド データ ソースと通信するか、バックエンド ファイル システムやレガシー データ ソースである可能性があります。 。 これでは巨大なトランザクション負荷を処理できず、サーバーをどんどん追加することもできません。 そして、この図はこれをうまく説明しています。
データ ストレージがある場所には、スケーラビリティのボトルネックがあります。 ここに ASP.NET WCF の例がありますが、必要な数のサーバーを追加できます。最初は XNUMX 台のサーバーから始めます。負荷が増大した場合は、別のサーバーを追加し、前にロード バランサーを配置して、すべてのサーバーを均等に使用できます。このレイヤー上のリソース。 したがって、問題はありません。 ただし、これらのアプリケーション ボックスまたは Web フロントエンド サーバーは常にバックエンド データ ソースと通信します。 これは典型的な展開であり、データベース サーバーがあり、起動がそれほど速くなく、その後スケーラビリティの問題が発生します。 巨大なトランザクション負荷がかかると機能が停止し、場合によっては単一障害点にもなります。 しかし最も重要なことは、どのようなアプリケーション アーキテクチャにおいても、これらのデータベース サーバーは非常に深刻な脅威をもたらし、それがスケーラビリティのボトルネックになるということです。 したがって、すべてのリクエストを一部のデータベース サーバーに戻すと、この層で実現できるスケーラビリティがすべて失われます。 ASP.NET セッション状態の場合も同様です。 SQL Server またはセッション状態サーバーを使用する場合、それはその上に留まるためです。 すべてのセッション データは常に XNUMX 台のサーバーでホストされ、セッションは非常にトランザクション的な種類のデータであるため、それらのリクエストを処理するには非常にスケーラブルなデータ ソースが必要になります。 したがって、これが私たちが分散キャッシュ システムの助けを借りて解決しようとしている主な課題です。
解決策：インメモリ分散キャッシュ
解決策は非常に簡単で、先ほども述べたように、スケーラブルなメモリ内分散キャッシュ システムを使用できます。 のような NCache スケーラビリティに関してデータ ソースに関連するすべての問題に対処するためです。
次に、すぐに、次のようなインメモリ分散キャッシュ システムの基本について説明します。 NCache。 重要な特徴がいくつかあります。 NCache そして、これは、利用可能なほとんどのインメモリ分散キャッシュ システムの一部になると予想しています。 したがって、この点に関しては、 NCache 定義する必要があるとしたら、インメモリ キャッシュ システムとは何でしょうか?
動的クラスタリング
これは、複数の安価なキャッシュ サーバーが結合されたクラスターであり、CPU 容量だけでなくメモリも活用できます。 したがって、それらは結合されて XNUMX つの容量となり、CPU リソースだけでなくメモリも利用することになります。 したがって、物理的には複数のサーバーになる可能性があり、Web の単純な Web サーバー構成ボックスで十分であればそれほど高価ではありません。これはキャッシュに使用できるものであり、その後、それらのサーバーが結合されて正式な論理容量が得られます。 したがって、アプリケーションの観点から見ると、XNUMX つの分散キャッシュを使用しているだけですが、物理的には複数のサーバーが舞台裏で動作し、このメモリ内分散キャッシュを作成するためにすべての計算能力とメモリを消費する可能性があります。 つまり、これが単一のサーバーではないという最初の最も重要な特徴です。 複数のサーバーが相互に連携して動作することになります。 つまり、XNUMX 台のサーバーですべてのデータをホストし、すべてのリクエストを処理するデータベースの先を行っています。
データの一貫性
次の特徴は、データの一貫性に関するものです。バックグラウンドで複数のサーバーを処理しているため、次の疑問は、更新をどのように処理するかということです。 たとえば、同じデータが XNUMX 台または XNUMX 台のサーバーで更新されたり、レプリカが存在したり、異なるサーバーにデータの複数のコピーが存在したりする場合があります。 したがって、使用するトポロジに関係なく、データは一貫した方法で更新される必要があります。 したがって、キャッシュ サーバー上の何かを更新すると、すべての更新が分散キャッシュ上のすべてのキャッシュ サーバーに表示されるようになります。 ちなみに、私は目に見えるものを使っているのですが、レプリケーションという用語は使っていません。 レプリケーションももう XNUMX つの機能です。 つまり、可視とは、たとえば、サーバー XNUMX によってリクエスト ハンドルが取得され、データが更新されることを意味します。 次のリクエストがサーバー XNUMX に送られた場合、サーバー XNUMX にも同じデータがあった場合、分散キャッシュから古い値ではなく更新された値を取得する必要があります。
したがって、これは分散キャッシュの観点から非常に重要な特性であり、すべてのデータ更新がすべてのキャッシュ サーバーに一貫して適用される必要があります。 そして、これはアプリケーションではなく分散キャッシュの責任であるべきです。 アーキテクチャはこのモデルをサポートする必要があります。
線形スケーラビリティ
次のことは、今日のテーマと一致しますが、線形にスケーリングする方法です。 したがって、分散キャッシュは、メモリ容量だけでなくトランザクションに対しても線形にスケールアウトする必要があります。 これにより、キャッシュ サーバーをさらに追加できるようになり、キャッシュ サーバーの数が増えるにつれて、線形のスケーラビリティが得られるようになります。 先ほどグラフをお見せしました。 つまり、私がここで言っているのは、サーバーをどんどん追加して、処理できるリクエスターの数と、同時にサーバーに保存できるデータの数の容量を増やす必要があるということです。キャッシュを線形に分散します。 したがって、これは非常に重要な特性であり、分散キャッシュから線形のスケーラビリティが得られ、アプリケーション アーキテクチャ全体が非常にスケーラブルになります。
信頼性を高めるデータ複製
XNUMX番目の重要な特徴。 これはオプション XNUMX で、レプリケーションもサポートするトポロジを選択できます。 分散キャッシュがあり、信頼性を高めるためにサーバー間でデータを複製します。 サーバーがダウンしたり、メンテナンスのためにサーバーをオフラインにする必要がある場合でも、データの損失やアプリケーションのダウンを心配する必要はありません。 したがって、これらは分散キャッシュのいくつかの重要な特性です。 これらについては今後のスライドでさらに詳しく説明し、その後、Azure 固有の分散キャッシュのデプロイについても説明します。 Microsoft Azure で分散キャッシュを使用するにはどうすればよいですか? これまでにご質問がございましたら、お知らせください。 質問と回答タブをご利用ください。 全体的に挙手も見られますが、会議への参加にはこの問題があり、多くの挙手が表示されますが、実際に質問がある場合はお知らせください。 質問と回答タブに入力してください。喜んでお答えします。 続けるべきだと思います。
ここでは、分散キャッシュの典型的な展開を示します。 これは一般的な展開であり、Microsoft Azure に固有のものではありません。
NCache Microsoft Azureへの導入
の展開に移ります NCache この直後の Microsoft Azure で。 したがって、通常はオンプレミスでもクラウドでもよく、デプロイメントに関してはそれほど大きな変化はありません。 NCache 行きます。 これは通常の展開方法です NCache、そこには専用のキャッシュ層があります。
これらは、オンプレミスの物理ボックス、ホスト ボックス VM、または実際のクラウド VM の場合もあり、クラウドから VM を取得してそれをキャッシュに使用するだけです。 個別の専用キャッシュ ボックスにキャッシュを作成できます。これが推奨されます。 推奨されるプラットフォームは 64 ビットであり、これが唯一の前提条件です。 NCache .NET 4.0です。 そしてアプリケーションは、オンプレミスまたはホストされる場合もあります。 これらは、IIS のサーバーに直接デプロイすることも、Microsoft Azure に関しては Web ロールまたはワーカー ロールにすることもできます。 これらはすべて、データ要件を満たすためにこのキャッシュ層に接続できます。 これらを個別にインストールしたり、個別のレイヤーを作成したり、すべてを同じレイヤーに配置したりすることもできます。 どちらのモデルもサポートされています。 しかし、一度紹介すると、 NCache アプリケーション アーキテクチャに組み込んで、オブジェクト キャッシュまたはセッション キャッシュ用にデプロイしたら、次のことを説明します。 NCache ユースケースに移行したら、ユースケースを検討します。
使い始めたら NCache、バックやデータベースを経由する高価な旅行を節約できます。 そして、非常にスケーラブルなプラットフォームがここに提供され、必要なだけサーバーを追加してスケールアップできます。 これを先ほど示した図と比較してください。
ここには非常にスケーラブルなプラットフォームがありましたが、これが主な競合の原因でした。 スケーラビリティのボトルネックの主な原因。 これを比較すると、アプリケーション層とデータベースの間に非常にスケーラブルなプラットフォームが存在することになります。 これは非常にスケーラブルなプラットフォームであり、分散キャッシュの観点からも非常にスケーラブルなデータ ソースが得られます。 サーバーは必要なだけ追加できます。 負荷が増大しても、その時点でバックエンド データ ソースが停止することを心配する必要はありません。 サーバーは必要なだけ追加でき、リクエスト処理能力を直線的に拡張できます。 NCache。 導入アーキテクチャに関して質問がある場合はお知らせください。 NCache しかし、全体としては非常に単純です。
さて、次はデプロイ方法です NCache Microsoft Azureで。 それで、私たちのウェブサイトを使用することになります。 そこから図を使いますので、ご了承ください。 Microsoft Azure でのデプロイメントは、オンプレミスでのデプロイメントとそれほど変わりません。
したがって、まず、これを基本的なデプロイメントとし、すべてを同じ Microsoft Azure 仮想ネットワーク上に配置することをお勧めします。 たとえば、仮想ネットワークを作成し、Microsoft Azure 仮想マシンを使用すると、サーバー側のデプロイメントは常に VM 上に行われます。 それで、それが私たちが選んだモデルです NCache Microsoft Azureで。 VM を作成するか、同じ仮想ネットワークを選択してすべての VM デプロイメントを作成します。 たとえば、ここに示すように XNUMX つの VMS から開始し、その後、必要なだけ多くの VM をこのキャッシュ レイヤーに追加できます。 できれば、アプリケーションも同じ Azure 仮想ネットワーク上に配置したいと考えています。 したがって、すべてを同じ仮想ネットワークの一部にすることができ、その場合にパフォーマンスと安定性の利点を最大限に引き出すことができます。 NCache。 これに関する厳しい要件がない場合は、いつでもアプリケーションを別の VM にデプロイできます。
したがって、このモデルに基づいて、アプリケーション アーキテクチャは VM 自体に配置できます。つまり、アプリケーションを自分で管理する IIS に直接デプロイして、それを完全に担当することも、自分自身の Azure Web ロールまたはワーカー ロールの両方にすることもできます。モデルはアプリケーション側でサポートされていますが、 NCache サーバー側の展開は常に VM 上に行われます。 ということで、こんな感じで応募してみます NCache 実践的な部分に進んでから実際にお見せします。
別の種類のデプロイメントでは、XNUMX つの特定の Azure 仮想ネットワークを使用できます。 NCache サーバー VM。すべてのサーバーが同じ仮想ネットワークの一部です。 できれば同じサブネットも必要です。 さらに、アプリケーションを別の仮想ネットワーク上に配置することもできます。 その場合、何らかの種類のポートをサーバー上で転送する必要があります。 NCache 仮想ネットワーク。 たとえば、ここではプライベート ポートがパブリック ポートにマッピングされており、アプリケーションはこのパブリック ポートを使用して実際に接続します。 NCache。 ここで追加の構成を実行する必要がある場合がありますが、そのための詳細なヘルプドキュメントが用意されていますが、問題なく動作します。 この仮想ネットワーク サーバーが別の仮想ネットワークからキャッシュ サーバーにアクセスするようにすることができます。 また、同じ機能を利用してキャッシュツーキャッシュ アプリケーションを使用することもできます。
したがって、これは別の種類の展開ですが、推奨されるアプローチは、すべてのキャッシュ サーバーとアプリケーション サーバーを同じ Microsoft Azure 仮想ネットワーク上に展開することです。 そのときが最大のメリットを得ることができます NCache。 ご質問がございましたらお知らせください。
Azure 導入ガイドも Web サイトから入手できますので、サポートにご案内できれば幸いです。 実際に、ここでドキュメントを見てみましょう。 ドキュメントには、これらすべての詳細を詳細に説明する特定のガイド、導入ガイドがあります。
わかった。 質問があります。 どうですか NCache とは異なる Redis? わかった。 今日の議題はもっと活用することです NCache または Microsoft Azure の分散キャッシュ システムを使用します。 別のウェビナーを開催しています Redis 対 NCache。 で利用可能なさまざまな機能について説明します。 NCache そしてその一部ではない Redis。 これについて簡単に答えたい場合は、ここの比較ページにアクセスして、 Redis 対 NCache。 これにすぐにサインアップすると、すべての機能を機能ごとに比較できるようになります。 NCache 対 Redis。 そして実のところ、これのためのウェビナーも用意しています。これは YouTube チャンネルのウェビナーです。 したがって、YouTube にログインするだけの場合は、 Alachisoft そしてそれから Alachisoft たくさんのビデオがありますが、そのうちの XNUMX つは次のようなものになります。 Redis ソース NCache タイトル。 これについては別のウェビナーがあります。 これであなたの質問の答えが得られることを願っています。 これについてはさらに質問があります。 わかった。 話を戻します。展開について説明しましたが、展開関連の質問があればお知らせください。それらの質問には喜んでお答えします。
分散キャッシュの一般的な使用法
次は分散キャッシュをどう使うかです。 次のような分散キャッシュ システムを使用する共通領域は何ですか? NCache? 最も一般的なものを XNUMX つ挙げましたが、これらは業界に固有のものである可能性があり、要件やユースケースに固有のものである可能性があり、さまざまな使用方法がある可能性があります。 NCache。 しかし、主にこれらは次の XNUMX つのカテゴリに分類されます。
アプリケーションデータのキャッシュ
最初のカテゴリはアプリケーション データのキャッシュです。 次のような分散キャッシュ システムを使用できます。 NCache アプリケーションデータのキャッシュとして。 以前にデータベースに存在し、アプリケーションがデータベースに移動していたものはすべて、今ではそれを置くことができます。 NCache。 また、以前にデータベース内にあったすべてのデータにアクセスするために、データベースと比較して高速なメモリ内キャッシュを取得できます。 したがって、アプリケーションのパフォーマンスを向上させ、次に最も重要なこととして、データベースがスケールアウトできない部分を線形にスケールアウトします。 劇的なレベルまでスケールアウトできます。 大量のトランザクション負荷を処理でき、サーバーは必要なだけ追加できます。 そしてこれには、 NCache API。 キーと値のペアでデータを追加するだけです。 キーは文字列で、値は .NET で許可されたオブジェクトです。オブジェクト キャッシュ モデルを使用すると、ドメイン オブジェクト、コレクション、データセット、画像など、あらゆる種類のアプリケーション関連データをキャッシュできます。 これにより、データ キャッシュ側で提供している機能の点で大きなメリットが得られます。
ASP.NET 固有のデータのための信頼性とスケーラブルなキャッシュ
次の使用例は、ASP.NET 固有のアプリケーションに関するものです。 たとえば、ASP.NET には非常に簡単に始める方法があります。 NCache。 ここには XNUMX つの選択肢があります。
ASP.NETセッションストレージ
ASP.NET セッション状態ストレージがあります。 これを MVC または ASP.NET Web フォームで使用したり、任意の ASP.NET Web アプリケーションで使用したりできます。 コードを変更することなく、セッション データを分散キャッシュに保存できます。 また、データベースや状態サーバーとは異なり、単一のサーバーではありません。 複数のサーバーが存在する可能性があります。 したがって、セッション データがサーバー間でレプリケートされているため、非常にスケーラブルで信頼性が高く、メモリ内にあるため非常に優れたパフォーマンスが得られます。 コードを一切変更せずにすべてを変更できます。 そして、 NCache、マルチサイトセッションの展開も行っています。 XNUMX つのデータセンターを持ち、コードを変更せずにセッションを同期することもできます。 したがって、これらは利用できるいくつかの拡張機能です。 ASP.NET アプリケーションに対するセッション状態のサポートは終了しました。これにはコードの変更は必要ありません。
ASP.NET View State キャッシング
これに関する次の機能は、 ASP.NET view state、これもコード変更のオプションではありません。 ビューステートとは何なのか知りたい方のために説明します。 ビューステートはクライアント側の状態管理です。 たとえば、ビュー ステートが Web フォームにのみ適用される場合、MVC アーキテクチャにはビュー ステートが存在しなくなります。 ASP.NET Webフォームの場合、ページ上にあるすべてのボタンまたはすべてのウィジェットをコントロールします。これらはビュー ステートの作成に寄与し、応答に応じてブラウザに送り返されます。ビュー ステートは結合されます。応答パケットが送信され、ブラウザに送り返されます。 ブラウザ側では、実際には使用されません。 それはただそこに留まり、ポストバックすると、ビューステートがサーバー上のリクエストパケットと一緒に来て、実際にビューステートを使用するときになります。 そのため、常に応答の一部としてブラウザに送り返され、リクエストの一部としてサーバーに戻されるため、リクエストと応答のパケットは重くなります。 ブラウザ側では実際に使用されることはありません。 常にサーバー側で使用されます。 特に巨大なトランザクション負荷がかかると、帯域幅が大量に消費されます。
したがって、パフォーマンスや帯域幅の使用率の点で、これに関連する多くの問題があります。 と NCache ビューステートをサーバー側に保存することも、サーバー側に保持することもできます。 NCache、小さなダミー トークンをブラウザに送り返します。 したがって、ビューステートのサイズが小さくなり、帯域幅使用コストが向上します。 これにより帯域幅を大幅に節約できます。 そして同時に、パケットが小さいほど処理が容易になります。 リクエストとレスポンスのパッケージが小さくなり、アプリケーションのパフォーマンスの向上にも貢献します。 したがって、当社の使用を開始すると、パフォーマンスが向上し、帯域幅使用コストが削減されます。 ASP.NET view state プロバイダー。 これはコード変更不要のオプションでもあります。 NCache。 Microsoft Azure では非常に簡単に使用できます。
ASP.NET出力キャッシュ
ここでの XNUMX 番目の重要な機能は、ASP.NET MVC および Web ファーム用の ASP.NET 出力キャッシュ プロバイダーです。 アプリケーション内に、異なるリクエストに対して XNUMX つの異なるページにかなり静的なコンテンツがある場合、それらすべてのリクエストを再レンダリングして再実行するのではなく、たとえそれらのリクエストに応答して同じデータを取得したとしても、それらをキャッシュし、その後、キャッシュされた出力を後続のリクエストに使用します。 同じリクエストを再度受け取った場合は、ドリルを実行せずに、単純にキャッシュ コンテンツを取得します。 NCache 直接。 したがって、ASP.NET ページ出力全体を次の場所に保存できるようにします。 NCache 後続のリクエストに使用されます。 また、ASP.NET 出力キャッシュ プロバイダーの助けを借りて、処理能力と実行時間を大幅に節約し、パフォーマンス上の多くの利点を実現できるため、コードの変更も必要ありません。
したがって、これらはすぐに始めることができる 10 つの重要な側面です。 これらはすべてコード変更のないオプションです。 セットアップには 15 ～ XNUMX 分かかる場合があります。その後、これまで説明してきたすべての利点を実感できるようになります。 そして、Microsoft Azure には、これらに代わるものはありません。 最終的にはデフォルトのオプションを使用することになります。これは、すべてをこのデータベースのプロセッサーに保持することを意味します。 そして、それらに関連する問題とは何かについてはすでに話しました。 したがって、まずはこれらの機能を確認し、ユースケースが進んできたら、アプリケーション データ キャッシュを並行して使用し始めることを強くお勧めします。 XNUMX 番目の重要な使用例は、 NCache, アプリケーション アーキテクチャで分散キャッシュを使用する重要性を伝えることができるよう、これらに多くの時間を費やしています。 ここまでの時点で何かご質問等ございましたらお願いいたします。
メッセージングによるスケーラブルな実行時データ共有
XNUMX 番目に重要なユースケース NCache それは、メッセージング サポートの助けを借りて、ランタイム データ共有プラットフォームとしてスケーラブルかつ非常に信頼性の高い方法で使用できることです。 MSN キューや Java メッセージング サービスに似ています。 メッセージングプラットフォームもあります。 すでにキャッシュにデータがあるため。 たとえば、データが追加された場合、製品カタログがある場合、製品が追加、更新、またはキャッシュから削除された場合、それに基づいて通知を受け取りたい場合は、イベント通知伝播システムを使用して伝播して通知することができます。キャッシュ内のデータが変更された場合に使用します。 そのため、必要に応じてこれらのメッセージに接続して使用を開始できるデータ レベルのメッセージがあり、また、カスタム アプリケーション メッセージもいくつか存在し、メッセージング プラットフォームの助けを借りて XNUMX つのアプリケーションが他のアプリケーションと通信できるようになります。 したがって、あるアプリケーションが他のアプリケーションとデータを共有でき、同じ分散キャッシュ システムを使用する異なるアプリケーション間でメッセージを共有できるため、非常に強力なデータ共有になります。 これは非常に強力な機能であり、多くの人はそれを知りませんが、提供される機能という点では非常に強力です。
ご質問がございましたらお知らせください。 これらはいくつかの重要な使用例です NCache、すぐに説明します。 Microsoft Azure で分散キャッシュを使用することを計画したら、非常に重要な概念、つまり作成するシーンが非常に重要になります。
キャッシュするデータは何ですか？
キャッシュする必要があるデータの種類は何ですか? 現在、分散キャッシュは通常、最も簡単にアクセスできるデータ用であり、より多くの読み取りと書き込みがあり、そのデータは後続のリクエストで何度も読み取られます。 データを XNUMX つの異なるカテゴリに分類しました。 通常はデータベース内に存在する永続データを持つことができます。変更される可能性はありますが、変更の頻度はそれほど高くありません。そのため、データを参照データとトランザクション データにさらに分割しました。 しかし、永続的なデータと一時的なデータがあります。 永続データはデータベース内に実際に存在するデータであり、キャッシュすることが非常に重要です。 これにより、バックエンド データベースへの高価な移動が削減されます。
次に、一時的なデータである一時データがあります。これは長さが短く、現在のユーザーのスコープでのみ有効であるか、さらに言えば現在のアプリケーション サイクルのスコープでのみ有効です。 それはユーザー構成、ユーザー設定、ユーザー ASP.NET セッション、ビュー ステート出力キャッシュである可能性があります。 通常、これはデータベースには属しませんが、どれくらい早く必要になるか、またキャッシュした後に何回必要になるかに応じて、キャッシュに保持しておくと意味があります。 その後、このデータをさらに他のカテゴリに分類できます。 たとえば、データのほとんどが読み取りである場合、読み取り数が書き込み数よりも多い場合、または読み取り数と書き込み数が同じである場合などです。 したがって、参照は書き込みよりも読み取りの方が多く、トランザクションは書き込みだけでなく読み取りも行われます。
次に、一時的なデータである一時データがあります。これは長さが短く、現在のユーザーのスコープでのみ有効であるか、さらに言えば現在のアプリケーション サイクルのスコープでのみ有効です。 それはユーザー構成、ユーザー設定、ユーザー ASP.NET セッション、ビュー ステート出力キャッシュである可能性があります。 通常、これはデータベースには属しませんが、どれくらい早く必要になるか、またキャッシュした後に何回必要になるかに応じて、キャッシュに保持しておくと意味があります。 その後、このデータをさらに他のカテゴリに分類できます。 たとえば、データのほとんどが読み取りである場合、読み取り数が書き込み数よりも多い場合、または読み取り数と書き込み数が同じである場合などです。 したがって、参照は書き込みよりも読み取りの方が多く、トランザクションは書き込みだけでなく読み取りも行われます。 したがって、すべての参照データをキャッシュすることを検討できます。これは通常、データベースに属する永続的なデータです。 それを分散キャッシュに取り込んで、データベースに戻らないようにできる限り多くのデータをキャッシュしてみてください。 これにより、必要なパフォーマンス上の利点のほとんどが得られます。 次に、バックエンド データ ソースから一時データやトランザクション データを取得するときにパフォーマンスを低下させたくないため、ASP.NET セッション ステート、ビュー ステート、出力キャッシュなどのトランザクション データの一部をキャッシュすることを検討する必要があります。 。 ユーザーの数にもよりますが、何百万ものユーザーがログインしている場合は、ユーザーごとにデータベースに XNUMX 回アクセスするシナリオを考えてください。低速なソースからデータを取得するのにどれだけの時間がかかるかがわかります。 、バックエンド データ ソースから。 キャッシュから取得するため、分散キャッシュにキャッシュすることを必ず検討する必要があります。
キャッシュ API の概要
キャッシングはこんな感じです。 Interfaceのようなハッシュテーブルです。 文字列ベースのキーがあり、その値としてオブジェクトがあります。 オブジェクトには、任意の .NET パラメータ オブジェクトを指定できます。 .NET で許可されているものはすべてオブジェクト キャッシュとして保存できます。 文字列キーの場合は、意味のあるキー構成を思いつくことができます。 たとえば、従業員 ID 1000 のすべての従業員、従業員 ID 1000 の従業員をこのキーでここに保存できます。 その従業員のすべての注文にこのキーを含めることができます。ここでは、従業員の注文とその従業員の ID が存在します。 実行時パラメータも存在する可能性があります。 そして、従業員のクエリを実行することもできます。 たとえば、責任のあるクエリをキャッシュし、引数がマネージャーに等しい役職に基づいて従業員というコードを検索したとします。 したがって、キャッシュ内に単一のオブジェクトとして保存されたコレクションを取得できます。 したがって、これはキャッシュ キーを作成する方法の単なる例ですが、必要に応じてキーの基礎となるテクニックを思いつくことができます。 これは単なる例です。アプリケーションにとってより意味のあるものを使用してください。
皆さん、何か質問があれば教えてください。 今日はあまり質問がありません。 これまでにご質問がございましたら、お知らせください。 また、特定の部分でペースが遅すぎるか速すぎる場合は知らせて、ペースを維持できるようにします。 同じ質問回答タブを使用してフィードバックをお寄せいただくこともできます。特定の機能についてもより多くの時間を費やします。
皆さん、何か質問があれば教えてください。 今日はあまり質問がありません。 これまでにご質問がございましたら、お知らせください。 また、特定の部分でペースが遅すぎるか速すぎる場合は知らせて、ペースを維持できるようにします。 同じ質問回答タブを使用してフィードバックをお寄せいただくこともできます。特定の機能についてもより多くの時間を費やします。 わかった。 空間データはどうなるのかという質問があります。 わかった。 そのようなデータもクエリできますか? はい。 もちろん、非常に強力なクエリのサポートがあり、このオブジェクトはどのようなタイプでもかまいません。 したがって、これはキャッシュする予定のあらゆる種類のデータをカバーしていることをお伝えしておきます。 これで、渡したさまざまなパラメータに基づいて、さまざまな引数に基づいてデータをクエリできるようになりました。 実際のところ、私たちは非常に強力なオブジェクト クエリ言語を持っており、それをここで計画しました。 したがって、オブジェクト クエリ言語を使用して並列クエリを実行します。 また、オブジェクト クエリ言語を使用すると、非常に柔軟なクエリを実行できます。 たとえば、あなたからこんな質問がありました。 たとえば、現在の場所に近いすべての会場を取得したい場合は、「はい」になります。 あなたはできる。 たとえば、すべてのデータがキャッシュ内に伝播されているとします。 すべてのメニューが別個のオブジェクトとしてキャッシュに個別に保存されています。 右？ そして、それらのオブジェクト属性を取得すると、位置情報も得られます。 したがって、すべての会場を選択するクエリを実行できます。ここで、会場はその場所に等しいです。 したがって、オブジェクト属性にこの情報があれば、一致するすべてのレコードを配布キャッシュから取得できます。 だからこそ、一つの方法として。
XNUMX 番目の方法は、クエリが必要な空間情報またはすべての情報を、タグの形式でオブジェクトの一部として渡すことです。 オブジェクトを保存してから、ここにタグとして追加のキーワードを保存します。 これらは識別する識別子であり、キャッシュ内に論理的なコレクションを作成します。 したがって、タグベースの API を使用して、「タグで取得」と言うと、結果に一致するコレクション全体を取得することもできます。あるいは、「タグが次と等しい場所を選択する」というクエリを実行することもでき、タグは本質的には次のとおりです。すでに追加した場所。タグは XYZ 場所に等しく、その基準に基づいて一致するすべてのレコードが取得されます。 したがって、クエリを処理するには、オブジェクトの上にタグを追加するか、実際のオブジェクトの属性にのみ依存する XNUMX つの方法があります。 そして、それらに対して SQL のような検索クエリを実行します。 あなたの質問に答えられることを願っています。 これに関してさらに質問がある場合はお知らせください。
もう一つ質問があります。 イベントに基づいて特定のキャッシュされたアイテムの有効期限を設定できますか? たとえば、レコードはキャッシュされ、データベース内で更新されると期限切れになります。 絶対に！ 有効期限はXNUMX種類あります。 時間は有効期限であり、有効期限には XNUMX 種類あります。そのため、時間が経過するとアイテムを期限切れにすることができ、この有効期限はデータベースの依存関係に基づくこともできます。 たとえば、データベース内で何かが変更された場合、それがあなたの質問の答えになります。 たとえば、データベース内でレコードが変更された場合、キャッシュ内にレコードがあり、それに依存していました。そのデータベース レコードが変更されるとすぐに、データベースはイベント通知を送信し、キャッシュ内のアイテムを前面から自動的に削除できます。キャッシュ。 したがって、データベース内で有効期限が切れるとすぐに期限切れになる可能性があります。 したがって、これはまさにリレーショナル データベースの依存関係に関して私たちが提供しているものであり、SQL の依存関係がこれをカバーします。 他のスライドをすぐに読んでから、オブジェクト キャッシュの部分に進んでいただければ幸いです。これで多くの質問が解決されるはずです。 他にご質問がございましたら、同じところからプレゼンテーションを再開させていただきますので、お知らせください。
質問があります。 サンプルの永続化を表示し、サンプル キャッシュからデータを取得できますか? まずはサンプルをご覧になることをお勧めします。 NCache これらは当社のウェブサイトからも入手できます。 それでは、簡単にサンプルをご紹介します。 NCache。 これを正確に処理するサンプルをご案内します。 したがって、データベースの同期があり、次に依存関係があります。 したがって、これらはそうすべきです。 依存関係ハンドル、SQL 依存関係、およびデータベース同期も別の種類のサンプルであり、読み取りおよび書き込みリクエストを使用してシナリオを処理するのに役立ちます。 これがあなたの質問の答えになることを願っています。 どうもありがとうございます。
もう XNUMX つ質問があります。 データを並べ替えるためにこれをクエリできますか? はい。 サポートごとに注文ごとにグループ化しています。 したがって、これらの属性をクエリと一緒に使用できます。 とても良い奴らだ！ ご質問をお送りいただきまして誠にありがとうございます。 本当に感謝しています。 これからも来てください。 これはプレゼンテーションの終わり頃に計画されており、すでにこれらについて説明するつもりでしたが、すべての質問が寄せられるのは良いことですので、引き続き質問してください。 どうもありがとうございます。
NCache アーキテクチャ
さて、次は早速建築の話に行きます。 分散キャッシュは、サーバーの追加または削除に関して非常に柔軟です。 サーバーは必要なだけ追加できます。 どのサーバーでもオフラインにすることができます。 これは、TCP ベースのキャッシュ クラスタリングに基づいています。 これは、私たちが独自に実装した質問プロトコルです。 サードパーティまたは Windows クラスタリングは使用していません。 Microsoft Azure であっても、IP アドレスとポートに依存するだけです。 NCache 残りの世話をするでしょう。 これは 100% ピアツーピア アーキテクチャです。 単一障害点はなく、任意のサーバーをオフラインにして新しいサーバーを追加しても、クライアントには影響がありません。 実行中のキャッシュ クラスターに変更を動的に適用できます。 これらの構成は、これらのサーバーがクライアントと常に通信するように動的になります。 サーバーがダウンしたり、新しいサーバーが追加されたりすると、すぐに通知されます。 メモリ内マップがあり、これがクライアントに伝播され、キャッシュに変更があるたびに更新されます。 したがって、これらのマップはクラスター メンバーシップ情報とキャッシュ トポロジ情報マップであり、キャッシュ クラスターに変更があるとすぐに更新されます。 そのため、接続フェイルオーバーのサポートがあり、サーバーがダウンした場合、クライアントが自動的にそれを行い、サーバーがそのサーバーを離脱させ、生き残ったノードが自動的に利用可能になり、クライアントが自動的に接続します。 つまり、クライアント アプリケーションに関する限り、データ損失やアプリケーションのダウンタイムは発生せず、XNUMX つの異なるトポロジから選択できます。
キャッシングトポロジ
アクティブ モードとパッシブ モード、またはマスター モードまたはスレーブ モードは、キャッシュ トポロジに基づいて決定されます。 先ほども言いましたが、これはピアツーピア アーキテクチャです。 したがって、各サーバーは独立してキャッシュ クラスターに参加します。 したがって、依存関係はなく、以前のようなリードホストの概念もありません。 AppFabric あるいは、構成やクラスター管理の観点からも、アクティブかパッシブは存在しません。 すべてのサーバーは、構成およびキャッシュ クラスター内の位置に関して 100% 独立しています。 ただし、さまざまなキャッシュ トポロジがあり、アクティブとパッシブがありますが、それらはキャッシュ内のデータに基づいています。 データがアクティブに利用可能な場合、それをアクティブと呼びます。データが単なるバックアップであり、クライアントがデータに接続していない場合、それをパッシブと呼びます。 ただし、このパッシブ サーバーは、100% ピアツーピア アーキテクチャのキャッシュに再び追加されます。
質問があります。 モバイル プラットフォーム、Android または iOS で使用できる SDK はありますか? NCache ネイティブモバイルアプリでは？ 現時点では Java API だけでなく .NET もあり、Restful API の開発に取り組んでいます。それがリリースされれば、iOS アプリだけでなく Android アプリからも使用できるようになるでしょう。 それについてはメールを送ってください。リクエストを送ってください。エンジニアリング部門に転送します。また、タイムラインも含めてすぐにご連絡します。
これで、XNUMX つの異なるキャッシュ トポロジができました。
ミラーリングされたキャッシュ
アクティブ/パッシブのミラーリングを行いました。 これは今日の議題ではないので、簡単にざっと目を通しておきます。 私は実践的な部分にもっと焦点を当てたいと思っています。 それでは、さまざまなトポロジーを少し見てみましょう NCache オファー。 XNUMX つの異なるトポロジがあります。 ミラーリングされたキャッシュは、XNUMX ノードのアクティブ/パッシブです。 すべてのクライアントがアクティブに接続されており、バックアップ サーバーがここにあります。 アクティブがダウンすると、バックアップは自動的にアクティブになります。 そして、これらのクライアントは自動的にフェイルオーバーします。 これは小規模な構成に推奨され、読み取りと右に非常に適しており、信頼性も非常に高いです。
複製されたキャッシュ
次に、Replicated を示します。これはアクティブ/アクティブ モデルです。 したがって、両方のサーバーはアクティブですが、クライアントは分散されています。 したがって、Microsoft Azure に XNUMX つの Web ロールまたはワーカー ロールがあり、均等に負荷分散されている場合、一部はサーバー XNUMX に接続し、一部はサーバー XNUMX に接続します。 ここには同期モデルがあります。
ミラーリングでは非同期が行われたため、読み取りパフォーマンスも非常に高速でした。 レプリケートでは常に同期モデルがあります。 したがって、各サーバーにキャッシュのコピー全体があり、これらのサーバーには同じデータがあり、同期された方法ですべての更新がすべてのサーバーに適用されます。 たとえば、サーバー XNUMX でサーバー項目番号 XNUMX を更新すると、同期方式でサーバー XNUMX に適用され、その操作が完了します。 ただし、読み取りは、クライアントが接続されているサーバー上でローカルに適用されます。 したがって、読み取りは非常に高速でスケーラブルであり、書き込みは非常に一貫性があります。なぜなら、ここで何かを変更すると、常にその変更がここにも反映され、その操作のみが完了するからです。 したがって、更新のための信頼性の高いデータ トランザクションと超高速パフォーマンスを実現するには、これは非常に優れたトポロジです。サーバー XNUMX が失われると、これらのクライアントはサーバー XNUMX にフェイルオーバーし、サーバー XNUMX が失われると、これらのクライアントはフェイルオーバーします。 したがって、データの損失やアプリケーションのバウンスは発生しません。
パーティション化されたキャッシュ
次に、パーティション化されたキャッシュがあり、データがパーティション化され、次にレプリケーションでパーティション化されます。 そのため、必要に応じて XNUMX 台以上のサーバーを使用でき、データはすべてのサーバーに自動的に分割されます。 一部のデータはサーバー XNUMX に送信され、一部のデータはサーバー XNUMX に送信されます。 コインの分布マップは、キャッシュ内にデータが存在する場合、サーバーを特定し、そのサーバーをデータの読み取りおよび書き込みに使用することをすでに認識しています。 サーバーが増えると、キャッシュからのコピーの読み取り、書き込み、データの読み取り元のサーバー、データの書き込み先のサーバーが増えることを意味します。 したがって、これらのサーバーは全体的なパフォーマンスと全体的なスケーラビリティに貢献します。 したがって、サーバーが増えると、キャッシュのスケーラビリティが向上します。 Partitioned にはバックアップがありません。
パーティション-レプリカキャッシュ
レプリカを含むパーティションがあり、各パーティションを別のサーバー上のパッシブ レプリカ パーティションにバックアップできます。 たとえば、ある人のバックアップはサーバー XNUMX にあり、サーバー XNUMX のバックアップはサーバー XNUMX にあります。 そのため、サーバーがダウンしたり、サーバーをオフラインにする必要がある場合でも、データが失われることはありません。 バックアップは一度に利用可能になります。 また、これは非常に直線的にスケーラブルでもあり、実際、パフォーマンス数値の点で最もスケーラブルなトポロジです。
これを裏付けるベンチマークの数字をいくつか紹介しましょう。 ご質問がございましたらお知らせください。 先ほども述べたように、ここでは時間を節約するために、これらのトポロジをざっとざっと見ていきます。
ここでは XNUMX つのノードを持つミラーリングされたキャッシュを示します。 レプリケーションは読み取りには非常に優れていますが、書き込みはそれほどスケーラブルではありませんが、書き込みのスケーラビリティだけでなく、読み取りとの更新とパーティションの同期の性質があるため、ここでポイントがわかります。 読み取りと書き込みを備えたパーティション化されたレプリカにはバックアップも含まれるため、パフォーマンスとスケーラビリティを備えたバックアップを取得できます。 そして、同期レプリカを使用してパーティション化されたレプリカも作成します。
クライアントキャッシュ
他にもいくつかの機能があります。たとえば、コードを変更せずにローカルのニアクライアント キャッシュもサポートしており、アプリケーション側でもキャッシュを有効にすることができます。 このキャッシュはサーバー キャッシュと同期しており、主に参照タイプのデータに推奨されます。 したがって、書き込みよりも読み取りの方が多い場合は、これをオンにすると、既存のアプリケーションに加えて超高速のパフォーマンス向上が得られます。 ネットワーク上の移動を分散キャッシュに保存します。 これにより、すでにデータベースの後方への移動が保存されていますが、クライアント キャッシュを使用して、ネットワークを経由する必要があるこの移動を保存することもできます。 それをオフにするだけです。 さらに、アプリケーションへのプロセス内で実行して、シリアル化とプロセス間通信をさらに節約することもできます。 そして NCache すべての同期を管理します。 ここで何かが変更されると、それはここだけでなく他のクライアント キャッシュにも伝播され、その逆も同様です。 使い始めるには非常に良い機能です。 パフォーマンスのベンチマークについてはすでに説明しました。
分散キャッシュの WAN レプリケーション
さらに、Microsoft Azure では WAN レプリケーションもサポートされています。 たとえば、XNUMX つのデータ センターがあり、XNUMX つはニューヨークに、もう XNUMX つはおそらくヨーロッパにある場合、あるデータ センターから別のデータ センターにデータを転送することもできます。 ここにキャッシュ クラスターを配置し、ブリッジの助けを借りて、アクティブ/パッシブ ノードでバックアップされるデータをブリッジに転送し、ブリッジがそのデータをターゲット サイトに転送することができます。 これは、DR シナリオではアクティブ/パッシブである場合もあれば、アクティブ/アクティブである場合もあります。
わかった。 質問があります。 一時的にネットワーク接続がないモバイル アプリなど、切断されたシステムでクライアント キャッシュを使用できますか? とても良い質問ですね。 問題は、クライアント キャッシュを切断モードで使用できるかどうかです。 私たちはそれについて話しました。 これはクライアントの XNUMX 人からの機能リクエストでした。その後、実際に詳細に話し合いました。 それで、あなたが興味を持っている特定の要件があります。私たちはすでにいくつかの計画を立てており、これについてはすでに議論しており、それ以来、これと同様のリクエストがすでにあります。 それについて電子メールを送っていただければ、私のユースケースでクライアント キャッシュを使用し、切断モードでも使用できるようにしたいと考えています。 エンジニアリング部門ではすでに議論されており、たまたまこれを提供しているため、喜んでこの件をエンジニアリング部門に伝えます。 どうもありがとうございます。
わかった。 その場合はメールお待ちしております。 この時点で、クライアント キャッシュはサーバー キャッシュと組み合わせて動作します。 これがダウンすると、クライアント キャッシュはサーバー キャッシュと同期するため、すべてのデータも失われます。 ただし、切断モードを使用する予定です。このモードでは、サーバー接続がダウンした場合でも、クライアント キャッシュは稼働し続け、後の段階で実行されるいくつかの操作もキューに入れられます。
実践的なデモ
次に、実践的なデモを簡単に紹介します。 実際の製品はどのように動作するのでしょうか？ 残り時間が少しありますが、残り時間は XNUMX 分だと思います。 そこで、Azure の概要を簡単に説明します。 始めるために基本的に必要なもの NCache の展開を計画するということです NCache.
まず最初に必要なのは、Azure 仮想ネットワークを作成することです。 Microsoft Azure にアクセスし、仮想ネットワークを作成します。 クイック作成またはカスタム作成を使用することもできます。たとえば、クイック作成を選択した場合は、次のように言うことができます。 NCache VM。 これは、次の目的で使用する仮想ネットワークになります。 NCache そして、この仮想ネットワークを作成するだけです。 必要に応じて、仮想ネットワークに関する具体的な詳細を考え出すことができます。 または、環境内にすでに仮想ネットワークがあり、それを使用したいと考えている場合もあります。 NCache 展開。 それが私たちの最初のステップです。 すでに作成されている仮想ネットワークがいくつかあります。 それで、次のステップに進むことができます。
次のステップは、 NCache 仮想マシン。 必要なのは、次のような仮想マシンを作成することだけです。 NCache プリインストールされているので、インストールするだけです NCache Microsoft Azure VM イメージをから取得します。 Azure marketplace それはのためです NCache professional でも興味があるなら NCache enterprise、単純にプレーンイメージ 2012 サーバーを使用できます。 インストール NCache 新しい VM を生成する必要があるたびに、その上にそのイメージを保存し、後の段階でそれをロードします。 NCache サーバーの展開。 したがって、ギャラリーからイメージ (たとえば 2012 サーバー) を選択するだけです。 名前を付けるだけで、次を選択できます。 たとえば、デモ 3 です。サーバー層を選択し、必要に応じて情報を入力するだけです。
これらは Azure 固有の手順です。 したがって、これについてはよくご存知だと思います。 次に最も重要なことは、新しいものを作成したいかどうかです。 cloud service または、すでに存在するものを使用します。 たとえば、ベンチマークを使用すると、仮想ネットワークも自動的に検出されます。 ただし、独自の VM を作成することもできます。 cloud service新しいものを作成することもできます。 cloud service。 ただし、すべてのサーバー VM に対して仮想ネットワークを選択し、それをすべてのサーバー VM で同じにすることをお勧めします。 NCache。 そのため、サーバー間の通信に関しては、システムのパフォーマンスが向上します。 したがって、このベンチマークを選択し、それに基づいて次のベンチマークを選択するだけです。
必要に応じて、ネットワークに関する特定の詳細を入力できます。 しかし、全体として、必要なのはこれだけです。 それで、私はただ...わかりました。 私が選択したクラウド サーバーは、この種類の仮想マシンをサポートしていません。 したがって、新しいものを作成することを選択する必要があるだけです cloud service それと。 わかった。 それで、承認するように言っておきます。それで終わります。 ということで、こうなります。 ただ、これに関してはキャンセルさせていただきます。 これらのサーバーはすでにここにあり、実際、すでに構成済みのいくつかのサーバーにすぐにログオンできます。 では、ご容赦ください。 キャッシュを作成して環境内で構成し、環境内で簡単にテストする方法を説明します。 XNUMX分ほど時間があります。 なので、しっかり活用していきたいと思います。 必要なだけお気軽に質問を投稿してください。 環境を整えながら質問には必ず答えます。
わかった。 これらのサーバーはすでに持っています。 これらにすぐにログオンできます。 すでにいくつかのテストにこれらを使用していますが、ここでパスワードを間違えたようです、ご容赦ください。 さあ！ わかった！ ほら！ デモ 2 はここにあります。 これが私の XNUMX つのボックスです。 わかった！ したがって、これら XNUMX つのボックスは、Microsoft Azure の同じ仮想ネットワークの一部としてすでに構成されています。
質問があります。 VM は必ず必要ですか? それとも Azure アプリ サーバーを使用できますか? ドッカーはどうですか？ まだ Docker のサポートはありません。 エンジニアリング部門が開発に取り組んでいるかどうかを確認できます。 サーバーモデルに関する限り、 NCache Microsoft Azure 上に VM が必要です。 仮想アプリケーションはサービス モデルである可能性があります。 cloud service、Web ロール、ワーカー ロール、アプリケーションがデプロイされている実際の VM の可能性があります。 しかし NCache サーバー部分は VM である必要があります。先ほど述べたように、最も簡単な方法は、事前に構成された VM イメージを作成することです。 NCache。 ギャラリーに保持しておき、新しいインスタンスを生成する必要があるときにロードします。 利用可能な VM テンプレートがある場合は、自動スケーリングにも同じものを選択することもできます。 NCache インストールがアクティブ化され、構成されている場合は、ノードが特定の制限に達したときに、新しい VM を生成するだけです。
もう一つ質問があります。 すでに述べたかもしれませんが、帯域幅使用率の観点からデータを削減するための暗号化と圧縮はありますか。暗号化と圧縮について質問していると思います。 はい！ これら XNUMX つの機能は、コードを変更することなく利用できます。 機密データを送信するためにデータを暗号化することができ、データを暗号化してから圧縮することもできます。 したがって、これらは一部です NCache サポート。 ご質問いただきまして誠にありがとうございます。 他にご質問がございましたら、お知らせください。
環境のセットアップ
早速、実際の製品の動作を見ていきたいと思います。 したがって、次に行う必要があるのは、当社の Web サイトにアクセスしてインストールすることです。 NCache ここにあるクラウド バージョン、プロフェッショナル クラウド、Microsoft で入手可能 Azure marketplace 同様に、または通常の Enterprise Edition をダウンロードして Microsoft Azure VM にインストールします。 エンタープライズ インストールはすでに完了しています。 これでステップ XNUMX が完了しました。 ステップ XNUMX では、名前のないキャッシュを作成します。そのために、 NCache にインストールされているマネージャー ツール NCache。 したがって、必要に応じて VMS の XNUMX つからすべてを管理することも、ネットワーク上でこれらのサーバーにアクセスできる別のサーバーから完全に管理することもできます。
クラスター化キャッシュの作成
次のステップは、名前付きキャッシュを作成することです。 早速やってみます。 それはデモキャッシュと呼ばれます。
これは、このキャッシュを使用するためにすべてのクライアント アプリケーションに使用する名前です。 この名前を参照して、キャッシュからデータをフェッチすることができます。 これが最も推奨されるものであるため、パーティション化されたレプリカ キャッシュ トポロジを選択します。
次に、レプリケーション オプションとして [非同期] を選択します。これは、より高速なためです。 サーバー 1 はサーバーのプライベート IP を使用していることがわかります。そのため、サーバー間の展開の観点から仮想ネットワークを測定することをお勧めしました。 そのため、内部 IP でアクセスでき、サーバー間で非常に高速な通信が行われます。
Azure VMS では、既定でファイアウォールが開かれており、通信用の TCP ポートが開かれています。 したがって、それをオフにするか、少なくともパンチすることをお勧めします NCache ファイアウォール上の通信用のポート。 そして、サーバーごとのキャッシュのサイズは、キャッシュに含める予定のデータに基づくメモリに基づきます。 したがって、XNUMX ギガのキャッシュ サイズが必要な場合は、ここで指定した適切な量のメモリを考え出すだけです。 これは単なる上限です。キャッシュがいっぱいになった場合は XNUMX つのオプションがあります。新しい更新を拒否してデータを追加できないことを意味し、例外を受け取るか、エビクションのパーセンテージを指定するだけでエビクションをオンにすることができます。これらのアルゴリズムは、新しいアイテムのためのスペースを空けるために、これらのアルゴリズムを使用してどれだけのアイテムを削除できるかを制御できます。 したがって、キャッシュがいっぱいになり、エビクションがオンになった場合、一部のアイテムは自動的に削除され、さらにアイテムを追加できるようになります。 デフォルト設定で終了することを選択します。
これでステップ 2 が完了します。右側のペインにキャッシュが構成され、このキャッシュに関連するすべての設定が表示されます。 ステップ 3 はクライアント ノードを追加することです。デモ 3 を追加することもできますが、サーバーが 4 つしかないため、これら XNUMX つのボックスをクライアントとして追加するだけです。 ステップ XNUMX では、このキャッシュ クラスターを開始してテストします。そのためには、右クリックして選択するだけです。これにより、すべてのキャッシュ サーバーでこのキャッシュが開始されます。ちなみに、これらのクライアント ノードは実際には Web ロールまたは VM です。私のアプリケーションはデプロイされました。
したがって、すべてを同じネットワーク上に置くことをお勧めしたのはそのためです。 したがって、それらを管理できるようにするには、 NCache マネージャー。 そして、統計を右クリックすると、perf-mon カウンターが開きます。 キャッシュが開始されました。 一部の設定はグレー表示され、キャッシュの実行中は変更できませんが、圧縮をオンにし、右クリックして構成のハード適用を選択するなど、一部の設定は引き続き変更できます。 最初にプロジェクトを保存するように求められます。 したがって、これを実行してから、構成をハード適用します。 さあ、どうぞ。
これでキャッシュが構成され、クライアントが構成されました。 XNUMX つのステップが完了し、インストールが完了しました NCache.
ストレスのシミュレーションとキャッシュ統計の監視
キャッシュを作成し、クライアントを構成し、構成の観点からは完了しましたが、必要なのはこのキャッシュ クラスターを起動して実行することだけです。そのためには、付属のストレス テスト ツールを使用します。 NCache。 そしてそれをキャッシュに対して実行します。 それで、私もいくつかの活動を見ることができました。 XNUMX 番目のボックスにもログオンし、このコンソールベースのアプリケーションも実行します。 そこで、その前に XNUMX 番目のインスタンスを実行して、XNUMX 秒あたりのリクエスト数のカウンターを確認しました。 ストレス テスト ツールの XNUMX つのインスタンスによって、XNUMX 秒あたり約 XNUMX のリクエストが生成されます。
XNUMX 番目のサーバーでは、これを実行するだけです。 そのため、さらに負荷がかかり、XNUMX 秒あたりのリクエスト数のカウンターがほぼ XNUMX 倍に跳ね上がっていることがわかります。 XNUMX 秒あたり XNUMX リクエスト。
このボックスから XNUMX つのインスタンスを実行しましたが、依然として両方のサーバーを使用していました。 アプリケーションが両方のサーバーを組み合わせて使用している別のインスタンスを実行しました。その後、この監視ツールを使用して、正常性、CPU、リクエスト、サイズ、ネットワーク、およびサーバー側からのさまざまなマトリックスを取得します。クライアント側。
ここで私が行ったように、独自のダッシュボードを作成することもできます。 時間の都合上、少し急ぎましたが、これは簡単な XNUMX つのステップでした。 NCache。 キャッシュは稼働しています。
NCache サンプル
次に、実際のアプリケーションでキャッシュを使用します。そのためには、次のリンクをすぐに参照してください。 NCache サンプル。 例えば、基本的な操作をしたい場合のサンプルです。 セッション状態を使用する場合は、この ASP.NET セッション状態アプリケーションを使用できます。 このリストには、ビューステートと出力キャッシュのサンプルも含まれています。 ぜひ、これらを活用して、使用する際の参考にしてください。 NCache 実際のアプリケーションでは。
質問があります。 200 つのレベルのキャッシュを構成できます。大きい方は永続状態で 1 GB に相当し、小さい方はメモリ内で 1 GB の揮発性が高くなります。また、レベル 2 のメモリを、レベル XNUMX キャッシュから一般的に参照されるオブジェクトのメモリのサブセットと同期させることはできますか? これは可能です。 質問が XNUMX つあります。 最初の疑問は、XNUMX つの異なるメモリを使用して XNUMX つの異なるキャッシュを作成できるかどうかです。 はい。 ほとんどのクライアントは、静的データ用に XNUMX つのキャッシュを作成し、動的データ用に別のキャッシュを作成できます。 つまり、これは実行可能なことであり、これら XNUMX つのキャッシュに対してまったく異なる構成を作成することができます。
次の質問は、これら XNUMX つのキャッシュ間でデータを同期できるかどうかです。 はい。 あなたはできる。 このキャッシュ同期の依存関係があります。 この機能は非公開ですが、実装方法の詳細をいくつか共有できます。また、XNUMX つの異なるキャッシュ間で同期依存関係を持たせることもできます。 これと同じ機能は、クライアント キャッシュ (キャッシュ) がある場合はどこでも現物キャッシュを使用するものであり、他のサーバーで構成されたクラスター化キャッシュと同期されます。 あ、はい。 あなたの質問に答えると、はい、XNUMX つの異なるキャッシュを持つことができ、それら XNUMX つのキャッシュ内のデータ間で同期することもできます。
簡単にまとめます。オブジェクト キャッシュの増加には利用できるものがたくさんあります。これらは、 NCache オブジェクト キャッシュのサポートと、ASP.NET セッションのビュー ステートについてはすでに説明しました。 サードパーティとの統合もいくつかあります。 したがって、これでウェビナーは実質的に終わりです。 時間の都合上、少し説明してしまい申し訳ありませんが、繰り返しになりますが、機能不全の問題に関する基本的な詳細、ソリューションのメモリ内分散キャッシュについての説明、Microsoft Azure での展開、さまざまな使用例について説明しました。 、クラスタリングのサポート、内でのトポロジのサポート NCache。 Microsoft Azure を使い始める方法に関する具体的な実践デモがありました。 NCache 行く。
プレゼンテーションの感想を教えてください。 製品の全体的な評価はいかがでしたか? これについてご意見をお聞かせください。 終わりに向けてできることはいくつかあります。 当社の Web サイトにアクセスして、30 日間の試用版をダウンロードできます。 NCache。 クラウド エディションを選択することもできます。 NCache professional cloud、Microsoft Azure で利用できます。 私たちにもクライアントがいます。 その後、必要に応じて、Azure VM を使用して Enterprise Edition 製品を使用することもできます。 サポート ページにアクセスして、サポート チームに連絡できます。 サポートに連絡できる連絡先の詳細がいくつかあります。 support@alachisoft.com.必要に応じて製品デモをリクエストしたり、価格情報について営業チームにお問い合わせいただくこともできます。 さて、もう XNUMX 時間経過したので、そろそろお別れの時間だと思います。 このデモの後でも質問がある場合はお知らせください。 メールまたはお電話でご連絡いただけます。ご質問がございましたら、喜んでお待ちしております。 皆さん、本当にありがとうございました。 発表できて楽しかったです NCache 今日のウェビナー。 製品はどうでしたか、プレゼンテーションはどうでしたか教えてください。いつでもご連絡させていただきます。 皆様、お時間をいただきまして誠にありがとうございました。