Ubuntu Server 24.04 最小インストール vs 標準インストール：パフォーマンスベンチマークが実際に示すもの

2台の同一の仮想マシンにUbuntu Server 24.04 LTSをインストールし、片方にはMinimal、もう片方にはStandard Serverを選択し、インストール規模が小さい方が実際にアプリケーションが高速化されるのかどうか疑問に思うことがあるでしょう。これが、ほとんどの「Minimal vs Standard」比較の背後にある実際的な疑問です。答えは、単一のベンチマークスコアよりも複雑です。Minimalでは、ストレージ使用量、インストール済みパッケージ数、バックグラウンドソフトウェア、場合によってはアイドル状態のメモリや起動処理を削減できますが、CPU、データベース、Webサーバーのカーネルが自動的に高速化されるわけではありません。

コードネーム「Noble Numbat」のUbuntu 24.04 LTSは、Canonicalによって2029年5月31日までの5年間、セキュリティメンテナンスが行われます。どちらのインストールスタイルも同じUbuntuリリースファミリーに属し、同じUbuntuリポジトリを使用できます。重要な違いは、パフォーマンスが調整された別のオペレーティングシステムではなく、デフォルトでインストールされる内容です。Canonicalのパッケージアーカイブではubuntu-server-minimal「Ubuntu Server最小システム」と説明されていますが、ubuntu-serverメタパッケージにはより広範なサーバー管理ツールと推奨パッケージが含まれています。公式のUbuntu Server最小パッケージ定義、Ubuntu Serverパッケージ定義、およびUbuntu 24.04 LTSリリースノートを参照してください。

ミニマル vs スタンダード：実際に何が変わるのか？

ミニマルオプションは、より小規模な開始点として理解するのが最適です。これは、必要最低限​​のサーバープラットフォームをインストールし、汎用サーバー管理者が期待するであろう便利なソフトウェアの一部を省略します。標準サーバーメタパッケージには、端末マルチプレクサ、エディタ、トラブルシューティングユーティリティ、リポジトリ管理ヘルパー、および対話型管理に役立つその他のパッケージなどの追加ツールが含まれています。

Canonicalは、最小限のUbuntuクラウドイメージを、不要なパッケージや場合によっては推奨パッケージを意図的に省略した、より小さなイメージとして文書化しています。Canonicalは、これらのイメージは、より大きなベースイメージよりもデプロイ、プロビジョニング、および起動が速いと述べています。このクラウドイメージに関する記述は、ソフトウェアが少ないほど転送、インストール、初期化の手間が少なくなるという一般的なメカニズムを裏付けていますが、Ubuntu Server ISOインストーラーの普遍的なベンチマーク値として誤解されるべきではありません。クラウドに関するドキュメントは、Ubuntuベースイメージと最小限イメージのページで入手できます。

ベンチマークの主張がこれほど大きく異なる理由

パフォーマンス比較では、多くの場合、3つの異なる要素が混在します。1つ目はフットプリントです。ワークロードをデプロイする前に、パッケージ数、ディスク容量、メモリ使用量はどれくらいでしょうか？ 2つ目は起動オーバーヘッドです。起動時にサービスをアクティブ化するのにどれくらいの時間がかかるでしょうか？ 3つ目はワークロードのパフォーマンスです。1秒あたりのリクエスト数、データベーストランザクション数、コンパイル時間、圧縮速度、その他のアプリケーション指標などが挙げられます。

最小限の構成は、最初のカテゴリで明確な優位性を示す可能性が最も高いです。標準システムに有効化された追加サービスがある場合は、2番目のカテゴリでも改善される可能性があります。3番目のカテゴリは通常、それほど劇的ではありません。両方のマシンが同じカーネル、同じアプリケーションバージョン、同じデータベース、同じサービスセット、同じCPUとストレージ構成を実行している場合、アプリケーションは異なる動作をする理由をほとんど見出さないことがよくあります。Webサーバーは、単に、、、またはトラブルシューティングパッケージがないという理由だけで高速化されるわけではありませtmuxんvim。

そのため、「MinimalはRAM使用量が40%少ない」や「Minimalは15%高速」といった固定数値は、著者がUbuntuの正確なポイントリリース、パッケージの状態、仮想化プラットフォーム、ハードウェア、サービスリスト、ベンチマーク方法を明記していない限り、慎重に扱う必要があります。Canonicalは、Ubuntu Server 24.04のすべての展開環境に対して、MinimalとStandardのパフォーマンスを比較した統一的な表を公開していないため、この記事でもそのような表を作成することはありません。

Ubuntu Server 24.04のベンチマークはまあまあ

最も有用な比較は、ご自身のハードウェアまたはクラウドインスタンスタイプで再現できるものです。まず、同一のリソース上に2つの新規インストール環境を構築してください。Ubuntu 24.04ポイントリリース、CPU数、RAM割り当て、仮想ディスクタイプ、ファイルシステム、ファームウェアモード、ネットワークモデル、仮想化ホストはすべて同じものを使用します。測定前に同じアップデートを適用してください。

1. パッケージ数とインストールサイズを記録する

インストール済みパッケージ数をカウントするには：

dpkg-query -f '${binary:Package}
' -W | wc -l

次に、ディスク使用量を調べます。

df -h /
sudo du -xsh /usr /var 2>/dev/null

これらはフットプリントの測定値であり、アプリケーションの速度の測定値ではありません。両方のシステムで同じアップデートサイクルの直後に実行してください。

2. キャッシュと無駄を混同せずに、アイドル状態のメモリを比較する

を使用してくださいfree -h。ただし、キャッシュされたすべてのメガバイトが永続的に消費されると想定するのではなく、列に注目してくださいavailable。Linux は、意図的にアイドル状態の RAM をファイルシステム キャッシュに使用します。また、違いを説明できるように、アクティブなサービスも記録してください。

free -h
systemctl --type=service --state=running
systemctl list-unit-files --state=enabled

Minimalモードで3つのサービスが削除されたことでメモリ使用量が削減されるのであれば、それは有益な結果と言えるでしょう。後で同じサービスをインストールして有効化すれば、メモリ使用量の差は縮小すると予想されます。

3. 起動時間を測定し、原因を特定する

Systemdには、組み込みのタイミングツールが含まれています。

systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain

複数回起動を実行し、明らかな外れ値を除外して、1回の実行結果ではなく中央値を比較してください。仮想マシンの起動時間は、ハイパーバイザー、クラウド初期化、ストレージの遅延、DHCP、ファームウェア、およびバックグラウンドのホスト負荷によって影響を受ける可能性があるため、単一のサンプルだけでは十分な証拠とはなりません。

4. 実際に関心のあるワークロードをテストする

サーバーがNginx、PostgreSQL、Redis、Docker、Javaサービス、またはPython APIを実行する場合、ソフトウェアスタックを同一にした後で、そのワークロードのベンチマークテストを実施してください。重要なテストは「どちらの新しいOSが軽量か？」ではなく、「両方のマシンにワークロードに必要なすべてのものが搭載された後、軽量なベースラインによって本番ワークロードに変化が生じるか？」です。

CPU負荷の高いテストでは、両方のマシンで同じベンチマークバイナリとバージョンを使用してください。ストレージテストでは、ファイルシステム、マウントオプション、仮想ディスクコントローラ、キュー設定、キャッシュポリシーを同一にしてください。ネットワークテストでは、両方のゲストが同じパスを共有していることを確認し、同じ物理ホストリソースを競合する可能性があるため、ベンチマークを同時に実行しないでください。

どのようなパフォーマンスの違いが期待できるでしょうか？

小規模なVPS、コンテナホスト、アプライアンス型デプロイメント、または自動化されたフリートでは、不要なパッケージはすべてストレージ、更新帯域幅、インベントリの複雑さ、または管理上の注意のいずれかを消費するため、Minimalは実用的な利点があります。また、より小さな開始イメージを使用することで、イメージを繰り返し転送または拡張する必要がある場合のプロビジョニング時間を短縮できます。

人間が対話的に管理する汎用サーバーでは、標準インストールの方がより良い選択肢となる場合がある。追加ツールはトラブルシューティング時の時間短縮に役立ち、いくつかの非稼働コマンドラインユーティリティのリソースコストは、データベースバッファプール、JVMヒープ、コンテナワークロード、ファイルキャッシュなどに比べればごくわずかであることが多い。実行されないパッケージを削除しても、CPUサイクルが魔法のように解放されるわけではない。

標準パッケージセットも「肥大化」の固定定義ではありません。Canonicalはアップデートを通じてパッケージの依存関係や推奨事項を変更する可能性があり、管理者は両方のインストールをカスタマイズするのが一般的です。異なる状態で起動した2つのサーバーは、パッケージの追加や削除によって時間の経過とともに収束する可能性があります。

最小限とは、サポートを減らすという意味ではありません

よくある懸念として、Minimalを選択するとサポートが不十分なオペレーティングシステムになってしまうのではないかという点が挙げられます。CanonicalのMinimal Ubuntuクラウドのドキュメントには、MinimalイメージはUbuntuアーカイブへのアクセスと、ベースイメージと同じセキュリティメンテナンスモデルを維持していると明記されています。Ubuntu Server 24.04 LTS自体も、リリースの標準的なセキュリティメンテナンスライフサイクルの対象となります。失うのは主にプリインストールされた便利な機能であり、通常のパッケージエコシステムへのアクセスではありません。

最小限の環境では対話型管理を行うには機能が不足している場合、Canonical はunminimizeMinimal Ubuntu イメージ用のユーティリティを提供しています。このユーティリティは、ドキュメントと翻訳を復元し、環境をより使いやすくするための追加パッケージをインストールします。Canonical は、Minimal Ubuntu のドキュメント内でこのコマンドについて説明しています。ただし、このコマンドを実行するとunminimize、すべての標準サーバーインストールと完全に一致するとは限りません。インストールされるパッケージは、イメージの種類、インストーラーの選択、アーキテクチャ、およびアップデートによっても異なります。

どちらを選ぶべきでしょうか？

管理された再現可能なベースが必要で、デプロイメントに必要なパッケージが既に正確に分かっている場合は、Minimalを選択してください。これは、自動プロビジョニング、ゴールデンイメージ、CIワーカー、コンテナホスト、エッジアプライアンス、およびディスクやメモリの余裕が重要な小規模VMに特に適しています。

管理者の利便性を最優先する場合、つまりベースラインの最適化よりも利便性を重視する場合は、Standardを選択してください。これは、手動で管理するサーバー、ラボシステム、トラブルシューティングが頻繁に発生する環境、またはアプリケーションのフットプリントがオペレーティングシステムのオーバーヘッドをはるかに上回るマシンにとって、多くの場合、より簡単な選択肢となります。

純粋にスループットのみを基準に判断する場合は、他人のマシンの一般的なパーセンテージに基づいて選択しないでください。両方の環境を同一のテストインスタンスにインストールし、アプリケーションスタックを標準化して、実際のワークロードを測定してください。

結果を確認する方法

勝者を決定する前に、以下の5点を確認してください。両方のマシンが同じUbuntu 24.04ポイントリリースとカーネルを使用していること。両方のマシンが同じアップデートを受け取っていること。CPU、RAM、ディスク、ファイルシステム、仮想化の設定が一致していること。実行中のサービスリストが取得されていること。ノイズを検出するために、アプリケーションベンチマークが十分な回数繰り返されていること。後でテストを再現できるように、パッケージリストとベンチマークコマンドを結果とともに保存してください。

優れた結論では、通常、フットプリントとスループットを区別します。例えば、「この環境では、最小構成の方がインストール済みパッケージとディスク容量が少なく、アプリケーションのベンチマークは、両システムを同一構成にした後でも、通常の実行ごとのばらつきの範囲内でした。」といった具合です。これは、どちらかのインストール方法が普遍的に高速であると主張するよりも、はるかに有用です。

Ubuntu Server 24.04の場合、Minimalはより軽量な初期設定、Standardはより便利な初期設定です。パフォーマンス面でのメリットは、フットプリントとプロビジョニングのオーバーヘッドにおいて最も顕著に現れます。本番環境の速度に影響するかどうかは、インストーラーのラベルではなく、実際のワークロードによって判断すべきです。