オーランドコードキャンプ

分散キャッシングを使用した.NETアプリケーションのスケーリング

イクバル・カーン
プレジデント＆テクノロジーエバンジェリスト

.NETアプリケーションでは、トランザクションの負荷が増大するため、データベースまたはストレージのボトルネックが発生する可能性があります。 ボトルネックを取り除き、分散キャッシングを使用して.NETアプリケーションをスケーリングする方法を学びます。 この講演の内容は次のとおりです。

• .NETアプリケーションのスケーラビリティのボトルネックの概要
• 分散キャッシングの説明と、それがパフォーマンスの問題をどのように解決するか
• アプリケーションのどこで分散キャッシングを使用できますか
• 分散キャッシュのいくつかの重要な機能
• 分散キャッシュを使用した実践例

今日の話はそれについてではありません NCache、分散キャッシュについてです。 参考にさせていただきます NCache これは一例ですが、概念は全体的なものであるため、すべてのキャッシュに適用されます。

スケーラビリティとは

わかった！ まず、いくつかの定義を説明しましょう。 最初の定義はスケーラビリティです。 スケーラビリティはアプリケーションのパフォーマンスではありません。 ユーザーが XNUMX 人いて、アプリケーションのパフォーマンスが超高速である場合、ユーザーが XNUMX、XNUMX、または XNUMX 人でも同じ優れたパフォーマンスが得られるまで、アプリケーションはスケーラブルではありません。 したがって、スケーラビリティとは、ピーク負荷時の高いパフォーマンスを意味します。 パフォーマンスとスケーラビリティを混同する人がいます。 ユーザーが XNUMX 人いる場合、アプリケーションのパフォーマンスが良くない可能性があります。その場合、キャッシュは役に立たず、解決すべき別の問題が生じます。

線形スケーラビリティ

線形スケーラビリティとは、アプリケーションがサーバーを追加できるように設計されている場合、サーバーを追加することでトランザクション容量を増やすことができることです。 繰り返しになりますが、スケーラビリティは、アプリケーションが XNUMX 秒あたり何人のユーザーを処理できるかというトランザクション容量の観点から定義しています。 したがって、サーバーを追加するにつれてアプリケーションがより線形に多くのトランザクションを処理できる場合、そのアプリケーションは線形にスケーラブルになります。私たちの目標は、アプリケーションで線形のスケーラビリティを実現するための線形スケールになることです。

非線形のスケーラビリティ

そして、私たちは非線形のスケーラビリティを絶対に望んでいません。つまり、アプリケーションが、ある時点以降、サーバーを追加してもあまり問題にならず、実際にはおそらく増加するような方法でアプリケーションが設計されているということです。落とす。 つまり、どこかに解決されていないボトルネックが存在するということです。

どのアプリがスケーラビリティを必要としますか？

では、なぜスケーラビリティが必要なのでしょうか、またどのアプリケーションにスケーラビリティが必要なのでしょうか?

通常、これらはサーバー側アプリケーションであるアプリケーションです。 これらは ASP.NET 現在 ASP です.NET core、Web サービス、IoT バックエンド、ビッグ データ処理。 ビッグ データ処理は .NET 側では一般的ではなく、Java の現象に多く見られますが、.NET でも同様に実行できるはずですが、ビッグ データ処理アプリにはスケーラビリティやその他のサーバー アプリケーションも必要です。 たとえば、あなたが銀行である場合、何百万もの顧客がいて、彼らが電話して住所を変更したり、新しいカードを発行または要求したり、送金したりする場合、それらのリクエストすべてをバッチモードで処理する必要があります。夜間であり、翌営業日までに完了しなければならないコンプライアンス要件がいくつかあります。 したがって、これらのバッチ処理が増えるにつれて、他のバッチ処理アプリケーションもスケーラブルである必要があります。 したがって、これらのアプリケーションだけではありません。 多くのトランザクションを圧縮時間で処理する必要がある他のアプリケーションでは、その圧縮時間は XNUMX 秒あたりのトランザクション数であり、この場合の圧縮時間はコンプライアンス要件内に収まる可能性があります。 したがって、これらのアプリケーションのいずれかが高トラフィックまたは高トランザクションである場合は、正しい話に到達しました。

スケーラビリティの問題

では、スケーラビリティの問題はどこにあるのでしょうか? なぜ私たちはこのような会話をしているのでしょうか？ アプリケーション層が非常にうまく拡張され、ロード バランサーがあり、サーバーをどんどん追加できるのは、間違いなくアプリケーション層ではありません。 すべてがとても素敵に見えます。 問題は実際にはデータベース、つまりデータストレージにあります。 ここで私が言っているのは、リレーショナル データベースまたはメインフレームのレガシー データのことです。 また、アプリケーション層を拡張するのと同じ方法でこれらを拡張することはできません。 理由は、この中のデータが配布されていないためです。 データベースの性質上、すべてを XNUMX つにまとめる必要があります。 そして、メインフレームでも同じことが言えます。 したがって、データベースは非常に高速である可能性があります。 サーバー側でメモリ内キャッシュを実行している可能性がありますが、スケーリングされておらず、 NoSQL databases.

人々が使用する理由のXNUMXつは NoSQL XNUMX つはトランザクションのスケーラビリティに関するもので、もう XNUMX つはデータのスケーラビリティに関するものです。たとえば、何テラバイトものデータがあるとします。 NoSQL の方がはるかに適しています。 そして、人々がそれを使用する XNUMX 番目の理由は、JSON ドキュメントがスキーマの柔軟性を提供するためです。 しかし、 NoSQL databaseは必ずしも役立つわけではありません。その理由は、データをリレーショナル データベースからリレーショナル データベースに移動する必要があるためです。 NoSQL database。 技術的およびビジネス上のさまざまな理由でそれができない場合はどうすればよいでしょうか。 データの一部は、リレーショナル データベースと従来のメインフレーム データに保持する必要があります。 それでも、 NoSQL databaseは素晴らしいです、そして私たちは NoSQL database 私たちが昨年立ち上げたものを、 NosDB、前述したように、データを入力できない限り、問題は解決されません。 したがって、リレーショナル データベースを使用する必要がある場合は、リレーショナル データベースが引き起こすスケーラビリティの問題を解決する必要があり、そこでこそ分散キャッシュが役に立ちます。

分散キャッシュの展開

分散キャッシュは本質的に、メモリ内の分散ストアです。

論理的に言えば、それはちょうどアプリケーション層とデータ層の間にあります。 物理的には、別個の VM の束であることも、アプリケーションと同じボックス上に存在することも、その一部がここにあることも、一部がここにあることもあり、これらについてはこれから説明します。 ただし、論理的には、アプリケーション層とデータベース層の間にあります。 そして、基本的な議論は、データをキャッシュすると、データベースに頻繁にアクセスしなくなります。 データベースにアクセスしないため、それほど負荷がかからないため、ボトルネックにはなりません。 80% の確率でキャッシュ層に移動でき、キャッシュ層にはデータベースのように分散されているため、データベースのようなボトルネックがない場合。 NoSQL database キャッシュ層も分散しています。 それはキー/値です。 実際、分散キャッシュの別の言葉はインメモリです。 NoSQL キーバリューストアは、分散キャッシュに入れるすべてのものにキーがあり、オブジェクトである値があるためです。 したがって、これを行うと、80 パーセントの時間はここにアクセスし、20 パーセントの時間はデータベースにアクセスすることになります。 その 20% はほとんどがアップデートです。

もちろん一部の読み取りはありますが、読み取りトランザクションとの競合がなく、これがボトルネックではなくなったため、それらの更新も高速に実行されます。 なぜ？ 分散キャッシュは 16 つ以上のサーバーのクラスターを形成するためです。 これらは高価なボックスではなく、データベース サーバー タイプのボックスでもありません。 これらは、大量のメモリを搭載した 32 コアまたは 32 コアのボックスと同様の典型的な Web サーバー構成です。 ロットとは、64 ～ 16 ギガがお客様に推奨される値であることを意味します。 当社の顧客の中には 32 を超える人もいますが、8 を超えることをお勧めすることはほとんどありません。ここでさらに多くのボックスを追加するよりも、別のボックスを追加することをお勧めします。 メモリを追加する場合は、処理能力をアップグレードする必要があるためです。 なぜ？ .NET アプリケーションにはガベージ コレクションと呼ばれる機能があり、収集しなければならないメモリが増えれば増えるほど、ガベージ コレクターまたは GC が動作する必要があり、その場合 CPU がボトルネックになり、アプリケーションに問題が発生し始めます。 したがって、スイート スポットは、これらの VM または物理ボックス内の XNUMX ～ XNUMX GB のメモリであり、ほとんどのお客様がここで VM を使用しています。 また、ハードウェア構成としては約 XNUMX コアで、通常は XNUMX 枚のネットワーク カードがあり、XNUMX 枚のネットワーク カードはクラスタリング用で、もう XNUMX 枚はクライアントが通信するためのものです。 クライアントという言葉はアプリケーション サーバーを意味するため、クライアントではありません。 キャッシュ クライアントとなるのはアプリケーション サーバーです。

したがって、少なくとも 40 つのキャッシュ サーバーが必要で、アプリケーション層とキャッシュ層の比率は 50 対 XNUMX または XNUMX 対 XNUMX になります。 そして、その比率は、私たちが長年にわたって見てきたこと、そして XNUMX 年以上この分野に携わってきたことに最も基づいており、より多くのアクティビティを追加するためにここにサーバーを追加する場合は、XNUMX 対 XNUMX または XNUMX 対 XNUMX を上回るということになります。 XNUMX 対 XNUMX の比率では、非常に優れた容量が得られます。 そしてもちろん、XNUMX つの理由のいずれかでサーバーを追加します。 先ほど説明したようにメモリが必要なため、より多くのストレージが必要になるか、最初は XNUMX つのサーバーがあり、破棄が最大になるまでここにボックスを追加し続けたため、より多くのトランザクション容量が必要になります。 リレーショナル データベースでそのようなことが起こると、行き詰まってしまいます。 あなたは興奮しています。 この場合、XNUMX 番目のボックスの容量が最大になるまで XNUMX 番目のボックスを追加し、その後 XNUMX 番目のボックスを追加するだけです。 したがって、ここには好きなだけボックスを置くことができます。 当社の顧客の中には、平均して約 XNUMX ～ XNUMX 個のボックスをここに保有しており、一部の顧客はアプリケーション層に XNUMX ～ XNUMX 個のボックスを保有しており、それに応じて保有しています。 したがって、XNUMX 台のボックスまたは XNUMX 台のサーバー アプリケーション層の場合、キャッシュ層には約 XNUMX 台のサーバーが存在することになります。 それで、それがあなたの計画を立てる方法です。

したがって、これまでの説明の目的は、キャッシュ層を設けることでスケーラビリティのボトルネックがなくなることを理解していただくことです。 したがって、どの製品を使用する場合でも、どのキャッシュ ソリューションを使用する場合でも、アプリケーションにキャッシュ層を組み込む必要があります。 したがって、ピクチャ内にキャッシュを含めるようにアプリケーションを設計する必要があります。そうすれば、ボトルネックが発生しなくなります。

分散キャッシュの使用例

さて、.NET 開発者はキャッシュを使用すべきであると確信しましたが、次に頭に浮かぶのは、キャッシュをどこで使用するべきかということです。 どのように使用すればよいですか?

そして、最初のユースケースは、これまで話してきたアプリケーション データのキャッシュです。これは、データベースにアプリケーション データがあり、それをここにキャッシュするので、データベースに行く必要がなくなります。これと同じことです。 。

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

この使用例で留意すべき点は、データが 10 つの場所に存在することです。15 つはデータベースであるマスター、もう XNUMX つはそうではないキャッシュです。 では、データが XNUMX つの場所に存在する場合、何が問題になるのでしょうか? コピーが XNUMX つある場合、最大の懸念は、キャッシュが新しいかどうか、キャッシュにデータベースと同じバージョンのデータが含まれるかどうかです。キャッシュに同じバージョンのデータが含まれない場合は、読み取り専用データを強制的にキャッシュします。 また、読み取り専用データはデータ全体の約 XNUMX ～ XNUMX% です。 つまり、あまり恩恵を受けていないのです。 メリットは得られていますが、アプリケーションを実際にスケーラブルにする必要があるほどのメリットは得られていません。

したがって、実際のところ、一般の人にキャッシュとは何のために使われるのかと尋ねるほどです。 彼らは、読み取り専用データをそこに入れるだけでいいと言うでしょう。 誰もがトランザクション データをキャッシュすることを恐れています。 30 秒ごと、XNUMX 分ごと、XNUMX 分ごと、または予測できない方法で変化する顧客、アカウント、アクティビティのデータ。 そのため、人々はそのコピーが XNUMX つ存在するため、キャッシュすることを恐れています。また、データベース内で変更したことがキャッシュに認識されなかったらどうなるのでしょう。 したがって、さらに続けるときは、そのことを念頭に置いておきましょう。

ASP.NET固有のキャッシュ

XNUMX 番目の使用例は、ASP.NET アプリケーションがある場合で、最も一般的に知られているのは セッション状態。 これは、この例のすべてであり、最初の例はセッション状態です。 セッションには、デフォルトで XNUMX つのストレージ オプションがあります。 XNUMX つは Microsoft が提供する InProc で、もう XNUMX つは SQL です。 オンプレミスには状態サーバーもありますが、XNUMX つのオプションすべてにスケーラビリティの問題があります。 SQL サーバーにはパフォーマンスの問題があります。 そもそもキャッシュが存在しないのと同じ理由です。 セッションを SQL に保存すると、セッションは BLOB として保存されます。 すべてのリレーショナル データベースが BLOB ストレージ用に設計されたのではなく、構造化データ用に設計されているのと同様、リレーションは SQL です。 したがって、実行されません。 問題はたくさんあります。 ご来店されるほとんどのお客様は、 NCache、最初の使用例はセッション状態です。 それは彼らに直接的な利益をもたらすからです。 そして、セッション状態の本当に優れた点は、Microsoft が提供するフレームワークがあるため、プログラミングが必要ないことです。これにより、次のようなサードパーティ キャッシュが可能になります。 NCache プラグインすると、ここにあるものすべてがキャッシュに保存されます。

ASP.NET のもう XNUMX つの側面は、MVC フレームワークを持っていない場合、または多くの ASP.NET アプリケーションがまだ使用している MVC 以前のフレームワークを使用している場合、ビュー ステートと呼ばれるものがあります。 また、ビュー ステートが何なのか知らない人のために説明すると、ビュー ステートは Web サーバーからブラウザに送信され、ポストバック時にのみ戻される暗号化された文字列です。 したがって、往復するだけで数百キロバイトの暗号化強度が得られる可能性があります。 そして、これにアプリケーションが処理する数百万のトランザクションを掛けると、少なくともかなりの帯域幅になります。 そして、帯域幅は無料ではなく、かなり高価です。

そして XNUMX 番目はもちろんですが、パフォーマンスに非常に重いペイロードを送信する必要がある場合、応答時間が遅くなります。 したがって、サーバー側でビューステートをキャッシュするだけで小さなキーを送信できれば、ポストバックが発生したときにキーが戻ってきて、ビューステートがキャッシュからフェッチされて表示されるようになれば、さらに良いでしょう。ページへ。 これが XNUMX 番目の使用例です。 繰り返しますが、同様に、プログラミングは必要ありません。次のようなサードパーティのキャッシュを接続するだけです。 NCache.

XNUMX番目のユースケースは ASP.NET出力キャッシュ。 このキャッシュはページ出力です。 ページ出力が変更されない場合、Microsoft はそれをローカルのスタンドアロン InProc にキャッシュするフレームワークをすでに備えています。 Web ファームで初めてページ出力がキャッシュされたときに、各 Web サーバーが独自のコピーをキャッシュするのではなく、Web ファーム全体でその出力を利用できるように、その代わりに XNUMX 番目の分散キャッシュを配置することをお勧めします。

以上が、アプリケーション データ キャッシュに加えて、ASP.NET アプリケーションの XNUMX つのユース ケースです。

さて、ここでの問題の性質はまったく異なります。 この例では、データのコピーが XNUMX つありました。 ここで、キャッシュはマスター ストアです。 したがって、セッションをデータベースに保存する必要はなくなります。 ビューステートを他の場所に保存する必要はなくなりました。 したがって、キャッシュはマスター ストアであり、メモリ内ストアです。 では、インメモリ ストアがマスター ストアである場合、何が問題になるのでしょうか? 記憶は揮発性だ！ うん。 したがって、持続力はありません。 したがって、優れた分散キャッシュでは、セッションが失われないように、データの信頼性を提供するために複数のサーバー間でデータを複製する必要があります。 なぜなら、あなたは航空会社で、ハワイ向けの特別な週末プロモーションを行ったので、Web サイトへのトラフィックが XNUMX ～ XNUMX 倍になり、彼らはあらゆる種類の検索を行った人々であり、これから送信ボタンを押すとセッションが失われます。 顧客ごとに数千ドルの売上があり、その顧客を失う可能性があります。 したがって、セッションを失うことは絶対に避けるべきです。 したがって、レプリケーションを行わない限り、セッションをキャッシュに入れないでください。

ランタイムデータ共有

XNUMX 番目の使用例は、実行時のデータ共有です。 これは多くの人が長い間知らなかったことです。 ユーザーは、複数のアプリケーション間でイベントを共有するためにメッセージ キューを使用します。 しかし、分散キャッシュは非常にシンプルで強力なデータ中心のイベント メカニズムを提供します。これをサービス バスやメッセージ バスのようなものと考えると、これを介して相互に通信できるアプリケーションになります。 したがって、それぞれに利点がある MSMQ または RabbitMQ を使用する代わりに、キャッシュはそれらに代わるものではありません。 ただし、ニーズがデータに関連している場合、またはメッセージングのニーズがデータに関連しており、同じデータ センター内にある場合、分散キャッシュはよりシンプルなインターフェイスを提供しますが、さらに重要なのは、よりスケーラブルであるということです。 したがって、より高度なトランザクション アプリケーションを使用している場合、この話全体はスケーラビリティに関するものになります。

したがって、この通常のメッセージ キューを使用してこれらすべてを行うこともできます。 非常に高トランザクションの環境になると、分散キャッシュと同じ方法では分散されません。 したがって、分散キャッシュを使用すると、これらすべてを行うことができます。 Pub/Sub タイプのデータ共有があるとします。イベント通知があり、継続的なクエリ機能があります。 NCache Java キャッシュにもあるものです。 Redis そうではないため、非常にシームレスな方法でアプリケーション間でデータを共有することができます。 また、ここでも問題は ASP.NET 固有のキャッシュ アプリケーションに似ています。これは、このデータはおそらくデータベース内に存在しますが、共有する形式では存在しないためです。

したがって、共有しようとする前に、変換されたフォームがキャッシュに保持されるように、フォームの一部に変換している可能性があります。 したがって、そのデータを失いたくないので、キャッシュでデータを複製する必要があります。 実際には、アプリケーション データのキャッシュでも、16 つのキャッシュ サーバーがダウンしてレプリケーションが行われなかったために一部のデータが失われた場合でも、技術的には可能です。 技術的には、そのデータをデータベースから再ロードできます。 パフォーマンスが低下することを除けば問題はありません。なぜなら、何と言っても、失われたデータが 16 ギガバイトだった場合、やりたくない XNUMX ギガのデータベース ヒットを経験しなければならないからです。 そのため、ほとんどのお客様は、メモリが非常に安価であるため、アプリケーション データ キャッシュであってもレプリケーションを選択します。 彼らはパフォーマンスへの影響さえ受けたくありません。 もちろん、この XNUMX つの場合はそれを持っていなければなりませんが、この XNUMX つはある種、あると良いものです。

実践的なデモ

さて、これを行う方法について先に進む前に、まずキャッシュがどのようなものかを示したいと思います。 使うつもりです NCache ここの例として。

環境のセットアップ

つまり、Azure には、demo1、demo2、demo-client という 1 つの VM があります。 Demon2 と XNUMX はキャッシュ サーバー VM になり、demo-client はアプリケーション サーバー VM になります。 あなたの場合、キャッシュ VM が XNUMX つあり、クライアント VM の比率が XNUMX 対 XNUMX、XNUMX 対 XNUMX、または XNUMX 対 XNUMX であるとします。

そこで、デモクライアントにログインし、このツールを使用します。 NCache 呼ばれています NCache マネジャー。 ということで、ここから始めさせていただきました。 ここに来て、新しいクラスター化キャッシュを作成すると言います。

クラスター化キャッシュの作成

すべてのキャッシュ NCache という名前が付けられているので、democache という名前にします。それぞれの意味については詳しく説明しません。これについては後ほど説明しますが、 パーティション化されたレプリカ トポロジ。 の場合 NCache、トポロジとは、データがどのように保存および複製されるかを意味します。 パーティション レプリカ トポロジは、もしここに戻ってきたら、これから作成する XNUMX ノードのキャッシュ クラスターとして考えてください。

パーティション化されたレプリカの場合、すべてのサーバーに XNUMX つのパーティションが存在します。 したがって、合計 XNUMX つのパーティションが存在します。 の場合には NCache、キャッシュ全体には約 XNUMX 個のバケットがあるため、そのうちの約半分がパーティション XNUMX に割り当てられ、残りの半分がパーティション XNUMX に割り当てられます。

各パーティションは、レプリカと呼ばれる別のサーバーにバックアップされます。 の場合のレプリカ NCache これは、クライアントがレプリカと通信せず、パーティションのみがレプリカと通信することを意味します。 また、レプリカは、プライマリ パーティションまたはパーティションがダウンした場合にのみアクティブになります。

つまり、このサーバーが停止した場合、たとえば 1 ノードのクラスターとパーティションがあり、サーバー 2 が停止したとすると、パーティション XNUMX は現在停止しています。 したがって、レプリカ XNUMX は自動的にパーティション XNUMX になり、データが失われることはありません。 したがって、パーティション化されたレプリカは、このストレージとレプリケーションの戦略を提供します。 これは基本的に、データを複製する必要があることを示しています。 同期レプリケーションと非同期レプリケーションもあります。 とにかく、この話に戻りますが、それが何を意味するのかだけを説明したいと思います。 そこで、パーティションとレプリカ間の非同期レプリケーションを選択します。 次に、キャッシュ サーバーを指定します。つまり、最初のサーバーは [demoXNUMX]、XNUMX 番目のサーバーは [demoXNUMX] です。 さて、私が言っていることはすべて、 NCache完全にスクリプト化できるので、自動化できます。 すべてデフォルトのままにします。 これは、キャッシュ クラスターが形成された TCP ポートです。 このサーバー上でキャッシュが使用するメモリ量を指定します。キャッシュはこのメモリを超えるメモリを使用しません。 つまり、ここで指定するものはすべて XNUMX 倍であるためです。 パーティションとレプリカがあります。

したがって、これはパーティションのサイズです。 したがって、あなたの場合、キャッシュサーバーに16ギガがある場合、オペレーティングシステムとその他のプロセスに約2〜2.5ギガを残し、残りを割り当てる必要があるため、もちろんこれよりもはるかに多くなります。 つまり、16 ギガから 13 ギガ半が残っているとします。ただし、13 ギガ半を 2 で割ったものがパーティション サイズになります。 NCache このメモリを超えて使用しないようにします。 したがって、これだけ多くのメモリが消費されると、次のような場合にキャッシュがいっぱいであると見なされます。 NCache。 その後 NCache には XNUMX つのオプションのいずれかがあります。 一つ、言えることは NCache データの一部が自動的に期限切れになるか、これがエビクションと呼ばれるものを実行できるようになるまで、データの新たな追加は拒否されます。 それで、 NCache 5 つのエビクション アルゴリズム LRU、LFU、および優先 FIFO が提供されます。 したがって、この場合、キャッシュの XNUMX% を削除すると言えます。

ここで、これについて、次の文脈で少し話したいと思います。たとえば、それぞれのファイルに保存しているとします。 使用事例 ここ。 アプリケーション データのキャッシュを実行している場合、エビクションはまったく問題ありません。 何も問題ない。 最近使用されていないメモリの一部を削除して、新しいデータ用のスペースを確保したメモリを使い果たしただけです。 そうすると、動く窓みたいになるんですよね？ したがって、使用するデータが増えると、古いデータが削除され、新しいデータが削除されます。 したがって、それが最も一般的に使用されます。 しかし、それがセッションだったらどうでしょうか？ セッションを保存するためにキャッシュが使用されている場合、エビクションは望ましくありません。 なぜ立ち退かせたくないのですか？ セッションがまだアクティブである可能性があるためです。 20 分が経過していないか、タイムアウトが何であれ、それが経過していない可能性があります。 その場合でもセッションをエビクトすると、ユーザーがログアウトしていないのにキックしているという、先ほど説明したのと同じ問題が強制的に発生することになります。 したがって、行う必要があるのは、キャパシティ プランニングを行うことです。 の場合には NCacheこれは非常に簡単に行うことができ、平均的なセッションが消費するメモリ量を確認して、容量計画を行うことができます。 使用されるメモリの量を推定します。 この他のセッション ストレージが決して削除されないように容量を確保してください。 アプリケーション データ ストレージまたはアプリケーション データ キャッシュは削除できますが、問題ありません。 ただし、セッション キャッシュは削除しないでください。 ユーザーがセッションを使用しなくなった場合にのみ有効期限が切れます。

それで、「終了」とだけ言うつもりです。これで XNUMX ノードのキャッシュ クラスターが完成しました。 ここに来て、クライアント ノードを追加します。 私の場合、前述したようにクライアント ノードは XNUMX つだけです。 おそらくキャッシュがないと思うので、始めました。 そのサービスが必要なので、 NCache マネージャーはこれに話しかけて設定を行うことができます。 わかった！ これが完了したので、ここに来てキャッシュを開始するつもりです。 そこで、キャッシュを開始することで、 NCache これら XNUMX つのボックスの間に、その TCP に対するクラスターを構築しています。

ストレスのシミュレーションとキャッシュ統計の監視

そのため、実際には、どのボックスにどのようなデータが含まれているか、クラスターが存在するかどうかの詳細には立ち入りません。 デモキャッシュがあることを知っているだけです。 パーティション化されたレプリカの場合、そのキャッシュに接続するたびに、アプリケーションはすべてのサーバーに自動的に接続します。 それで、 NCache すべての詳細を処理してくれるので、ここに来て統計を表示するつもりです。これらは、何を確認できるように、いくつかの PerfMon カウンターです。 NCache 使い始めてからでも構いません。 このツールも起動します NCache モニター。 そして、それはダッシュボードスタイルのツールのようなものです。 そして、次の場合には、 NCacheでは、ストレス テスト ツールを使用するオプションがあり、プログラミングを行わずにアプリケーションの使用状況を非常に迅速にシミュレートできます。

たとえば、ストレス テスト ツールのデモキャッシュと言って、700 つの取得と 7 つのプットなどを実行します。 そして突然、このツールが両方のキャッシュ サーバーと通信し、各ボックスで 800 秒あたり約 XNUMX 件、最大で XNUMX ～ XNUMX 件のリクエストを実行していることがわかります。 負荷を増やしたいとします。 そこで、ストレス テスト ツールをもう XNUMX つ起動したいと思います。

これはアプリケーションで行うのと同じです。 つまり、アプリケーションをテストしたいときは、ストレス テスト ツールを使用してアプリケーションを実行し、さらにストレスを加え続けて、システム全体が機能するかどうかを確認します。 したがって、現在はそのキャッシュ コンポーネントをテストしているだけです。 ほとんどのお客様が評価するときに行うこと NCache、彼らはこのベンチマークを行います。 そのため、環境内のすべての設定が完了すると、たとえ私たちがベンチマークを公開したとしても、ベンチマークは公開されません。 つまり、彼らはすべてを独自の環境で検証しているということです。 したがって、これをさらに追加すると、負荷が XNUMX 倍になっていることがわかります。

ストレス テスト ツールをもう 50 つ紹介します。 上昇し続けていることがわかります。 すぐそこです、見てください！ したがって、クライアントの CPU を最大限に活用できるようになるまで、ストレス テスト ツールをどんどん追加し続けることができます。 つまり、アプリケーションサーバーの使用率は約 5,000% になりました。 したがって、ストレス テスト ツールをさらに追加できることは間違いありません。 そのクライアントを最大にしたら、さらに XNUMX つのクライアントを追加します。 それで、それが私にできる方法です。 たとえば現在でも、わずか XNUMX つのストレス テスト ツールで XNUMX 秒あたり約 XNUMX 件のリクエストを実行しています。 したがって、これを使用すると、たとえばここでこれらすべてを監視することもできます。 したがって、これを使用すると、実際にキャッシュがどのように見えるかを確認できます。 ここで、開発者の観点からさらに詳しく見ていきましょう。

ASP.NET固有のキャッシュ

キャッシュがどのようなものかを理解したところで、アプリケーション内でそのキャッシュを使用する方法を見てみましょう。 したがって、ASP.NET の場合、前述したように、最初に行うべきことはセッションにキャッシュを使用することです。 なぜ？ それが一番簡単だからです。 プログラミングも努力も必要ありません。 興味を持ってキャッシュを設定する速度を示しました。 NCacheここに来てサンプルコードの一部に入るとしましょう。すでに開かれているはずですが、開いていません。 そこで、使用できる ASP.NET アプリケーションを紹介します。 NCache セッションには ASP.NET を使用します。 web.config を変更するだけです。 これで、web.config が手に入りました。 最初に行う必要があるのは、アセンブリ時にこのアセンブリ ラインを追加することです。 NCache、このセッション ストア プロバイダーは NCache ASP.NET セッション ストア プロバイダー インターフェイスを実装したアセンブリ。 それで、これが許可するものです NCache したがって、ここの行をコピーするだけで、ここにあるセッション状態タグに到達するだけです。 の場合には NCache、そのタグをコピーするだけです。 このモードがカスタムであることを確認してください。これにより、サードパーティのキャッシュをプラグインできるようになります。タイムアウトは希望する値であり、次の場合に必要なのは唯一のものです。 NCache キャッシュ名が指定されていることを確認することです。

したがって、インストールしたら、 NCache 次に、キャッシュ サーバーにサーバー部分をインストールし、アプリケーション サーバーにクライアント部分をインストールします。 NCache、先ほどと同じようにキャッシュを作成し、これを更新するだけで完了です。 使い始めるのに必要な作業はこれだけです NCache そして、すべてのセッションはキャッシュ内の XNUMX つのオブジェクトになります。 PerfMon カウンターでこれを行うと、表示されているセッションの数が表示されます。 通常、お客様は XNUMX つのキャッシュを作成します。 つまり、ここではキャッシュを XNUMX つ作成しただけですよね? したがって、お客様は XNUMX つのキャッシュを作成します。 キャッシュの XNUMX つはセッション用です。 したがって、セッション用に別のキャッシュがあります。 XNUMX つのキャッシュと XNUMX つのキャッシュはアプリケーション データ用です。 XNUMX つは参照データと呼ばれるものです。 もう XNUMX つはトランザクション データです。 トランザクション データは非常に頻繁に変更されるものです。 そして、彼らがそうする理由は、これから説明する他のいくつかの機能のためです。 ただし、同じ VM 上に複数のキャッシュを作成できます。 セッション状態ストレージに関して行う必要があるのはこれだけです。非常に簡単で、プログラミングは必要ありません。これで準備完了です。

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

ただし、アプリケーション データのキャッシュを実行したい場合、残念ながら .NET 空間では、EF コアがサードパーティのキャッシュをプラグインできるアーキテクチャをついに提供するようになりました。

NCache もサポートしています。 ただし、EF6 を含む EF6 が登場するまで、アーキテクチャはサードパーティ キャッシュのプラグインを実際にはサポートしていませんでした。 Hibernate は長い間、そのアーキテクチャをサポートしていました。 つまり、NHibernate の場合 NCache プログラミングなしでプラグインできます。 そのため、最小限の機能を備えたアプリケーション データ キャッシュでも、API 呼び出しを行わずに実行できます。 ただし、ほとんどの場合、アプリケーション データのキャッシュのために精神的に準備しておく必要があり、プログラミングを行う必要があります。 しかし、これは非常に単純な API です。 この API は、ASP.NET キャッシュ オブジェクトに非常によく似ています。 キャッシュ名を使用してキャッシュに接続します。

これがどのようなものかを簡単にお見せしましょう。 早速ですが、Azure VM の問題がいくつか発生しました。 私はこれ以外のことをすべて開いた状態で開始します。 それで、この本当に基本的なコンソール アプリケーションを持っているとしましょう。 最初に行う必要があるのは、次の XNUMX つをリンクすることです。 NCache アセンブリ、XNUMX つは NCache.Runtime、もう XNUMX つは NCache。ウェブ。 NCache.Web は、呼び出す実際の API です。 次に、これら XNUMX つをリンクするか、これら XNUMX つの名前空間を再度使用します。 NCache.Runtime、次に .Web.Caching。 アプリケーションの開始時に、名前に基づいてキャッシュに接続し、データベースの場合と同様にキャッシュ ハンドルを取得します。 もちろん、ASP.NET アプリケーションでは、アプリケーションの開始または InIt メソッドの global.ASAX でこれを行うことになるでしょう。 次に、オブジェクトを作成し、Cache.Add を実行します。 Cache.Add はキー、ある種の文字列を使用します。 これは適切なキーではありません。キーはより具体的である必要があります。そして、これがオブジェクトであり、それだけです。 あなたが電話をかけると、舞台裏でこれが進行します。 たとえば、パーティション化されたレプリカ トポロジがある場合、アプリケーションが接続されたとします。 したがって、すべてのボックスがすべてのキャッシュ サーバーに接続されます。 つまり、Cache.Add を実行しただけですよね? そこで、Cache.Add はバケット マップのような分布マップを調べます。 すべてのバケットには、どのキーをこのバケットに入れることができるかという観点から、ハッシュ キーの値の範囲という観点からキー値の範囲があります。 つまり、すべてのサーバーに接続されているため、バケット マップを使用して、どのサーバーにアクセスして通信すべきかを知ることになるのですね。

そして、ここに項目番号 XNUMX を追加するとします。 ここで項目 XNUMX を追加します。非同期レプリケーションを有効にしていた場合、アプリケーションは元に戻り、アプリケーションは完了します。 キャッシュは、このパーティションがこれをここで複製する必要があることを認識します。 したがって、一括操作で非同期にこれを他のボックスに複製すると、すぐにそのアイテムが XNUMX か所に存在することになります。 つまり、これが Cache.Add が内部で実行していたことです。

さて、話が前後しますが、概要を説明したかっただけですが、キャッシュとはどのようなものなのか、作成方法、API とはどのようなものなのかを説明したいと思います。

アプリのデータキャッシュ機能

次に、アプリケーション データ キャッシュにキャッシュを使用する際に解決しなければならない問題について説明します。

キャッシュを最新に保つ

キャッシュを最新の状態に保つことについて話しましたよね? では、キャッシュを最新の状態に保つにはどうすればよいでしょうか? キャッシュが新しいことをどのように確認しますか?

時間ベースの有効期限の使用

最も一般的で誰もがサポートするもの Redis 有効期限です。 絶対的な有効期限。 したがって、キャッシュに何かを追加するときに、ここでも有効期限を指定するとします。つまり、XNUMX 分後に期限切れになるとします。 こういう場合にこう言うと、 NCache, NCache サーバー上にインデックスが作成され、そのデータが監視され、XNUMX 分後に期限切れになります。 つまり、実際には、今から XNUMX 分後の絶対日時値を指定することになります。 NCache その日の時刻の値にその項目を期限切れにする必要があることを知っています。 このようにして、キャッシュはデータが確実に削除されるように自動的に処理します。 そして、それは実際には何を意味するのでしょうか？ つまり、誰かがデータベース内のデータを変更する可能性があるため、このデータを 20 分以上、または XNUMX 分以上保持しておくのは非常に不安であるとキャッシュに伝えていることになります。 したがって、その期間キャッシュ内に保持しておくことが安全です。 スライド式有効期限と呼ばれるもう XNUMX つの有効期限があります。これは同じように聞こえますが、その目的はまったく異なります。 スライド有効期限は主にクリーンアップに使用されます。 したがって、セッションがある場合は、スライド式有効期限を使用して、このセッションを誰も使用しなくなった後にクリーンアップします。 したがって、非アクティブ状態が XNUMX 分間続いた後に誰かがログアウトすると、セッションは期限切れになったと見なされます。 したがって、自動的に削除されます。

データベースの依存関係の使用

ただし、それはキャッシュを最新の状態に保つこととは何の関係もありません。 絶対有効期限はキャッシュを最新の状態に保つものです。 しかし、絶対有効期限には大きな問題があります。 そして、問題は、そのデータをキャッシュに長期間保存しておいても安全であると推測していることですが、その推測が必ずしも正確であるとは限りません。 それで、その場合はどうしますか？ その場合、キャッシュ自体を同期する機能が必要になります。 データベース内の変更に気付いた場合、キャッシュはデータベースが何であるかを認識する必要があることを意味します。 つまり、キャッシュには、キャッシュされた項目とデータベース内のデータとの間に関係があり、それをキャッシュに伝える必要があります。ADO.NET には SQL キャッシュの依存関係と呼ばれるものがあります。 NCache これは SQL 依存関係であり、Oracle 依存関係とも呼ばれ、実際には非常に単純な方法で機能します。 しかし、これは本当に強力な機能です。 そして、私たちはここに来ました。 SQL 依存関係のみを使用します。 つまり、キャッシュに何かを追加するときは、同じ Cache.Add を実行しますよね。 キャッシュキーを持っています。 ここで、値の代わりにキャッシュ項目を指定します。 NCache独自のデータ構造があり、そこには値が含まれていますが、SQL キャッシュ依存関係と呼ばれるものも含まれています。

この SQL キャッシュの依存関係は、 NCache独自のクラスですが、ADO.NET SQL キャッシュの依存関係にマップされます。 ここには接続文字列があり、その後に SQL ステートメントがあることに注意してください。 したがって、この場合の SQL ステートメントは、product テーブル内の XNUMX つの行にマッピングされます。 それで、ここで実際に何が起こっているのでしょうか？ つまり、実際にこのコードをここで実行しているということです。 データベースはここにあるので、先ほど渡した接続文字列に基づいてデータベースに接続するようにキャッシュ クラスターに要求し、その接続文字列に基づいて SQL サーバーを渡して、「お願いします」と言っています。 SQLサーバーデータベースに接続します。 また、SQL サーバーを監視して、このデータ セットに変更が発生した場合に、キャッシュ サーバーであるユーザーに通知します。 これは、この行が更新されたか削除されたかを意味します。 その場合、SQL サーバーはクライアント (この場合はキャッシュ サーバー) にデータベース通知を送信します。 そのうちの XNUMX つ。 では、キャッシュ サーバーは何をするのでしょうか? キャッシュ サーバーはそのアイテムをキャッシュから削除します。 削除するということは、キャッシュ内にそのファイルが存在しないため、アプリケーションは最新のコピーが存在するデータベースからそれを取得することを強制されることを意味します。 したがって、有効期限は経験に基づいた推測ですが、これは推測ではありません。 これは実際の予測可能な同期であり、キャッシュがデータベースと常に一致していることが確認されます。

さて、次の場合は、 NCache、これを行うには XNUMX つの異なる方法があります。 XNUMX つは、リアルタイムのようなデータベース イベントを使用する SQL 依存関係です。 もう一つは、 NCacheポーリングを使用する独自の DB 依存関係。これはイベント通知メカニズムを持たないデータベースや SQL サーバーに対しても当てはまります。SQL 依存関係が多すぎると思われる場合は、SQL 依存関係ごとに SQL キャッシュ依存関係が作成されます。追加のデータ構造である SQL サーバー。 これらを何十万も作成した場合、SQL サーバーが停止することを考えてください。 したがって、多くの SQL 依存関係がある場合に、そのような方法で同期するのは得策ではないかもしれません。 そうすれば、監視するポーリング テーブルがあるため、XNUMX 回の呼び出しで数千行を同期できる DB 依存関係がはるかに優れている可能性があります。

そして XNUMX 番目の方法は、実際に CLR ストアド プロシージャを作成し、トリガーによって呼び出されるようにすることです。 したがって、更新、挿入、更新、削除のトリガーがある場合は、この CLR プロシージャを呼び出します。 そして、CLR プロシージャはその行からデータを取得し、アプリケーションが使用している .NET オブジェクトを構築し、それをキャッシュに保存します。 ここで、データベース トランザクション内でキャッシュが更新されるのを待つ必要がないため、非同期 API が非常に役立ちます。 これはデータベース トランザクションの速度を低下させるだけであり、タイムアウトが非常に早くなる傾向があります。 したがって、このメカニズムを実装する場合は、非同期メソッドを使用してデータを更新することをお勧めします。

以上が、キャッシュを同期できる XNUMX つの方法です。 この機能は非常に重要です。これにより、キャッシュを常に最新の状態に保つことができるため、これがないと推測することになります。 また、同じ方法で、キャッシュを非リレーショナル データベースと同期できます。 カスタム依存関係機能があります。 NCache あなたのコードはどれですか NCache を呼び出すと、カスタム データ ストアにアクセスして監視できるようになります。 カスタム データ ソースはクラウド ストレージである可能性があります。 それは何でも構いませんが、行って確認できるコードであれば何でも構いません。 したがって、キャッシュを最新の状態に保つことが非常に重要であり、これらはそれを保証する方法です。

リードスルーとライトスルー

そこで、次の機能はリードスルーとライトスルーです。

リードスルーは基本的に、これもコードです。 さて、私が話しているこれらすべての機能は、 NCache 持っていますが、そうではありません NCache それだけ。 Java キャッシュにはすべてそれらがあります。 Redis 持っているかもしれないし、持っていないかもしれない。 したがって、詳細を実行したい場合、何があるかどうかを知りたい場合は、これを実行する必要があります。 Redis あるかどうか、の場合 NCache ここに来て比較に行くだけで、 Redis 対 NCache 機能の比較。 これは、ドキュメントとキャッシュのドキュメントに基づいています。 したがって、実際にこれをダウンロードして、これらの機能をすべて実行することができます。 したがって、リードスルーは基本的にキャッシュ サーバー上にあるコードです。 ということで、こんな感じです。 つまり、実装するということです。 それで、そのインターフェースを見せて、リードスルーインターフェースが次のように見えるようにしましょう… それで、これがリードスルーインターフェースですよね？ ハンドカーソルイン NCache データ ソースに接続する InIt があり、破棄し、load メソッドがあります。 したがって、load によってキーが与えられ、取得したデータに基づいてオブジェクトが返されます。 そして、いつ有効期限が切れるかなどを指定できます。 write -t​​hrough でも同じことが言えます。InIt とdispose があり、その後、ソースへの書き込みが行われます。 したがって、書き込みは追加、更新、または削除のいずれかになります。 リードスルー、ライトスルーはどこで使用されますか?また、それらがそれほど重要であるのはなぜですか?

まず第一に、リードスルーの仕組みにより、Cache.Get が可能になりますが、キャッシュにはデータがありません。 キャッシュはリードスルーを呼び出してデータベースから取得します。 それは XNUMX つの利点です。 XNUMX 番目の利点は、リードスルーと有効期限およびデータベース同期を組み合わせられることです。 したがって、キャッシュからそれを削除する代わりに、それを再ロードします。 ライトスルーは、ライトビハインドがあることを除いて同じように機能します。ライトビハインドは、キャッシュがデータベースを更新するという点でキャッシュのみを更新することを意味します。 したがって、更新も超高速になります。 したがって、データベースのパフォーマンスがボトルネックになった場合は、キャッシュを使用して救済することができます。 リードスルーとライトスルーを実装したら、すべての永続化コードまたはその大部分をキャッシュ層に統合でき、先ほど説明した両方の機能の恩恵を受けることができます。

データのグループ化とデータの検索

したがって、キャッシュを最新の状態に保ち、リードスルー ライトスルーも実行すると、大量のデータがキャッシュされ始めることになります。 したがって、キャッシュは単なるキー値ストアではなくなりました。 つまり、すべてをキーとして取得するのは不便です。

検索できなければなりません。 SQL 検索を実行できる必要があります。 したがって、データベースでやり慣れていることを実行できなければなりません。

キャッシュで SQL 検索を実行できない場合、キャッシュは非常に制限的になります。これは分散キャッシュであるためキャッシュ内で結合を行うことができないためです。他にもグループ化、サブグループ化、データをグループ化できるタグなどの機能があります。 XNUMX 回の呼び出しですべてを取得します。

繰り返しになりますが、大量のデータをキャッシュする場合は、キャッシュ内のデータを簡単に見つけられるようにすることが非常に重要です。 したがって、これらの機能は非常に重要です。

分散キャッシュ機能

いくつかの機能について簡単に説明します。私が本当に触れておきたかった XNUMX つの機能は、ニア キャッシュまたはクライアント キャッシュと呼ばれます。

スタンドアロンの InProc キャッシュに慣れている人が、分散キャッシュに移行すると、ネットワークを経由するため、パフォーマンスが突然低下します。 シリアル化を経る必要があるため、突然パフォーマンスが速くなくなります。 当社の顧客の多くは、パフォーマンスが上がると期待していたのに、実際には下がってしまったと不満を抱いています。 その理由は、オブジェクトをヒープに保存するスタンドアロンの InProc キャッシュと競合できないためです。 したがって、クライアント キャッシュ機能がある場合、それは本質的にはオブジェクトをローカルに保持するローカル キャッシュですが、クラスター化されたキャッシュに接続されます。

繰り返しますが、これは機能です NCache があり、ほとんどの Java キャッシュには、それを失うことなく同じ高速パフォーマンスが実際に提供されます。

NCache、私たちのWebサイトにアクセスして、オープンソースのキャッシュをダウンロードできます。 したがって、オープンソース キャッシュまたは Enterprise Edition をダウンロードすると、前述したように、それらの間のすべての比較を取得できます。 NCache & Redis その上。

次はどうする？

• NCache 詳細
• ダウンロード NCache
• パーソナライズされたLIVEデモをリクエストする