ボストンコードキャンプ31

ASPを最適化する.NET Core 分散キャッシュによるパフォーマンス

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

ASP.NET Core トラフィックの多いWebアプリケーションの開発で急速に普及しています。 ASPを最適化する方法を学ぶ.NET Core オープンソースの .NET 分散キャッシュを使用することで、速度を低下させることなく極端なトランザクション負荷を処理できるパフォーマンスを実現します。この講演の内容は次のとおりです。

ASPの概要.NET Core パフォーマンスのボトルネック
分散キャッシュの概要と、分散キャッシュによるパフォーマンスの問題の解決方法
アプリケーションのどこで分散キャッシングを使用できますか
いくつかの重要な分散キャッシュ機能
オープンソースを使用した実践例 NCache 分散キャッシュとして

わかりました、ありがとう、皆さん、私の声はよく聞こえますか？さて、スポンサーの皆様に感謝の意を表し、スライドを含めるのを忘れていました。ウェブサイトにアクセスして、すべてのスポンサーのロゴを表示します。ちなみに私たちもその一人なので、これも最後に紹介します。主催者が私たちにそう言いました。したがって、このトピックについて説明しますが、可能であればこの会話をよりインタラクティブに保ちたいと思います。それでは、何か質問がございましたら、遠慮なく止めていただければと思います。すべてが録画されていることを確認させてください。

さて、今日のテーマはASPをどのように最適化するかです。.NET core 分散キャッシュによるアプリケーションのパフォーマンス? というオープンソース製品を使用します。 NCache。ここで何人が聞いたことがあるでしょうか NCache 前に？いい数字ですね。わかりました、使用します NCache 例として。この話はそれに関するものではありません NCache、ASPについてです。.NET Core パフォーマンスとキャッシュの使用方法について教えてください。 ASP のおかげでここに来たと思います。.NET core 人気になりつつある、新しいクリーンな軽量アーキテクチャ、クロスプラットフォームテクノロジ、.NET の再設計はオープンソース、多くの ASP.NET レガシーアプリケーションも ASP に移行しています.NET core。 ASP.NET core は、.NET で Web アプリケーションを開発する際の主要なテクノロジになります。

そのため、スケーラビリティを必要とするアプリケーションを開発する人が増えています。それで、ASP.NET core もちろんスケーラビリティも必要です。スケーラビリティとは何かを簡単に定義しましょう。ほとんどの人はすでにこれを知っていると思いますが、完全を期すために、これを定義します。

スケーラビリティとは何ですか？

スケーラビリティとは、応答時間が非常に優れているアプリケーションの場合、XNUMX 人のユーザーに対して非常に優れたパフォーマンスを発揮します。XNUMX、XNUMX 万、XNUMX 万人のユーザーでも同じパフォーマンスを維持できる場合、そのアプリケーションはスケーラブルであると言えます。アプリケーションが XNUMX 人のユーザーに対して適切に動作しない場合は、ここでは説明しませんが、他の問題が発生していることになります。そこで、XNUMX 人のユーザーから XNUMX 万、XNUMX 万のユーザーまで良好なパフォーマンスを維持する方法について説明します。

線形スケーラビリティ

線形スケーラビリティとは、負荷の増大に応じて実稼働環境にサーバーを追加できるようにアプリケーションが設計されていることを意味し、サーバーを追加するとトランザクション容量も増大し、維持できれば優れたパフォーマンスが得られます。線形スケーラビリティ。線形のスケーラビリティを維持できない場合は、何らかのボトルネックがあり、サーバーを追加するとすぐにアプリケーションが直面することになります。すぐに、サーバーを追加するかどうかは問題になりません。ボトルネックにぶつかっただけです。ボトルネックについてお話します。

次のアプリケーションにはスケーラビリティが必要です

では、どのアプリケーションにスケーラビリティが必要なのでしょうか? 一般に、サーバーアプリケーション、これらは Web アプリケーション、ASP です.NET core、他の Web アプリケーションによって使用される Web サービス。 Web サービスは、外部アプリケーションによって使用される独立したアプリケーションである場合もあれば、開発中の Web アプリケーションの一部である場合もあります。いずれにせよ、トランザクションが多い場合は、スケーラビリティも必要になります。

マイクロサービスは今、注目の新しいバズワードになりつつあります。これがアプリケーションを再構築する方法です。マイクロサービスはサーバー側のテクノロジーにも導入される予定で、トランザクションの多いアプリケーションで使用され、スケーラビリティが必要になります。他のサーバーアプリケーションの場合、多くの大規模組織はバックエンドでバッチ処理を行っており、バックエンドでワークフローを実行する必要があります。大量のトランザクションを処理する必要がある多数のバックエンドサーバーアプリケーションには、スケーラビリティも必要です。したがって、あなたの会社、またはこれらの種類のアプリケーションのいずれかに従事していて、優れたパフォーマンスを実現したい場合は、これが最適です。

スケーラビリティの問題

これらのアプリケーションにはスケーラビリティが必要であることがわかったところで、スケーラビリティの問題はあるのでしょうか? はい、アプリケーション層、つまり ASP にはありますが、そこにはありません.NET core アプリケーションでは、トランザクションの負荷が増大するにつれてサーバーを非常に簡単に追加できます。通常、アプリケーション層の前にロードバランサーがあり、トラフィックがすべてのサーバーに均等に送信され、ユーザーが増えるにつれて追加するだけです。箱が増えても問題ありません。もちろん、問題はデータストレージまたはデータベースです。これらはリレーショナルデータベースであり、メインフレームです。これが理由の XNUMX つです。 NoSQL databaseは勢いを増し始めましたが、技術的な理由と非技術的な理由の両方で、ほとんどの状況では依然としてリレーショナルデータベースを使用する必要があることが判明しました。したがって、皆さんがこれまでに行ってきた、または現在行っているほとんどのアプリケーションを見ると、.NET の場合はリレーショナルデータベースを使用することになります。最も人気のあるものは、もちろん SQL サーバーです。したがって、使用できない場合は、 NoSQL database、スケーラビリティを助けるのに何の役に立つでしょうか? そしてその理由は、 NoSQL database リレーショナルデータベースを放棄してデータを移動するように求められます。 NoSQL一部のデータでは保存できますが、多くのビジネスデータでは保存できません。すべての顧客、アカウント、アクティビティはすべてリレーショナルデータベースに残しておく必要があります。したがって、このスケーラビリティの問題は、図にあるリレーショナルデータベースを使用して解決する必要があります。それが私がこう言う理由です。 NoSQL database 使用できないため、必ずしも答えになるとは限りません。

解決策 (分散キャッシュ)

したがって、これを解決する方法は、当然、分散キャッシュを使用することです。これが、環境に分散キャッシュがデプロイされる方法です。

したがって、これはアプリケーション層です。場合によっては、ここの前にロードバランサーがあり、トラフィックをすべてのアプリケーションサーバーに送信することがあります。場合によっては、ロードバランサーが存在しないこともあり、バックエンドアプリケーションであるため、負荷が他の方法で共有されている可能性もありますが、いずれにせよ、アプリケーションを実行するサーバーが複数あることには変わりありません。したがって、これは非常にスケーラブルですが、データベースをどんどん追加し続けることはできません。現在、リレーショナルデータベース企業は、自社側で拡張するためにできる限りのことをしようとしています。たとえば、はるかに高速なインメモリテーブルを用意しています。 SQL サーバーでは、読み取り専用レプリカの概念が導入されていないと思います。そのため、インメモリテーブルと読み取り専用レプリカを組み合わせると、パフォーマンスが向上しますが、後で説明するように、これ。作成するレプリカの数が増えるほど、何かを更新するたびにすべてのレプリカで更新する必要があるという点で、頭痛の種が増えます。したがって、スケーラビリティを備えた最高のパフォーマンスを実現するには、レプリカが XNUMX つだけであることを確認する必要があります。したがって、すべてのデータに対して XNUMX つのマスターコピーと XNUMX つのレプリカが必要であり、同時に拡張できなければなりません。したがって、それができない理由は、リレーショナルデータベースは分散キャッシュと同じ方法でパーティション化できないためです。 NoSQL database 分散キャッシュと NoSQL はキーと値のペアであり、リレーショナルデータベースとは大きく異なる設計ですが、最終的には、アプリケーション層とデータベースの間にキャッシュ層として分散キャッシュを配置する必要があります。

それで、これは構成としてはどのようなものになるでしょうか? したがって、通常、これらはそれほど高価なボックスではありません。これらは通常、8 コアから 16 コアのボックス、16 から 32 ギガビットの大量のメモリ、および 1 から 10 ギガビットのネットワークカードです。場合によっては 64 つのネットワークカードがあり、64 つはクラスタリングを実行するためのもので、もう 32 つはクライアントなどのツール用のものですが、それはそれだけのことであり、ハイエンドで処理能力の高いデータベースサーバーに仕事をさせるのとは大きく異なります。それらは 16 つだけ、またはほとんどありません。したがって、これを回避する他の方法はありません。 .NET 環境に 32 ギガを超える RAM がある場合、そのメモリはガベージコレクションを通じて収集する必要があり、収集するメモリが増えるにつれて収集されるため、お客様にはボックスあたり 16 ギガを超える RAM を使用しないでくださいと伝えています。より多くの処理能力が必要になります。したがって、非常に高価な箱を入手し始めるという同じ問題が発生します。 32、XNUMX ～ XNUMX ビット、XNUMX ～ XNUMX ギガメモリを入手する方が良いですが、ボックス数が多いほど安くなります。

分散キャッシュはどのように機能するのでしょうか?

では、分散キャッシュは何をするのでしょうか? 実際にクラスターを構築しますが、これもまたクラスターからの話です。 NCache という観点、他にも次のようなものがあります Redis 似たようなことを違う方法で行います。したがって、分散キャッシュはクラスターを構築します。これは TCP ベースのクラスターです。クラスターで最も重要なことは、本番環境でデータベースがダウンしないようにするのと同じように、キャッシュもダウンしないようにすることです。どちらかに降ります。したがって、このクラスターは可用性が高くなければなりません。したがって、顧客にとって可用性を高めるための最良の方法は、ピアツーピアアーキテクチャを採用することです。このアーキテクチャでは、すべてのノードが平等な市民であり、どのノードもダウンしたり、ボックスを追加したりできます。マスターは存在しません。スレーブを使用すると、複雑さと高可用性の問題が発生するためです。そこで、メモリ、CPU、ネットワークカードをリソースとしてプールしました。したがって、追加するにつれて、トラフィックやトランザクションがますます増えているとします。通常はボックスを追加するのと同じように、4 対 1、5 対 1 の比率でサーバーを追加します。少なくとも XNUMX つのキャッシュサーバーがあり、その後さらに追加し続けるため、XNUMX つから始めます。負荷が増え始め、突然すべてが遅くなり始め、XNUMX つ目のボックスを追加します。さらに追加するとすべてが改善されます。ボックスをロードして追加すると、ある時点まで処理が遅くなり始めます。 XNUMX 番目のボックスを追加すると、画像が表示されます。

このようにして線形にスケールします。理論上、無制限のものはありませんが、より多くの状況に合わせてスケールインし、ボトルネックがない場合は無制限にスケールします。したがって、これにより、データベースがボトルネックになるのを防ぐことができます。したがって、これはアプリケーションアーキテクチャのほぼ不可欠なベストプラクティスとなっています。高トランザクションのアプリケーションを実行している場合は、分散キャッシュを組み込む必要があります。これが唯一の方法であり、すべてがメモリ内にあるため、パフォーマンスを達成できます。ディスクにアクセスするものはすべてメモリ内で実行されるものほど高速になることはありません。 - 分散されているため、メモリとスケーラビリティが向上します。行く前にこれに関して何か質問はありますか？実際に、の場合、 NCache あなたはできる。 NCache .NET と Java をサポートしていますが、Python などの他のアプリケーションがある場合は使用できません。 NCache場合は、他のキャッシュソリューションを使用する必要がありますが、アプリケーションはスケーラブルな環境にある必要があります。基本的に、使用する言語は関係なく、機能は変わりません。 .NET アプリケーションの場合、いくつかの利点があります。 NCache は、完全な .NET スタック、.NET コーススタックであるため、非常にうまく適合するという .NET 固有の利点を多数提供します。 Java 側にもインメモリデータグリッドと呼ばれる同様の製品があり、Java スタックに非常によく適合します。たとえば、いくつかの情報を共有します。それで、 NCache Java API を持っていますが、Java API を使用するのは製品を購入する人だけです。 NCache または使用 NCache .NET の観点から。それで、彼らは持っています NCache 彼らは、それを Java にも使用するほうがよいと言いました。Java ショップは Java ベースのインメモリデータグリッドを探し、.NET ショップは NCache。つまり、.NET ショップであれば、Java に対してすべての .NET 専門知識を持っているため、すべての専門知識によって市場がこのように分割されるのです。では、なぜ状況が複雑になるのでしょうか? データベースの場合、SQL データベース以外のどのデータベースでも使用できますか? データベースにアクセスする方法は、キャッシュ層に存在する独自のカスタムコードを通じて行われるため、誰でも構いません。

これはもう XNUMX つの機能であり、これから説明しますが、キャッシュをデータベースと確実に同期させるための重要な機能の XNUMX つは、カスタムコードがキャッシュサーバー上に存在する必要があるということです。キャッシュをブラックボックスにすると、キャッシュ上にはデータ以外は何もなくなり、トリガーやストアドプロシージャなどのないリレーショナルデータベースがあるようなものになります。したがって、キャッシュの使用が制限されます。つまり、キャッシュは単なるブラックボックスとしてスタートしました。 Memcached は人気のあるキャッシュでしたが、何もせず、単なるストアでしたが、時間が経つにつれて、コードも実行できる適切なインテリジェントなエンティティに進化しました。どれでも NoSQL、任意のリレーショナルデータベースを使用できます。繰り返しになりますが、私が話しているこれらの機能はすべて、オープンソースであり、エンタープライズ向けの両方です。それがオープンソースであるため、私が言及しているのはそのためです。他に何かご質問は？対処するとき NCache 主に自動キャッシュですか、それともキャッシュに API を使用しますか? では、さらに詳しく説明していきますが、何をキャッシュするかによって異なります。特定の種類のキャッシュの使用は自動的に行われます。たとえば、ASP を導入している場合、.NET core セッションの場合、これはプラグイン可能なモジュールであり、プラグインするだけでセッションをキャッシュに保存し始めるため、何もする必要はありませんが、アプリケーションデータをキャッシュする場合、そこに大きなメリットがあります。では、何をキャッシュするかを決定するために呼び出さなければならない API があるのでしょうか? どれくらいの期間キャッシュしますか? データベースとどのように同期しますか? 他にも心に留めておかなければならないことがたくさんあります。そこで、次のような分散キャッシュをどのように使用するかについて、すべての機能を説明します。 NCache あらゆる種類のデータをキャッシュできるようにするには、API が必要です。はい。

分散キャッシュの使用

わかった。これで、分散キャッシュが重要であることがわかりました。これにより、パフォーマンスとスケーラビリティが得られます。分散キャッシュの使用方法を見てみましょう。分散キャッシュを使用できる方法は XNUMX つあります。 XNUMX つの大きな技術的ユースケース。

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

そして XNUMX つ目はアプリケーションデータのキャッシュです。これについては、これまで説明してきたことです。これについては、すぐに詳しく説明します。アプリケーションデータのキャッシュでは、データがデータベースとキャッシュに存在することに留意する必要があることが XNUMX つあります。データが XNUMX か所に存在する場合、最もよく起こる問題は何でしょうか? 同期が失われる可能性があるため、顧客はその百万ドルを銀行から XNUMX 回引き出し、XNUMX 回はキャッシュから、もう XNUMX 回はデータベースから引き出す可能性があるため、そのような状況は絶対に避けたいものです。以前はこの状況が非常にひどかったため、キャッシュという言葉を言うと、ほとんどの人は読み取り専用データをキャッシュするだけだという考えを抱くほどでした。データが変更されることはありません。変更されたものをキャッシュしておけば、問題が発生する可能性はありません。そこで、このようなことが起こらないようにする方法について説明しますが、これはアプリケーションデータのキャッシュにおいて留意すべき最も重要なことです。

ASP.NET Core 特定のキャッシュ

XNUMX 番目のユースケースは ASP です.NET core-固有のキャッシュと、ASP からキャッシュできるものが XNUMX つあります.NET core。 XNUMX つはセッションです。これはほぼすべての ASP にあります。.NET core アプリケーションはセッションを使用し、以前の ASP.NET 環境では、Microsoft では InProc、状態サーバー、SQL の XNUMX つのストレージオプションが提供され、XNUMX 番目がカスタムでした。最初の XNUMX つは実際には機能しませんでしたが、XNUMX つ目はキャッシュをプラグインできましたが、ASP で使用できました。.NET core 彼らは実際に正しいことを行っています。つまり、git コードから取得し、IDistributedCache インターフェイスに基づくように実際に設計したのです。したがって、サードパーティストアをプラグインできるようになり、次のようなものをプラグインできます NCache セッションの保存が自動的に開始されます。その方法を説明します。

ASPのXNUMX番目のこと.NET Core は応答キャッシュであり、キャッシュできるページ出力です。したがって、次回そのページが呼び出されるとき、そのページは実行されるべきではなく、変更されていない場合は出力を返すだけでなければなりません。同じ出力を再度再現する場合、なぜページを再実行または実行するのでしょうか? 出力を提供するだけではだめなので、ASP.NET では出力キャッシュと呼ばれていましたが、現在は応答キャッシュと呼ばれています。現在は、より多くの HTTP 標準に基づいています。したがって、これは不可能でしたが、サードパーティのコンテンツキャッシュをエッジに接続することができますが、これについても説明します。アプリケーションデータキャッシュと ASP の間で留意すべき違い.NET core キャッシュは、データが XNUMX か所に存在するアプリケーションデータキャッシュとは異なり、現在はデータはキャッシュ内にのみ存在し、キャッシュはメモリ内にあるため、レプリケーションがない限り、いずれかのキャッシュサーバーがダウンするとこのデータは失われます。。したがって、良好なレプリケーションが得られないキャッシュは、セッションやデータのその他の傾向のキャッシュには適していないということは、覚えておくべき非常に重要な点です。

XNUMXつ目のASPがある.NET coreSignalR と呼ばれる具体的なものについては説明しませんが、ライブフィードバックを提供できるライブ Web アプリがある場合、株価を常に更新する必要があるとします。したがって、分散キャッシュをバックプレーンとして使用することもできますが、それについては触れませんでした。

セキュリティ

最初の XNUMX つの質問については、必要に応じて詳しく説明します。したがって、まず第一に、キャッシュはアプリケーションの背後に存在します。アプリケーションとデータベースの間に存在します。一般に、かなり安全な環境内で行われます。アプリケーションが DMZ 内にある場合、キャッシュを DMZ 内ではなくファイアウォールの内側に保持するお客様もいます。時にはDMZ内に保管されることもありますが、ほとんどの場合は安全な状況にありますが、大手銀行などの金融サービス顧客の多くはそれに満足しておらず、さらなるセキュリティを求めています。そこで、Enterprise Edition の登場です。 NCache には暗号化を実行できる機能があります。したがって、キャッシュに置かれたすべてのデータは 3DES または AES256 暗号化などで自動的に暗号化され、さらにセキュリティも確保され、キャッシュへのすべての接続は Active Directory を通じて認証され、認証が必要になります。したがって、完全なセキュリティ機能がエンタープライズエディションに組み込まれています。

平均的な顧客は、データが機密でない限り暗号化を使用しません。したがって、財務データを保管している場合は、コンプライアンス上の問題や HIPAA の問題が発生するため、環境が安全であっても、コンプライアンス上の問題が発生するとすぐに、さらに一歩進んで暗号化を行う必要があります。。それで、 NCache Enterpriseたとえば、クライアントとキャッシュ層の間の TLS 接続を実行します。そのため、接続自体は完全に保護されており、さらに暗号化が組み込まれているため、メモリに保存されるデータも暗号化された形式で保存されます。そして、それはかなり満足しています。つまり、当社には多くの金融サービス顧客がおり、彼らはそれに完全に満足しています。

NCache 導入可能であり、ほとんどのお客様は依然としてオンプレミス環境で使用しています。したがって、彼らはアプリケーションをデプロイする独自のデータセンターを持っているため、 NCache アプリケーションの一部として。クラウドの中にいると、 NCache Azure と AWS の両方で利用でき、VM として利用できるか、マネージドキャッシュサービスをちょうど立ち上げようとしています。いずれにしても、次のことを確認します。 NCache クラウドの仮想ネットワーク内に存在します。したがって、オンプレミスでは、常に独自の環境で多数の VM を取得するか、独自のデータセンターの場合は独自のサーバーを取得してアプリケーションとともにデプロイするだけであるため、これは問題ではありません。あなたがインストールします NCache ソフトウェアとして内部にインストールするためのもので、docker を使用することもでき、最新のアプリケーションで実行できると期待されるすべての機能を確認しました。 NCache します。そしてクラウドでは、VM を取得するかマネージドキャッシュを取得できますが、クラウドでは、AWS の場合は常に VPC 内、Azure の場合は vnet 内に作成されます。それは仮想ネットワーク内にあります。したがって、これはアプリケーションに近いものです。なぜなら、複数のホップにまたがって拡張する必要がある場合ではないからです。たとえば、それがホスト型キャッシュの場合です。小規模なアプリケーションでは問題ありませんが、重大なアプリケーションにはおそらく問題ありません。 NCache は、ほとんどの場合、アプリケーションを通じてビジネスを行うミッションクリティカルなアプリケーションで使用されます。そこで使用するのが NCache.

したがって、そのような状況では、速度の低下を許すことはできず、速度の低下を許すことができない場合は、すべての制御をそこで行い、キャッシュを可能な限りアプリケーションの近くに保持する必要があります。それは、どのようなユースケースを行うかによって異なります。たとえば、最大かつ最も迅速な利点はセッションであり、コードを変更せずにすぐにプラグインすることができます。単なる設定変更です。 ASPの場合.NET core、それは構成の変更ではありません。これは起動ファイルのコード変更ですが、非常に小さいものですが、アプリケーションデータのキャッシュを行う場合は、それでも非常に簡単な変更です。

API がどのようなものかを簡単にお見せしましょう。それで、この API を見てください。

キャッシュ接続

Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();

データの取得

Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");

データの書き込み

cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);

cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;

Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");

それは非常に小さなcache.get、cache.add、Insert、removeにすぎません。したがって、オブジェクトとしてキーと値があります。したがって、組み込むのは非常に簡単ですが、実際に作成する必要があるため、データベースからデータを取得するときは常に最初にキャッシュを確認し、キャッシュにデータがある場合はキャッシュから取得し、そうでない場合はデータベースにアクセスします。それを取得してキャッシュに入れる、それがモデルです。その通り。スピードを上げるつもりだ、そうでないと間に合わない。お見せします NCache 少し後で。

Pub/Subメッセージングとイベント

したがって、pub/sub メッセージングも非常に強力な機能です。今日の多くのアプリケーションでは、その作業を調整する必要があります。今日、ある人と話していましたが、イベントベースのプログラミングをたくさん行う必要があると言っていました。したがって、pub/sub メッセージングは、アプリケーション内にインメモリのスケーラブルなプラットフォームであるインフラストラクチャを備えているため、非常に強力なイベント駆動型プログラミングモデルを提供します。メッセージングバスのようなものと考えることができます。分散環境向けではありません。これは同じデータセンターの XNUMX つの場所タイプの状況ですが、すべてがメモリ内にあり、スケーラブルであるため、非常に高速です。これが、次のような分散キャッシュを使用する XNUMX 番目のユースケースです。 NCache。はい、そうです、そうです、そしてオープンソースもそれをサポートしています。したがって、これらの機能はすべて、オープンソースとエンタープライズの両方で利用できます。 NCache API はオープンソースとエンタープライズでほぼ同じです。

pub/sub でこれまで見てきたことは、高トラフィックのアプリケーションや高トランザクションを使用している場合、pub/sub エンジンが超高速であることが本当に必要であるということです。 NCache 本当に輝いています。

ASP.NET Core アプリのデータキャッシュ

わかった。つまり、アプリケーションデータのキャッシュです。どうやってやるのですか？それで、それはそこに答えることでもあるので、それを行うことができる方法はXNUMXつあります。

I分散キャッシュ

ASP の IDistributedCache インターフェイスを使用できます。.NET core 付属しており、それに対してプログラムした場合は、プラグインするだけです。 NCache プロバイダーとして。したがって、IDistributedCache API プログラミングを行ったら、それ以上コードを変更する必要はありません。したがって、一度プログラムを作成すれば、XNUMX つのキャッシュベンダーに縛られないという利点があります。欠点は、それが最小公倍数であることです。それがどのようなものかお見せします。これですべてです。 Get と Put があるだけです。 Get、Remove、Set はご存知でしょうが、キャッシュを最大限に活用するには他にもできることがたくさんあります。つまり、キャッシュをデータベースと同期する必要があるという事実について話しました。したがって、それには長所と短所があります。

Entity Framework Core Cache

XNUMX つ目は、EF Core アプリケーションを持っている場合、EF Core アプリケーションを持っていることになります。プラグインするより簡単な方法です。 NCache そしてお見せします。そこで、実際に EF Core の拡張メソッドを実装しましたが、これもオープンソースでありエンタープライズです。 EF Core サンプルがあります。わかった。したがって、EF Core アプリケーションがある場合、通常は次のような EF Core クエリがあり、LINQ スタイルのクエリを使用して何かをフェッチします。それで、拡張メソッドを実装しました。FromCache としましょう。これらはたくさんのメソッドです。これはそのうちの XNUMX つです。つまり、このクエリが最後にキャッシュに保存されていた場合はキャッシュに移動し、クエリから取得します。キャッシュ。キャッシュにない場合は、データベースに移動し、この通常の EF コアクエリを実行して取得し、キャッシュに置きます。したがって、その XNUMX 行または XNUMX つのメソッド呼び出しだけで、データベースからのすべてのデータのキャッシュが自動的に開始されます。そのため、作業が簡素化され、プラグインする場所が正確にわかるため、余分な API 呼び出しを行う必要がありません。

したがって、EF Core アプリケーションの場合も、コードの変更は必要になりますが、できる限り最小限の変更でデータのキャッシュを開始できます。実際、EF コアの場合、それらは一連のメソッドであり、これは FromCache であり、ほとんどが from であり、使用できるメソッドは XNUMX つまたは XNUMX つほどです。FromCache、次に LoadIntoCache、FromCacheOnly です。したがって、EF Core では、変更を保存すると、データベースの更新前またはデータベースの更新後にキャッシュも更新されます。したがって、キャッシュには更新されたバージョンのデータが含まれます。キャッシュの整合性は、まず、キャッシュに保持されているデータがすべてキャッシュサーバーであることを確認することによって維持されます。たとえば、これはキャッシュサーバーです。サーバーが XNUMX 台ある場合と、サーバーが XNUMX 台ある場合を考えてみましょう。キャッシュ全体はパーティションに分割され、各パーティションには独自のバケットのセットがあるため、データはパーティションの XNUMX つにのみ存在します。したがって、そのデータは他のサーバーにレプリケートされます。これはレプリカと呼ばれますが、次の場合はレプリカと呼ばれます。 NCache はアクティブではなく、パッシブであり、アプリケーションはレプリカと通信しません。アプリケーションはパーティションとのみ通信します。したがって、データは XNUMX つの場所にのみ保存されるため、同期の問題は発生しません。全員が同じサーバーにアクセスしますが、パーティション化されているため、全員が同じサーバーにアクセスするわけではありません。一部のキーはここに保存され、一部はここに保存され、一部はここに保存されます。

これが分散キャッシュのようなものです NCache SQL サーバーでは実行できないことを実行できます。これは、リレーショナルデータベースの性質上、分割できないことですが、分散キャッシュの性質上、実行できるためです。ここで分割すると、これらは XNUMX つのサーバーになり、おそらく XNUMX 個のアプリケーションサーバーで共有されます。そして、すべてのアプリケーションサーバーには XNUMX つ、XNUMX つ、XNUMX つ、または XNUMX つのワーカープロセスがある場合があります。そのため、多くの異なるクライアントプロセスがキャッシュと通信しますが、実際のデータは XNUMX つの場所にのみ保存されるため、同期の問題は発生しません。現在、他のトポロジが存在します NCache 同じデータがアクティブ-アクティブで複数存在する場合、複製されます。その場合、 NCache 変更を同期する必要があります。これはトークンベースであり、シーケンスベースの更新アルゴリズムであり、あまりスケーラブルではありません。したがって、トランザクションが多い環境にはお勧めしません。

レプリケーションを使用したパーティション化されたキャッシュは、より優れた戦略であり、使用するのに適したキャッシュトポロジと呼ばれます。それで、そのようにして NCache キャッシュ内のデータが常に正しいことを確認します。それはあなたの質問の答えになりましたか？それで、あなたが示したポートは、どのキャッシュからそれを取得する必要があるかを示すコード上の構成または設定はありますか? うん。たとえば、app.config にアクセスすると、mycacheId を使用することが表示されるので、キャッシュが何であるかを示します。したがって、キャッシュを作成すると、 NCache。すべてのキャッシュには名前が付けられ、その名前によってバックグラウンドでキャッシュの場所がわかるため、ここで名前を指定するだけで、どこに行ってキャッシュを取得するかがわかります。そして、キャッシュが実際にどのようなものかを示します。これらのサーバーすべてに XNUMX つのキャッシュ名があり、同じサーバー内で複数のキャッシュ名を持つことができ、同じサーバー上で複数のキャッシュを持つことができ、XNUMX つのキャッシュは複数のサーバー上に存在でき、分散キャッシュであるため、XNUMX つのキャッシュ名が存在する必要があります。複数のサーバーではこのように分散されますが、同じサーバーを他のキャッシュ名にも使用でき、各キャッシュ名によって分離されます。良い質問。

高可用性

つまり、ここで私は高可用性が本当に本当に重要だと言いました。実行時に停止することなくサーバーを追加または削除できない場合、アプリケーションの可用性は実際には高くありません。私たちにはすでに実行している顧客がいます NCache 何ヶ月も何年も止まることなく。たとえば、XNUMX 台のサーバー構成があり、負荷が増大したため XNUMX 台目のサーバーを追加したとします。したがって、XNUMX 番目のサーバーを追加する必要があります。XNUMX 番目のサーバーを追加するだけです。ツールを通じてそれを示します。XNUMX 台追加するだけです。 NCache 舞台裏は再分割されます。したがって、これら 2 つのパーティションは 3 つのパーティションに変換されます。こことここのバケットの一部は、アプリケーションの実行中に自動的に XNUMX 番目のパーティションに割り当てられますが、アプリケーションはこれに気づきません。舞台裏では XNUMX 番目のパーティションが存在し、レプリカも作成されています。つまり、レプリカ XNUMX をここに移動する必要があり、レプリカ XNUMX がここに作成されるとします。

NCache この背後でそれを維持します NCache ハッシュマッピングにキーを使用しますが、すべて動的に実行されるため、再分割され再割り当てされるバケットマップのような分散マップと似ています。したがって、実際には、データは実行時に自動的にあるサーバーから別のサーバーに移動します。

ロケーションアフィニティ

したがって、場合によっては、一部のデータを同じパーティションにまとめて保持したい場合があります。 NCache にはロケーションアフィニティ機能があり、指定することができ、その後それを指定することになります。これら XNUMX つのデータは関連していると言うでしょう。同じサーバー上に置きたいのですが、 NCache その上に追加のキーを作成することで、同じサーバー上にそれを保持します。先ほども述べたように、これらはすべて高度な機能であり、最小公倍数だけを使用するだけでは得られないものであり、これらの機能を使用することで、 NCache お客様のニーズに合わせて、お客様の環境に合わせてカスタマイズします。

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

それで、私が最初に取り上げたかったのは、これらのトピックであり、これらは非常に重要です。アプリケーションデータキャッシュの場合、最も重要なことは、キャッシュが常に最新であることです。つまり、最新とは、正しいデータが含まれていることを意味します。データベース内のデータが変更された場合、キャッシュには最新のデータが含まれます。

時間ベースの有効期限

したがって、有効期限はキャッシュで行われる最も一般的な方法であり、ほとんどすべてのキャッシュには機能として有効期限があります。 NCache それも持っています。絶対的な有効期限と、スライド式の有効期限があります。絶対有効期限とは、データをキャッシュに追加しているとします。これは XNUMX 分以上期限切れになったら OK と言えるでしょう。これは、データを XNUMX 分以上キャッシュに保持するのは安全ではないと思うからです。つまり、データを XNUMX 分間キャッシュに保持しても安全であり、一部のデータには十分であるが、他のデータにはそうでない可能性がある、という知識に基づいた推測を行っていることになります。

スライド有効期限は、セッションを保存するときに、誰も使用しなくなったらOKし、全員がそのセッションを使用し終わったら削除する場合に適しています。つまり、それはむしろクリーンアップの期限切れです。絶対的な有効期限は同期です。同期はデータベースとの一貫性を保つため、スライディングはクリーンアップです。ただし、有効期限は根拠に基づいた推測です。その推測が間違っていても

データベースの依存関係

データの不整合を許容できる場合もあれば、許容できない場合もあります。したがって、それができない場合は、他の機能が必要になるため、ここがその場所です NCache 特に際立っているのは、たとえば、キャッシュをデータベースと同期できることです。それで、 NCache SQL Server に組み込まれている SQL 依存関係を使用して SQL Server を監視します。したがって、キャッシュするすべての項目について、これを SQL データベーステーブルの対応する行にマップすると言うことができます。 NCache それを監視し、その行が変更されると、 NCache 次に、そのアイテムをキャッシュから削除するか、再度リロードします。それで、突然インテリジェントキャッシュができました。キャッシュしているものは常に一貫していることを確認できます。これは、キャッシュがブラックボックスの場合には得られないものです。

したがって、キャッシュを使用してその種のインテリジェンスを実現できる必要があります。SQL の依存関係は .NET の機能なので、そこが重要です。 NCache データベースが SQL の場合、.NET であることが役立ちます。さて、ここでも Oracle に依存していますが、これも Oracle データベース通知を使用します。ポーリングベースの通知という別の方法があります。これはより効率的ですが、リアルタイムではなく、キャッシュを同期することもできます。非リレーショナルデータソース。データは次の場所にある可能性があります NoSQL database、それはクラウド内にあるかも知れませんし、どこにでもあり、それを監視できるようにしたいと考えます。したがって、カスタム依存関係と呼ばれるもの、つまりキャッシュサーバー上に存在するコードを作成できます。 NCache 一定の間隔で呼び出し、データソースを確認し、データが変更された場合は通知します。 NCache、データは変更されました。これを削除するか、リロードしてください。

つまり、この領域は NCache 本当に本当に強いです。データを最新の状態に保ちたい場合は、キャッシュが最新であることを確認するために次のことを実行できる必要があります。

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

もう XNUMX つの機能は、リードスルーとライトスルーです。したがって、これに有効期限とデータベースの同期が組み合わされるようになりました。これにより、キャッシュがデータベースからデータをロードできるようになり、たとえばリードスルーがある場合、リードスルーがどのようなものかを示します。これは実装する単なるインターフェイスであり、コードは実際にはキャッシュ上に存在するため、このコードを実装するインターフェイスは次のとおりです。したがって、ソース呼び出しからのロードがあり、キーが与えられてから、 NCache メソッドを呼び出し、キャッシュサーバーがメソッドを呼び出し、このコードがサーバー上で実行されます。すべてのキャッシュサーバーで、 NCache このメソッドを呼び出して、このキーがキャッシュにないため、先に進んでロードしてくださいと言います。したがって、cache.Get を実行すると、そのキーはキャッシュにないと考えられ、キーが存在しないことを示す null を返すか、リードスルーがある場合はキャッシュに移動することができます。そして NCache データベースにアクセスして読み取ることができます。だから、いつでも手に入れることができます。これは、データを常にキャッシュに保持しておきたい多くの場合に非常に便利です。

したがって、リードスルーを使用すると、リードスルーと有効期限またはデータベース同期を組み合わせると、データの有効期限が切れたときに行うことができます。 NCache 自動的に更新できるのに、なぜ削除するのでしょうか? データを再ロードする場合は、とにかく次回に行ってください。そのデータは必要であり、最新の状態を保つために期限切れにするためです。それで、なぜそれを持っていないのですか？ NCache 戻ってリロードしてください。リードスルーを実装している場合は、 NCache これは自動的に行われ、同じことが起こります。データベースまたはデータソース内のデータが変更され、この同期機能によってデータベースが変更されたことが認識され、リードスルーを実装していれば、自動的に再ロードされます。。

同様に、ライトスルーには、ライトビハインドがある場合にキャッシュを更新できるという別の利点があります。つまり、一部のデータは、更新にはそれほど敏感ではありません。もちろん、金融データの銀行残高の場合は、後書きを実行したくありませんが、場合によっては、更新をキューに入れるだけで問題ありません。したがって、キャッシュを更新する場合、キャッシュの更新はデータベースを更新するよりもはるかに高速です。もちろん、分散されているため、よりスケーラビリティが高くなります。キャッシュを更新すると、 NCache データベースを舞台裏で非同期的に更新してください。これが後書き機能で、アプリケーションが突然高速化します。何がボトルネックになっているのでしょうか? データベースから読み取り、データベースに書き込みます。読み取りはキャッシュできるため、データベースにアクセスする必要さえありませんが、書き込みはデータベースに送信する必要があります。データベースがマスター権を持っているため、それを回避することはできませんが、ライトビハインドのようなものになります。かんたんです。

これももう XNUMX つの機能です。 NCache 突然、アプリケーションをさらに強化します。質問: では、念のため、データベースに書き込むことができず、非同期を実行すると、例外がスローされますか? はい。例外をスローします。コールバックを呼び出すことができます。 NCache 繰り返しますが、コードは、このライトビハインドコードはキャッシュサーバー上で実行されていますが、コールバックがここにあるため、クライアントに通知が返され、コールバックが呼び出され、修正アクションを実行できます。キャッシュに慣れてきたら、 NCache キャッシュをデータベースと同期できると、より多くのデータをキャッシュすることになります。キャッシュするデータが増えれば増えるほど、キャッシュはデータベースのように見え始めます。これは、キーと値を組み合わせてデータを取得する方法が十分にスマートではないことを意味します。したがって、SQL に基づいてデータ、特に参照データを検索できる必要があります。

SQL検索

EF Core クエリについて話したとき、キーだけではなく属性に基づいてデータを取得していると説明しました。したがって、SQL クエリや LINQ クエリ、またはキャッシュを大幅に高速化する EF コアを使用してデータを検索できる場合。それは別の方法です NCache 際立っているのは、すべてのデータをキャッシュに保存すると、検索できることです。ボストンまたはニューヨークに拠点を置く顧客をすべて教えてくださいと言うと、キャッシュから顧客オブジェクトのコレクションが得られます。つまり、データベースはよりデータベースらしくなり始めており、そのデータベース、特に参照データに対するプレッシャーをすべて取り除くことができます。したがって、SQL 検索は非常に重要です。

わかった。今私があなたに見せたいのは NCache のように見えますか、またはキャッシュは次のようになりますか? ということで、Azureにログインしました。したがって、XNUMX つのキャッシュサーバー VM があります。したがって、XNUMX つのキャッシュサーバーがあり、XNUMX つは Windows クライアント、もう XNUMX つは Linux ラインです。 .NET Core、アプリケーションを Windows または Linux で実行している可能性があります。 NCache 実際には動作する可能性がありますが、キャッシュサーバーは Linux 上でも実行できます。 .NET Core なぜなら NCache は .NET Core ネイティブ。

キャッシュを作成する

たとえば、私は Windows クライアントに対してリモートデスクトップを実行しました。実際にキャッシュを作成してみます。キャッシュには XNUMX つのサーバーがあり、Windows クライアントが XNUMX つ、Linux クライアントが XNUMX つずつあります。クライアントという言葉を使用する場合、実際にはアプリケーションサーバーボックスを指します。わかった。ということで、これを使ってみます NCache マネージャーツール。このツールは Enterprise Edition の一部ですが、オープンソースのコマンドラインツールまたは構成ファイルを使用して同じことをすべて行うことができます。ただし、便宜上、ここではキャッシュを作成します。

すべてのキャッシュに名前が付けられていると述べたので、キャッシュをデモキャッシュと呼ぶことにします。

トポロジを選択します。レプリケーションを使用したパーティション化されたキャッシュを選択します。

非同期レプリケーションを行うので、非同期レプリケーションと非同期レプリケーションがあります。同期レプリケーションは、より機密性の高いデータ、財務データ、および更新の一部としてこれらのレプリケーションを実行する必要があるものである場合に、非同期を行う余裕がない場合に行われます。これにより、当然速度が低下しますが、速度がさらに高くなります。

ここにキャッシュサーバー 6 があり、キャッシュサーバー 7 があり、XNUMX サーバーのクラスターを作成したところです。まだ実行されていません。 XNUMX つのクライアントノードを追加します。これは私のウィンドウです、サーバーがありました。つまり、XNUMX は Windows クライアント、XNUMX は UNIX クライアントです。わかった。したがって、通常は XNUMX つのキャッシュサーバーと XNUMX つのクライアントを使用します。前述したように、少なくとも XNUMX つのキャッシュサーバーがあり、クライアントとサーバーの比率は XNUMX 対 XNUMX、XNUMX 対 XNUMX になります。それで、今はキャッシュを開始しているところです。繰り返しになりますが、これらすべてを XNUMX か所から行うことができ、まもなくリリースされる次のバージョンでも同じことが可能です。これはすべて Web ベースなので、クラウド上で行うことができます。統計を開こうとしています。これらはモニタリングのようなもので、perfmon 統計です。

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

このボックスがクライアントになったので、クライアントがこれと通信できるかどうかをテストして確認します。そこで、PowerShell コンソールを開いてみましょう。 Windows から XNUMX つのパーシャルを取得し、ここでは XNUMX つの Linux にログインします。つまり、ここに Linux があり、今度はここに Linux があります。右？ここでは、PowerShell を起動する必要があります。また、Windows では必要のないモジュールをインポートする必要があります。モジュールはすでにそこにあるので、ここでも同じことを行う必要があります。 Linux で PowerShell を起動する必要があるので、クライアントを起動します。それで、 NCache このストレステストツールが付属しているため、自分の環境でストレステストを非常に簡単に行うことができます。正確にその方法がわかるように、 NCache 実行しますか？したがって、そのパフォーマンスについては何も言う必要はありません。ここでは、サーバーごとに 500 秒あたり約 XNUMX のリクエストを実行しているとします。

わかった。そこで、負荷を増やしたいので、XNUMX 番目のコンソールに移動して、もう一度ストレステストを実行することにします。

さて、突然、これが 1500 倍にジャンプすることがわかります。それでは、さらにストレスを加えてみましょう。 Linux の 3,000 つに来て同じことを言うと、突然リクエストあたり 4,000 件近くになりました。つまり、現在は合計で 50,000 秒あたり約 XNUMX のリクエストを実行しており、「もう XNUMX つやらせてください」という感じで、さらに XNUMX 秒あたり XNUMX のリクエストを実行しています。つまり、もっと多くの VM がある場合は、さらに多くのインスタンスを追加し続けることができます。インスタンスを増やすこともできます。すぐにわかると思いますが、これがどのようなものになるかは最大値に達し、これら XNUMX つのサーバーは必要になります。 XNUMX 秒あたり少なくとも約 XNUMX のリクエストを処理できますが、これも小さなデータセットの場合であり、オブジェクトサイズが増加すると、もちろん減少しますが、最大値に達したら、ここで繰り返し作業を進めます。正しく実行されています。XNUMX 番目の VM はありませんが、これを実行して XNUMX 番目のアドレスを追加するだけです。完了と言うと、ここに XNUMX 番目のボックスが追加され、パーティション分割がすべて実行されます。または自動的に再パーティション化されます。

同様に、いずれかの VM を停止する必要がある場合も、それが実行されます。はい、それで、私の話は終わりです。何か質問がありましたらお答えできますか？これは唯一のネイティブ .NET ソリューションであり、他の唯一のネイティブソリューションは AppFabric 中止になったもの。それで、 Redis は .NET ソリューションではありませんが、Microsoft はテクノロジーに依存しないことを望んでいたため、Azure 用にそれを選択しましたが、私たちはネイティブ .NET です。私たちは初日からそうしており、私たちが知る限りでは、.NET にとって最も人気のある選択肢です。

NCache 詳細

エディションの比較

ダウンロード NCache