第37章 サーバーヒンティングを用いた高可用性
37.1. サーバーヒンティングを用いた高可用性
Red Hat JBoss Data Grid では、サーバーヒンティングによってデータのバックアップコピーが元データと同じ物理サーバー、ラック、またはデータセンター上に保存されないようにします。トータルレプリケーションはすべてのサーバー、ラックおよびデータセンター上で完全なレプリカの作成を強制するため、サーバーヒンティングはトータルレプリケーションには適用されません。
複数のノードにまたがるデータ分散は一貫したハッシュメカニズムによって制御されます。JBoss Data Grid は、一貫したハッシュアルゴリズムを指定するためのプラグ可能なポリシーを提供します。詳細は「ConsistentHashFactories」を参照してください。
トランスポート設定で machineId、rackId、または siteId を設定すると、TopologyAwareConsistentHashFactory が使用されます。これは、サーバーヒンティングが有効な DefaultConsistentHashFactory と同じです。
サーバーヒンティングは、JBoss Data Grid 実装の高可用性を確実に実現する場合に特に重要になります。
37.2. ConsistentHashFactories
37.2.1. ConsistentHashFactories
Red Hat JBoss Data Grid は、一貫したハッシュアルゴリズムを選択するためのプラグ可能なメカニズムを提供します。これは 4 つの実装に同梱されていますが、カスタム実装を使用することもできます。
JBoss Data Grid には 4 つの ConsistentHashFactory 実装が同梱されています。
-
DefaultConsistentHashFactory- すべてのノード間でセグメントが均等に分散されるようにします。ただし、キーマッピングは、各キャッシュの履歴に依存するため、複数のキャッシュ間で同じであることは保証されません。consistentHashFactory が指定されない場合は、このクラスが使用されます。 -
SyncConsistentHashFactory- 現在のメンバーシップが同じである場合、各キャッシュでキーマッピングが同じになることを保証します。ただし、この欠点として、キャッシュに参加するノードによって既存ノードもセグメントを交換する可能性があり、その結果、状態遷移のトラフィックが追加で発生したり、データの分散がより不均等になります。 -
TopologyAwareConsistentHashFactory-DefaultConsistentHashFactoryと同等ですが、設定にサーバーヒンティングが含まれる場合に自動的に選択されます。 -
TopologyAwareSyncConsistentHashFactory-SyncConsistentHashFactoryと同等ですが、設定にサーバーヒンティングが含まれる場合に自動的に選択されます。
一貫したハッシュ実装をハッシュ設定で選択できます。
<distributed-cache consistent-hash-factory="org.infinispan.distribution.ch.impl.SyncConsistentHashFactory">
この設定は、同じメンバーを持つキャッシュに同一の一貫したハッシュがあることを保証し、さらに machineId、rackId、または siteId 属性がトランスポート設定で指定される場合に、バックアップコピーを複数の物理マシン、ラック、およびデータセンターにまたがって分散します。
想定される欠点として、この設定により、バランスの再調整時に必要とする数以上のセグメントが移動する可能性があります。ただし、この影響は、多数のセグメントを使用することによって軽減できます。
もう 1 つの想定される欠点として、セグメントが均等に分散されないことや、さらには多数のセグメントを実際に使用することによりセグメントの分散状況が悪化することなどがあります。
上述の欠点がありますが、多くの場合、SyncConsistentHashFactory および TopologyAwareSyncConsistentHashFactory を使用すると、ノードがクラスターに参加した順序に基いてハッシュが計算されないため、クラスター化環境でオーバーヘッドが減少します。また、これらのクラスは通常、各ノードに割り当てられるセグメントの数に大きな違いがあっても許容されるため、デフォルトのアルゴリズムよりも高速になります。
37.2.2. ConsistentHashFactory の実装
カスタム ConsistentHashFactory は、以下のメソッド (これらすべては org.infinispan.distribution.ch.ConsistentHashの実装を返します) を使って、org.infinispan.distribution.ch.ConsistenHashFactory インターフェースを実装する必要があります。
ConsistentHashFactory メソッド
create(Hash hashFunction, int numOwners, int numSegments, List<Address> members,Map<Address, Float> capacityFactors) updateMembers(ConsistentHash baseCH, List<Address> newMembers, Map<Address, Float> capacityFactors) rebalance(ConsistentHash baseCH) union(ConsistentHash ch1, ConsistentHash ch2)
37.3. キーアフィニティーサービス
37.3.1. キーアフィニティーサービス
キーアフィニティーサービスを使用すると、分散された Red Hat JBoss Data Grid クラスターの特定のノードに値を配置できます。サービスは、識別する指定済みクラスターアドレスに基いて、ハッシュ化されたキーを特定のノードに返します。
キーアフィニティーサービスにより返されたキーは、ユーザー名などの意味を持つことができません。これらは、このレコードのためにアプリケーション全体で使用される無作為の ID にすぎません。提供されたキージェネレーターは、このサービスにより返されるキーが一意であることを保証しません。カスタムキー形式について、KeyGenerator の独自の実装を渡すことができます。
このサービスの参照を取得し、使用する方法の例を以下に示します。
キーアフィニティーサービス
EmbeddedCacheManager cacheManager = getCacheManager();
Cache cache = cacheManager.getCache();
KeyAffinityService keyAffinityService =
KeyAffinityServiceFactory.newLocalKeyAffinityService(
cache,
new RndKeyGenerator(),
Executors.newSingleThreadExecutor(),
100);
Object localKey = keyAffinityService.getKeyForAddress(cacheManager.getAddress());
cache.put(localKey, "yourValue");
以下の手順は、提供された例の説明です。
キーアフィニティーサービスの使用
- キャッシュマネージャーおよびキャッシュの参照を取得します。
-
これにより、サービスが起動されます。その後、提供された
Executorを使用してキーが生成され、キューに置かれます。 -
ローカルノードにマップされるサービスからキーを取得します (
cacheManager.getAddress()はローカルアドレスを返します)。 -
KeyAffinityServiceから取得されたキーを持つエントリーは常に、提供されたアドレスを持つノードに格納されます。この場合は、ローカルノードになります。
37.3.2. ライフサイクル
KeyAffinityService は Lifecycle を拡張します。これにより、キーアフィニティーサービスを停止、起動、および再起動することが可能になります。
キーアフィニティーサービスライフサイクルパラメーター
public interface Lifecycle {
void start();
void stop();
}
サービスは、KeyAffinityServiceFactory を介してインスタンス化されます。すべてのファクトリーメソッドには非同期キー生成に使用される Executor があるため、呼び出し元のスレッドでは行われません。ユーザーはこの Executor のシャットダウンを制御します。
KeyAffinityService は、不必要になった時点で明示的に停止する必要があります。これにより、バックグラウンドキーの生成が停止され、保持された他のリソースが解放されます。KeyAffinityServce は、登録されているキャッシュマネージャーがシャットダウンした場合のみ停止します。
37.3.3. トポロジーの変更
KeyAffinityService キーの所有権は、トポロジーが変更されると、変わることがあります。キーアフィニティーサービスは、トポロジーの変更と更新を監視し、古いキーまたは指定されたものと異なるノードにマップされるキーを返さないようにします。ただし、キーが使用されたときにノードアフィニティーが変更されないことは保証されません。以下に例を示します。
-
スレッド (
T1) は、ノード (A) にマップされるキー (K1) を読み取ります。 -
トポロジーが変更され、
K1がノードBにマップされます。 -
T1はK1を使用してキャッシュにデータを追加します。この時点では、K1はリクエストされたノードとは異なるBにマップします。
上記のシナリオは理想的ではありませんが、クラスターの変更中にすでに使用中のキーを移動できるため、アプリケーションのサポートされた動作です。KeyAffinityService は安定したクラスターに対してアクセス近接の最適化を提供します。トポロジーの変更が安定的でないときには適用されません。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.