Oracle Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング

CORBA サーバ アプリケーションのスケーリング

ここでは、以下の内容について説明します。

このトピックでは Production サンプル アプリケーションを例として使用し、CORBA C++ アプリケーションをスケーリングして処理能力を高める方法を示します。事前に、必ず次の個所をお読みください。

Production サンプル アプリケーションのスケーリングについて

Production サンプル アプリケーションには、Wrapper サンプル アプリケーションと同じエンド ユーザ向けの機能が用意されています。Production サンプル アプリケーションでは、Oracle Tuxedo ソフトウェアの機能を使用して既存の Oracle Tuxedo アプリケーションをスケーリングする方法が示されます。

この節では、以下の内容について説明します。

設計上の目標

Production サンプル アプリケーションの設計上の主な目標は、次の処理により、対応できるクライアント アプリケーションの数を大幅に増やすことです。

アプリケーションのスケーリング方法

これらの設計上の目標に対応するため、Production サンプル アプリケーションは次のようにしてスケーリングされています。

以下の節では、Production サンプル アプリケーションが複製されたサーバ プロセスとサーバ グループ、オブジェクト状態管理、およびファクトリ ベース ルーティングをどのように使用して、スケーラビリティの目標を達成するかを説明します。

OMG IDL の変更

Production サンプル アプリケーションでの OMG IDL の変更は、RegistrarFactory オブジェクトの find_registrar() オペレーション、および TellerFactory オブジェクトの find_teller() オペレーションに限定されています。2 つのオペレーションは、それぞれ学生 ID と口座番号を要求するように修正する必要があります。これらは、ファクトリ ベース ルーティングの実装に必要なものです。Production サンプル アプリケーションでのファクトリ ベース ルーティングの実装と使用については、「ファクトリ ベース ルーティングによるスケーリング」を参照してください。

ステートレス オブジェクト モデルの使用方法

ここでは、Production サンプル アプリケーションにおいて、スケーラビリティを増大させるために、オブジェクト状態管理をどのように Registrar オブジェクトおよび Teller オブジェクトで使用するかを説明します。オブジェクト状態管理の概要については、「オブジェクト状態管理の使用」を参照してください。

スケーラビリティを増大させるには、Production サーバ アプリケーションで、Registrar および Teller オブジェクトに method アクティブ化ポリシーをコンフィグレーションします。これら 2 つのオブジェクトに method アクティブ化ポリシーを割り当てた結果、振る舞いに次の変化がみられます。

Basic から Wrapper までの各種サンプル アプリケーションでは、Registrar オブジェクトはプロセス バウンド オブジェクト (process アクティブ化ポリシー) となっていました。Registrar オブジェクトに対するクライアント要求はすべて、常にサーバ マシンのメモリ内の同じオブジェクト インスタンスに送られました。Basic サンプル アプリケーションの設計は、すべての小規模なデプロイメントに適しています。しかし、クライアント アプリケーションの要求が増すにつれて、Registrar オブジェクト上のクライアント要求はキューに入れられるようになり、このため応答時間が遅くなります。

ただし、Registrar および Teller オブジェクトがステートレス オブジェクト (method アクティブ化ポリシー) であり、これらのオブジェクトを管理するサーバ プロセスが複製されている場合、Registrar および Teller の各オブジェクトは並行して複数のクライアント要求を処理できます。これらのオブジェクトで処理できる同時のクライアント要求の数で制約があるのは、Registrar および Teller のオブジェクトをインスタンス化できる、利用可能なサーバ プロセスの数だけです。したがって、これらのステートレス オブジェクトはマシン リソースのより効率的な使用と、クライアント応答時間の短縮を実現します。

最も重要なのは、Oracle Tuxedo CORBA で、Registrar および Teller オブジェクトのコピーを各複製サーバ プロセス内でインスタンス化できるように、オブジェクトの各コピーがユニークでなければならないことです。これらのオブジェクトの各インスタンスをユニークにするために、オブジェクトのファクトリではユニークなオブジェクト ID をオブジェクトに割り当てる必要があります。

Oracle Tuxedo アプリケーションが複製サーバ アプリケーション プロセスのそれぞれで Registrar および Teller オブジェクトのコピーをインスタンス化するには、オブジェクトの各コピーがユニークなオブジェクト ID (OID) を備えていなければなりません。ユニークな OID は、これらのオブジェクトを作成するファクトリで割り当てられます。ユニークなオブジェクト ID の生成についての詳細は、『Tuxedo CORBA サーバ アプリケーションの開発方法』を参照してください。その他の設計上の考慮事項については、「設計上の追加考慮事項」を参照してください。

サーバ プロセスおよびサーバ グループの複製によるスケーリング

ここでは、以下の内容について説明します。

このトピックでは、サーバ プロセスおよびサーバ グループを複製することによる、Production サンプル アプリケーションのスケーリング方法を説明します。概要については、「サーバ プロセスおよびサーバ グループの複製」を参照してください。

Production アプリケーションでのサーバ プロセスの複製

この節では、Production サンプル アプリケーションによるサーバ アプリケーションの複製方法を説明します。この機能の概要については、「サーバ プロセスの複製」を参照してください。

図 2-1 では、単一のマシン上で実行される、複製された ORA_GRP および APP_GRP グループを示します。

これらのグループの 1 つに要求が到達したとき、Oracle Tuxedo ドメインにはこの要求を処理できるサーバ プロセスがいくつかあります。Oracle Tuxedo ドメインは、最も負荷の軽いサーバ プロセスを選択することができます。

図 2-1 では、次の点に留意してください。

Production アプリケーションでのサーバ グループの複製

この節では、Production サンプル アプリケーションによるサーバ グループの複製方法を説明します。この機能の概要については、「サーバ グループの複製」を参照してください。

図 2-2 は、別のマシンに複製された Production サンプル アプリケーションのグループを示します。このアプリケーションの UBBCONFIG ファイルに指定されているとおり、ORA_GRP2 と APP_GRP2 があります。

図 2-2 では、Production マシン 1 と 2 のグループの内容で異なるのはデータベースのみです。

所定のデータベース内の学生情報は、同じデータベース内の口座情報とはまったく関係がない場合があります。

Production サンプル アプリケーションがファクトリ ベース ルーティングを使用して、複数のマシン間にアプリケーションの処理負荷を分散する方法の詳細については、「ファクトリ ベース ルーティングによるスケーリング」を参照してください。

Production アプリケーションの複製サーバ プロセスおよびグループのコンフィグレーション

コード リスト 2-1 は、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  = "ORACLE_XA:Oracle_XA+Acc=P/scott/..."
CLOSEINFO = ""
        TMSNAME   = "TMS_ORA"
    ORA_GRP2
        LMID      = SITE1
        GRPNO     = 5
        OPENINFO  = "ORACLE_XA:Oracle_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

ファクトリ ベース ルーティングによるスケーリング

ここでは、以下の内容について説明します。

このトピックでは、ファクトリ ベース ルーティングを使用して Production サンプル アプリケーションをスケーリングする方法について説明します。ファクトリ ベース ルーティングの概要については、「ファクトリ ベース ルーティングの使用 (CORBA サーバのみ)」を参照してください。

Production アプリケーションでのファクトリ ベース ルーティングについて

この節では、Production サンプル アプリケーションがどのようにファクトリ ベース ルーティングを使用するかを説明します。この機能の概要については、「ファクトリ ベース ルーティングの使用 (CORBA サーバのみ)」を参照してください。

ファクトリ ベース ルーティングを使用すると、Oracle Tuxedo CORBA のロード バランシング機能およびスケーラビリティ機能を拡張できます。Production サンプル アプリケーションでは、ファクトリ ベース ルーティングを使用して、1 つのマシンに 1 つの学生のサブセットを登録する要求を、別のマシンに別の学生のサブセットを登録する要求を送信できます。アプリケーションの処理機能を向上させると、アプリケーション内でのファクトリ ベース ルーティングを簡単に変更して、マシンをさらに追加できます。

Production サンプル アプリケーションでのファクトリ ベース ルーティングの実装に関する設計上の主な考慮事項は、ルーティングの基準となる値の選択です。Production サンプル アプリケーションは、次のようにファクトリ ベース ルーティングを使用します。

UBBCONFIG ファイルでのファクトリ ベース ルーティングのコンフィグレーション

University Production サンプル アプリケーションでは、ファクトリ ベース ルーティングの実装方法が例示されます。ubb_b.nt コンフィグレーション ファイルからの INTERFACES、ROUTING、および GROUPS セクションでは、Oracle Tuxedo CORBA アプリケーションでファクトリ ベース ルーティングを実装する方法が示されます。このサンプルの ubb_p.nt または ubb_p.mk UBBCONFIG ファイルは、Oracle Tuxedo ソフトウェアをインストールしたディレクトリで見つけることができます (¥samples¥corba¥university¥production サブディレクトリを参照)。

UBBCONFIG ファイルでは、グループおよびマシンの識別方法に加えて、INTERFACES および ROUTINGセクションにおいて、以下のデータを指定する必要があります。

ファクトリでのファクトリ ベース ルーティングの実装

ファクトリでは、TP::create_object_reference() オペレーションに対する呼び出しの実装と同様の方式でファクトリ ベース ルーティングが行われます。このオペレーションには、コード リスト 2-5 の C++ バインディングがあります。

CORBA::Object_ptr  TP::create_object_reference (
                       const char* interfaceName,
                       const PortableServer::oid &stroid,
                        CORBA::NVlist_ptr criteria);

このオペレーションに対する 3 番目のパラメータである criteria は、ファクトリ ベース ルーティングに使用される、名前の付いた値を指定します。ファクトリ内でファクトリ ベース ルーティングを実装するには、NVlist をビルドする必要があります。ファクトリ ベース ルーティングの使用はオプションであり、この引数に依存します。ファクトリ ベース ルーティングを使用する代わりに、この引数に 0 (ゼロ) の値を渡すこともできます。

前述のように、Production サンプル アプリケーションの RegistrarFactory オブジェクトは、値 STU_ID を指定します。この値は、UBBCONFIG ファイル内の次の情報に完全一致している必要があります。

RegistrarFactory オブジェクトは、コード リスト 2-6 に記載のコードを使用して、学生 ID を NVlist に挿入します。

// 学生 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 オブジェクトには、コード リスト 2-7 に示す TP::create_object_reference() オペレーションに対する呼び出しが含まれます。これにより、コード リスト 2-6 で作成された NVlist が渡されます。

// ルーティング基準を使用して、registrar オブジェクト参照
// を作成
CORBA::Object_var v_reg_oref =
    TP::create_object_reference(
        UniversityP::_tc_Registrar->id(),
        object_id,
        v_criteria.in()
    );

Production サンプル アプリケーションはまた、TellerFactory オブジェクトでもファクトリ ベース ルーティングを使用し、口座番号に基づいて Teller オブジェクトがインスタンス化されるべきグループを決定します。

実行時の処理

ファクトリでファクトリ ベース ルーティングを実装するとき、Oracle Tuxedo CORBA によってオブジェクト参照が生成されます。以下の例では、ファクトリ ベース ルーティングの実装時に、クライアント アプリケーションが Registrar オブジェクトへのオブジェクト参照を取得する方法を示します。

クライアント アプリケーションがその後、オブジェクト参照を使用してオブジェクトを呼び出すと、Oracle Tuxedo CORBA はオブジェクト参照で指定されたグループに要求をルーティングします。

設計上の追加考慮事項

ここでは、以下の内容について説明します。

設計上の追加考慮事項について

Registrar オブジェクトおよび Teller オブジェクトを設計する際には、次のことを確認してください。

オブジェクトはユニークなオブジェクト ID (OID) を持ち、メソッド バウンドである必要があります。つまり、これらのオブジェクトには、method アクティブ化ポリシーが割り当てられている必要があります。

Registrar オブジェクトおよび Teller オブジェクトのインスタンス化

Production サンプル アプリケーションほど高度でない University サーバ アプリケーションでは、Registrar オブジェクトと Teller オブジェクトの実行時の振る舞いは、より単純でした。

しかし今では、University および Billing サーバ プロセスは複製されているため、Oracle Tuxedo CORBA は Registrar オブジェクトと Teller オブジェクトの複数インスタンスを区別できなくてはなりません。たとえば、グループ内で 2 つの University サーバ プロセスが実行されている場合、Oracle Tuxedo CORBA には、1 つ目の University サーバ プロセスで実行されている Registrar オブジェクトと、2 つ目のサーバ プロセスで実行されている Registrar オブジェクトを区別する手段が必要です。これらのオブジェクトの複数のインスタンスを区別するには、各オブジェクト インスタンスがユニークである必要があります。

各 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 セットを送信します。RegistrarFactory オブジェクトでファクトリ ベース ルーティングがどのように実装されるかは、Registrar オブジェクトへのリファレンスがどのように作成されるかによって変わります。

たとえば、クライアント アプリケーションが RegistrarFactory オブジェクトに要求を送信して、Registrar オブジェクトのオブジェクト参照を取得した場合、クライアント アプリケーションはその要求に学生 ID を含めます。クライアント アプリケーションは、RegistrarFactory オブジェクトが返すオブジェクト参照を使用して、その後の Registrar オブジェクトへのすべての呼び出しを、特定の学生のために行う必要があります。ファクトリによって返されたオブジェクト参照は、グループ固有のものだからです。したがって、たとえばクライアント アプリケーションがその後、Registrar オブジェクトに対して get_student_details() オペレーションを呼び出すと、クライアント アプリケーションでは、Registrar オブジェクトが、その学生のデータを格納しているデータベースと関連付けられたサーバ グループにおいて、確実にアクティブ化されます。

この機能を示すために、Production サンプル アプリケーションに実装されている以下の実行シナリオを検討してみます。

上記の説明の RegistrarFactory オブジェクトは、クライアント アプリケーションに、ORA_GRP1 内でのみインスタンス化が可能な Registrar オブジェクトへのユニークなリファレンスを返します。このグループには Production マシン 1 上で実行され、100001 から 100005 までの ID を持つ学生の学生データを格納したデータベースがあります。したがって、クライアント アプリケーションが所定の学生のために、その後の要求をこの Registrar オブジェクトに送信すると、Registrar オブジェクトは適正なデータベースと対話を行います。

Teller オブジェクトが適切なサーバ グループでインスタンス化されるようにする方法

Registrar オブジェクトは Teller オブジェクトが必要になると、University サーバ オブジェクトにキャッシュされていた TellerFactory オブジェクト参照を使用して、TellerFactory オブジェクトを呼び出します。

しかし、TellerFactory オブジェクトではファクトリ ベース ルーティングが使用されているため、Registrar オブジェクトは Teller オブジェクトへのリファレンス要求時に、学生の口座番号を渡します。このようにして TellerFactory オブジェクトは、正しいデータベースを備えたグループ内の Teller オブジェクトへのリファレンスを作成します。

アプリケーションをさらにスケーリングする方法

将来的には、Production サンプル アプリケーションのシステム管理者が Oracle Tuxedo ドメインの容量を増やす必要を感じる場合もあります。たとえば、今後大学の学生数が著しく増えたり、いくつかのキャンパスを包含する、州全体の大学システムのコース登録プロセスに対応するように Production アプリケーションが拡張されたりすることが考えられます。これを行うのに、アプリケーションを修正したり再ビルドしたりする必要はありません。

システム管理者は、以下の処理によって、容量を追加し続けることができます。