マルチテナントDockerアーキテクチャの設計：適切な分離レベルの選択

概要

マルチテナントのDockerホスティングでは、コスト、複雑さ、分離のバランスが求められます。共有コンテナは安価ですがコンテナエスケープのリスクがあり、テナントごとに別のスタックを用意すると強力な分離が得られる代わりにコストが高くなります。この記事では、単一のDockerデーモンと名前空間を使用する方法、テナントごとのDocker-in-Docker、テナントごとの個別VMという3つの一般的なアーキテクチャを説明します。テナントの要件を評価し、リソース制限を実装し、読み取り専用ファイルシステムを使用してコンテナを堅牢化する方法を学びます。また、KubernetesやDocker Swarmなどのオーケストレーションツールを使用してマルチテナントデプロイメントを管理する方法も説明します。最後には、ユースケースに適した分離レベルを選択するための意思決定フレームワークを習得できます。ただし、パフォーマンスのオーバーヘッドや運用の複雑さなどの注意点もあります。結論として、共有カーネルの分離は低リスクのテナントには許容されますが、機密性の高いワークロードには強力な分離（共有カーネルなし）が不可欠です。

Docker上でマルチテナントのSaaSプラットフォームを実行する場合、最大のアーキテクチャ上の決定は、テナント間にどの程度の分離を適用するかです。分離が少なすぎると、1つのコンテナが侵害されただけで全顧客ベースのデータが漏洩する可能性があります。分離が多すぎると、コンテナが約束したコストと運用上のメリットが損なわれます。

この記事では、実践的な意思決定フレームワークを提供します。テナントの信頼レベルを評価し、分離アーキテクチャを選択し、コンテナを堅牢化し、大規模にオーケストレーションします。具体的なトレードオフと安全にデプロイするためのステップバイステップの計画を手に入れることができます。

ステップ1：テナントの信頼と機密性を評価する

すべてのテナントが同じではありません。無料利用層のユーザーは共有インフラストラクチャで問題ないかもしれませんが、エンタープライズクライアントは強力な保証を求めます。テナントを3つの層に分類します。

• 低信頼（例：匿名トライアルユーザー）：最小限の分離で許容、悪用のリスクが最も高い。
• 中信頼（例：検証済み顧客）：偶発的な妨害を防ぐために適度な分離が必要。
• 高信頼（例：SLA付きの契約）：強力な分離が必要 – 場合によっては個別のVM。

また、データの機密性も考慮します。テナントが個人情報や財務データを保存する場合は、より強力な分離を選択します。この分類が以降のすべての決定を導きます。

ステップ2：分離アーキテクチャを選択する

オプションA：共有DockerデーモンとLinux名前空間（最も安価、最も弱い分離）

すべてのテナントが同じホスト上、同じDockerデーモンのコンテナとして実行されます。分離は完全にカーネルの名前空間とcgroupに依存します。これがデフォルトのDockerモデルです。

長所： オーバーヘッドが最小、管理が容易、特別なツールは不要。内部ツールや重要でないマルチテナンシーに最適。

短所： カーネルの脆弱性により分離が破られる可能性があります。悪意のあるテナントがコンテナエスケープを試みる可能性があります。リソースの競合は現実的で、1つのノイジーネイバーが他のテナントをリソース不足にする可能性があります。

使用すべき場合： 一時的なデータを持つ低信頼テナント（デモ環境やCI/CDランナーなど）。

オプションB：テナントごとのDocker-in-Docker（中程度の分離、適度なコスト）

各テナントはコンテナ内に独自のDockerデーモン（Docker-in-Docker – DinD）を持ちます。これにより、個別のコンテナライフサイクルが提供され、あるテナントが別のテナントのコンテナを見ることができなくなります。

長所： 共有デーモンよりも優れた分離。各テナントは独自のDocker Composeスタックを実行できます。テナントが独自のコンテナをビルドおよび管理する必要がある場合に便利。

短所： DinDには既知の問題があり、ネストされたストレージドライバーが問題を引き起こす可能性があり、ホストカーネルは依然として共有されます。ネストされたレイヤーによるパフォーマンスのオーバーヘッドは10〜20％になる可能性があります。セキュリティは完全ではありません。DinDコンテナからのコンテナエスケープは依然としてホストに到達します。

使用すべき場合： 独自のサービスを構成する必要がある中信頼テナント（ユーザーがカスタムWebアプリをデプロイできるプラットフォームなど）。

オプションC：テナントごとの個別VM（最も強力な分離、最も高いコスト）

各テナントは専用の仮想マシン上で実行され、そのVM内にDockerがあります。ハイパーバイザーがハードウェアレベルの分離を提供し、カーネルの共有は一切ありません。

長所： 最も強力な分離 – コンテナエスケープがあってもVMにのみ到達し、他のテナントには影響しません。PCI-DSSやHIPAAなどのコンプライアンス要件を満たします。パフォーマンスの分離はほぼ完全です。

短所： 高いオーバーヘッド（テナントごとに完全なOS）、プロビジョニングが遅い、管理の複雑さが増す。コンテナの密度の利点が失われます。

使用すべき場合： 機密データを持つ高信頼テナント、または侵害が壊滅的となる可能性があるテナント。

ステップ3：すべてのアーキテクチャでコンテナを堅牢化する

選択したアーキテクチャに関係なく、以下のセキュリティプラクティスを普遍的に適用します。

• 信頼できる最小限のベースイメージ（例：Alpine、distroless）を使用して攻撃面を減らす。
• コンテナを非rootとして実行する – コンテナ内でrootとして実行しない。DockerfileでUSERを設定する。
• コンテナ仕様で読み取り専用のルートファイルシステムを有効にする。書き込み可能なディレクトリはデータ用にのみマウントする。
• --memory、--cpusでリソース制限を設定して、ノイジーネイバーの問題を防ぐ。
• ネットワーキングを制限する：ユーザー定義のブリッジネットワークを使用し、必要なポートのみを公開する。

マルチテナントシナリオでは、以下も実装します。

• ゲートウェイでのテナントごとのAPIレート制限。
• すべてのコンテナアクションの監査ログ。

コンテナエスケープの防止について詳しくは、コンテナエスケープから防御するガイドを参照してください。

ステップ4：マルチテナントデプロイメントをオーケストレーションする

多数のコンテナを手動で管理するとすぐに手に負えなくなります。オーケストレーターを使用します。

• Docker Swarm：最もシンプルで、ネイティブなDocker統合、組み込みのロードバランシング、シークレット管理を提供します。小規模から中規模のデプロイメントに最適です。ラベルと制約を使用して、各テナントのスタックを専用ノードに配置できます。
• Kubernetes：名前空間、NetworkPolicy、PodSecurityPolicyを介したより高度な分離を提供します。ただし、かなりの複雑さが追加されます。マネージドKubernetes（GKE、EKS）を検討して運用負荷を軽減します。
• HashiCorp Nomad：Dockerおよび非コンテナワークロードをサポートする、より軽量な代替手段です。

本番環境対応のオーケストレーション設定については、Docker Composeを超えて：本番環境対応のコンテナ化アプリケーションのオーケストレーションをお読みください。

注意点とトレードオフ

• パフォーマンスのオーバーヘッド：DinDはCPU/メモリのオーバーヘッドが10〜15％増加する可能性があります。VMはベアメタルと比較して5〜10％のオーバーヘッドがありますが、コンテナよりも大きくなります。実際の負荷でテストしてください。
• 運用の複雑さ：個別のVMでは、OSのアップデート、ハイパーバイザーのパッチ、VMのライフサイクル管理が必要です。DinDはストレージドライバーの問題（overlay2内のoverlay2はサポートされていません。--storage-driver vfsを使用しますが、低速です）を引き起こします。
• コンプライアンス：PCI-DSSが必要な場合、共有カーネルアーキテクチャは一般的に受け入れられません。適切なセグメンテーションを備えたVMを使用します。
• コスト：共有Dockerデーモンはほとんど追加コストがかかりません。DinDはCPU/メモリが少し多くかかります。VMはライセンスとリソースのため、テナントあたり2〜5倍のコストになる可能性があります。

結論：意思決定フレームワーク

| 信頼レベル | 推奨アーキテクチャ | 主な注意点 | |------------|----------------------|------------| | 低信頼 | 共有Dockerデーモン | コンテナエスケープのリスクを受け入れる。レート制限と監査を実装。 | | 中信頼 | テナントごとのDinD | ネストされたストレージを処理。テナントごとのセキュリティグループを検討。 | | 高信頼 | 個別VMとDocker | 追加のコンピュートに予算を組む。VMプロビジョニングを自動化（例：Terraform）。 |

多くのSaaS企業では、ハイブリッドアプローチが有効です。無料層には共有デーモン、有料顧客にはDinD、エンタープライズクライアントにはVMを使用します。これにより、リスクの低い場所ではコスト効率を、重要な場所では強力な分離を実現できます。

分離はスペクトラムであり、二項選択ではないことを忘れないでください。目標は、データの価値とテナントの信頼性に保護レベルを合わせることです。セキュリティ要件を満たす最もシンプルなオプションから始め、必要に応じて進化させてください。

コンテナ構成のロックダウンに関する追加のベストプラクティスについては、Dockerを使用したWebアプリケーションのセキュリティ保護：分離とベストプラクティスの実践ガイドを参照してください。