Data Grid には、キャッシュ用にリモートと組み込みの 2 つのデプロイメントモデルがあります。どちらの導入モデルでも、アプリケーションは、従来のデータベースシステムと比較して、読み取り操作の待ち時間を大幅に短縮し、書き込み操作のスループットを向上させてデータにアクセスできます。

Red Hat は、ほとんどのデプロイメントにはサーバー/クライアントアーキテクチャーを推奨します。データレイヤーはビジネスロジックから分離されているため、リモートキャッシュでは、デプロイメントがより高速になります。Data Grid Server は、開発コストを削減できるように、監視および可観測性やその他の組み込み機能を提供します。

図1.1 リモートキャッシュデプロイメントモデル

Data Grid は、永続ストレージにあるデータのすべてのアプリケーション要求を処理します。

インラインキャッシュでは、Data Grid はキャッシュローダーとキャッシュストアを使用して、永続ストレージのデータを操作します。

図1.2 インラインキャッシュ

Data Grid は、アプリケーションが永続ストレージから取得するデータを保存し、永続ストレージに対して読み取り操作の数を減らし、後続の読み取りの応答時間を増やします。

図1.3 サイドキャッシュ

サイドキャッシュでは、アプリケーションは永続ストレージから Data Grid クラスターにデータを追加する方法を制御します。アプリケーションがエントリーを要求すると、以下が発生します。

Data Grid は、一貫性のあるハッシュ技術を使用して、クラスター全体でキャッシュ内の各エントリーの固定のコピーを保存します。分散キャッシュは、データ層を線形にスケールでき、容量をノードに参加として増やすことができます。

分散キャッシュは、Data Grid クラスターに冗長性を追加し、耐障害性と耐久性の保証を提供します。Data Grid デプロイメントは通常、正常なシャットダウンおよびバックアップから復元するためにクラスターの状態を保持するように永続ストレージとの統合を設定します。

図1.4 分散キャッシュ

Data Grid は、Red Hat Build of Quarkus、Red Hat JBoss EAP、Red Hat JBoss Web Server、および Spring 上に構築されたアプリケーションに外部キャッシュを提供できます。これらの外部キャッシュは、HTTP セッションやその他のデータはアプリケーションレイヤーとは別に保存されます。

Data Grid にセッションを外部化すると、以下の利点があります。

図1.5 セッションの外部化

Data Grid は、地理的に分散したデータセンターで実行されているクラスター間および異なるクラウドプロバイダー間でデータをバックアップできます。クロスサイトレプリケーションは、Data Grid にグローバルクラスタービューを提供し、以下を提供します。

図1.6 クロスサイトレプリケーション

Data Grid には非常に多くの設定可能な組み合わせが含まれているため、すべてのユースケースに対応するパフォーマンスメトリックの式を 1 つに決定することは不可能です。

Data Grid パフォーマンスおよびサイジングガイド ドキュメントの目的は、Data Grid デプロイメントの要件を決定するのに役立つユースケースとアーキテクチャーに関する詳細を提供することです。

さらに、次の相互に関連する要因を考慮し、Data Grid に適用してください。

さまざまな組み合わせと未知の外部要因の数を考えると、すべての Data Grid のユースケースを満たすパフォーマンス計算を提供することは不可能です。前述の要因のいずれかが異なる場合、あるパフォーマンステストを別のテストと比較することはできません。

パフォーマンスメトリックを限定して収集する Data Grid CLI を使用して、基本的なパフォーマンステストを実行できます。要件にあった結果をテストで出力されるように、パフォーマンステストをカスタマイズできます。テスト結果は、Data Grid キャッシング要件の設定とリソースを決定するのに役立つベースラインメトリックを提供します。

現在の設定のパフォーマンスを測定し、要件を満たしているかどうかを確認します。要件が満たされていない場合は、設定を最適化し、パフォーマンスを再測定してください。

Data Grid デプロイメントのプランニングでは、データセットのサイズを計算してから、適切なノード数と、データセットを保持する RAM の容量を測定する必要があります。

以下の式を使用して、データセットの合計の概算サイズを予測できます。

Data set size = Number of entries * (Average key size + Average value size + Memory overhead)

分散キャッシュのデータセットサイズ

分散キャッシュには、データセットサイズを判断するために追加の計算が必要です。

通常の運用条件では、分散キャッシュは、設定する 所有者の数 と等しい各キー/値エントリーのコピーを多数保存します。クラスターのリバランス操作時に、追加のコピーがあるエントリーもあるので、所有者数 + 1 を算出してそのシナリオを許可する必要があります。

以下の式を使用して、分散キャッシュのデータセットサイズの推定を調整できます。

Distributed data set size = Data set size * (Number of owners + 1)

Distributed data set size <= Available memory per node * Minimum number of nodes

Planned nodes = Minimum number of nodes + Number of owners - 1

Distributed data set size <= Available memory per node * (Planned nodes - Number of owners + 1)

たとえば、サイズが 10KB の 100 万のエントリーを保存して、エントリーごとに 3 つの所有者を設定する計画を予定します。クラスター内の各ノードに 4 GB の RAM を割り当てる予定の場合には、以下の式を使用してデータセットに必要なノード数を判断できます。

Data set size = 1_000_000 * 10KB = 10GB
Distributed data set size = (3 + 1) * 10GB = 40GB
40GB <= 4GB * Minimum number of nodes
Minimum number of nodes >= 40GB / 4GB = 10
Planned nodes = 10 + 3 - 1 = 12

クラスター化された Data Grid キャッシュを複製または分散として設定できます。

読み取り操作 : 書き込み操作

アプリケーションによる書き込み操作を多くするか、読み取り操作を多くするか検討します。通常、分散キャッシュは書き込み操作で最適なパフォーマンスを、レプリケートキャッシュは読み取り操作で最適なパフォーマンスを実現できます。

所有者が 2 名のノード 3 つで設定されるクラスターの分散キャッシュに k1 を配置するには、Data Grid は k1 を 2 回書き込みます。レプリケートされたキャッシュで同じ操作を行うと、Data Grid は k1 を 3 回書き込みます。レプリケートキャッシュへの各書き込みの追加ネットワークトラフィックの量は、クラスター内のノード数と等しくなります。ノードが 10 個あるクラスターのレプリケートキャッシュでは、書き込みのトラフィクが 10 倍になるなどです。クラスタートランスポートのマルチキャストで UDP スタックを使用して、トラフィックを最小限に抑えることができます。

レプリケートキャッシュから k1 を取得するには、ノードごとに、ローカルに読み取り操作を実行できます。分散キャッシュから k1 を取得するには、操作を処理するノードはクラスター内の別のノードからキーを取得しないといけない場合があります。これにより、ネットワークホップが追加で発生し、読み取り操作が完了するまで時間が長くなります。

また、Hot Rod クライアントは、ニアキャッシュ機能を使用して、頻繁にアクセスされるエントリーをローカルメモリーで保持し、読み込みの繰り返しを回避することもできます。

データの保証

各ノードにすべてのエントリーが含まれるため、レプリケートキャッシュは分散キャッシュよりも、データが損失されないように保護されます。3 つのノードで設定されるクラスターでは、2 つのノードがクラッシュでき、複製キャッシュからデータが失われることはありません。

同じシナリオでは、所有者が 2 人の分散キャッシュでは、データが損失します。分散キャッシュによるデータの損失を回避するには、owners 属性を宣言するか、numOwners() メソッドで各エントリーの所有者をさらに設定し、クラスター全体でのレプリカ数を増してください。

クラスターのスケーリング

Data Grid クラスターは、ワークロードのニーズに合わせて水平的にスケーリングし、CPU やメモリーなどのコンピュートリソースをより効率的に使用します。この弾力性を最大限に活用するには、ノード数の増減でスケーリングすることでどの程度キャッシュの容量に影響があるかを検討する必要があります。

レプリケートキャッシュの場合は、ノードがクラスターに参加するたびに、データセットの完全なコピーを受け取ります。各ノードに全エントリーを複製すると、ノードの参加にかかる時間が長くなり、全体的な容量に制限が課せられます。レプリケートキャッシュは、ホストで利用可能なメモリー量を超えることはできません。たとえば、データセットのサイズが 10 GB の場合、各ノードに少なくとも 10 GB のメモリーが必要です。

分散キャッシュの場合は、クラスターの各メンバーがデータのサブセットのみを格納するため、ノードを追加すると容量も増加します。10 GB のデータを保存するには、所有者数が 2 つで、メモリーのオーバーヘッドを考慮しない場合には、利用可能なメモリーが 5 GB のノードを 8 個指定すると良いでしょう。追加のノードがクラスターに参加すると、分散キャッシュの容量が 5GB 増加します。

分散キャッシュの容量は、基盤となるホストで利用可能なメモリー量により、制限されることはありません。

同期または非同期のレプリケーション

Data Grid は、プライマリーの所有者がレプリケーション要求をバックアップノードに送信すると、同期または非同期に通信できます。

同期レプリケーションでは、Data Grid は、バックアップノードでレプリケーション要求の完了時に元のノードに通知します。Data Grid は、クラスタートポロジーの変更が原因でレプリケーション要求に失敗すると、操作を再試行します。他のエラーが原因でレプリケーション要求に失敗すると、Data Grid はクライアントアプリケーションの例外を出力します。

非同期のレプリケーションでは、Data Grid はレプリケーション要求の確認は行いません。これは、すべての要求が正常に実行されるのと同じ効果を持ちます。ただし、Data Grid クラスターでは、プライマリーの所有者のエントリーが正しく、Data Grid は今後のある時点でバックアップノードに複製を作成します。プライマリー所有者がクラッシュすると、バックアップノードにエントリーのコピーがない場合や、以前のコピーが含まれる可能性があります。

クラスタートポロジーが変更されたことが原因で、非同期のレプリケーションでデータの不整合が生じる可能性もあります。たとえば、プライマリー所有者が複数指定されている Data Grid クラスターについて考えてみましょう。ネットワークエラーまたはその他の問題により、1 つ以上のプライマリー所有者が予期せずにクラスターから退出するため、Data Grid により、どのノードがどのセグメントのプライマリー所有者であるかが更新されます。これが発生すると、一部のノードで以前のクラスタートポロジーを使用し、他のノードで更新されたトポロジーを使用することが理論的に可能です。非同期通信では、Data Grid が以前のトポロジーからのレプリケーション要求を処理し、書き込み操作から以前の値を適用する時間が短縮される可能性があります。ただし、Data Grid はノードクラッシュを検出し、このシナリオから多くの書き込み操作に影響が及ばないように、素早くクラスターのトポロジーの変更を更新します。

非同期レプリケーションでは、1 回にノードが処理できるバックアップの書き込み数を、考えられる送信者数だけに限定するため、非同期のレプリケーションを使用しても、書き込みのスループットは保証されません。同期レプリケーションにより、ノードはより多くの受信書き込み操作を同時に処理できるようになり、特定の設定では個別の操作の完了に時間がかかることが考慮され、合計スループットが多くなっています。

ノードがエントリー複製の要求を複数送信すると、JGroups はクラスターの残りのノードに一度に 1 つずつメッセージを送信するので、送信元のノード別の複製要求は 1 つだけ作成されることになります。つまり、Data Grid ノードは他の書き込み操作と並行して処理でき、クラスター内の他のノードから書き込みを行うことができます。

Data Grid は、クラスタートランスポート層で JGroups フロー制御プロトコルを使用して、バックアップノードへのレプリケーション要求を処理します。未確認のレプリケーション要求の数が、max_credits 属性 (デフォルトでは 4MB) で設定されたフロー制御のしきい値を超えると、送信元ノードで書き込み操作がブロックされます。これは、同期および非同期レプリケーションの両方に適用されます。

セグメント数

Data Grid は、データをセグメントに分割して、データをクラスター全体に均等に分散します。セグメントを均等分散すると、個別のノードのオーバーロードが回避され、クラスターのリバランス操作をより効率化します。

Data Grid はデフォルトで、クラスターごとに 256 ハッシュ領域セグメントを作成します。クラスターごとに最大 20 個のノードで設定されるデプロイメントの場合には、このセグメント数が理想的であるため、変更しないでください。

クラスターごとに 20 を超えるノードで設定されるデプロイメントの場合には、セグメント数を増やすと、データの詳細レベルが上がるので、Data Grid はクラスター全体に効率的に分散できるようにします。設定するセグメント数を算出するには、以下の式を使用します。

Number of segments = 20 * Number of nodes

たとえば、クラスターが 30 個ある場合は、600 セグメントを設定する必要があります。大規模なクラスターのセグメントを増やすことは、一般的には適切ですが、この公式でデプロイメントに適したおおよその数がわかります。

Data Grid が作成するセグメント数を変更するには、クラスターを完全に再起動する必要があります。永続ストレージを使用する場合は、キャッシュストアの実装によっては、StoreMigrator ユーティリティーを使用してセグメント数を変更する必要もあります。

セグメント数を変更すると、データが破損する可能性があるため、ベンチマーキングおよびパフォーマンスの監視で収集したメトリックをもとに、注意して変更する必要があります。

Data Grid がデータのプライマリーソースではない場合に、性質的に埋め込みキャッシュとリモートキャッシュは古くなります。Data Grid デプロイメントのプランニング、ベンチマーク、およびチューニング時に、アプリケーションに適したキャッシュの有効期限を選択します。

利用可能な RAM を最大限にできるようにレベルを選択し、キャッシュミスを回避します。Data Grid にエントリーがメモリーにない場合は、アプリケーションが読み取りおよび書き込み要求を送信する時にプライマリーストアに送信されます。

キャッシュミスにより、読み取りおよび書き込みのレイテンシーが増えますが、多くの場合、プライマリーストアへの呼び出しは Data Grid のパフォーマンス低下よりもコストが高くなります。たとえば、一例として、リレーショナルデータベース管理システム (RDBMS) を Data Grid クラスターにオフロードします。このように Data Grid をデプロイすると、従来のデータベースの運用におけるコストが大幅に削減されるため、キャッシュに古くなったエントリーを許容するのは合理的です。

Data Grid では、エントリーに対してアイドルおよびライフスパンの値を最大で設定し、キャッシュの許容できる有効期限を保ちます。

有効期限の値が大きくなると、エントリーがメモリーに保存される期間が長くなり、読み込み操作で古い値が渡される可能性が高くなります。有効期限の値が小さいほどキャッシュに含まれる古い値が少なくなりますが、キャッシュミスが発生する可能性が高くなります。

有効期限を指定するため、Data Grid は既存のスレッドプールからリーパーを作成します。スレッドでのパフォーマンスに関する考慮事項として主に、次に有効期限の実行を行うまでの間隔を適切に設定することが挙げられます。間隔が短いほど有効期限が頻繁に実行されますが、より多くのスレッドを使用します。

さらに、アイドル状態の最大有効期限を使用して、Data Grid がクラスター全体でタイムスタンプを更新する方法を制御できます。Data Grid は touch コマンドを送信して、ノード全体で最大アイドル有効期限を同期的、または非同期的に連携します。同期レプリケーションでは、整合性または速度のどちらを優先するかに応じて、sync または async の touch コマンドのいずれかを選択できます。

RAM はコストの高いリソースで、通常、利用できる量に限りがあります。Data Grid を使用すると、メモリーからエントリーを削除することで、頻繁に使用されるデータを優先するように、メモリー使用量を管理できます。

エビクションは、以下で Data Grid のキャッシュをバインドします。

エビクションからパフォーマンスへの影響は、キャッシュのサイズが設定したしきい値に到達すると Data Grid が算出する必要のある追加の処理内容からきています。

エビクションは読み取り操作の速度を低下させることもできます。たとえば、読み取り操作がキャッシュストアからエントリーを取得する場合に、Data Grid はそのエントリーをメモリーに送り、別のエントリーをエビクトします。このエビクションプロセスでは、パッシベーションを使用する場合に、新たにエビクトされたエントリーをキャッシュストアに書き込むことができます。これが発生すると、読み取り操作はエビクションプロセスが完了するまで値を返しません。

Data Grid は、キャッシュエントリーを、デフォルトで JVM ヒープメモリーに保存します。Data Grid は、オフヒープストレージを使用するように設定できます。つまり、管理された JVM メモリー領域外のネイティブメモリーが、データで占有されます。

以下の図は、Data Grid が実行している JVM プロセスのメモリー領域を簡略して示しています。

図2.1 JVM メモリー領域

JVM ヒープメモリー

ヒープは、参照される Java オブジェクトや他のアプリケーションデータをメモリーに維持するのに役立つ新しい世代と古い世代に分けられます。GC プロセスは、到達不能オブジェクトから領域を回収し、新しい生成メモリープールでより頻繁に実行します。

Data Grid がキャッシュエントリーを JVM ヒープメモリーに保存すると、キャッシュへのデータ追加を開始するため、GC の実行が完了するまで時間がかかる場合があります。GC は集中的なプロセスであるため、実行が長く頻繁になると、アプリケーションのパフォーマンスが低下する可能性があります。

オフヒープメモリー

オフヒープメモリーは、JVM メモリー管理以外のネイティブで利用可能なシステムメモリーです。JVM メモリーの領域 の図には、クラスメタデータを保持し、ネイティブメモリーから割り当てられる メタスペース メモリープールが表示されます。この図は、Data Grid キャッシュエントリーを保持するネイティブメモリーのセクションも含まれています。

オフヒープメモリー

ただし、JVM ヒープダンプはオフヒープメモリーに保存されているエントリーを表示しない点が短所です。

永続データソースと対話するように Data Grid を設定すると、パフォーマンスに大幅に影響を及ぼします。このパフォーマンスのペナルティーは、従来型のデータソースが本質的にインメモリーキャッシュよりも遅いという事実から来ています。読み取り操作と書き込み操作はいつでも、呼び出しが JVM 外で行われると時間がかかります。キャッシュストアの使用方法に応じて、Data Grid パフォーマンスは、永続ストレージのデータにアクセスする場合と比べ、インメモリーデータがパフォーマンスを向上するので、パフォーマンスが低下されるのを抑えることができます。

永続ストレージで Data Grid デプロイメントを設定すると、クラスターの正常なシャットダウンの状態を保持できるなど、他の利点も得られます。また、キャッシュから永続ストレージにデータをオーバーフローし、メモリーだけで利用できる容量以上のキャパシティーを獲得できます。たとえば、メモリーに 200 万程度だけを保持しつつ、合計 1000 万個のエントリーを確保できます。

Data Grid は、ライトスルーモードまたはライトビハインドモードで、キー/値のペアをキャッシュと永続ストレージに追加します。これらの書き込みモードはパフォーマンスに別の影響を与えるため、Data Grid デプロイメントの計画時に考慮する必要があります。

パッシベーションおよびアクティベーションは、Data Grid が、キャッシュ内の特定のエントリーに対して、永続ストレージへの複数の呼び出しを実行する可能性があります。たとえば、エントリーがメモリーで利用できない場合には、Data Grid はエントリーをメモリーに戻して (読み取り操作 1 回)、永続ストレージから削除します。また、キャッシュのサイズ制限に達すると、Data Grid は別の書き込み操作を実行して、新たにエビクトされたエントリーを渡します。

データを保護すると共に、ネットワーク侵入を防ぐことは、デプロイメント計画で最も重要な要素です。機密な顧客情報が公開インターネットに漏洩したり、データが侵害され、ハッカーが機密情報を一般に公開できるようになるので、ビジネスの評判に大打撃を与えます。

これを念頭に、ユーザーを認証し、ネットワーク通信を暗号化するには、強固なセキュリティーストラテジーが必要になります。では、Data Grid デプロイメントのパフォーマンスに対する代償は何ですか ?計画時のこれらの考慮事項はどのように調整すればいいですか

認証

ユーザー認証情報の検証時のパフォーマンスに対する影響は、メカニズムとプロトコルによって異なります。Data Grid は、Hot Rod 経由でユーザーごとに認証情報を 1 回検証し、HTTP 経由で全要求を場合によっては検証する場合があります。

暗号化

クラスタートランスポートを暗号化すると、ノード間でデータを渡して、MITM 攻撃から Data Grid デプロイメントを保護するので、データのセキュリティーを確保できます。ノードは、クラスターに参加する際に TLS/SSL ハンドシェイクを実行し、パフォーマンスが大幅に低下し、追加のラウンドトリップのレイテンシーが増加します。ただし、各ノードが接続を確立すると、接続がアイドル状態にならないことを想定して、そのままずっと接続を確保します。

リモートキャッシュの場合、Data Grid Server はクライアントとのネットワーク通信を暗号化することもできます。パフォーマンス上の観点では、クライアントとリモートキャッシュ間の TLS/SSL 接続の影響は同じです。セキュアな接続の交渉に時間がかかり、追加の作業が必要になりますが、接続が確立されると、暗号化からのレイテンシーが原因で Data Grid のパフォーマンス影響を与えることはありません。

TLSv1.3 を使用する以外に、暗号化を使用した時のパフォーマンスの低下を緩和する方法として唯一、Data Grid を実行する JVM を設定することができます。たとえば、標準の Java 暗号化の代わりに OpenSSL ライブラリーを使用する場合は、結果として最大 20% 早くなり、より効率的に処理できます。

認可

ロールベースアクセス制御 (RBAC) により、データに対する操作を制限でき、追加のセキュリティーをデプロイメントに提供します。RBAC は、Data Grid クラスター全体に分散されたデータに、最小限のユーザーアクセス権限を指定するポリシーを実装するのに最適な方法です。Data Grid ユーザーは、キャッシュからデータの読み取り、作成、変更、または削除を行うのに十分なレベルの権限が必要です。

別のセキュリティーレイヤーを追加してデータを保護すると、常にパフォーマンスが低下します。Data Grid は、ユーザーによるデータの操作を許可する前にアクセス制御リスト (ACL) で各操作を検証するので、認可の操作ではレイテンシーが長くなります。ただし、認可によるパフォーマンスへの影響は、暗号化よりもはるかに低いため、通常、利点で欠点が補填されます。

クライアントリスナーは、Data Grid クラスターでデータを追加、削除、または変更されるたびに通知を出します。

たとえば、以下の実装は、指定の場所で温度が変わるたびにイベントをトリガーします。

@ClientListener
public class TemperatureChangesListener {
   private String location;

   TemperatureChangesListener(String location) {
      this.location = location;
   }

   @ClientCacheEntryCreated
   public void created(ClientCacheEntryCreatedEvent event) {
      if(event.getKey().equals(location)) {
         cache.getAsync(location)
               .whenComplete((temperature, ex) ->
                     System.out.printf(">> Location %s Temperature %s", location, temperature));
      }
   }
}

Data Grid クラスターにリスナーを追加すると、デプロイメントのパフォーマンスの考慮事項が追加されます。

埋め込みキャッシュの場合には、リスナーは Data Grid と同じ CPU コアを使用します。多くのイベントを受信し、大量の CPU を使用してこれらのイベントを処理するリスナーは、Data Grid が使用できる CPU を減らし、その他の操作の速度を低下させます。

リモートキャッシュの場合には、Data Grid Server は内部プロセスを使用してクライアント通知をトリガーします。Data Grid Server は、イベントをプライマリー所有者ノードからクライアントに送信する前に、リスナーの登録先のノードに送信します。Data Grid Server には、クライアントリスナープロセスイベントの速度が遅い場合にキャッシュへの書き込み操作を遅延させるバックプレシャーメカニズムも含まれています。

リモートキャッシュが設定された例として、イベントを 10 個生成するリスナーで 10 台のクライアントを登録すると、Data Grid Server はネットワーク全体で 100 個のイベントを送信します。

Data Grid Server にカスタムフィルターを指定して、クライアントへのトラフィックを減らすことができます。フィルターを使用すると、Data Grid Server が最初にイベントを処理して、イベントをクライアントに転送するかどうかを判断できます。

Data Grid キャッシュをクエリーすると、データを分析してフィルタリングし、リアルタイムで知見を得ることができます。たとえば、プレイヤー同士が競争して点数を獲得するオンラインゲームを思い浮かべてください。上位 10 位のプレイヤーを表示するリーダーボードを実装する場合は、以下のように、ある時点で最高得点を獲得したプレイヤーを特定して、最大 10 位までの結果に制限するといったクエリーを作成できます。

QueryFactory queryFactory = Search.getQueryFactory(playersScores);
Query topTenQuery = queryFactory
  .create("from com.redhat.PlayerScore ORDER BY p.score DESC, p.timestamp ASC")
  .maxResults(10);
List<PlayerScore> topTen = topTenQuery.execute().list();

前述の例では、何百万もあるキャッシュエントリーから基準とあったエントリーを 10 件特定できるので、クエリーを使用する利点がわかります。

ただし、パフォーマンスへの影響の面では、インデックス操作とクエリー操作に関するトレードオフを考慮する必要があります。キャッシュをインデックス化するように Data Grid を設定すると、クエリーがはるかに速くなります。インデックスなしでは、クエリーがキャッシュ内のすべてのデータをチェックする必要があるので、データの種類と量に応じて、結果が遅くなります。

インデックス化が有効な場合に書き込みのパフォーマンスがある程度、低下します。インデックスする内容を理解し、慎重にプランニングすることで、最も深刻な影響は回避できます。

最も効果的な方法として、必要なフィールドだけをインデックス化するように Data Grid を設定できます。Plain Old Java Objects(POJO) を保存するか、Protobuf スキーマを使用するかに関係なく、アノテーションをつけるフィールドが多いと、Data Grid がインデックス構築にかかる時間が長くなります。フィールドが 5 つある POJO があるものの、この内 2 つのフィールドだけをクエリーする必要がある場合は、必要のない 3 つのフィールドをインデックス化しないように Data Grid を設定してください。

Data Grid には、インデックス操作を調整するオプションが複数あります。たとえば、Data Grid はデータとは違う形式でインデックスを保存し、メモリーではなく、ディスクにインデックスを保存します。Data Grid は、エントリーが追加、変更、削除されるたびに、インデックスライターを使用してキャッシュとインデックスを同期させます。インデックスを有効にした後、書き込みが遅くなり、インデックスが原因でパフォーマンスが低下したと考えられる場合は、ディスクに書き込む前に、インデックスをメモリーバッファーに長く保持することができます。その結果、インデックス処理が高速化され、書き込みスループットの低下を抑えることができますが、メモリーが多く消費されます。ただし、ほとんどのデプロイメントでは、デフォルトのインデックス設定が適しており、書き込みがあまり遅くならないようになっています。

たとえば、書き込みの多いキャッシュでは、頻繁にクエリーを実行する必要がなく、ミリ秒単位の結果が必要ない場合など、キャッシュにインデックスを作成しないほうが適しているシナリオもあります。すべて実現する内容により、異なります。クエリーが速くなると、読み込みも速くなりますが、インデックス化すると代わりに書き込みが遅くなります。

maxResults と hit-count-accuracy の値を適切に設定することで、インデックス付きクエリーのパフォーマンスを向上させることができます。

SELECT field1, field2 FROM Entity WHERE x AND y

分散システム上に存在するデータは、一時的なネットワークの停止やシステム障害、あるいは単純なヒューマンエラーによって生じるエラーなどの影響を受けやすくなっています。このような外部要素については制御できませんが、データの品質に深刻な影響を与える可能性があります。データ破損の影響は、顧客満足度の低下、サービスが利用できなくなるほどのコストのかかるシステムの再構築など多岐にわたります。

Data Grid は ACID(atomic, consistent, isolated, durable) トランザクションを実行すると、キャッシュの状態が一貫していることを確認できます。

トランザクションとは、Data Grid が 1 つの操作として処理する一連の操作のことです。トランザクションのすべての書き込み操作が正常に完了するか、すべてに失敗します。これにより、トランザクションでは、一貫した方法でキャッシュの状態を変更して、読み取りおよび書き込みの履歴を提供するか、キャッシュの状態を全く変更しません。

トランザクションを有効にした時のパフォーマンス上の懸念は主に、データセットの一貫性を高めることと、書き込みスループットを低下させるレイテンシーを増やすこと、この 2 点でバランスを取ることです。

2 つ以上のトランザクションが同じキーに同時に書き込むことがないような、競合率が低いワークロードの場合には、楽観的ロックが最適なパフォーマンスを発揮します。

Data Grid は、トランザクションをコミットする前にキーで書き込みロックを取得します。キーの競合がある場合、ロックの取得にかかる時間が原因でコミットを遅延させる可能性があります。さらに、Data Grid が競合する書き込みを検出すると、トランザクションをロールバックし、アプリケーションによる再試行が必要になり、レイテンシーが長くなります。

競合率の高いワークロードの場合、悲観ロックが最適なパフォーマンスを発揮します。

Data Grid は、アプリケーションがキーにアクセスするときにキーに対する書き込みロックを取得し、他のトランザクションでキーを変更できないようにします。キーはすでにロックされているため、トランザクションのコミットは 1 つのフェーズで完了します。複数のキートランザクションを使用する悲観ロックにより、Data Grid のキーのロック時間が長くなり、書き込みスループットが低下する可能性があります。

Data Grid クラスターでは、クラスター内のノードのサブセットが相互に分離され、ノード間の通信が解除されるスプリットブレインが発生する可能性があります。これが発生すると、少数派のパーティションに含まれる Data Grid キャッシュは DEGRADED モードになり、多数派のパーティションのキャッシュは利用可能な状態を維持します。

また、Data Grid は、クラスターを統合しなおしている間は、読み取りだけが可能です。このストラテジーは、アプリケーションが (古くなった) データにアクセスできるようにして可用性を、エントリーへの書き込みを拒否することで一貫性を保つ、よりバランスの取れたオプションです。

デフォルトでは、Data Grid はマージ時に競合を解決しようとしないので、クラスターは、すぐに正常な状態に戻り、通常のクラスターのリバランス以上にパフォーマンスのペナルティーは発生しません。ただし、この場合は、キャッシュ内のデータに一貫性がなくなる可能性が高くなります。

マージポリシーを設定すると、Data Grid がパーティションを修復するのに時間がかかります。マージポリシーを設定すると、Data Grid は各キャッシュからエントリーのすべてのバージョンを取得し、以下のように競合を解決します。

全体的な CPU とメモリー割り当てに関しては通常、クロスサイトレプリケーションを実行する Data Grid クラスターは非対称です。サイジングに、クロスサイトレプリケーションを考慮する場合に、主な考慮事項は、クラスター間の状態遷移の操作による影響です。

たとえば、NYC の Data Grid クラスターはオフラインになり、クライアントは LON の Data Grid クラスターに切り替えるとします。NYC のクラスターがオンラインに戻ると、LON から NYC への状態遷移が発生します。この操作はクライアントから古い内容を読み取らないようにすることができますが、状態遷移を受信するクラスターのパフォーマンスが低下します。

状態遷移操作が必要とする処理量が増加した分をクラスター全体に分散できます。ただし、状態遷移操作によるパフォーマンスへの影響は、データセットのタイプやサイズなどの環境や要素により全く異なります。

Active/Active デプロイメントの競合解決

Data Grid は、複数のサイトがクライアント要求を処理すると (Active/Active のサイト設定と呼ばれる)、同時書き込み操作による競合を検出します。

次の例では、LONデータセンターとNYCデータセンターで実行されている Data Grid クラスターで、同時書き込みの結果、エントリーが競合する様子を示しています。

            LON       NYC

k1=(n/a)    0,0       0,0

k1=2        1,0  -->  1,0   k1=2

k1=3        1,1  <--  1,1   k1=3

k1=5        2,1       1,2   k1=8

                 -->  2,1 (conflict)
(conflict)  1,2  <--

Active/Active のサイト設定では、同時書き込みがデッドロックになり、データが損失するので、同期バックアップストラテジーを使用しないでください。非同期バックアップ戦略 (strategy=async) を使用すると、Data Grid では、同時書き込みの処理に、クロスサイトマージポリシーを選択できます。

パフォーマンスの面では、Data Grid が競合解決に使用するマージポリシーでは、追加の計算が必要ですが、通常は大きなペナルティーは発生しません。たとえば、デフォルトのクロスサイトマージポリシーは、辞書式比較 (または文字列の比較) を使用しており、完了するまでに数ナノ秒しかかかりません。

Data Grid では、クロスサイトマージポリシーの XSiteEntryMergePolicy SPI も提供します。Data Grid がカスタム実装との競合を解決するように設定するには、常にパフォーマンスを監視して悪影響がないかを監視する必要があります。

分散キャッシングの利点の 1 つは、各ホストからのコンピュートリソースを使用して、大規模なスケーリングデータ処理をより効率的に実行できることです。Data Grid で直接処理ロジックを実行することで、ワークロードを複数の JVM インスタンスに分散します。コードは、データを格納しているのと同じメモリー領域でも実行されるので、エントリーの反復処理速度を早めることができます。

Data Grid のデプロイメントへのパフォーマンスの影響については、コードの実行状況により完全に異なります。より複雑な処理操作を行うと、パフォーマンスが低下するため、慎重に計画を立てて、Data Grid クラスターでコードを実行するようにする必要があります。コードをテストし、小規模なサンプルデータセットで複数実行を試すことから開始します。メトリックを収集後には、最適化の特定を開始し、実行中のコードのパフォーマンスに対する影響を理解できます。

確実に考慮するべき点として、処理を長時間にわたり実行すると、通常の読み取りおよび書き込みの操作に悪影響を及ぼし始めます。したがって、デプロイメントを時間とともに監視し、パフォーマンスを継続的に評価することが重要です。

埋め込みキャッシュ

Data Grid は埋め込みのキャッシュで、データと同じメモリー領域でコードを実行できる API を 2 つ提供します。

1 つのノード、ノードのグループ、または特定の地理的リージョン内の全ノードで操作を実行する場合は、クラスターの実行を使用する必要があります。データセット全体に対して正しい結果を保証する操作を実行する場合には、分散ストリームを使用するオプションがより効果的です。

ClusterExecutor clusterExecutor = cacheManager.executor();
clusterExecutor.singleNodeSubmission().filterTargets(policy);
for (int i = 0; i < invocations; ++i) {
   clusterExecutor.submitConsumer((cacheManager) -> {
      TransportConfiguration tc =
      cacheManager.getCacheManagerConfiguration().transport();
      return tc.siteId() + tc.rackId() + tc.machineId();
   }, triConsumer).get(10, TimeUnit.SECONDS);
}

Map<Object, String> jbossValues =
cache.entrySet().stream()
     .filter(e -> e.getValue().contains("JBoss"))
     .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));

リモートキャッシュ

リモートキャッシュの場合、Data Grid は ServerTask API を提供し、カスタム Java 実装を Data Grid Server に登録し、Hot Rod で execute() メソッドを呼び出すか、Data Grid コマンドラインインターフェイス (CLI) を使用して、プログラムを使用してタスクを実行できます。1 つの Data Grid Server インスタンスだけで、またはクラスター内のすべてのサーバーインスタンスでタスクを実行できます。

リモート Data Grid クラスターのサイジング時には、エントリーの数およびサイズを計算する必要がありますが、クライアントトラフィックの量も計算します。Data Grid は、データを格納し、クライアントの読み取り要求と書き込み要求をタイムリーに処理するために十分な RAM が必要です。

レイテンシーに影響し、応答時間を決定する要因は多数あります。たとえば、キー/値のペアのサイズは、リモートキャッシュの応答時間に影響します。リモートキャッシュのパフォーマンスに影響を与える他の要因には、クラスターが受信する 1 秒あたりの要求数、クライアントの数、書き込み操作に対する読み取り動作の比率などが含まれます。

デプロイメントを設定して設定したら、Data Grid クラスターのベンチマークを開始して、パフォーマンスを分析し、測定します。ベンチマークにより、環境を調整し、Data Grid の設定を調整してパフォーマンスを最適化することができます。つまり、レイテンシーが低くなり、スループットが最も高いことを意味します。

パフォーマンスを最適化するのは、最終的な目標ではなく、継続的なプロセスであることに注意してください。ベンチマークテストで、Data Grid デプロイメントが希望するパフォーマンスレベルに達したことが示されている場合は、それらの結果が修正または常に有効になることを期待することはできません。

Operator サブスクリプションを作成し、コマンドラインインターフェイス (CLI) が含まれる Hyperfoil ディストリビューションをダウンロードして、Red Hat OpenShift で Hyperfoil を設定します。

Hyperfoil Controller を Red Hat OpenShift でインスタンス化することで、Hyperfoil コマンドラインインターフェイス (CLI) を使用してベンチマークテストをアップロードおよび実行できます。

Hyperfoil を使用してベンチマークテストを実行し、Data Grid クラスターのパフォーマンスデータを収集します。

Hyperfoil は、stats コマンドを使用してベンチマークの実行結果をテーブル形式で出力します。

[hyperfoil]$ stats
Total stats from run <run_id>
PHASE  METRIC  THROUGHPUT  REQUESTS  MEAN  p50  p90  p99  p99.9  p99.99  TIMEOUTS  ERRORS  BLOCKED