NCache アーキテクチャ
今日は、について話します NCache 建築。 NCache は、.NET および Java アプリケーション用のインメモリ分散ストアです。 非常に高速でスケーラブルです。 また、これを高トランザクション サーバー アプリケーションで使用して、アプリケーションのパフォーマンスとスケーラビリティを向上させることができます。
の一般的な使用法 NCache
分散キャッシュ
2つの一般的な方法 NCache 使われています。1つ目は 分散キャッシュ アプリケーションデータをキャッシュすることで、データベースへの高価なアクセスを削減し、2番目は メッセージングとストリーム プラットフォームです。アーキテクチャの説明に入る前に、これら2つについて簡単に説明します。
-
アプリのデータキャッシュ
分散キャッシュでは、アプリケーションデータのキャッシュとは、 NCache APIは通常、アプリケーションデータをキャッシュするだけです。キャッシュはデータベースよりもはるかに高速なので、データベースに頻繁にアクセスする必要がありません。また、メモリ内にあるため高速で、スケーラビリティも優れています。アプリケーションに近いため高速で、分散されているためスケーラビリティも優れています。さらに、.NETアプリケーションでEF Coreを使用している場合は、 NCache EF Coreだけでなく、NHibernateやEF 6でも利用可能です。Javaアプリケーションをお持ちの場合は、 NCache Hibernateの2次キャッシュとして使用できます。また、Spring Cacheとして使用したり、JCacheに対してプログラムすることもできます。 -
Webアプリのキャッシュ
分散キャッシュの使用の2番目の部分は、Webアプリケーションがある場合、 のセッション NCache その後 NCache これらのセッションを複数のサーバーに複製し、 NCache サーバーがダウンしてもデータは失われませんが、これらのセッションは分散ストアであるため非常にスケーラブルで、明らかに超高速です。また、.NET、Java、Nodejsなどのすべての言語でマルチサイトセッション機能が利用可能です。セッションに加えて、たとえば.NET 6の場合、ASP.NET Coreアプリケーションはセッションを保存できます。 レスポンスキャッシュ NCache そして、彼らはまた、 NCache として SignalR用バックプレーンSignalRは、Webアプリケーションがクライアントにイベントを送信するライブWebアプリケーション向けです。また、.NET 4.8を使用している場合は、セッション状態を保存することもできます。 状態を表示, 出力キャッシュ、また SignalR も。
NCache ミッションクリティカルなアプリ向け
早速お見せしましょう NCache ミッションクリティカルなアプリケーション向けの分散キャッシュとして、これがどのようなものなのかご説明します。「ミッションクリティカル」という言葉を使ったのは、多くの場合、お客様が NCache 顧客対応の非常に機密性の高いアプリケーションで使用され、ビジネスにとって非常に重要です。 NCache それは、ご存知のとおり、非常に重要なインフラストラクチャの一部です。
そして、これらは、先ほど述べたように、トランザクション量の多いサーバーアプリケーションです。これらはWebアプリケーションです。マイクロサービス、Web API、またはその他のサーバーアプリケーションです。もちろん、.NET、Java、Node.js、またはPythonを使用できます。そして、これらのアプリケーションは、SQL Server、Oracle、Db2、MySQL、またはその他のリレーショナルデータベースとしてデータベースにアクセスしようとしています。あるいは、レガシーメインフレームデータにアクセスしたり、Mongo DB、Cosmos DB、CassandraなどのNoSQLデータベースを使用したりしている可能性があります。このような状況では、 NCache 分散キャッシュになるのは… NCache 2台以上のサーバーを別々のキャッシュ層として使用できますが、別々のキャッシュ層を用意する必要はありません。アプリケーションは同じボックスで実行できます。 NCache 問題なく動作しますが、より一般的な展開アーキテクチャは別のキャッシュ層を持つことです。これはよりクリーンな方法です。 NCache.
例えば、2台のサーバーからなるキャッシュクラスタから始めるとします。 NCache クラスタ、 NCache これらすべてのサーバーのメモリ、CPU、ネットワークカードのリソースを1つの論理容量にプールし、アプリケーションを通じてより多くのトランザクション負荷をそのサーバーにかけるとします。 NCache この2つのサーバーは最大限に活用されていますが、3台目、4台目、5台目などを簡単に追加できます。 NCache 決してボトルネックにならない。これはデータベースではできないことです。データベースはスケーラブルではありません。NoSQLはスケーラブルですが、ほとんどの場合、さまざまなビジネス上の理由からリレーショナルデータベースを使用する必要があり、レガシーメインフレームも使用しています。そのため、データストレージ層はスケーラブルではありません。 NCache 可能な限り多くのデータをキャッシュすることで、アプリケーションのスケールアップに役立ちます。一般的な目標は、データの検索に要する時間の約80%を節約することです。 NCache データベースにアクセスするよりも、むしろその比率を達成できれば、データベースへの負荷が軽減され、アプリケーションは拡張可能になります。
メッセージングとストリーム
2番目によくある使用例、つまり NCache メッセージングとストリームのプラットフォームとして利用し、複数のアプリケーションが相互に通信できるようにすることです。 Pub / Subメッセージングを通じて、 連続クエリまたは NCache ベースイベントです。具体的にどのように見えるかお見せしましょう。例えば、大量のリアルタイムメッセージングやストリーム処理を必要とする高トランザクションのサーバーアプリケーションがある場合、 NCache. 今も同じ NCache 分散キャッシュだったものが、メッセージングとストリームのプラットフォームになりました。繰り返しますが、これはインメモリ分散ストアです。線形に拡張でき、メッセージを複数のサーバーに複製します。実際、 NCache そこには Persistence も含まれています。
これにより、様々なアプリケーションが実現できます。例えば、Pub/Subメッセージングは非常に普及しており、複数のパブリッシャーと複数のサブスクライバーが互いに分離した形で通信できるパラダイムです。分離とは、パブリッシャーはサブスクライバーが誰であるかを知らず、特定のトピックにメッセージをパブリッシュするだけで、サブスクライバーはそれを受信できることを意味します。継続的クエリも同様です。これらが一般的な2つの方法です。 NCache 使用されている。
.NET と Java アプリケーションの比較
さて、どのように NCache .NET と Java アプリケーションを処理します。 NCache 非常にユニークなネイティブ マルチプラットフォーム機能があり、非常に興味深いと思いますので、詳しく説明します。
.NET版
NCache .NETとJavaの両方にネイティブなソリューションを提供しようとしています。つまり、.NETアプリケーションでは、アプリケーションスタック全体が.NETを基盤としており、.NET以外のものは一切使用していないということです。例えば、 NCache アプリケーションはネイティブの.NETクライアントを使用してアプリケーション上で動作します。これはアプリケーションサーバー上で実行され、 NCache これを 100% 'C Sharp' (C#) で開発しました。
同様に、.NETで記述したRead-through、Write-through、Right-behind、Loader/Refresherなどのサーバー側コードがある場合、 NCache 独自の.NET CLRプロセスでそのコードを実行します。その方法を説明します。この図を何度も繰り返し参照します。例えば、こちらが NCache アーキテクチャでは、WindowsまたはLinuxで実行される.NETアプリケーションがあります。ネイティブ NCache .NETクライアントです。これは NCache .NET Editionのクラスタ NCache クラスター。つまり、サーバー側のコードも .NET であるということです。
さて、 NCache マルチプラットフォームネイティブサポートにおいて非常に強力なアーキテクチャとなっているのは、キャッシュプロセスと管理プロセスがサーバーサイドのコードプロセスとは独立しているからです。そして、非常に高性能なRPC、つまりインメモリRPCが存在します。 NCache 用途、その NCache 独自の超高速RPCを開発しました。キャッシュはこれを利用してサーバーサイドコードと通信します。例えば、リードスルーハンドラーを呼び出す必要がある場合、リードスルーハンドラーは.NET CLRプロセス内で実行され、データベースにアクセスしてデータを取得し、それをキャッシュに渡します。ライトスルー、ローダー、リフレッシャーについても同様です。つまり、アプリケーション全体のエクスペリエンスは.NETで実現されます。
Java版
さて、Java側に移りましょう。ここでも同じように、Javaのサーバーサイドコードがあります。 NCache 100% Javaクライアントがあり、アプリケーションサーバー上で動作します。.NETと同じように動作します。こちらはJava Editionです。例えば、Linux、Windows、Docker、Kubernetesなどで動作するJavaアプリケーションがあるとします。そのアプリケーションには NCache Javaクライアントは、先ほども述べたように100%ネイティブJavaです。このJavaクライアントは.NETクライアントと完全に同一です。また、 NCache .NETクライアントと同じ方法でクラスタリングするには、 NCache独自のソケットプロトコルと NCache サーバーは、サーバー側の Java コードが独自の JVM 上で実行されるように設計されています。
つまり、開発、テスト、デバッグはすべてネイティブJVMプロセス内で行われます。そして、このキャッシュプロセスは、いわゆるリードスルーハンドラーを呼び出します。リードスルーハンドラーは、例えばOracleやDb2、あるいはSQL Serverデータベースにアクセスしてデータを取得し、キャッシュプロセスに渡します。ここでも、高性能なインメモリRPCが使用されます。つまり、.NETとJavaのコードをそれぞれ独自のネイティブプロセスにカプセル化するアーキテクチャを持つことによって、 NCache Java と .NET の両方にネイティブ スタックを提供できます。
また、Javaアプリケーションの場合は、WindowsまたはMac OSで開発を行う必要があるかもしれません。 NCache 完全にサポートしている場合、またはLinuxを使用している場合は、.NETユーザーよりもDockerとKubernetesを使用する可能性が高くなります。 NCache Dockerイメージを提供し、Kubernetes、Azure AKS、AWS EKS、Google GKE、Red Hat OpenShiftも完全にサポートしています。非常にシームレスにご利用いただけます。
そう、 NCache 非常にユニークです。ネイティブな.NETエクスペリエンスとネイティブなJavaエクスペリエンスを同時に提供します。Java開発者であれば、非Java製品を使っているという感覚がなく、.NET開発者であれば、非.NET製品を使っているという感覚がありません。これが.NETの素晴らしい点です。 NCache 設計方法です。
動的クラスター
ピアツーピアアーキテクチャ（自己修復）
- 単一障害点なし（マスター/スレーブなし）
- クラスターコーディネーター 最も古いノード、次に古いノードが自動的に後継ノードとなる
さて、それでは 動的クラスタリング の一部 NCache 高可用性のためのアーキテクチャです。少し待ってください。まずはダイナミッククラスタについてです。ここで「クラスタ」という言葉を使うとき、Kubernetesクラスタや他のオペレーティングシステムレベルのクラスタを意味するわけではありません。これは NCache独自のTCPベースのクラスタです。このクラスタはピアツーピアアーキテクチャを採用しています。ピアツーピアとは、マスターもスレーブもないことを意味します。マスター/スレーブの問題は、マスターがダウンするとスレーブが動作不能になるか、機能が制限されることです。一方、ピアツーピアアーキテクチャでは、すべてのノードの能力が同等です。当然のことながら、クラスタコーディネーターノードが存在し、これが最も古いノードです。このノードがダウンすると、次に古いノードが自動的にクラスタコーディネーターとして選択されます。クラスタコーディネーターはクラスタメンバーシップを管理します。分散マップ、クラスタの健全性、その他多くの管理を行います。これらについては後ほど詳しく説明します。
動的クラスター
- サーバーの追加/削除 実行時
- クラスターメンバーシップ 実行時の伝播
- キャッシュやクライアントアプリケーションを停止することなく
ダイナミッククラスタリングとは、キャッシュやアプリケーションを停止することなく、実行時にクラスタにサーバーを追加したり削除したりできることを意味します。中断は一切ありません。例えば、クラスタに新しいサーバーを追加すると、クラスタのメンバーシップは実行時に更新され、その実行時情報がクライアントに伝播されます。これについては次のスライドでもう少し詳しく説明します。
クラスタ接続フェイルオーバー
- 接続の自動回復（再試行, タイムアウト)
- 心拍 接続の切断を検出する
クラスタ接続のフェイルオーバー機能もあります。これらはソケットであるため、クラスタサーバーは通常、同じサブネット内にあり、互いにかなり近い距離にありますが、必ずしもそうとは限りません。異なるリージョンにサーバーを展開しているお客様もいらっしゃいますが、それでも問題なく動作します。ただし、ほとんどの場合、 NCache サーバーは互いにかなり近い距離にあるはずです。それでも接続に失敗する可能性があります。その場合は NCache 再試行ロジックとタイムアウト、ハートビートロジックがあり、これらはすべて動的な動作を保証するためのものです。
動的クライアントと動的構成
動的クライアント接続
- 実行時にクライアントを追加/削除する
- 止まることなく キャッシュまたはクライアントアプリケーション
動的アーキテクチャのもう一つの部分は、動的クライアントです。このように、クラスタは実行時にサーバーを追加または削除する機能を持っていましたが、同様に、実行時にクライアントを追加または削除する機能も持っています。クライアントとはどういう意味でしょうか？クライアントとは NCache アプリケーションサーバー、つまりWebサーバー上で動作するクライアントは、アプリケーションが通信する部分です。つまり、実行時にクライアントを追加したり削除したりしても、アプリケーションを停止する必要はありません。 NCache、キャッシュ、またはアプリケーションを中断することなく実行できます。これが最初の部分です。
動的構成
- クラスタメンバーシップ、キャッシュトポロジ、分散マップ
- ランタイム すべてのクライアントとサーバーへの伝播
2つ目の部分は動的構成です。前のスライドで述べたように、クラスターにサーバーを追加すると、クラスターのメンバーシップが変更されます。これは接続中のすべての既存クライアントに伝播され、接続先となる新しいサーバーがあることをクライアントが認識します。そのため、キャッシュトポロジに基づいてクライアントが選択した場合、そのサーバーにも接続できます。さらに、トポロジによっては分散マップが存在する場合があります。分散マップは、パーティションキャッシュとパーティションレプリカキャッシュに使用されます。サーバーを追加すると、分散マップも更新され、実行時に伝播されます。また、他にも様々な構成変更があります。ホットアプライ機能も実行可能で、これも実行時に伝播されます。これが2つ目の部分です。
クライアント接続フェイルオーバー
- サーバーとのクライアント接続の場合
- 接続の自動回復（再試行, タイムアウト)
- 生き続ける 接続の切断を検出する
3つ目は、クライアント接続フェイルオーバーです。これはクラスタ接続フェイルオーバーと同じ仕組みです。しかし、クライアントはクラスタサーバーに常に近いとは限らないため、実際にはより一層必要になります。また、間にルータやファイアウォールが存在する可能性もあります。そのため、クライアントとクラスタ間の接続が切断される可能性が高くなります。そこで、 NCache 非常にインテリジェントな再試行機能とタイムアウト機能を備えています。また、キープアライブ機能も備えているため、接続が切断されてもクライアントは自動的に再接続し、接続を維持します。 NCache 集まる。
スプリットブレインの検出と回復
もう一つの重要なトピックは、 NCache アーキテクチャはスプリットブレインです。スプリットブレインはクラスタ内で発生する可能性のある現象です。
接続が切断されるとスプリットブレインが発生する
- 接続の再試行が失敗したときに形成されるサブクラスター
- 各サブクラスタは独自のコーディネータを選択し、他のサブクラスタは死んでいると想定する
スプリット・ブレインが発生するのは、例えば1台のサーバーで構成された健全なクラスターがある場合です。これらのサーバー間の接続が何らかの理由で切断されると、スプリット・ブレインが発生します。ネットワーク接続はいつでも切断される可能性があります。これはよくあることです。スプリット・ブレインが発生すると、サブクラスターが形成されます。例えば、この場合はスプリット2、スプリット3、スプリットXNUMXと続きます。各サブクラスターは、自身を生存者と認識します。そのため、独自のクラスター・コーディネーターを作成し、独立したクラスターになります。
スプリットブレイン検出
- スプリット 再接続時に検出 サーバー付き
- 分割回復プロセスが開始されました
しかし、これらの分割はすべて、かつては健全なクラスタの一部であったことを記憶しており、これらのサーバーは自発的に離脱したわけではなく、円滑に離脱したわけでもありません。「ノードの離脱」は実行していません。 NCache 管理ツールは接続が切断されたと判断し、これらのサーバーを継続的に検索してネットワーク接続が回復するかどうかを確認します。そして、ほとんどの場合、5分、10分、30分、1時間後には接続が回復する可能性が高くなります。
スプリットブレインリカバリー
- サブクラスター 反復的にマージ 最大から最小まで
- 小規模なクラスタクライアントは大規模なクラスタに移動されます
- 小さなクラスターのデータが失われました
そうなると、スプリットブレインリカバリが実行されます。そして、これらの分割されたクラスタが統合されます。これらのサブクラスタは、最大のものから最小のものへと反復的に統合されます。当然ながら、独立したクラスタになったため、一部のデータが失われます。しかし、これはすべて、指定したルールに基づいて自動的に実行されます。
スプリットブレインについては別の記事で詳しく説明しています ビデオ これは概要を示すもので、非常に重要な機能であり、 NCache クラスターは健全な状態を維持し、スプリット ブレインが発生しても回復できます。
キャッシングトポロジ
さて、それでは キャッシングトポロジキャッシュトポロジとは、本質的にはデータストレージ、レプリケーション戦略、そしてクライアント接続戦略を指します。トポロジには4種類あり、パーティションキャッシュ、パーティションレプリカ、レプリケートキャッシュ、ミラーキャッシュです。ここではパーティションキャッシュについて見ていきましょう。
パーティション化されたキャッシュ
- キャッシュをパーティションに分割 実行時に
- キャッシュサーバーごとに1つのパーティション。キャッシュクラスター全体に100個のバケットが均等に分散されます。
- サーバーの追加/削除によりパーティションが作成/削除されます
パーティション化されたキャッシュ 基本的に、キャッシュ全体がパーティションに分割され、各サーバーに100つのパーティションが存在します。そして、バケットという概念があります。つまり、各パーティションにはバケットが存在します。キャッシュ全体で合計XNUMX個のバケットがあります。つまり、パーティションの数に応じて、バケットは均等に分割されます。
これらのパーティションは実行時に作成されます。これが重要な点です。サーバーを追加すると、パーティションが作成されます。例えば、サーバーが100台の場合、パーティションはXNUMXつしかなく、XNUMX個のバケットはすべてそのパーティションに格納されます。実行時にXNUMX台目のサーバーを追加すると、前のスライドで説明したように、クラスターメンバーシップ情報が更新されるだけでなく、分散マップも更新されます。分散マップとは、基本的にどのパーティションにどのバケットが含まれているかを示すマップです。つまり、XNUMX台目のパーティションを追加すると、分散マップも変更されます。分散マップは、実際にはバケットにマッピングされたハッシュマップです。ハッシュマップの値はバケットごとに異なります。これは、追加したデータの量によって変化することはなく、サーバーの数やパーティションの数が変更された場合、またはデータの再バランス調整を行った場合にのみ変化します。つまり、パーティションは動的です。
動的データバランシング
- バケットを他のパーティションに移動する 実行時に
- パーティションが追加/削除された場合
- パーティションが過負荷になった場合
2つ目は、動的なデータバランス調整が行われることです。これはすべてハッシュマップベースであるため、使用したキーの種類によっては、一部のバケットに他のバケットよりも多くのデータが割り当てられる可能性があります。その結果、一部のパーティションがほぼ満杯になり、他のパーティションがほぼ空になることがあります。そして、そうなると NCache しきい値を設定できる機能があります。例えば、パーティションの使用率が80%を超えたら、20%、10%、5%などを削除します。削除ではなく、動的にバランス調整するということです。つまり、データバランス調整とは、パーティション1からバケットを取得し、他のパーティションにコピーまたは移動することを意味します。つまり、データバランス調整によって、データとすべてのパーティションがほぼ均等に保たれます。
クライアントはすべてのパーティションに接続します
- 使用することにより、 分布図 & クラスターメンバーシップ
- クライアントは自動的に接続します 新しいパーティション 実行時に
パーティションキャッシュでは、すべてのクライアントがすべてのパーティションまたはすべてのサーバーに接続します。これは、3回の呼び出しで必要なアイテムに直接アクセスするためです。例えば、クライアントが1つのサーバーにのみ接続されていて、アイテム番号1を取得したい場合、サーバー2と通信し、サーバーXNUMXはサーバーXNUMXにアクセスしてアイテムを取得します。これはXNUMXホップ操作であり、クライアントがデータの場所に直接アクセスする場合ほど最適化されていません。クライアントがデータの場所を把握できるのは、分散マップのおかげです。分散マップは、クライアントがデータの場所を把握し、そこから直接アクセスしてデータを取得できるようにするために作成されるものです。
パーティションキャッシュにはレプリケーション機能がありません。そのため、いずれかのサーバーがダウンするとデータが失われます。後ほど説明する「パーシスタンス」機能を使用する以外に、これを防ぐ方法はありません。パーシスタンス機能を使用すると、パーティションキャッシュでもデータが失われることはありません。
パーティション-レプリカキャッシュ
パーティションのレプリカ（動的）
- 実行時に作成 パーティションが追加/削除されたとき
- 別のサーバーに存在します パーティションよりも
- 顧客は彼らと話をしないクライアントはパーティションと通信します。
パーティションはレプリカと通信/複製します。
次のトポロジーはパーティション・レプリカ・キャッシュです。これは、両方のメリットを享受できるため、弊社で最も人気のあるトポロジーです。スケーラビリティを実現するパーティション分割と、高可用性を実現するレプリケーションの両方を実現します。そのため、データ損失はありません。例えば、パーティションキャッシュと同様に、すべては同じですが、各パーティションのレプリカが別のサーバー上に存在します。つまり、パーティション1はサーバー1上にあり、そのレプリカはレプリカ2と呼ばれ、この場合はサーバーXNUMX上にあります。つまり、パーティションが動的に作成されるのと同様に、レプリカもパーティションが追加または削除された実行時に作成されます。そして、それらは常に別のサーバー上に存在します。
もう一つの特徴は、すべてのレプリカがパッシブであるということです。パッシブとは、クライアントがレプリカと直接通信しないことを意味します。クライアントはパーティションとのみ通信し、パーティションはレプリカを更新します。つまり、パーティションで何かを更新すると、パーティションがレプリカを更新します。そして、その更新はデフォルトで非同期です。非同期であるのは、より高速になるためです。まず、クライアントはレプリケーションの実行を待つ必要がありません。次に、一括レプリケーションを実行できます。つまり、数百または数千の更新をまとめて、レプリカに一度に移動またはプッシュできます。このネットワーク通信のコストは、データを結合するよりもはるかに高速または高くなるためです。
非同期/同期レプリケーション
- 非同期（デフォルト）: 一括コピー。データが多少失われる可能性がありますが、処理速度は速くなります。
- 同期: 操作は完了しました。レプリケーションが失敗した場合、操作は失敗します。
しかし、非同期レプリケーションは当然ながら常に一貫性があるわけではありません。結果的に一貫性が保たれますが、これはおそらく95%から99%の状況では十分なものです。非常に機密性の高いデータを扱うケースは1%から5%程度でしょう。そのため、非同期レプリケーションではなく同期レプリケーションが望ましいでしょう。そこで、Sync Replicationという機能を有効にすると、クライアントがパーティション内のアイテムを更新しても、パーティションがレプリカを更新するまでその操作は完了しません。つまり、そのレプリケーションが失敗すると、操作も失敗します。つまり、操作が成功すればレプリケーションも成功するということです。これは非常に重要な機能です。
動的データバランシング（レプリカ上）
- パーティション上でもレプリカ上のデータバランスがとれる
そして最後に、パーティショントポロジやパーティションキャッシュトポロジと同様に、レプリカにも動的データバランシングが行われます。パーティションが動的にデータバランシングされると、レプリカは常にパーティションの同一のコピーであるため、レプリカもそれに一致する必要があります。そのため、レプリカもデータバランシングを受けることになります。
動的パーティション化
では、動的パーティショニングが実際にどのように行われるのか、簡単に見ていきましょう。例えば、6台のサーバーからなるクラスターがあり、そこにXNUMXつのアイテムがあり、XNUMX台目のサーバーを追加したいとします。これは別のユースケースなので、まだデータの追加はしていません。これは、ノードを追加するとデータが他のパーティションに移動する仕組みです。
例えば、ノードを追加するとします。これで3台目のサーバーができました。パーティション3が作成され、パーティション1はパーティション2とパーティション1からデータを取得します。つまり、パーティション2から一部データを取得し、パーティション3から一部データを取得します。例えば、パーティション1からアイテム4、パーティション2からアイテム3を取得して、パーティションXNUMXになったとします。
パーティション 3 になったので、レプリカは別のサーバーに置く必要があるため、たとえば、サーバー 1 に配置されることになります。つまり、サーバー 1 にレプリカ 2 があった場合、レプリカ 3 に変換され、レプリカ 2 はサーバー 3 に移動されます。そのため、たとえば、レプリカ 3 には 3、4、4 ではなく 5、6 が含まれ、レプリカ 2 には 5、6 が含まれるようになります。これらはすべて、アプリケーションに中断が発生することなく、実行時に動的に実行されます。
同じことが逆方向にも起こります。サーバーがダウンした場合、例えば3つのパーティションがあったとします。 NCache クラスターのサーバー3がダウンしました。これは、あなたがダウンさせたか、サーバー自体がダウンしたかのどちらかです。その瞬間、パーティション3は利用できなくなり、レプリカ3はアクティブになります。ご覧の通り、色が変わりました。通常、レプリカはアクティブではありませんよね？アクティブになるのはパーティションだけですが、今はパーティション化されています。ただし、これは一時的なものです。同じマシンにXNUMXつのパーティションが存在するとレプリカがなくなるのは避けたいからです。
ここで、これがパーティション1とマージされます。つまり、アイテム3はパーティション1に、アイテム4はパーティション2にマージされます。そして、状況はこのようになり、レプリカ3はレプリカ2になります。つまり、同じことが実行時に逆方向にも起こります。これは、ダイナミック・パーティショニングの非常に柔軟で動的な機能です。この動的機能によって、高可用性が実現されます。 NCache.
メンテナンスモード
動的パーティショニングは非常に便利で強力ですが、再パーティショニングをしたくない場合もあります。その一つが定期メンテナンスです。例えば、オペレーティングシステムのパッチを適用する際に、サーバーを5分か10分ダウンさせるとします。キャッシュクラスタ全体には数十ギガバイトのデータがあるかもしれません。そのため、その5分間だけ再パーティショニングを行い、その後ノードを復旧させたときに再度再パーティショニングを行うのは避けたいものです。そこで、スケジュールメンテナンス機能を有効にします。 NCache その場合、このノードを停止するときには、再度管理ツールを使用して停止する必要があり、このレプリカがアクティブになることがトリガーされますが、再パーティション化は行われません。
つまり、パーティション1のレプリカ3、パーティション2のレプリカ1、そしてこのレプリカ3という3つのサーバー構成のままです。このレプリカ1は実際にはパーティション2なので、アクティブで稼働しています。パーティション3はバックアップされていますが、高可用性ではありません。パーティション5とレプリカ10にはバックアップがありません。しかし、これは一時的なもので、必要なのはXNUMX分かXNUMX分だけです。このサーバーが復旧すると、以前の状態に戻り、パーティションが再び稼働するとレプリカに戻ります。これが、スケジュールされたメンテナンス機能の仕組みです。 NCache 作品。
複製されたキャッシュ
次のトポロジーは 複製されたキャッシュこのトポロジでは、2台以上のサーバーを構成できます。各サーバーはキャッシュ全体のコピーを保持し、すべてのサーバーがアクティブ状態にあるため、すべてのサーバーにクライアントが接続されています。ただし、このトポロジでは、各クライアントは1台のサーバーにのみ接続します。そのサーバーがキャッシュ全体を保持しているためです。そのため、パーティションやパーティションレプリカのように、2台のサーバーに接続する必要はありません。
このトポロジでは、キャッシュ全体がすぐそこにあるため、すべての読み取りは超高速です。しかし、更新は同期的に行う必要があります。なぜなら、これら1つのサーバーは両方ともアクティブサーバーであるため、同じアイテムが同時に更新される可能性があり、データ整合性の問題が発生することは避けたいからです。そのため、更新は同期方式で行われます。同期方式では、インデックススキーム、インデックス、そして発行されるシーケンス番号のようなものがあり、すべてのアイテムが同じ順序で更新されます。これにより、常に正しい方法で更新を行うことができます。ただし、同期更新では、クライアントがアイテム2を更新すると、このサーバーはアイテム1にアイテム1の更新を通知します。両方のサーバーがアイテムXNUMXの更新に成功した場合にのみ更新が成功し、制御が戻ります。つまり、パーティショントポロジやパーティションレプリカトポロジほど高速ではありませんが、操作は保証されており、更新が成功すれば、常にすべてのサーバーで更新が実行されます。
このトポロジは、読み取り集中型の操作に適しています。2サーバー構成のクラスターでは、書き込みもかなり高速です。パーティションレプリカほど高速ではありませんが、ほとんどの状況では十分な速度です。ただし、サーバーを追加すると更新のパフォーマンスが低下します。実際には、同期更新が必要なサーバーが増えるため、速度が低下します。そのため、このトポロジには独自の用途があり、私たちはこれを維持しています。多くのお客様が特殊な状況で使用しています。
ミラーリングされたキャッシュ
4番目のトポロジーは ミラーリングされたキャッシュこれも非常に特殊なトポロジです。2ノードのみのトポロジで、アクティブノードとパッシブノードがあります。アクティブノードはキャッシュ全体を保持し、そのキャッシュのコピーがパッシブノードに配置されます。すべてのクライアントはアクティブノードに接続し、アクティブノードのすべての情報を更新します。更新内容は非同期でパッシブノードにミラーリングまたは複製されます。この非同期性により、パーティションレプリカと同様に非常に高速になります。
このトポロジでは、アクティブノードがダウンした場合、パッシブノードが自動的にアクティブになり、すべてのクライアントはパッシブノードまたは新しくアクティブになったノードに自動的に移行します。これにより、ダウンタイムや中断は発生しません。これは自動フェイルオーバーサポートと呼ばれ、まさにその通りです。そして、アクティブノードが復旧すると、当然のことながら、このノードも再びアクティブになり、逆の順序で同じことが起こります。
ミラートポロジーは特殊なケースで非常に便利です。2台のサーバーを超えて拡張することはできませんが、すべてのクライアントがここに接続し、別のマシンにレプリカを作成できるという点で、独自の用途があります。例えば、災害復旧などの状況で使用できます。
ライブ永続性
もう一つの非常に強力な機能は NCache と呼ばれる ライブ永続性ライブパーシスタンスは、パーティショントポロジとパーティションレプリカトポロジでのみ利用可能です。ライブパーシスタンスは、実行時にキャッシュを更新すると、パーシスタンスストアも即座に更新されます。パーシスタンスストアへの更新は非同期です。そのため、アプリケーションのパフォーマンスに影響を与えることはありません。 NCache パフォーマンス。つまり、アプリケーションが非常に高速に動作できるのはそのためです。永続化はバケットレベルで行われます。つまり、NoSQLドキュメントストアに保持されるキャッシュ全体を表す100個のバケットがあります。これはファイルベースのストアなので、サーバーベースのストアではありません。NoSQLデータベースサーバーではなく、NoSQLドキュメントストアです。 NCache 使用する。すべてのサーバーに共通の場所で使用できます。 NCache クラスター化し、それによってすべてが同じ永続ストアに依存できるようになります。
この機能の利点、そしてこの機能が提供されている理由として挙げられるのは、まず第一に、永続化の対象が何であれ、例えばキャッシュ全体を永続化できるということです。キャッシュ全体は常に永続化されます。キャッシュ内で更新している内容は、数ミリ秒の違いはあるものの、永続ストアにも保存されていると言えます。そのため、その内容を取得して別のキャッシュにリロードしたり、すべてのサーバーがダウンした場合でも、永続ストアから再起動したりできます。ごくわずかなデータを除いて、データが失われることはありません。また、ある環境から別の環境にキャッシュを移行したい場合も、簡単に行うことができます。
もう 1 つの利点は、パーティション トポロジとパーティション レプリカ トポロジの可用性が向上することです。パーティション トポロジについては後ほど詳しく説明します。先ほど説明したように、Partitioned Cache にはレプリケーションがないため、いずれかのパーティション、いずれかのサーバーがダウンすると、そのパーティションは失われます。永続性がオンになっている場合は、パーティションは失われません。データのコピーがこれらのバケットにも保持されているからです。つまり、このサーバーがダウンすると、メモリ内のバケットは他のサーバーに再割り当てされますが、当然ながらデータは保持されません。他のサーバーは、これらのバケットが空のバケットであり、そのバケットに永続性ストアにデータが存在することを認識するため、永続性ストアからデータを再ロードします。
つまり、Partitioned-Cache を使用しているにもかかわらず、サーバーがダウンしてもデータが失われることはありません。また、Partitioned-Cache と同様に、パーティションレプリカと同様のメリットが得られます。
ここで得られるメリットは、より多くのメモリを使用できることです。レプリカ用にはより多くのメモリを割り当てる必要があるため、キャッシュにより多くのデータを保存できます。レプリカ用にはメモリを割り当てる必要はありませんが、永続ストアにはメモリを割り当てる必要があります。これがパーティションキャッシュのメリットです。パーティションレプリカにもメリットがあります。興味深いのは、これは既に高可用性を実現しているものの、高可用性が実現されるのは1台のサーバーが同時にダウンした場合のみであるということです。しかし、パーティションレプリカであっても永続性がなければ、例えば2台のサーバーが同時にダウンするとデータが失われます。なぜなら、各パーティションには1つのコピーしか存在しないため、2台のサーバーがダウンすると、許容できる以上のサーバーを失うことになるからです。永続性があれば、問題は発生しません。永続ストアからすべてのデータを再ロードするだけで済みます。
どちらの場合も、永続ストアからデータをロードする際には、以前は3台のサーバーがあったのが、今は2台になっていることを念頭に置く必要があります。データが2台のサーバーに収まりきらないほど大きくなる場合もあり、その場合は残りの2台のサーバーに3台分のデータ量に対応できるだけのメモリがあるか確認する必要があります。これが唯一の制限です。それ以外は、永続化によってパーティションキャッシュとパーティションレプリカキャッシュの両方に真の価値がもたらされます。
クライアントキャッシュ
さて、もう一つの非常に重要な特徴は NCache と呼ばれる クライアントキャッシュ分散ストア環境でInProc速度を実現します。例えば、分散ストアでは NCache クラスタ、つまりアプリケーションはここで実行されます。これは通常、データベースなどのキャッシュ上に配置されます。クライアントキャッシュは、分散キャッシュのシナリオでよく使用されます。クライアントキャッシュは、このキャッシュクラスタ上のキャッシュで、アプリケーションのすぐ近くに配置されます。アプリケーションサーバーまたは NCache クライアントボックスです。好みに応じてInProcまたはOutProcを選択することもできます。InProcキャッシュは、データをデシリアライズされたオブジェクト形式でヒープ上に保持するため、非常に高速です。つまり、オブジェクトがヒープ上に存在しているようなものです。さらに高速化することも可能です。
つまり、InProcキャッシュは超高速でありながら、同時に同期されているという利点がある。 NCache クラスターです。同期の仕組みは、クライアントキャッシュに保存されているデータはすべてクラスターが認識することです。つまり、このクライアントキャッシュに保存されているデータがクラスター内の別のクライアントによって更新されると、クラスターはそのクライアントキャッシュに更新を通知します。そして、そのクライアントキャッシュは非同期的に更新されます。もちろん、数ミリ秒の遅延はありますが、前述の通り、ほとんどの場合は結果整合性モデルを採用しており、99%のケースで許容範囲内です。
それが受け入れられないなら NCache 楽観的同期はデフォルトで、数ミリ秒の遅延が発生し、技術的には古いデータが存在する状況が発生する可能性があります。これは前述の通り、99%の確率で問題ありません。しかし、もし問題が起こり、データが非常に機密性の高いものであってもクライアントキャッシュを使用したい場合は、悲観的同期機能を使用できます。悲観的同期では、アプリケーションがクライアントキャッシュから何かを取得する前に、クライアントキャッシュはデータの新しいバージョンがあるかどうかのみを確認します。これは、データ自体を取得するよりも高速です。 NCache 複数のバージョン情報を保持します。そして、そのデータの新しいバージョンがある場合はクライアントキャッシュがそれを取得し、ない場合はクライアントキャッシュからそれを返します。
コードを変更することなく使用できるクライアントキャッシュです。環境にプラグインするだけで、読み取り負荷の高い状況に適しています。読み取り負荷が高い場合は少なくとも5:1、10:1の比率が理想的ですが、例えばWebセッションのように1:1の比率の場合、クライアントキャッシュは全く役に立ちません。実際、推奨されません。
WANレプリケーション
マルチゾーン/マルチリージョン
さて、もう一つの NCache はどこ NCache ありません WANレプリケーション アプリケーションのマルチゾーンまたはマルチリージョン展開に対応します。例えば、災害復旧（DR）用にアプリケーションを2つの異なるサイトに展開し、1つはアクティブ、もう1つはパッシブにすることができます。そして、このアプリケーションは NCache すでに稼働しているアプリケーションがあり、ここには稼働していないアプリケーションがあります。しかし、このサイトがダウンした場合でも、すぐに負荷を引き継げるようにする必要があります。そこで、ブリッジを設置することができます。ブリッジとは、2ノードのクラスタで、同じマシン上に配置できます。 NCache メインのキャッシュ、あるいは専用のキャッシュを別に用意することもできます。それはあなた次第です。そして、このキャッシュで更新されたものはすべて、WANを介して別のキャッシュに非同期的に複製されます。これがアクティブ/パッシブ方式です。
アクティブ/アクティブでも同じことができます。例えば、このサイトがアクティブな状況で、両方のサイトが互いに更新できるアクティブ/アクティブでも全く同じことができます。この場合、競合が解決されるか、発生する可能性があります。競合とは、同じアイテム、同じキーが両方のサイトで同時に更新されることを意味します。このような状況が発生した場合、ブリッジはデフォルトで「最終更新を優先する」ロジックを適用します。つまり、タイムスタンプが新しい更新が優先されます。しかし、例えば、必要に応じて、競合解決と競合解決ハンドラーを提供することもできます。これはブリッジが呼び出す.NETまたはJavaコードで、データまたはオブジェクトの両方のコピーをその解決ハンドラーに渡します。そして、コンテンツを分析してどちらがより適切かを判断します。そして、「この更新を優先する」と判断すると、その更新が両方のサイトに適用されます。これが両側に適用されている限り、競合は発生しません。
その NCache 3つ以上のサイトをアクティブ/アクティブ、アクティブ/パッシブ、あるいはそれらの組み合わせで提供できます。例えば、少なくとも1つのアクティブサイトが必要ですが、それらはすべてパッシブにすることも、すべてアクティブにすることも、アクティブとパッシブの組み合わせにすることもできます。また、アクティブサイトが複数ある場合も同様に、競合解決が可能です。
コンテナ (Docker および Kubernetes)
最後に、コンテナはDockerとKubernetesで非常に人気が高まっています。 NCache 今のところ、.NETやWindowsよりもJavaやLinuxで人気があるため、当然サポートされていますが、これは時間とともに変わっていくでしょう。いずれにせよ、 NCache どちらの環境でも問題なく処理できます。例えば、典型的な例は次のとおりです。 Kubernetesのデプロイメント NCache.
これが NCache 展開。 NCache 独自のDiscovery Serviceが備わりました。これらはスケール可能なポッドで、Kubernetesクラスタ内のアプリケーションは NCache クライアントはAzure、AKS、AWS、EKS、Google GKE、Red Hat OpenShiftのいずれかになります。Red Hat OpenShiftは通常、AWS、Azure、Googleなどの他のクラウド、または他のクラウドですが NCache これらすべてをサポートしています。また、このPodはKubernetesでより一般的なLinuxである可能性があり、 NCache 問題なく動作します。また、アプリケーションはLinuxでもWindowsでも動作します。つまり、LinuxでもWindowsでも、LinuxでもWindowsでもどちらでも構いません。
Docker / Kubernetes (マルチゾーン)
WANレプリケーションも同様に機能します。例えば、クラウドであれば複数のアベイラビリティゾーンを利用できる場合、マルチゾーンKubernetesを構築したいとします。
そこで私たちがお勧めするのは、Kubernetesクラスターを1つ作成し、 NCache デプロイメントは、アクティブ/アクティブ、またはアクティブ/パッシブにすることができます。ブリッジは完全にここに配置することも、完全にここに配置することもできます。あるいは、ブリッジを分割して、一部をこのゾーンに、一部をあのゾーンに配置することも可能で、その場合、レプリケーションは非同期で実行されます。
本日のトピックはこれでほぼ網羅できたと思います。ぜひ当社のウェブサイトをご覧いただき、 NCache プレイグラウンド これはブラウザからライブ実行コピーを使用する非常に迅速かつ簡単な方法です NCache2ノード構成も可能 NCache インストールの手間なく、すべてのツールを備えたクラスタを構築できます。または、準備が整ったら、こちらにアクセスして 登録してダウンロード どちら NCache Enterprise for .NET Edition または NCache Enterprise for Java Edition。前述のとおり、Linux 用の .tar.gz、.msi、または Docker のいずれかを入手できます。Docker イメージをプルするだけで済みます。 NCacheこれで私のプレゼンテーションは終了です。ありがとうございました。