Anthos を使用した Java アプリケーションのモダナイゼーション: ユーザーガイド

このドキュメントでは、Anthos を使用して以前の Java モノリシック アプリケーションをモダナイズするためのプロセス、ベスト プラクティス、ツールの概要を説明します。

このドキュメントは、CTO、CIO、エンタープライズ アーキテクト、アプリケーション デベロッパー、IT セキュリティ管理者、DevOps チーム、サイト信頼性エンジニアリング(SRE)のチームを対象としています。コンテナ化とコンテナ化による運用と開発上のメリットに関する基礎知識を前提にしています。

このドキュメントでは、2 フェーズのアプローチのモダナイゼーションを提案しています。

  1. コンテナ化。このフェーズでは、オンプレミスか Google Cloud かに関係なく、Anthos プラットフォームでの最適な候補となるアプリケーションをコンテナ化してデプロイします。このフェーズでは、Migrate for Anthos、最新の継続的インテグレーション / 継続的デプロイ(CI / CD)プラクティス、システム インテグレータ ツールなど、さまざまなサービスとテクノロジーを使用します。
  2. リファクタリングとプラットフォームの再構築。時間の経過とともに、以前のモノリシック アプリケーションを最新の Java フレームワーク(Spring Boot など)とマイクロサービスにリファクタリングし、再プラットフォーム化します。

このドキュメントでは、各フェーズのガイダンスとリソースが用意されています。また、仮想マシン(VM)でエンタープライズを維持することを計画する場合の代替パスも用意されています。

モダナイゼーションの事例

多くの組織は、イノベーションを模索しながら、ビジネス アプリケーションの実行を維持することに苦戦しています。開発チームと運用チームは、アプリケーション サービスへの新しい需要に対応しつつ、既存のアプリケーション ポートフォリオの維持、運用、改善も行う必要があります。

この新しい需要は、デジタル ビジネス イニシアチブと、既存の機能を改善するためのデジタル トランスフォーメーションの目標によるものです。しかし、Gartner レポート(マルチプラットフォーム アプリケーションのモダナイゼーション ビジネスケースの構築、2019 年 11 月)によると、現在のアプリケーションの 90% は 2025 年まで引き続き使用され、これらのアプリケーションをサポートし管理するための技術的負担は増え続け、現在の IT 予算の 40% を超える額が投じられるとみられています。

企業は新しいアプリケーションを開発して導入していますが、アプリケーションのほとんどはいまだに従来のモノリシック アプリケーションです。これらの従来のアプリケーションの多くは、IBM WebSphere や Oracle® WebLogic などの専用の商用アプリケーション サーバー上で実行されます。多くの場合、これらのアプリケーションは高度に最適化され、メンテナンスや管理が行われているため、企業はイノベーションに苦戦を強いられています。さらに、専用のアプリケーション サーバーによって運用上のオーバーヘッドが増大する可能性があり、(多くの場合に)非常に高額なライセンス契約が必要です。

多くの調査によると、組織は既存のアプリケーション コードを書き換えるのではなく、従来のアプリケーションをモダナイズすることで時間と費用を節約できます。従来のアプリケーションをモダナイズする戦略では、モダナイズに要する時間とコストの削減に重点を置く必要があります。

モダン アプリケーション

最新のアプリケーションによって、顧客に優れたエクスペリエンスを提供でき、顧客維持と満足度の向上による収益の改善につながります。最新のアプリケーションとプラットフォーム開発の原則は、デジタル トランスフォーメーションがもたらすメリットに大きな特長があります。以降のセクションでは、これらの原則について説明します。

デベロッパーと運用者の生産性を改善する

多くのレガシー アプリケーションはモノリシック アプリケーションです。これらのアプリケーションは、いくつかの機能を実行する大規模なコードベースを備えています。アプリケーションの高度化とそれを担う開発と管理チームの存在により、新機能を素早くメンテナンスしてリリースすることが難しくなっています。チーム間には多くの依存関係が存在し、本番環境やお客様に変更をリリースする前にそれらの依存関係を調整し承認を受ける必要があります。この拮抗する力関係により、デベロッパーと運用者の生産性が低下し、お客様の不満につながる可能性があります。

最新のアプリケーションはマイクロサービスを使用してビルドされています。モノリシック アプリケーションの異なるドメインが別々のサービスに分割され、それぞれが特定の機能を担います(そのため、マイクロサービスという用語を使用しています)。このアーキテクチャには次のような利点があります。

  • デベロッパー向け。サービスを互いに分離することで、デベロッパーは他のサービスから切り離して特定の機能に取り組むことが可能です。このアプローチにより、デベロッパーは他のサービスやチームとの緊密な依存関係なしにサービスに機能を追加できるため、デベロッパーの生産性が向上します。
  • 運用者向け。各マイクロサービス リリースでは小さな変更が実装されており、運用チームは 1 つの大規模かつ複雑な変更と比較して、はるかに容易に管理できます。この制御された方式で小規模な変更をデプロイすると、リリースが失敗した場合のリスクが軽減され、運用における生産性が向上します。
  • お客様向け。最新のアーキテクチャの開発と運用の効率化により、モノリシック アーキテクチャよりも迅速にお客様に新機能を提供できるようになります。

サービスと API に重点を置く

多くの場合、レガシー アプリケーションはインフラストラクチャに重点を置いて設計されています。サーバー、仮想マシン(VM)、ネットワーキング、ストレージは、モノリシック アプリケーションの重要な設計要素です。最新のアプリケーションは、サービスと API に重点を置いて設計されています。サービスと API にフォーカスすることには、次のような利点があります。

  • サービスの冗長性と復元力。任意の場所でサービスを実行できます。多くの場合に VM、コンテナ、クラスタなど多くの場所で実行されます。
  • サービスの可用性。サービスに重点を置いて運用することで、アプリケーションの全般的な可用性を改善できます。サービスが利用可能である限り、インフラストラクチャの障害は問題ではなく、関連性がありません。インフラストラクチャではなくサービスと API の観点から設計および検討を行う場合には、稼働時間が重視され、稼働時間がサービスレベル目標(SLO)を満たすことに貢献します。

コンテナ内でマイクロサービスとして実行する

通常、従来のアプリケーションは VM として、またはベアメタルで動作します。これらのプラットフォームは高コストで使用効率が悪い(CPU と RAM の使用率が低い)ため、最新のクラウドベースのプラットフォームよりも管理が困難です(特にベアメタル サーバーの場合)。コンテナ内でマイクロサービスとして走行することから、最新のアプリケーションには次のような利点があります。

  • 小規模でより効率的なアプリケーション。コンテナは、モノリシック アプリケーションよりも 2~3 桁小さいフットプリントでマイクロサービスをパッケージ化できます。
  • Linux ユーザー空間の分離単一のホストで複数のコンテナを実行して、ホストを効率的に使用できます。
  • さまざまな環境とインフラストラクチャ間での移植性。コンテナは、すべての依存関係と必要なライブラリを使用してアプリケーションをカプセル化するため、オンプレミスのデータセンターまたはパブリック クラウド環境のいずれであるかを問わず、任意の環境でコンテナを実行できます。

オープン標準でビルドする

従来のアプリケーションは、多くの場合、機能に商用プロダクトまたはライセンス付きプロダクトを使用します。このアプローチは、ライセンス費用が原因でコストが高くなるだけでなく、アプリケーションが商用プラットフォームに大きく依存する結果につながります。

商用ソフトウェアは、走行するインフラストラクチャまたはハードウェアによって制限される場合があります。たとえば、ソフトウェアの実行がオンプレミスでのみ可能な場合、企業は高コストなデータセンターとインフラストラクチャ(ネットワーキング、ストレージ、サーバー、電力、HVAC など)を管理する必要があります。

多くの場合に、オープンソース ソフトウェアを使用してビルドされているため、最新のアプリケーションとサービスには、次のような利点があります。

  • 拡張性と移植性。任意の場所でサービスを実行できます。
  • サポート。Kubernetes や Docker などの広く採用されているオープンソース テクノロジーには、多くの場合、単一の企業に拘束されない、または単一の企業の利益を目的としない機能を構築する、(多くの企業で構成される)強力なコミュニティが存在します。こうしたオープンソースのアプローチにより、プロダクトの全般的な機能セットが向上します。オープンソース テクノロジー(Kubernetes など)を採用する頻度が高いほど、ほとんどの同等の商用テクノロジーと比べて機能セットが強化されます。
  • 柔軟性。このモデルでは、アプリケーション プラットフォームまたはインフラストラクチャの 1 つのベンダーがロックされなくなりました。オープン標準を採用することで、お客様とビジネス要件に基づいてアプリケーションとインフラストラクチャに関する決定を行うことができます。

最新プラットフォーム

最新のアプリケーションには最新のプラットフォームが必要です。最新のプラットフォームはいくつかのニーズを満たしている必要があります。

高速、高信頼性の安全な機能ロールアウト

最新のプラットフォームでは、新機能の高速、高信頼性の安全なロールアウトをサポートする必要があります。

  • 高速。この要件は、サービスと新機能をデプロイするために十分な自動化を行うことに依存します。自動化により、人間による作業とエラーを排除でき、デリバリー速度が向上します。
  • 高信頼性。プラットフォームでは、機能を段階的にリリースするか、動作しない場合は機能を元の状態に戻す必要があります。
  • セキュリティ。プラットフォームは、きめ細かいアクセス制御をサポートする必要があります。承認された運用者のみが、サービスにアクセスできる、またはプラットフォームに機能とサービスをデプロイできる必要があります。

サービスの優先度

最新のアプリケーションは、インフラストラクチャではなくサービスの観点から設計、開発、実行されます。サービスに対するこの優先度は、インフラストラクチャの障害に対する復元性を有するプラットフォームによって異なります。最新のプラットフォームには、ハードウェアとソフトウェアの障害からサービス(とプラットフォーム自体)を復元する機能が組み込まれています。

一貫性のあるコントロール プレーンを使用したハイブリッド クラウドとマルチクラウドのアプローチ

デジタル トランスフォーメーションの一環として、多くの企業がサービス ポートフォリオのマルチクラウド戦略またはハイブリッド クラウド戦略に移行しています。特定のアプリケーションをオンプレミス データセンターからパブリック クラウドに移動できない(規制、コンプライアンス、またはセキュリティ上の理由から)可能性があるものの、他のサービスに引き続きクラウドを使用することが必要な場合があります。最新のプラットフォームは、多くの場合、オンプレミス データセンター、プライベート クラウド、1 つ以上のパブリック クラウドなど、複数の環境で実行できます。さまざまなインフラストラクチャを実行する一方、最新のプラットフォームについては、デベロッパーと運用者に対して統一された一貫性のあるコントロール プレーンの操作性を実現する必要があります。これにより、運用の効率性が向上します。

Everything as declarative code

レガシー プラットフォーム(VM など)は、命令型の性質を持ちます。多くの場合、運用者はリソースを作成し、アプリケーション ランタイムで実行するスクリプトと構成を指定します。運用者がアプリケーションを変更する場合は、アプリケーションが走行している VM に直接変更を加えます。この処理により、構成のブレが生じる可能性があります。つまり、任意の時点でアプリケーションとプラットフォームが目的の状態にあることは保証されません。このような環境では、失敗に対するトラブルシューティングと復旧が困難な場合があります。

最新のプラットフォームは宣言型のシステムであり、すべてのリソースがコードとして定義されます。Infrastructure as Code(IAC)とも呼ばれます。インフラストラクチャ、サービス、デプロイ、セキュリティ、ポリシーは、プラットフォームの目的の状態を定義するリソース ドキュメントにまとめられます。この宣言型のアプローチにより、運用者は統一言語を介してサービス、セキュリティ、ポリシーを定義できます。これらのリソースはコードであるため、コード リポジトリに格納でき、アプリケーションで行うのと同じコードのセキュリティ チェックを行えます。プラットフォームの状態が(すべての状態の変更のすべての commit の履歴とともに)Git リポジトリに格納されている場合は、システムエラーや障害が発生した際に以前の状態に容易に復元できます。

Anthos プラットフォーム

Anthos は、Google Cloud の最新のアプリケーション プラットフォームです。オープンでハイブリッドなマルチクラウド Anthos プラットフォームを使用すると、既存のアプリケーションをモダナイズし、新しいアプリケーションをビルドして、任意の場所でより安全な方法で実行できます。Anthos は、Google が開発に深く関与したオープンソース テクノロジー(Kubernetes、Istio、Knative など)を基盤としており、オンプレミスとクラウドの各環境で一貫性の実現を支援し、アプリケーション開発を加速させます。

次の図は、典型的な企業環境における Anthos コンポーネントとそれらのインタラクションを示しています。

Anthos プラットフォームがサポートするコア モダナイゼーション機能。

以降のセクションでは、Anthos のコア コンポーネントについて簡単に説明します。

Anthos クラスタ: コンテナ オーケストレーション

Anthos のためのプライマリ コンピューティング環境は、Anthos クラスタを利用して、アプリケーションをデプロイする予定の環境での Kubernetes のインストールを管理します。これらのサービスはアップストリームの Kubernetes リリースをバンドルし、標準準拠の Kubernetes クラスタを作成、スケール、アップグレードできます。

Kubernetes には、コントロール プレーンノード コンポーネントという 2 つの主要な構成要素があります。GKE を使用する場合、Google Cloud はコントロール プレーンをホストし、Kubernetes API サーバーは顧客がアクセスできる唯一のコントロール プレーン コンポーネントです。GKE は、Compute Engine のインスタンスを使用して、顧客のプロジェクトのノード コンポーネントを管理します。Anthos クラスタを使用する場合、すべてのコンポーネントは顧客のオンプレミス仮想化環境でホストされます。

Kubernetes をインストールして実行すると、アプリケーションのデプロイ、構成、アップグレード、スケーリングを管理する共通のオーケストレーション レイヤにアクセスできます。

Anthos Config Management: ポリシー管理

Anthos Config Management によって、構成ファイルと呼ばれるファイルを使用して単一のクラスタ、マルチテナント クラスタ、マルチクラスタの Kubernetes のデプロイを管理できます。構成ファイルは Git リポジトリに保存します。

一部の構成ファイルは Kubernetes オブジェクトのマニフェストです。それ以外の構成ファイルはオブジェクトのマニフェストではなく、Anthos Config Management で必要とされる情報を提供します。構成ファイルは YAML または JSON で記述できます。Anthos Config Management は、これらのファイルの更新を監視し、関連するすべてのクラスタに変更を自動的に適用します。

コードとして構成のアプローチを使用すると、Kubernetes にデプロイしたアプリケーションの管理にすでに使用しているのと同じ原則に従って、Anthos クラスタの構成を管理できます。

Anthos Service Mesh: サービス管理

Anthos Service Mesh は、Anthos クラスタで走行しているサービスを接続、モニタリング、保護できる Istio 互換フレームワークです。Anthos Service Mesh を使用すると、サービスコードの変更を必要とせず、デプロイされたサービス(負荷分散、サービス間の認証、モニタリングなど)のネットワークを作成できます。

Anthos Service Mesh は、アプリケーションの各 Pod にサイドカー プロキシを自動的に挿入します。Pod は Kubernetes アプリケーションの基本的な実行単位です。Pod はアプリケーションのコンテナ(場合によっては複数のコンテナ)をカプセル化します。Anthos Service Mesh では、各 Pod にアプリケーション コンテナと Envoy プロキシ コンテナ(サイドカー プロキシとも呼ばれます)の 2 つのコンテナが含まれています。サイドカー プロキシは、Pod との間で送受信されるネットワーク トラフィックをすべて傍受します。Anthos Service Mesh は、メッシュへの受信トラフィックを管理するための Ingress ゲートウェイも構成します。オープンソースの Istio API を使用して、サイドカーとゲートウェイに適用されるポリシーを構成できます。

モダナイゼーションへのステップ

Google Cloud には、Java アプリケーションをモノリシック状態からマイクロサービスに移行するための規範的なプロセスが用意されています。以下のステップに沿って、ご自分のビジネスの要件とニーズに最適なペースで進めてください。

  1. コードを書き換えることなく、VM での実行からコンテナでの実行まで、適切なアプリケーションのリフトとモダナイズを行います。
  2. 最新の CI / CD の手法を使用して、コンテナ化されたアプリケーションを Anthos プラットフォームにデプロイします。アプリケーションの中には、コンテナ化に適さず、VM として維持されるものもあります。
  3. 時間をかけて、アプリケーションを OSS アプリケーション スタック、最新のフレームワーク、マイクロサービスにリファクタリングします。

次のフローチャートは、このステップを示しています。

モダナイゼーション プロセスのステップの流れ。

これらの重要なステップについては、それぞれ次のセクションで説明します。

モダナイゼーションのステップ

以降のセクションでは、モダナイゼーション プロセスの各ステップと、Anthos と Migrate for Anthos が各段階でどのようにサポートできるかを説明します。

ステップ 1: Java アプリケーションをコンテナ化する

このモダナイゼーションのステップでは、VM として走行する適切な Java アプリケーションをコンテナ化します。

最新のフレームワークとパッケージ化されたアプリケーションのコンテナ化

コンテナ化は、アプリケーション コードとそのオペレーティング環境のすべての依存関係とライブラリをパッケージ化するプロセスです。1 つのホストで複数のコンテナを実行できます。各コンテナには、独立したスタンドアロン アプリケーション環境があります。コンテナは、VM の代替手段であり、軽量かつ移植可能で効率性に優れています。

通常、Java アプリケーションをビルドして JAR ファイルとしてパッケージ化するには、mavengradle などのツールを使用します。その後、VM またはベアメタル サーバーでバイナリを実行します。

Java アプリケーションは、次の 2 つのうちのいずれかの方法でコンテナ化できます。

  1. Migrate for Anthos を使用して、アプリケーションのリフトとモダナイズを行います。
  2. システム インテグレータ ツールを使用してコンテナをビルドします。

Migrate for Anthos を使用したリフトとモダナイズ

Migrate for Anthos を使用すると、VM からコンテナ化されたアーティファクト(Dockerfile や Kubernetes リソース マニフェストなど)にアプリケーションを直接移行できます。その後、コンテナを Anthos(Anthos on GKE、VMware の Anthos クラスタ)にデプロイします。

Migrate for Anthos を使用した移行

Migrate for Anthos を使用してアプリケーションを移行するプロセスは次のとおりです。

  1. 移行候補を特定する。このステップでは、移行に適したアプリケーションを評価します。次の 2 つのアプリケーション タイプが移行に適しています。
    • ソースコードにアクセスできないアプリケーション。 たとえば、デベロッパーが企業に在籍しなくなり、コードベースがサポートされなくなったと仮定します。これらのアプリケーションを VM として管理する代わりに、Migrate for Anthos の簡素化されたコンテナ化プロセスを使用して、これらのアプリケーションを Anthos に移行できます。
    • メンテナンスされていても、開発は実施されていないアプリケーション。アプリケーションによっては、積極的に開発されていなくても、他のサービスへの依存関係によって、企業が引き続き必要とする場合があります。Migrate for Anthos は、これらのアプリケーションをサポートするプラットフォームをモダナイズするプロセスを簡素化します。
  2. Anthos に移行する。移行に適した候補を特定したら、Migrate for Anthos で最新の CI / CD の手法を使用して、VM を Anthos にデプロイ可能なコンテナ化アーティファクトに変換します(次のセクションをご覧ください)。Migrate for Anthos は、アプリケーションのデータと状態を移行する際にも有用です。
Migrate for Anthos と困難な移行

企業が管理するアプリケーションの数は数千にも達する場合があります。移行対象のアプリケーション数や、コンテナ化に伴う複雑さが原因で、企業による重要なクラウド イニシアチブの推進が阻害される場合があります。その結果、企業はビジネス チャンスを逃し、最高水準のパブリック クラウド サービスのメリットを享受できない可能性があります。これらのサービスとしては、データサービスと分析に関連するサービス(BigQuery など)、人工知能アプリケーション(AutoML など)、Google Cloud のトレーニング済み API などの機械学習(ML)アプリケーションなどが考えられます。

Migrate for Anthos を使用すると、次の方法でアプリケーション ポートフォリオの課題と複雑性を軽減できます。

  • 大規模なアプリケーションの移行の処理。Migrate for Anthos を使用すると、デベロッパーや運用者に技術的な負担が生じることなく、多くのアプリケーションをモダナイズするのと並行して Anthos に移行できます。
  • コンテナ化の簡素化。多数のアプリケーションと組み合わせると、コンテナ化が複雑になる可能性があります。また、企業に、短期間での大規模なモダナイゼーションの取り組みに対応できるスキルやリソースがない場合があります。このようなケースでは、Migrate for Anthos によって Anthos への移行とモダナイゼーションが簡略化され、効率的に行えるようになります。

詳細については、Migrate for Anthos に関するドキュメントをご覧ください。

コンテナ化のためのその他のツール

Docker はコンテナ イメージをビルドするために広く使用されているプラットフォームです。Dockerfile は、イメージをアセンブルするためにコマンドラインで呼び出すことのできるすべてのコマンドが含まれたテキスト ドキュメントです。Docker コンテナを作成するには、バイナリ(JAR ファイル)をビルドして、Dockerfile にパッケージ化します。作成した Dockerfile は、CI / CD パイプラインで使用できます。次の図は、Dockerfile を使用するワークフローを示しています。

コンテナ化で使用できるツール

ステップ 2: 最新の CI / CD を使用して Anthos にアプリケーションをデプロイする

このモダナイゼーションのステップでは、コンテナ化された Java アプリケーションを、最新のソフトウェア配信方法を使用して Anthos にデプロイします。

CI / CD を使用したコンテナ化プロセスのフロー

アプリケーションについては、ビルド、テスト、顧客への提供を行うための、適切にオーケストレーションされ自動化された、再現性があり信頼性の高い方法が必要とされます。複数の開発チームが継続的に機能を追加するため、多くの場合、CI / CD を使用してコンテナ化されたアプリケーションをビルド、テスト、デプロイします。

最新のソフトウェア配信方法のメリット

Anthos の最新の CI / CD またはソフトウェア配信プラットフォームでは、次のことが可能です。

  • アプリケーションのプロビジョニングのためのベスト プラクティスを作成し、更新する。
  • スターター(またはボイラープレート)のプロジェクトで新しいアプリケーションをオンボーディングする。
  • 他のアプリケーション開発を中断することなく、アプリケーションの開発と反復を行う。
  • プラットフォーム全体でシームレスにポリシーを実装し、伝搬する。
  • GitOps を使用してデプロイし、リリース管理と変更追跡を改善する。

Anthos を使用したソフトウェア配信プラットフォーム

次の図に示すコンポーネントは、Anthos プラットフォームで利用可能なソフトウェア配信プラットフォームの全体を構成します。

Anthos プラットフォームに含まれているコア ソフトウェア配信コンポーネント。

各コンポーネントは、プラットフォーム上で走行するシステムとアプリケーションに機能を提供します。通常、プラットフォームの稼働時間、構成、安定性、スケーラビリティを維持するのは、開発、運用、セキュリティなどの複数のチームです。

ソフトウェア配信プラットフォームの中核となるコンポーネントは、CI / CD システムです。CI / CD プロセスの定義を開始する際、各コンポーネントが、標準化されたインターフェースに準拠したアーティファクトを生成または使用することを確認する必要があります。標準インターフェースを使用すると、より優れた実装が市場にリリースされたときに、各コンポーネントを簡単に交換できます。コンテナ化されたアプリケーションに向けたプラットフォームを作成する場合は、次の 3 つの標準化されたインターフェースから選択できます。

  • Git リポジトリ
  • Docker イメージ
  • Kubernetes マニフェスト

これらのインターフェースを使用すると、次の図にフローを示すように再利用可能で柔軟な CI / CD パイプラインを作成できます。

再利用可能な継続的デリバリーとデプロイ パイプラインでのコンポーネントのマッピング。

プロセスは次のとおりです。

  1. デベロッパーはアプリケーション コードをアプリケーションの Git リポジトリに commit します。
  2. CI システムでコードをテストして Docker イメージ アーティファクトを作成し、イメージをレジストリに保存します。
  3. アーティファクトをデプロイする準備が整うと、アーティファクトへの参照がアプリケーションの構成ファイルに追加されます。
  4. そのアプリケーション構成は、Kubernetes で読み取り可能な形式でレンダリングされてコード リポジトリに保存されます。これにより、本番前環境にデプロイされます。
  5. 変更がコード リポジトリに commit された後、運用者が変更を確認して、マスター ブランチにマージします。
  6. アプリケーションが本番環境にデプロイされます。
  7. 組織全体で横断的に変更を適用する場合、運用者は変更をリポジトリに commit します。これにより、アプリケーション構成がトリガーされます。デベロッパーが次の変更をデプロイすると、デベロッパーは運用者からの更新を受け取ります。
  8. 同時に、セキュリティ エンジニアは、独自のポリシー リポジトリに commit することによりデプロイ可能な対象を定義するポリシーを実装および調整できます。

ステップ 3: Java の従来のアプリケーション用にオンプレミス VM を最適化する

このモダナイゼーションのステップでは、次の図に示すように、Java アプリケーションはオンプレミスのデータセンターまたは Google Cloud で VM として実行されます。

アプリケーションを移行するか、オンプレミスで最適化するかについての決定ポイント。

一部の Java アプリケーションは、次の理由からコンテナ化の候補として適していない可能性があります。

  • 一部のアプリケーションが、ビジネス クリティカルである。ビジネス クリティカルなアプリケーションをコンテナに移行するリスクが大きすぎる場合、VM を Google Cloud に移行することでインフラストラクチャの柔軟性によるコスト面でのメリットが得られます。Google Cloud では、VM のサイズをカスタマイズすると、費用が膨大になる場合があります。
  • 運用チームが最新のプラットフォームの管理に精通していない。運用チームによっては、VM 環境の管理に精通していない、または最新のコンテナ化されたプラットフォームでの運用に必要なスキルを保有していない場合があります。たとえば、従来のアプリケーション間の接続と依存関係を管理するための現在のツールチェーンには精通しているものの、コンテナ化されたプラットフォームを本番環境に運用できるようになるには時間を要する場合があります。
  • クラウドを段階的に導入する必要がある。たとえば、クラウドの導入を開始する必要があるものの、一度に大量の変更を行うことは望ましくない場合があります。または、リスクが伴うため、環境(データセンターからクラウドへ)とプラットフォーム(VM からコンテナへ)を同時に変更したくないこともあります。
  • 予算と運用上の制約がある。これには、ハードウェアやインフラストラクチャ、ライセンス、アプリケーション アーキテクチャの要件などが含まれることが考えられます。

VM ワークロードを実行するためのオプション

VM ワークロードをより効率的に実行するには、次の 1 つ以上のオプションを選択できます。

  • Google Cloud で実行する。Google Cloud で VM を実行するには、次の 2 つの方法があります。
    • Compute Engine インスタンスとして。Compute Engine は、高性能なネットワーク インフラストラクチャとブロック ストレージにアクセスでき、Google のデータセンターで走行する構成可能な VM を提供します。このオプションにより、企業はオンプレミスのデータセンターとサーバーを管理し、仮想化商用ライセンス(該当する場合)に対して料金を支払う必要がなくなります。
    • VMware as a Service としてVMware と Google Cloud の提携によって実現するオープン プラットフォームは、マルチクラウド環境とハイブリッド クラウド環境でのクラウド アプリケーションの一貫したデプロイ、オペレーション、セキュリティを実現します。このオプションは、現在 VMware 固有の機能に依存している VMware を実行している企業に適用できます。企業は、一貫したコントロール プレーンで(複数の環境全体で)VM を管理するハイブリッド クラウド環境にあるか、または独自のデータセンターとサーバー インフラストラクチャを管理する必要がなくなっています。
  • オンプレミスのデータセンター。次のような理由で、特定のアプリケーションをオンプレミスで VM として実行できます。
    • 規制やコンプライアンスに関する考慮事項
    • ユーザーまたは他のアプリケーションに近い場所に配置することを必要とするパフォーマンスに関するニーズ
    • オンプレミスのハードウェアへの現在の投資

VM を移行するためのツールとソリューション

Google Cloud には、VM を Google Cloud に移行する際に使用できるさまざまなツールとソリューションが用意されています。Migrate for Compute Engine を使用すると、データをバックグラウンドで透過的に移行しながら、数分以内にアプリケーションを検証、実行、Google Cloud に移行できます。Compute Engine への移行方法については、Google Cloud への移行: スタートガイドをご覧ください。

VMware as a Service に移行する場合、Google は信頼できるパートナーと連携して、VMware の Google Cloud への移行を支援するプロフェッショナル サービスを提供しています。

ステップ 4: アプリケーションをマイクロサービスにリファクタリングする

プラットフォームをモダナイズした後は、プラットフォーム上で走行するアプリケーションのモダナイズに専念できます。この段階では、Anthos プラットフォームで走行するアプリケーションをマイクロサービスにリファクタリングします。

アプリケーションのリファクタリングがモダナイゼーションのフローに沿って進められているケース。

依然としてコンテナでモノリスとして走行するアプリケーションが存在することも考えられますが、これは問題ではありません。アプリケーションをモダナイズする前提条件は、アプリケーションを最新のプラットフォーム(Anthos など)に移行することです。移行後、アプリケーションをマイクロサービスにモダナイズするプロセスが、時間の経過とともに発生する場合があります。

Anthos に移行すると、デベロッパーと運用者はともに、アプリケーションとプラットフォームを管理する新しい方法に精通できるようになります。これにより、デベロッパーはコードの迅速なマージと高頻度なテストの実施について習熟でき、一方、運用者はソフトウェアのビルド、テスト、ユーザーへの配信に関する最新の方法を十分に把握できます。

Anthos プラットフォームで走行するアプリケーションの場合は、業務部門でマイクロサービスにモダナイズする対象アプリケーションに優先順位を付けることができます。Google と SI パートナーは、このモダナイゼーションのステップで企業を支援するためのデベロッパーと運用者向けの複数のツールを用意しています。以降のセクションでは、これらのリソースについて説明します。

Spring Cloud GCP

リファクタリングの一環として、Java アプリケーションを Spring Boot などの最新の Java フレームワークに移行できます。Spring Boot と Spring Framework には、最新の Java ベースのエンタープライズ アプリケーションを対象とする包括的なプログラミングと構成のモデルが用意されています。Spring Cloud は、デベロッパーが分散システムの一般的なパターンの一部(構成管理、サービス ディスカバリ、サーキット ブレーカー、インテリジェント ルーティング、マイクロ プロキシ、制御バス、ワンタイム トークン、グローバル ロック、リーダーの選出、分散セッション、クラスタの状態など)を迅速にビルドするためのツールを備えています。

Spring Boot アプリケーションから Google Cloud を簡単に使用できるようにするために、Spring Cloud GCP プロジェクトには、次の Google Cloud プロダクトをサポートするいくつかのライブラリと機能が用意されています。

  • Pub/Sub: Spring Integration と Spring Stream
  • Cloud Spanner、Datastore、Cloud SQL: Spring Data
  • Cloud Logging、Cloud Trace
  • Firestore: Spring Data Reactive Repositories
  • Cloud Storage: Spring Resource と Spring Integration
  • Cloud Vision API: CloudVisionTemplate テンプレート
  • Identity-Aware Proxy(IAP): IAP ヘッダーからの Spring Security ID の抽出
  • BigQuery: Spring Integration

デベロッパー ツール

Google Cloud には、最新のコンテナ化された Java アプリケーションの作成を支援するツールが用意されています。これらのツールには、次のものがあります。

  • Cloud CodeCloud Code は、開発用クラスタの作成から、テスト、完成したアプリケーションの本番環境での実行テストに至るまで、IDE での Kubernetes アプリケーションの開発サイクル全体をサポートします。Cloud Code には、すぐに実行可能なサンプル、そのまま使用可能な構成スニペット、カスタマイズされたデバッグ機能が用意されているため、Kubernetes での開発が簡単になります。Cloud Code は、効率化された Google Kubernetes Engine(GKE)機能を備えており、Google Cloud でホストされるクラスタの作成を簡略化でき、さらに Google Cloud ツール(Cloud Source Repositories、Cloud Storage、さまざまな Cloud ライブラリなど)ともスムーズに統合できます。Cloud Code は VS CodeIntelliJ のどちらでも使用できます。
  • Artifact RegistryArtifact Registry は、統合された Google Cloud エクスペリエンスの一部として、アーティファクトの保管と依存関係のビルドを行うための中心的な場所として機能します。Artifact Registry は、パッケージ、ライブラリ、Docker コンテナ イメージを 1 か所で管理できる場所として機能します。これらのアーティファクト(パッケージとコンテナ イメージ)は、このドキュメントの前の部分で説明した最新の CI / CD パイプラインで使用できます。
  • ビルドツールJibBuildpacks など)Jib と Buildpacks によって、使用方法について習熟している Java ツール(Maven や Gradle など)を使用してコンテナをビルドできます。このようなビルドツールがない場合は、手動で Dockerfile を作成してテストする必要があります。この手動による方法では、コンテナを作成して実行するための Docker デーモンを実行するホストが必要です。このプロセスでは、さらにいくつかのステップを必要とするため、デベロッパーがコードを本番環境に迅速かつシームレスに push することを必要とする場合には、多くの反復作業が生じる可能性があります。単一のビルドステップでは、Jib はバイナリのビルドをオーケストレートし、コンテナ イメージを作成して、イメージを Container Registry に push します。Jib は、デベロッパーにとって汎用なビルドツールを使用して、デベロッパーの生産性を高めます。Java コンテナをレジストリに push したら、CI / CD パイプラインを介してデプロイできます。次の図は、Buildpack または Jib での、このフロー全体を示しています。

    マイクロサービスの作成プロセスにおいて他のデベロッパー ツールが適しているケース。

オープンソース アプリケーション サーバーへの再プラットフォーム化

一部のアプリケーションでは、Java アプリケーションをリファクタリングするには、Java アプリケーション サーバーを再プラットフォーム化する必要もあります。ライセンス費用を削減するために、商用アプリケーション サーバー プラットフォーム(WebSphere や WebLogic など)で走行している Java アプリケーションを、オープンソース コンポーネント(JBoss や Tomcat など)用に再プラットフォーム化します。

従来の Java アプリケーション アーキテクチャ

従来の Java アプリケーションでは通常、3 階層または 4 階層の JEE アーキテクチャを使用します。JEE アーキテクチャでは、多階層エンタープライズ アプリケーションのコンポーネント ベースの開発がサポートされます。次の図は、JEE アプリケーション システムの一般的な階層を示しています。

プレゼンテーション階層、アプリケーション階層、エンタープライズ データ階層で構成される多階層プラットフォーム アーキテクチャ。

各階層は次のとおりです。

  • プレゼンテーション階層。プレゼンテーション階層に存在する、サーブレットや JavaServer ページ(JSP または JSF)などのウェブ コンポーネントまたはスタンドアロン Java アプリケーションは、中間階層への動的インターフェースを備えています。
  • アプリケーションまたは中間階層。アプリケーション階層(中間階層)では、Enterprise Java Beans とウェブサービスは、アプリケーションの再利用可能で配布可能なビジネス ロジックをカプセル化します。これらのサーバー階層のコンポーネントは、JEE アプリケーション サーバーに格納されており、これらのコンポーネントがアクションを実行してデータを保存するためのプラットフォームを備えています。
  • エンタープライズ データ階層。このデータ階層では、企業のデータが通常、リレーショナル データベースに格納、保持されます。

通常、これらのさまざまな階層は、仮想化された環境にデプロイされ、アプリケーション サーバーに依存します。このため、ライセンス費用が非常に高額になる可能性があります。

オープン標準に移行するメリット

オープン標準に移行すると、ライセンス費用が削減され、クラウドベースのデプロイ手法とクラウドベースのプラットフォームによるメリットが得られます。

ツールとソリューション

Google Cloud はさまざまなシステム インテグレータ(SI)と提携しており、JEE アプリケーションの再プラットフォーム化と OSS 技術の導入に実績があります。

再プラットフォーム化のプロセスでは、まず従来の Java アプリケーションの評価を行います。評価では、アプリケーションの複雑性、機能、使用状況に関する指標、ビジネス上の重要性など、さまざまな要素が考慮されます。この評価では、再プラットフォーム化の対象として一連のアプリケーション候補の優先順位付けを行います。SI には、企業が商用アプリケーション サーバーのすべての依存関係をソースコードから削除する作業を支援するデベロッパーと DevOps 向けのツールが用意されています。テストと終了の基準は、次のステージ(デプロイ)に進む前に各アプリケーションごとに考慮されます。このステージは、ソースコードにアクセスでき、プラットフォームのオープンソース バリアントが存在するアプリケーションに対して実施します。

リファクタリングのベスト プラクティス

次の 2 つの Google Cloud の記事では、モノリシック アプリケーションからマイクロサービスへの移行のメリットとプロセスについて説明しています。

Anthos Service Mesh を使用した VM へのマイクロサービスの接続

企業はさまざまなアプリケーションを保有しています。ほぼすべての企業は、最終的に次のいずれかのプラットフォームでアプリケーションを実行しています。

  • コンテナでマイクロサービスを実行するための Anthos プラットフォーム
  • VM を実行するための仮想化プラットフォーム

この 2 つのプラットフォームで走行するサービスは、多くの場合に互いに依存しており、相互に安全に通信できる必要があります。Anthos プラットフォームで走行するマイクロサービスについては、Anthos Service Mesh が、Anthos 外部の仮想環境で走行する VM に対してセキュリティを強化した接続を実現します。

VM を使用した Anthos Service Mesh のメリット

  • VM では、Anthos で走行するコンテナおよびマイクロサービスと同じ Kubernetes スタイルの宣言型ポリシーとセキュリティ管理フレームワークを利用できます。このアプローチにより、運用者は、Anthos で走行しているコンテナと別の環境で走行している VM の間にセキュリティが強化された(mTLS)認証による接続を確保できます。
  • 既存の VM で Anthos プラットフォームへのサービスとして表示されるように再コーディングする必要はありません。VM がサービスとして表示されるようになった後、Anthos はこれを GKE で走行しているサービスとして扱います。
  • 運用者は、インストルメンテーションすることなく、VM の拡張オブザーバビリティ(指標)を取得できます。この指標は、Anthos で走行しているサービスと同じように表示されます。

VM のコンテナ化

時間をかけて、リファクタリング済みの既存の VM をコンテナに移行できます。このアプローチでは、モダナイズする対象アプリケーションの優先順位付けを行うことで、独自のペースでモダナイゼーションを進めることができます。

次のステップ