How to Improve Domain Data Grid Performance (Japanese Language)

現在のPayara Platformアーキテクチャの基礎となるのは、ドメイン・データ・グリッドの採用です。ドメイン・データ・グリッドは複数のPayara ServerまたはPayara Microインスタンスを結合して、互いにデータを共有する交換可能なノードの堅牢なクラスタを形成し、クラスタにデプロイされたあらゆるアプリケーションに対して高可用性とフェールオーバー機能を提供します。

Payara Platformのドメイン・データ・グリッドは、Hazelcast IMDG Community Editionの強力なオープンソース技術をベースに構築されており、複数の環境に対応した分散アプリケーションを簡単に作成することができます。

データ・グリッドは、Payara Platformバージョン5.x製品においてデフォルトで有効になっており、管理者ユーザーは、対応するサーバー・ログの以下のメッセージ出力を見ることにより、データ・グリッド構成の証拠を見ることができます。

[2021-01-20T17:56:58.408-0500] [] [INFO] [] [fish.payara.nucleus.cluster.PayaraCluster] [tid: _ThreadID=80 _ThreadName=Executor-Service-4] [timeMillis: 1611183418408] [levelValue: 800] [[
Data Grid Status
Payara Data Grid State: DG Version: 35 DG Name: production DG Size: 2
Instances: {
   DataGrid: production Group: MicroShoal Name: Instance-1 Lite: false This: true UUID: f0b6d054-f017-40a5-ad50-732fb6e200b9 Address: /192.168.1.148:6900
   DataGrid: production Group: MicroShoal Name: Instance-2 Lite: false This: false UUID: f0b6d054-f017-40a5-ad50-732fb6e200b9 Address: /192.168.1.150:6900
}]]

ドメイン・データ・グリッドは複数の方法で構成することができますが、その基本的な振る舞いは非常に簡単です。既存のデータ・グリッドが新しいサーバー・インスタンスを発見すると、インスタンスはユーザーの直接の介入を要さずシームレスにデータ・グリッドへ参加します。ネットワークの遅延、JVMの設定、Hazelcastの設定はすべて、インスタンスがデータ・グリッドに参加して正式なHazelcastクラスタ・メンバーとなるまでの時間に影響します。Hazelcastの設定を調整することで、インスタンスがクラスタに参加するために必要となる時間が改善され、初期化されたばかりのドメイン・データ・グリッドがユーザーのリクエストに対応できるようになるまでの全体的な時間を改善することができます。

以下のシステム・プロパティはHazelcastが内部的に使用しており、インスタンスがデータ・グリッドに参加するまでの待ち時間を制御するために使用することができます。

このプロパティは少々わかりづらいのですが、ここで説明することを押さえておけば理解しやすいでしょう。

• Hazelcastのクラスタ戦略は非常に複雑ではありますが、主に知っておくべき事柄は、すべてのHazelcastクラスタにはマスター・ノードとメンバーが必要であり、各インスタンスがクラスタに参加する方法を調整するということです。
  • Payara Serverでは、デフォルトのドメイン・データ・グリッド構成において、DASは常にマスター・ノードとして機能します。
  • Payara Microは、最初に起動したインスタンスが自身をマスター・ノードとして設定します。同一ネットワーク上で起動した新しいインスタンスは、マスター・ノードと調整してデータ・グリッドに参加しようとします。
• 新しいサーバー・インスタンスが起動する時、Hazelcastは到達可能な既存のマスター・ノードが存在するか探索を試み、発見された場合にはマスター・ノードに連絡を取りノードが管理しているクラスタへの参加を試みます。

上記2つのプロパティは、マスター・ノードがインスタンスから最初の参加要求を受信してから以下のいずれかが発生するまでの、pre-joinフェーズと呼ばれる時間枠を構成するのに使用されます。

• wait.seconds.before.join秒、クラスタへの参加を要求する新しいインスタンスがない
• max.wait.seconds.before.joinで定義された時間が経過した

pre-joinフェーズが終了すると、マスター・ノードは正式なjoinフェーズに移行し、マスター・ノードは対応するpre-joinフェーズを完了したすべてのインスタンス（または以前に参加を試みて失敗したものの引き続き参加を試みているインスタンス）を参加させます。

これらをすべて考慮すると、サーバー・インスタンスがデータ・グリッドに参加するのに要する時間を最適化するには、両方の値を1～5秒くらいにできるだけ低く設定する必要があります。ここでは、新しいPayara Microインスタンスを起動する際にこれらのプロパティを設定する例を示します。

java -Dhazelcast.wait.seconds.before.join=1 -Dhazelcast.max.wait.seconds.before.join=5 -jar payara-micro.jar

このような最適化は、常にグリッドに参加しようとするインスタンスの数がそれほど多くない場合に上手く働くことを覚えておいてください。例えば、20個の新しいインスタンスが同時に起動された場合、マスター・ノードのpre-joinフェーズが短すぎて、これらのインスタンスが同時に（または前後して）参加することができません。参加するインスタンスの数が環境の生存期間を通じて一貫して少ないと予想される場合には、より短い時間を考慮すべきでしょう。

本稿執筆時点では、hazelcast.wait.seconds.before.joinプロパティを0に設定することは推奨されていません（新しい参加要求の待ち時間を無効化してしまいます）。これはHazelcastの既知のバグによるもので、望ましくない副作用をもたらします。私達はこのバグがHazelcastの将来のリリースで修正されると期待しており、修正後にはPayara Platformにもすぐに反映する予定です。