3 拡張プロキシの構成

この章では、Coherence*Extendプロキシを構成する手順について説明します。拡張プロキシにより、クライアントは、Coherenceクラスタに定義されているキャッシュにアクセスして、これらのキャッシュを使用できます。この章の各手順は、基本設定を行うためのものであり、完全な構成方法を示すものではありません。

この章の内容は次のとおりです。

3.1 拡張プロキシの構成の概要

拡張プロキシは、ExtendクライアントがCoherenceクラスタのキャッシュにアクセスして、これらのキャッシュを使用できるようにする、クラスタ内のサーバー(DefaultCacheServerプロセス)です。プロキシ・サーバーは、データの格納は行わず、クライアント・リクエストの受入れのみに使用されます。プロキシ・サーバーはプロキシ・サービスで構成され、このプロキシ・サービスは、クラスタ上で実行されるキャッシュ・サービス・インスタンスおよび起動サービス・インスタンスにアクセスできる基礎となるクラスタ・サービスです。Coherenceクラスタには、Extendクライアントの接続を受け入れるための拡張プロキシ・サービスと、クライアントでデータを取得して格納する際に使用するキャッシュが組み込まれている必要があります。

拡張プロキシ・サービスは、キャッシュ構成デプロイメント・ディスクリプタで構成されます。このデプロイメント・ディスクリプタは、多くの場合、クラスタ側のキャッシュ構成ファイルと呼ばれます。これは、クラスタでキャッシュを設定する際に使用するキャッシュ構成ファイルと同じです。キャッシュ構成デプロイメント・ディスクリプタの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

3.2 拡張プロキシ・サービスの定義

拡張プロキシ・サービス(ProxyService)は、ExtendクライアントからTCP/IPを使用してCoherenceクラスタにアクセスできるクラスタ・サービスです。プロキシ・サービスには、CacheServiceクラスタ・サービス(クライアントからキャッシュへのアクセスに使用)、およびInvocationServiceクラスタ・サービス(クライアントがクラスタ上でInvocableオブジェクトを実行する際に使用)の2種類のクラスタ・サービス用のプロキシが組み込まれています。

この項の内容は、次のとおりです。

3.2.1 単一のプロキシ・サービス・インスタンスの定義

拡張プロキシ・サービスは、<caching-schemesノード内で、<proxy-scheme要素を使用して構成します。例3-1では、ExtendTcpProxyServiceという名前のプロキシ・サービスを定義し、クラスタ・ノードでサービスが自動的に開始されるように、trueに設定されている<autostart要素が含まれます。<proxy-schemeのすべてのサブ要素の一覧と説明は、『Oracle Coherenceでのアプリケーションの開発』の<proxy-scheme要素参照を参照してください。

例3-1に構成されているように、プロキシ・アドレスおよびエフェメラル・ポートが自動的に割り当てられ、クラスタ・ネーム・サービスに登録されます。Extendクライアントはネーム・サービスに接続し、リクエストされたプロキシのアドレスにクライアントをリダイレクトします。ネーム・サービスを使用すると、プロキシをエフェメラル・アドレス上で実行できるため、ポート管理と構成が簡素化します。プロキシのアドレスおよびポートの明示的な定義の詳細は、「プロキシ・アドレスの明示的な構成」を参照してください。

例3-1 拡張プロキシ・サービスの構成

...
<caching-schemes>
   <proxy-scheme>
      <service-name>ExtendTcpProxyService</service-name>
      <autostart>true</autostart>
   </proxy-scheme>
</caching-schemes>
...

3.2.2 複数のプロキシ・サービス・インスタンスの定義

予想されるクライアント接続数をサポートするため、およびフォルト・トレランスとロード・バランシングをサポートするために、複数の拡張プロキシ・サービス・インスタンスを定義できます。クライアント接続は、プロキシ・サービス・インスタンス間で自動的に調整されます。接続の調整に使用されているアルゴリズムは、構成されているロード・バランシングの戦略によって変わります。ロード・バランシングの詳細は、「ロード・バランシング接続」を参照してください。

複数のプロキシ・サービス・インスタンスを定義するには、単一のプロキシ・サービス定義を複数のプロキシ・サーバーで読み込んで、各プロキシ・サービスに同じサービス名を使用します。同じサービス名のプロキシ・サービスはピアと見なすことができます。

次の例では、ExtendTcpProxyServiceプロキシ・サービスの2つのインスタンスを定義します。プロキシ・サービス定義は、各キャッシュ・サーバーのそれぞれのキャッシュ設定ファイルで <proxy-scheme>要素内に含まれています。同じマシン上に共存するプロキシを含む、すべてのプロキシで同じ構成を使用できます。

プロキシ・サーバー1:

...
<caching-schemes>
   <proxy-scheme>
      <service-name>ExtendTcpProxyService</service-name>
      <autostart>true</autostart>
   </proxy-scheme>
</caching-schemes>
...

プロキシ・サーバー2:

...
<caching-schemes>
   <proxy-scheme>
      <service-name>ExtendTcpProxyService</service-name>
      <autostart>true</autostart>
   </proxy-scheme>
</caching-schemes>
...

3.2.3 複数のプロキシ・サービスの定義

複数の拡張プロキシ・サービスを定義することにより、それぞれのプロキシで異なるアプリケーションを提供できます。より予測性の高い環境を構築するために、特定のアプリケーションのExtendクライアントを特定のプロキシに誘導できます。

次の例では、ExtendTcpProxyService1とExtendTcpProxyService2の2つの拡張プロキシ・サービスを定義します。

...
<caching-schemes>
   <proxy-scheme>
      <service-name>ExtendTcpProxyService1</service-name>
      <autostart>true</autostart>
   </proxy-scheme>
   <proxy-scheme>
      <service-name>ExtendTcpProxyService2</service-name>
      <autostart>true</autostart>
   </proxy-scheme>
</caching-schemes>
...

3.2.4 プロキシ・アドレスの明示的な構成

ネーム・サービスに対応していない古いExtendクライアント、または特定のファイアウォールの制約のあるクライアントでは、特定のプロキシ・アドレスが必要になる場合があります。この場合、特定のアドレスとポートでリスニングするようにプロキシを明示的に構成できます。ファイアウォール構成の詳細は、「Extendクライアントのファイアウォールの構成」を参照してください。

子要素の<tcp-acceptor>には、TCP/IPクライアント通信のために拡張プロキシ・サービスがリスニングするアドレス(IPまたはDNS名と、ポート)が含まれます。アドレスは、<address-provider>要素を使用して明示的に定義するか、オペレーション・オーバーライド構成ファイル内で定義できます。さらに、<address-provider>要素を使用して参照できます。後者の方法は、アドレス構成をプロキシ・スキーム定義から分離し、プロキシ定義を変更することなくランタイムでのアドレスの変更を可能にします。アドレス定義の参照の詳細は、「TCPアドレス用のアドレス・プロバイダ参照の使用」を参照してください。

例3-2では、198.168.1.5およびポート7077にバインドされているTCP/IPソケットでクライアント・リクエストをリスニングするように設定されている、ExtendTcpProxyServiceという名前のプロキシ・サービスを定義します。

例3-2 明示的に構成されたプロキシ・サービス・アドレス

...
<caching-schemes>
   <proxy-scheme>
      <service-name>ExtendTcpProxyService</service-name>
      <acceptor-config>
         <tcp-acceptor>
            <address-provider>
               <local-address>
                  <address>192.168.1.5</address>
                  <port>7077</port>
               </local-address>
            </address-provider>
         </tcp-acceptor>
      </acceptor-config>
      <autostart>true</autostart>
   </proxy-scheme>
</caching-schemes>
...

指定したポートは、他のアプリケーションに自動的に割り当てられないように、コンピュータのエフェメラル・ポートの範囲外になるようにしてください。指定したポートを使用できない場合、デフォルトの動作では、次に使用可能なポートを選択します。自動ポート調整を無効にするには、値falseを含む<port-auto-adjust>要素を追加します。また、ポートの選択範囲を指定する場合は、ポート範囲の上限を表すポート値を含めます。次の例では、7077から8000のポート範囲を設定します。

<acceptor-config>
   <tcp-acceptor>
      <local-address>
         <address-provider>
            <address>192.168.1.5</address>
            <port>7077</port>
            <port-auto-adjust>8000</port-auto-adjust>
         </address-provider>
      </local-address>
   </tcp-acceptor>
</acceptor-config>

<address>要素では、CIDR注釈をサブネットおよびマスクとして使用できます(例: 192.168.1.0/24)。CIDRは、単一のアドレス構成によって、同一サブネット内のコンピュータ間での情報共有を可能にすることで、構成を単純化しています。各クラスタ・メンバーで同じCIDRアドレス・ブロックを指定すると、各コンピュータのローカルNICでは、自動的にアドレス・パターンの一致が検出されます。/24の接頭辞のサイズは、192.168.1.0から192.168.1.255までの256の使用可能アドレスと一致します。

ファイアウォールが不要なソリューションの場合は、IPおよびポート値を省略可能で、これにより、TCMP (デフォルトで7574)と同じIPアドレスおよびポートがプロキシで使用されます。リスニング・ポートを0にしてポートを構成することも可能で、これにより、プロキシはシステム割当てのエフェメラル・ポートでリスニングします。「単一のプロキシ・サービス・インスタンスの定義」に示すように、構成は<acceptor-config>要素を省略した場合と同じです。エフェメラル・ポートを使用するようにプロキシが構成されている場合、クライアントはクラスタ・ネーム・サービスを使用してプロキシを特定する必要があります。

3.2.5 クラスタ・サービス・プロキシの無効化

キャッシュ・サービス・プロキシと起動サービス・プロキシは、拡張プロキシ・サービス定義内で無効化できます。これらのプロキシはいずれもデフォルトで有効になっており、クライアントにサービスが不要な場合は明示的に無効化できます。

クラスタ・サービス・プロキシは、それぞれ<cache-service-proxy>内および<invocation-service-proxy>内で<enabled>要素をfalseに設定することによって無効にします。

次の例では、Extendクライアントがクラスタ内でInvocableオブジェクトを実行できないように、起動サービス・プロキシを無効にします。

<proxy-scheme>
   ...
   <proxy-config>
      <invocation-service-proxy>
         <enabled>false</enabled>
      </invocation-service-proxy>
   </proxy-config>
   ...
</proxy-scheme>

同様に、次の例では、Extendクライアントがクラスタ内のキャッシュへアクセスしないようにキャッシュ・サービス・プロキシを無効にします。

<proxy-scheme>
   ...
   <proxy-config>
      <cache-service-proxy>
         <enabled>false</enabled>
      </cache-service-proxy>
   </proxy-config>
   ...
</proxy-scheme>

3.2.6 NamedCache読取り専用アクセスの指定

デフォルトでは、Extendクライアントは、プロキシ設定されたNamedCacheインスタンスに対するデータの読取りおよび書込みがいずれも許可されています。<cache-service-proxy>要素内で<read-only>要素を指定すると、Extendクライアントでは、クラスタ上でキャッシュされているコンテンツを変更できなくなります。次に例を示します。

<proxy-scheme>
   ...
   <proxy-config>
      <cache-service-proxy>
         <read-only>true</read-only>
      </cache-service-proxy>
   </proxy-config>
   ...
</proxy-scheme>

3.3 Extendクライアントで使用するキャッシュの定義

Extendクライアントは、クラスタ上のキャッシュに対してデータの読取りおよび書込みを行います。クライアント・データは、どのようなキャッシュ・タイプでも格納できます。Extendクライアントの場合、クラスタ上のキャッシュは、クライアント側で使用されているキャッシュと同じ名前である必要があります。「リモート・キャッシュの定義」を参照してください。キャッシュの定義の詳細は、『Oracle Coherenceでのアプリケーションの開発』のキャッシュの使用に関する項を参照してください。この項では、クライアントの拡張に一般的に使用される3つのキャッシュ・タイプの基本的な例について説明します

基本パーティション(分散)キャッシュ

次の例では、dist-extendという名前の基本パーティション・キャッシュを定義します。

...
<caching-scheme-mapping>
   <cache-mapping>
      <cache-name>dist-extend</cache-name>
      <scheme-name>dist-default</scheme-name>
   </cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
   <distributed-scheme>
      <scheme-name>dist-default</scheme-name>
      <backing-map-scheme>
         <local-scheme/>
      </backing-map-scheme>
      <autostart>true</autostart>
   </distributed-scheme>
</caching-schemes>
...

基本ニア・キャッシュ

一般的なニア・キャッシュは、ローカル・キャッシュ(スレッド・セーフで並行性が高く、かつサイズが制限されており、場合によっては自動的に失効するもの)をフロント・キャッシュとして使用し、リモート・キャッシュをバック・キャッシュとして使用するように構成されます。ニア・キャッシュの構成には、2つの子要素を持つnear-schemeが使用され、1つはローカル(フロント)・キャッシュを構成するためのfront-scheme、もう1つはリモート(バック)・キャッシュを定義するためのback-schemeです。

ニア・キャッシュは、coherence-cache-configファイルの<near-scheme>要素を使用して構成します。この要素には、ローカル(フロント層)キャッシュを構成するためのfront-schemeと、リモート(バック層)キャッシュを定義するためのback-schemeの2つのサブ要素が要求されます。フロント層には通常、ローカル・キャッシュ(<local-scheme>)を選択しますが、JVMヒープ・ベース以外のキャッシュ(<external-scheme>または<paged-external-scheme>)またはJavaオブジェクトに基づくスキーム(<class-scheme>)も使用できます。

リモート、すなわちバック層のキャッシュは、<back-scheme>要素を使用して記述します。バック層のキャッシュには、分散キャッシュ(<distributed-scheme>)またはリモート・キャッシュ(<remote-cache-scheme>)を定義できます。<remote-cache-scheme>要素を使用すると、現在のクラスタの外部からクラスタ化キャッシュを使用できます。

<near-scheme>のオプションのサブ要素には、フロント層とバック層のオブジェクトの同期を維持する戦略を指定する<invalidation-strategy>、およびキャッシュで発生したイベントの通知を受け取るリスナーを指定する<listener>などがあります。

例3-3は、ニア・キャッシュの構成を示しています。

例3-3 ニア・キャッシュ構成

<?xml version="1.0"?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
   coherence-cache-config.xsd">
   <caching-scheme-mapping>
      <cache-mapping>
         <cache-name>dist-extend-near</cache-name>
         <scheme-name>extend-near</scheme-name>
      </cache-mapping>
   </caching-scheme-mapping>
   <caching-schemes>
      <near-scheme>
         <scheme-name>extend-near</scheme-name>
         <front-scheme>
            <local-scheme>
               <high-units>1000</high-units>
            </local-scheme>
         </front-scheme>
         <back-scheme>
            <remote-cache-scheme>
               <scheme-ref>extend-dist</scheme-ref>
            </remote-cache-scheme>
         </back-scheme>
         <invalidation-strategy>all</invalidation-strategy>
      </near-scheme>
   </caching-schemes>
</cache-config>

基本ローカル・キャッシュ

ローカル・キャッシュは、特定のアプリケーションに対してローカルである(つまりアプリケーション内に完全に含まれる)キャッシュです。ローカル・キャッシュの特に興味深い属性について、次に示します。

ローカル・キャッシュはリモート・キャッシュと同じインタフェースを実装し、ローカル・キャッシュの使用とリモート・キャッシュの使用にプログラミング上の違いはありません。
ローカル・キャッシュのサイズは制限できます。サイズの制限とは、ローカル・キャッシュでキャッシュするエントリ数を制限し、キャッシュが一杯になったらエントリを自動的に削除できることを意味します。さらに、エントリのサイジングとエビクション・ポリシーの両方をカスタマイズできます。たとえば、キャッシュされたエントリで使用されるメモリーに基づいてキャッシュ・サイズを制限できます。デフォルトのエビクション・ポリシーでは、対数曲線で測定された、最も頻繁に使用する(MFU)情報と最後に使用した(MRU)情報の組合せを使用して削除するキャッシュ項目が決定されます。このアルゴリズムは、短期キャッシュと長期キャッシュの両方に対して十分に機能し、頻度と新しさのバランスをとってキャッシュ・スラッシングを回避するため、最適な汎用エビクション・アルゴリズムであるといえます。また、ピュアLRUアルゴリズムおよびピュアLFUアルゴリズムがサポートされ、カスタム・エビクション・ポリシーのプラグイン機能もサポートされています。
ローカル・キャッシュはキャッシュ・エントリの自動失効をサポートしており、キャッシュ内の各キャッシュ・エントリに存続時間の値を割り当てることができます。さらに、定期的または事前に設定した時刻にフラッシュするようキャッシュ全体を構成できます。
ローカル・キャッシュはスレッド・セーフで、高い並行性を備えています。
ローカル・キャッシュでは、キャッシュのget統計が提供されます。ここには、キャッシュ・ヒットおよびキャッシュ・ミスの統計情報が保持されます。これらの実行時統計は、キャッシュの有効性を正確に推定できるため、キャッシュ実行時にサイズ制限や自動失効の設定を適宜調整できます。

ローカル・キャッシュの構成要素は<local-scheme>です。ローカル・キャッシュは通常、ニアスキームのフロント層としてなど、他のキャッシュ・スキーム内にネストされています。<local-scheme>には、キャッシュの特性を定義できるいくつかのサブ要素がオプションで用意されています。たとえば、<low-units>および<high-units>サブ要素はキャッシュのサイズを制限します。キャッシュが最大許容サイズに達すると、指定されたエビクション・ポリシー(<eviction-policy>)に従って削除対象エントリが決定され、指定されたより小さなサイズに戻ります。エントリおよびサイズの制限は、該当するスキームの単位換算カリキュレータ(<unit-calculator>)で計算される単位で測定されます。

キャッシュの有効期間も制限できます。<expiry-delay>サブ要素は、前回の更新からエントリが期限切れとしてマークされるまでの、キャッシュでエントリが保持される期間を指定します。期限切れのエントリを読み取るには、構成済のキャッシュ・ストア(<cachestore-scheme>)からエントリをリロードすることになります。期限切れになった値は、フラッシュ遅延に基づいてキャッシュから定期的に破棄されます。

<cache-store-scheme>が指定されていない場合、キャッシュされたデータはメモリー内に存在して、キャッシュに対して実行された操作のみが反映されます。使用可能なすべてのサブ要素の詳細は、<local-scheme>を参照してください。

例3-4は、ローカル・キャッシュ構成を示しています。

例3-4 ローカル・キャッシュ構成

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
   xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
   coherence-cache-config.xsd">
  <caching-scheme-mapping>
    <cache-mapping>
      <cache-name>example-local-cache</cache-name>
      <scheme-name>example-local</scheme-name>
    </cache-mapping>
  </caching-scheme-mapping>
  <caching-schemes>
    <local-scheme>
      <scheme-name>example-local</scheme-name>
      <eviction-policy>LRU</eviction-policy>
      <high-units>32000</high-units>
      <low-units>10</low-units>
      <unit-calculator>FIXED</unit-calculator>
      <expiry-delay>10ms</expiry-delay>
      <cachestore-scheme>
        <class-scheme>
          <class-name>ExampleCacheStore</class-name>
        </class-scheme>
      </cachestore-scheme>
      <pre-load>true</pre-load>
    </local-scheme>
  </caching-schemes>
</cache-config>

3.4 プロキシ・サーバーでのストレージの無効化

プロキシ・サービスは、クラスタ内でデータの保存も行うクラスタ・メンバー(キャッシュ・サーバー)で実行されます。これが一般的に推奨されるのは、キャッシュ・サーバーを拡張すると、クラスタのストレージ容量に加え、プロキシの合計帯域幅も増加するためです。しかし、プロキシとストレージ・ノードを2つの異なる階層で実行し、それらを別々に拡張することもできます。ただし、これは一般的に必要なく、さらに慎重な計画も要します。異なる階層で実行するには、明示的にキャッシュ・データを保存しないようにプロキシを構成する必要があります。

注意:

ストレージが有効なプロキシは、ニア・キャッシュのフロント・キャッシュをバイパスし、バック・キャッシュがパーティション・キャッシュである場合は、バック・キャッシュに対して直接動作します。

プロキシ・サーバーでのストレージを無効にするには、クラスタ・メンバーの起動時にcoherence.distributed.localstorage Javaプロパティをfalseに設定します。次に例を示します。

-Dcoherence.distributed.localstorage=false

ストレージは、分散キャッシュの定義の際に、キャッシュ構成ファイルで無効にすることもできます。これには、<local-storage要素をfalseに設定します。詳細は、『Oracle Coherenceでのアプリケーションの開発』の<distributed-scheme要素のリファレンスを参照してください。

...
<distributed-scheme>
   <scheme-name>dist-default</scheme-name>
   <local-storage>false</local-storage>
   <backing-map-scheme>
      <local-scheme/>
   </backing-map-scheme>
   <autostart>true</autostart>
</distributed-scheme>
...

3.5 プロキシ・サーバーの起動

プロキシ・サーバーは、DefaultCacheServerクラスを使用して起動できます。プロキシ・サーバーを起動する手順:

現在のディレクトリをOracle Coherenceのライブラリ・ディレクトリに変更します(Windowsの場合は%COHERENCE_HOME%\lib、UNIXの場合は$COHERENCE_HOME/lib)。
Javaコマンドが実行されるようにパスを構成します。
DefaultCacheServerクラスを実行し、キャッシュ構成ファイルおよびオペレーション構成ファイルの場所を含めます。次に例を示します。
```
java -cp path_to_configuration_files;coherence.jar
   com.tangosol.net.DefaultCacheServer
```