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)(IAC)とも呼ばれます。 インフラストラクチャ、サービス、デプロイ、セキュリティ、ポリシーは、プラットフォームの目的の状態を定義するリソース ドキュメントにまとめられます。この宣言型のアプローチにより、オペレーターは統一言語を介してサービス、セキュリティ、ポリシーを定義できます。これらのリソースはコードであるため、コード リポジトリに格納でき、アプリケーションで行うのと同じコードのセキュリティ チェックを行えます。プラットフォームの状態が(すべての状態の変更のすべてのコミットメントの履歴とともに)Git リポジトリに存在している場合は、システム障害や障害が発生したときに以前の状態に容易に復元できます。

Anthos プラットフォーム

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

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

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

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

Anthos GKE: コンテナ オーケストレーション

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

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

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

Anthos Config Management: ポリシー管理

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

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

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

Anthos Service Mesh: サービス管理

Anthos Service Mesh は、Anthos GKE で実行されているサービスの接続、モニタリング、保護を可能にする 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 プラットフォームにデプロイします。一部の Java アプリケーションは、コンテナ化に適切ではなく、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(GKE 上と GKE On-Prem 上)にデプロイします。

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 プラットフォームで実行されているアプリケーションをマイクロサービスにリファクタリングします。

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

コンテナで monolith として実行されているアプリケーションもありますが、問題ありません。アプリケーションのモダナイズの前提条件は、アプリケーションを最新のプラットフォーム(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 Code Cloud Code は、開発用クラスタの作成から、テスト、完成したアプリケーションの本番環境での実行に至るまで、IDE での Kubernetes アプリケーションの開発サイクル全体をサポートします。Cloud Code には、すぐに実行可能なサンプル、そのまま使用可能な構成スニペット、カスタマイズされたデバッグ機能が用意されているため、Kubernetes での開発が簡単になります。Cloud Code は、Google Cloud でホストされるクラスタであれば、効率的な Google Kubernetes Engine(GKE)機能によって簡単に作成できます。また、Google Cloud ツール(Cloud Source Repositories、Cloud Storage、さまざまな Cloud ライブラリなど)ともスムーズに統合できます。Cloud Code は VS CodeIntelliJ のどちらでも使用できます。
  • Artifact Registry Artifact Registry では、Google Cloud の統合されたエクスペリエンスの一部として、アーティファクトの格納と依存関係の構築を 1 か所で行えます。 Artifact Registry は、パッケージ、ライブラリ、Docker コンテナ イメージを 1 か所で管理できる場所として機能します。これらのアーティファクト(パッケージとコンテナ イメージ)は、このドキュメントの前半で説明した最新の CI/CD パイプラインで使用できます。
  • ビルドツールJib)や(Buildpacks Jib や Buildpacks を使用すると、使い慣れた Java ツール(maven や gradle など)を使用してコンテナをビルドできます。このようなビルドツールがない場合は、手動で Dockerfile を作成してテストする必要があります。この手動の方法では、コンテナを作成して実行するための Docker デーモンを実行するホストが必要です。このプロセスにはさらにいくつかの手順が含まれており、コードを迅速かつシームレスに本番環境に push したいと考えるデベロッパーは繰り返すことが可能です。単一のビルドステップでは、Jib でバイナリのビルドをオーケストレートし、コンテナ イメージを作成して Container Registry に push します。Jib では、デベロッパーが使い慣れたビルドツールを使うことで、デベロッパーの生産性が向上します。Java コンテナをレジストリに push したら、CI/CD パイプラインを介してデプロイできます。次の図は、Buildpack または Jib の全体的なフローを示しています。

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

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

一部のアプリケーションでは、Java アプリケーションをリファクタリングするには、Java アプリケーション サーバーを再プラットフォーム化する必要があります。ライセンス費用を削減するために、商用アプリケーション サーバー プラットフォーム(WebSphere や WebLogic など)で実行されている Java アプリケーションを、オープンソース コンポーネント(Jbos や 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 をコンテナに移動できます。このアプローチでは、モダナイズするアプリケーションに優先順位を付けることで、独自のペースでモダナイズできます。

次のステップ