この記事では、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 ヒープ メモリを設定する場合、コンテナーメモリの容量と同じにしないでください。コンテナーのメモリ不足 (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 アプリケーションのコンテナー化に関する一般的な推奨事項を理解したら、次の記事に進み、コンテナー化ベースラインを確立します。