第20章 クライアント/サーバー

クライアントサーバーモードで Red Hat Data Grid にアクセスすると、たとえば、JVM 以外の環境から Red Hat Data Grid にアクセスしようとすると、アプリケーションに埋め込まれるよりも適切である場合もあります。Red Hat Data Grid は Java で書かれているため、アクセスしたい C\\ アプリケーションがある場合、p2p 方式では実行できません。一方、言語に依存しないプロトコルが使用され、対応するクライアントおよびサーバーの実装が利用可能であることを前提とします。

図20.2 JVM 以外のアクセス

他の状況では、Red Hat Data Grid のユーザーは、ビジネスプロセスサーバーを定期的に起動/停止するエラスティックアプリケーション層が必要です。ユーザーがディストリビューションまたは状態遷移で設定した Red Hat Data Grid をデプロイした場合、このような状況で発生するデータに関するシャッフルに起動時間が大きく影響できるようになりました。以下の図では、Red Hat Data Grid が p2p モードでデプロイされたと、状態遷移が完了するまで 2 番目のサーバーのアプリケーションが Red Hat Data Grid にアクセスできませんでした。

図20.3 P2P でのエラビリティーの問題

これは、アプリケーションがこれらのプロセスが終了するまで Red Hat Data Grid にアクセスできないため、新規のアプリケーション層サーバーを起動することは、状態遷移による影響を受けません。これは、移動する状態が大きくなると、時間がかかる可能性があります。これは、アプリケーション層のサーバーのターンアラウンドかつ予測可能な起動時間を使用するエラスティック環境で望ましくありません。このような問題は、新しいアプリケーション層サーバーを起動することで、クライアントサーバーモードで Red Hat Data Grid にアクセスすることで解決できます。これは、バッキングデータグリッドサーバーに接続できる軽量クライアントを起動するだけです。再ハッシュや状態遷移が発生する必要がないため、サーバーの起動時間はより予測可能で、アプリケーション層のエラビリティーが重要な最新のクラウドベースのデプロイメントで非常に重要になります。

図20.4 弾力性を実現

また、データストレージにアクセスする必要のある複数のアプリケーションを見つけることが一般的です。このような場合、これらの各アプリケーションごとに Red Hat Data Grid インスタンスをデプロイすることは可能ですが、保守が困難である可能性があります。ここでデータベースについて考えても、各アプリケーションとともにデータベースをデプロイしませんか？そのため、クライアントサーバーモードで Red Hat Data Grid をデプロイする場合は、アプリケーションの共有ストレージ層として機能する Red Hat Data Grid データグリッドノードのプールを維持できます。

図20.5 共有データストレージ

このように Red Hat Data Grid をデプロイすると、各層を個別に管理できます。たとえば、Red Hat Data Grid のグリッドノードをダウンすることなく、アプリケーションやアプリケーションサーバーをアップグレードすることができます。