午前2時14分のPagerDutyの悪夢
ナイトスタンドの上でスマートフォンが悲鳴を上げました。アラートの内容は簡潔でした。Node-04: RAM usage 98%, Swap activity high。私は机にかじりつき、目を細めてターミナルウィンドウを見つめました。その間にも、OOM（Out of Memory）キラーがランダムなプロセスの儀式的な処刑を開始していました。
原因はメモリリークでもトラフィックの急増でもありませんでした。それは「仮想化コスト（仮想化税）」でした。私は16GBのノード上で3つのKVM仮想マシンを動かしていましたが、それら3つのアイドル状態のカーネルが、ただ存在しているだけで1.5GBものRAMを消費していたのです。ハードウェア容量の10%が、何の意味もなく浪費されていました。
KVMやVMwareのような従来の仮想化は堅牢ですが、コストがかかります。ホストOSの上で冗長なカーネルを動かすことを強いられるからです。データベース、VPN、CIランナーなどの内部サービスをスケールさせようとすると、これらのオーバーヘッドが投資対効果（ROI）を食いつぶします。あの夜、私は2つ目のOSという重荷を背負わずに、VMのような隔離環境が必要だと痛感しました。その解決策がLXCと、そのモダンな管理レイヤーであるLXDでした。
システムコンテナ vs アプリケーションコンテナ
「コンテナ」という言葉を聞くと、多くのエンジニアはすぐにDockerを思い浮かべます。しかし、LXC/LXDは根本的に異なる問題を解決します。Dockerが作るのはアプリケーションコンテナです。これはNginxのバイナリのような単一のプロセスをラップします。そのプロセスが終了すれば、コンテナも消滅します。これはエフェメラル（一時的）なマイクロサービス向けに構築されており、長期間稼働する環境向けではありません。
対してLXC/LXDはシステムコンテナ提供します。これらは、ホストのLinuxカーネルを共有する軽量な仮想マシンだと考えてください。内部には完全なinitシステム（systemd）、cronジョブ、そして複数のサービスが存在します。SSHでログインすることもでき、物理サーバーとまったく同じように扱うことができます。カーネルのエミュレーションがゼロであるため、ホストのネイティブパフォーマンスの99%を引き出すことができます。新しいDebian環境を1.8秒で起動でき、5台のKVM VMで悲鳴を上げるようなホストに、50台のコンテナを詰め込むことが可能です。
実践：LXD導入の儀式
LXDは、基盤となるLXC技術をユーザーフレンドリーにするデーモンです。クリーンなCLIと強力なREST APIを提供します。最近のほとんどのディストリビューションでは、古いツールチェーンに悩まされないよう、Snapでのインストールが推奨されています。
# Ubuntu/DebianにLXDをインストール
sudo snap install lxd
# sudoの手間を省くため、ユーザーをlxdグループに追加
sudo usermod -aG lxd $USER
newgrp lxd最初のインスタンスを生成する前に、システムを初期化する必要があります。このウィザードでストレージとネットワークを設定します。プロのヒント：常にZFSまたはBTRFSを選択してください。これらのファイルシステムを使用すると、コピーオンライト（CoW）技術により、10GBのコンテナを約200ミリ秒でクローンできます。
lxd init開発用のマシンであれば、デフォルト設定で十分です。予備のディスクがない場合はループバックのZFSプールを選択し、IPv4/IPv6ネットワークを自動設定するためにLXDにlxdbr0ブリッジを作成させましょう。
フリート（艦隊）の展開
LXDのイメージライブラリは膨大です。Ubuntu、Debian、Alpine、さらにはArchまで即座に取得できます。ステージング用のWebサーバーとしてDebian 12インスタンスを立ち上げてみましょう。
# 'web-server'という名前のDebian 12コンテナを起動
lxc launch images:debian/12 web-serverlistコマンドで、構築したフリートの状態を素早く確認できます。
lxc listコンテナが内部IPを持って実行されているのが確認できるはずです。SSHのことは一旦忘れて、execコマンドを使って直接ルートシェルに入ってみましょう。
lxc exec web-server -- bash内部は本物のサーバーのように感じられるはずです。aptも使えれば、systemctlもあり、独自のファイルシステムも持っています。シェルを抜けてもコンテナはバックグラウンドで動作し続け、アイドル時のCPU消費はほぼゼロです。
ハードニングとリソース制限
カーネルを共有することの欠点は「ノイジーネイバー（うるさい隣人）」効果です。理論的には、暴走した1つのスクリプトがホストのリソースを使い果たす可能性があります。LXDは、再起動なしで即座に適用できる詳細なCgroups制限によってこれを防ぎます。
# コンテナを2つのCPUコアと1GBのRAMに制限
lxc config set web-server limits.cpu 2
lxc config set web-server limits.memory 1GB
# ハードウェア割り当てを確認
lxc info web-serverこれらの制限は厳格です。もし不正なPythonスクリプトが16GBのRAMを確保しようとしても, コンテナがそれを抑制し、ホスト全体のクラッシュを防ぎます。
ゼロレイテンシ・スナップショット
本番環境の設定をいじる前に、セーフティネットとしてスナップショットを撮っておきましょう。これはほぼ一瞬で完了します。
lxc snapshot web-server before-update
# ネットワーク設定を壊してしまった場合でも、数秒で復元可能：
lxc restore web-server before-updateコンテナをインターネットに公開するには、LXDのプロキシデバイスを使用します。これにより、ホストのポートをコンテナの内部ポートに直接マッピングできます。
lxc config device add web-server http-proxy proxy listen=tcp:0.0.0.0:80 connect=tcp:127.0.0.1:80現場からの教訓：厳しい現実
2024年、私はクライアントのモニタリングスタックを12台のKVM VPSインスタンスから単一のLXDホストに移行しました。私のミスは何だったか？それはストレージのスループットを軽視したことです。CPUパフォーマンスはネイティブ並みでしたが、標準のext4ループファイル上のディスクI/Oは低速でした。私たちはZFSを使用した専用のNVMeパーティションに切り替え、レイテンシを40%削減しました。高トラフィックのデータベースをコンテナに移行する前には、必ずストレージバックエンドを検証してください。
結論
LXC/LXDは私のインフラ戦略を根底から変えました。もはや内部ツールのために個別の「OS税」を払う必要はありません。かつて3つのVMで手一杯だった同じ16GBのノードで、現在はVPN、プライベートGitサーバー、3つのステージング環境を含む22のコンテナを動かしています。ハイパーバイザーの肥大化なしにLinuxの完全な柔軟性が必要なら、ハードウェアと戦うのをやめてLXDに切り替えましょう。サーバーも、そしてあなたの睡眠時間も、きっと感謝するはずです。
