拡張プロキシの構成

3 拡張プロキシの構成

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

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

拡張プロキシの構成の概要
Extendクライアントがデータを検索してクラスタに格納するには、プロキシおよびキャッシュが構成されている必要があります。
拡張プロキシ・サービスの定義
拡張プロキシ・サービス(ProxyService)は、ExtendクライアントからTCP/IPを使用してCoherenceクラスタにアクセスできるクラスタ・サービスです。
Extendクライアントで使用するキャッシュの定義
Extendクライアントは、クラスタ上のキャッシュに対してデータを読み書きします。クライアント・データは、どのようなキャッシュ・タイプでも格納できます。
プロキシ・サーバーでのストレージの無効化
データを保存しないようにプロキシ・サービスを明示的に構成する必要があります。
プロキシ・サーバーの起動
プロキシ・サーバーは、DefaultCacheServerクラスを使用して起動できます。

親トピック: はじめに

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

拡張プロキシは、1つ以上のプロキシ・サービスをホストするCoherenceクラスタのメンバーです。プロキシ・サービスは、Extendクライアントがクラスタ内のキャッシュにアクセスするために使用する、基本となるクラスタ・サービスです。Extendクライアントがデータを検索してクラスタに格納するには、プロキシおよびキャッシュが構成されている必要があります。

拡張プロキシおよびキャッシュ・サーバーは、同じクラスタのメンバー・プロセス(DefaultCacheServerプロセス)で実行されます。拡張プロキシとキャッシュ・サーバーを同じ場所に配置すると、クラスタの設定が簡単になり、プロキシがクラスタにあわせて自動的にスケーリングされます。ただし、拡張プロキシはクラスタの個別のメンバーとして構成することもできます。この場合、プロキシとキャッシュ・サーバーは、独立してスケーリングできる個別の層として構成されます。

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

親トピック: 拡張プロキシの構成

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

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

この項には次のトピックが含まれます:

親トピック: 拡張プロキシの構成

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

拡張プロキシ・サービスは、<caching-schemes>ノード内で、<proxy-scheme>要素を使用して構成します。例3-1では、ExtendTcpProxyServiceという名前のプロキシ・サービスを定義し、クラスタ・ノードでサービスが自動的に開始されるように、trueに設定されている<autostart>要素が含まれます。『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>
...

親トピック: 拡張プロキシ・サービスの定義

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

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

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

次の例では、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>
...

親トピック: 拡張プロキシ・サービスの定義

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

複数の拡張プロキシ・サービスを定義することにより、それぞれのプロキシで異なるアプリケーションを提供できます。より予測性の高い環境を構築するために、特定のアプリケーションの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>
...

親トピック: 拡張プロキシ・サービスの定義

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

ネーム・サービスに対応していない古い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>
      <address-provider>
         <local-address>
            <address>192.168.1.5</address>
            <port>7077</port>
            <port-auto-adjust>8000</port-auto-adjust>
         </local-address>
      </address-provider>
   </tcp-acceptor>
</acceptor-config>

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

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

親トピック: 拡張プロキシ・サービスの定義

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

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

クラスタ・サービス・プロキシは、それぞれ<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>

親トピック: 拡張プロキシ・サービスの定義

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>

親トピック: 拡張プロキシ・サービスの定義

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>

親トピック: 拡張プロキシの構成

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

データを保存しないようにプロキシ・サービスを明示的に構成する必要があります。

プロキシとストレージ・ノードを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>
...

親トピック: 拡張プロキシの構成

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

プロキシ・サーバーは、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
```

親トピック: 拡張プロキシの構成