WebSphere アプリケーションを Azure Kubernetes Service (AKS) に移行する

  • [アーティクル]

このガイドでは、既存の WebSphere Application Server (WAS) ワークロードを Azure Kubernetes Service (AKS) 上の IBM WebSphere Liberty または Open Liberty に移行するときの注意事項について説明します。

移行前

移行を確実に成功させるには、開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。

ターゲットが移行作業に適したターゲットであることを確認する

WAS アプリケーションを Azure に正常に移行する最初の手順は、最も適切な移行ターゲットを選択することです。

WAS traditional は、Azure Virtual Machines で適切に実行されます。 仮想マシン (VM) ターゲットは、オンプレミスのデプロイに最も近いため、最も簡単な選択です。 仮想マシンの管理とデプロイのエクスペリエンスは、オンプレミスにあるものと類似します。

もう 1 つのオプションは、WAS traditional ワークロードをアプリケーション コンテナーに変換してコンテナーに移行することです。 コンテナー ターゲットは、Azure Kubernetes Service (AKS) と Azure Red Hat OpenShift で実行できます。 この容易さのトレードオフは、経済的コストです。

一般に、VM ベースのソリューションの 1 分あたりのコストは、コンテナーと比較して高くなります。 コンテナーベースのソリューションの実行コストは低くなりますが、コンテナー オーケストレーション プラットフォームの要件に合わせてアプリケーションを制限する必要があります。

変更を最小限に抑えることが移行作業の最も重要な要素である場合は、VM ベースの移行を検討してください。 この場合は、 「WebSphere のアプリケーションを Azure Virtual Machines に移行する」を参照してください。

ランタイム コストを削減するために、アプリケーションをコンテナー内で実行するように変換することが許容できる場合、AKS ベースまたは Azure Red Hat OpenShift ベースの移行を検討します。

AKS ベースの移行では、Free 階層を使用できます。 無料のクラスター管理を取得して、仮想マシン、関連ストレージ、消費したネットワーク リソースに対してのみ料金を支払います。 この場合は、 「WebSphere applications を Azure Kubernetes Service に移行する」を参照してください。

Azure Red Hat OpenShift ベースの移行の場合、コンピューティングとインフラストラクチャのコストに加えて、アプリケーション ノードにはOpenShift ライセンス コンポーネントの別のコストがあります。 このコストは、アプリケーション ノード数とインスタンスの種類に基づいて課金されます。 ワークロードやビジネスのニーズに合わせて、オンデマンドの価格または予約インスタンスのいずれかを使用できます。 この場合は、 「WebSphere アプリケーションを Azure Red Hat OpenShift に移行する」を参照してください。

Azure Red Hat OpenShift ドキュメントの攻略ガイドでは、移行に関連するいくつかの側面について説明しています。 攻略ガイドの完全な一覧については、 「Azure Red Hat OpenShift ドキュメント」を参照してください。

事前構築済みの Azure Marketplace オファーが適切な出発点であるかどうか判断する

AKS が適切なデプロイ ターゲットであると判断したら、IBM WebSphere Liberty Operator または Open Liberty Operator (オペレーター) が、Kubernetes で Liberty を実行できる唯一の方法として許容します。 この事実を受け入れた後、事前構築済みの Azure Marketplace オファー が適切な出発点であるかどうかを判断する必要があります。 事前構築済みの Azure Marketplace オファーについて考慮すべき点を次に示します。

  • IBM と Microsoft は、AKS で Liberty をすばやくプロビジョニングできるように、このオファーを作成しました。 このコンセプトについては、次のコンテンツで詳述します。
  • 大まかに言えば、オファーによって次の手順が自動化されます。
    • 必要に応じて、既存のアプリケーション イメージを取得します。
    • 必要に応じて、AKS クラスターと Azure Container Registry (ACR) インスタンスをプロビジョニングします。
    • AKS に IBM WebSphere Liberty Operator または Open Liberty Operator をインストールして構成します。
    • 演算子を使用して全体を実行します。 オペレーターは、AKS でコンテナ化された Liberty アプリケーションをデプロイおよび管理します。 リファレンス ドキュメントは、 「IBM WebSphere Liberty Operator」 または 「Open Liberty Operator」を参照してください。

事前構築済みの Azure Marketplace オファーを使用しない場合は、演算子を直接使用する方法を学習する必要があります。 演算子の習得については、この記事の範囲外です。 オペレーターの完全なドキュメントは、 「IBM WebSphere Liberty Operator」 および 「Open Liberty Operator」で入手できます。

AKS で Liberty を処理するさまざまな方法を紹介しました。事前構築済みの Azure Marketplace オファーを使用するか、演算子を直接使用して自分で行うかを選択できるようになりました。

Liberty バージョンに互換性があるかどうか確認する

Kubernetes ベースのクラスターにアプリケーションをデプロイして管理するには、 Open Liberty Operator または WebSphere Liberty Operator が必要です。 既存の Liberty バージョンが、オペレーターによってサポートされているバージョンの 1 つであることを確認してください。 Open Liberty のバージョンは、GitHub OpenLiberty/open-liberty で維持されています。 IBM は、IBM WebSphere Application Server Liberty のバージョンを維持しています。 詳細については、 「WebSphere Application Server Liberty」を参照してください。

事前構築済みの Azure Marketplace オファーを使用すると、パブリック レジストリからアプリケーション イメージを選択できるため、すべてのバージョンが暗黙的にサポートされます。

ライセンスが必要かどうかを判断する

IBM WebSphere Liberty の場合は、アプリケーション・コンテナー内の IBM プログラムのバージョンに対応する使用許諾契約書の条項に同意する必要があります。 この IBM プログラムに適用される使用許諾契約書については、 「WebSphere Liberty Operator のライセンス情報の表示」を参照してください。 詳細については、 「Microsoft Azure で WebSphere Liberty を実行する」を参照してください。

製品エディションが、デフォルトの IBM WebSphere Application Server (ベース) 以外の場合、 .spec.license.edition value は、製品エディションを指定します。 その他の使用可能な値は、IBM WebSphere Application Server Liberty Core と IBM WebSphere Application Server Network Deployment です。 事前構築済みの Azure Marketplace オファーを使用すると、サポートされている製品エディションを選択できます。

IBM 移行ツールを使用したインベントリの相違点

アプリケーションを WebSphere Application Server Liberty または Open Liberty に移行するには、移行を計画し、アプリケーションを分析し、ソース コードを更新する必要があります。 IBM には、Java EE 7 または Java EE 8、および Java SE 8 または Java SE 11 などの新しい Liberty 環境に現在の環境とテクノロジ間の相違点を特定する移行ツールがあります。 詳細については、 「アプリケーションを Liberty に移行する」を参照してください。

サーバー容量をインベントリする

現在の実稼働サーバーのハードウェア (メモリ、CPU、ディスク) と、平均およびピーク時の要求数とリソース使用率を文書化します。 この情報は、選択した移行パスに関係なく必要になります。 たとえば、ノード プール内の VM のサイズ、コンテナーによって使用されるメモリの量、コンテナーが必要とする CPU 共有の数などの選択に役立ちます。

AKS でノード プールのサイズを変更できます。 方法については、「Azure Kubernetes Service (AKS) でノード プールのサイズを変更する」を参照してください。

すべてのシークレットをインベントリする

Azure Key Vault などの "サービスとしての構成" テクノロジが登場する前に、"シークレット" の明確に定義された概念はありませんでした。 代わりに、現在 "シークレット" を呼ばれるものとして効果的に機能する、さまざまな種類の構成設定のセットがありました。 WAS などのアプリ サーバーでは、これらのシークレットは多くの異なる構成ファイルと構成ストアにあります。 すべてのシークレットとパスワードについて、実稼働サーバー上のすべてのプロパティと構成ファイルを確認します。 また、パスワードや資格情報を含む構成ファイルがアプリケーション内に見つかる場合もあります。 WAS は、構成データを複数のドキュメントのカスケード階層のディレクトリに格納します。 ほとんどの構成ドキュメントには XML コンテンツがあります。 詳細については、 「構成ドキュメント」 および 「Azure Key Vault の基本概念」を参照してください 。

シークレットの強固なインベントリを作成後、シークレットに関するオペレーターのドキュメントを参照してください。 詳細については、次の記事をご覧ください。

すべての証明書をインベントリする

パブリック SSL エンドポイントで使用されるすべての証明書を文書化します。 次のコマンドを実行して、運用サーバー上のすべての証明書を表示できます。

keytool -list -v -keystore <path to keystore>

認定資格証の信頼できるインベントリを作成したら、次の記事を使用して認定資格証を構成します。

サポートされている Java バージョンが正しく動作することを検証する

Liberty を使用するには、Java のバージョンが指定されているので、そのサポートされているバージョンを使用してアプリケーションが正しく実行されているかを確認する必要があります。

WebSphere Application Server Liberty のランタイムには、Java Runtime Environment (JRE) の最低レベルの固有要件があります。 詳細については、 「機能に対する Java バージョンの依存関係」を参照してください。

Open Liberty には Java Standard Edition ランタイムが必要です。 Java Runtime Environment (JRE) または Java SE Development Kit (JDK) ディストリビューションを使用して実行できます。 詳細については、 「サポートされている Java Standard Edition リリース」を参照してください。

JNDI リソースをインベントリする

すべての JNDI リソースをインベントリします。 たとえば、データベースなどのデータソースには、関連付けられている JNDI 名が存在することがあります。これによって、JPA が特定のデータベースに EntityManager のインスタンスを正しくバインドできます。 JNDI リソースとデータベースの詳細については、IBM ドキュメントの 「WebSphere データ・ソース」 を参照してください。 JMS メッセージ ブローカーなど、その他の JNDI 関連リソースには、移行または再構成が必要になる場合があります。 JMS 構成の詳細については、 「JMS リソースを使用する」を参照してください。

事前構築済みの Azure Marketplace オファーを使用している場合、デプロイ時にカスタマイズできる JNDI リソースのセットは、オファーがサポートするものに制限されます。 AKS 上の WebSphere Liberty の場合、デフォルトの Java Naming and Directory Interface (JNDI) 名前空間でオブジェクトを使用できるようにします。 詳細については、 「Liberty 機能 JNDI デフォルト名前空間を使用した開発」を参照してください。 Open Liberty については、 「Java の名前付けおよびディレクトリ インターフェース」を参照してください。

プロファイルの構成を検査する

WAS の主要な構成単位は、プロファイルです。 そのため、 resources.xml ファイルには、移行のために慎重に検討する必要がある多数の構成が含まれています。 このファイルには、サブディレクトリに格納されているその他 XML ファイルへの参照が記載されています。 詳細については、 「分散オペレーティング・システムおよび IBM i オペレーティング・システムでプロファイルを管理する」を参照してください。

アプリケーション内

deployment.xml ファイルおよび WEB-INF/web.xml ファイルを調べます。

これらのカスタマイズは、AKS が実行するコンテナー イメージでキャプチャする必要があります。 事前構築済みの Azure Marketplace オファーを使用する場合、このようなカスタムは、カスタム コンテナー イメージを作成して、それをパブリック レジストリで利用できるように最適に処理し、デプロイ時にそのレジストリを指すようにします。

WebSphere Application Server Network Deployment セルを使用している場合、各クラスター メンバーは、traditional WAS のインストールで実行されます。 Liberty は、WebSphere Application Server のライトウェイト プロファイルです。 これは、WAS の柔軟で動的なプロファイルです。これにより、WAS サーバーは、使用可能な Java Enterprise Edition コンポーネントの大規模なセットを展開する代わりに、必要なカスタム機能のみを展開できます。

セッション レプリケーションが使用されているかどうか確認する

アプリケーションがセッション レプリケーションに依存している場合は、次のオプションがあります。

  • HTTP セッションの場合、セッション管理のレベルに応じて、キャッシュリやデータベースを使用して、セッション データを収集できます。
  • 分散セッションの場合は、データベース セッションの永続化を使用して、データベースにセッションを保存できます。
  • 動的キャッシュの場合は、キャッシュまたはデータベース内のセッション データを管理できます。
  • セッション管理にデータベースを使用するようにアプリケーションをリファクターできます。
  • Azure Redis Service へのセッションを外部化するようにアプリケーションをリファクターできます。 詳細については、「Azure Cache for Redis」を参照してください。

これらのすべての選択肢において、Liberty が HTTP セッション状態のレプリケーションを行う方法を習得することをお勧めします。 次のドキュメントは、Liberty で HTTP セッションを管理する方法を理解するのに役立ちます。

事前構築済みの Azure Marketplace オファーでは、Application Gateway イングレス コントローラーを介したセッション アフィニティがサポートされます。 オファーをデプロイするときに、 [Cookie ベースのアフィニティを有効にする] を選択します。

データソースの文書化

アプリケーションでデータベースを使用する場合は、次の情報を把握する必要があります。

  • データソース名
  • 接続プールの構成
  • JDBC ドライバーの JAR ファイルの場所

WAS の JDBC ドライバーの詳細については、 「WebSphere Application Server で JDBC ドライバーを使用する」を参照してください。

JDBC 構成は、Liberty のコア・サーバー構成です。 詳細については、 「JDBC ドライバー」を参照してください。

事前構築済みの Azure Marketplace オファーでは、データベースのサポートが制限されています。 アプリケーション イメージの構成を処理し、オファーをデプロイするときにイメージを使用できます。

WAS がカスタマイズされているかどうか確認する

次のうち、どのカスタマイズが行われたかを確認し、作業内容を把握します。

  • スタートアップ スクリプトは変更されていますか? このようなスクリプトには、 wsadmin、 AdminControl、 AdminConfig、 AdminApp および AdminTask が含まれます。
  • JVM に渡される特定のパラメーターはありますか?
  • サーバーのクラスパスに追加された JAR はありますか?
  • サーバーの再起動後に WAS コンポーネントが自動的に起動するように、 systemd などの OS レベルのファシリティを使用していますか?

これらの質問に対する回答に応じて、移行に関する考慮事項を考慮する必要があります。

これらのカスタマイズは、AKS が実行するコンテナー イメージでキャプチャする必要があります。 事前構築済みの Azure Marketplace オファーを使用する場合、このようなカスタムは、カスタム コンテナー イメージを作成して、それをパブリック レジストリで利用できるように最適に処理し、デプロイ時にそのレジストリを指すようにします。

オンプレミスへの接続が必要かどうかを判断する

アプリケーションからオンプレミスのサービスのいずれかにアクセスする必要がある場合、Azure の接続サービスの 1 つをプロビジョニングする必要があります。 詳しくは、「オンプレミス ネットワークの Azure への接続」をご覧ください。 または、オンプレミスのリソースで公開されている一般公開の API を使用するように、アプリケーションをリファクタリングする必要があります。

Java Message Service (JMS) キューまたはトピックが使用中かどうか確認する

アプリケーションで JMS キューまたはトピックを使用している場合は、外部でホストされている JMS サーバーにそれらを移行する必要があります。 JMS を使用する方法の 1 つとして、Azure Service Bus と Advanced Message Queuing Protocol の使用が挙げられます。 詳細については、「Azure Service Bus Standard と AMQP 1.0 で Java Message Service 1.1 を使用する」を参照してください。

JMS パーシステンス ストアを構成した場合、構成をキャプチャして、移行後に適用する必要があります。

IBM MQ を使用している場合は、このソフトウェアを Azure 仮想マシンに移行してそのまま使用します。

Microsoft には、IBM MQ と Logic Apps を統合するソリューションがあります。 詳細については、 「Azure Logic Apps で IBM MQ サーバーからワークフローに接続する」を参照してください。

独自に作成したカスタム共有 Java EE ライブラリを使用しているかどうか確認する

共有 Java EE ライブラリ機能を使用している場合は、次の 2 つの選択肢があります。

  • アプリケーション コードをリファクターして、ライブラリへの依存関係をすべて削除し、代わりにその機能をアプリケーションに直接組み込みます。
  • サーバーのクラスパスにそれらのライブラリを追加します。

Java Enterprise Edition アプリケーションからのサードパーティ API へのアクセスで説明されているように同じ手法でこれらライブラリを処理できます。

OSGi バンドルが使用されているかどうか確認する

WAS に追加された OSGi バンドルを使用している場合、Web アプリケーションに同様の JAR ファイルを直接追加する必要があります。

事前構築済みの Azure Marketplace オファーに提供されるイメージにバンドルを含めることができます。 詳細については、 「OSGi アプリケーション用ライブラリを構築する」を参照してください。

アプリケーションに OS 固有のコードが含まれているかどうかを判断する

アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、アプリケーションが Windows 上で実行されている場合、ファイル システム パス内の / または \ の使用を File.Separator または Paths.get に置き換える必要がある場合があります。

AKS 上の Liberty は Linux x86_64 で実行されます。 OS 固有のコードは、Linux と互換性がある必要があります。 特定の OS 情報を検出する方法については、 「Liberty バージョンに互換性があるかどうか確認する」 の手順を実行します。

IBM Integration Bus が使用中かどうかを判断する

アプリケーションが IBM Integration Bus を使用している場合は、IBM Integration Bus がどのように構成されているかを把握する必要があります。 詳細については、 「IBM Integration Bus」を参照してください。

IBM Integration Bus は、事前構築済みの Azure Marketplace オファーでは直接サポートされていません。 この機能を有効にするには、IBM ドキュメントの 「Liberty 上の JMS アプリケーションが Service Integration Bus に接続できるようにする」 の手順を実行します。

アプリケーションが複数の WAR で構成されているかどうか確認する

アプリケーションが複数の WAR で構成されている場合は、これらの各 WAR を個別のアプリケーションとして扱い、それぞれについてこのガイドに従う必要があります。

アプリケーションが EAR としてパッケージ化されているかどうか確認する

アプリケーションが、EAR ファイルとしてパッケージ化されている場合は、 application.xml、 ibm-application-bnd.xmi、 ibm-application-ext.xmi ファイルを調べて、構成をキャプチャします。 詳細については、 「WebSphere で エンタープライズ アーカイブ (EAR) パッケージを構築する」を参照してください。

事前構築済みの Azure Marketplace オファーを使用すると、既存のコンテナー イメージを使用できます。 ビジネス要件に従ってアプリケーションを準備できます。

実稼働サーバーで実行されているすべての外部プロセスとデーモンを特定する

デーモンの監視など、アプリケーション サーバーの外部で実行されているプロセスがある場合は、それらを削除するか、別の場所に移行する必要があります。

ファイル システムが使用されているかどうかとその使用方法を判断する

Kubernetes は、永続ボリューム (PV) を持つファイル システムを扱います。 永続ボリュームのマウントは、事前構築済みの Azure Marketplace オファーではサポートされていません。 さまざまなストレージ オプションを有効にするには、「Azure Kubernetes Service のアプリケーション用ストレージ オプション」の手順を実行します。

読み取り専用の静的コンテンツ

現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。 静的コンテンツを Azure Blob Storage に移動し、グローバルな高速ダウンロードのために Azure CDN を追加することを検討できます。 詳細については、「Azure Storage での静的 Web サイト ホスティング」と 「クイック スタート:Azure ストレージ アカウントと Azure CDN との統合」を参照してください。

動的に公開される静的コンテンツ

アプリケーションによってアップロードまたは生成されるが、作成後に変更できない静的コンテンツをアプリケーションで許可する場合は、前述のように Azure Blob Storage と Azure CDN を使用し、Azure Function でアップロードと CDN の更新を処理します。 「Azure Functions を使用した静的コンテンツのアップロードと CDN の事前読み込み」で、ご利用いただけるサンプルの実装を提供しています。

ネットワーク トポロジを決定する

Azure Marketplace オファーの現在のセットが、移行の出発点となります。 移行する必要があるアーキテクチャの側面がオファーに含まれていない場合は、既存のデプロイのネットワーク トポロジをキャプチャする必要があります。 その後、ソリューション テンプレートの 1 つを使用して基本オファーを立ち上げた後でも、そのトポロジを Azure で再現する必要があります。

ネットワーク トポロジは、非常に広範なトピックですが、次のリファレンスを使用すると、移行作業に多少の方向性を見出すことができます。

JCA アダプターとリソース アダプターの使用に関する考慮事項

既存のアプリケーションで JCA アダプターまたはリソース・アダプターを使用して他のエンタープライズ・システムに接続する場合は、これらの成果物の構成を、Azure Kubernetes Service (AKS) 上で実行されている Liberty サーバーに適用してください。 詳細については、 「JCA 構成要素の概要」 および 「Java コネクター アーキテクチャ」を参照してください。

クラスタリングが使用されているかどうかを判断する

オペレーターは、AKS で WAS ワークロードを実行する可能性のあるすべての方法でクラスタリングを処理します。

EJB クラスタリングを検査する

アプリケーションでローカルの Enterprise Java Bean (EJB) を使用している場合は、クラスター化された EJB への移行が必要になる場合があります。 詳細については、 「Liberty で EJB アプリケーションをデプロイする」を参照してください。

負荷分散の要件の考慮

負荷分散を考慮する最善の方法は、組み込みの Azure Marketplace オファーによって提供される App Gateway 統合を使用することです。

移行

このセクションの手順では、分析によって事前構築済みの Azure Marketplace オファーを使用することを決定していることを前提としています。

オファーをプロビジョニングする

Azure Portal でオファーを開くには、 「Azure Kubernetes Service の IBM WebSphere Liberty と Open Liberty」を参照してください。 [作成] を選択したら、オファーのフィールドの入力の際に前の手順で収集した情報を使用します。

キーストアの考慮

アプリケーションで使用されるすべての SSL/TLS キーストアの移行を考慮する必要があります。 詳細については、「キーストアの構成」を参照してください。

JMS ソースの接続

データベースを接続したら、IBM ドキュメントの 「JCA 構成要素の概要」 の手順を実行します。

ログの考慮

ログ記録をマスターしないとクラウドを実行できません。 Operator は、さまざまな監視方法を提供します。 詳細については、 「Liberty サーバーランタイム環境を監視する」を参照してください。 Elastic Stack を使用する場合、Azure では Elastic の優れたサポートが提供されます。 詳細については、 「Elastic と Azure の統合とは?」 を参照してください。これら 2 つの知識を組み合わせて、AKS でのLiberty 向け Azure 最適化ログ ソリューションを実現できます。

アプリケーションを移行する

デプロイ時にアプリケーション イメージを提供することを選択したかどうかにかかわらず、CI/CD 経由でアプリケーションを更新する必要があります。 IBM ドキュメントには、この更新の実行方法のサンプルが示されています。 詳細については、 「Liberty でアプリケーションをデプロイする」を参照してください。

テストの構成

Azure 内で実行されている新規サーバーにアクセスできるように、アプリケーションに対してコンテナー内テストを構成する必要があります。 CI/CD に関する考慮事項と同様に、ネットワーク セキュリティ規則により、Azure にデプロイされたアプリケーションにアクセスできるようにテストします。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。

移行後

「移行前」ステップで定義した移行の目標に到達したら、エンド ツー エンドの受け入れテストを実施して、すべてが予期したとおりに機能することを確認します。 次の記事では、移行後の機能強化について説明します。