Ubuntu Server 24.04 最小構成 vs 標準構成：パフォーマンスベンチマーク解説

仮想プライベートサーバーではメモリが不足しているように感じるため、Ubuntu Server 24.04 LTS を再インストールすると、デフォルトの Ubuntu Server インストールか Ubuntu Server (最小化) のどちらかを選択することになります。パッケージが少ないほど、Web リクエストが速くなり、データベースクエリが短くなり、CPU スループットが高くなると思いがちですが、その違いはもっと微妙です。初期パッケージセットを小さくすると、ディスク使用量とバックグラウンド アクティビティは減少しますが、それだけでプロセッサやストレージ デバイスが速くなるわけではありません。

結論：最小限のインストール環境を構築したい場合や、必要なツールだけを追加したい場合は、最小限のインストールを選択してください。より幅広いデフォルトのサーバーツールセットが必要な場合は、標準インストールを選択してください。起動時間、アイドル時のメモリ使用量、ディスク使用量、実際のアプリケーションパフォーマンスは、すべてを「より高速」という単一のラベルで括るのではなく、それぞれ個別に比較してください。

証拠に関する注記（2026年10月9日）：この記事では、再現可能なベンチマーク手法と、各指標で得られる結果について説明します。2つのUbuntu 24.04インストール環境における実際の測定スコアは掲載していません。検証されていないRAM、ディスク、起動時間、スループットの数値は、テスト結果として示していません。

標準版Ubuntu Serverと最小化版Ubuntu Serverの違いは何ですか？

Ubuntu Server の Subiquity インストーラーは、ubuntu-server標準 (デフォルト) とubuntu-server-minimal最小化の 2 つのインストール ソースを提供します。Canonical はこれらのソース識別子を文書化し、casper/install-sources.yamlインストーラー識別子は変更される可能性があるため、選択した ISO を確認することを推奨しています。Canonical Subiquity 自動インストール ソースのドキュメントを参照してください。

どちらもUbuntu Server 24.04 LTSであり、最適化されたCPUアーキテクチャが異なる2つのLinuxディストリビューションではありません。主な違いは、インストール時に提供されるソフトウェアです。どのパッケージが表示されるかは、インストールメディアのリビジョン、オプションの選択、アップデート、ドライバ、およびその後インストールされるアプリケーションによって異なります。あるイメージビルド用に公開されたリストが、すべての24.04ポイントリリースインストーラにそのまま適用されるとは限りませんのでご注意ください。

最小サーバーオプションは、別のイメージファミリーである最小Ubuntuクラウドイメージや、Ubuntuデスクトップの最小インストールオプションと混同しないでください。Ubuntu 24.04 LTSのリリースノートでは、以前のリリースと比較して、最小クラウドイメージのパッケージ数とダウンロードサイズが大幅に削減されたことが説明されています。これらの公開されているクラウドイメージの例は、標準と最小化されたライブサーバーISOの比較ベンチマークではなく、その数値をあたかもベンチマークであるかのように再利用しないでください。

どのパフォーマンスベンチマークが重要ですか？

期待される動作は、測定結果とは異なります。最小化されたマシンは、インストール直後はリソース消費量が少なくなるかもしれません。しかし、両方のマシンで同じデータベース、コンテナランタイム、監視エージェント、Webサーバーが実行されるようになると、観測された差は縮小したり、消滅したり、方向が変わったりする可能性があります。唯一妥当な結論は、対象となるワークロードを測定することによってのみ得られます。

ストップウォッチではなく、公平なテスト設定から始めましょう

同じUbuntu Server 24.04 LTS ISOリビジョンから、標準バージョンと最小化バージョンの2つの使い捨て仮想マシンを作成します。vCPU数、RAM、仮想ディスク、ファイルシステム、ブートモード、ハイパーバイザー設定、ネットワーク接続、ストレージクラスはすべて同一に設定します。物理マシンについては、同等のハードウェアを使用し、同様の熱および電力条件下でテストしてください。これらのマシンは、本番環境のトラフィックには使用しないでください。

両方のシステムで、同じセキュリティアップデートを適用して再起動します。、、、、インストーラーイメージのバージョンとテスト日を記録しcat /etc/os-releaseます。Ubuntu Server 24.04uname -rはlscpu通常、一般提供カーネルトラックを使用しますが、オプションでハードウェア有効化カーネルを使用することもできます。異なるカーネルトラックを使用すると、インストールタイプのみの比較が損なわれる可能性があります。この違いについては、Ubuntu カーネルの GA カーネルと HWE カーネルに関するドキュメントで説明されています。

2種類の測定値を収集してください。

1. 新規インストール時のベースライン：同一のアップデート直後、ワークロードをインストールする前の状態。これにより、インストール時のデフォルト設定における実際的な差異を明確にすることができます。
2. 本番環境に近いベースライン：同じアプリケーションパッケージをインストールし、同じサービスを有効化し、同一の設定を適用した後、初期フットプリントの違いが依然として重要かどうかを確認します。

各テストにつき、少なくとも複数回（できればウォームアップ後に5回以上）実行し、中央値とばらつきを比較してください。再起動後、複数回の起動時間を測定してください。一方のシステムのコールドブート結果と、もう一方のシステムのウォームアップ後の結果を比較しないでください。

まずは簡単に測定できる違いから測定してみましょう。

1. インストール済みのパッケージ数をカウントし、ディスク容量を確認します。

パッケージ数とストレージ使用量は、通常、最も簡単に確認できる特性です。各仮想マシンで、以下を実行します。

dpkg-query -W -f='${binary:Package}\n' | wc -l
df -h /
lsblk -f

ルートファイルシステム上のパーティション数、使用容量、およびファイルシステムレイアウトを記録してください。ルートパーティションのサイズが同程度であることを確認してください。そうでない場合、パーティション分割によって見かけ上の違いが生じる可能性があります。ディスク使用量にはログ、パッケージキャッシュ、ファイルシステムメタデータも含まれるため、インストール時間や更新履歴が同一であることが重要です。

2. 利用可能なRAMを比較する。「空き」RAMだけでなく、利用可能なRAMも比較する。

両方のシステムが一定の安定化期間アイドル状態になった後、以下を実行します。

free -h
systemctl --type=service --state=running --no-pager

availableと の列freeを確認してくださいused。Linux は、通常は使用されていないメモリをキャッシュとして使用し、アプリケーションが必要としたときに解放します。free列の値が小さいからといって、必ずしも問題があるとは限りません。追加のメモリ使用量が、実際に維持する予定のサービスによるものかどうかを確認してください。

3. 起動時間を比較し、遅いサービスを見つける

起動のたびに、ディストリビューションに付属のsystemdツールを使用してください。

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

systemd-analyze time起動段階のタイミングは報告されますが、必ずしもアプリケーションがリクエストを受け付ける準備ができていることを意味するわけではありません。blameユニットが並列で初期化される場合や、一部のサービスタイプが同じ方法で測定されない場合があるため、このリストは誤解を招く可能性があります。クリティカルチェーンを調査し、関心のあるサービスエンドポイントを個別に確認してください。これらの制限事項については、Ubuntu 24.04 systemd-analyze マニュアルに記載されています。

例えば、サーバーがHTTP APIを実行している場合、再起動からAPIヘルスエンドポイントが成功するまでの時間を計測します。ホストがデータベースを実行している場合は、クエリが成功するかどうかを確認します。このような準備状況の計測は、オペレーティングシステムが起動ターゲットに到達することよりも、より実用的な指標となります。

次に、制御された負荷の下でCPUとストレージをテストします。

4. 両方のマシンで同じCPUワークロードを実行する

単純なCPU比較を行うには、新規インストール時のフットプリントを記録した後、各使い捨てVMに同じバージョンのsysbenchをインストールします。その後、同じコマンドを実行します。

sudo apt update
sudo apt install sysbench
sysbench --threads=1 --time=30 cpu --cpu-max-prime=20000 run

繰り返し実行した場合の1秒あたりのイベント数とレイテンシを比較してください。sysbenchプロジェクトのドキュメントには、コマンド構文と組み込みのCPUテストが記載されています。割り当てられたCPU数に収まる場合にのみ、同じスレッド数で2回目の実行を行ってください。パッケージセットを削減しただけではCPUの高速化を主張することはできません。予期しない差異が見られた場合は、ホストCPUの競合、クロック動作、カーネルバージョン、およびバックグラウンドプロセスを確認してください。

5. 本番環境のディスクをベンチマークせずにディスクI/Oをテストする

オプションのストレージ実験として、両方のテストマシンにfioをインストールし、十分な空き容量のある使い捨てファイルシステム上に同一のテストファイルを作成します。以下のコマンドは、現在のユーザーのホームディレクトリに256MiBのファイルを作成し、そのファイルに対して制限付きランダム読み取りワークロードを実行します。

sudo apt install fio
dd if=/dev/urandom of="$HOME/fio-sample.bin" bs=1M count=256 status=progress
fio --name=randread --filename="$HOME/fio-sample.bin" --rw=randread --bs=4k --size=256M --ioengine=libaio --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

両方のマシンで、同一のディスクとI/Oパラメータを使用して実行してください。256 MiBのファイルでは、データベースやストレージデバイスを正確にモデル化するには小さすぎる場合があります。十分なスクラッチ領域と安全なテスト環境が利用可能な場合にのみ、ファイルサイズを大きくし、ワークロードを変更してください。IOPS、帯域幅、レイテンシの分布を記録し、最大の帯域幅の値だけを記録しないでください。ワークロードパラメータについては、Ubuntu 24.04 fioマニュアルを参照してください。有用なデータを含む生のブロックデバイスに対して書き込みテストを実行しないでください。

6. 実際のアプリケーションを最後にテストする

両方のマシンに、Webまたはデータベースのバージョン、接続制限、ログ記録、TLS、キャッシング、監視など、まったく同じアプリケーションスタックをインストールします。別の負荷ジェネレータから、同じ同時実行数とテスト期間で同等のリクエストミックスを送信します。スループット、応答レイテンシの中央値と95パーセンタイル、エラー率、CPU使用率、メモリ負荷、スワッピングを測定します。同じデータセットを使用し、競合を考慮せずに、どちらのマシンもノイズの多いストレージバックエンドを共有していないことを確認します。

小規模なAPIサーバーの場合、負荷がかかった際に一方の構成でスワップが発生すると、アイドルメモリの差が問題となる。一方、十分なRAM容量を持つCPU負荷の高いワーカーの場合、同じアプリケーションバイナリでも実質的に同等のスループットが得られる可能性がある。どちらの結果も、テストを行う前に断言することはできない。

矛盾するベンチマーク結果の解釈方法

• パッケージ数は少ないがCPUスコアは同等：これは完全に一貫性がある。インストールするツールの数が少なくても、計算性能は必ずしも変わらない。
• ディスク使用量は少ないがIOPSは同等：空き容量とデバイス速度は異なる特性です。ストレージハードウェア、I/Oパターン、ファイルシステム、キャッシュなどを確認してください。
• systemdの起動は高速化されるが、アプリケーションの準備は同様に遅い：ボトルネックは、アプリケーションの起動、ネットワーク依存関係、またはデータベースの復旧にある可能性がある。
• アイドル状態のRAMは少ないが、リクエストのレイテンシは同じ：最小化することで有用な容量の余裕が得られる可能性があるが、現在のワークロードはメモリに制約されていない。
• 実行ごとにスコアが大きく変動する場合：勝者を決定する前に、ノイズの多い近隣環境、CPU周波数スケーリング、アップデート、スケジュールされたタスク、サーマルスロットリング、キャッシュウォーミングなどを調査してください。

測定された利点がアイドルディスク容量のわずかな削減に過ぎず、かつ運用ワークフローで不足している管理ユーティリティが繰り返し必要となる場合は、標準インストールの方が生産性の高い選択肢となる可能性があります。サーバーが自動的にプロビジョニングされ、厳密に定義されたサービスを実行している場合は、最小限の基本構成にすることで、パッケージ選択の監査が容易になることがよくあります。

既存のサーバーを最小化モードに切り替えるべきでしょうか？

通常、ベンチマークの数値だけを追い求めるのは避けるべきです。正常に動作する標準的なインストールを行うには、まず実際に稼働しているサービスを調べ、アプリケーションのパフォーマンスを測定してください。無関係なパッケージを削除しても、既に健全なワークロードが改善されるとは限りません。また、不用意にパッケージを削除すると、ネットワーク、リカバリ、ログ記録、リモート管理などが機能しなくなる可能性があります。CanonicalのUbuntuセキュリティガイドラインでは、不要なパッケージを削除する際には、デフォルトパッケージを無差別に削除するのではなく、適切な最小限の初期インストールを選択することを推奨しています。

再構築が有効な場合は、データと構成をバックアップし、復元を検証し、新しいインスタンスに最小化オプションをインストールし、必要なパッケージを明示的にプロビジョニングします。トラフィックを移動する前に、SSHアクセス、アップデート、時刻同期、バックアップ、監視、ファイアウォールポリシー、およびアプリケーションの健全性を検証してください。管理者がバンドルされた診断機能やさまざまな役割を頻繁に利用する場合は、新規インストール時のフットプリントが大きくなっても、標準インストールの方が望ましい場合があります。

セキュリティは関連していますが、別個のものです。パッケージ数を減らすことで、メンテナンスが必要なソフトウェアの量を削減できる可能性がありますが、これは特定のCVE（共通脆弱性識別子）の削減を保証するものではありません。どちらのインストール方法においても、セキュリティアップデートとサービス強化は依然として必要です。

最終確認チェックリスト

• 両方のマシンがUbuntu Server 24.04 LTSであり、アーキテクチャ、パッチレベル、カーネルトラック、インストーラー世代が同じであることを確認してください。
• 標準または最小化の選択、オプションのインストーラーの選択肢、および後から追加されたサービスについて記録してください。
• 同一のアップデート後、およびアイドル状態の安定化期間経過後に、パッケージ数、ルートファイルシステムの使用量、および利用可能なメモリを比較します。
• 複数回の再起動にわたって起動およびアプリケーションの準備状況の測定を繰り返し、単一の最良の実行結果ではなく、中央値を報告する。
• CPU、ストレージ、アプリケーションのワークロードに対して一致するパラメータを使用し、エラーとレイテンシの分布を記録します。
• 同一の依存関係、構成、およびデータを使用してアプリケーションを実行し、違いが容量、信頼性、またはデプロイ時間に影響を与えるかどうかを判断します。

実用的な結論：狭い範囲の自動化サーバーの場合、通常は最小化設定が最適な初期フットプリントとなります。標準設定では、より充実したデフォルトツールセットが提供されます。どちらのオプションも、常に高速というわけではありません。Ubuntu Server 24.04 LTS では、実際に処理しなければならないワークロードに基づいてサービスのパフォーマンスを測定するベンチマークが最も有用です。