Migrate for Anthos で以前の Java アプリケーションのモダナイゼーションを合理化する方法

※この投稿は米国時間 2020 年 6 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

近年、Google ではハイブリッド クラウドとマルチクラウドのアプリケーション プラットフォームである Anthos を活用して、お客様の Java アプリケーションと、開発、提供プロセスのモダナイズを支援するあらゆる方法をご紹介してきました。今週は、VM ベースの既存のアプリケーションを、Google Kubernetes Engine（GKE）のコンテナで実行できるようにインテリジェントに変換できる Migrate for Anthos が、以前の Java アプリケーションの移行にどのように役立つかについて説明します。

新しい機能の有効化、オンプレミス データセンターのデコミッション、メンテナンス コストの節約など、目的はさまざまですが、多くの組織が以前の Java アプリケーションのモダナイズに積極的に取り組んでいて、できれば GKE と Anthosのコンテナで実行したいと考えています。残念ながら、以前のアプリケーションの中には、リソースの構成と使用状況の情報を取得する方法が、標準仕様の Kubernetes と互換性のないものがあるため、複雑な回避策が必要になります。

これを支援するため、Migrate for Anthos の最新リリースには、以前のアプリケーションの移行を簡素化、合理化するために役立つ新機能が組み込まれています。Oracle Java SE 7 および 8（Update 191 以前）を使用するアプリケーションなど、Linux ベースの従来のアプリケーションに対してコンテナ リソースの可視性を自動的に強化します。これは、以前の Java アプリケーションをアップグレードまたはリファクタリングせずにコンテナに正常に変換する場合に極めて重要です。

Migrate forAnthos は、Linux ファイルシステムの制限に対処するユーザー空間ファイルシステムを透過的かつ自動的に実装することにより、Java アプリケーションをコンテナに正常に移行できます。ご存知と思いますが、Linux は cgroups を使用してコンテナのリソース割り当てを適用します。ただし、Kubernetes での実行については、Kubernetes ノードの procfs / proc ファイルシステムがデフォルトでコンテナにマウントされ、コンテナ自体に割り当てられているリソースではなくホストリソースを反映することが既知の問題として報告されています。また、以前のアプリケーションの一部は、cgroups ファイルからではなく /proc ディレクトリの meminfo や cpuinfo などのファイルからリソースの構成と使用状況の情報を取得するため、それらのアプリケーションをコンテナで実行すると、エラーと不安定性が生じる可能性があります。たとえば、古い Java バージョンは meminfo と cpuinfo からの情報を使用して、JVM ヒープに割り当てるメモリの量、ガベージ コレクション（GC）用に並列で実行するスレッドの数などを決定します。正しく構成されていないコンテナで古い Java アプリケーションを実行すると、メモリ不足エラーが原因でプロセスが強制終了され、優先順位付けやトラブルシューティングが困難になることがあります。

Java のバージョンをアップグレードできない以前のアプリケーションについては、Migrate for Anthos はコミュニティで使用されている一般的なアプローチを採用し、LXCFS ファイルシステムを実装します。これは、ユーザーの介入、特別な構成、アプリケーションの再ビルドを必要としません。Google の目標は、簡単なものだけでなく、お客様がすべてのアプリケーションを迅速かつ効果的に移行できるように支援し、モダナイゼーションの目標を達成できるようにすることです。

以前の Java ウェブ アプリケーションのサンプル

Migrate for Anthos を使用した場合と使用しない場合で移行された、以前の Java アプリケーションの動作の違いを見てみましょう。

このテストでは、古いバージョンの Oracle Java SE 7 Update 80 を使用する JBoss 8.2.1 サーバーを使用しています。このバージョンは Oracle の Java SE 7 アーカイブからダウンロードできます。今回は 2 つの方法でパッケージ化を行います。1 つは標準の Docker コンテナ イメージとして、もう 1 つは Migrate for Anthos を使用してアプリケーションをコンテナに移行したサーバー VM としてパッケージ化する方法です。

アプリケーション側は、処理されるリクエストごとにメモリ負荷をシミュレートするコード行を追加した、サンプルの JBoss ノード情報のサンプル アプリケーションを使用します。次の変更を適用しました。

src/main/java/pl/goldmann/work/helloworld/NodeInfoServlet.java

GKE でアプリケーションをテストする

2 つのアプリケーション コンテナをデプロイするときは、GKE Pod 仕様で次のリソース制限を適用し、4 つの vCPU と 16 GiB の RAM を持つ GKE ノードに 1 つの vCPU と 1 GiB の RAM を割り当てます。

その後、この 2 つのアプリケーション インスタンスを実行します。最初に、ウェブブラウザでアプリケーションの URL にアクセスし、基本的なアプリケーションの出力を確認します。 

標準のコンテナでは次のようになります。

一方、Migrate for Anthos で移行されたコンテナでは次のようになります。

結果の違いは一目瞭然です。標準のコンテナでは、多数の同様のテストでも報告されているように、Java はリソース値をホストノードから報告し、コンテナ リソースの割り当てからは報告しません。標準コンテナの場合、報告される最大ヒープサイズは Java 7 のサイズ設定アルゴリズムに基づいていて、ホストの物理メモリの 4 分の 1 がデフォルトです。一方、Migrate for Anthos で移行されたコンテナの場合、値が正しく報告されます。

Java ガベージ コレクション（GC）のスレッドプランをクエリすると、同様の影響を確認できます。シェルに接続して実行します。

標準コンテナの場合の出力:

移行されたワークロード コンテナの場合の出力:

ここでも、Migrate for Anthos コンテナからは正しい同時実行を確認できますが、標準のコンテナでは確認できません。

次に、負荷がかかった状態での違いによる影響を見てみましょう。Hey を使ってアプリケーションに負荷をかけます。たとえば、次のコマンドはアプリケーションに 2 分間負荷をかけます。リクエストの同時実行は 50 です。

標準のコンテナでのテスト結果は次のとおりです。

これは、サービスが負荷を正しく処理していないことを明確に示しています。実際、コンテナログを検査すると、次のエントリが何度も出現しています。

これはメモリ不足（OOM）エラーによるものです。Kubernetes のデプロイにより OOM で強制終了されたコンテナが自動的に再起動されましたが、その間サービスを利用できませんでした。この理由は、コンテナ リソースの制約ではなく、ホストリソースを考慮することで Java ヒープサイズが誤って計算されているためです。計算が間違っていると、Java は利用可能なメモリ以上のメモリを割り当てようとするため、強制終了されてアプリが中断されます。

対照的に、Migrate for Anthos で移行されたコンテナで同じ負荷テストを実行すると、結果は次のようになります。

これは、メモリの負荷が高い場合でも、アプリケーションが負荷を正常に処理したことを示しています。 

コンテナ テクノロジーを以前のアプリで活用する

Migrate for Anthos を活用することで、Kubernetes で既知の問題となっていたコンテナ リソースの可視性が自動的に強化される仕組みを紹介しました。これにより、古いバージョンの Java で実行される、以前のアプリケーションは移行後に正しく動作するため、Kubernetes Pod 仕様を通じて動的に適用される制約に合わせて手動で調整したり再構成したりする必要がなくなります。また、以前のアプリケーションがメモリ負荷の下でもエラーや再起動を発生させることなく、安定して応答性を維持する点も説明しました。

Migrate for Anthos のこの機能を使用すると、Kubernetes でコンテナ化とコンテナ オーケストレーションのメリットを活用し、以前のアプリケーションの運用と管理のモダナイゼーションを促進できます。イメージベースの管理、無停止のローリング アップデート、クラウド ネイティブ アプリケーションと以前のアプリケーション全体で統合されたポリシーおよびアプリケーション パフォーマンス管理によって CI / CD を活用できるようになり、ソースコードへのアクセスやアプリケーションの書き換えは必要ありません。

詳細については、導入 2 日目からのオペレーションに対するサポートの概要を記した原典のリリースブログをご参照ください。また、こちらのフォームから詳細情報をリクエストできます（コメント欄に「Migrate for Anthos」と記載してください）。

- Google Cloud シニア プロダクト マネージャー Ady Degany、Google Cloud プロダクト マーケティング マネージャー Tom Nikl