49 アップグレードに関する考慮事項

Coherenceには多くの機能があり、そのいくつかは、アプリケーションを正常にアップグレードできるように正しく実装する必要があります。

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

• アプリケーションの再コンパイル
  アプリケーションがCoherenceバージョンをアップグレードするたびに(マイナー・パッチ更新の場合でも)、新しいCoherenceバージョンに対してアプリケーション・コードを再コンパイルすることをお薦めします。
• シリアライズ
  アプリケーション内の異なるJVM間でネットワーク経由で送信されるすべてのクラスは、デフォルトのCoherenceシリアライズ(Java)またはPOFシリアライズを使用してシリアライズ可能である必要があります。これは、クラスタ・メンバーとCoherenceクライアント・プロセスの両方に適用されます。
• キャッシュ・キーおよび値
  キャッシュ・キーおよび値の変更がシリアライズにどのように影響するかを考慮する必要があります。
• エントリ・プロセッサ
  アプリケーションでカスタム・エントリ・プロセッサを使用する場合は、バージョン間で互換性がある必要があります。これには、POFシリアライズを使用するのが理想的で、シリアライズの進化可能性が含まれます。
• フィルタ
  アプリケーションでカスタム・フィルタ実装を使用する場合は、バージョン間で互換性がある必要があります。これには、POFシリアライズを使用するのが理想的で、シリアライズの進化可能性が含まれます。
• アグリゲータ
  アプリケーションでカスタム・アグリゲータを使用する場合、これらはバージョン間で互換性がある必要があります。これには、POFシリアライズを使用するのが理想的で、シリアライズの進化可能性が含まれます。
• 値エクストラクタ
  アプリケーションでカスタム・エクストラクタを使用する場合、これらはシリアライズ対応である必要があります。フィールドの追加または削除は、進化可能な方法で行う必要があり、理想的にはPOFの進化可能性を使用します。
• ラムダの使用
  Coherence APIでのラムダの使用は、Coherenceアプリケーションの他のクラスと同様に処理する必要があります。通常、Coherence APIメソッド・パラメータとして使用されるラムダは、ラムダがシリアライズされ、サーバーに送信されて実行されることを意味します。
• トピック
  Coherenceトピックは、キャッシュと同様に、シリアライズされたデータをサーバーに格納します。トピックに公開される値に使用されるクラスは、シリアライズ互換性があり、進化可能である必要があります。
• キャッシュ・ローダーおよびキャッシュ・ストア
  キャッシュ・ローダーまたはキャッシュ・ストアを使用して外部データ・ソースにアクセスするアプリケーションは、引き続き外部データ・ソースからデータをロードし、外部データ・ソースに書き込むことができる必要があります。
• Coherenceクライアント
  クライアント・アプリケーション・コード(ExtendとgRPCの両方)は、下位互換と上位互換の機能を持つように記述する必要があります。Coherence自体は、クライアントが様々なバージョン(異なるメジャー・バージョンを含む)でCoherenceクラスタに接続できることを保証しますが、これをサポートするようにアプリケーション・コードを記述する必要があります。
• キャッシュ構成の変更
  アップグレードの一部として、キャッシュ構成ファイルで変更できることがいくつかあります。また、完全なクラスタ停止がないと変更できないものもあります。
• オペレーション構成の変更
  オペレーション構成ファイル(またはオーバーライド・ファイル)で変更できるCoherence構成アイテムは多数あり、その一部はローリング更新で変更でき、一部は変更できません。
• セキュリティおよびSSL/TLS
  Coherenceのセキュリティには、次のような多くの機能があります:
• 永続性
  Coherence永続性を使用するアプリケーションは、キャッシュ・キーおよび値に使用されるクラスがシリアライズ互換性があり、進化可能であることを確認する必要があります。
• フェデレーション
  フェデレーションは、異なるCoherenceクラスタ間でデータをコピーします。フェデレーテッド・キャッシュ・キーおよび値で使用されるクラスは、異なるクラスタ間でデータを正常に送信できるように、バージョン間で進化可能である必要があります。
• エグゼキュータ・サービス
  Coherence同時実行モジュールの一部であるエグゼキュータ・サービスは、Coherenceクラスタ内のタスクをリモートで実行します。これらのタスクはシリアライズされ、実行のために他のクラスタ・メンバーに送信されるため、Coherenceでネットワークを介して送信される他のクラスと同様に進化可能である必要があります。

アプリケーションの再コンパイル

アプリケーションがCoherenceバージョンをアップグレードするたびに(マイナー・パッチ更新の場合でも)、新しいCoherenceバージョンに対してアプリケーション・コードを再コンパイルすることをお薦めします。

アプリケーションの再コンパイルには、完全な継続的インテグレーションのビルドおよびテストの実行も含まれることが理想的です。Coherence APIは、パッチ・リリースに対して下位互換性があることが保証されていますが、バイナリ互換性がない場合があります。つまり、アプリケーションは、Coherenceのマイナー・パッチ・アップグレードの場合、コード変更を必要としませんが、正しく動作するために再コンパイルが必要なことがあります。

アプリケーション開発者は、Coherenceのアップグレード時に必ずリリース・ノートを参照する必要があります。特に、アプリケーション・コードを変更して代替を使用できるように、非推奨を確認する必要があります。非推奨のコードはパッチでは削除されませんが、Coherenceのメジャー・アップグレードで削除される可能性があります。

シリアライズ

アプリケーション内の異なるJVM間でネットワーク経由で送信されるすべてのクラスは、デフォルトのCoherenceシリアライズ(Java)またはPOFシリアライズを使用してシリアライズ可能である必要があります。これは、クラスタ・メンバーとCoherenceクライアント・プロセスの両方に適用されます。

クラスが変更されたアプリケーションの新しいバージョンにアップグレードする場合、クラスの使用方法に応じて考慮するルールが多数あります。詳細は、次の項を参照してください。たとえば、「キャッシュ・キーおよび値」です。

JavaシリアライズはCoherenceで使用されるデフォルトのシリアライザですが、シームレスなアップグレードを必要とするアプリケーションでは、かわりにCoherence POFを使用する必要があります。Javaシリアライズは、多大な労力を伴わなければ下位互換性を確保できず、適切に進化できません。一方、POFは、下位および上位互換性があるように記述でき、プラットフォームに依存せず、完全に進化可能です。

ローリング・アップグレードでキャッシュ・サービスで使用されるシリアライザは変更できません。たとえば、アプリケーションはJavaシリアライズからPOFシリアライズに変更できません。

• クラスの追加または削除
  アップグレード中にクラスを追加または削除する場合は注意してください。
• enumクラス
  アプリケーションでenum型を使用する場合、通常のクラスに適用されるものと同じルールがenumクラスにも適用されます。さらに、いくつかの考慮事項もあります。

クラスの追加または削除

アップグレード中にクラスを追加または削除するときは注意してください。

シリアライズできる新しいクラスが追加され、ネットワーク経由でアプリケーション内の別のJVMに送信される場合は、ローリング・アップグレード中に新しいクラスを持たないJVMにこのクラスが送信されないようにする必要があります。

シリアライズできるクラスを削除し、ネットワーク経由でアプリケーション内の別のJVMに送信する場合は、ローリング・アップグレード中に新しいクラスを持たない新しいバージョンのJVMにこのクラスが送信されないようにする必要があります。

この問題に対する一般的な解決策は、可能であれば2段階でアップグレードすることです:

1. 最初のアップグレードでは、新しいクラスを追加しますが、これらのクラスを使用する機能は追加しません。
2. 2番目のアップグレードで、残りのコードを追加します。

たとえば、記憶域が無効なクラスタ・メンバーまたはExtendクライアントでアプリケーション・コードが実行され、記憶域が有効なメンバーが別々であるアプリケーションでは、最初に記憶域が有効なメンバーをアップグレードします。これは、新しいクラスを現在使用しているアプリケーション・コードがないためです。次にアプリケーション・メンバーをアップグレードします。

enumクラス

アプリケーションでenum型を使用する場合、通常のクラスに適用されるものと同じルールがenumクラスにも適用されます。さらに、いくつかの考慮事項もあります。

一部のコードが列挙値の序数に依存している可能性があり、値の順序が変更されると序数が変更されるため、バージョン間で列挙値の順序は変更しないでください。

たとえば、Day列挙がSUNDAYで始まる場合(次の例を参照):

public enum Day {
    SUNDAY, MONDAY, TUESDAY, WEDNESDAY,
    THURSDAY, FRIDAY, SATURDAY 
}

SUNDAYを(次の例のように)値の末尾に移動すると、破壊的変更となる可能性があります:

public enum Day {
    MONDAY, TUESDAY, WEDNESDAY,
    THURSDAY, FRIDAY, SATURDAY, SUNDAY
}

また、列挙型の既存の値を削除しないでください。古いバージョンのアプリケーションを実行しているCoherenceメンバーからこれらの値の1つを受け取る可能性があるためです。値を削除すると、残りの値の序数も変更されるため、破壊的な変更となります。

列挙に新しい値を追加する場合は注意してください。新しい値は、常に列挙の値リストの最後に追加する必要があります。既存のアプリケーションは新しい列挙値をデシリアライズできないため、アプリケーションが新しい値の使用を開始する前に、すべてのCoherenceメンバーが新しいコードにアップグレードされていることが重要です。

キャッシュ・キーおよび値

キャッシュ・キーおよび値の変更がシリアライズにどのように影響するかを考慮する必要があります。

キー・クラス

シリアライズされた形式が同じで、equalsメソッドとhashCodeメソッドに互換性があるかぎり、キャッシュ・キー・クラスに変更を加えることができます。同じキャッシュ・キー値を表すキー・クラスの新しいバージョンとそのクラスの古いバージョンの両方のインスタンスは、同等のCoherenceバイナリ値にシリアライズされる必要があります。

Portable Object Formatの使用を参照してください

次の場合にフィールドを追加できます:

• 新しいフィールドは一時的です(つまり、キーのシリアライズされたバイナリ表現には含まれません)

• 新しいフィールドは、equalsおよびhashCodeメソッドの一部ではありません。

POFを使用する場合、キー・クラスのPOF識別子は変更できません。つまり、POF構成のtype-id要素に使用される値は、バージョン間で同じである必要があります。POF識別子は、シリアライズされたバイナリ値の一部として格納されるため、変更すると、キー・データのシリアライズされた形式が変更されます。

また、POFを使用している場合は、キー内のフィールドのPOF識別子も変更できません。各フィールドの識別子は、シリアライズされたバイナリ値の一部として格納されるため、変更すると、キー・データのシリアライズされた形式が変更されます。

キーのシリアライズ形式には影響しないため、キー・クラスに対してメソッドを追加または削除できます。

値クラス

キャッシュ値に使用されるクラスは、進化可能になるように記述する必要があります。POFシリアライズを使用して、上方および下方のシリアライズの進化を実現できます。

シリアライズの互換性は、キーおよび値クラス自体にとって重要であるだけでなく、キーおよび値の一時的でないフィールドのタイプも互換性がある必要があります。

エントリ・プロセッサ

アプリケーションでカスタム・エントリ・プロセッサを使用する場合は、バージョン間で互換性がある必要があります。これには、POFシリアライズを使用するのが理想的で、シリアライズの進化可能性が含まれます。

エントリ・プロセッサは、以前のバージョン(またはそのタイプの互換性のあるサブクラス)と同じ結果タイプを返す必要があります。アップグレード中にエントリ・プロセッサが実行される可能性があるため、古いバージョンのアプリケーションのコール元が同じ結果タイプを受け取ることが予想されます。

新しいバージョンのエントリ・プロセッサで新しいフィールドが導入された場合は、processメソッドのコードで、それらのフィールドをnull(またはデシリアライズ時に他のデフォルト・セット)にできる必要があります。古いバージョンのアプリケーションがエントリ・プロセッサを実行した場合、その新しいフィールドを設定できません。そのため、プロセッサが新しいバージョンのクラスを使用して記憶域メンバーで実行された場合、デシリアライズ時にフィールドが欠落します。

古いバージョンが失敗なく実行されるために必須の古いバージョンのフィールドには、エントリ・プロセッサの新しいバージョンでも移入する必要があります。

新しいエントリ・プロセッサ・クラスの導入は、記憶域が有効なすべてのクラスタ・メンバーがアップグレードされるまでプロセッサが実行されないことが保証されている場合にのみ行えます。アプリケーションの新しいバージョンがエントリ・プロセッサの起動を試行し、そのコールが古いバージョンのコードを実行している記憶域メンバーをターゲットとする場合、コール元はClassNotFoundExceptionを根本原因とする例外を受け取ります。

既存のエントリ・プロセッサ・クラスをアプリケーションから削除するのは、アプリケーションのどの部分もそのエントリ・プロセッサを呼び出そうとしないことが保証されている場合にのみ行うようにしてください。

フィルタ

アプリケーションでカスタム・フィルタ実装を使用する場合は、バージョン間で互換性がある必要があります。これには、POFシリアライズを使用するのが理想的で、シリアライズの進化可能性が含まれます。

フィルタは、MapListenerを使用してイベントを登録するために使用できるため、フィルタには、equalsおよびhashCodeの適切な実装が必要です。これらのメソッドが変更され、新しい実装が古い実装と等しくない場合、アプリケーションは正しいイベントを受信しないか、イベントを受信しない可能性があります。

新しいフィルタ実装で新しいフィールドが導入された場合、フィルタ・メソッドはそのフィールドが設定されていないときに実行できる必要があります。古いバージョンのアプリケーションが古いバージョンのフィルタを使用してメソッドを実行する場合、新しいバージョンを実行しているクラスタ・メンバーで実行するためにデシリアライズされると、それらのフィールドは設定されません。新しいバージョンでは、これを許可するか、適切なデフォルト値をそのコンストラクタまたはデシリアライズ時に設定する必要があります。

新しいフィルタ・クラスの導入は、記憶域が有効なすべてのクラスタ・メンバーがアップグレードされるまで、新しいフィルタ・クラスが使用されないことが保証されている場合にのみ行えます。アプリケーションの新しいバージョンがキャッシュ問合せの実行、MapListenerの追加、または新しいフィルタ・クラスに関連するその他の操作を試行した場合、その操作は、まだアップグレードされていないクラスタ・メンバーで実行されると失敗します。

カスタム・フィルタ実装を削除できるのは、アプリケーションの既存のバージョンで、アップグレード中にこれらのフィルタを必要とするメソッドが実行されないことが保証される場合にのみです。

アグリゲータ

アプリケーションでカスタム・アグリゲータを使用する場合、これらはバージョン間で互換性がある必要があります。これには、POFシリアライズを使用するのが理想的で、シリアライズの進化可能性が含まれます。

アグリゲータの新しいバージョンで、以前のバージョンと同じ結果タイプが返される必要もあります。古いバージョンのアプリケーションを実行しているアプリケーション・コードがアグリゲータを起動し、アグリゲータが新しいバージョンを実行している記憶域メンバーで実行される場合、コール元のコードでは、同じ結果タイプ(またはその結果タイプの互換性のあるサブクラス)を受け取ることが期待されます。

アグリゲータの部分的な結果タイプも、バージョン間で互換性を保つ必要があります。アグリゲータは、異なるメンバーからの結果が収集され、単一の結果に削減される削減フェーズを実行するため、削減を実行するメンバーは、異なるバージョンのアグリゲータを実行している記憶域メンバーから部分的な結果を受け取る可能性があります。

アグリゲータ・クラスの新しいバージョンで新しいフィールドが導入される場合、デシリアライズ中にそれらのフィールドが設定されていなくても、アグリゲータは機能する必要があります。あるいは、コンストラクタで、またはデシリアライズ時に適切なデフォルト値を設定する必要があります。アップグレード中にアグリゲータが古いバージョンのアプリケーションから呼び出され、新しいバージョンを実行している記憶域メンバーで実行される場合、デシリアライズ時に新しいフィールドは存在しません。

新しいアグリゲータ・クラスの導入は、記憶域が有効なすべてのクラスタ・メンバーがアップグレードされるまでアグリゲータが実行されないことが保証されている場合にのみ行えます。アプリケーションの新しいバージョンがアグリゲータの起動を試行し、そのコールが古いバージョンのコードを実行している記憶域メンバーをターゲットとする場合、コール元はClassNotFoundExceptionを根本原因とする例外を受け取ります。

カスタム・アグリゲータ実装を削除できるのは、アプリケーションの既存のバージョンで、アップグレード中にこれらのアグリゲータを必要とするメソッドが実行されないことが保証されたる場合のみです。

値エクストラクタ

アプリケーションでカスタム・エクストラクタを使用する場合、これらはシリアライズ対応である必要があります。フィールドの追加または削除は、進化可能な方法で行う必要があり、理想的にはPOFの進化可能性を使用します。

コール元アプリケーションに返される型を抽出するために使用されるエクストラクタは、以前のバージョンと同じ型を返す必要があります。

値エクストラクタは、Coherenceで索引を定義するために使用されます。特定の索引は、値エクストラクタによってキー設定されたマップから識別されます。値エクストラクタの実装が変更され、以前のバージョンと正確には等しくない場合、索引が使用されないか、間違った索引が使用される可能性があります。

新しい値エクストラクタ・クラスの導入は、記憶域が有効なすべてのクラスタ・メンバーがアップグレードされるまで、値エクストラクタが実行されないことが保証されている場合にのみ行えます。アプリケーションの新しいバージョンが値エクストラクタの起動を試行し、そのコールが古いバージョンのコードを実行している記憶域メンバーをターゲットとする場合、コール元はClassNotFoundExceptionを根本原因とする例外を受け取ります。

カスタム値エクストラクタ実装を削除できるのは、アプリケーションの既存のバージョンで、アップグレード中にこれらの値エクストラクタを必要とするメソッドが実行されないことが保証される場合のみです。

ラムダの使用

Coherence APIでのラムダの使用は、Coherenceアプリケーションの他のクラスと同様に処理する必要があります。通常、Coherence APIメソッド・パラメータとして使用されるラムダは、ラムダがシリアライズされ、サーバーに送信されて実行されることを意味します。

Coherenceでは、動的ラムダと静的ラムダの2つの方法でラムダを使用します。動的ラムダの場合、ラムダ状態とコードの両方がシリアライズされ、実行されるサーバーに送信されます。静的ラムダの場合、状態のみがシリアライズされ、ラムダ・コードがサーバーにすでに存在している必要があります。

ローリング・アップグレードを完全にサポートするには、動的ラムダを使用する必要があります。ラムダ式を使用したエントリの処理を参照してください。

トピック

Coherenceトピックは、キャッシュと同様に、シリアライズされたデータをサーバーに格納します。トピックに公開される値に使用されるクラスは、シリアライズ互換性があり、進化可能である必要があります。

ローリング・アップグレード中、トピックは公開された要素を失うことなく機能し続けます。アップグレードにトピック・サブスクライバを含むアプリケーションJVMのアップグレードが含まれる場合、古いアプリケーション・メンバーが停止されると、コミットされていない要素が新しいサブスクライバに再送されます。Coherenceでは、少なくとも1回の配信が保証されるため、メッセージを処理するアプリケーション・コードは、メッセージが複数回受信されることを考慮して常に冪等になるように作成する必要があります。Portable Object Formatの使用を参照してください

キャッシュ・ローダーおよびキャッシュ・ストア

キャッシュ・ローダーまたはキャッシュ・ストアを使用して外部データ・ソースにアクセスするアプリケーションは、引き続き外部データ・ソースからデータをロードし、外部データ・ソースに書き込むことができる必要があります。

進化可能なデータベース・スキーマの作成は、このドキュメントの範囲をはるかに超えていますが、アプリケーション・アップグレードの一部としてデータベース・スキーマが更新された場合、古いバージョンのコードを実行しているクラスタ・メンバーが、新しいデータベース・スキーマの読取りまたは書込みを試行する場合があります。

キャッシュ・ストアはアプリケーション・コードであり、データベースのみでなく、あらゆるものと対話できるため、キャッシュ・ストアで使用される外部データ・ソースに対する変更は、下位および上位互換性がある必要があります。

Coherenceクライアント

クライアント・アプリケーション・コード(ExtendとgRPCの両方)は、下位互換と上位互換の機能を持つように記述する必要があります。Coherence自体は、クライアントが様々なバージョン(異なるメジャー・バージョンを含む)でCoherenceクラスタに接続できることを保証しますが、これをサポートするようにアプリケーション・コードを記述する必要があります。

クライアント・アプリケーション・コードは、ローリング・アップグレード中に発生する切断に耐えられるように記述する必要もあります。Coherenceは、ローリング・アップグレード中に次のリクエストでクライアントを自動的に再接続しますが、クライアントの切断時に処理中だったリクエストは、クライアントで例外をスローする可能性があります。処理中のリクエストは実際にはサーバー上で完了している可能性があるため、失敗したリクエストを再試行するアプリケーションは、これらのリクエストが冪等であること、つまり、安全に複数回再試行できることを確認する必要があります。たとえば、プロキシの強制終了時に記憶域メンバーで進行中のクライアントからのputリクエストによって、クライアントで例外がスローされる場合がありますが、記憶域メンバーではputは成功します。クライアントがputを再試行すると、putは2回実行されます。これは問題ありませんが、putの副次的作用は2回発生します。たとえば、イベントに基づいて他の処理を実行するアプリケーションは、そのエントリに対して2つのイベントを受信します。

キャッシュ構成の変更

アップグレードの一部として、キャッシュ構成ファイルで変更できることがいくつかあります。また、完全なクラスタ停止がないと変更できないものもあります。

考慮すべき例をいくつかあげます:

• キャッシュの追加 - アプリケーションの新しいバージョンでは、新しいキャッシュの作成が必要になる場合があります。古いバージョンのキャッシュ構成ファイルに新しいキャッシュのマッピングがない場合、アップグレードが失敗する可能性があります。

• キャッシュの削除 - キャッシュ・マッピングが削除されると、新しいバージョンの構成を使用するクラスタ・メンバーが、古いバージョンのアプリケーションを実行しているメンバーからキャッシュcreateリクエストを受信したときに、例外が発生する可能性があります。

• キャッシュ・タイプの変更 - ローリング・アップグレードでキャッシュのタイプを変更できるとはかぎりません。たとえば、レガシー・レプリケート・キャッシュから分散キャッシュに変更することはできません。一部のキャッシュ・タイプは変更できます。たとえば、新しいバージョンのアプリケーションでニア・キャッシュを使用するように変更できます。これは、新しいJVMに対してローカルであるためです。

キャッシュの追加

新しいキャッシュがキャッシュ構成ファイルに追加され、そのキャッシュ・マッピングがアプリケーションの新しいバージョンの完全に新しいスキームおよびサービス名にマップされる場合、これはローリング・アップグレードで機能します。新しい構成を持つクラスタ・メンバーのみが新しいサービスを開始し、新しいキャッシュを保持します。既存のメンバーは、新しいキャッシュのリクエストを受信しません。

問題は、新しいキャッシュがアプリケーションに追加され、既存のサービスにマップされた場合に発生します。アプリケーション・コードが新しいキャッシュをリクエストすると、そのキャッシュを作成するリクエストは、同じキャッシュ・サービスを実行しているすべてのメンバーに送信されます。これには、古いバージョンを実行しているメンバーが含まれますが、そのキャッシュに対するマッピングがないため、例外がスローされます。

キャッシュの追加や削除を容易にするには、キャッシュ構成ファイルで固定キャッシュ名のかわりにワイルドカード名を使用します。

例49-1では、キャッシュ構成ファイルには柔軟性がなく、アップグレードが困難なマッピングがあります。fooとbarの2つのキャッシュ名のみがサポートされます。記憶域が有効なメンバーがこの構成を使用しており、アプリケーションが別のキャッシュを追加する必要がある場合、アップグレードは機能しません。

例49-1 固定マッピングを含むキャッシュ構成ファイル

<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>foo</cache-name>
      <scheme-name>storage</scheme-name>
    </cache-mapping>

    <cache-mapping>
      <cache-name>bar</cache-name>
      <scheme-name>storage</scheme-name>
    </cache-mapping>
</caching-scheme-mapping>

例49-2では、キャッシュ構成ファイルでワイルドカード・マッピングが使用されています。これには、ワイルドカード文字*を使用してキャッシュ名をstorage-schemeという名前のスキームにマップする単一のマッピングがあります。この構成の記憶域が有効なメンバーは、任意のキャッシュ名をサポートします。

例49-2 ワイルドカード・マッピングを使用したキャッシュ構成ファイル

<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>*</cache-name>
      <scheme-name>storage-scheme</scheme-name>
    </cache-mapping>
</caching-scheme-mapping>

ただし、異なる構成を持つ異なるスキームにキャッシュをマップする必要があるアプリケーションでは、単一のワイルドカード・マッピングでは不十分です。この場合、アプリケーションは接頭辞付きのワイルドカード・マッピングを使用する必要があります。

例49-3では、キャッシュ構成ファイルにはfoo-*とbar-*の2つのマッピングがあります。つまり、foo-で始まるキャッシュ名(foo-、foo-1、foo-abcなど)は、foo-storageスキームにマップされます。同じことが、bar-という接頭辞が付いたキャッシュ名にも適用されます。アプリケーションの新しいバージョンで、既存のマッピング名のいずれかに一致する新しいキャッシュ名が導入されているかぎり、アップグレードは機能します。

例49-3 接頭辞付きのワイルドカード・マッピングを使用するキャッシュ構成ファイル

<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>foo-*</cache-name>
      <scheme-name>foo-storage</scheme-name>
    </cache-mapping>

    <cache-mapping>
      <cache-name>bar-*</cache-name>
      <scheme-name>foo-storage</scheme-name>
    </cache-mapping>
</caching-scheme-mapping>

キャッシュの削除

アップグレード中にキャッシュをキャッシュ構成から簡単に削除することはできません。

アップグレード・プロセス中に、新しいメンバー上のキャッシュ・サービスがクラスタに参加すると、既存のクラスタの上位メンバー上のそのサービスに存在するすべてのキャッシュ名のキャッシュ作成メッセージが受信されます。新しいメンバー・キャッシュ構成にマッピングがないキャッシュ名がこれに含まれている場合、例外が発生します。

キャッシュをキャッシュ構成ファイルから削除する場合は、アップグレードを開始する前に、そのキャッシュが既存のクラスタ・メンバーで破棄されている必要があります。キャッシュを破棄する唯一の方法は、アプリケーション・コードにあります。古いクラスタ・メンバー上のキャッシュを破棄しても、既存のアプリケーションが失敗しないようにする必要があることは明らかです。アプリケーションのそのバージョンをそのキャッシュなしで実行でき、破棄後にキャッシュを再作成しようとするコードを持たないようにする必要があります。

キャッシュ・タイプの変更

アップグレード中に、基本となるキャッシュのタイプを変更することはできません。たとえば、レプリケート・キャッシュは非推奨ですが、クラスタを完全に停止することなく、レプリケート・キャッシュから分散キャッシュにキャッシュを変更することはできません。

アップグレードでは、キャッシュ・タイプに対する次の変更が許可されます:

• NearCache - Coherence JVMのローカル構成であるため、キャッシュをニア・キャッシュから変更したり、ニア・キャッシュに変更できます。

• ViewScheme - これは分散キャッシュ上のローカル・ビューであるため、ビュー・スキームから、またはビュー・スキームに変更できます。

• ReadWriteBackingMap - キャッシュのバッキング・マップを読取り/書込みバッキング・マップから、または読取り/書込みバッキング・マップに変更できますが、注意が必要です。新しいバージョンでキャッシュ・ストアを使用する場合、アップグレード中に新しいメンバーに送信されたデータのみが外部データ・ソースに書き込まれ、既存のメンバーで発生するデータ変更は書き込まれません。

• バッキング・マップ・タイプの変更 - アップグレードでバッキング・マップ構成のタイプを変更できます。たとえば、ローカル・スキームからCaffeineまたはエラスティック・データに、またはその逆に変更できます。バッキング・マップは、個々のクラスタ・メンバーがキャッシュ・データを格納する方法を構成するため、アップグレード中に他のメンバーとの互換性の問題は発生しません。

• バッキング・マップ構成 - そのJVMにのみローカルのバッキング・マップ構成の変更も可能です。たとえば、高または低の単位、単位計算機、失効遅延などの変更があります。

オペレーション構成の変更

オペレーション構成ファイル(またはオーバーライド・ファイル)で変更できるCoherence構成アイテムは多数あり、その一部はローリング更新で変更でき、一部は変更できません。

セキュリティおよびSSL/TLS

Coherenceのセキュリティには、次のような多くの機能があります:

• クラスタ・メンバーのSSL/TLSの変更

• ExtendおよびgRPCクライアントのSSL/TLSの変更

• アイデンティティ・アサーション

• 記憶域アクセス認可

Oracle Coherenceの保護のOracle Coherenceセキュリティの概要に関する項を参照してください。

クラスタ・メンバーのSSL/TLSの変更

CoherenceのSSL/TLS構成に対する変更は、アップグレード時に既存のクラスタ・メンバーおよびクライアントと互換性がある必要があります。

ローリング・アップグレードでは、クラスタ通信を非SSL/TLSからSSL/TLS(またはその逆)に変更することはできません。新しいメンバーは、既存のメンバーとクラスタを形成できなくなります。

一方向認証から双方向認証への変更は、既存のメンバーが新しいメンバーに有効な証明書を提供できる場合にのみ可能です。

ホスト名検証の変更は、アップグレード中に既存のメンバーが引き続き検証される場合にのみ実行できます。

Oracle Coherenceの保護のSSLを使用したTCMP通信の保護を参照してください。

ExtendおよびgRPCクライアントのSSL/TLSの変更

クラスタ・メンバーシップと同様に、ExtendまたはgRPCプロキシのSSL/TLS構成の変更は、既存のクライアントが引き続き新しいプロキシに接続できるように行う必要があります。既存のクライアントが新規プロキシに接続できないため、プロキシを非SSL/TLSからSSL/TLS(またはその逆)に変更することはできません。1つの解決策として、変更された構成を実行する新しいプロキシを導入し、既存のプロキシ構成を残して、各Coherenceサーバーが2つのプロキシ(1つのSSL/TLSと1つの非SSL/TLS)を実行するようにします。既存のクライアントと新しいクライアントは、関連するプロキシに接続できます。アップグレード後に、古いプロキシ構成を削除する別のアップグレードを行うことができます。

または、アップグレード中にクライアントを停止できる場合は、プロキシのSSL/TLS構成を変更しても問題はありません。

ExtendまたはgRPCクライアントでのSSL/TLSの変更では、新しいクライアントが既存のプロキシに引き続き接続できるようにするか、またはアップグレード中に新しいプロキシにのみ接続するように新しいクライアントが構成されるようにする必要があります。Oracle Coherenceの保護のSSLを使用したExtendクライアント通信の保護に関する項を参照してください。

アイデンティティ・アサーション

Coherence Extendは、接続時にサーバー上で検証されるトークンをクライアントから渡すメカニズムとしてアイデンティティ・アサーションを使用するように構成できます。クライアントまたはプロキシでアイデンティティ・アサーション・コードを変更する場合は、古いクライアントが引き続き新しいプロキシに接続でき、新しいクライアントが古いプロキシに接続できるように、互換性を維持した方法で行う必要があります。

クライアントによって送信されるトークンは、クライアント上でシリアライズされ、サーバー上でデシリアライズされます。使用される更新されたトークン・クラスは、シリアライズ互換性があり、既存のクラスタ・メンバーで認識される必要があります。

アイデンティティ・アサーションの使用は、サーバー側のプロキシ・サーバーを最初にアップグレードして削除される場合にかぎり、アップグレードで削除できます。

または、アップグレード中にクライアントを停止できる場合、プロキシのアイデンティティ・アサーション構成およびコードを変更しても問題はありません。Oracle Coherenceの保護のExtendクライアント接続の保護に関する項を参照してください。

記憶域アクセス認可

記憶域アクセス認可機能を使用して、記憶域が有効なクラスタ・メンバーのキャッシュに対する操作を認可する場合は、すべての変更に互換性がある必要があります。『Oracle Coherenceの保護』のサーバー側操作へのアクセスの認可に関する項 を参照してください。

永続性

Coherence永続性を使用するアプリケーションは、キャッシュ・キーおよび値に使用されるクラスがシリアライズ互換性があり、進化可能であることを確認する必要があります。

クラスタ・メンバーが別のバージョンのアプリケーションによって格納されている永続性ファイルの読取りを試行した場合、データに互換性がない場合、これは失敗する可能性があります。シリアライズされたバイナリ・データがファイルから読み取られ、シリアライズされたバイナリ形式でキャッシュにロードされるため、実際の問題はすぐに目に見える形で現れないことがありますが、アプリケーションが後でそのデータをデシリアライズしようとすると失敗します。

詳細については、以下を参照:

• Portable Object Formatの使用

• Oracle Coherenceの管理の永続キャッシュに関する項

特に、ローリング・アップグレードを実行する場合は、次の領域を考慮してください:

Javaのバージョン

異なるCoherenceバージョンのサーバーを同じクラスタで実行する場合は、アップグレードの前後で同じメジャーJavaバージョンを使用する必要があります。

シリアライズ形式

Javaシリアライズ互換性の一般的なルールは、永続性にも適用されます。「シリアライズ」を参照してください。

Coherence POFシリアライズを使用し、キャッシュ・データ・クラス(キー、値またはその両方)に変更がある場合は、IEvolvablePortableObjectインタフェースの実装を通じてシリアライズの互換性を維持できます。Oracle Coherenceリモート・クライアントの開発の進化可能な移植性のあるユーザー定義型に関する項を参照してください。

たとえば、JavaからPOFにシリアライズ形式が変更された場合、以前に作成したスナップショットまたはアーカイブはロードできません。

永続性の場所の変更

永続性の場所を変更する場合は、サーバーを停止し、すべての永続性ディレクトリを新しい場所に移動またはコピーする必要があります。次に、サーバーを起動する前に、サーバーをアップグレードし、新しい場所を使用するように永続性構成を更新します。変更可能な永続性の場所は次のとおりです:

• <active-directory>
• <event-directory>
• <snapshot-directory>
• <trash-directory>

たとえば、oldEnvironmentをnewEnvironmentに変更する場合、アップグレードしたサーバーを起動する前に、ディレクトリ/oldEnvの内容を/newEnvにコピーまたは移動する必要があります。次に、それに応じて永続性構成を更新します。

例49-4に、永続性の場所が/oldEnvに設定されたままである永続性構成を示します。

例49-4 oldEnvironmentの永続性の場所

<persistence-environments>
   <persistence-environment id="oldEnviornment">
      <persistence-mode>on-demand</persistence-mode>
      <active-directory>/oldEnv</active-directory>
      <snapshot-directory>/oldEnv</snapshot-directory>
      <trash-directory>/oldEnv</trash-directory>
   </persistence-environment>
</persistence-environments>

例49-5では、新しい永続性の場所/newEnvを反映するように永続性構成が更新されています。

例49-5 newEnvironmentの永続性の場所

<persistence-environments>
   <persistence-environment id="newEnviornment">
      <persistence-mode>on-demand</persistence-mode>
      <active-directory>/newEnv</active-directory>
      <snapshot-directory>/newEnv</snapshot-directory>
      <trash-directory>/newEnv</trash-directory>
   </persistence-environment>
</persistence-environments>

Oracle Coherenceの管理の永続性環境の作成に関する項を参照してください。

ローリング・アップグレードの分散キャッシュ構成変更ルールは、永続性にも適用されます。「キャッシュ構成の変更」を参照してください。

フェデレーション

フェデレーションは、異なるCoherenceクラスタ間でデータをコピーします。フェデレーテッド・キャッシュ・キーおよび値で使用されるクラスは、異なるクラスタ間でデータを正常に送信できるように、バージョン間で進化可能である必要があります。

Coherenceでのフェデレーションの使用に関する一般情報は、Oracle Coherenceの管理のクラスタ間のキャッシュのフェデレートに関する項を参照してください。

JDKのアップグレード、ラムダ、シリアライズ互換性など、アップグレードに関する一般的な考慮事項に加えて、フェデレーションに固有の側面も考慮する必要があります。

ローリング更新を使用したフェデレーテッド・クラスタのアップグレード

ローリング更新が可能な場合は、フェデレーテッド・クラスタはローリング・ベースでのアップグレードも可能です。アップグレードの実行に関するガイダンスは、「ローリング再起動の実行」を参照してください。フェデレーションには複数のCoherenceクラスタが含まれるため、すべてのクラスタがアップグレードされるまで、クラスタを一度に1つずつアップグレードする必要があります。

ローリング更新を実行できない場合のフェデレーテッド・クラスタのアップグレード

ローリング更新を実行できない場合は、古いクラスタを停止し、アップグレードで新しいクラスタを作成する必要があります。その後、フェデレーションのreplicateAll()操作を使用して、既存のクラスタからアップグレードされたクラスタにデータをレプリケートできます。Oracle CoherenceのマネージメントのFederationManager MBeanに関する項を参照してください。

replicateAllの前提条件は次のとおりです:

• シリアライズ形式: シリアライズ形式が変更されておらず、アップグレード間で互換性があることを確認します。「シリアライズ」を参照してください。

• パーティション数の変更: フェデレーションはパーティションごとに変更を追跡し、パーティションがあるクラスタ・メンバーから別のクラスタ・メンバーに移行したときに失われていた可能性のある変更を再送信できます。パーティション数が異なる2つのクラスタ間のフェデレーションは可能ですが、この場合、一部の追跡が無効になります。

  フェデレーテッド・クラスタでパーティション数を変更する場合は、replicateAll()を使用して再起動されたクラスタに再移入しますが、その後、手動のステップを実行して、すべてのキャッシュ・データがアップグレードされたクラスタにフェデレートされたことを確認します。たとえば、replicateAll()の完了後にキャッシュ・サイズを確認します。

  『Oracle Coherenceの管理』で、永続的なサービスのパーティション数を変更して移行する際の回避策に関する項を参照してください。

分散スキームからフェデレーテッド・スキームへの移行

Coherence永続性を使用すると、分散キャッシュ・サービスをフェデレーテッド・キャッシュ・サービスに簡単に移行できます。Oracle Coherenceの管理のフェデレーションの使用に関する項を参照してください。

エグゼキュータ・サービス

Coherence同時実行モジュールの一部であるエグゼキュータ・サービスは、Coherenceクラスタ内のタスクをリモートで実行します。これらのタスクはシリアライズされ、実行のために他のクラスタ・メンバーに送信されるため、Coherenceでネットワークを介して送信される他のクラスと同様に進化可能である必要があります。

詳細は、「エグゼキュータの使用」を参照してください。