アプリごとに1つのLXCか、Docker VMを1つか：バックアップと影響範囲の制御に優れているのはどちら？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

One Docker VM vs One LXC per App: Which Gives Better Backup and Blast-Radius Control? - Zima Store Online

アプリケーションが共通の実行環境、リバースプロキシ、監視スタック、バックアップスケジュールを共有しており、アプリケーションプラットフォーム全体をまとめて復元しても問題ない場合は、1つのDocker VMを選択してください。サービスごとにリスク、アップデート、ストレージ、復旧の要件が異なり、パッケージ、マウント、アプリケーションの障害がスタックの他の部分を中断させてはならない場合は、アプリごとに1つのLXCを選択してください。より優れた設計とは、隠れた依存関係を増やさずに文書化できる、最小の復旧単位です。

コンテナを比較する前に復旧単位を定義する

最初に判断すべきなのは、DockerとLXCのどちらが少ないリソースで動作するかではありません。アップデートの失敗、データベースの破損、マウントの不具合、ホストの交換が発生した後に、何をまとめて復元する必要があるかです。単一のDocker VMでは、オペレーティングシステムとコンテナエンジンを含む大きな復旧単位が1つ作成されます。アプリごとに1つのLXCを用意すると、それぞれが独自のファイルシステム、ネットワークID、制限、バックアップ対象を持つ、より小さな復旧単位が複数作成されます。

ZimaSpaceのベアメタル、Docker、Proxmoxのストレージレイヤーに関するガイドでは、レイヤーを追加するたびに永続データの保存場所が変わる理由を解説しています。この比較では、すでにProxmoxを選択していることを前提に、各アプリケーションの復旧境界をどの大きさにするべきかを検討します。

アプリケーションが1つのデータベース、1つのComposeネットワーク、1つのIDプロバイダー、または1つのリバースプロキシ設定を共有しているため独立して起動できない場合、LXCを分けても、実際の分離を実現せずにバックアップファイルが複数できるだけになる可能性があります。コンテナ数を数える前に、依存関係を整理してください。

比較の観点	Docker VMを1つ	アプリごとに1つのLXC
バックアップ対象	より大きなVMバックアップを1つ作成し、アプリケーション対応のデータ保護を行います	アプリコンテナごとに、より小さなProxmoxバックアップを1つ作成します
復元範囲	Dockerプラットフォーム全体をまとめて復元します	関係のないゲストを置き換えずに、1つのサービスを復元できます
ツールの共有	Dockerデーモン、プロキシ、監視エージェント、パッチ適用サイクルを共有します	ベースパッケージ、エージェント、ユーザー、ネットワークルールが重複します
アップデートの影響範囲	カーネル、Docker、ファイアウォール、ファイルシステムの変更が、すべてのアプリに影響する可能性があります	パッケージやアプリの変更の大半が1つのLXC内にとどまります
リソースのオーバーヘッド	ゲストOSは1つですが、その中ですべてのアプリが競合します	コンテナごとのオーバーヘッドは小さいものの、サービスの基本構成が繰り返される
アプリ間通信	シンプルなDockerネットワークと共有Composeプロジェクト	ルーティングネットワーク、DNS、認証情報、ファイアウォールポリシーが必要
最適な構成	1人の運用担当者と1つの復旧スケジュールで管理する、密接に関連したアプリケーションスタック	リスクとライフサイクル要件が異なる独立したサービス

Docker VMを1台にまとめるとプラットフォームのバックアップが簡単になる

1台のVMにLinuxゲスト、Docker Engine、Composeファイル、シークレット、プロキシ設定、コンテナイメージ、永続ボリュームをまとめて格納できます。ProxmoxはVMを1つのオブジェクトとしてバックアップできるため、スタック全体を同じ時点の状態に戻したい場合、ホストの交換や大規模なロールバックを簡単に行えます。

ProxmoxのVMとLXCコンテナの復元に関する最近のガイドでは、LXCの復元は完全な仮想ディスクではなくコンテナのファイルシステムをアーカイブするため、軽量になることが多いと説明されています。一方、VMの利点は完全性です。1回の復元で、ゲストOSとDocker環境をまとめて元に戻せます。

このシンプルさが最も活きるのは、アプリケーションを意図的に1つのプラットフォームとして構成している場合です。メディアスタックでは、リバースプロキシ、認証、ダウンロードツール、監視、ストレージマウントを共有することがあります。1つの要素だけを復元すると、バージョンや認証情報の不整合が生じる可能性があるため、1つの調整されたVMバックアップのほうが、実際の依存関係の境界に適している場合があります。

LXCを分離すれば障害単位と復元単位を小さくできる

アプリごとにLXCを1つ用意すれば、壊れたパッケージ、ルートファイルシステム全体の破損、設定の損傷、更新の失敗を1つのゲスト内にとどめられます。運用担当者は、そのコンテナを復元するだけで済み、同じバックアップ時点以降に正常に変更された無関係なサービスをロールバックする必要がありません。

Proxmoxにおけるサービスの障害範囲を小さくするという実用的な主張は、すべてのアプリケーションが自動的にコンテナ化に値するということではありません。サービスごとに信頼性、保守、可用性の要件が異なる場合、分離には価値があるということです。

すべてのLXCが同じ書き込み可能なアプリケーションディレクトリをマウントしている場合、保護されていない1つのデータベースに依存している場合、または同じプロキシと認証サービスを必要としている場合、そのメリットは失われます。個別のルートファイルシステムでも、共有認証情報、ストレージ、または破壊的な自動化を通じて広がる障害を封じ込めることはできません。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

バックアップの粒度を細かくすると、復元作業が増える可能性がある

バックアップが小さくなれば、運用担当者は重要度の高いサービスを個別に保持、復元、テストできます。Home AssistantのLXCには頻繁なバックアップを設定し、交換可能なダッシュボードにはより短い保持期間を設定できます。バックアップスケジュールは、すべてのアプリケーションを同じように扱うのではなく、変更の頻度と影響に合わせて設定できます。

その代償はオーケストレーションです。5台のLXCを復元するには、正しい起動順序、固定アドレス、DNSレコード、ストレージマウント、証明書、サービス認証情報が必要になる場合があります。各ゲストを個別に取得するバックアップでも、ゲスト間の依存関係が自動的に保持されるわけではありません。

ZimaSpaceのProxmox Backup Serverのワークフローは、VMとコンテナの両方を保護できます。どのサービスを1つの復旧ポイントでまとめて扱い、どれを個別に復旧可能にするかは、引き続き利用者が決めます。

更新によって実際の影響範囲が明らかになる

1台のDocker VM内では、オペレーティングシステムの更新、Dockerデーモンの変更、iptablesやnftablesの変更、ディスク容量不足、またはファイルシステムの問題によって、すべてのコンテナが停止する可能性があります。Dockerによってアプリケーションのパッケージは分離されますが、ゲストカーネル、デーモン、ストレージドライバー、ネットワークスタックは共有されたままです。

LXCを分けると、こうした変更の多くをより小さなゲスト内で行えるようになります。あるアプリケーションで異なるパッケージバージョンや再起動スケジュールを使用しても、他のすべてのサービスの環境を変更せずに済みます。これは、外部公開アプリ、実験的なソフトウェア、または更新サイクルが短いサービスに便利です。

ただし、すべてのLXCはProxmoxホストのカーネルを共有します。ホストカーネル、ストレージ、ネットワークブリッジ、またはProxmoxの障害は、依然として共通の障害要因です。アプリごとにLXCを分けることでゲストレベルの影響範囲は縮小できますが、ホストの独立性が生まれるわけではありません。

共有データベースとプロキシによって、「1アプリ」よりも適切なグループ分けが決まる場合がある

アプリケーションは、Webサービス、データベース、キャッシュ、ワーカー、スケジューラー、プロキシルートなど、複数のコンポーネントで構成されることがよくあります。各コンポーネントを別々のLXCに分割すると、アプリケーションの一貫した状態が複数のゲストにまたがるため、通常の復旧がかえって難しくなる場合があります。

より適切な単位は、アプリケーションスタックごとに1つのLXCを用意し、そのLXC内で密接に連携するコンポーネント向けにDocker Composeを使う方法かもしれません。別の選択肢として、リスクの低い関連サービスには1つのDocker VMを使い、データベース、公開アプリケーション、ハードウェア依存のワークロードには個別のLXCを用意する方法もあります。

各ゲストに何個のアプリケーションを配置するかについてのProxmoxコミュニティでの議論は、分離は一律のアプリ数ではなく、依存関係、セキュリティ、復旧要件に従うべきだという実情を反映しています。

永続ストレージによってバックアップが完全かどうかが決まる

VMのバックアップでは仮想ディスクは取得できても、NASのバインドマウント、外部NFS共有、パススルーされたストレージ、別の場所に保存されたアプリケーションバックアップは含まれない場合があります。LXCのバックアップではルートファイルシステムは取得できても、バインドマウントされたデータセットはアーカイブの外部に残る場合があります。Proxmoxのジョブが成功と報告しただけで、どちらのアーキテクチャでも完全な復旧が保証されるわけではありません。

Composeファイル、シークレット、データベース、アップロードコンテンツ、証明書、外部マウント、バックアップ先をすべて棚卸しします。各パスがVMまたはLXCのバックアップ内にあるか、別のスナップショットで保護されているか、構成から再構築されるかを記録します。

ここが判断の境界です。永続的なアプリケーション状態が、保護されていない1つの共有パスに存在する場合、ゲスト数を変えても復旧性は向上しません。バックアップの粒度を最適化する前に、データの境界を見直してください。

両方の設計で障害訓練を実施する

すべてのアプリケーション、共有依存関係、永続パス、外部マウントを一覧にします。
各サービスで許容できる最大停止時間とデータ損失量を定義します。
完全なDocker VMを新しいゲストIDに復元し、スタック全体を検証します。
関係のないアプリケーションを変更せず、代表的なLXCを1つ復元します。
起動順序、DNS、証明書、データベースへのアクセス、マウントの利用可能性をテストします。
1つのゲスト更新を意図的に失敗させ、どのサービスが停止するかを確認します。
文書化された手順だけを使って復旧を繰り返します。

運用担当者の手順数と復元時間の両方を測定します。復元にあたって文書化されていない関係を10個も再構築する必要があるなら、小さなLXCアーカイブでも運用上簡単とは限りません。すべてのアプリケーションから有効な変更まで削除してしまうなら、大きなVMバックアップでも安全とは限りません。

アプリスタックにはどのゲスト構成が適していますか？

Docker VMを1つにまとめる場合

アプリケーションがインフラを共有し、まとめて保守され、1つのバックアップおよびロールバックポイントを受け入れられる場合は、1つのVMを選択します。永続データのパスを明示し、アプリケーションを考慮したデータベースバックアップを追加し、共有VMを重要なプラットフォームとして監視します。

アプリまたはアプリスタックごとにLXCを1つ割り当てる場合

サービスごとにリスク、信頼性、ハードウェアアクセス、更新、または保持要件が異なる場合は、別々のLXCを選択します。密接に連携するコンポーネントはまとめ、共通の基本設定を自動化して、分離が手作業の繰り返しにならないようにします。

ハイブリッド構成を使用する場合

リスクの低い関連Dockerサービスは1つのVMにまとめ、一方で公開アプリ、データベース、Home Assistant、またはハードウェアに依存するワークロードは、専用のLXCまたはVMに分離します。これにより、すべてのサービスに1つのアーキテクチャを適用するよりも、実用的な境界を設定できます。

よくある質問

アプリごとにLXCを1つ割り当てれば、Dockerは不要ですか？

いいえ。LXCではネイティブパッケージを実行することも、小規模なDocker Composeスタックをホストすることもできます。LXCはProxmoxにおけるゲストの境界を定義し、Dockerはその境界内でのアプリケーションのパッケージ化を定義します。両者は異なる分離とデプロイの課題を解決します。

大きなVMを1つにまとめたほうがバックアップは簡単ですか？

1つのオブジェクトとしてスケジュールや復元を行いやすくなりますが、アーカイブは大きくなり、ロールバックの影響がすべてのアプリケーションに及びます。データベースや外部マウントされたデータについては、アプリケーションごとのバックアップも必要になる場合があります。

LXCはProxmoxノード間で移行できますか？

はい。ただし、デバイスマッピング、ローカルバインドマウント、ホストドライバー、ストレージパス、ネットワークに関する前提は再構築が必要になる場合があります。ルートファイルシステムは、ハードウェアとストレージに関する完全な依存関係よりも簡単に移行できます。

最終結論

アプリケーションが実際に1つのプラットフォームを形成し、まとめてバックアップ、パッチ適用、復元すべき場合は、1つのDocker VMを使用します。サービスに個別の復旧ポイントと、ゲスト単位でより小さな障害範囲が必要な場合は、別々のLXCを使用します。最適な構成は、アイコンごとにゲストを1つ割り当てるのではなく、共有状態と復旧責任に基づいてサービスをグループ化します。