JVMランタイムでワークロードを絞り込み

ラベル不要、ワンクリックでクラスタ内のJavaワークロードをすべて検出

Javaのメモリは、他のメモリとは挙動が異なります。固定の -Xmx ヒープは、コンテナのリミットを下げたからといって縮小してはくれません。そのため、ステートレスなAPIと同じ感覚でJavaサービスをライトサイジングすると、OOMKillを招くことになります。多くのチームはこのことを理解しており、JVMワークロードは特に慎重に扱いたいと考えています。問題は、どうやって見つけるかです。Podに「これはJVMで動いている」とラベルを付けているケースはほとんどないため、「このクラスタ内のJavaワークロードだけを見せてほしい」という問いに答えるには、マニフェストをgrepしたり、周囲に聞いて回ったりするしかありませんでした。

この課題が解消されました。PerfectScaleのワークロードテーブルに、フィルター付きのRuntime列が追加されました。選択肢はAll、JVM、Non-JVMの3つです。

できること

PerfectScaleはノードエージェントを通じてJavaコンテナを自動検出するため、このフィルターはラベル付けの運用ルールではなく、検出結果に基づいて機能します。いずれかのコンテナでJVMが動作していれば、そのワークロードはJVMとしてカウントされます。選択したクラスタと期間でJavaコンテナが検出されると、Runtime列はワークロードテーブルのすべてのタブ(Recommendations、Labels and Policies、HPA、GPU)に表示され、CSVエクスポートにも含まれます。

実際に得られるメリットは次のとおりです。

ワンクリックでJVMインベントリを作成。 JVMでフィルターしてCSVをエクスポートすれば、現在のrequests、limits、推奨値を含むJavaサービスの完全なリストをJavaプラットフォームチームに渡せます。属人的な知識は不要です。

より安全に自動ライトサイジングを導入。 まずNon-JVMでフィルターし、Java以外のすべてに対して自動化を有効にします。その後、JVMのリストをもとに、自動化を適用する前にヒープ設定とコンテナのリミットを照らし合わせて確認します。固定の -Xmx がメモリリミットに近いワークロードこそ、確認する価値があります。

Javaのメモリ問題のトリアージを迅速化。 このフィルターは、PerfectScaleが既にJava向けに提供している機能と組み合わせて活用できます。コンテナごとのヒープ、非ヒープ、ガベージコレクターの各メトリクスに加え、リミットを MaxHeapSize 未満に切り詰めるのではなく、明示的に設定されたヒープパラメータを尊重した推奨値が提供されます。

始め方

1. まだの場合は、JVM検出を有効にしてください。PerfectScaleエージェントのhelmフラグを1つ設定するだけです。詳細はJavaコンテナガイドをご覧ください。検出はLinuxノード上で実行されます。
2. クラスタのワークロードテーブルを開きます。Javaコンテナが検出されると、フィルター付きのRuntime列が表示されます。
3. JVMまたはNon-JVMを選択するか、CSVをエクスポートして完全なインベントリを取得します。

Runtimeフィルターは、本日よりすべてのお客様にご利用いただけます。Javaを多く運用されている方で、この機能によって推奨値のレビュー方法が変わった場合も、変わらなかった場合も、ぜひご意見をお聞かせください。