第37章 サーバーヒンティングを用いた高可用性

Red Hat JBoss Data Grid は、一貫したハッシュアルゴリズムを選択するためのプラグ可能なメカニズムを提供します。これは 4 つの実装に同梱されていますが、カスタム実装を使用することもできます。

JBoss Data Grid には 4 つの ConsistentHashFactory 実装が同梱されています。

一貫したハッシュ実装をハッシュ設定で選択できます。

<distributed-cache consistent-hash-factory="org.infinispan.distribution.ch.impl.SyncConsistentHashFactory">

<distributed-cache consistent-hash-factory="org.infinispan.distribution.ch.impl.SyncConsistentHashFactory">

この設定は、同じメンバーを持つキャッシュに同一の一貫したハッシュがあることを保証し、さらに machineId、rackId、または siteId 属性がトランスポート設定で指定される場合に、バックアップコピーを複数の物理マシン、ラック、およびデータセンターにまたがって分散します。

想定される欠点として、この設定により、バランスの再調整時に必要とする数以上のセグメントが移動する可能性があります。ただし、この影響は、多数のセグメントを使用することによって軽減できます。

もう 1 つの想定される欠点として、セグメントが均等に分散されないことや、さらには多数のセグメントを実際に使用することによりセグメントの分散状況が悪化することなどがあります。

上述の欠点がありますが、多くの場合、SyncConsistentHashFactory および TopologyAwareSyncConsistentHashFactory を使用すると、ノードがクラスターに参加した順序に基いてハッシュが計算されないため、クラスター化環境でオーバーヘッドが減少します。また、これらのクラスは通常、各ノードに割り当てられるセグメントの数に大きな違いがあっても許容されるため、デフォルトのアルゴリズムよりも高速になります。

カスタム ConsistentHashFactory は、以下のメソッド (これらすべては org.infinispan.distribution.ch.ConsistentHashの実装を返します) を使って、org.infinispan.distribution.ch.ConsistenHashFactory インターフェースを実装する必要があります。

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)

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)

キーアフィニティーサービスを使用すると、分散された 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");

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");

以下の手順は、提供された例の説明です。

KeyAffinityService は Lifecycle を拡張します。これにより、キーアフィニティーサービスを停止、起動、および再起動することが可能になります。

public interface Lifecycle {
     void start();
     void stop();
}

public interface Lifecycle {
     void start();
     void stop();
}

サービスは、KeyAffinityServiceFactory を介してインスタンス化されます。すべてのファクトリーメソッドには非同期キー生成に使用される Executor があるため、呼び出し元のスレッドでは行われません。ユーザーはこの Executor のシャットダウンを制御します。

KeyAffinityService は、不必要になった時点で明示的に停止する必要があります。これにより、バックグラウンドキーの生成が停止され、保持された他のリソースが解放されます。KeyAffinityServce は、登録されているキャッシュマネージャーがシャットダウンした場合のみ停止します。

KeyAffinityService キーの所有権は、トポロジーが変更されると、変わることがあります。キーアフィニティーサービスは、トポロジーの変更と更新を監視し、古いキーまたは指定されたものと異なるノードにマップされるキーを返さないようにします。ただし、キーが使用されたときにノードアフィニティーが変更されないことは保証されません。以下に例を示します。

上記のシナリオは理想的ではありませんが、クラスターの変更中にすでに使用中のキーを移動できるため、アプリケーションのサポートされた動作です。KeyAffinityService は安定したクラスターに対してアクセス近接の最適化を提供します。トポロジーの変更が安定的でないときには適用されません。