JBoss Data Gridの構成とチューニングポイント

2013年10月24日(木)
西ヶ谷 岳

JDGサーバーを構成する各モジュールについてさらに詳しく見ていきましょう(図2)。

図2:JDGサーバーの内部構成(クリックで拡大)

infinispan server

JDGサーバーはクライアントとの接続手段として、Hot Rod、Memcached、RESTの3つのコネクタがデフォルトで有効になっています。Hot RodとMemcachedについては、Infinispanサーバーモジュール内で独自のプロトコルサーバーが起動するにようになっており、それぞれにスレッドプールを持っています。

なお、REST用にはJBoss EAPサーバーと同じJBoss Webモジュールが使用されているため、JBoss EAPと同じ考え方でWebコンテナのチューニングが行えます。また、これらのプロトコルサーバーはコンフィグレーションの変更により、自由に停止することができます。例えば、Hot Rodクライアントしか使わないのであれば、MemcachedとRESTのコネクタを起動させないことで起動時に生成するスレッドが減り、JDGサーバーを軽量化することができます。

infinispan core

JDGサーバーの中で中心的な役割であるInfinispanコアは複数のキャッシュコンテナを持ち、キャッシュコンテナには複数のキーバリューストア(キャッシュ)を定義することができます。キャッシュはオプションでデータを永続化するためのキャッシュストアを定義することができます。

キャッシュストアの実装としては、ファイルシステムを使用するファイルストア、データベースを使用するJDBCストア、別のJDGクラスタをストアと見立てて使用するリモートストアが用意されており、独自のカスタムストアを実装して設定することもできます。ただし、キャッシュストアを併用する場合、JDGの性能は使用するストアの性能に制約を受けるため、ストアの使用は十分に注意する必要があります。

アーキテクチャ上はInfinispanコアがクラスタリングに使用するプロトコルモジュールは選択することができるようになっています。しかしながら、現状選択可能なプロトコルモジュールは実質的にJGroupsのみです。

jgroups

JGroupsは複数ノードによる動的なクラスタを容易に管理することができるよう、複数のプロトコルスタックの集合として構成されています。これらプロトコルスタックには、例えば、新しいノードがクラスタに参加してきたことを検出するためのディスカバリプロトコルや、クラスタからノードが離脱したことを検出する障害検知プロトコル、メッセージの再送制御や順序制御を担当するプロトコルなどがあります。JGroupsはユニキャスト通信とマルチキャスト通信を組み合わせ、効率的に動的なクラスタを管理できる特徴を持っています。

以上で述べてきたように、JDGサーバーはモジュールベースアーキテクチャの特長を活かし、非常に多くの拡張可能点を持っています。従って、JDGをチューニングするという観点では、単にパラメータを変更するだけでなく、拡張点における部品を取り替えたり、不要な部品を削除して軽量化を図ったりすることができる特徴を持っています。

次節では、上記で説明したアーキテクチャを念頭において、JDGクラスタをチューニングするポイントについて述べます。

JDGのチューニングポイント

JDGをチューニングする項目は、JVMレベル、OSレベル、ネットワークレベル、Infinispanレベル、JGroupsレベルと非常に多岐にわたります。スペースの都合上、これら全てを網羅して解説することはできませんので、ここではシステム開発の初期の設計・評価のフェーズで必ず考慮しなければならない、基本的で重要な項目について述べたいと思います。

JVMレベルのチューニング:ヒープサイズ

JVMレベルのチューニングでまず考えなければいけないのはJVMのヒープサイズ設定です。JDGのキャッシュデータは全てJavaヒープに保持されますので、アプリケーションで使用する予定のクラスオブジェクトを想定し、実際の運用で想定される最大エントリ数を保持できるようにJavaヒープを確保するように設計します。なお、Javaヒープとして確保しなければならないメモリ容量はJDGに設定するキャッシュモードによって異なる点に注意します。例えば、10GBのデータをReplicationモードで保持するためには、ノード数に関わらず各ノードは10GB以上のJavaヒープ容量が必要なため、以下の式が当てはまります。

必要ヒープサイズ > 最大使用データ量

Distributionモードではノード数、およびレプリカ数(owners数)によって異なり、以下の式によって見積もる必要があります。

必要ヒープサイズ > 最大使用データ量 * owners数 / ノード数

なお、ここで確保すべきヒープ容量は、HotSpot の世代別ヒープ管理におけるOld領域として確保すべき値である点に注意してください。実際に-Xms/-Xmxオプションを設定する場合は、これにEden領域を加えた値を設定しなければなりません。

また、必要ヒープサイズはノード障害が発生してもOutOfMemoryErrorが発生しない値でなければなりません。従って、キャッシュモードがDistributionモードの場合は、上記計算式のノード数は障害発生時に停止することを許容するノード数を除いた、縮退後のノード数で見積もる必要があります。

レッドハット株式会社

JBossサービス事業部 JBossシニアコンサルタント
株式会社富士通研究所を経て、2002年にサン・マイクロシステムズに入社。主にエンタープライズJavaのコンサルティングサービスを担当。その後、日本オラクルを経て、2012年より現職。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています