NCache アーキテクチャ
録画番組
ロン・フセイン、ザック・カーン著
今日のウェビナーは以下に基づいて行われます NCache アーキテクチャさあ、分散キャッシングの概要と、それが.NETおよび.NET Coreにおけるボトルネックをどのように解決するかについて説明します。一般的なユースケース、分散キャッシュのアーキテクチャ、クラスタリングの詳細、そして、分散キャッシュだけでなく、分散キャッシュに関するあらゆる疑問にもお答えします。 NCacheですが、キャッシュ全般についてです。このウェビナー中はいつでも、GoToWebinarの質問タブからご質問いただけますので、ご都合の良いときに質問タブをご利用ください。ご質問をご記入いただければ、プレゼンテーション中にRonまたは私がお答えいたします。セッションの最後に少し時間を設けておりますので、ご質問にお答えいたします。皆様と楽しい時間を過ごせることを楽しみにしております。
では、これ以上長々と話さずに、ロンにバトンタッチして、始めましょう。とても良かったです。ありがとう、ザック。さて、皆さん、ザックが先ほど言ったように、今日のトピックは NCache このウェビナーでは、建築の仕組みについて詳しく説明します。 NCache クラスタリングの仕組み、選択できる最も一般的なトポロジ、そしてクラスタリングの主な利点の1つは何ですか？ NCache アプリケーションのユースケースについて。どのようなユースケースがあり、どのように最大限に活用できるのか？ NCache サーバー アプリケーション内では?
皆さん、私の画面が見えていると思います。確認が取れ次第、すぐに作業に取り掛かります。ええ、皆さんが確認できれば、これで大丈夫だと思います。これでいいと思います。はい、良さそうです。完璧です。では、早速始めましょう。
スケーラビリティの問題
まず最初に定義しましょう NCache では、スケーラビリティ問題とは何か、そしてどのように NCache スケーラビリティの問題を解決できます。アプリケーションがデプロイされる一般的なサーバーアーキテクチャでは、アプリケーションがデプロイされているかどうかに関わらず、通常、複数のインスタンスまたは複数のサーバーが使用されます。つまり、アプリケーション層は非常にスケーラブルであると言えます。
アプリケーション層には、サーバーをいくつでも追加できます。複数のアプリケーションサーバーまたはWebサーバーが同じアプリケーションをホストし、チームとして連携してリクエスト負荷を分散するWebフォームやアプリフォームを構築できます。さらに、マイクロサービスアーキテクチャなどの新しいアーキテクチャに移行すれば、より多くの計算処理能力やリクエスト処理能力を必要とするアプリケーションサービス、つまりマイクロサービスを個別にスケーリングできるようになります。
アプリケーション層は非常にスケーラブルです。線形に拡張可能です。規模が大きくなるにつれて、より多くのリクエスト負荷を処理できるようになります。問題は、リレーショナルデータベースなどのデータベースを扱う際に発生します。なぜなら、これらのアプリケーションは、スケーラビリティのレベルに関わらず、常にバックエンドデータベースと通信する必要があるからです。そして、バックエンドデータベースと通信する場合、通常は単一のソースです。これはあまりスケーラブルではありません。ストレージには非常に適しており、多くのディスクリソースを利用できます。そのため、ストレージのメリットを享受できます。しかし、アプリケーションに膨大なトランザクション負荷がかかり、それがデータベースのトランザクション負荷にも反映されると、データベースはダウンする傾向があります。そして、これがアプリケーションがリクエスト処理に苦労するという主な問題です。スケーラブルではなく、エンドユーザーエクスペリエンスも損なわれます。
NoSQLデータベースは、この問題をある程度解決してくれます。SQLデータベースを使うこともできますが、そのためにはアプリケーションを再設計し、リレーショナルデータベースの使用をやめてNoSQLデータベースを使うようにする必要があり、それは大規模なプロジェクトになります。したがって、NoSQLは必ずしもスケーラビリティの問題に対する解決策になるとは限りません。
ソリューション： NCache 分散キャッシュ
では、このような状況になったらどうすればいいのでしょうか？解決策は非常にシンプルです。メモリ内に分散キャッシュを構築すればいいのです。 NCacheまず、インメモリなので、アプリケーションのパフォーマンスが向上するという最大のメリットがあります。リレーショナルデータベースと比較して非常に高速です。そして、最大のメリットは、線形にスケーラブルであることです。通常、単一のソースを持つデータベースサーバーとは異なります。 NCache 複数のサーバーに配置できます。 キャッシュクラスター 複数のマシンで実行できます。ご存じのとおり、要件やニーズが拡大し、アプリケーション層で処理するリクエスト処理能力がさらに必要になった場合は、実行時にキャッシュクラスターにサーバーを追加できます。
についての良いこと NCache リレーショナルデータベースやバックエンドデータベースに加えて使用するものであり、従来のデータソースを置き換えるものではありません。既存のデータソースを補完することで、アプリケーションのパフォーマンスを向上させます。アプリケーションのリクエスト処理能力を高めることができます。また、アプリケーション側の拡張に合わせて、キャッシュクラスタ内のサーバ数を増やすことができます。これらのサーバはクラスタ内のサーバであるため、チームとして動作します。リクエスト負荷をサーバ間で分散することで、結果として線形なスケーラビリティを実現します。つまり、 NCache 線形にスケーラブルなモデルであり、非常に使いやすいです。デプロイメントアーキテクチャの仕組みについて説明しましょう。典型的な大規模な本番環境では、次のように動作します。 NCache 次のようになります:
多数のサーバーが必要になります。WindowsまたはLinuxのサービスで、以下のような設計になっています。 NCache アプリケーションとデータベースの間に配置されます。例えば、2つか3つの NCache サーバーを4台か5台に増やすことができます NCache サーバーや、さまざまな種類のアプリケーション（例えば、ASP.NETやASP.NET CoreのWebアプリケーション、.NETや.NET Coreのサービス、.NET/.NET Coreのサーバーアプリケーションなど）が対象となります。JavaやNode.jsで開発されたアプリケーションも、分散キャッシュのメリットを享受できます。
NCache それ自体は.NET/.NET Coreで記述されています。WindowsだけでなくLinuxマシンでも動作します。同様に、アプリケーションはどのプラットフォームでも問題なく動作します。通常、私たちは次のことをお勧めします。 NCache 専用のセットアップサーバーで、 NCache、リソースを専用に確保できるように NCacheそして、アプリケーションサーバーは別の層に配置されます。そのため、アプリケーション専用のリソースも確保できます。また、小規模な構成の場合は、別の展開オプションもあります。 NCache アプリケーションが動作している同じマシン上で動作している。つまり、常にその可能性が存在します。 NCacheしかし、前述の通り、推奨される選択肢は、図に示すように、独立したキャッシュ層を設けることです。そして、 NCache アプリケーションとデータベースの間に位置します。ここでの考え方は、アプリケーション内で最も頻繁に使用するデータをキャッシュすることです。参照データでもトランザクションデータでも構いません。「参照」とは、読み取り中心のデータ、「トランザクション」とは、読み取りと書き込みの両方が中心のデータを指します。キャッシュするデータが分かれば、そのデータを「ワーキングセット」と呼ぶことができます。初めてデータベースからそのデータを取得できるようになり、その後、データベースに追加することもできます。 NCache その後の通話は、 NCache データベースへのコストのかかるアクセスを省くだけです。これは一般的に「キャッシュアサイド」パターンと呼ばれ、変更内容はすべてキャッシュにも反映され、その後データベースにも反映されます。また、データベースがキャッシュに存在しない場合は、常にデータベースから取得してキャッシュ内に保持します。 NCache ただし、常に最初にキャッシュをチェックします。そのため、キャッシュ内でデータが見つかった場合は、データベースにアクセスする必要がなく、その時点から戻ります。
リードスルー / ライトスルー
これに代わるアプローチは、ここで点線で表されている「リードスルー」または「ライトスルー」を使用することです。 NCache これを自動化する機能があり、「キャッシュスルー」オプションが提供されます。これは、読み取りの場合は「リードスルー」、書き込みの場合は「ライトスルー」と呼ばれます。これは、常にキャッシュをメインソースとして使用し、キャッシュにリードスルー/ライトスルーハンドラを実装することで、バックエンドデータソースの更新を担当します。そのため、どのような読み取り操作を実行しても、データが存在しない場合は、プロバイダーに基づいてデータベースにシームレスにアクセスし、アプリケーション用にデータを取得し、アプリケーションに返して内部に保存します。 NCache更新の場合、アプリケーションから呼び出したモデルに応じて、同期または非同期のアプローチでキャッシュとデータベースが更新されます。
リードスルー、ライトスルー、キャッシュパターンについてさらに詳しく説明しますが、大まかな展開のイメージとしては、次のようになります。 NCache サーバーフォームに展開され、複数のアプリケーションまたはアプリケーションフォームに接続できます。 NCache そして、分散キャッシュを活用できるようになります。分散キャッシュでは、インメモリアクセスによってアプリケーションのパフォーマンスが向上します。また、キャッシュ層に複数のサーバーを配置することで、線形スケーラビリティを実現できます。ご説明が明確になったかと思います。ご質問があればお気軽にお寄せください。幸いなことに、今のところご質問はないようですので、ご自由に続けてください。ありがとうございます。
NCache スケーラビリティの数値
では次に、 NCacheのスケーラビリティの数値についてお話ししました NCache アプリケーションのスケーラビリティの問題を解決できます。つまり、 NCache それ自体は線形にスケーラブルです。アプリケーション層がスケーラブルであること、そしてデータベースのボトルネックが線形にスケーラブルなモデルによって解決されていることを踏まえ、参考となる数値をいくつかご紹介します。これらはQA環境で実施したベンチマークテストの結果です。CPUとRAMの性能が高いサーバーを使用し、高負荷状況でも十分に活用できるようにしました。最初は1台のサーバーから始め、2台のサーバーでアプリケーションの負荷を高めていきました。そして、一部のサーバーでCPUとRAMの容量が限界に達した時点で、サーバーをもう1台追加しました。
これが経験則です。既存のキャッシュサーバーを使い続ける場合は、2つから始めます。 NCache サーバーがあり、その 1 台のサーバーのハードウェア容量が限界に達している場合、CPU が限界に達している場合、または RAM が限界に達している場合は、スケール アウトして、キャッシュ クラスターに 2 台目のサーバーを追加する必要があるという選択をする時点です。これは、平均 1 キロバイトのオブジェクト サイズで行ったこととまったく同じで、アプリケーションの負荷を増やし続け、サーバーの数を増やし続けました。指定されたサーバーのセットが限界に達するまでです。これは一時的なデータではなく、実際のアプリケーション データですが、QA ラボでシミュレートされました。そのため、サーバーを XNUMX 台、XNUMX 台、XNUMX 台、XNUMX 台、最大 XNUMX 台のサーバーに増やすと、平均 XNUMX キロバイトのオブジェクト サイズで XNUMX 秒あたり XNUMX 万件のリクエストを処理できるようになりました。
つまり、キャッシュへの読み込みと書き込みを一貫して組み合わせることで、全体として毎秒2万リクエストのスループットを達成しました。しかも、パフォーマンスを犠牲にすることなく実現しています。つまり、スループットとは、毎秒のリクエスト数が多いことだけでなく、個々のリクエストのレイテンシも維持し、超高速である必要があるということです。このデモ動画とホワイトペーパーは、当社のウェブサイト（ここをクリック）。そして、それはあなたが見直すこともできるものです。
分散キャッシュの一般的な使用法
さて、一般的な使用例をいくつかお話しましょう NCache.
-
アプリのデータキャッシュ
最も多い使用例はアプリケーションデータのキャッシュです。 アプリのデータキャッシュこれはバックエンドデータベースから取得されるデータです。データベースはディスクベースであるため、一般的に速度が遅いことは既に述べました。これに対し、RAMはより高速なソースです。もう一つの問題は、データベースはトラフィック量が多いと処理能力が低下する傾向があることです。トランザクション負荷が高く、サーバーが1台しかない場合、アプリケーション側で必要なパフォーマンスが得られないことが予想されます。そのため、アプリケーション内でアプリケーションデータをキャッシュすることは非常に理にかなっています。 NCache非常に簡単です。 NCache APIを使ってキャッシュを呼び出すだけです。キャッシュ初期化APIを呼び出すことでキャッシュに接続します。キャッシュに接続したら、「キャッシュ.追加、キャッシュ.更新、キャッシュ.削除'または'キャッシュ.取得' を使ってキャッシュからデータを取得します。最後にいくつか例を挙げます。ここでの考え方は、参照データであれトランザクションデータであれ、複数回読み取る可能性のあるデータであれば何でも良いということです。参照データの場合、 NCache 変更を取得するためにデータベースに戻る必要がないため、大きな価値が追加されます。
分散キャッシュの一般的な使用法 そうです、キャッシュ内のデータはより長期間使用可能になります。そして、データを使用している間、 NCacheバックエンドデータベースにアクセスする必要がなくなります。これによりアプリケーションのパフォーマンスが向上します。また、スケーラビリティも向上します。 NCache 比較するとスケーラブルです。
参照データをすべてキャッシュするのは非常に直感的ですが、トランザクションデータの一部、あるいは大部分をキャッシュすることもお勧めします。私たちの経験上、複数回読み取るデータ、たとえ2～3回読み取るデータであっても、キャッシュすることをお勧めします。なぜなら、データベース内で変更が行われ、その後も複数回（2～3回）読み取る場合は、そのデータをキャッシュしておくことが非常に理にかなっているからです。そうすることで、バックエンドデータベースにアクセスする必要がなくなります。また、次のような機能が組み込まれています。 NCache これにより、データベースとの100%の同期も実現できます。これは常に考慮すべき点です。
ロン、ちょっとした質問が来ました。主に次のような内容です。
クラスター化されたキャッシュには常にネットワーク経由でアクセスする必要がありますか？ネットワークの問題でアプリケーションが動作しなくなるのではないかと心配です。一部のデータをローカルで管理する方法はありますか？通常、デフォルトの展開では、 NCache 別々の箱に、そしてアプリケーションも別々の箱に入っていますよね？ NCache TCPプロトコルに基づいているため、ネットワーク呼び出しとなります。「クライアントキャッシュ」と呼ばれる機能があり、これはアプリケーションマシン上に存在するローカルキャッシュです。また、より多くのパフォーマンスが必要で、ネットワークによる遅延を一切避けたい場合は、「インプロセス」にすることもできます。つまり、アプリケーションプロセス内に格納されます。その場合、データのサブセットは自動的にクライアントキャッシュ内に格納されます。これにより、プロセス間通信が削減されます。さらに、ネットワーク通信やネットワークオーバーヘッドも削減されます。実際にクライアントキャッシュの機能があり、トポロジの説明で詳しく説明します。詳細は後ほど説明しますが、簡単に概要を説明すると、クライアントキャッシュの仕組みは次のようになります。これは、アプリケーションと同じマシン上に存在するキャッシュです。クライアントキャッシュを有効にしておけば、ネットワークへの頻繁なアクセスが不要になります。コードを変更することなく動作します。これで質問への回答ができたと思います。他に質問があればお知らせください。はい、いいですね。ロン、お願いします。とても良いです。
-
ASP.NET および ASP.NET Core のキャッシング
次の使用例 NCache これはWebアプリケーション内のデータです。ユーザーデータのキャッシュが必要な場合、通常はASP.NETまたはASP.NET Coreのセッション状態になります。このデータは一時的なデータであるため、データベースには保存されません。これはユーザーが作成するデータであり、ユーザーがアクティブな間はアプリケーションのスコープ内に保持されます。履歴的な観点からデータベースに保存する場合もありますが、ほとんどの場合、データはユーザーに属するものです。
Microsoft ASP.NET または ASP.NET Core セッションについて考えてみましょう。いくつかのオプションがあります。ステートサーバー、インプロセス、データベースサーバーを使用できますが、これらのオプションにはそれぞれ問題があります。たとえば、インプロセスは単一障害点であり、スティッキーセッションのロードバランシングを使用する必要があります。ASP.NET ステートサーバーもまた単一障害点であり、ご存知のようにスケーラブルではありません。データベースもオプションですが、バックアップできるため単一障害点ではありませんが、場合によっては単一障害点になる可能性があり、低速でスケーラブルではありません。では、ここでどうすればよいのでしょうか？ここでも、 NCache ASP.NET および ASP.NET Core のセッション状態キャッシュ用です。当社のプロバイダーをプラグインするだけで動作します。コードの変更は不要ですが、プラグインするとすぐに NCache アプリケーション内で、 NCache メインのセッションストレージになります。RAMベースなので超高速です。複数のサーバーがあるため非常にスケーラブルです。そして、 NCacheプレゼンテーションが進み、トポロジーについて説明すれば、 NCache レプリケーションのおかげで、バックアップが確保されています。セッションデータはユーザーデータですよね？ですから、どんな状況でも失いたくないデータです。一度失えば、ユーザーにもビジネスにも影響が出るからです。そこで、レプリケーションによってデータのバックアップも確保されているのです。
分散キャッシュの一般的な使用法 メリットを挙げるとすれば、まず第一に、インメモリアクセスによってアプリケーションのパフォーマンスが向上します。複数のサーバーがセッションキャッシュをサポートするため、非常にスケーラブルです。さらに、高可用性とデータ信頼性の機能が組み込まれているため、セッションデータの損失やアプリケーションのダウンタイムは発生しません。 NCache サーバーがダウンした場合、スティッキーセッションロードバランシングを使用する必要がなくなります。 NCache 共有エンティティです。リクエストはどのウェブサーバーに送っても構いません。常にデータを見つけることができます。 NCache 当社のプロトコルに基づいています。つまり、コードの変更は一切不要です。
もう1つのユースケースとして、ASP.NET Webフォームを使用している場合は、ビューステートをバンドルすることもできます。この場合もビューステートがキャッシュされます。ビューステートは重くなり、帯域幅を大量に消費します。リクエストとレスポンスのパケットの一部となり、常にブラウザに送り返されます。ブラウザで実際に使用されることはありませんが、クライアント側のブラウザに保存されます。ポストバック時に、サーバー側でビューステートが返されます。つまり、 NCacheでは、ビューステートをサーバー側でキャッシュできるようになりました。これにより、ペイロードに重いビューステートが付加されなくなります。これによりパフォーマンスが向上します。ご存知のとおり、ビューステートは常にブラウザ側に保存されます。しかし、必要に応じてサーバー側で保持することで、アプリケーション全体の動作が向上します。実際のリクエストとレスポンスのパケットに重いビューステートが付加されなくなるため、帯域幅を消費することがなくなります。また、ビューステートがサーバー側に保存されるため、セキュリティも非常に高まります。さらに、暗号化やセキュリティ機能も設定できます。これもコード変更なしで使用できます。ただし、これは従来のWebフォームにのみ適用されます。ASP.NET Webフォームアプリケーションを使用している場合は、ビューステートのキャッシュも検討することをお勧めします。
そして、ASP.NET と ASP.NET Core のレスポンス キャッシュがあります。静的ページ、またはページ内の静的なページ部分については、それらのページ出力をキャッシュすることを検討する必要があります。ASP.NET Core には、選択可能なレスポンス キャッシュ オプションがあり、これもコードの変更を必要としません。さらに、ASP.NET と ASP.NET Core の SignalR バックプレーンもあります。Web フォームで SignalR を使用する場合は、バックプレーンが必須です。ファイルシステムやデータベースなどの一般的なバックプレーンは、先ほど説明したようなスケーラビリティとパフォーマンスの課題を抱える可能性があります。 NCacheこれは非常に高速で、拡張性と信頼性に優れています。なぜなら、バックグラウンドで非常に信頼性の高いメッセージングシステムを使用しているからです。これらは、ASP.NETまたはASP.NET Coreアプリケーションで活用できるユースケースの一部です。
-
Pub / Subメッセージング
いいですね。次に進みましょう。はい。それでは次はPub-Subメッセージングについてお話しします。ご覧のとおり、 NCache すでにアプリケーション間で共有されていますよね。つまり、データ要件に応じて使用できるエンティティです。データを追加したり、データを取得したりできます。パフォーマンスとスケーラビリティのメリットが得られます。 NCacheこのユースケースを拡張するには、 NCache メッセージングプラットフォームとしても機能します。 NCache メッセージングは非常に強力です NCacheこれは非同期のイベント駆動型メカニズムであり、複数のアプリケーションが相互にメッセージング要件やアプリ連携要件を駆動することができます。複数のアプリケーションが相互に通信する必要がある場合、通信の構築は困難です。そのため、中央集権的な存在に頼らざるを得なくなります。 NCache まさにその実体です。メッセージング機能により、一つのアプリケーションからデータやメッセージを追加できるオプションが提供されます。 NCacheそして、それらのメッセージは、反対側のすべてのサブスクライバー、つまり、それらのメッセージを必要とする他のアプリケーションに伝播されます。
分散キャッシュの一般的な使用法 同様に、これはデータ駆動型メッセージにもなり得ます。例えば、データが追加、更新、削除されたら通知が届きます。これらはカスタムアプリケーションメッセージやデータ駆動型メッセージなど、内部にデータが入力される領域と、その両方をカバーします。 NCache 他のアプリケーションにそれを認識させたい場合、メッセージング要件をそのアプリケーションを通して実現できます。あるいは、カスタムメッセージングやアプリケーション駆動型メッセージングのように、あるアプリケーションが別のアプリケーションと通信する必要がある場合にも利用できます。これもまた、インメモリのスケーラブルモデルに基づいています。信頼性の高いレプリケーションオプションも利用可能です。従来のPub-Subメッセージングプラットフォームに基づいており、トピックの概念とメッセージブローカーの概念があり、複数のアプリケーションが接続されます。そのため、パブリッシャーアプリケーションとサブスクライバーアプリケーションを定義できます。パブリッシャーアプリケーションは、メッセージをパブリッシュします。 NCache これらはすべての加入者に送信されます。そして、加入者は独自のメッセージを送信することもできます。 NCache これらの異なるアプリケーション間の通信プラットフォームとして機能します。
-
全文検索（分散Lucene）
最後に、もう1つのユースケースとして全文検索があります。アプリケーションで全文検索の要件を NCache、Lucine.NET ベースのフルテキスト検索機能の使用を検討できます。
ご存知の通り、Lucene APIは通常スタンドアロンです。複数のサーバーに拡張することも可能です。 NCache メモリ内にインデックスをロードする機能も提供します。つまり、 NCache ディスクベースのインデックスを使用しますが、複数のサーバーを接続することで、ストレージとリクエスト処理能力を拡張できます。つまり、ディスクベースではありますが、データベース上の単一のソースよりも優れています。トランザクション負荷が大きい場合、各サーバーが独自のインデックスリクエストセットを処理するからです。そのため、非常にスケーラブルで信頼性も高くなります。これはアシストストアであるため、シーンインデックスに関しては、永続性自体が重要な機能です。 NCache内部に保存したデータは NCache ディスク上にも保存できますし、データベースプロバイダによっては、一部のデータベース上にも保存できます。しかし、Luceneは NCache 使用ケースの性質上、データが永続的であることが求められるため、RAM と比較してディスクを使用します。
分散キャッシュの一般的な使用法
ザック、話を進める前に質問が投稿されていると思います。ええ。その質問は、基本的に「DBはデフォルトで」という発言から来たものです。それで、あなたの質問の途中で、あなたが終わるまで待ちたかったのですが、質問は基本的に「尋ねている」というものです。もしそうなら、その質問について詳しく説明していただけますか？
こんにちはロン、 NCache また、バックグラウンドプロセスとしてデータベース内のデータを同期するオプションを備えたメモリ内キャッシュにデータを保存するという要件がある場合、データ公開の目的にも適していますか？ NCache メモリ キャッシュとデータベース間の同期メカニズムをデフォルトで処理しますか?
はい、とても良い質問ですね。高度なケースでは、これは常に必須となる可能性があります。これには2つの理由があります。1つは、アプリケーションが現在使用しているデータが NCacheですが、データはデータベースに存在します。つまり、これらは2つの異なるソースであり、読み取りと書き込みの両方で同期する必要があります。さて、接続されたアプリケーションが NCache データベースは内部のデータを変更する唯一のアプリケーションです NCache データベースでは、リードスルーとライトスルーの使用をお勧めします。これは要件に応じて非同期または同期方式で実行できます。つまり、実際には、データベースからデータを取得しようとするたびに、 NCache キャッシュに存在せず、キャッシュしたい場合、自動的にリードスルーが呼び出され、コードに基づいてバックエンドデータベースからデータが読み込まれます。同様に、データがデータベースから取得され、キャッシュ内のデータを更新するとすぐにデータベース内のデータを更新する必要がある場合、ライトスルーが使用されます。ライトスルーはライトビハインドとも呼ばれ、キャッシュ内でデータが更新される必要があることを意味します。 NCache ライトスルーハンドラを使ってデータベースに書き込みます。非同期呼び出しが必要な場合は、ライトビハインドを使ってバックグラウンドで実行できます。しかし、繰り返しになりますが、 NCache そしてあなたのアプリケーションがその責任を負います。 NCache がコードを呼び出し、アプリケーションがそれを呼び出します。
もう一つの状況としては、他のアプリケーションがデータベース内のデータを直接変更している可能性があり、あなたのアプリケーションがそれを認識していないというケースが考えられます。この場合、実際には、データベース同期機能を使用する必要があります。カスタム依存関係を作成する必要があります。SQL Serverにはチェーン通知機能があり、私たちのデータベースにはデータベース依存関係があります。そのため、データベースへの変更をすべて捕捉する同期機能は数多くあります。 NCache 自動的に。そして、リードスルーを再び使用して、内部のデータを再読み込みすることができます NCache まとめると、 NCache 両方の状況に対応できます。つまり、アプリケーションのみが内部で何かを変更する場合と、 NCache およびデータベース、またはキャッシュを使用しているアプリケーションの範囲外でデータベースが変更される可能性がある状況です。
つまり、両方のシナリオがカバーされており、 NCache こういった場合には、100%同期オプションが表示されます。メモリキャッシュについておっしゃっているのであれば、通常はメモリキャッシュはASP.NETにも搭載されていますよね？しかし、 NCache メモリキャッシュとしてなので、既に質問にはお答えしています。他にご質問があればお知らせください。そこから対応させていただきます。
分かりやすく説明できたかと思います。これらはユースケースの一部です。繰り返しになりますが、これらのユースケースには多くの機能があり、あらゆる種類のアプリケーション、そしてアプリケーション内の特定の要件は、オブジェクトキャッシュとセッションキャッシュの機能によって完全に処理できます。
ちょっと質問なんですが、ロン。
MySQLデータベースと同じように、キャッシュ内のデータにアクセスする方法はありますか？キャッシュデータに対してSQLクエリを実行できるようにしたいのですが、可能でしょうか？
確かに。 NCache まず、SQL検索とLINQクエリをサポートしています。そのため、接続するだけでアプリケーションを作成できる場合は、 NCache条件に基づいた検索を実行するには、条件に基づいた検索を記述する簡単な方法があります。例えば、 製品価格 10より大きく100より小さいものを検索したり、カテゴリに基づいてすべての商品を検索したり、地域に基づいて顧客を検索したりすることもできます。つまり、SQLベースの検索やLINQベースの検索を考案し、 NCache キャッシュからデータを取得できます。これが一つの選択肢です。
もう一つの選択肢は、LINQ Padとの統合です。つまり、アプリケーション開発をせずにデータを視覚化したいだけであれば、LINQ Padを使えばLINQクエリを実行でき、LINQクエリを実行することでデータを視覚化できるという簡単な方法です。
そして、次のリリースでは、3つ目のオプションとしてデータアナライザーツールを提供します。これにより、キャッシュ内のデータを自動化して監視できるようになります。また、GUIから条件に基づいた検索オプションも利用できるようになります。これは現在開発中の機能で、要件定義と開発作業は完了しています。次のリリースで提供される予定です。
どれも本当に楽しみです。完璧ですね。ええ、とても良いですね。ロン、今のところは大丈夫だと思います。興味深い質問がいくつかあったので、この質問も最後にいくつか残しておきますが、はい、続けましょう。わかりました。
自己修復ダイナミッククラスター
次に、動的キャッシュ クラスターの詳細について説明します。 NCache TCP IP ベースのキャッシュクラスタリングプロトコルに基づいています。これは、当社独自に実装したキャッシュクラスタリングです。このためにサードパーティや Windows クラスタリングは使用していません。100% 独自のプロトコルです。.NET および .NET Core で記述されているため、TCP ソケットも .NET および .NET Core ベースであるため、非常に便利です。100% ピアツーピアアーキテクチャなので、単一障害点はありません。実行時にサーバーを追加または削除できます。キャッシュやそれに接続されているクライアントアプリケーションを停止する必要はありません。したがって、実行中のキャッシュクラスタに動的に変更を加えることができます。 NCache 問題は発生しません。サーバーを追加すると、クライアントは実行時に通知を受け取ります。クライアントは、このサーバーがキャッシュクラスターから外れたことを自動的に認識し、追加のサーバーの使用を開始します。クラスターは自動的に調整されます。同様に、サーバーを削除すると、他のサーバーがそのサーバーが完全になくなったことを検出します。クライアントに通知され、クライアントは失われたサーバーの使用を停止します。クライアント側には接続フェイルオーバーのサポートも組み込まれているため、サーバーがダウンすると、クラスターがクライアントにその旨を伝え、接続をフェイルオーバーして、残っているサーバーの使用を開始します。
そのため、クラスタ内の変更はどのような場合でもクライアントに伝播されます。クライアントはインテリジェントであり、キャッシュクラスタの状態を常に把握しています。そのため、レプリケーションサポートも組み込まれているため、ダウンタイムやデータ損失は発生しません。 NCache 可用性が高く、レプリケーションのおかげで信頼性も非常に高いです。アプリケーション側では100%の稼働率を保証し、アプリケーションの中断は一切ありません。 NCache.
キャッシングトポロジ
次に、キャッシュトポロジについてお話しします。これが私が最も説明したい部分です。4つのオプションから選択できます。最初のオプションは、やはり小規模な構成向けです。これは、キャッシュの構成方法を決定します。
ミラーリングされたキャッシュ
そこで、ミラーキャッシュトポロジを使用してキャッシュを構成するオプションがあります。その仕組みは、最大で2台のサーバーのみを使用することです。1台のサーバーはアクティブサーバーとして機能し、すべてのクライアントが接続されます。もう1台のサーバーはパッシブサーバーとして機能し、バックアップとして機能します。バックアップは NCacheこのトポロジーは、一度設定すれば、自動的にアーキテクチャに従います。基本的に、これがアクティブになるかこれがパッシブになるかを定義する必要はありません。 NCache 自動的に行われます。しかし、実際に何が起こるかというと、すべてのクライアントアプリケーションがアクティブサーバーに接続し、そこからデータの読み書きを行うことになります。アクティブサーバー上のデータは、非同期ミラーリングオプションを通じてパッシブサーバーにバックアップされます。つまり、クライアントがアクティブサーバーを更新して返すため、クライアントアプリケーション側でレプリケーションのコストは発生しません。クライアントアプリケーションは超高速になります。舞台裏では、 NCache バックアップを更新する必要があります。バックアップが存在するのには重要な理由があります。サーバー1がダウンした場合、バックアップサーバーは自動的にアクティブサーバーとして更新され、クライアントは接続をフェイルオーバーし、新しくアクティブになった（以前はバックアップサーバーだった）サーバーの使用を開始します。そして、最初のサーバーが復帰すると、キャッシュクラスターに既にアクティブノードが存在するため、アクティブノードではなくバックアップノードとして再び参加します。これらはすべてアプリケーションに対してシームレスに実行されます。サーバーが追加されたり、サーバーが失われたりしても、ユーザーが介入する必要はありません。
このトポロジは、書き込みだけでなく読み取りにも非常に優れています。つまり、参照データやトランザクションデータには適しているということです。ただし、最大でサーバーが2台しかなく、そのうちアクティブなサーバーは常に1台だけであるため、キャパシティの問題があります。そのため、小規模な構成で信頼性の高いデータ（キャッシュ機能など）を使用する場合、これは選択肢の一つとなるでしょう。
複製されたキャッシュ
次に、1つ目のオプションはレプリケートキャッシュです。これも小規模な構成向けです。この方法では、すべてのサーバーがアクティブになります。サーバー2とサーバー2は両方ともアクティブです。クライアントは複数のサーバーに分割されます。つまり、図に示すように2つのクライアントがある場合、一部のクライアントはサーバーXNUMXに接続し、残りのクライアントはサーバーXNUMXに接続します。つまり、これらのXNUMXつはサーバーXNUMXに接続され、これらのXNUMXつはサーバーXNUMXに接続されています。
これは自動的に行われます。接続バランスは内部に組み込まれています。 NCacheすべてのサーバーはアクティブですが、各サーバーにはキャッシュのコピーが存在します。つまり、サーバー1にあるデータはすべてサーバー2にもコピーされ、このコピーは同期更新によって維持されます。つまり、あるサーバーで実行した更新は、同期呼び出しによって他のサーバーにも適用される必要があり、クライアントは操作全体が完了するまで待機することになります。いずれかのサーバーで操作が失敗した場合、操作全体がロールバックされます。このようにして、すべてのサーバーで100%同期されたコピーが実現されます。これは信頼性の面で非常に優れていますが、読み取り集中型のユースケースでは、データのコピーや複数のサーバーからのコピーが増えるため、サーバーが増えるほど読み取り容量が増加します。これは、リクエストを処理するサーバーが増えるためです。しかし、同期更新があることにお気づきかと思いますが、書き込み操作はすべてのサーバーに適用する必要があります。そのため、書き込み容量が小さい構成に適しています。サーバーが1台またはXNUMX台の場合、同じ操作をXNUMX回またはXNUMX回適用する必要があり、パフォーマンスに悪影響を与える可能性があります。そのため、このトポロジは参照データを扱うシナリオや小規模な構成に適しています。読み取りに関しては拡張性に優れていますが、書き込みに関してはそれほど拡張性が高くありませんが、非常に信頼性が高いです。高可用性とデータの信頼性を実現します。例えば、いずれかのサーバー（例えばサーバーXNUMX）がダウンした場合でも、アプリケーションはフェイルオーバーして生き残ったサーバーを選択し、既に利用可能なキャッシュのコピーが存在するため、データ損失やダウンタイムは発生しません。
パーティションキャッシュとパーティションレプリカキャッシュ
次のオプションは、パーティションキャッシュを使用してキャッシュを構成することです。パーティションキャッシュとパーティションレプリカは、ご存知のとおり最も一般的なトポロジです。パーティションキャッシュを使用すると、利用可能なサーバーノード間でデータを分散できます。例えば、1台のサーバーがあり、データがある場合、データの半分はサーバー2に、残りの半分はサーバーXNUMXに分散されます。データの分散は、 NCacheこれはアプリケーションが行うものではなく、実行時にアプリケーションによって自動的に行われます。インテリジェントな分散マップとハッシュアルゴリズムによって、どのデータがどのサーバーに送信されるかが決まります。
これを踏まえると、アプリケーションはキャッシュクラスター内のすべてのサーバーにデータを均等に分散することになります。データが均等に分散されると、リクエスト負荷も均等に分散されます。つまり、サーバーの台数に応じて読み取りと書き込みの容量が増加します。サーバーが2台の場合、2台のサーバーがチームとして動作します。2台から3台に増えると、読み取りと書き込みのリクエストを処理するサーバーの台数が増えます。つまり、読み取りと書き込みのスケーラビリティが向上します。つまり、サーバーを追加すればするほど、線形にスケーラビリティが向上します。サーバーを追加すると、データが分散されるため、メモリリソースもプールされ、すべてのサーバーのストレージがプールされます。つまり、サーバーが2台の場合、容量は2台分です。3台目、4台目のサーバーを追加すると、容量はサーバー数に応じて増加します。つまり、全体の容量がプールされるため、キャッシュクラスターにサーバーを追加すると、線形に増加します。
読み取り、書き込みともに非常に優れており、参照だけでなくトランザクションデータにも非常にスケーラブルです。このトポロジの唯一の欠点は、バックアップがないことです。サーバーがダウンすると、そのパーティションも失われます。そのため、そのような事態が発生した場合、バックエンドデータベースからそのデータを構築する手段が必要です。つまり、高パフォーマンスの実現が主な目標であり、パフォーマンス重視のアプリケーションで、データベースへのバックアップを許容できる場合（よくあるケースです）、このトポロジに頼る必要はありません。 NCache 高可用性とデータの信頼性を実現するには、他のすべてのトポロジと比較して、これが最高のパフォーマンスを実現します。
しかし、高可用性が必要で、データの信頼性要件も提供する必要がある場合は、 NCacheより優れたトポロジーとして、「レプリカのパーティションキャッシュ」があります。全体的なアーキテクチャは、レプリカの拡張によるパーティション分割と全く同じです。各サーバーにはデータのパーティションがありますが、各サーバーは1つのパーティションを維持します。2つはクライアントが接続するアクティブなデータパーティション、もう2つは別のサーバーのバックアップパーティションです。サーバー1がアクティブで、そのバックアップはサーバーXNUMX上に、サーバーXNUMXがアクティブで、そのバックアップはサーバーXNUMX上にあります。そして、同期または非同期のバックアップオプションを選択できます。レプリカのパーティションと非同期を選択した場合、クライアントはアクティブなパーティションを更新し、クライアントで完了した操作を返します。その後、 NCache バックアップパーティションはバックグラウンドで更新されます。同期を選択した場合、クライアントアプリケーションはアクティブとバックアップをトランザクション操作として更新します。いずれにしても、同期の方が信頼性が高く、非同期の方が高速であることは明らかです。しかし、どちらの方法でも、 NCache データの信頼性を確保できるので、サーバーがダウンした場合でもバックアップトポロジがアクティブになり、データの損失やアプリケーションのダウンタイムは発生しません。その通りです。
それでは、3台のサーバーを使ったこのトポロジーを簡単にご説明しましょう。これにより、読み取りと書き込みの両方において高いパフォーマンス、そして読み取りと書き込みの両方におけるリニアなスケーラビリティといったメリットをすべて享受できます。さらに、スケーラビリティ、高可用性、そしてデータ信頼性というメリットも得られます。仮にいずれかのサーバーがダウンしても、データ損失やアプリケーションのダウンタイムは発生しません。
デモ
ご理解いただけたでしょうか。それではデモ環境へご案内し、これらのキャッシュトポロジの構築方法と、キャッシュクラスタの簡単なテスト方法を簡単にご説明いたします。ご質問などございましたらお気軽にお問い合わせください。また、ご紹介する内容はすべて、お客様の環境や具体的なユースケースに合わせて、ハンドヘルドセッションやテクニカルサポートセッションでご提供することも可能です。ウェビナー終了後も、ここでご説明した内容について、チーム一同、喜んでご説明させていただきます。お客様にとってどのように機能するかをデモンストレーションさせていただきます。
質問に関して言えば、最後にちょうどいいタイミングで届いた質問が一つあります。そのうちの一つは、あなたのお気に入りの質問の一つです。
アプリケーションキャッシュにHazelcastを使用するかどうかについては多くの議論がありました。 NCache Hazelcast では規定されていないのですか?
分かりました。まず第一に、これは議論のようなものです。 NCache 実際には.NETと.NET Coreで書かれているため、推奨プラットフォームは NCache Windowsです。 NCache .NETだけでなく、WindowsやLinuxでも動作することが特長です。プラットフォームと互換性のサポートにより、 NCache 提供されている機能の中で、これを実現できる製品は他にありません。これが最初の点で、利用を検討しているプラットフォームについて検討する場合、より好ましい選択肢となります。もう一つの違いは、ぜひ皆さんに当社の製品について調べてみてほしいということです。 比較ページそこにも非常に良い資料が見つかるでしょう。しかし、簡単にまとめると、 NCache オブジェクトキャッシュのサポートには、他の製品には全く欠けている多くの機能があります。例えば、SQL検索など、精巧な機能セットが提供されています。 NCacheキャッシュローダーとキャッシュリフレッシャーがあります。これらは完全に独自の機能です。 NCacheサーバー側で .NET および .NET Core コードを実行できる当社のリードスルーおよびライトスルーハンドラーは、まさに他に類を見ない機能です。 NCacheなどなど、まだまだありますよね。サーバー側でカスタマイズできる機能の中には、 NCache アプリケーションの観点から見ると、他の製品にはない機能が数多くあります。ぜひ比較ページをご覧ください。機能ごとの比較も掲載されており、より詳細な情報が得られます。
これは間違いなく私たちのお気に入りの質問です。ウェビナーでも技術的なソリューションでも、HazlecastでもScalaでも、 Redisでも、どうもありがとう、ロン。ええ、大丈夫だと思います。続けてください。もちろん。
新しいクラスターキャッシュを作成する
それでは、新しいクラスターキャッシュを作成して、製品の簡単なデモをしてみましょう。「test Cache」という名前にしましょう。さて、この部分をここに移動しますので、しばらくお待ちください。
さて、4つのキャッシュトポロジについて説明しました。今回は、非同期レプリケーションオプションを備えた最も推奨される「レプリカのパーティションキャッシュ」を選択します。これらはすべてデフォルトのままにしておきます。
続いて、GUIツールを使ってキャッシュを簡単に設定する方法をご紹介します。これはWebマネージャーですが、PowerShellコマンドレットを使ってすべてを実現できます。また、必要に応じてこの展開を自動化することも可能です。サーバー1を追加します。 NCache インストールされます。次にサーバー2を追加します。つまり、2つのボックスに NCache 2GBのキャッシュサイズでセットアップします。ここでの私の考えは、2ノードのキャッシュクラスタを作成し、それぞれ2GBのキャッシュサイズを使用するというものです。つまり、2台のサーバーで合計XNUMXGBのキャッシュサイズになります。 NCache すでにインストールされています。そして、私のボックスを使ってこのキャッシュクラスターに接続します。
TCPパラメータ。これは設定が必要なポートです。デフォルトのままにするか、ファイアウォールの影響を受けないポートを指定してください。
暗号化と圧縮の設定が必要な場合は、この画面が表示されます。ここではそのままにしておきます。「次へ」を選択します。キャッシュがいっぱいになった場合の削除は選択できます。1つのオプションは、キャッシュへの書き込み操作を一切行わないことです。「キャッシュがいっぱいです」というエラーが表示されます。もう1つのオプションは、削除を設定することです。これらのアルゴリズムに基づいて、実行時にキャッシュから一部のアイテムを削除します。優先度、使用状況、最も古いアイテム、または頻繁に使用されていないアイテムが削除され、アイテムの5%がキャッシュから削除されます。このキャッシュは「完了時に開始」と「自動開始」に設定して、サーバーの再起動時などに自動的に開始されるようにします。 NCache サーバーを再起動すると、停止されていたキャッシュを再起動できるようになります。
「完了」を選択すれば完了です。キャッシュクラスターの設定はこんなに簡単です。しばらくすると、このキャッシュが開始される別のビューが表示されます。そこから監視と管理の詳細についてご説明します。キャッシュ設定に関するより詳細なビデオもご用意していますので、ご質問があればお気軽にお寄せください。ビデオもご参照いただけます。
クラスターの監視を選択すると、別のダッシュボードが開き、キャッシュを完全に監視できます。完全に接続されたキャッシュクラスター、リクエストスループットカウンター、レイテンシカウンター、追加、フェッチ、更新カウンターが表示されます。同様に、CPUとメモリの使用率、そしてキャッシュフルの状況も表示されます。
クライアント用のダッシュボードとレポートビューも用意されており、サーバー側とクライアント側のダッシュボードを確認できます。現時点では接続されたアプリケーションはありませんが、このtest-stressボタンを使用して負荷をシミュレートできます。このtest-stressを呼び出すことで、キャッシュクラスター上でダミーの負荷、つまり何らかのアクティビティを開始できます。実行すると、1つのクライアントが接続され、このトポロジではデータが分散されることがわかります。つまり、一部のデータはサーバー2に、残りのデータはサーバーXNUMXに送信されます。つまり、このクライアントは両方のサーバーを均等に使用しています。両方のサーバーにリクエストが送信され、両方のサーバーのキャッシュサイズが増加していることがわかります。
両方のサーバーでアクティブパーティションとバックアップパーティションが表示されています。レイテンシカウンターを簡単にお見せすると、私の操作では1ミリ秒未満、さらにはマイクロ秒単位のレイテンシとなっています。クライアントダッシュボードにはクライアント側の統計情報が表示されており、同様にサーバー側の統計情報を示すレポートも表示されています。
ロン、質問があります。実はいくつか質問が来ていて、そのうちの 1 つは次の通りです。
削除に関してどのような推奨事項がありますか？ 削除が少なくとも必要な場合、次の質問ですが、削除がオフになっている場合、キャッシュサイズを増やすか減らすかは可能ですか？
はい。つまり、エビクションはユースケースに基づいて設定する必要があるということですね。データがエビクションしても問題ないのであれば、そうすべきです。エビクション自体も、キャッシュがいっぱいになった場合に一部のデータを削除します。理想的な状況は、キャッシュがいっぱいになることがなく、キャッシュの容量が十分に確保されていることです。つまり、キャッシュがいっぱいにならないように十分なサイズやメモリを割り当てます。しかし、万が一、いっぱいになった場合、バックエンドデータベースからいつでもデータを再構築できるようなデータであれば、エビクションを有効にすることをお勧めします。例えば、ASP.NETセッションでは、エビクションを有効にすることはお勧めしません。新しいユーザーのためにスペースを作るために一部のユーザーを削除することになるからです。すべてのユーザーが重要なデータを持っているはずです。つまり、どのようなシナリオでも失いたくないデータです。そのため、このようなシナリオではキャッシュサイズを増やすことをお勧めします。キャッシュサイズは十分な大きさになるように計画し、いっぱいになった場合に備えて NCache 実行時にキャッシュサイズを変更できます。この設定を編集して、それに基づいて設定を増やし、実行中のキャッシュに保存できます。つまり、すぐに適用でき、実行時にキャッシュサイズを増やすことができます。
他に質問はありますか？これで答えが出たようですね。いくつか最後に残しておきますので、デモを完了させてください。はい。それではデモ環境に戻りましょう。クライアントを追加できます。例えば、私のBoxをクライアントとして追加できます。これは私のBoxから実行できるサンプルアプリケーションの概要です。例えば、これはGitHubからも入手できますので、検索してみてください。 NCache GitHubにはサンプルがいくつかあり、そこからサンプルを1つ抽出しました。アプリケーション内で実際に必要なのは、このNuGetパッケージをインクルードすることです。 Alachisoft.NCache.SDK、もし興味があれば アプリデータのキャッシュ検討すべきサンプルはこれです。これを基に、アプリケーション内にいくつかのリソースを含めることができます。
これには既にいくつかのライブラリが含まれています NCacheをこの新しいNuGetパッケージの一部として追加します。そして、この参照を次のように追加します。 Alachisoft.NCache。クライアント. また追加する ランタイムキャッシュそうです。これに基づいてキャッシュハンドルを定義でき、その中にたくさんのメソッドがあります。例えば、キャッシュの初期化方法をお見せしましょう。実際に中身を見ていきましょう。ちょっと我慢してください。ちょっと苦労しています。とにかく、どういうわけか、実際に中身を見ることができません。ボックス自体に問題があると思います。とにかく、APIは非常に直感的です。PowerPointからお見せしましょう。このサンプルは実際にそれを使用していますが、コードにステップインできないため、デモンストレーションできません。
これはキャッシュハンドルで、私が紹介したかったコードの一部です。 CacheManager.GetCache キャッシュに接続できるようになります。その後、 キャッシュ.取得 実際にキャッシュからデータを取得するには、次のように呼び出します。同様に、 キャッシュ.追加 or キャッシュ.AddAsync キャッシュにレコードを追加し、同様に挿入するにはupsertのようにキャッシュにデータを追加し、同様に次のように呼び出すことができます。 キャッシュ.削除.
したがって、この サンプル ダウンロードしてキャッシュに対して実行できるツールが利用可能です。アプリケーション側からキャッシュを指定するだけです。設定項目は豊富です。キャッシュ名とIPアドレスをインラインで指定することも、このNuGetパッケージに含まれるclient.ncconfを利用することもできます。リソースをいくつかお見せすると、多くのファイルが追加されていることがわかります。このファイルはキャッシュへの接続を可能にするファイルです。つまり、既に「democache」に接続できているということです。実行すると、キャッシュに対して何らかの処理が実行され、キャッシュ操作が開始されます。
同様に、私はさらにいくつかのオプションを提供する別のサンプルを持っています。例えば、次のような質問がありました 内部を探索 NCacheそうですね。それでは、ここにあるサンプルを使うことをお勧めします。これはSQL検索用です。これもGitHubからダウンロードしたもので、サンプルデータを使ってSQL検索を呼び出しています。そして、ここにはたくさんの機能があります。これも同じように、サンプルは非常に直感的です。アイテムを挿入して、名前タグを使ってクエリを実行したり、定義済みのインデックスやプロジェクションを使ってクエリを実行したりできます。
残念ながら環境問題のためこれらの方法の詳細を述べることはできませんが、これらは使用上の大きな参考資料となるでしょう。 NCache アプリケーション内でキャッシュを使用する必要があるアプリケーション、またはアプリケーション内で検索を行うユースケースがあるアプリケーションから。
クライアントキャッシュ
もう一つの質問は クライアントキャッシュこのトポロジーはコード変更の必要もありません。データベースからキャッシュしたデータは NCacheクライアントキャッシュを使用することで、さらにキャッシュすることができます。これは別のキャッシュの上に構築されるキャッシュです。コードを変更することなく動作します。クラスタ化されたキャッシュと同期されているため、データの整合性の問題はありません。同期は以下によって行われます。 NCache1つのクライアントキャッシュで行われた更新は、必ずクラスター化されたキャッシュに伝播され、その後他のクライアントキャッシュに伝播されます。そして、キャッシュ内ですべての同期が管理されます。書き込み回数が少ない参照データのシナリオでは、このオプションを選択することを強くお勧めします。
WANレプリケーション
同様に、 NCache また、持って WANレプリケーションアクティブ/パッシブとアクティブ/アクティブのトポロジーをご用意しています。そのため、キャッシュデータ全体をブリッジキャッシュを介してデータセンター間で複製できます。ブリッジ自体はアクティブ/パッシブサーバーにバックアップされているため、ソースキャッシュとターゲットキャッシュがあり、一方向のレプリケーション、つまりデータセンター間での東西方向のデータ移行が可能です。これは、DRシナリオや東西方向の移行、あるいはあるアプリケーションのデータをターゲットアプリケーションで使用する必要がある場合などに利用できます。つまり、キャッシュデータ全体をデータセンター間で転送することが可能です。
もう1つの選択肢はアクティブ-アクティブです。この場合、両方のサイトがアクティブになり、サイト1はサイト2にデータを転送し、サイト2はサイト1にデータを転送します。これもコードの変更は不要です。設定のみで済みます。ブリッジを設定したら、2つのキャッシュを接続します。 NCache 引き継ぎ、キャッシュ間でのデータのレプリケーションを開始します。
これはマルチアクティブ・アクティブトポロジーにも拡張されます。つまり、2つのサイトだけでなく、3つ、4つ、あるいは5つのサイトが相互にデータを転送する構成も可能です。つまり、 NCache実際に、すべてのサイトからデータを一度に同期できる機能です。ちなみに、これは非同期で行われるため、レプリケーションのコストはアプリケーション側でもユーザー側でも発生しません。これはアプリケーション側で行われます。クライアントアプリケーションはここにもここにも接続されています。このWANレプリケーションによってパフォーマンスが低下することはありません。これはバックグラウンドで実行されます。 NCache何かご質問があればお知らせください。これでプレゼンテーションと機能説明を終了させていただきます。ザック、ご質問があればお知らせください。
はい、いくつかあります。皆さん、お待たせしました。プレゼンテーション中に疑問に思っていたことがあれば、このタイミングでご質問いただければ幸いです。それでは、まず一つ。
キャッシュが正常に動作しているかどうかは、どのように確認すればよいでしょうか？何か通知などは届きますか？例えば、問題が発生しているかどうかはどうやってわかるのでしょうか？
はい。 監視および管理ツール一つは、視覚的にクラスタの健全性を確認することです。CPU使用率やRAM使用率などです。ベースラインが分かれば、アプリケーションがどれくらいのリクエストを生成しているか、そして典型的な使用率はどれくらいかが分かります。 NCache これらのカウンターに基づいて、監視・管理ダッシュボードを使用して視覚的に確認できます。また、あらゆる状況に対応するアラートも用意しています。例えば、キャッシュの開始、停止、ノードの参加、離脱、キャッシュサイズがいっぱいになった場合、あるいはスプリットブレインなどのクラスタの異常状態が発生した場合などです。アラートはWindowsイベントログに記録されます。また、メールアラートの設定も可能です。 NCache、そしてあなたにメールを送ることもできます。これはプロアクティブな監視、アラート機能になります。 NCacheここで、 NCache アラートが発せられ、それに基づいて対処することができます。また、パフォーマンスモニターのカウンタログやキャッシュログの形で履歴データが取得されます。何が問題なのかわからず、何か問題が見つかった場合などにも役立ちます。 NCache参加してレビューすることもできます NCache ログを確認し、その場合のキャッシュの健全性を評価します。この点に関しては、検討できる方法がたくさんあります。
いいですね。もう一つ質問があります。
最新の.NETバージョンは何ですか？ NCache 現在クライアントをサポートしていますか?
はい。通常、私たちは最新の .NET Framework バージョンである .NET Core を使用しています。.NET 6 は現在サポートされており、これは次の前提条件です。 NCache.NET 6が必須です NCache サーバー側では、アプリケーションはどの .NET Framework 上でも動作可能です。確か 3.5 以降、4.0、4.5、あるいは 4.7、4.8 まで対応していたと思います。アプリケーションは .NET または .NET Core のどちらのフレームワークでも動作可能です。制限があるのはサーバー側だけです。また、例えば .NET 7 のような新しいフレームワークとの互換性がテストされ次第、弊社の QA ラボでテストを実施しています。承認が得られ次第、公式サポートもリリースする予定です。
素晴らしいですね。もう一つ質問があります。
キャッシュサーバー間でクラスター化されたキャッシュの安全な数はどれくらいでしょうか？例えば、キャッシュサーバー間で15個のクラスター化されたキャッシュを作成してもよいでしょうか？
はい。まずは NCache 設定できるキャッシュの数に制限はありません。実際、私のデモ環境を見ると、10つのキャッシュが設定されています。つまり、必要な数だけ作成できます。ただし、技術的な推奨事項、あるいはキャパシティ関連の推奨事項があり、実稼働環境では通常、XNUMX～XNUMX個のキャッシュを超えないようにすることをお勧めします。これは、各キャッシュが独立したキャッシュクラスターであるためです。実際には、ストレージ、クラスタリング、通信のためのすべてのリソースを消費し、クラスター管理のオーバーヘッドも発生します。つまり、キャッシュの数が増えると、その環境、あるいはその環境内で、キャパシティの問題が発生することになります。したがって、可能であればXNUMX～XNUMX個以内に抑えることをお勧めします。複数のキャッシュが必要な場合は、最大XNUMX個まで拡張できます。ただし、先ほども述べたように、これはあくまで推奨事項であり、強制的な制限はありません。これは、私たちからの一般的な推奨事項です。
わかりました。セッションも終わりに近づいていますし、皆さんもDockerで他の作業をされていると思いますので、もう1つだけ付け加えさせてください。
できる NCache DR レプリケーションを提供しますか?
はい、可能です。先ほどご説明したWANレプリケーション機能、つまり最後のトポロジーは、DR（災害復旧）をカバーしています。アクティブサイトのデータは他のサイトにも転送できるため、DRサイトは完全にバックアップされます。アプリケーション側でスイッチを切り替えるだけで済みます。すべてのデータが既にバックアップされているため、1つのデータセンターが完全にダウンした場合でも、あるいはメンテナンスのためにデータセンターを停止する必要が生じても、データ損失は発生しません。
はい。ほぼ可能な限りのことをお話しできたと思います。皆様、セッション以外でも対応可能ですので、ご安心ください。既にご利用いただいている場合は、既存の設定の確認など、喜んでお手伝いさせていただきます。 NCache初めての方は NCache、トライアルを設定して、統合アプリケーションでこれがどのように機能するかを説明する手取り足取りのセッションを喜んでお手伝いいたします。しかし何よりも、ご質問があればいつでもご連絡ください。 NCache、製品の使い方について、また何かサポートが必要な場合は、お気軽にお問い合わせください。今後も多くの新機能や新バージョンのリリースを予定していますので、ぜひご注目ください。今後もこのようなウェビナーを開催していきますので、どうぞご期待ください。
ロンに拍手を送ります。本日はセッションのために時間を割いていただき、本当に感謝しています。次回も楽しみにしています。皆様、ありがとうございました。ザック、ありがとうございました。もちろんです。それでは皆さん。素晴らしい一日をお過ごしください。次回のウェビナーでお会いできるのを楽しみにしています。ちなみに、このウェビナー終了後、ウェビナーの録画をウェブサイトにアップロードする予定です。もしご質問や、私たちがお伝えしたポイントをもう一度確認したい場合は、ぜひウェブサイトにアクセスして録画をご覧ください。
よし、じゃあ。みんなに敬意を表して。良い一日を。ありがとう、みんな。じゃあね。