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の生成についての詳細は、『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
    # By default, activate 2 instances of each server
    # and allow the administrator to activate up to 5
    # instances of each server
    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に挿入します。

// put the student id (which is the routing criteria)
// into a 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が渡されます。

// create the registrar object reference using
// the routing criteria :
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つ目のUniversityサーバー・プロセスで実行されている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オブジェクトは、クライアント・アプリケーションに、Productionマシン1上で実行され、100001から100005までのIDを持つ学生の学生データを格納したデータベースが含まれる、ORA_GRP1内でのみインスタンス化が可能なRegistrarオブジェクトへの一意の参照を返します。したがって、クライアント・アプリケーションが所定の学生のために、その後のリクエストをこのRegistrarオブジェクトに送信すると、Registrarオブジェクトは適正なデータベースと対話を行います。

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

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

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

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

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

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