|
|
この章では、Oracle Tuxedo システムの主要なスケーラビリティ機能を利用して CORBA サーバ アプリケーションのスケーラビリティを高める方法について、Production University サンプル アプリケーションを例にして説明します。Production サンプル アプリケーションは、これらのスケーラビリティ機能を利用して以下の目標を達成します。
高度にスケーラブルなアプリケーションのサポートは、Oracle Tuxedo システムの長所の 1 つです。多くのアプリケーションは、1 ～ 10 のサーバ プロセス、および 10 ～ 100 のクライアント アプリケーションが動作している環境で良好に機能します。しかし、ビジネス環境では、アプリケーションは次のレベルの処理をサポートする必要があります。
このような要件を負ったアプリケーションをデプロイすると、リソースの不足および性能のボトルネックがすぐに表面化します。Oracle Tuxedo システムではこうした大規模なデプロイメントが複数の方法でサポートされていて、この章ではそれらのうち次の 3 つについて説明します。
アプリケーションを高度にスケーラブルにするために Oracle Tuxedo システムで提供されているほかの機能には、IIOP リスナ/ハンドラがあります。概要については『Tuxedo CORBA アプリケーション入門』、詳細な説明については『Oracle Tuxedo アプリケーションの設定』を参照してください。また、『Oracle Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング』も参照してください。
ここでは、非常に大規模な処理機能を実現できるようにアプリケーションをスケーリングする方法について、Production サンプル アプリケーションを例にして説明します。Production サンプル アプリケーションの設計上の基本的な目標は、対応できるクライアント アプリケーションの数を大幅に増やすために、次のように対処することです。
こうした設計目標に対応するために、Production サンプル アプリケーションでは次の処理をします。
| 注意 : | Production サンプル アプリケーションを使いやすくするために、このアプリケーションは 1 台のマシン上で 1 つのデータベースを使用して実行できるように Oracle Tuxedo ソフトウェア キット上でコンフィグレーションされています。ただし、この章で示した例では、アプリケーションは 2 つのデータベースを使って 2 つのマシン上で動作しています。 |
| 注意 : | Production サンプル アプリケーションの設計では、複数台のマシン上で複数のデータベースを使用して実行するコンフィグレーションが可能になるように設定されています。複数のマシンおよびデータベースを使用するようにコンフィグレーションを変更する作業には、UBBCONFIG ファイルの変更とデータベースの分離が関係し、これらの詳細は「Production サーバ アプリケーションをさらにスケーリングする方法」で説明されています。 |
以後の各節では、Production サンプル アプリケーションのスケーラビリティの目標を達成するために、複製されたサーバ プロセスおよびサーバ グループの使用、オブジェクト状態管理、およびファクトリ ベース ルーティングについて説明します。次の節では、Production サンプル アプリケーションに実装されている OMG IDL の変更について説明します。
Production サンプル アプリケーションでの OMG IDL の変更は、RegistrarFactory オブジェクトの find_registrar() オペレーション、および TellerFactory オブジェクトの find_teller() オペレーションに限定されています。これら 2 つのオペレーションはそれぞれ、ファクトリ ベース ルーティングの実装に必要な学生 ID と口座番号を要求するように変更されます。Production サンプル アプリケーションでのファクトリ ベース ルーティングの実装および使用については、「ファクトリ ベース ルーティング」を参照してください。
Oracle Tuxedo システムでは、サーバ アプリケーションのコンフィグレーションに多様な選択肢が用意されています。たとえば、以下のコンフィグレーションが可能です。
次の節では、複製されたサーバ プロセスおよびグループについて説明するほか、それらを Oracle Tuxedo システムにコンフィグレーションする方法についても説明します。
使用するアプリケーションでサーバ プロセスを複製すると、以下の利点があります。
複製されたサーバ プロセスの利点を完全に活用するには、使用するサーバ アプリケーションによってインスタンス化される各オブジェクトのすべてがユニークな ID を持つようにしてください。こうすれば、オブジェクト上でのクライアント呼び出しによって必要なオブジェクトがインスタンス化される処理が、利用可能な複数のサーバ プロセスの境界内で実行されるので、既にアクティブ化されているオブジェクトのためのキューに入れられずに済みます。
図 8-1 は、次のことを示します。
この図では、2 つのグループは 1 台のマシンで実行されているものとして示されます。
これらのグループのいずれかに要求が着信したとき、Oracle Tuxedo ドメインには要求を処理できる利用可能なサーバ プロセスが複数あり、Oracle Tuxedo ドメインは最も負荷の少ないサーバ プロセスを選択することができます。
図 8-1 では、次の点に注意してください。
サーバ グループの概念は Oracle Tuxedo システムに固有のもので、CORBA の実装に追加されます。サーバ グループは、Oracle Tuxedo システムのスケーラビリティ機能の重要な要素です。基本的に、デプロイメント システムにマシンを追加する場合は、グループを追加する必要があります。
図 8-2 は、別のマシンに複製された Production サンプル アプリケーションのグループを示します。このアプリケーションの UBBCONFIG ファイルに指定されているとおり、ORA_GRP2 と APP_GRP2 があります。
図 8-2 では、Production マシン 1 と 2 のグループの内容で異なるのはデータベースのみです。Production マシン 1 用のデータベースには、学生のサブセットについて、学生情報および口座情報が含まれています。Production マシン 2 用のデータベースには、学生の別のサブセットについて、学生情報および口座情報が含まれています。両方のデータベースにあるコース情報のテーブルは同じ内容です。データベースにある学生情報が、同じデータベース内の口座情報とは完全に無関連であることに注意してください。
サーバ グループのコンフィグレーションの方法、実行場所、および複製の方法は、UBBCONFIG ファイルに指定されています。サーバ グループを複製すると、次の処理が可能になります。
Production サンプル アプリケーションがファクトリ ベース ルーティングを使用して複数台のマシンにアプリケーションの処理負荷を分散させる方法の詳細については、「ファクトリ ベース ルーティング」を参照してください。
使用する Oracle Tuxedo ドメインにある複製されたサーバ プロセスおよびグループをコンフィグレーションするには、以下の手順に従います。
UBBCONFIG ファイルを、「ワードパッド」などのテキスト エディタで開きます。GROUPS セクションで、コンフィグレーションするグループの名前を指定します。SERVERS セクションに、複製するサーバ プロセスに関する次の情報を入力します。GROUP パラメータ。サーバ プロセスが属するグループの名前を指定します。複数のグループに関係するサーバ プロセスを複製する場合は、各グループに 1 つずつサーバ プロセスを指定します。SRVID パラメータ。数値識別子を指定して、サーバ プロセスにユニークな ID を割り当てます。MIN パラメータ。アプリケーションの起動時に開始されるサーバ プロセスのインスタンスの数を指定します。MAX パラメータ。同時に実行できるサーバ プロセスの最大数を指定します。
MIN および MAX パラメータは、指定されたオブジェクトへの要求をサーバ アプリケーションでどの程度まで並行処理できるかを決定します。実行時には、必要に応じて、システム管理者がリソースのボトルネックを調べて、新しいサーバ プロセスを起動することができます。このアプリケーションは、システム管理者がスケーリングできるように設計されています。
次に、Production サンプル アプリケーションの UBBCONFIG ファイルの GROUPS および SERVERS セクションから引用した行を例示します。
*GROUPS
APP_GRP1
LMID = SITE1
GRPNO = 2
TMSNAME = TMS
APP_GRP2
LMID = SITE1
GRPNO = 3
TMSNAME = TMS
ORA_GRP1
LMID = SITE1
GRPNO = 4
OPENINFO = "BEA_XA:BEA_XA+Acc=P/scott/..."
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ORA_GRP2
LMID = SITE1
GRPNO = 5
OPENINFO = "BEA_XA:BEA_XA+Acc=P/scott/..."
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
*SERVERS
# デフォルトでは、各サーバのインスタンスを 2 つアクティブ化
# して、管理者が各サーバのインスタンスを 5 つ
# までアクティブ化できるようにしている
DEFAULT:
MIN = 2
MAX = 5
tellp_server
SRVGRP = ORA_GRP1
SRVID = 10
RESTART = N
tellp_server
SRVGRP = ORA_GRP2
SRVID = 10
RESTART = N
billp_server
SRVGRP = APP_GRP1
SRVID = 10
RESTART = N
billp_server
SRVGRP = APP_GRP2
SRVID = 10
RESTART = N
univp_server
SRVGRP = ORA_GRP1
SRVID = 20
RESTART = N
univp_server
SRVGRP = ORA_GRP2
SRVID = 20
RESTART = N
「CORBA サーバ アプリケーションの概念」で説明したように、オブジェクト状態管理は大規模なクライアント/サーバ システムでは根本的に重要な検討事項です。それは、こうしたシステムでは最適なスループットおよび応答時間を実現することが重要であるためです。この節では、Oracle Tuxedo サーバ アプリケーションによって管理されるオブジェクトのスケーラビリティを高めるためにオブジェクト状態管理を使用する方法を、Production サンプル アプリケーションの Registrar および Teller オブジェクトを例にして説明します。
次の表は、使用する Oracle Tuxedo アプリケーションのスケーラビリティを大きく高めるために、Oracle Tuxedo システムでサポートされているオブジェクト状態管理モデルを使用する方法をまとめたものです。
スケーラビリティによる性能向上を達成するには、Production サーバ アプリケーションの Registrar および Teller オブジェクトを、method アクティブ化ポリシーを持つようにコンフィグレーションする必要があります。これら 2 つのオブジェクトに method アクティブ化ポリシーを割り当てた結果、振る舞いに次の変化がみられます。
Basic サンプル アプリケーションから Wrapper サンプル アプリケーションを通じて、Registrar オブジェクトはプロセス バウンドです。このオブジェクトへのすべてのクライアント要求は、マシンのメモリにある同じオブジェクトのインスタンスへ送られます。Basic サンプル アプリケーションの設計は、すべての小規模なデプロイメントに適しています。しかし、クライアント アプリケーションの要求が増すにつれて、Registrar オブジェクト上のクライアント要求はキューに入れられるようになり、このため応答時間が遅くなります。
しかし、Registrar および Teller オブジェクトがステートレスで、これらのオブジェクトを管理するサーバ プロセスが複製されていれば、これらのオブジェクトはクライアント要求の並行処理に利用可能になります。これらのオブジェクトで同時に処理できるクライアント要求の数に対する唯一の制限は、これらのオブジェクトをインスタンス化できる利用可能なサーバ プロセスの数です。したがって、これらのステートレス オブジェクトはマシン リソースのより効率的な使用と、クライアント応答時間の短縮を実現します。
最も重要なのは、Oracle Tuxedo システムが Registrar および Teller オブジェクトのコピーを、両オブジェクトごとに複製されたサーバ プロセス内でインスタンス化できるようにするためには、これらのオブジェクトのコピーがユニークである必要があるということです。これらのオブジェクトの各インスタンスをユニークにするために、オブジェクトのファクトリではユニークなオブジェクト ID をオブジェクトに割り当てる必要があります。このことも含めて、これら 2 つのオブジェクトに関する設計上の検討事項については、「Registrar および Teller オブジェクトに関する設計上の追加考慮事項」を参照してください。
ファクトリ ベース ルーティングは、特定のサーバ グループへクライアント要求を送信する方法を提供する強力な機能です。ファクトリ ベース ルーティングを使用すれば、アプリケーションの処理負荷を複数のマシンに分散できます。これは、指定されたオブジェクトがインスタンス化されるグループ、つまりマシンを決定できるからです。
ファクトリ ベース ルーティングを使用すれば、Oracle Tuxedo システムのさまざまなロード バランシング機能およびスケーラビリティ機能を拡張することができます。Production サンプル アプリケーションの場合、ファクトリ ベース ルーティングを使用すれば、学生のサブセットの 1 つを登録する要求を 1 台のマシンへ送信し、別のサブセットに関する要求は別のマシンへ送信することができます。使用するアプリケーションの処理能力を増やすためにマシンを追加しても、Oracle Tuxedo システムではアプリケーションのファクトリ ベース ルーティングを簡単に変更してマシンの追加に対応できます。
ファクトリ ベース ルーティングの第一の利点は、デプロイメント環境の拡大に対応して、アプリケーション、特にインタフェースの呼び出し機能をスケール アップするための簡単な方法が提供されることです。アプリケーションのデプロイメント範囲を追加マシンにも広げることは、厳密には管理用の機能であり、アプリケーションの再コーディングや再ビルドは不要です。
クライアント/サーバ アプリケーションにファクトリ ベース ルーティングを実装する際に設計上最も重要な検討事項は、ルーティングのベースとなる値の選択です。以下の節では、ファクトリ ベース ルーティングの機能について、Production サンプル アプリケーションを使用して説明します。Production サンプル アプリケーションは、ファクトリ ベース ルーティングを次のように使用します。
ファクトリでファクトリ ベース ルーティングを実装する際には、ファクトリがオブジェクト参照を作成する方法が変更されます。すべてのオブジェクト参照はグループ ID を含み、デフォルトのグループ ID はオブジェクト参照を作成するファクトリと同じになります。しかし、ファクトリ ベース ルーティングを使用する場合、ファクトリはグループ ID を決定するルーティング基準も含めてオブジェクト参照を作成します。その後、クライアント アプリケーションがこうしたオブジェクト参照を使用して呼び出しを送信すると、Oracle Tuxedo システムによって、要求はオブジェクト参照に指定されたグループ ID へルーティングされます。ここでは、オブジェクト参照に関するグループ ID がどのようにして生成されるかを説明します。
ファクトリ ベース ルーティングを実装するには、次の項目を調整する必要があります。
調整が必要なデータについて説明するために、以降の 2 つの節では、UBBCONFIG ファイルでのファクトリ ベース ルーティングのコンフィグレーションと、ファクトリでのファクトリ ベース ルーティングの実装を説明します。
要求がルーティングされる各インタフェースについて、UBBCONFIG ファイルに次の情報を記述する必要があります。
ファクトリ ベース ルーティングをコンフィグレーションするには、UBBCONFIG ファイルの INTERFACES および ROUTING セクションで次のデータを指定するほか、グループおよびマシンを識別する方法を指定する必要があります。
INTERFACES セクションには、ファクトリ ベース ルーティングを有効にするインタフェースの名前の一覧が示されます。各インタフェースについて、このセクションでインタフェースのルーティングの基準の種類を指定します。このセクションでは、次の例のように、FACTORYROUTING という識別子でルーティング基準を指定します。INTERFACES
"IDL:beasys.com/UniversityP/Registrar:1.0"
FACTORYROUTING = STU_ID
"IDL:beasys.com/BillingP/Teller:1.0"
FACTORYROUTING = ACT_NUM
上の例では、Production サンプルでファクトリ ベース ルーティングが使用される 2 つのインタフェースの完全修飾されたインタフェース名を示します。FACTORYROUTING 識別子は、ルーティング値の名前を指定します。値はそれぞれ、STU_ID および ACT_NUM です。
ROUTING セクションでは、ルーティング値ごとに以下のデータを指定します。TYPE パラメータ。ルーティングの種類を指定します。Production サンプルでは、ルーティングのタイプはファクトリ ベース ルーティングです。したがって、このパラメータは、FACTORY と定義します。FIELD パラメータ。ファクトリがルーティング値に挿入する名前を指定します。Production サンプルでは、フィールドのパラメータはそれぞれ student_id および account_number です。FIELDTYPE パラメータ。ルーティング値のデータ型を指定します。Production サンプルでは、student_id および account_number のフィールド型は long です。RANGES パラメータ。各グループにルーティングされる値を指定します。
次に、Production サンプル アプリケーションで使用する UBBCONFIG ファイルの ROUTING セクションの例を示します。
ROUTING
STU_ID
FIELD = "student_id"
TYPE = FACTORY
FIELDTYPE = LONG
RANGES = "100001-100005:ORA_GRP1,100006-100010:ORA_GRP2"
ACT_NUM
FIELD = "account_number"
TYPE = FACTORY
FIELDTYPE = LONG
RANGES = "200010-200014:APP_GRP1,200015-200019:APP_GRP2"
上の例では、一方の範囲に入る ID を持った学生についての Registrar オブジェクト参照は一方のサーバ グループにルーティングされ、もう一方の範囲に入る ID を持った学生についての Registrar オブジェクト参照は他方のグループにルーティングされるということが示されています。同様に、ある 1 つの範囲の口座に対する Teller オブジェクト参照は、ある 1 つのサーバ グループにルーティングされ、別の範囲の口座に対する Teller オブジェクト参照は、別のグループにルーティングされます。
UBBCONFIG ファイルの ROUTING セクションにある RANGES 識別子で指定されたグループを識別およびコンフィグレーションする必要があります。たとえば、Production サンプルは APP_GRP1、APP_GRP2、ORA_GRP1、および ORA_GRP2 という 4 つのグループを指定します。これらのグループをコンフィグレーションし、グループが実行されるマシンを識別する必要があります。
次の例は、Production サンプルの UBBCONFIG ファイルの GROUPS セクションを示します。このセクションで、ORA_GRP1 および ORA_GRP2 グループがコンフィグレーションされています。GROUPS セクションに列挙されている名前が、ROUTING セクションに指定されているグループ名とどのように一致するかに注目してください。この点が、ファクトリ ベース ルーティングの正常な動作に不可欠です。さらに、アプリケーションでグループをコンフィグレーションする方法に関する何らかの変更も、ROUTING セクションに反映される必要があります。Oracle Tuxedo ソフトウェアに収録されている Production サンプルは、1 台のマシンで実行するようにコンフィグレーションされています。ただし、このアプリケーションを複数のマシンで実行できるようにコンフィグレーションすることは簡単です。
*GROUPS
APP_GRP1
LMID = SITE1
GRPNO = 2
TMSNAME = TMS
APP_GRP2
LMID = SITE1
GRPNO = 3
TMSNAME = TMS
ORA_GRP1
LMID = SITE1
GRPNO = 4
OPENINFO = "BEA_XA:BEA_XA+Acc=P/scott/..."
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ORA_GRP2
LMID = SITE1
GRPNO = 5
OPENINFO = "BEA_XA:BEA_XA+Acc=P/scott/..."
CLOSEINFO = ""
TMSNAME = "TMS_ORA"
ファクトリは、TP::create_object_reference() オペレーションへの呼び出しが実装されている方法によってファクトリ ベース ルーティングを実装します。このオペレーションには、次の C++ バインドがあります。
CORBA::Object_ptr TP::create_object_reference (
const char* interfaceName,
const PortableServer::oid &stroid,
CORBA::NVlist_ptr criteria);
このオペレーションに対する 3 番目のパラメータである criteria は、ファクトリ ベース ルーティングに使用される、名前の付いた値を指定します。このため、ファクトリでファクトリ ベース ルーティングを実装する機能は、NVlist をビルドすることにあります。
前述のように、Production サンプル アプリケーションの RegistrarFactory オブジェクトは、値 STU_ID を指定します。この値は、UBBCONFIG ファイルの次の項目と正確に一致する必要があります。
RegistrarFactory オブジェクトは、次のコードを使用して NVlist に学生 ID を挿入します。
// 学生 ID (ルーティング基準になる)
// を CORBA NVList に挿入する
CORBA::NVList_var v_criteria;
TP::orb()->create_list(1, v_criteria.out());
CORBA::Any any;
any <<= (CORBA::Long)student;
v_criteria->add_value("student_id", any, 0);
RegistrarFactory オブジェクトは次のようにして TP::create_object_reference() オペレーションを呼び出し、前のサンプル コードで作成された NVlist を渡します。
// ルーティング基準を使用して、
// registrar オブジェクト参照を作成
CORBA::Object_var v_reg_oref =
TP::create_object_reference(
UniversityP::_tc_Registrar->id(),
object_id,
v_criteria.in()
);
Production サンプル アプリケーションはまた、TellerFactory オブジェクトでもファクトリ ベース ルーティングを使用し、口座番号に基づいて Teller オブジェクトがインスタンス化されるべきグループを決定します。
| 注意 : | 指定されたインタフェースおよび OID を持つ 1 つのオブジェクトが 2 つの異なるグループで同時にアクティブ化されることも、それら 2 つのグループに同じオブジェクト実装がある場合には起こりえます。しかし、使用するファクトリでユニークな OID が生成されていれば、こうした状況はほぼありません。指定されたインタフェース名および OID の 1 つのオブジェクト インスタンスがドメイン内で一度に 1 つだけ利用可能であることを保証する必要がある場合は、次のいずれかを行います。つまり、ファクトリ ベース ルーティングを使用して、特定の OID のオブジェクトが常に同じグループにルーティングされるようにするか、指定されるオブジェクト実装が 1 つのグループのみに存在するようにドメインをコンフィグレーションするかです。そうすれば、指定されたインタフェース名および OID を持つ 1 つのオブジェクトに複数のクライアントがオブジェクト参照をした場合でも、その参照は常に同じオブジェクト インスタンスへルーティングされることになります。 |
| 注意 : | オブジェクトの OID によるルーティングを利用可能にするには、TP::create_object_reference() オペレーションで OID をルーティング基準に指定してから、UBBCONFIG ファイルをそれに合わせて設定します。 |
ファクトリでファクトリ ベース ルーティングを実装するとき、Oracle Tuxedo システムによってオブジェクト参照が生成されます。次の例は、ファクトリ ベース ルーティングが実装されているときにクライアント アプリケーションが Registrar オブジェクトへのオブジェクト参照を取得する方法を示します。
RegistrarFactory オブジェクトを呼び出し、Registrar オブジェクトの参照を要求します。要求には学生 ID が含まれます。RegistrarFactory は、NVlist に学生 ID を挿入します。これは、ルーティング基準として使用されます。RegistrarFactory は、TP::create_object_reference() オペレーションを呼び出し、Registrar インタフェース名、ユニークな OID、および NVlist を渡します。NVlist の値と比較して、グループ ID を判別します。
続いてクライアント アプリケーションがオブジェクト参照を使用してオブジェクト呼び出しを実行した場合、Oracle Tuxedo システムはその要求を、オブジェクト参照で指定されたグループへルーティングします。
| 注意 : | Process-Entity デザイン パターンを使用する場合は、ファクトリ ベース ルーティングの実装に注意してください。オブジェクトは、グループのデータベースに格納されているエンティティしか処理できません。 |
Registrar および Teller オブジェクトの設計に影響する主な考慮事項には、以下のものがあります。
Registrar および Teller オブジェクトが Production のデプロイメント環境、つまり、複数の複製されたサーバ プロセスおよび複数のグループで適切に機能するようにする方法。University および Billing の各サーバ プロセスが複製されている場合の設計では、これら 2 つのオブジェクトをどのようにインスタンス化するかを考慮する必要があります。
これらの考慮事項の主要な意味は、これらのオブジェクトが次の項目を満たす必要があるということです。
以降の節では、これらの検討事項およびその内容について詳しく説明します。
Production サンプル アプリケーションの前に扱った University サーバ アプリケーションでは、Registrar および Teller オブジェクトの実行時の振る舞いは簡単なものでした。
しかし、University および Billing サーバ プロセスが複製されると、Oracle Tuxedo ドメインには Registrar および Teller オブジェクトの複数のインスタンスを区別する方法が必要になります。つまり、1 つのグループで 2 つの University サーバ プロセスが実行中である場合、Oracle Tuxedo ドメインには、いわば、1 番目の University サーバ プロセスで実行中の Registrar オブジェクトと、2 番目の University サーバ プロセスで実行中の Registrar オブジェクトを区別するための方法が必要になります。
これらのオブジェクトの複数のインスタンスを区別する機能を Oracle Tuxedo ドメインに与える方法は、オブジェクトの各インスタンスをユニークにすることです。
各 Registrar および Teller オブジェクトをユニークなものにするには、これらのオブジェクトのファクトリで、これらに対するオブジェクト参照を作成する方法を変更しなければなりません。たとえば Basic サンプル オブジェクトでは、RegistrarFactory オブジェクトが Registrar オブジェクトへのオブジェクト参照を作成すると、TP::create_object_reference() オペレーションが、文字列 registrar のみからなる OID を指定していました。しかし、Production サンプル アプリケーションでは、同じ TP::create_object_reference() オペレーションが、生成されたユニークな OID を使用します。
Registrar および Teller オブジェクトのそれぞれにユニークな OID を付与した結果、これらのオブジェクトの複数のインスタンスが、Oracle Tuxedo ドメインの中で同時に実行できるようになりました。この特性はステートレス オブジェクト モデルに典型的なもので、Oracle Tuxedo ドメインのスケーラビリティを高めつつ、高い性能を提供する方法の例でもあります。
そして最後に、ユニークな Registrar および Teller オブジェクトはクライアント要求ごとにメモリに格納される必要があるため、これらのオブジェクトへの呼び出しが完了したときには、オブジェクトの状態がメモリ上でアイドル状態となって残らないように、オブジェクトを非アクティブ化することが非常に重要になります。Production サーバ アプリケーションでは、ICF ファイルでこれら 2 つのオブジェクトに method アクティブ化ポリシーを割り当てることで、この問題を解決しています。
複製されたサーバ グループを使用することでスケーラビリティについて得られる最大の利点は、複数のマシンに処理を分散できることです。しかし、University サンプル アプリケーションの場合のように、アプリケーションがデータベースと対話する場合は、これら複数のサーバ グループがデータベースとの対話に与える影響を考慮することが重要です。
多くの場合、デプロイされているマシンに、データベースは 1 つずつ関連付けられています。サーバ アプリケーションが複数台のマシンに分散されている場合は、データベースをどのようにセットアップするかを検討する必要があります。
この章で説明しているように、Production サンプル アプリケーションでは、2 つのデータベースを使用します。しかし、このアプリケーションは、簡単にそれ以上のデータベースに対応できるようコンフィグレーションできます。使用するデータベースの数は、システム管理者が決定してください。
Production サンプル アプリケーションでは、学生および口座の情報は、2 つのデータベース間に分割されますが、コース情報は同一です。コース情報は、コース登録用途では読み取り専用となっているため、両方のデータベースのコース情報が同一であることは問題にはなりません。一方で、学生情報および口座情報については読み書きが行われます。複数のデータベースが学生および口座についても同一のデータを格納するとしたら (つまり、データベースが分割されていない場合)、アプリケーションでは、学生情報または口座情報が変更されるたびにデータベース全体にわたって学生および口座の情報の更新を同期する処理のオーバーヘッドに対処する必要が生じるでしょう。
Production サンプル アプリケーションは、ファクトリ ベース ルーティングによって、1 台のマシンに要求の 1 セットを、別のマシンに要求の別の 1 セットを送信します。先に説明したように、ファクトリ ベース ルーティングは、Registrar オブジェクトの参照が作成されている方法によって RegistrarFactory オブジェクトに実装されています。
たとえば、クライアント アプリケーションが RegistrarFactory オブジェクトに要求を送信して、Registrar オブジェクトのオブジェクト参照を取得した場合、クライアント アプリケーションはその要求に学生 ID を含めます。クライアント アプリケーションは、RegistrarFactory オブジェクトが返すオブジェクト参照を使用して、その後の Registrar オブジェクトへのすべての呼び出しを、特定の学生のために行う必要があります。ファクトリによって返されたオブジェクト参照は、グループ固有のものだからです。したがって、たとえばクライアント アプリケーションがその後、Registrar オブジェクトに対して get_student_details() オペレーションを呼び出すと、クライアント アプリケーションでは、Registrar オブジェクトが、その学生のデータを格納しているデータベースと関連付けられたサーバ グループにおいて、確実にアクティブ化されます。この機能を示すために、Production サンプル アプリケーションに実装されている以下の実行シナリオを検討してみます。
RegistrarFactory オブジェクトの find_registrar() オペレーションを呼び出します。この要求には学生 ID 1000003 が含まれます。 RegistrarFactory オブジェクトにルーティングします。RegistrarFactory オブジェクトは、UBBCONFIG ファイルのルーティング情報に基づいて、学生 ID を使用して ORA_GRP1 の Registrar オブジェクトへのオブジェクト参照を作成し、このオブジェクト参照をクライアント アプリケーションに返します。register_for_courses() オペレーションを呼び出します。 Registrar オブジェクトをインスタンス化し、それにクライアント呼び出しを送信します。
以上のシナリオの RegistrarFactory オブジェクトがクライアント アプリケーションに返すのは、ORA_GRP1 でだけインスタンス化できる Registrar オブジェクトへのユニークな参照です。ORA_GRP1 は Production マシン 1 で実行されていて、学生 ID が 100001 ～ 100005 の範囲の学生に関するデータが格納されているデータベースを利用します。このため、続けてクライアント アプリケーションが学生に関する Registrar オブジェクトへの要求を送信したとき、Registrar オブジェクトは適切なデータベースとやり取りができます。
Registrar オブジェクトで Teller オブジェクトが必要になると、Registrar オブジェクトは TellerFactory オブジェクトを呼び出します。このとき、University Server オブジェクトでキャッシュされている TellerFactory オブジェクト参照が使用されます。詳細については、「Teller オブジェクトへの要求の送信」を参照してください。
しかし、TellerFactory オブジェクトではファクトリ ベース ルーティングが使用されているため、Registrar オブジェクトは Teller オブジェクトの参照要求時に、学生の口座番号を渡します。このようにして TellerFactory オブジェクトは、正しいデータベースを備えたグループ内の Teller オブジェクトの参照を作成します。
| 注意 : | Production サンプル アプリケーションが適正に動作するためには、システム管理者がサーバ グループとデータベースのコンフィグレーションを正しく行うことが不可欠です。具体的には、システム管理者はルーティング テーブルで指定されたルーティング基準と、これらの基準を使用した要求のルーティング先となるデータベースを、確実に一致させる必要があります。Production サンプルを例にすると、指定されたグループにあるデータベースは、そのグループにルーティングされた要求に正しく対応する学生情報および口座情報を含んでいる必要があります。 |
将来的には、Production サンプル アプリケーションのシステム管理者が Oracle Tuxedo ドメインの容量を増やす必要を感じる場合もあります。たとえば、University で学生数が大幅に増加した場合や、7 つのキャンパスがある大学の全体のコース登録処理を扱えるように Production アプリケーションをスケール アップする場合などが考えられます。これを行うのに、アプリケーションを修正したり再ビルドしたりする必要はありません。
継続的に容量を追加するために、システム管理者には以下のツールが用意されています。
UBBCONFIG ファイルを変更する必要があります。サーバ プロセスが実行されるグループを追加し、グループでどのサーバ プロセスを実行するか指定してから、どのマシンで実行するかを指定してください。
たとえば、この章で示したように 2 つのグループへルーティングする代わりに、システム管理者が UBBCONFIG ファイルでルーティング ルールを変更することで、Oracle Tuxedo ドメインに追加された新しいグループの間でアプリケーションの処理をさらに分離することが可能です。ルーティング テーブルへのすべての変更は、UBBCONFIG ファイルでコンフィグレーションされているサーバ グループおよびマシンに対するすべての変更および追加と整合している必要があります。
| 注意 : | データベースを使用するアプリケーションの容量を増やす場合、特にファクトリ ベース ルーティングを使用しているときには、データベースの設定に与える影響を検討する必要があります。たとえば、Production サンプル アプリケーションが 6 台のマシン間に分散している場合は、UBBCONFIG ファイルのルーティング テーブルに基づいて、適切に各マシンのデータベースを設定する必要があります。 |
一般に、ステートレス オブジェクトを実装する際のコストと、ステートフル オブジェクトを実装する際のコストを比較する必要があります。
オブジェクトをその永続状態で初期化するコストが高い場合 (これは、たとえば、そのオブジェクトのデータが大きな領域を占めている場合や、永続状態の場所が、それをアクティブ化するサーバントから大幅に離れたディスク上である場合ですが)、たとえオブジェクトが会話の間アイドル状態であるとしても、オブジェクトをステートフルにしておく方が合理的です。オブジェクトをアクティブ化されたままにしておくコストが、マシンのリソース使用率との関連で高額になる場合は、そのようなオブジェクトをステートレスにするほうが合理的です。
オブジェクトの状態を、アプリケーションに合わせて効率的かつ適切な方法で管理することにより、アプリケーションの能力を最大限に高めて、多数のオブジェクトを使用する多数のクライアント アプリケーションを同時にサポートできます。一般には、こうした目的のために、オブジェクトに対して method アクティブ化ポリシーを割り当てます。こうすることによって、アイドル状態のオブジェクト インスタンスが非アクティブ化され、マシンのリソースをほかのオブジェクト インスタンスに割り当てられるようになります。ただし、使用するアプリケーション固有の特性および要件は、アプリケーションごとに異なります。
| 注意 : | Oracle Tuxedo リリース 8.0 以降では、性能の拡張として、パラレル オブジェクトのサポートが提供されています。この機能を利用すると、特定アプリケーションのすべてのビジネス オブジェクトをステートレス オブジェクトにすることができます。詳細については、『Tuxedo CORBA プログラミング リファレンス』の「TP フレームワーク」を参照してください。 |
サーバ リソースはオブジェクトがアイドル状態のときには絶対に使用されないため、ステートレス オブジェクトは一般に、サーバ リソースの性能を高め、最適な使い方を実現します。ステートレス オブジェクトは、一般に、サーバ アプリケーションの実装に適した手法です。ステートレス オブジェクトは、特に以下の状況に適しています。
オブジェクトをステートレスにすることで、サーバ アプリケーションのリソースがクライアント アプリケーションからの入力の待機のために不定期に長時間拘束されないようにできます。
ステートレス オブジェクト モデルを使用するアプリケーションでは、次の特性に注意してください。
ステートフル オブジェクトは、いったんアクティブ化されると、オブジェクトが存在しているプロセスが停止されたり、オブジェクトがアクティブ化されているトランザクションが完了したりといった、特定のイベントが発生するまで、メモリ内にとどまります。
ステートフル オブジェクトは、一般に以下の状況に適しています。
| 注意 : | プロセス オブジェクトをトランザクションにどのように関与させるかについては、注意深く検討してください。トランザクションに関与しているすべてのオブジェクトは、ほかのクライアント アプリケーションまたはオブジェクトから呼び出せません。プロセス オブジェクトは多数のクライアント アプリケーションによって利用されるので、トランザクションに対して頻繁に、または長期間関与すると、問題の原因になる可能性があります。 |
ステートフル オブジェクトの以下の振る舞いに注意してください。
たとえば、1 つのオブジェクトがデータベースにロックを保持し、大量のデータをメモリにキャッシュしている場合、そのステートフル オブジェクトによって使用されているデータベースおよびメモリは、トランザクションが完了するまでほかのオブジェクトでは利用できません。
  
|