このドキュメントは、アプリケーション オーナーとクラウド アーキテクトを対象としています。このドキュメントでは、Tomcat で実行されている Java アプリケーションを、Google Kubernetes Engine（GKE）、GKE Autopilot、Cloud Run、GKE Enterprise で実行されているコンテナに移行する方法について説明します。このプロセスを使用して、オンプレミス環境、プライベート ホスティング環境、他のクラウド プロバイダから Tomcat アプリケーションを移行できます。また、Migrate to Containers を使用して移行を自動化するメリットも紹介します。
このドキュメントは、次のプロダクトについて習熟されていることを前提としています。
- Tomcat アプリケーション サーバーにデプロイされ、Linux 仮想マシン（VM）で実行される Java アプリケーション。
- Kubernetes のコンセプトと Kubernetes コマンドライン ツールの基本的な使用方法。
このドキュメントは、Google Cloud への移行に関するシリーズの一部です。シリーズの概要については、Google Cloud への移行: 移行パスの選択をご覧ください。
Migrate to Containers を使用して、互換性のある Tomcat アプリケーションをサポートされている移行元の環境から GKE、GKE Enterprise、または Cloud Run 環境に移行するには、このドキュメントをお読みください。移行元の環境としては、次のようなものがあります。
- Compute Engine 環境
- VMware vSphere 環境
- Microsoft Azure VM 環境
- Amazon Elastic Compute Cloud（Amazon EC2）環境
Migrate to Containers は、適合性評価ツールを使用して、Linux VM 内のすべての Tomcat アプリケーションを検出、検査、移行します。Tomcat アプリケーションは、このツールによって、個々の Tomcat アプリケーション コンテナに分割されます。移行後は、アプリケーションの一部またはすべてを共有のコンテナ イメージにグループ化できます。次の図では、Migrate to Containers がアプリケーションをどのように分割してコンテナへ移行するのかを示します。
Migrate to Containers を使用すると、次のようなメリットがあります。
- ワークロードのモダナイゼーション: 次の機能を提供します。
- コンテナ内のマイクロサービス（ベースイメージのサイズを縮小）
- サービス ディスカバリ
- 柔軟性（Deployment と HorizontalPodAutoscaler を使用）
- Cloud Logging
- Cloud Monitoring
- コンテナ化された環境: 既存の VM ベースのアプリケーションをコンテナ化します。コンテナに移行するメリットをご覧ください。
- Tomcat の公式イメージ: デフォルトの Tomcat 公式イメージを使用するか、独自のものを使用するように移行または Dockerfile を更新できます。Docker の公式イメージは、Docker のベスト プラクティスをベースイメージにもたらします。
- アプリケーションの自動分割: Tomcat の元の構成を維持しながら、検出された各アプリケーションを個別のコンテナに分割することを自動的に提案します。
- シークレット管理: Tomcat サーバーが使用するキーストア、トラストストア、証明書を検出します。また、Kubernetes プリミティブを自動的に生成して外部化し、Kubernetes Secret としてマウントします。
- 推奨されるロギングの変更: 一般的な Java ロギング フレームワークの構成ファイル（log4j2、log4j、logback など）を自動的に検出し、Kubernetes でのロギングに合わせて変更を提案します。
Migrate to Containers を使用してコンテナに Tomcat アプリケーションを移行することは、ワークロードのモダナイゼーションの過程で考えられるステップの一つです。移行を利用すると、Tomcat アプリケーションをクラウド環境で実行するように変えることができます。また、コストの高い書き直しを避けることもできます。
理想的な移行の候補は、サポート対象の Tomcat および Java のバージョンで動作しており、完全な書き換えによるモダナイゼーションではコストがかかりすぎるか難しすぎるアプリケーションです。
Google Cloud への移行を設計する
Tomcat アプリケーションを移行元の環境から Google Cloud で動作するコンテナへ移行するには、Google Cloud への移行のシリーズで説明されているフレームワークに従います。
次の図は、移行の過程を示しています。
上の図に示すフレームワークは、4 フェーズで構成されています。
- 評価: 移行元の環境、Google Cloud に移行するアプリケーション、移行に適した Tomcat アプリケーションを評価します。
- 計画: Migrate to Containers 用の基本インフラストラクチャを作成します（リソース階層のプロビジョニングやネットワーク アクセスの設定など）。
- デプロイ: Migrate to Containers を使用して、Tomcat アプリケーションを移行元の環境から、GKE、GKE Autopilot、Cloud Run、または GKE Enterprise に移行します。
- 最適化: クラウドのテクノロジーと機能を最大限に活用し始めます。
移行元の環境とアプリケーションの評価
評価フェーズでは、移行元の環境と移行するアプリケーションに関する情報を収集します。これは、移行と移行先の環境の両方で必要なリソースのサイズを適切に設定するのに役立ちます。
評価フェーズでは、次のことを行います。
- ワークロードの包括的なインベントリを作成します。
- プロパティと依存関係に応じてアプリケーションを分類します。
- チームを Google Cloud でトレーニングして教育します。
- Google Cloud 上で実験と概念実証を作成します。
- ターゲット環境の総所有コスト（TCO）を計算します。
- 最初に移行するアプリケーションを選びます。
以降のセクションは、Google Cloud への移行: ワークロードの評価と検出に基づいています。ただし、そのドキュメントでは、Migrate to Containers でコンテナに移行する Tomcat アプリケーションの評価に特化した内容が説明されています。
インベントリを構築する
移行を評価目的で調べるには、Tomcat 環境を把握する必要があります。環境を把握するには、ワークロードとそれらの依存関係に関する情報を収集します。
アプリのインベントリを作成するでは、Tomcat 環境でワークロードとそれらの依存関係のインベントリを作成する方法について説明します。対象のガイダンスに沿って、インベントリを作成します。この作業が完了したら、以下の説明に進んでください。
ワークロードと依存関係のインベントリを作成した後は、インベントリを絞り込みます。Migrate to Containers を使用して Tomcat アプリケーションを移行する場合に組織の関心を引く側面と機能を評価します。
移行のために Tomcat 環境を評価する前に、Migrate to Containers を使用した VM のコンテナへの移行と Google Cloud への移行: ワークロードの評価と調査における評価作業を行います。その作業が終了したら、ワークロードのインベントリを実施します。
ワークロードのインベントリを完了するには、次の点を考慮してください。
- Tomcat インスタンスで実行されているオペレーティング システム: Tomcat インスタンスで実行されているオペレーティング システムとそのライセンスに関する情報を収集し、オペレーティング システムが互換性のあるオペレーティング システムと Kubernetes のバージョンの一覧にあることを確認します。
- アプリケーションを実行している Tomcat のバージョン: アプリケーションを実行している Tomcat のバージョンに関する情報を収集し、それらのバージョンに Migrate to Containers との互換性があることを確認します。
- Tomcat インスタンスにデプロイされたアプリケーション: 各 Tomcat インスタンスにデプロイされているアプリケーションを評価します。次に、アプリケーション間、およびアプリケーションと外部サービス間の依存関係をマッピングします。次に、アプリケーションの構成ソースに関する情報を収集します。これには、次の構成が含まれている可能性があります。
- 環境変数
- 非標準の Tomcat インストール パス
- LDAP ユーザー レジストリ
- Java Database Connectivity（JDBC）接続
- Tomcat プロキシ
- Java プロキシ
- Migrate to Containers の適合性スコア: Tomcat アプリケーションが Migrate to Containers を使用した移行に適しているかどうかを評価します。Migrate to Containers には適合性評価ツールが用意されており、これを Tomcat インスタンスをホストしている VM 上で実行して適合性スコアを計算し、移行のプロセスに関する助言を得る必要があります。Migrate to Containers は、一連の評価ルールを使用して Tomcat アプリケーションを正常に移行します。
- Tomcat クラスタリング: Tomcat クラスタリングは、クラスタ内のすべての Tomcat ノード間でセッション レプリケーションを有効にします。組み込みの
McastServiceメンバーシップ プロバイダなど、一部のクラスタリング実装は、ネットワーク レベルのマルチキャストをサポートしていないため、Kubernetes では正しく機能しません。つまり、Tomcat クラスタリングを構成するには、移行時に手動で構成する必要があります。詳細については、Apache Tomcat Wiki の ClusteringCloud をご覧ください。 - Tomcat プロキシ: 多くの実際のシナリオでは、Tomcat がリバース プロキシの背後で実行されるように構成されている場合があります。リバース プロキシの主な用途は次のとおりです。
- SSL オフロード: 目的のバックエンド サーバーにリクエストを渡す前の暗号化された通信の終了。SSL オフロードの代わりに、Google マネージド証明書を使用して Ingress を作成することもできます。
- キャッシュ保存: レスポンスのローカルコピーをキャッシュに保存すると、バックエンド サーバーの負荷が軽減され、後続の呼び出しのレスポンス時間が短縮されます。キャッシュ保存の代替手段として、Cloud CDN で BackendConfig を作成することもできます。
- 圧縮: サーバー レスポンスを圧縮すると、ネットワーク帯域幅の要件が縮小されます。デフォルトの GKE Ingress では、レスポンスは圧縮も解凍もされません。カスタム Ingress コントローラ（NGINX Ingress コントローラなど）を使用し、use-gzip オプションを
trueに設定して gzip 圧縮を有効にすることもできます。
- Java プロキシ: プロキシ サーバーを使用して Tomcat アプリケーションと Java アプリケーションからの下り（外向き）を制御する場合は、Java のプロキシ設定を無効にできます。Java 仮想マシン（JVM）コマンドライン オプションからプロキシ設定を削除します。次に、Anthos Service Mesh（ASM）の Egress ゲートウェイを構成して、Tomcat コンテナからの下り（外向き）ネットワーキングを制御します。
評価を完了する
環境と Tomcat のワークロードに関連するインベントリを構築したら、Google Cloud への移行: ワークロードの評価と調査の評価フェーズの残りの作業を行います。この作業が完了したら、以下の説明に進んでください。
基盤の計画と構築
基盤の計画と構築のガイダンスに従った後、Tomcat の基盤を完成させます。
- Tomcat ワークロードと移行元の環境が、Tomcat ワークロードの移行の前提条件を満たしていることを確認します。
- データ収集フェーズを完了するには、Tomcat インスタンスを実行している VM で
mfitを実行します。詳細については、適合性評価ツールの使用をご覧ください。
Migrate to Containers とその依存関係をプロビジョニングして構成するには、Migrate to Containers の設定をご覧ください。
この作業が完了したら、以下の説明に進んでください。
Tomcat アプリケーションをコンテナに移行する
デプロイ フェーズでは、次のマイルストーンを使用して説明します。
移行計画を作成して確認する
Tomcat アプリケーションの Migrate to Containers 移行計画を作成します。
- 移行元の環境を Migrate to Containers の移行元として構成する: Tomcat アプリケーションを移行するには、Migrate to Containers に、VM が実行される移行元の環境に関する情報が必要です。これらの情報は、このドキュメントのインベントリの作成セクションで説明している手順で収集します。移行元の環境の構成について詳しくは、移行元の追加をご覧ください。
移行計画を作成する: 移行元の環境からサポートされている移行先の環境に移行する Tomcat アプリケーションを指定するには、移行計画を作成します。たとえば、永続データを保存する場所を構成します。
移行計画の作成とモニタリングの詳細については、移行の作成をご覧ください。Tomcat アプリケーションの移行計画を作成するには、移行の実行で説明されているように、
migctlコマンドライン ツールを使用します。移行計画を確認してカスタマイズする: 移行する各 VM の移行計画を生成したら、要件に沿えるように各プランを見直してカスタマイズします。移行計画のカスタマイズの詳細については、移行計画のカスタマイズをご覧ください。
移行アーティファクトとデプロイ記述子を生成する
Migrate to Containers は、アプリケーションのターゲット Tomcat アーティファクトを生成するために、移行計画で構成した VM で実行されるアプリケーションを抽出します。その後、複数のアーティファクトを作成し、Cloud Storage バケットに配置します。Migrate to Containers は、ターゲット環境でコンテナ イメージのインスタンスをデプロイするためにカスタマイズして使用できるデプロイ記述子も生成します。
Migrate to Containers により、移行されるアプリケーションごとに、以下のものを含むフォルダが作成されます。
- Dockerfile
- アプリケーション バイナリ
- Tomcat 構成ファイル
- ビルド スクリプト
- ビルドとデプロイに使用する Skaffold YAML
- （省略可）
secrets.shスクリプト - （省略可）ロギング アーカイブ
作成して移行するコンテナ アーティファクトの進行状況をモニタリングできます。移行のモニタリングの詳細については、移行されたワークロードのモニタリングをご覧ください。
生成されたリソースと記述子を確認して検証する
Migrate to Containers でコンテナ アーティファクトとデプロイ記述子を生成したら、これらのアーティファクトと記述子を確認し、要件に合わせて更新します。たとえば、次の点を検討してください。
- コンテナ イメージ記述子: Migrate to Containers で生成したコンテナ イメージ記述子を調べ、コンテナ ワークロードに対して十分であることを確認します。ベース コンテナ イメージを更新する必要がある場合は、生成された Dockerfile の
FROM値を更新します。Dockerfile のCATALINA_OPTS環境変数を変更して、JVM 環境変数を設定または変更することもできます。 - アプリケーション レベルのロギング: Migrate to Containers では、変更されたロギング アーカイブが自動的に生成されます。これにより、ロギング設定を変更して、ローカルファイルではなくコンソールにログを書き込むようにできます。
コンテナ アーティファクトとデプロイ記述子の確認について詳しくは、アーティファクトの確認をご覧ください。
コンテナ化されたワークロードを GKE、GKE Autopilot、Cloud Run、GKE Enterprise にデプロイして検証する
ワークロードに対するデプロイ記述子の準備ができたら、次のタスクを実行できます。
- アプリケーション コンテナ イメージをビルドする: 移行したワークロードのアプリケーション コンテナ イメージをビルドします。手順については、コンテナ イメージをビルドするをご覧ください。
- 移行したアプリケーションを移行先の環境にデプロイします。
- 移行したアプリケーションを、GKE、GKE Autopilot、または GKE Enterprise にデプロイするには、Tomcat ワークロードをターゲット クラスタにデプロイするの手順を行います。
- 移行したアプリケーションを Cloud Run にデプロイするには、Cloud Run へのデプロイの手順を行います。
- 移行したワークロードのモニタリング: Tomcat アプリケーション コンテナをデプロイした後、移行先の環境でのパフォーマンスに関するデータを収集できます。詳細については、移行したワークロードのモニタリングをご覧ください。
- 移行したワークロードを統合する: ワークロードを移行先の環境にデプロイしたら、デプロイ プロセスとパイプラインを使用して、ワークロードのコンテナ アーティファクト生成とデプロイ プロセスを統合します。自動デプロイ プロセスを設定しておらず、ワークロードを手動でデプロイしている場合は、手動デプロイから自動デプロイに移行することをおすすめします。
Migrate to Containers をアンインストールする
Migrate to Containers を使用したワークロードの移行が完了した後は、次の操作を行うことをおすすめします。
- 移行中に Migrate to Containers で生成されたアーティファクトへのすべての参照が存在することを確認します。
- Migrate to Containers をアンインストールします。
移行後の環境を最適化する
移行を完了するには、環境の最適化をご覧ください。
移行した Tomcat アプリケーションに対し、次に挙げる Tomcat 固有の最適化を行えます。
- ロギングを調整する: ログファイルが通常はローカル ファイル システムに書き込まれる VM とは異なり、Kubernetes ログは通常
stdoutまたはstderrにストリーミングされます。その後、ログは Cloud Logging などの専用のバックエンドを介して保存、分析、クエリされます。logConfigsアーカイブ アーティファクトで Migrate to Containers の推奨される変更を使用するか、ロギング構成を手動で変更してログをstdoutまたはstderrに書き込めます。 - 機密データの保護: パスワードなどの機密データを Kubernetes Secret に保存します。Kubernetes Secret を使用して、コンテナの起動時に構成のプレースホルダを置き換えます。
- リソース プロファイルを調整する: Kubernetes が Pod を効率的にスケジューリングできるように、リクエストと上限の両方についてリソースの制約を微調整します。メモリ不足（OOM）例外を回避するには、JVM のヒープサイズに合わせてリソースを微調整することも重要です。
- Pod の配置を制御する: 移行した Tomcat アプリケーションが頻繁に相互通信する場合は、同じノードで実行するようにスケジュールします。Pod の配置を制御することが移行したアプリケーションに対して有益なものかどうかについては、ノードに Pod を割り当てるをご覧ください。
次のステップ
- Tomcat アプリケーションをコンテナに移行するための手順ガイドを試してみる。
- リバース プロキシの背後で実行されている複数の Tomcat アプリケーションをコンテナに移行するための手順ガイドを試してみる。
- コンテナの構築と操作のベスト プラクティスを確認する。
- 費用を最適化した Kubernetes アプリケーションを GKE で実行するためのベスト プラクティスを確認する。
- マイクロサービスのアーキテクチャを確認する。
- Migrate to Containers を使用して VM をコンテナに移行する。
- Migrate to Containers を使用して WebSphere アプリケーションをコンテナに移行する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。