クラウドネイティブのコンテキストで JVM メモリを構成する方法

背景

少し前に、ビジネス開発チームから、アプリケーションのメモリ使用量が非常に高く、頻繁に再起動が発生しているとの報告があり、何が起こっているのか調べてほしいと依頼されました。

これまでこの問題にはあまり注目していなかったので、調査と分析のプロセスを記録しておきます。

まず、監視パネルで Pod の監視を確認しました。

確かにほぼ満杯であることがわかりましたが、アプリケーションの JVM 使用率を確認すると、約 30% しかありませんでした。これは、JVM OOM の原因となったのはアプリケーションメモリがいっぱいだったのではなく、Pod メモリがいっぱいだったために Pod メモリオーバーフローが発生し、k8s によって強制終了されたことを示しています。

アプリケーションのレプリカ数を維持するために、k8s は Pod を再起動する必要があるため、一定時間実行した後にアプリケーションが再起動されるようです。

このアプリケーションは JVM 8G で構成されており、コンテナは 16G のメモリを要求するため、Pod のメモリ使用量は約 50% になるようです。

コンテナの原理

この問題を解決する前に、まずコンテナの動作原理について簡単に理解しておきましょう。なぜなら、k8s ではすべてのアプリケーションがコンテナ内で実行され、コンテナは基本的にホストマシン上で実行される通常のアプリケーションだからです。

しかし、Docker を使用すると、各コンテナで起動されたアプリケーションが互いに干渉せず、ファイルシステム、ネットワーク、CPU、メモリが完全に分離され、まるで異なるサーバーで 2 つのアプリケーションが実行されているように感じられます。

実際のところ、これはブラックテクノロジーではありません。 Linux はバージョン 2.6.x 以降、長い間namespace分離をサポートしてきました。 namespaceを使用すると、2 つのプロセスを完全に分離できます。

単にリソースを分離するだけでは不十分で、CPU、メモリ、ディスク、帯域幅などのリソースの使用を制限することも必要です。これはcgroupsを使用して設定することもできます。

特定のプロセスのリソースを制限することができます。たとえば、ホストマシンに 4 コアの CPU と 8G のメモリがある場合、他のコンテナを保護するには、コンテナを 1 コアの CPU、2G のメモリという上限で構成する必要があります。

この図は、コンテナテクノロジーにおける名前空間と cgroup の役割を明確に示しています。要するに：

名前空間は分離を担う
cgroupは制限する責任がある

k8s にも対応する引き出しがあります:

 resources: requests: memory: 1024Mi cpu: 0.1 limits: memory: 1024Mi cpu: 4

このリソースリストは、アプリケーションがコンテナーに少なくとも 1 つの 0.1 コアと 1024M のリソースを割り当てる必要があり、最大 CPU 制限が 4 コアであることを示しています。

異なるOOM

この問題に戻ると、コンテナに OOM があり、それが k8s によって再起動されることを確認できます。これは制限を設定する目的でもあります。

k8s メモリオーバーフローによりコンテナが終了した場合、終了コード 137 のイベントログが表示されます。

アプリケーションの JVM メモリ構成はコンテナ構成サイズと同じであるため、両方とも 8 GB ですが、Java アプリケーションにはオフヒープメモリなどの JVM 管理外のメモリも含まれており、コンテナメモリサイズが簡単に 8 GB の制限を超え、コンテナメモリオーバーフローが発生する可能性があります。