フィリー.NETコードキャンプ

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

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

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

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

今日のトピックは、ASP を最適化する方法です。.NET core パフォーマンス。私はもっとインタラクティブな議論をしたいと思っていますので、皆さんが質問がある場合は、私たちが話している間、手を挙げてください。 ASP のおかげでここに来ていると思います。.NET core は、クリーンで軽量なアーキテクチャを備えているため、現在、新しい .NET アプリケーションや .NET Web アプリケーションを開発するための一般的なテクノロジです。おそらく、すでに ASP.NET から MVC を使用していると思います。その場合はASPに移行しましょう.NET core かなり簡単になります。 ASP.NET core 軽量です。これはクロスプラットフォームであり、オープンソースであり、巨大なレガシー ASP.NET ユーザーベースがあるため、ほとんどのユーザーが ASP に移行する可能性が非常に高いです。.NET Core.

それで、ASP.NET core 今後は、高トラフィックの Web アプリケーションや高トラフィックのサーバーアプリケーションと Web アプリケーションを開発するための .NET のテクノロジが選択されることになります。それはASPを意味します.NET core スケーラビリティが必要であり、それがあなたがここにいる理由だと私は確信しています。さらに詳しく説明する前に、定義を理解しておきましょう。

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

スケーラビリティとは何ですか? スケーラビリティとは本質的に、XNUMX 人のユーザーがいるアプリケーションがあり、超高速で優れた応答時間を実行する場合、XNUMX、XNUMX、または XNUMX のユーザー、同時ユーザーでも同じ応答時間、同じパフォーマンスを維持できる場合、アプリケーションはスケーラブルであることを意味します。アプリケーションが XNUMX 人のユーザーに対してうまく動作しない場合は、これは問題ではありません。他のユーザーがいる場合は、データベースへのアクセス方法や全体的なプログラミングのやり方を見直す必要があるでしょう。これは、少なくとも少数のユーザー向けにアプリケーションを開発し、良い仕事をした後、それをスケールする方法を知る必要があることを前提としています。

線形スケーラビリティとは何ですか?

線形スケーラビリティとは、運用環境にサーバーを追加できることを意味し、サーバーを追加すると、トランザクション容量を線形的に追加できます。

ここでさらに詳しく説明しますが、何が起こるかというと、XNUMX つのサーバー Web ファームの負荷分散から始めるとします。一定のユーザー数を超えると、これら XNUMX つのサーバーが限界に達し、パフォーマンスが低下し始めます。その後 XNUMX 台目のサーバーを追加すると、突然容量が少なくとも XNUMX 分の XNUMX、または新しい公式によって増加するはずです。 XNUMX 台のサーバーを最大にすると、必ず増分を再度追加します。それができれば、直線的にスケーラブルなアプリケーションアーキテクチャを手に入れることができます。それができない場合は、非線形になります。

非線形スケーラビリティとは何ですか?

非線形とは、基本的に、アプリケーションにスケーリングを妨げるボトルネックがあるため、いくつかのサーバーを追加した後、さらにサーバーを追加しても変化がないことを意味します。したがって、負荷をさらに追加し、アプリケーションがクラッシュする可能性がある程度まで通信すると、実際にはパフォーマンスが低下します。したがって、非線形のスケーラビリティは絶対に望ましくありません。これは基本的に、ある時点以降はスケーラビリティがなくなることを意味します。

スケーラビリティが必要なアプリはどれか

では、どのようなタイプのアプリケーションにスケーラビリティが必要なのでしょうか? これらはすべてサーバーアプリケーションです。これらは ASP を備えた Web アプリケーションです.NET core Webサービス、やはりASP.NET core。マイクロサービスで開発する場合、マイクロサービスは現在大きなバズワードになりつつあり、コンテナ内およびコンテナ化された環境で実行できるため、ASP も実行できます。.NET core コンテナ化された環境では、マイクロサービスは、バックエンドで大量のトランザクションを処理するスケーラビリティやその他のサーバーアプリケーションにとって非常に優れたユースケースの XNUMX つです。

したがって、これらのタイプのアプリケーションのいずれかがある場合、通常、これらは顧客向けの出力向けアプリケーションであるか、少なくとも出力向けアプリケーションの一部です。 Web サービスアプリケーションの場合、Web アプリケーション全体の一部である可能性があり、Web サービス層があり、同様のことがマイクロサービスにも当てはまりますが、通常、それらは顧客向けまたは出力向けのアプリケーションですが、常にそうとは限りません。大企業の場合、社内ユーザーが何万人もいるかもしれませんが、ほとんどの場合、それは社外のユーザーです。

スケーラビリティの問題と解決策

つまり、スケーラビリティの問題があり、それが今日私たちがこの会話をしている理由であり、スケーラビリティの問題はアプリケーション層にはありません。したがって、負荷分散された環境がある場合、アプリケーション層は非常に直線的に拡張されます。さらにサーバーを追加しても問題ありません。それはデータベースまたはデータストレージです。保存されているあらゆる種類のデータがボトルネックになるのは、アプリケーションデータ、セッション、保存または取得しているその他のデータである可能性があり、それがボトルネックになる理由の XNUMX つです。 NoSQL database人気を博しました。

NoSQL Database

問題は NoSQL databaseつまり、リレーショナルデータベースから離れることが求められます。私たちがこれまで見てきたことは、多くの状況、つまり大部分の場合で、次のように使用できるということです。 NoSQL database一部のデータについては問題ありませんが、多くのデータは依然としてリレーショナルデータベースに存在する必要があります。したがって、Azure では引き続き SQL Server または SQL データベースを使用することになります。したがって、リレーショナルデータベースを使用してこのスケーラビリティの問題を解決する必要があります。 NoSQL databaseは使用できないため、必ずしも答えになるわけではありません。リレーショナルデータベースを置き換えることもできません。 NoSQL database いつも。そして、代替できない場合、使用できない場合、その恩恵を受けることはできません。たとえ使用できたとしても、 NoSQL database、それでも、メモリ分散キャッシュが提供するパフォーマンスよりも優れたパフォーマンスは提供されません。したがって、私が話していることの多くはまだ必要です。

それでは、実際に何が起こるのかを見て、実際にそれを見てみましょう。スケーラビリティの問題は、実際に問題が発生するまで待ちたくないものです。なぜなら、あなたがアプリケーションを開発していて、今日のパフォーマンスは良好で、XNUMX 人のユーザーにとっては良いことだ、あるいはユーザーの数が何であれ、突然あなたのビジネスが人気になり始めた場合、より多くの顧客がやって来るからです。マーケティング担当者やビジネス部門が良い仕事をしていたときに、突然アプリケーションの速度が低下し始めました。これは、XNUMX 秒ごとに速度が低下し、Web アプリケーションによって収益損失が発生することが調査によって文書化されています。顧客はこれらのオンラインビジネスの多くに属しているため、オンラインビジネスの種類は e コマースビジネス、オンラインストアを持つ小売ビジネスであり、ヘルスケア、電子政府、ソーシャルメディア、オンラインギャンブル、旅行業界などです。消費者と取引を行う必要があるため、多くの企業がオンライン化しています。これらは消費者または数万人であり、通常は一緒にオンラインにアクセスします。また、オンラインは必ずしも Web アプリケーションであるとは限りません。バックエンドと通信するモバイルアプリケーションがある可能性があるため、Web サービスアプリケーションである可能性もあります。

したがって、スケーラビリティの問題が発生するまで待つのは得策ではありません。問題が発生すると、ビジネスに多大なコストがかかることになります。非線形曲線がその時点でサービスを追加しても役に立たないことがわかるように、これらのアプリケーションは速度が低下します。したがって、事前に計画を立てる必要があります。アプリケーションのアーキテクチャが正しく、これを利用していることを確認してください。アプリケーションアーキテクチャに分散キャッシュを組み込むことは、ベストプラクティスとしてほぼ必須のようなものです。

分散キャッシング

では、分散キャッシュはどのように役立つのでしょうか? 使うつもりです NCache ここでの例として、 NCache は、.NET 用のオープンソース分散キャッシュです。これは GitHub で見つけることができます。また、当社の Web サイトでも見つけることができます。また、Enterprise Edition もあります。したがって、お金がない場合、または予算がない場合は、オープンソースを選択してください。オープンソースよりもさらに多くの機能を備えた、よりサポートされているバージョンが必要な場合は、Enterprise を選択してください。それで、私は使用するつもりです NCache 例として挙げていますが、これについて話しているわけではありません NCache。私はキャッシュ全体について話しています。では、分散キャッシュはどのように役立つのでしょうか? さて、次の場合について考えてみましょう NCache XNUMX つ以上のサーバーからなるクラスターを作成するので、ご覧のとおり、キャッシュ層であるこの中間層には XNUMX つのサーバーがあり、ここにあるサーバーの数によっては XNUMX つ以上のサーバーが存在する可能性があります。ここにどれくらいの負荷がありますか？

したがって、分散キャッシュがない場合、データベースは単なるサーバーの XNUMX つであり、リレーショナルデータベースを実際に分散することはできません。つまり、SQL サーバーのリレーショナルデータベースはパフォーマンスの向上に努めています。たとえば、現在はメモリ内にテーブルがあります。 SQL にはデータベースの読み取り専用レプリカもあります。したがって、読み取りは複製できますが、レプリカの問題は、更新するたびに XNUMX か所または XNUMX か所が更新されるため、すべての更新が非常に遅くなるということです。したがって、これを解決する理想的な方法ではありません。分散キャッシュというより良い方法があり、分散キャッシュがスケーラブルである理由は分散という言葉であり、分散できる理由はキーバリューストアであるためです。すべてはキーに基づいて保存されます。キーは複数のパーティションに簡単にハッシュマップでき、すべてのパーティションがサーバーとなり、これが分散を実現する方法です。

したがって、少なくとも 16 つのキャッシュサーバーがあり、一般的な構成ではサーバーあたり約 32 ～ 4 GB のメモリが使用されます。これは、やはりインメモリストアであるため、大量のメモリが必要になるためです。そして、クラスタを形成します。このメモリと CPU をクラスタのリソースとして引き出すのが TCP ベースのクラスタです。つまり、最初は 6 台または 2 台の Web サーバーを備えた Web アプリケーションから始めたとします。つまり、16 台のキャッシュサーバーと、たとえば 32 ～ 80 ギガのメモリを持つことになります。そして今では、ますます使用量が増え始め、20% の時間はキャッシュに保存され、20% は更新のためにデータベースに保存されることになります。実行している更新の数によっては、2% 未満になる場合もあります。一部のデータでは、他のデータよりも多くの更新が行われますが、ここでアプリケーション層にさらにサーバーを追加すると、データベースに対して行ったことと同じことが再び行われることになります。キャッシュ層が最大になります。つまり、サーバーは 8 台しかありません。ここの Web ファーム内の約 XNUMX 台のサーバーに到達したとします。なぜなら、先ほども言ったように、ユーザーが増えれば増えるほど、より多くのアプリケーションサービスが利用できるからです。つまり、これは最大値になります。上限に達するとすぐに、XNUMX 番目のサーバーを追加しました。これらはそれほどハイエンドのサーバーではありません。これらは低コストのサーバーです。

通常、一般的なサーバーは約 8 コアです。 30 ギガバイトを超える RAM を搭載している場合は、16 コアにする必要があります。RAM が増えると、マネージドメモリではないためガベージコレクションが必要になり、より多くの処理能力が必要になるためです。ただし、ほとんどのお客様には、これらの推奨事項はオープンソースにも適用されるため、サーバーあたり 16 ～ 32 ギガの RAM を使用することをお勧めします。本当にハイエンドのいくつかのサービスがサーバーを追加するのではなく、サーバーを追加するだけです。つまり、20,000 台のサーバーが最大になったときに、30,000 台目を追加するだけで同じことが起こります。20,000 台目または XNUMX 台目を追加しても、おそらく最大になることはありません。なぜなら、必要なトランザクション容量が何であれ、たとえば、同時ユーザーが XNUMX ～ XNUMX 人いる場合、これはほとんどの Web アプリケーションのハイエンドに相当します。つまり、それ以上のものはあるかもしれません。おそらく同時ユーザー数が XNUMX 万人を超える可能性がありますが、同時ユーザー数が XNUMX 人であれば、おそらく数百万人が来ることを意味します。毎日ウェブサイトにアクセスします。つまり、私たちはその規模について話しているのです。

このため、突然データベースがボトルネックではなくなりました。アプリケーションのデータをキャッシュする…つまり、これは一般的なキャッシュです。共有キャッシュです。このキャッシュをここに置くと、これはインメモリキャッシュなので、インメモリとは、いずれかのキャッシュサーバーがダウンするとデータが失われることを意味します。つまり、キャッシュはインテリジェントなレプリケーションを提供する必要がありますが、 NCache これは、いずれかのサーバーがダウンした場合に、別のサーバーにそのデータのコピーがあることを確認するためですが、コピーの作成が多すぎると、全体の速度も低下します。それで、 NCache データのコピーを XNUMX つ作成するだけで、パーティションが作成されます。すべてのパーティションは他のサーバーにバックアップを保持しており、XNUMX つのサーバーがダウンするとすぐにパーティションは別のコピーを作成します。そして、共有キャッシュを持つことにより、これらのボックスはステートレスになります。ステートレスとは、アプリケーション層にデータが保存されないことを意味します。

したがって、アプリケーション層がステートレスであるという目標を達成できた場合にすべきことは、干渉を引き起こすことなくアプリケーションサーバーを停止できることを意味します。パッチ、オペレーティングシステムのパッチ、アプリケーションのアップグレードなどを適用する必要があるとします。すべてのデータはデータベースまたはこの層にあるため、簡単にバグが発生する可能性があるため、ここで適用し続けることができるとします。

分散キャッシュの使用例

さて、キャッシングを使用する必要がある理由が確立されましたが、その利点は何でしょうか? どのような問題を解決するのか、またその問題をどのように解決するのか。最初の質問は、何に使うのですか？どのような使用例がありますか? アプリケーション内のどこで分散キャッシュを使用しますか?

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

20 つ目はアプリケーションデータのキャッシュです。これは、すでに説明した使用例です。つまり、アプリケーションデータを含むデータベースがあり、このデータをキャッシュにキャッシュすることで、データベースにアクセスする必要がなくなります。ここで、覚えておくべきことが 80 つあります。これに戻りますが、アプリケーションデータキャッシュでは、データには XNUMX つのコピーがあり、XNUMX つはデータベースであるマスターに、もう XNUMX つはキャッシュにあります。データが XNUMX つの場所に存在する状況では、何が問題になる可能性があるでしょうか? そうですね、XNUMX つのコピーが不整合になったり、同期が取れなくなったりする可能性があります。つまり、キャッシュが古くなっている可能性があります。したがって、キャッシュが変更されても、静的データ、つまり読み取り専用データのみをキャッシュする必要があります。また、読み取り専用データはデータ全体の XNUMX% にすぎず、XNUMX% はトランザクションデータと呼ばれるものです。トランザクションデータをキャッシュできない場合は、そのキャッシュによって制限を受けることになります。 NCache いくつかの非常に強力な機能があり、またすべてオープンソースであり、キャッシュを常に最新の状態に保つのに役立つ非常に強力な機能がすべてあります。それはいいので、その瞬間に行きます。

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

2 番目の使用例は、やはりアプリデータキャッシュが ASP 用であることです。.NET core ASP以外の他のアプリケーションも.NET core、他に少なくとも XNUMX つの用途があります。XNUMX つは、次のような分散キャッシュにセッションを復元できるセッションです。 NCache そのためにプログラミングは必要ないので、非常に迅速に実行できます。アプリケーションのパフォーマンスに関して最も早く利益を得たい場合、アプリケーションがすでにライブであるか、完了しているとします。これは、次のような分散キャッシュ内のセッションの表示を開始するだけです。 NCache。また、プログラミングがないため、必要に応じて実行する必要があるテストはほとんどありません。もちろん、環境内ですべてが機能していることを確認するための基本的な健全性テストは行われますが、開発作業は必要ありません。そのため、これには開発スケジュールやリリーススケジュールは関係ありません。それでは、非常に迅速に。

XNUMXつ目のASP.NET core 特定のキャッシュは、応答キャッシングこれは ASP.NET にあり、以前は ASP では出力キャッシュと呼ばれていました。.NET core 実際、彼らはそれをより標準ベースにしました。したがって、サードパーティのエッジキャッシュソリューションで理解できる HTTP ベースのキャッシュディレクティブが使用されていますが、基本的にはページの出力をキャッシュしているので、次回そのページが呼び出されたときに、出力が同じになるのであれば、なぜそのページを実行する必要があるのでしょうか。なぜ単に出力を提供しないのでしょうか? これは、多くの場合、出力があまり頻繁に変更されない状況では良いのですが、非常に動的なアプリケーションの場合は、おそらくそれほど多くの静的接触は発生しないでしょうが、たとえ短期間であっても、それでも節約になります。それで、ASP.NET core 応答キャッシュにはミドルウェアの概念があり、次のような分散キャッシュをプラグインできます。 NCache 基本的に ASP と同じ層に存在するミドルウェアとして.NET core または、同じですが、ミドルウェアのキャッシュがここにあり、ここが実際の ASP である可能性があります.NET core 応用。これは、分散キャッシュの XNUMX 番目に大きな一般的な使用例であり、これらについてもう少し詳しく説明しますが、概要を示しているだけです。

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

XNUMX 番目のユースケースは、多くの人が知らないことですが、どのようなことができるのか pub/subメッセージング分散キャッシュを使用したイベント。 Pub/Sub メッセージングを使用すると、非同期のイベント駆動型の方法でデータ情報を共有することで、複数のアプリケーションまたはアプリケーションの複数のインスタンスが相互に連携して作業できるようになります。これをリンクできる例にはどのようなものがありますか? マイクロサービス、繰り返しになりますが、マイクロサービスは独立した分離されたサービスですが、連携する必要があります。つまり、あるマイクロサービスが他のマイクロサービスで使用されるものを生成する可能性があり、それがワークフローの実行方法になりますが、相互に直接依存したくないのです。そうしないと、モデル全体が壊れてしまいます。それで、あなたがすることは、これはもはやデータベースのキャッシュではないと実際に考えることです、しかし、これを考えてください、そして私は実際にそうするつもりです.. XNUMX秒待ってください、私はただXNUMX枚の写真のためにそれを回転させます、考えてください分散キャッシュは現在、メッセージングプラットフォームとして機能しています。

つまり、パラダイムシフト全体が起こり、アプリケーションが使えるようになりました。これらは、マイクロサービスまたはその他のアプリケーションを実行する複数の VM またはコンテナーであり、パブリッシュ/サブスクライブ方式で相互に通信できます。つまり、トピックがあり、パブリッシャーとサブスクライバーが存在するため、アプリケーションが非常に簡素化されます。

現在、Rabbit や MSMQ メッセージングキューイングの要件など、他の Pub/Sub ソリューションもあります。次のような分散キャッシュの何が特別なのか NCache? なぜあれではなくこれを使用する必要があるのでしょうか? 分散キャッシュを使用する理由は、分散キャッシュが非常に高速であるためです。それはすべて記憶の中にあります。メッセージキューは永続化され、メッセージを長期間保存するため、メッセージキューが持つすべての機能を備えているわけではありませんが、すべてが同じデータセンター内で実行され、実際にトランザクション環境である場合には、多くの状況でメッセージキューをそれほど長期間保持する必要はありませんが、これをワークフローに使用する場合は、レプリケーションで十分です。すべてのデータが複数のサーバーに保存されているという事実は、メッセージやイベントが失われないようにするには十分です。したがって、データのコピーが XNUMX つあるため問題の性質が異なるアプリケーションデータキャッシュとは異なり、キャッシュを最新の状態に保つ必要があります。 XNUMX 番目と XNUMX 番目のケースでは逆で、データのコピーはキャッシュとして XNUMX つだけ存在します。そのため、キャッシュ内にはレプリケーションの目的で一貫性のあるコピーが複数存在する必要があります。それがないと、メモリ内にあるキャッシュによってデータが失われるためです。したがって、サーバーがダウンしたからといって、メッセージ、セッション、ページ出力を失うことは望ましくありません。したがって、イベントでの Pub/Sub メッセージングは通常、分散キャッシュの非常に強力な使用例であり、これもすべてオープンソースです。

それで、もう一つの機能があります NCache これは連続クエリと呼ばれるもので、実際には他の .NET 空間キャッシュにはありません。一部の Java キャッシュにはこれがあります。また、連続クエリを使用すると、キャッシュ上でクエリの SQL タイプを指定できるため、たとえば select のような言い方ができます。 customer.city がニューヨークの顧客で、この件に興味があるので、このデータセットを監視してもらえないかキャッシュを尋ねているとします。それで。この属性を持つ顧客オブジェクトがキャッシュに追加、更新、またはキャッシュから削除された場合は、通知してください。したがって、すべてのオブジェクトを自分で監視する必要はありません (いずれにせよ不可能です)、またはチェックする必要があるため、キャッシュがそれを実行します。これは、SQL Server が SQL に依存する仕組みと似ています。サーバーにデータセットを監視して、そのデータセットが変更されたときに通知するように依頼できます。ただし、これはテーブル内の XNUMX つ以上の行ですが、ここでは分散キャッシュにあるオブジェクトです。以上が XNUMX つの一般的な使用例です。

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

したがって、最も一般的な使用例はアプリケーションデータのキャッシュだと思います。実際のところ、分散キャッシュという言葉はマイクロソフトのエコシステムを表す言葉です。 Java 側では、インメモリデータグリッドと呼ばれます。私たちはXNUMXつの言葉を使います。私たちは Microsoft エコシステムに属していますが、分散キャッシュを使用し、Java の利点を活かして Web 上のメモリデータグリッドを使用します。したがって、私たちはそれほど多くはなく、分散型インメモリデータストアがあります。したがって、アプリケーションデータキャッシュは分散キャッシュの使用例です。

IDistributedCache インターフェイス

したがって、アプリケーションデータキャッシュを使用する場合は、4 つの方法があります。 IDistributedCache インターフェイスがあり、ASP.NET XNUMX で利用できます。基本的には次のようになります。

非常にシンプルなインターフェース。 Microsoft はついに、その下に分散キャッシュをプラグインできるインターフェイスを提供しました。これの唯一の問題は、非常に単純なことです。したがって、これでは多くのことはできません。本当に基本的なことだけを行うことができます。そして、それが行う唯一のことは、有効期限を与えることです。キャッシュエントリオプションの有効期限を指定できます。あ、はい！ NCache これを実装しているため、IDistributedCache インターフェイスを介してプログラミングしている場合は、プラグインするだけで済みます。 NCache コードを変更せず、さらにコードを変更するだけでプログラミングは完了ですが、これを行うことはお勧めしません。分散キャッシュとその利点を本当に活用するつもりなら、他のすべての機能を理解したいと思うからです。なぜ使用してはいけないのでしょうか? では、それで行きます。

Entity Framework Core Cache

もう XNUMX つは、EF コアを実行している場合で、書きたいコードを最小限に抑えたい場合です。 NCache 現在の EF コア拡張メソッドプロバイダーについては、簡単にお見せしましょう。したがって、EF コア拡張メソッドを使用すると、キャッシュの使用方法が非常に簡素化されます。繰り返しますが、IDistributedCache と同様に、機能はそれほど広範囲ではありません。

たとえば、典型的な EF Core または EF LINQ ベースのクエリを確認したいとします。私たちが行ったことは、ファームキャッシュ拡張メソッドを実装したことであり、他の拡張メソッドもあります。チームの背後にあるときにこのクエリが最初に確認され、キャッシュ内にあると指定するとすぐに実行されます。キャッシュにそれがある場合はキャッシュから取得します。そうでない場合は、データベースにアクセスして取得し、提供される前にキャッシュします。したがって、プログラミングがかなり簡素化されます。それが必要な場合は、EF コアアプリケーションがすでにあり、できるだけ早くプラグインしたいとします。これが最も速い方法です。 NCache ご覧のとおり、そこにこれがあります。

NCache API

XNUMX番目のオプションは使用することです NCache これもかなり単純な API です。 NCache API は ASP.NETcache オブジェクトとほぼ同じに見えますが、それ以上のものを試してみましたが、かなり前に開発されました。 ASP.NET Core は存在するオブジェクトの唯一のインターフェイスなので、できるだけそれに近づけるようにしました。

つまり、これは単純な概念です。キャッシュに接続し、キャッシュハンドルを取得し、cache.get を実行します。インデックスがあるか忘れます。contains を実行でき、Add、insert、remove を実行できます。これらは非同期バージョンであるため、キャッシュが更新されるのを待つ必要はありません。明らかにそれ以上のものがあります。このようにして、キャッシュの使用がいかに簡単であるかを知ることができます。

アプリデータのキャッシュ機能 – キャッシュを最新の状態に保つ

さて、私が一番行きたかったのはこのページでした。はい、キャッシュのコピーが XNUMX つあると言いましたね。キャッシュ自体を最新の状態に保つことができない場合、使用は実際に制限されることになります。それを理解することは非常に重要です。キャッシュは何をするのでしょうか?

有効期限 (絶対 + スライド)

ほとんどのキャッシュには有効期限が設定されています。有効期限は TTL (Time to Live) とも呼ばれます。ASP.NET キャッシュオブジェクトでこの用語が使用されるため、絶対有効期限と呼びます。そのため、そのまま使用します。それは何をするためのものか？キャッシュにオブジェクトを追加していますが、その期間キャッシュしても安全だと思うので、今から 10 分後か XNUMX 分後に期限切れにしてくださいと言っているのです。あなたは経験に基づいた推測を行っていますが、一部の参照データのケースでは問題ありません。たとえば、製品カタログがあるとします。おそらくXNUMX分ごとに変化することはありません。そこでは価格が変わることはありません。したがって、状況によっては、より予測可能な変化が得られます。したがって、そこで表現を使用しても問題ありません。ただし、顧客またはアクティビティをキャッシュしている場合、顧客が電話して変更を加えるため、いつ変更されるかわかりません。そのため、有効期限だけでは対処できない可能性があります。したがって、ここはキャッシュ内の他の機能が必要な場所であり、これらすべての機能がキャッシュにある場所です。 NCache オープンソースとして。

キャッシュをデータベースと同期する

特徴の一つが、 NCache データベースと同期できます。ポーリングの場合、データベースは SQL Server、Oracle、または OLEdb になる可能性がありますが、同期とは次のことを意味します。 NCache がクライアントになると、キャッシュサーバーがデータベースのクライアントになります。これで、先ほど話した SQL 依存関係が使用されます。連続クエリと同じですが、SQL サーバーの場合です。 SQL 依存関係を使用します。それがどのように機能するかを説明します。

つまり、追加するときに、この製品オブジェクトをキャッシュに追加して、キーを取得し、製品を含むキャッシュアイテムを取得するとします。ここで行うことは、製品テーブル内の特定の製品を識別する SQL ステートメントを指定することです。この SQL ステートメントも SQL サーバー用です。イベントキャッシュを渡すと、 NCache それを SQL サーバーに渡します。 NCache、この製品をキャッシュするときに、SQL サーバーのレジスタに SQL 依存関係を通知し、マッピングを保持するようになりました。したがって、SQL サーバーがイベントを送信すると、 NCache この製品は現在データベースで更新されていると表示されます NCache それがまだキャッシュにあることを知っています。つまり、XNUMX つのうちの XNUMX つを実行します。キャッシュから削除するだけです。つまり、アプリケーションは何もする必要がなく、すべてキャッシュによって行われます。または、リードスルーと呼ばれるこの機能を実装している場合は、アイテムが自動的にリロードされます。それでは、データベースについては少し後で説明します。したがって、データベース同期は非常に強力な機能です。安心してすべてのデータをキャッシュできます。これがないと、探索のみを行う場合は制限があり、キャッシングについて基本的な方法を知っている一般的な人と話すと、キャッシングに対して「ああ、それは読み取り専用データだ」という反応が返ってくるほどです。キャッシュは静的データのみを対象とします。誰もがトランザクションデータに触れるのを恐れています。それはこれらの理由によるものです。有効期限は経験に基づいた推測にすぎず、製品カタログなどのより予測可能なケースには有効かもしれませんが、トランザクションデータには無効です。

キャッシュを非リレーショナルと同期する

したがって、非リレーショナルデータストアがある場合も同じ問題が発生します。それはクラウド内の何かである可能性もあれば、レガシーデータベースである可能性もあれば、メインフレームである可能性もあります。 SQL 依存関係と同じ目標を達成できますが、その場合はその通知に含まれていません。カスタム依存関係は、ユーザーが実装するものです。これはサーバー側のコードであるため、あなたのコードです NCache にはサーバーサイドコードという概念があります。ユーザーが作成したコードはキャッシュサーバー上に存在します。

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

カスタム依存関係が XNUMX つ、リードスルーライトスルーが XNUMX つです。先ほどリードスルーについて話しましたが、データベース同期中であれば、アイテムを削除した場合に、そのアイテムをリロードできるということです。 NCache 行ってリロードできます。どうすればリロードできるのでしょうか？ただし、読み取りコードです。既読スルーとは何ですか? 行ったり来たりしているように見えますが、これらの .s を接続したかったのはそのためです。どうすれば…書き込みと読み取りスルーは単なる単純なインターフェイスなので、ここには読み取りスルーインターフェイスがあります。はい、データソースに接続できる Init という XNUMX つの方法があります。 Dispose は切断であり、LoadFromSource のオーバーロードすぎます。したがって、LoadFromSource はキーであり、キャッシュ項目を返します。LoadFromSource には辞書を返すことができるオーバーロードがあります。つまり、LoadFromSource は次のようなものです。 NCache は、リードスルーハンドラーを呼び出します。

したがって、アプリケーションが Cache.Get を実行し、そのアイテムがキャッシュにないので、次のように伝えたとします。 NCache キャッシュにない場合は、リードスルーハンドラーに問い合わせてください。 NCache リードスルーハンドラーはキャッシュクラスター内に存在するコードであるため、リードスルーハンドラーを呼び出します。 NCache このメソッドを呼び出します。このメソッドはコードであり、データベース、データソース (SQL またはメインフレームなど) に移動し、データを取得して配置します。今 NCache データベースにアクセスする機能があるということは、自動リロードができることを意味します。つまり、それは便利な部分です。したがって、リレーショナルデータベースおよび非リレーショナルデータベースと同期できます。

リレーショナルデータのキャッシュ

最後はリレーショナルデータのキャッシュです。データアプリケーションを使用して帳簿を作成し、あるデータと他のデータとの関係を追跡する必要があります。複数の注文がある顧客の例を示します。通常、顧客を削除しませんが、削除した場合、キャッシュはそれを認識しないので、キャッシュから顧客オブジェクトを削除し、キャッシュ内に XNUMX 件の注文があった場合、それらの注文は削除されません。有効期間が長くなると、キャッシュに保持すべきではありません。したがって、XNUMX 対多の場合は、通常、多は XNUMX に依存するため、キャッシュから XNUMX つを削除する場合は、キャッシュから多くも削除する必要があります。今では、XNUMX つ削除するたびに、多くの情報を削除しに行く必要があり、それを追跡する必要があります。したがって、代わりにできることは、ASP.NET キャッシュオブジェクトに依存関係の概念が関連付けられていることです。 NCache これを実装すると、これら XNUMX つを関連付けることができ、顧客オブジェクトが更新または移動されると、すべての注文が自動的に削除されます。

キャッシュの依存関係は、多すぎる場合、XNUMX 対 XNUMX の場合、またコレクションをキャッシュして個々のオブジェクトを個別に保存したい場合にも使用できます。つまり、顧客のコレクションには XNUMX つのオブジェクトとしてキャッシュされており、一部の顧客も個別にキャッシュされていました。キャッシュ内に複数のコピーを保持できるためです。すべてはアプリケーションによって保持されます。したがって、正規化とデータ整合性が必要なデータベースとは異なり、キャッシュはパフォーマンスがすべてであるため、複数のコピーを持つことができます。複数のコピーがあり、XNUMX つのコピーが更新されたときにクリーンアップできるようにする必要がある場合、このキャッシュの依存関係によってそれが可能になります。以上が、キャッシュを最新の状態に保つ XNUMX つの方法です。これらはすべて、以下の一部として利用可能です NCache open source.

アプリデータのキャッシュ機能 - リードスルーとライトスルー

リードスルー、ライトスルーを再度実行しました。ライトスルーはリードスルーと同じですが、キャッシュを更新するときにキャッシュにデータベースを更新するよう要求する点が異なります。

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

したがって、リードスルーとは、キャッシュを読み取るときに、データがない場合に備えてデータベースから読み取るようにキャッシュに要求することです。リードスルーとライトスルーにより、永続化コードを XNUMX つのキャッシュ層に統合できるようになりました。そして、キャッシュがデータベースをより認識できるようになり、アプリケーションはますますシンプルになります。

後書き

ライトスルーには、データベースを更新するたびにライトビハインドと呼ばれる追加の利点もあります。つまり、アプリケーションで最も遅い操作はデータベースの更新です。データベースからデータをフェッチするよりもさらに遅くなります。データのフェッチにキャッシュを使用している場合は、データベースにあまりアクセスする必要がありません。データの機密性がそれほど高くない場合、更新されたデータにキャッシュを使用しないのはなぜでしょうか。これは、非同期更新のためにキューに入れることができることを意味します。データの機密性が非常に高い場合は、明らかに非同期更新のキューに入れたくありませんが、多くのデータは非同期更新のキューに入れることができます。それをキューに入れて、基本的に後書き機能を実行するときは、次のように尋ねます。 NCache 非同期方式でデータベースに書き込むと、キューが構築されるか複数の更新リクエストが発生すると、そのキューが複数のサーバーにレプリケートされるため、サーバーがダウンした場合でも道に迷うことはありません。また、アプリケーションはデータベースの更新を待つ必要がなくなるため、確実に高速化されます。したがって、ライトスルーにはパフォーマンス上の利点があります。そして、後ろに書いてください。既読スルーにはあらゆる利点があります。

アイテムの自動リロード

有効期限を設定して自動リロードすることもできます。したがって、有効期限が切れたら、そのアイテムを自動的にリロードできます。基本的に、有効期限はデータベースサーバーで変更される可能性があります。キャッシュ内ではもう有効ではないので、削除はしません。どうせ必要になるのでロードしないのはなぜでしょうか。それから、それはおそらくある種の検索データなので、自動的に読み取られます。繰り返しますが、キャッシュはアプリケーションからその作業をどんどん引き継ぎます。

アプリデータのキャッシュ機能 - データのグループ化

キャッシュを最新の状態に保つことができ、自信が持てるようになったら、今度は大量のデータをキャッシュし始めます。大量のデータをキャッシュし始めるとき、このキーと値のペアを超えてデータを検索できれば非常に便利です。昨日の夜、ある人と話したところ、さまざまな種類のデータを見つけるためにキーをフォーマットする方法について真剣に考え出す必要がありました。これはあなたがする必要のないことです NCache。グループ、サブグループ、タグ、名前付きタグと呼ばれるこれらのメタタグを割り当てることができます。これは、キーの名前を変更する代わりにオブジェクトに割り当てることができるメタデータです。これらはより良いデータである可能性があり、それに基づいて、このタグ、これらの XNUMX つのタグ、またはこれらの XNUMX つのタグが付いているものをすべてください、またはこのグループに属するものをすべてくださいと言うことができます。それは XNUMX つです。

次に、SQL クエリを実行できます。それをお見せしましょう。したがって、やはり、キャッシュはますますデータベースのように見え始めます。

したがって、たとえば、この名前を持つすべての製品を選択すると、製品オブジェクトの属性に基づいて検索を実行できるようになります。これでたくさんの NCache SQL Server と同じように、execute.reader を実行するコードです。これは非常によく似ており、Icache リーダーを取得して、それを通して自分の内容を確認するだけです。さて、これはまた、必要なときにキャッシュを実行させるものです。一方で、大量のデータをキャッシュに保存すると、次にキャッシュからデータを検索できるようになります。

ASP.NET Core セッションストレージ

ASPについてお話しました.NET core セッション。覚えておくべき重要なことは、XNUMX つの使用方法があるということです。

I分散キャッシュストレージ

XNUMX つはプラグインすることです NCache. NCache IDistributedCache プロバイダーを実装しました。それで、プラグインします NCache IDistributedCache プロバイダーおよび ASP として.NET core セッションの保存が自動的に開始されます NCache。ここにあるかどうか見てください。

たとえば、これが ASP です。.NET Core アプリケーションでは、サービスの設定に移動して追加するだけです NCache IDistributedCache プロバイダーとして、現在は通常の ASP を使用しています.NET core プロバイダーが現在接続されていることがわかっているため、IDistributedCache に依存することがわかっているセッション。したがって、これを実行すると、すべてのセッションが次の場所に保存されます。 NCache。そして、キャッシングがどのようなものかを説明します。実際のデモをお届けします NCache。それは一つの方法です。

NCache セッションプロバイダー

XNUMX 番目の方法は、実際に使用することです NCache セッション自体の独自のプロバイダーとして機能するため、IDistributedCache に移動する代わりに、同じサービスの構成に入り、追加すると言います。 NCache セッションプロバイダー。

現在、このセッションプロバイダーには、通常の IDistributedCache よりも多くの機能があります。より多くのセッション固有の機能があります。つまり、使用することをお勧めします NCache IDistributedCache との相性が良い独自のセッションプロバイダーを使用します。ただし、ASP の両方のオプションに進むことができます。.NET core これを提供します。先ほども述べたように、これにはコードの変更以外には何も必要ありません。それで全部です。それ以外はすべて自動です。したがって、次のような分散キャッシュの恩恵を受ける場合は、 NCache、これをアプリケーションのエントリポイントとして接続します。アプリケーションのデータキャッシュのオブジェクトキャッシュにはプログラミングが必要ですが、開発スケジュールに適合し、これよりも少し長いプロセスが必要となるため、今日この恩恵を受ける必要があります。しかし、これは非常に迅速に行われ、私はすでにこれを知っています。

ASP.NET Core 応答キャッシング

そして、これは設定なので、もう一度説明します。同じ方法で応答キャッシュが分散キャッシュを使用し、プラグインすることができます。 NCache そうすれば、自動的に機能します。

分散キャッシュのアーキテクチャ要件

いくつかの点について簡単に説明しましょう NCache しましょう。

高可用性

分散キャッシュはデータベースのようなもので、アプリケーションとともに本番環境に存在します。したがって、そのアーキテクチャが柔軟で可用性が高いことを確認する必要があります。

たとえば、 NCache ピアツーピアアーキテクチャを持っていますが、他のタイプの Redis ありません。したがって、マスタースレーブを持つ代わりに、ピアツーピアが必要になります。先ほども述べたように、メモリデータグリッド内で呼び出される Java キャッシュの多くはピアツーピアアーキテクチャを備えています。ピアツーピアの良い点は、全員がピアであるため、どのノードがダウンしても何も起こらないことです。おそらくマスタースレーブはスレーブがマスターになることはできません。マスターが死んでも、スレーブはスレーブのままです。そのため、回復するには手動による介入が必要になります。ピアツーピアの場合は自動で復旧します。したがって、ピアツーピアにより、いわゆる自己修復動的クラスターが自動的に調整されます。それが最初の側面です。

線形スケーラビリティレプリケーション

XNUMX 番目の側面は、パーティショニングである線形スケーラビリティであり、やはりパーティションの動的な調整による線形スケーラビリティです。

物事 NCache 自動的に行われるのは、たとえば、XNUMX つのサーバー構成があり、その XNUMX つのパーティションを合計したい場合に、XNUMX 番目のサーバーを追加して、XNUMX 番目のパーティションが追加されるとします。 NCache 自動的に、から行くとしましょう。ここに XNUMX つのパーティションを持つ XNUMX つのサーバーがあるとします。別のサーバーおよびパーティションへのバックアップとしてのすべてのパーティションは、本質的にハッシュマップが分散されたバケットのコレクションです。

したがって、1,000 個のバケットがあり、500 個がパーティション 1 に、500 個がワールドパーティション 2 に入り、すべてが正常に動作している場合、XNUMX 番目のサーバーを追加するとします。もう一度、XNUMX 番目のサーバーを追加することで XNUMX つのパーティションを持つことができるため、 NCache アプリケーションの実行中にバックグラウンドで自動的に実行され、1 番目のパーティションが作成され、パーティション 2 と 3 のデータの一部が 2 番目のパーティションに移動されます。もう一度、XNUMX分のXNUMX、XNUMX分のXNUMX、XNUMX分のXNUMX。つまり、バケットは実際に動き、すべてが動的に起こります。バケットが移動すると、レプリカも再調整されますが、レプリカ XNUMX とレプリカ XNUMX は以前と同じレプリカではなくなり、すぐにデータが減り、レプリカ XNUMX と呼ばれる新しいレプリカが作成されます。レプリカ XNUMX を持っていたサーバーはレプリカ XNUMX ではなくなり、XNUMX つになり、XNUMX 番目のサーバーにレプリカ XNUMX が作成されます。これはすべて自動的に行われます。

つまり、そのダイナミズムが高可用性を実現しているのです。したがって、サーバーを追加するときは手動介入が必要ですが、それは実際に行う必要があります... したがって、そのまま実行できるのであれば、それでも非常に便利です。文字通り、「追加」と言うだけですべてが行われます。ただし、サーバーのクラッシュが原因でドロップが発生する可能性もあるため、サーバーを削除する場合はさらに重要です。つまり、3 サーバー構成の場合、つまりサーバー 3 がダウンし、パーティション XNUMX が失われるということになります。 NCache レプリカ 3 にはパーティション 1 のコピーがあるため、レプリカ 2 がすぐにアクティブになります。つまり、一時的にパーティション 3、パーティション 3、およびパーティション XNUMX であるレプリカ XNUMX が作成されます。したがって、中断はありません。それが完了したら、 NCache ここで、サーバーが 3 台のみであることに気付き、パーティションは 1 つしか持てません。レプリカ 2 をパーティション 2 と XNUMX に一度にマージし、マージが完了すると、この場所にレプリカ XNUMX が作成されます。それで、この写真に戻ることができます。

さて、これは他のファッションでは自動的にはできないことです。これが意味するのは、このようなことが起こり、中間のものが故障した場合、IT 部門の担当者が手動で再調整する必要があり、それが起こるまでは XNUMX つのキャッシュといわゆる機能制限が必要になるということです。 NCache それは自動的に行われます。したがって、高可用性が実際にキャッシュ内に存在することを確認する必要があります。

クライアントキャッシュ

InProc の速度についてはすでに説明しました。

WAN レプリケーション

もう XNUMX つの機能があり、これは Enterprise Edition の機能です。つまり、複数のデータセンターがあり、多くのアプリケーションがそこに移動されている場合、クラウドのおかげで複数のリージョンにアプリケーションをデプロイすることが容易になります。

したがって、アプリケーションが複数のデータセンターにある場合、キャッシュも複数にレプリケートする必要がある場合があります。また、待ち時間が長いため、実際にはクラスター全体を複数のリージョンにまたがらせることはできません。つまり、クラスター内にクラスターを XNUMX つにまとめ、その間に非同期レプリケーションを行うブリッジが存在します。したがって、これはアクティブ/アクティブの双方向レプリケーションのケースであり、両方の場所で同じキーが更新されるため、ブリッジが競合解決を行います。これで、それを追跡できるようになりました。

NCache デモ

早速お見せしましょう NCache のように見える。 Azure を入手したので、基本的に調達またはプロビジョニングは完了しました。ポータルさえ入手できれば、それは完了です。それで、私は…本当に遅いです。来て！ XNUMXつ取って、はい、わかりました！これには XNUMX つの VM があり、そのうちの XNUMX つにログインしています。つまり、基本的に XNUMX つのキャッシュサーバーがあり、すべて Windows、XNUMX つのキャッシュクライアントは Windows、XNUMX つのキャッシュクライアントは Linux です。それはだから .NET core、全部できるよ。キャッシュサーバーも生きている可能性がありますが、 NCache 私が言ったように .net core 私たちの Web サイトにアクセスしたら、好みに応じて .msi または Tar.gz を実際にダウンロードできます。 Windows または Linux をインストールできます。実はここからもオープンソースをダウンロードできます。私たちの企業はオープンソースの上に構築されているため、私たちはオープンソースの所有者であり、企業の所有者でもあります。

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

それでは、早速ですが、申し訳ありませんが、2 ノードキャッシュクラスターを作成します。繰り返しますが、このツールはオープンソースではありませんが、これらすべてのことはオープンソースで実行できます。ただ、それほど美しくありません。実際、これは今後 Web ベースのツールになる予定です。それでは、先に進みます。これが私の最初のキャッシュサーバーです。これは私の 10.0.0.7 番目のキャッシュサーバーです。そこで、XNUMX つのサーバーキャッシュクラスターを実行することにします。他のすべてのデフォルトをそのまま使用します。先に進んで XNUMX つのクライアントを追加します。XNUMX つは Windows クライアントである私自身で、もう XNUMX つは XNUMX クライアントと Linux クライアントを追加します。キャッシュを開始しましょう。これは、キャッシュの作成と構成がどれほど迅速であるかを意味します。

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

これについて最初の統計を開始します。 NCache ストレステストツールと呼ばれるこのプログラムが付属しており、負荷をシミュレートできます。 NCache。つまり、プログラムのようなものです。独自に入力を取得します。ここで PowerShell を開いたので、test-stress を実行し、ここで指定したキャッシュ名を入力し、ここに書き込みます。今、このボックスが表示されています。これが最初のボックスです。それで、クライアントボックスに行くので、これを実行するだけですが、ここで突然アクティビティが開始されるのがわかります。つまり、現在、ボックスごとに 500 秒あたり約 XNUMX 回の操作を行っています。それで、負荷を増やしたいとします。その方法をテストしたいとします。 NCache 私の環境では実行されるので、同じボックス上で同じインスタンスを別のインスタンスで起動します。突然、負荷がほぼ 60 倍になり、Linux ボックスが XNUMX つになったことがわかります。ご覧のとおり、ここが Linux、これがです。ここにあるセブンボックス。そこで、ここでまず PowerShell を起動します。このモジュールをすぐにコピーして、同じストレステストのデモキャッシュを実行します。これを実行するとすぐに、これが突然約 XNUMX パーセントまで上昇したことがわかります。 XNUMX歳になる…

したがって、これを行うたびに、ボックスごとに 500 秒あたり約 XNUMX の操作が追加されることになります。もう XNUMX つやって、それで終わります。追加します…つまり、負荷が最大になり始めるまで、どんどん負荷を追加し続けて、それから XNUMX 番目のサーバーを追加します。そしてもちろん、さらにクライアントを追加する必要もあります。これらはすべて、サードパーティのツールでも簡単に監視できる perf-mon です。これはとてもシンプルです。これらは追加するキャッシュされたアイテムです。

当社の Web サイトからオープンソースをダウンロードできます。オープンソースは利用可能ですが、オープンソースをダウンロードするための MSI インストーラーもあります。したがって、オープンソースを使用するか、サポート環境で使用することに本当に確信がある場合は、すぐにエンタープライズをダウンロードしてください。たとえば、私がオープンソースに移行し、インストーラーをダウンロードできるようにすると、ソースコードに対して料金を請求される必要がなくなります。繰り返しになりますが、ソースコードはすべて GitHub にあります。