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

Last reviewed 2020-06-30 UTC

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

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

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

コンテナ化。このフェーズでは、オンプレミスか Google Cloud かに関係なく、Anthos プラットフォームでの最適な候補となるアプリケーションをコンテナ化してデプロイします。このフェーズでは、Migrate to Containers、最新の継続的インテグレーション / 継続的デプロイ（CI / CD）プラクティス、システムインテグレータツールなど、さまざまなサービスとテクノロジーを使用します。
リファクタリングとプラットフォームの再構築。時間の経過とともに、以前のモノリシックアプリケーションを最新の 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 つのベンダーがロックされなくなりました。オープン標準を採用することで、お客様とビジネス要件に基づいてアプリケーションとインフラストラクチャに関する決定を行うことができます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Migrate to Containers を使用したリフトとモダナイズ

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

Migrate to Containers を使用した移行

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

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

Migrate to Containers と困難な移行

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

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

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

詳細については、Migrate to Containers のドキュメントをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デベロッパーはアプリケーションコードをアプリケーションの Git リポジトリに commit します。
CI システムでコードをテストして Docker イメージアーティファクトを作成し、イメージをレジストリに保存します。
アーティファクトをデプロイする準備が整うと、アーティファクトへの参照がアプリケーションの構成ファイルに追加されます。
そのアプリケーション構成は、Kubernetes で読み取り可能な形式でレンダリングされてコードリポジトリに保存されます。これにより、本番前環境にデプロイされます。
変更がコードリポジトリに commit された後、運用者が変更を確認して、マスターブランチにマージします。
アプリケーションが本番環境にデプロイされます。
組織全体で横断的に変更を適用する場合、運用者は変更をリポジトリに commit します。これにより、アプリケーション構成がトリガーされます。デベロッパーが次の変更をデプロイすると、デベロッパーは運用者からの更新を受け取ります。
同時に、セキュリティエンジニアは、独自のポリシーリポジトリに 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 Virtual Machines を使用すると、バックグラウンドで透過的にデータを移行しながら、数分以内にアプリケーションを検証、実行、Google Cloud に移行できます。Compute Engine への移行方法については、Google Cloud への移行: スタートガイドをご覧ください。

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

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

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

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

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

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

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

Spring Google Cloud

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

Spring Boot アプリケーションから Google Cloud を簡単に使用できるようにするために、Spring Google Cloud プロジェクトには、次の 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 Kubernetes Engine（GKE）機能を備えており、Google Cloud でホストされるクラスタの作成を簡略化でき、さらに Google Cloud ツール（Cloud Source Repositories、Cloud Storage、さまざまな Cloud ライブラリなど）ともスムーズに統合できます。Cloud Code は VS Code と IntelliJ のどちらでも使用できます。
Artifact Registry。Artifact Registry は、統合された Google Cloud エクスペリエンスの一部として、アーティファクトの保管と依存関係のビルドを行うための中心的な場所として機能します。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 アプリケーションを、オープンソースコンポーネント（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 をコンテナに移行できます。このアプローチでは、モダナイズする対象アプリケーションの優先順位付けを行うことで、独自のペースでモダナイゼーションを進めることができます。

次のステップ

Google Cloud Enterprise オンボーディングチェックリストを確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud Architecture Center を確認します。