第VIII部 アップグレード可能なCoherenceアプリケーションの構築

Coherenceアプリケーションを正常にアップグレードするには、慎重な検討が必要ですが、これはアプリケーションの初期設計時から始める必要があります。アプリケーションが本番稼働し、開発チームが次のバージョンをデプロイする準備ができてから、これらの検討を始めるのでは遅すぎます。

最も単純なアップグレード・シナリオでは、アプリケーションは単一のCoherenceクラスタで構成され、すべてのクラスタ・メンバーが一緒に停止およびアップグレードされ、永続性やフェデレーションなどのCoherence機能は使用されません。このシナリオでは、アプリケーションを本番にデプロイする前にアプリケーションをビルドおよびテストするだけで済みます。後方互換性の問題を考慮する必要はありません。

アプリケーションのすべての部分を同時に停止およびアップグレードできない場合、より複雑なアップグレード・シナリオになります。アップグレード・プロセスの複雑さは、どのCoherence機能が使用されているか、アプリケーションがダウンタイムなしの更新をサポートする必要があるか、またはアプリケーションの一部が古いバージョンにとどまる必要があるかによっても異なります。

ノート:

これらの考慮事項は、アプリケーションを以前のバージョンにダウングレードする必要がある場合にも適用されます。本番稼働中のアプリケーションに重大な問題が見つかった場合、変更を元に戻し、以前のバージョンにダウングレードすることが唯一の解決策である場合があります。ダウンタイムなしのダウングレードが必要になることもあります。

アップグレード・シナリオ

アプリケーションのアップグレードは、単純な単一デプロイメントから、次のような非常に複雑なシナリオまで多岐にわたります:

• 一部がアップグレードされている間、アプリケーションの実行が継続されるダウンタイムなしのアップグレード。
• Coherence永続性を使用し、古いアプリケーションによって保持されているデータをリロードするアプリケーション。
• Coherenceフェデレーションを使用するアプリケーションで、アップグレードされたクラスタが古いバージョンのアプリケーションを実行しているクラスタにデータをフェデレートするか、新しいバージョンが古いバージョンを実行しているクラスタからフェデレーテッド・データを受信します。
• アプリケーションはCoherenceクラスタを共有する複数の部分で構成され、これらの部分は開発ライフサイクルが異なり、異なるタイミングでアップグレードされます。これらの部分は、他のクラスタ・メンバー、Coherence Extendクライアント、またはCoherence gRPCクライアントとしてデプロイできます。この場合、アプリケーションAPIとアプリケーション・データは、すべての部分間で互換性を維持する必要があります。

ノート:

Coherenceでは、メジャーCoherenceバージョンが異なるクラスタ・メンバーのローリング・アップグレードはサポートされていません。Coherenceのメジャー商用バージョンでは、バージョン番号の最初の4つの部分のいずれかが異なります。たとえば、12.2.1.4.xから14.1.1.0.xにアップグレードしたり、14.1.1.0から14.1.2.0にアップグレードすることはできません。パッチ番号間、つまり14.1.2.0.xから別の14.1.2.0.xバージョンにすることはできます。

Javaはメジャー・リリース間のシリアライズ互換性を保証しないため、Javaメジャー・バージョンが変わるアップグレードもクラスタ・メンバーでサポートされていません。たとえば、Java 17.1から17.2には移行できますが、Java 17からJava 21には移行できません。

第VIIIの構成は次のとおりです。

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