【ITニュース解説】I benchmarked boxr vs podman on container startup. Here are the honest numbers.

このニュース記事は、コンテナを起動する際の速さについて、二つの異なるコンテナエンジン「boxr」と「Podman」を比較したベンチマークテストの結果を報告している。システムエンジニアを目指す皆さんにとって、コンテナはこれからの開発や運用で避けて通れない技術であり、その根幹をなすコンテナエンジンの性能比較は非常に興味深い内容だ。

まず、コンテナとは、アプリケーションとその実行に必要なすべてのものを一つにまとめた、独立した実行環境のことだ。OSから隔離されて動作するため、どんな環境でも同じように動くというメリットがある。このコンテナの作成や実行、管理を行うのが「コンテナエンジン」と呼ばれるソフトウェアだ。Dockerが有名だが、Podmanや今回比較対象となっているboxrもその一種である。

今回のベンチマークテストで測定されたのは、すでにダウンロード済みの「alpine」という軽量なLinuxディストリビューションのイメージから、コンテナを「起動し、すぐに終了する」という最もシンプルな操作にかかる時間だった。これは、ユーザーがコマンドを実行してから結果が返ってくるまでの「体感速度」を測るものだ。具体的には、コマンドラインインターフェース（CLI）の起動時間も含めた全体的な時間を、20回ずつ繰り返し測定した。

その結果、boxrのバージョン0.1.44は中央値で134ミリ秒、Podmanのバージョン4.9.3は中央値で217ミリ秒を記録した。つまり、boxrはPodmanに比べて約38%高速にコンテナを起動できるという結果が出た。この差は、コンテナイメージがまだキャッシュされていない「コールドスタート」の場合でも同様の傾向が見られた。テスト環境は、2つの仮想CPUと7.7GBのメモリを持つUbuntuの仮想マシンが使用された。

しかし、これらの数字を鵜呑みにしてはいけない。記事の筆者が「ヘッドラインの数字よりも重要」と強調するように、いくつかの重要な「ただし書き（注意点）」が存在する。

一つ目は、「ルートレスモード」に関する制約だ。本来、コンテナはセキュリティ向上のため、root（管理者）権限なしで実行できる「ルートレスモード」で動かすことが推奨されている。今回のテスト環境では、仮想マシン自体が特殊なコンテナ環境で動いていたため、Podmanを完全なルートレスモードで実行できなかった。そのため、Podmanはroot権限で、boxrは「ルートレスモード」オプションを使って起動されたが、それでも内部的にはroot権限が関与している部分があった。この状況は、Podmanがユーザー名前空間（コンテナ内でユーザーを分離する機能）のセットアップをスキップできたため、むしろPodmanに有利に働いた可能性すらあると筆者は述べている。

二つ目は、ネットワーク機能が無効化されていた点だ。Podmanのデフォルトのネットワーク設定がテスト環境では動作しなかったため、両方のエンジンで「--network none」オプションを使ってネットワーク機能をオフにして比較された。これにより、純粋なコンテナエンジンとランタイムの起動速度が比較されたが、実際のアプリケーションではネットワーク設定は必須であり、その部分の性能は今回の結果には反映されていない。

三つ目は、Podmanの特定の環境設定を回避するための対策がとられた点だ。例えば、ストレージの選択やD-Busというプロセス間通信システムの問題に対応するため、一時的なファイルシステムを利用したり、特定のCGroupマネージャーを指定したりする必要があった。これらの調整は、Podmanの性能に有利に作用した可能性も指摘されている。

四つ目は、テスト環境が限定的であることだ。一つの仮想マシン、一つの軽量なイメージ（alpine）、そして「起動してすぐに終了する」という最も単純なワークロードでの結果である。実際のアプリケーションでは、ボリュームマウントやポート公開、様々なプロセスが動作するため、結果は大きく異なる可能性がある。

五つ目は、boxrのイメージキャッシュの挙動に関する quirk（癖）だ。boxrは「docker.io/library/alpine:latest」のような完全なイメージ名ではなく、「library/alpine:latest」のような短縮形でのみキャッシュを認識する。テストでは、boxrのキャッシュが有効になるようにイメージ名を調整したため、余計なイメージの再ダウンロードや展開によるペナルティは回避された。

これらの注意点を踏まえると、なぜboxrが高速だったのかという点について、筆者は推測を述べている。PodmanはGo言語で書かれたCLIが、conmonという中間プロセスを介してcrunという実際のランタイムに処理を渡す、という比較的多段階なアーキテクチャを持っている。一方、boxrは単一のRust製バイナリであり、CLIからランタイムへのパスがより短い。このようなアーキテクチャの違いが、特にシンプルなコンテナの起動において、boxrの優位性につながっている可能性が高い。

では、このコンテナの起動速度は、どのような場面で重要になるのだろうか。筆者は、長時間稼働するWebサーバーのようなサービスの場合、数十ミリ秒程度の起動時間の差はほとんど影響しないと指摘している。しかし、テストの各ステップで一時的にコンテナを起動・停止する継続的インテグレーション（CI）のジョブ、スクリプト内で補助的に起動されるヘルパーコンテナ、開発者が一日に何度も再起動するようなローカル開発環境、そして必要に応じてコンテナを起動・停止する「スケール・トゥ・ゼロ」のような環境では、この起動速度の差がユーザー体験やシステム全体の効率に大きな影響を与える可能性がある。

今回のベンチマークは特定の狭い疑問に答えたものであり、今後のさらなる検証が必要だと筆者は述べている。例えば、完全なルートレスモードでの比較、Webサーバーを起動して最初の応答までの時間を測るような、より現実的なワークロードでのテスト、OSのページキャッシュをクリアした状態でのストレージ性能の比較、そしてDockerやnerdctlといった他の主要なコンテナエンジンを含めた比較が挙げられている。

今回のベンチマークは、コンテナエンジンの性能を評価する上で、表面的な数字だけでなく、その測定方法や環境、そして隠された制約がいかに重要であるかを教えてくれる良い例だ。システムエンジニアを目指す皆さんは、ベンチマーク結果を見る際に、その数字がどのような条件下で測定されたものなのかを常に意識することが重要である。もし皆さんが自身の環境で同様のテストを実施する機会があれば、その結果を共有することで、この分野の理解がさらに深まるだろう。