データ・グリッドを何千という Java 仮想マシンにわたってデプロイすることは可能ですが、構成テストの信頼性を高め、その実行を簡単にするには、データ・グリッドをユニット、つまり、ポッドに分割することを検討することをお勧めします。ポッドとは、同じアプリケーションのセットを実行しているサーバーの一群です。
テストによって、eXtreme Scale が 1000 を超す JVM にスケールアウトできることが検証されています。 このようなテストでは、単一データ・グリッドを多数のコンピューターにデプロイするようなアプリケーションの構築を勧められます。 そのようなアプリケーションの構築は可能ですが、以下のようないくつかの理由により推奨されません。
アプリケーション・データ・グリッドをポッド (ユニット) に分割することは、より信頼性の高い選択肢です。ポッドとは、同種のアプリケーション・スタックを実行するサーバーの一群です。 ポッドのサイズは任意ですが、約 20 台の物理サーバーで構成されるのが理想的です。 単一データ・グリッドに 500 台の物理コンピューターがあるよりも、20 台の物理コンピューターの 25 ポッドにしてください。 単一の種類のアプリケーション・スタックは、指定されたポッドで実行する必要がありますが、異なるポッドが独自の種類のアプリケーション・スタックを持つことは構いません。
ポッドは、テストに都合のいいようにサイズ変更したデプロイメント・ユニットです。 数百台のサーバーでテストを行う代わりに、20 台のサーバーで行うのはより実用的です。 この場合、実動環境と同じ構成を引き続きテストしていきます。 実動環境では、1 つのポッドを構成する、20 台のサーバーの最大サイズでグリッドが使用されます。 1 つのポッドにストレス・テストをかけ、そのキャパシティー、ユーザー数、データ量、およびトランザクション・スループットを判別できます。 これによって、より簡単に計画が立てやすく、予測可能なコストで予測可能な拡張を行うという規格に従うことができます。
別のケースでは、ポッドには必ずしも 20 台のサーバーが必要というわけではありません。 ポッドのサイズの目的は、実用的なテストのためです。実動環境でポッドに問題が発生しても、影響を受ける一部のトランザクションが耐えられるように、ポッドのサイズは十分に小さくしてください。
バグが発生しても、単一のポッドにのみ影響するのが理想的です。バグは 100 パーセントではなく、アプリケーション・トランザクションの 4 パーセントにしか影響を与えません。 さらに、一度に 1 つのポッドをロールアウトできるので、アップグレードはより簡単です。 結果として、ポッドへのアップグレードで問題が生じた場合、ユーザーはそのポッドを切り替えて前のレベルに戻すことができます。 アップグレードには、アプリケーションに対する変更、アプリケーション・スタックに対する変更、またはシステム更新を含みます。 問題診断をより正確に行うために、アップグレードではできる限り、スタックのエレメントを一度に 1 つだけ変更するようにしてください。
ポッドを使用する環境を実装するには、ポッドにソフトウェアのアップグレードがあった場合に上下に互換性のあるルーティング層がポッドの上に必要です。 また、どのポッドが何のデータを持っているかについての情報を含むディレクトリーを作成する必要もあります。 (このために、できれば後書きシナリオを使って、別の eXtreme Scale データ・グリッドをその後ろのデータベースと一緒に使用してください。) これは、2 層の解決策を生み出します。 層 1 はディレクトリーで、特定のトランザクションを処理するポッドを検索するために使用されます。 層 2 はポッド自体で構成されます。 層 1 がポッドを識別すると、セットアップは各トランザクションをポッド内の適切なサーバーに送付します。このサーバーは、通常、トランザクションが使用するデータ用区画を保持するサーバーです。 さらに、必要であれば層 1 でニア・キャッシュを使用して、適切なポッドの検索に関連する影響を小さくすることができます。
ポッドの使用は、単一データ・グリッドを持つよりも少し複雑ですが、操作、テスト、および信頼性の面で改善されるため、スケーラビリティーのテストの重要な一部になっています。