← Spring コース
60. コンテナイメージと3者の比較
をそのまま1つの層としてに入れると、コードを1行変えるたびに19,914,752バイトの層が作り直しになります。 に付いている展開用の機能()で依存とアプリを別の層に分けると、変わる層は16,384バイトだけでした。イメージ全体は展開後でどちらも約396MBと変わりません。小さくなるのは変更のたびに作り直す部分です。
同じ応答を返す4つの展開後のイメージは、Rust 111.5MB、 native 196.2MB、NestJS 294.0MB、Spring()395.7MBでした。差には実行系( や Node)に加え、ベース OS の違いも混ざります。アイドル時のメモリは約2.5MB、87MB、93MB、265〜283MBで、JVM の値は既定の上限に左右され、512MB の上限では196〜201MBでした。
コース全体を振り返ると、Spring は Java と JVM の制約の上で、や設定、サーバとのつなぎ込みを、やといった実行時の仕組みで肩代わりしてきました。起動のたびに仕事が残り、実行系の JRE を連れて行くのはその裏返しで、その仕事をビルド時へ移すと、今度はビルドの時間と実行時の動的さを払うことを測りました。数値はどれも最小アプリのアイドル時のものです。
点線の付いた語はタップすると説明が出ます。用語集を開く →
ベースイメージOS と JRE。展開後 375.9MB
どちらの方式でも共通で、変わらないその上にアプリを載せる方法が2つ
素朴: fat JAR を1層19,914,752 バイト
1行変更でこの層を丸ごと作り直すレイヤ分け: dependencies19,783,680 バイト
依存を変えない限りそのままレイヤ分けでは、さらに上に重ねる
レイヤ分け: application16,384 バイト
1行変更で作り直すのはここだけ- ・合計は展開後で 395.8MB(素朴)と 395.7MB(レイヤ分け)。レイヤ分けでイメージが小さくなるわけではありません
- ・レイヤ分けには spring-boot-loader と snapshot-dependencies の層もありますが、この構成ではどちらも中身が無く 4,096 バイトでした
- ・Spring(JVM)のベースは Ubuntu ベースの eclipse-temurin:25-jre、Rust と native image のベースは debian:trixie-slim(展開後 109.5MB)で、イメージの差にはこの違いも含まれます
- ・実際に push や pull で転送される量は測っていません
図やコードに出てくる用語(タップで説明)
サンプルコードで身につける(5本) →
学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。
公式ドキュメントで詳しく ↗