NAS Dockerコンテナ管理：docker-composeで複数サービスを一元管理

Synology DS923+やQNAP TS-h973AXなどのNASにDocker環境を構築し、Home AssistantやNextcloud、Pi-holeといったサービスを導入すると、次第に管理すべきコンテナ数が増加します。GUIベースの管理ツール（Synology Container Managerなど）は直感的ですが、環境変数やボリュームマウントの複雑な設定を1つずつ手動で入力するのは非効率であり、設定のバックアップや他機への移行時に再現性を担保できないという課題があります。特に、メモリを32GBまで増設して10以上のサービスを並行稼働させるようなヘビーユースな運用では、個別のGUI操作による管理は限界に達します。

そこで不可欠となるのが、YAML形式で定義し一括制御できるdocker-composeによる管理手法です。インフラ構成をコードとして管理（IaC）することで、サービスの依存関係を明確に定義し、単一のコマンドで全スタックの起動・停止・更新を完結させられます。Composeファイルを適切に運用することで、NAS上の複雑なマイクロサービス群を、本番環境に近い統制された状態で効率的に運用し、メンテナンス時間を大幅に削減することが可能になります。

NASにおけるDocker Compose運用の全体像と設計思想

NAS（Network Attached Storage）でDockerを運用する場合、多くのユーザーがメーカー提供のGUI管理ツール（SynologyのContainer ManagerやQNAPのContainer Stationなど）を利用します。しかし、サービス数が増え、相互連携が必要な構成になると、GUIによる個別管理は限界を迎えます。ここで重要になるのがdocker-composeによる「Infrastructure as Code (IaC)」の考え方です。compose.yaml（旧docker-compose.yml）に定義を記述することで、ネットワーク構成、ボリュームマウント、環境変数をコードとして管理でき、バックアップや移行、バージョン管理をGit等で一元的に行えるようになります。

NAS環境でのCompose運用における最大の鍵は、ディレクトリ構造の標準化です。NASのストレージプール（例：/volume1や/share）配下に、サービスごとの独立したディレクトリを構築することが推奨されます。例えば、/volume1/docker/nextcloud/配下にcompose.yamlとconfig/ディレクトリを配置し、データの実体は/volume1/docker/nextcloud/data/に保存する形式です。これにより、特定のサービスのコンテナを削除しても設定ファイルやデータベースの内容が保持され、かつ、NAS全体のバックアップスケジュール（Hyper BackupやHBS3等）に組み込みやすくなります。

ハードウェアリソースの観点では、2026年時点のNAS運用において、メモリ容量が最大のボトルネックとなります。Dockerコンテナ自体は軽量ですが、Javaベースのアプリケーション（例：Nextcloudの全文検索機能やHome Assistantの高度なアドオン）やデータベース（PostgreSQL, MariaDB）を複数動かすと、メモリ消費量は急激に増大します。特に、ZFSファイルシステムを採用しているTrueNAS Scaleなどの環境では、ARC（Adaptive Replacement Cache）が物理メモリを大量に消費するため、Dockerに割り当てる分を明確に計算する必要があります。

以下に、NAS上のDocker運用における管理レイヤーの構成例を示します。

このように、単にコンテナを動かすのではなく、「プロキシ→アプリ→DB」というスタックを一つのComposeファイル、あるいは共通ネットワークに属する複数のComposeファイルとして設計することで、NASという限られたリソース内で高い可用性と保守性を実現できます。

NASハードウェアの選定基準と実装パターン

Docker Composeで複数サービスを運用する場合、NASのCPUアーキテクチャとメモリ帯域がパフォーマンスを決定づけます。2026年現在、エントリークラスのARMベースNAS（Realtek RTD1295等）でも動作は可能ですが、コンテナ数が増えるとI/O待ち（I/O Wait）によるシステム全体のレスポンス低下を招きます。中・上級者が目指すべきは、x86_64アーキテクチャを搭載し、メモリ増設が可能なモデル、あるいは自作NAS（Custom Build）による構成です。

具体的に、運用規模に応じた推奨スペックと製品例を挙げます。軽量なサービス（AdGuard Home, Vaultwarden, Uptime Kuma等）を5〜10個動かす程度であれば、Synology DS923+（AMD Ryzen R1600搭載）にメモリを32GBまで増設した構成で十分です。しかし、メディアサーバー（Plex, Jellyfin）でのハードウェアトランスコーディングや、大規模なドキュメント管理（Paperless-ngx）を行う場合は、Intel Quick Sync Video (QSV) を搭載したCPUが必須となります。QNAP TS-464などのIntel Celeron N5095/N5105搭載機は、低消費電力ながら強力なGPU性能を持ち、4K動画のトランスコードを低負荷で処理できます。

さらに、本格的なセルフホスト環境（30サービス以上）を構築する場合、市販NASではCPU性能が不足します。ここでは、AMD Ryzen 9 7900X (12C/24T, TDP 170W) や Intel Core i7-14700K を搭載した自作サーバーに TrueNAS Scale を導入するパターンが最適解となります。この構成では、DDR5-5600メモリを128GB搭載し、NVMe Gen5 SSD（Crucial T705 2TB等）をDockerのルートディレクトリ（/var/lib/docker）に割り当てることで、コンテナの起動時間やデータベースのクエリ速度を劇的に向上させることが可能です。

以下に、運用規模別のハードウェア構成案をまとめます。

• ライトユーザー（5〜15サービス）
  • CPU: AMD Ryzen R1600 / Intel Celeron N5105
  • RAM: 16GB 〜 32GB (DDR4)
  • Storage: SATA SSD 500GB (OS/App) + HDD (Data)
  • 消費電力: アイドル時 15W 〜 30W
• パワーユーザー（15〜40サービス）
  • CPU: Intel Core i5-13500 / Ryzen 5 7600
  • RAM: 64GB (DDR5)
  • Storage: NVMe Gen4 SSD 2TB (App/Cache) + HDD RAID-Z2
  • 消費電力: アイドル時 40W 〜 70W
• プロフェッショナル/ホスト（40サービス〜）
  • CPU: AMD Ryzen 9 7900X / Threadripper 7000シリーズ
  • RAM: 128GB 〜 256GB (ECC DDR5)
  • Storage: NVMe Gen5 SSD (Mirrored) + Enterprise SAS HDD
  • 消費電力: アイドル時 80W 〜 150W

特に注意すべきは、ストレージのI/O性能です。HDD上のディレクトリを直接ボリュームマウントしてデータベース（MySQL, MongoDB等）を動かすと、ランダムアクセス性能の低さから、コンテナの応答速度が数百msec単位で遅延します。必ずNVMe SSDをキャッシュまたは専用ストレージプールとして用意し、Dockerのデータディレクトリをそこに配置することが、快適な運用への最短ルートとなります。

実装時のハマりどころとトラブルシューティング

Docker ComposeをNASに導入する際、最も多くのユーザーが直面するのが「権限（Permissions）」の問題です。NASのOS（DSMやQTS）は独自のユーザー管理体系を持っており、Dockerコンテナ内のrootユーザーが作成したファイルが、NASの共有フォルダ上では所有者不明（UID 0）となり、GUIやSMB経由で編集・削除できなくなる現象が発生します。これを回避するためには、compose.yaml内で環境変数 PUID と PGID を明示的に指定する必要があります。

例えば、NAS上のユーザー「docker-user」のUIDが1026、GIDが100であれば、以下のように記述します。

environment:
  - PUID=1026
  - PGID=100

これにより、コンテナ内のプロセスがNAS上の特定ユーザーとして動作し、ファイル権限の不整合を防ぐことができます。これを怠ると、バックアップソフトがファイルを読み込めなかったり、アプリのアップデート時に設定ファイルが上書きされず、更新が反映されないといった事態に陥ります。

次に、ネットワーク構成における「ポート競合」と「Macvlan」の選択です。NAS自体の管理画面（ポート80, 443）と、Docker上のリバースプロキシ（Traefik等）が同じポートを奪い合うため、NAS側の管理ポートを変更するか、DockerコンテナにNASとは別の独立したIPアドレスを割り当てる「Macvlanネットワーク」を利用する必要があります。Macvlanを使用すれば、NASのIPが 192.168.1.10 であっても、コンテナに 192.168.1.11 などの個別のIPを付与でき、ポート競合を完全に回避できます。ただし、Macvlan利用時はホスト（NAS）とコンテナ間の通信がデフォルトで遮断されるため、別途ブリッジインターフェースを作成する高度な設定が求められます。

また、リソース制限（Resource Limits）の設定を忘れると、特定のコンテナがメモリリークを起こした際にNAS全体がフリーズし、SSH接続すら不能になる「OOM (Out of Memory) Killer」の餌食になります。以下のチェックリストを用いて、各サービスの制限値を設定することを推奨します。

• メモリ制限 (mem_limit):
  • 軽量ツール（Uptime Kuma等）: 256MB 〜 512MB
  • 中規模アプリ（Nextcloud, Gitea等）: 1GB 〜 2GB
  • 重いアプリ（Home Assistant, GitLab等）: 4GB 〜 8GB
• CPU制限 (cpus):
  • 基本的に制限なしで良いが、バッチ処理系は 0.5 (50%) などに制限し、ホストの応答性を確保する
• 再起動ポリシー (restart):
  • unless-stopped を基本とし、NAS再起動時に自動でサービスが復帰するように設定する
• ログローテーション:
  • max-size: "10m" などを指定し、ログファイルが数GBに膨れ上がりストレージを圧迫するのを防ぐ

パフォーマンス最適化と運用の自動化

複数サービスをComposeで一元管理する体制が整ったら、次は「運用コストの削減」と「パフォーマンスの極限化」に注力します。コンテナ数が増えると、個別のアップデート作業に膨大な時間がかかります。ここで導入すべきが Watchtower です。WatchtowerはDockerソケットを監視し、イメージの新しいバージョンがレジストリに公開されると、自動的にコンテナを停止・更新・再起動してくれるツールです。ただし、破壊的変更を含むアップデートでサービスが停止するリスクがあるため、本番環境では WATCHTOWER_NOTIFY を設定し、DiscordやSlackに通知を飛ばす運用が定石です。

ストレージパフォーマンスの最適化については、ファイルシステムの選択が重要です。BtrfsやZFSなどのコピーオンライト（CoW）ファイルシステムは、Dockerのレイヤー構造（Overlay2）と相性が悪く、書き込み増幅（Write Amplification）が発生してSSDの寿命を縮め、パフォーマンスを低下させることがあります。これを防ぐには、Dockerのデータ保存先ディレクトリに対して「CoWを無効化」する設定を適用してください。Synology DSMの場合、共有フォルダ作成時に「このフォルダでデータチェックサムを有効にする」のチェックを外すことで、CoWを回避し、DBのI/O速度を向上させることが可能です。

また、監視体制の構築により、リソースの「死角」をなくします。Prometheus と Grafana を組み合わせ、cadvisor を介してコンテナごとのCPU・メモリ使用率を可視化することで、どのサービスがリソースを過剰消費しているかを一目で判断できます。例えば、特定の時間帯にメモリ使用率が 90% を超える場合、スワップ領域の拡張（zRAMの導入）や、ハードウェア的なメモリ増設のタイミングを定量的に判断できます。

最後に、運用の自動化とバックアップの最適化について、以下の構成を推奨します。

特に、バックアップにおいては「コンテナを止めてからバックアップを取る」か、「スナップショット機能を利用する」ことが不可欠です。稼働中のデータベースファイルを単純にコピーすると、ファイルが不整合（Corrupted）な状態で保存されるリスクがあります。docker-compose exec を利用して mysqldump などの論理バックアップを定期的に実行し、そのダンプファイルをNASの外部ストレージに同期させるパイプラインを構築することが、プロフェッショナルなNAS運用における最終到達点となります。

NAS Docker運用におけるハードウェア・プラットフォームの徹底比較

Docker Composeを用いて多数のサービスを一元管理する場合、ベースとなるNASのハードウェア性能とOS（ハイパーバイザ）の選択が運用の安定性を決定づけます。特に2026年現在のトレンドでは、単なるファイルサーバーとしてのNASではなく、軽量な仮想化基盤としての側面が重視されています。

管理するコンテナ数が10個未満であればエントリーモデルで十分ですが、30個を超える中規模運用や、NextcloudやPlexなどのリソース消費が激しいサービスを組み込む場合は、CPUのマルチスレッド性能とメモリ帯域がボトルネックとなります。以下に、主要なプラットフォームの特性をまとめました。

表1：NAS OS・プラットフォーム別 Docker運用特性比較

SynologyやQNAPのような商用NASは、GUIベースの管理ツールが充実しており、導入ハードルは極めて低いです。しかし、docker-compose.yamlを直接編集して高度なネットワーク設定やボリュームマウントを行う場合、OS側の制限（権限管理やパスの制約）に直面することがあります。一方、TrueNAS SCALEやUnraid、あるいは純粋なLinuxサーバーは、Docker Composeのフル機能を制限なく利用でき、特にZFSによるスナップショット機能を活用したコンテナデータのバックアップ運用において圧倒的な優位性を持ちます。

次に検討すべきはCPUの選択です。2026年現在、省電力性と性能のバランスからIntel N100などの効率コア搭載モデルが人気ですが、コンテナ数が増えると計算資源の奪い合いが発生します。

表2：Dockerホスト向けCPU選択肢とパフォーマンス指標

Intel N100はアイドル消費電力が極めて低いため、24時間365日稼働のNASに最適ですが、シングルスレッド性能に限界があるため、重いJavaベースのアプリ（例：一部の管理ツールやMinecraftサーバー）を動かすとCPU使用率が容易に100%に達します。対してRyzenやCore i5クラスを選択すれば、Docker Composeのプロファイル機能を活用し、時間帯によって起動するサービスを切り替えるような高度な運用も余裕を持って行えます。

管理面では、docker-compose.yamlを記述した後の「可視化」が重要です。CLIでの操作に慣れている上級者であっても、リソース監視やログ確認のためにGUIツールを併用するのが一般的です。

表3：Docker管理ツール（GUI）の機能比較

Portainerはデファクトスタンダードとなっており、Composeファイルを「Stacks」として管理できるため、NAS上の複数ディレクトリに分散したdocker-compose.yamlを一元的に制御するのに最適です。一方、CasaOSはDockerを意識させない「アプリストア」的な体験を提供するため、技術的な詳細よりも利便性を重視するユーザーに向いています。ただし、複雑なネットワークブリッジやMacVLANの設定を行う場合は、最終的にDocker CLIでの操作が不可欠となります。

メモリ（RAM）は、Docker運用においてCPU以上に重要なリソースです。特にZFSなどの高度なファイルシステムを採用しているNASでは、ARC（Adaptive Replacement Cache）がメモリを大量に消費するため、コンテナに割り当てるメモリ量とのトレードオフが発生します。

表4：搭載メモリ量による運用可能スケールの目安

メモリ不足が発生すると、LinuxカーネルのOOM Killerが作動し、Dockerコンテナがランダムに強制終了される事態を招きます。特にMariaDBやPostgreSQLなどのデータベース系コンテナ、およびElasticsearchのようなJava VMベースのアプリを導入する場合は、1コンテナあたり1GB〜4GBのメモリを確保して計算する必要があります。

最後に、Dockerコンテナのデータ保存先（ボリューム）の物理的なストレージ構成についてです。データベースのI/O性能は、NAS全体のレスポンスに直結します。

表5：ストレージメディア別 Dockerボリューム性能比較

Docker Composeで管理するサービスの多くは、小さなファイルの頻繁な読み書き（ランダムI/O）を発生させます。これをHDD上のディレクトリにマウントすると、I/O Waitが発生し、CPU性能が十分であってもシステム全体が「もっさり」とした挙動になります。2026年現在のベストプラクティスは、OSとDockerボリューム（/var/lib/dockerおよびComposeのデータディレクトリ）をNVMe SSDに配置し、大容量のデータ（映画、写真、バックアップ）のみをHDDプールにマウントするハイブリッド構成です。

よくある質問

Q1. NASにDocker環境を構築する場合、メモリ増設のコストはどの程度見込むべきですか？

Synology DS923+などのモデルを例に挙げると、標準の4GBでは不足しがちです。16GBのDDR4 ECCメモリを1枚追加して合計20GBにする場合、純正品や互換メモリで約15,000円〜25,000円程度の予算が必要です。特にNextcloudやHome Assistantなど、メモリ消費量が多いコンテナを5つ以上同時に動作させる場合は、最低でも16GB以上の物理メモリを確保することを強く推奨します。

Q2. 24時間稼働させる場合の電気代への影響はどのくらいありますか？

CPUのTDP（熱設計電力）に依存します。Intel N100搭載の低電力NAS（TDP 6W）であれば、アイドル時の消費電力は10W以下に抑えられ、月額の電気代は数百円程度です。一方で、Core i5-13500（TDP 65W）を搭載した自作NASで多数のコンテナをフル稼働させると、平均消費電力が30W〜50Wに跳ね上がり、2026年現在の電気料金単価（約31円/kWh）で計算して月額1,500円〜2,300円程度のコスト増となります。

Q3. GUI管理ツールのPortainerとdocker-compose CLIのどちらを使うべきですか？

運用スタイルによります。Portainer CEはWeb画面からコンテナの停止・再起動やログ確認を直感的に行えるため、不慣れな方や管理数10個程度の環境に適しています。一方、100サービス規模の運用やGitOps（GitHub等での構成管理）を導入する場合は、docker compose up -dによる一括更新やシェルスクリプトでの自動化が可能なCLI運用が圧倒的に効率的です。

Q4. TrueNAS SCALEとSynology DSM、Docker運用のしやすさはどちらが上ですか？

自由度を求めるならTrueNAS SCALEです。Debianベースであり、カスタムアプリの導入やK3s（軽量Kubernetes）への移行パスが明確です。対してSynology DSMは、独自の「Container Manager」により、初心者でも数クリックでComposeファイルを展開でき、OSレベルでのバックアップ統合が強みです。ただし、詳細なネットワーク設定（macvlan等）を追い込む場合は、TrueNASの方が柔軟に制御可能です。

Q5. Raspberry Pi 5などのARM64環境で、x86_64専用のイメージを動かせますか？

基本的には不可能です。DockerイメージはCPUアーキテクチャに依存するため、Raspberry Pi 5（ARM64）ではlinux/arm64対応のイメージが必要です。一部のツール（qemu-user-static）を使えばx86_64イメージをエミュレーション動作させられますが、パフォーマンスは本来の10%以下に低下し、CPU使用率が100%に張り付くため、実運用には向きません。必ずmulti-arch対応のイメージを選択してください。

Q6. compose.yamlの「version」記述は今でも必要なのか、規格はどうなっていますか？

最新のDocker Compose V2仕様では、ファイル先頭のversion: '3.8'といった記述は「非推奨（Optional）」となり、省略しても問題ありません。Compose V2は仕様を統合しており、記述がなくても自動的に最新の仕様で解析されます。ただし、古いDocker Engine（v20.10以前）を搭載したNASで動作させる場合は、互換性維持のためにversion: '3'等の明記が必要なケースがあります。

Q7. HDDのみのNASでDockerを動かすと動作が重いのですが、原因は何ですか？

原因の多くはディスクI/Oのボトルネック（I/O Wait）です。HDDのランダムアクセス速度は数百IOPS程度ですが、Dockerコンテナのログ書き込みやデータベース（M[aria](/glossary/aria-multimodal-llm)DB等）の更新が重なると、ディスク待ちが発生しシステム全体が停滞します。/var/lib/dockerや設定フォルダを、読込速度 3,500MB/s 以上のNVMe SSD（M.2）へ移行させるだけで、コンテナの起動時間は30秒から2秒程度まで劇的に短縮されます。

Q8. docker-composeで管理している大量のコンテナを効率的にバックアップする方法は？

コンテナ本体ではなく「データボリューム」と「compose.yaml」をバックアップしてください。具体的には、/opt/stacksなどの設定ディレクトリを、ResticやBorgBackupなどの重複排除対応ツールを用いて外部ストレージへ保存します。例えば500GBのデータがあっても、差分バックアップであれば1回あたり数GBの転送量で済み、万が一NASが故障しても、新環境でdocker compose up -dを実行するだけで数分で復旧可能です。

Q9. 今後、DockerからPodmanやKubernetesに移行すべきタイミングはいつですか？

「ルート権限なし（Rootless）」でのセキュリティ強化が必要になった時や、複数台のNASを束ねてクラスター化したい時が移行タイミングです。Podmanはデーモンレスで動作するため、メモリ消費量を数百MB削減でき、セキュリティリスクを低減できます。また、3台以上のサーバーで負荷分散（ロードバランス）を行いたい場合は、K3sへの移行を検討してください。単一NASでの運用であれば、[Docker Compose](/glossary/pose-context-window-extension)が現状最もコストパフォーマンスに優れています。

Q10. AIツール（LLM）を使ってcompose.yamlを最適化することは可能ですか？

はい、非常に有効です。例えば「32GBのRAMを搭載したNASで、以下の10サービスを動作させるための最適なリソース制限（deploy.resources.limits）を提案して」と指示することで、メモリリークを防ぐmem_limit: 512Mなどの具体的な数値を算出させることができます。これにより、特定のコンテナがメモリを食いつぶしてOSごとハングアップする（OOM Killerの作動）リスクを大幅に軽減でき、安定稼働率を向上させられます。

まとめ

NAS上でのDocker運用を効率化するための要点は以下の通りです。

• 個別のdocker runコマンドではなく、docker-compose.yamlによる宣言的な定義でサービスを一元管理する
• NASのシステム安定性を確保するため、deploy.resources.limitsでコンテナごとのメモリ上限（例：512MB〜2GB）やCPU使用率を厳格に制限する
• データの永続化にはNASの共有フォルダ（/volume1/docker/...等）を適切にバインドマウントし、バックアップ運用を容易にする
• サービスごとにカスタムブリッジネットワークを構築し、不要なポート開放を避けて内部通信のセキュリティを高める
• Nginx Proxy ManagerやTraefikなどのリバースプロキシをフロントに配置し、ポート番号指定ではなくサブドメインによるアクセス環境を整備する
• docker compose pullおよびup -dによるワークフローを確立し、イメージの更新と再起動を最小限のダウンタイムで完結させる

まずは現在のdocker-compose.yamlにリソース制限の設定を追加し、NAS全体の負荷状況を確認してください。管理するサービスが10件を超える場合は、機能ごとにYAMLファイルを分割し、ディレクトリ構造を整理することをお勧めします。