この記事では、Java アプリケーションをコンテナー化するための推奨される戦略と設定の概要について説明します。 Java アプリケーションをコンテナー化するときは、コンテナーが使用可能な CPU 時間を慎重に検討してください。 次に、メモリの合計量と、Java仮想マシン (JVM) のヒープ サイズの両方で使用可能なメモリの量を検討します。 コンテナー化された環境では、アプリケーションはすべてのプロセッサにアクセスできるため、複数のスレッドを並列で実行できる可能性があります。 ただし、コンテナーには CPU へのアクセスを調整する可能性がある CPU クォータが適用されているのが一般的です。
JVM はヒューリスティックを使用して、CPU クォータに基づいて "使用可能なプロセッサ" の数を決定します。これは、Java アプリケーションのパフォーマンスに大きく影響する可能性があります。 コンテナー自体に割り当てられたメモリと JVM のヒープ領域のサイズは、プロセッサと同じくらい重要です。 これらの要因によって、ガベージ コレクター (GC) の動作とシステムの全体的なパフォーマンスが決まります。
新しいアプリケーションをコンテナー化する
新しいアプリケーションのJava ワークロードをコンテナー化する場合は、メモリについて考えるときに次の 2 つのことを考慮してください。
- コンテナー自体に割り当てられたメモリ。
- Java プロセスで使用できるメモリの量。
JVM の既定のエルゴノミックスについて
アプリケーションには、開始点と設定が必要です。 JVM には、使用可能なプロセッサの数とシステム内のメモリ量に基づく定義済みの値を持つ既定のエルゴノミックスがあります。 JVM は、次の表に示すデフォルト値を使用して、特定の始動フラグまたはパラメーターなしで開始します。
次の表に、使用可能なリソースの既定の GC を示します。
| 使用可能なリソース | 既定の GC |
|---|---|
| 任意の数のプロセッサ 最大 1,791 MB のメモリ |
SerialGC |
| 2 つ以上のプロセッサ 1,792 MB 以上のメモリ |
G1GC |
次の表は、JVM が実行されている環境で使用可能なメモリの量に応じて、既定の最大ヒープ サイズを示しています。
| 使用可能なメモリ | 既定の最大ヒープサイズ |
|---|---|
| 最大 256 MB | 使用可能なメモリの 50% |
| 256 MB から 512 MB | 約 127 MB |
| 512 MB を超える | 使用可能なメモリの 25% |
既定の初期ヒープ サイズは、使用可能なメモリの 1/64 です。 これらの値は、OpenJDK 11 以降、および Microsoft Build of OpenJDK、Azul Zulu、Eclipse Temurin、Oracle OpenJDK などのほとんどのディストリビューションで有効です。
コンテナー メモリを決定する
アプリケーションのニーズとその固有の使用パターンに応じて、ワークロードに最適なコンテナー メモリ量を選択します。 たとえば、アプリケーションで大きなオブジェクト グラフを作成する場合、多くの小さなオブジェクト グラフを含むアプリケーションに必要なメモリよりも多くのメモリが必要な場合があります。
ヒント
割り当てるメモリの量がわからない場合、適切な開始点は 4 GB です。
JVM ヒープ メモリを決定する
JVM ヒープ・メモリーを割り振る場合は、JVM ヒープに割り振る量より多くのメモリーが JVM に必要であることを覚えておいてください。 最大 JVM ヒープ メモリをコンテナー メモリの量と同じに設定しないでください。 この設定により、コンテナーのメモリ不足 (OOM) エラーやコンテナーのクラッシュが発生する可能性があります。
ヒント
JVM ヒープに 75% のコンテナー メモリを割り当てます。
OpenJDK 11 以降では、次のいずれかの方法で JVM ヒープ サイズを設定します。
| 説明 | フラグ | 例示 |
|---|---|---|
| 固定値 | -Xmx |
-Xmx4g |
| 動的な値 | -XX:MaxRAMPercentage |
-XX:MaxRAMPercentage=75 |
最小または初期ヒープサイズ
コンテナー内など、JVM インスタンスに予約されている一定量のメモリが環境で保証されている場合は、最小ヒープ サイズまたは初期ヒープ サイズを最大ヒープ サイズと同じサイズに設定します。 この設定は、メモリを OS に解放するタスクを実行してはならないことを JVM に示します。
最小ヒープ サイズを設定するには、絶対量に -Xms を使用するか、割合の -XX:InitialRAMPercentage を使用します。
Von Bedeutung
名前が示しているにもかかわらず、フラグ -XX:MinRAMPercentage は、システムで使用可能 な最大 256 MB の RAM を持つシステムの既定の最大 RAM の割合を設定します。
使用する GC を決定する
以前は、JVM の開始時に割り当てるヒープメモリの量を決定しました。 次の手順では、GC を選択します。 多くの場合、使用している最大 JVM ヒープ メモリの量は、GC の選択に影響します。 次の表では、各 GC の特性について説明します。
| 要因 | SerialGC | ParallelGC | G1GC | ZGC | ShenandoahGC |
|---|---|---|---|---|---|
| コア数 | 1 | 2 | 2 | 2 | 2 |
| マルチスレッド | いいえ | イエス | イエス | イエス | イエス |
| Javaヒープサイズ | <4 GB | <4 GB | >4 GB | >4 GB | >4 GB |
| 一時停止 | イエス | イエス | イエス | はい (<1 ミリ秒) | はい (<10 ミリ秒) |
| オーバーヘッド | 最小限 | 最小限 | 適度 | 適度 | 適度 |
| テイル レイテンシーの影響 | 高 | 高 | 高 | 低 | 適度 |
| JDK バージョン | 全て | 全て | JDK 8 以降 | JDK 17 以降 | JDK 11 以降 |
| 適しているケース: | 単一コアの小さいヒープ | 任意のヒープ サイズを持つマルチコアの小さいヒープまたはバッチ ワークロード | 中から大のヒープ (要求 - 応答/DB の相互作用) での応答性 | 中から大のヒープ (要求 - 応答/DB の相互作用) での応答性 | 中から大のヒープ (要求 - 応答/DB の相互作用) での応答性 |
ヒント
ほとんどの汎用マイクロサービス アプリケーションでは、Parallel GC から始めます。
必要な CPU コアの数を決定する
SerialGC 以外の GC の場合は、2 つ以上の vCPU コアを使用するか、Kubernetes 上の2000mに少なくともcpu_limitを使用します。 コンテナー化された環境では、1 つ未満の vCPU コアを選択しないでください。
ヒント
開始するコアの数がわからない場合は、2 つの vCPU コアを選択することをお勧めします。
開始点を選択する
Kubernetes、OpenShift、Azure Spring Apps、Azure Container Apps、Azure App Serviceなどのコンテナー オーケストレーション環境の 2 つのレプリカまたはインスタンスから開始します。 次の表は、新しい Java アプリケーションのコンテナー化に推奨される開始点をまとめたものです。
| vCPU コア | コンテナメモリ | JVM ヒープ サイズ | GC | レプリカ |
|---|---|---|---|---|
| 2 | 4 GB | 75% | ParallelGC | 2 |
次の JVM パラメーターを使用します。
-XX:+UseParallelGC -XX:MaxRAMPercentage=75
既存のオンプレミス アプリケーションをコンテナー化する
アプリケーションが既にオンプレミスまたはクラウド内の VM で実行されている場合は、次の構成から開始します。
- アプリケーションが現在アクセスできるメモリの量と同じです。
- アプリケーションが現在使用できる CPU または vCPU コアの数と同じです。
- 現在使用しているのと同じ JVM パラメーター。
vCPU コア数とコンテナー メモリの組み合わせが利用できない場合は、vCPU コア数とコンテナー メモリを切り上げて、最も近い組み合わせを選択してください。
次のステップ
Java アプリケーションのコンテナー化に関する一般的な推奨事項を理解したら、次の記事に進み、コンテナー化ベースラインを確立します。