- - PR -
EJBと負荷分散(クラスタリング)について
1
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-07-10 11:10
お世話になっております。
業務でEJBに触れる機会があり興味を持ったため、EJB3.0とシステムのクラスタ化について 学習しているのですが、幾つか疑問がありますので質問させて頂きます。 1.一般的なクラスタリングの構成(Webシステム) 2.LocalとRemoteを使い分ける際の指針 3.SessionBeanのネーミング 1.一般的なクラスタの構成 私なりにクラスタ構成を考えてみたのですが、 i) プレゼンテーション層(Servlet)とビジネス層(EJB)でサーバを分け、ビジネス層をクラスタ化する。 ii) プレゼンテーション層(Servlet)とビジネス層(EJB)を同一のサーバに置き、プレゼンテーション層ごとクラスタ化する。 iii) プレゼンテーション層(Servlet)とビジネス層(EJB)でサーバを分け、プレゼンテーション層とビジネス層をそれぞれクラスタ化する。 の3パターンがあるのではないかと思いました。 iiiのパターンは相当高負荷なシステムの場合しか使われないのではないか?等と想像してみたのですが、 実際にはどのようなクラスタ構成が多いのでしょうか? 2.LocalとRemoteを使い分ける際の指針 先のクラスタ構成のiiでは必然的にLocalを指定する事になるかとは思うのですが、その他の構成で LocalとRemoteを使い分ける際の指針(こういう場合にはRemoteにするとマズイ等)はありますでしょうか? 3.SessionBeanのネーミング そこまで重要なことでは無いのですが、EJBのクラスを作成する際に使用する一般的なネーミングルールは あるのでしょうか?XXXXというインターフェイスの実装クラスはXXXXBeanとする様ですが、XXXXの部分は 何でも良いのでしょうか?慣例的に、SessionBeanである事を示すネーミングルールがあったりはしないのでしょうか? 以上、拙い日本語で恐縮ですが、どなたかご回答の程宜しくお願い致します。 | ||||||||||||
|
投稿日時: 2008-07-10 22:21
一般的にどうなのかは知らないので個人的な意見ですが、
この構成が多いと思います。 i)ではプレゼンテーション層の冗長化が図れませんし、 iii)では最小構成が4台になるため、初期投資が大きくなります。 プレゼンテーション層とビジネス層のノードを分離すると ノード間の通信オーバーヘッドが発生するため、 よほど大規模でない限りパフォーマンス的に不利です。 ですが、ビジネス層以降を共有して、プレゼンテーション層を 複数提供するような場合では検討する可能性は高いと思います。
アプリケーションサーバの実装次第なので何とも言えませんが、 呼び出し回数が極端に多かったり、巨大なデータが流れる場合は Remoteは避けた方がいいと思います。 他にも、Localでは呼び出し元と同一スレッドで動作することが 保証されていたような記憶があるので、ThreadLocalを利用する 場合ではRemoteだとまずいことになるかもしれません。 #この辺は大嘘かもしれません。
私は実装的な階層毎に規則を作ることが多いです。 接尾辞としてFacade、Service、Logic、Daoなどを使います。 Business層を複数の階層に分けて実装するのでBusinessは使いません。 また、クラス名の最後にBeanは付けません。 わざわざBeanであることをアピールするメリットを感じられないので。 そんなことをしたらインテグレーション層からプレゼンテーション層まで なんちゃらBeanだらけになってしまって激しくうっとうしいです。 | ||||||||||||
|
投稿日時: 2008-07-11 09:38
一度試験的に作ったものについてなので、一般的でなくあまり参考にならないかもしれませんが、
i) プレゼンテーション層(Servlet)とビジネス層(EJB)でサーバを分け、ビジネス層をクラスタ化する。 で作成しました。(といってもEJB部分はクラスタ化しないで単純サーバですが) プレゼンテーション層(某社製:Java5までしかサポートしてない!)とビジネス層(GlassFish)をつなぐために、EJBにWebサービスをつけてEJBプレゼンテーション層から呼び出してます.サービスの中でLocalなEJBを呼び出しています。(当時実験したところGlassFishにRMI-IIOP接続するにはJava6でしか動作しないjarを呼び出し元に入れる必要があった)。 スレッドが多い状態での動作は見てませんが、単一スレッドでlocalhostのWebサービスから中のデータを取り出してXMLファイルに保存するのに11分ですんでいます。このファイルセットを単純にファイルコピーするだけで10分近くかかるので、読み出しスピードは気にしなくていいのではないかと思っています。書き込み(復元)の方は40分ほどかかっていますが、EJBで重複チェックなどしているためで、Webサービスを呼び出すことによるオーバヘッドとは思っていません。またlocalhostでなく近くのマシンのWebサービスから取り出した場合でも13分ですんでいます。 やむなくi)を選択しているのですが、ii)を選択した場合、画面への同時アクセス数が膨大になったときにEJB処理の方にも実行時間に影響がでるのではないかと思うのですが、そんなことはないのですか? | ||||||||||||
|
投稿日時: 2008-07-14 11:17
あしゅ様、だっちょ様、返信ありがとうございます。
あしゅ様> なるほど。 非常に勉強になります。分かりやすいご回答ありがとうございます。 だっちょ様>
確かに影響は出るかと思います。ただ、プレゼンテーションを行う為のビジネス層なので、EJB処理のスループットが良くてもプレゼンテーション層がボトルネックになってしまっては意味が無い様な気もします。 一度iiの方法で何か作ってみて、より理解を深めたいと思います。 重ねてご回答ありがとうございました。 |
1