> [!abstract] 概要(原文 abstract の日本語訳) > 軽量にアプリケーションを仮想化する技術としてコンテナは最近成功を収めており、特にクラウド上でのアプリケーション管理において顕著である。コンテナクラスタの管理が不可欠となる場面が多く、構築とデプロイのオーケストレーションが中心的問題となる。この新興トピックは研究者の関心を集めているが、これまでこの研究を統合する secondary study は存在しなかった。本研究は、コンテナとそのオーケストレーション、特にクラウド領域でのこの技術の応用に関する既存研究を、体系的に同定・分類・比較することを目的とする。46 件の選定論文に対する体系的マッピング研究を実施し、特性化フレームワークに基づいて分類・比較した。結果として、コンテナオーケストレーション領域における合意済みおよび新興の関心事を、クラウドコンテキスト内で位置付けつつ議論し、クラウドプラットフォーム・マイクロサービス・継続的開発の現代的関心へも近接させた。 ## 論文情報 - タイトル: Cloud Container Technologies: A State-of-the-Art Review - 著者: [[Claus Pahl]]([[Free University of Bozen-Bolzano]])・[[Antonio Brogi]]([[University of Pisa]])・[[Jacopo Soldani]]([[University of Pisa]])・[[Pooyan Jamshidi]]([[Carnegie Mellon University]]) - 媒体: IEEE Transactions on Cloud Computing, Vol. 7, No. 3, pp. 677-692 - 発表年: 2017 年 5 月オンライン公開、2019 年 7-9 月号正式掲載 - 投稿: 2016-10-25 / 改訂: 2017-03-10 / 受理: 2017-04-22 - DOI: 10.1109/TCC.2017.2702586 - IEEE document ID: 7922500 - ページ数: 16 - データ公開先: `http://www.inf.unibz.it/~cpahl/CCT/Cloud_Container_Technology-a_State-of-the-Art_Review.htm` ## 概要 46 件の primary studies(2007-2016)に対する体系的マッピング研究(Systematic Mapping Study; SMS)。コンテナ・コンテナオーケストレーションのクラウド領域での応用研究について、Population/Intervention/Comparison/Outcome(PICO)に基づき検索式 `(cloud OR PaaS) AND (container) AND (orchestrate OR (cluster OR manage))` で抽出し、4 軸の特性化フレームワーク(Technology Stack・Management Services・Architecture Setting・Tools/Platforms/Technology)に分類した。結果として、Docker・LXC が支配的ながら分野はまだ形成期にあり、ソリューション提案中心で実証研究が不足することを定量化した。 ## 問題設定 - **目的**: クラウドコンテナ技術の現状を統合し、研究の成熟度・トレンド・ギャップ・将来方向を識別する secondary study を提供する。これまでに同等の体系的レビューは存在しなかった。 - **対象期間**: 2007 年(LXC 出現)から 2016 年末まで。 - **データ源**: IEEE Xplore・ACM Digital Library・Science Direct・ISI Web of Science・SpringerLink・INSPEC・EI Compendex・DBLP。インデックス遅延を補うため Google Scholar も初期選択で活用。 - **PICO 分析**: - Population: 実践的動機(RQ1)・構造とアーキテクチャ(RQ2 由来)・管理手法と技術(RQ3 由来)・研究課題と将来方向(RQ4)。 - Intervention: 特性化・内部/外部検証・データ抽出・統合。 - Comparison: primary studies を特性化フレームワークにマッピングして比較。 - Outcome: 特性化フレームワーク。 ## 提案手法 ### 体系的マッピング研究プロセス(3 ステップ) 1. **計画**: ニーズの同定・研究質問の特定・プロトコルの定義。 2. **実施**: primary studies の選定・データ抽出と統合。 3. **文書化**: 観察の記録・脅威の分析・報告。 各ステップは評価フェーズを伴い、Petersen ら(2008)のプロセスをベースに、[[Claus Pahl]] らの過去 SLR 経験([4][5])に基づくプロトコルを構築。 ### 研究質問(RQ) | RQ | 内容 | 動機 | |---|---|---| | RQ1 (Research Application) | なぜどのクラウド活動で・どのように適用されたか | コンテナは IaaS の VM 代替であると同時に PaaS/SaaS のアプリケーションパッケージング機構でもある | | RQ2 (Research Distribution) | どのソース・いつ発表されたか | ソフトウェア工学・分散システム・OS など複数コミュニティに跨る | | RQ3 (Maturity) | 分野の成熟度 | 研究アプローチと評価方法から分野の成熟度を判定 | | RQ4 (Trends) | 関心事と将来研究 | リサーチギャップと将来方向の同定 | RQ1 はさらに 5 つのサブ質問に分解: (1) 動機、(2) 技術スタック、(3) 管理サービスとクラウド設定とアーキテクチャ、(4) 技術空間、(5) アプリケーションドメイン。 ### 検索式の構築 PICO の Population-Technology に基づく検索式: `(cloud OR PaaS) AND (container) AND (orchestrate OR (cluster OR manage))`。Product perspective(Docker OR Kubernetes OR Diego OR Rocket OR LXC)や Intervention(experimental OR empirical)などは初期段階では絞り込みすぎないために除外し、後の inclusion/exclusion 段階で評価。 ### スクリーニングと選定 - **Initial Selection**: タイトルと abstract をスクリーニング。包含基準は「abstract が containers に明示的に言及し、研究焦点への貢献が確認できる」こと。除外基準は「container 文脈外」「peer-review なし」「abstract/blog/プレゼンテーションのみ」。 - **Final Selection**: 評価アプローチの詳細とコンテナオーケストレーション/ツール対応の検証スキャン。最終的に 46 件を選定。 - **品質評価**: peer-review されたコンテンツで、内容がタイトル・abstract と一致するものを優先。 ### 分類フレームワーク(Table 3) | カテゴリ | 内容 | |---|---| | Contribution Type | Solution proposal (Architecture/Framework/Methodology/Library)・Evaluation research・Validation research・Experience report・Review (SOTA/Technology/SLR) | | Evaluation Method | Case study・Mathematical proof・Experience report・Example application・Controlled experiment | | Forum | Journal・Magazine・Conference/Workshop | | Technology Stack | Virtualisation Basics(VM・isolation・hypervisor・OS・control group・namespace)・Container Construction(provisioning・packaging・image building)・Container Management・Cluster Construction・Cluster Management | | Management Services | Architecture/Construction・Execution Management・Quality/SLA Management(monitorable/non-monitorable/testable) | | Architecture Setting | Deployment Stage(requirement・design・deployment・migration・DevOps)・Architecture Concern(flexibility・modularity・adaptiveness・integration・interoperability・quality)・Cloud Setting(single/private・multi/cross/hybrid・edge/fog・hosted・IoT-cloud・clustered; IaaS/PaaS/SaaS/XaaS) | | Tools/Platforms/Technology | Docker・Kubernetes・Diego・Rocket・CoreOS・LXC・OpenVZ・STXXL・MCSTL・Intel TBB・Xen・OVF・EAC | | Container Type | Container・Cluster manager・Unikernel | | Domain | Computing(big data・video・workflow・HPC・Web・disk-intensive・resource virtualisation)・Non Computing(health・physics/science・media・education) | | Community | Distributed Systems・Cloud and Big Data・Software Engineering・Autonomic Computing・Network/OS・Application | ## 新規性 - **secondary study としての位置付け**: 既存の technology review([S3][S4][S6][S9][S19][S17])は 6 件あるが、いずれも体系的な文献カバレッジを欠く。本研究は protocol ベースで再現可能な mapping study を提示する初の試み。 - **特性化フレームワークの提案**: 既存研究の比較・分類のための再利用可能な 4 軸フレームワークを定義し、外部専門家(5 名・3 機関・3 か国)による検証を受けて修正した。 - **時系列俯瞰**: LXC 出現(2007)から Docker 普及(2013-)を経たコンテナ研究の成長軌跡を、46 件の年次分布として可視化した。 ## 実験設定 - **データ抽出**: スプレッドシートで管理。分類スキームは抽出過程で進化(カテゴリの追加・統合・分割)し、外部専門家からのフィードバックを取り込んだ。 - **可視化**: トレンド(年次)・フォーラム・頻度(トピック)・Technology Stack・Architecture/Management Services・Tools の度数分布を円グラフ・棒グラフ・バブルチャートで提示(Fig. 4-19)。 - **マップ**: 一般マップ(generic)と技術固有マップ(domain-specific)を分離して提示。 ## 実験結果 ### 時系列分布 - 2007 年に Soltesz ら(`Container-based operating system virtualisation: a scalable, high-performance alternative to hypervisors`、[S35])が最も引用された pioneer 論文として現れる。 - LXC 出現から数年は研究は少なく、Docker 出現(2013)以降に研究が急増。2015 年が現在ピーク(2016 年データはインデックス遅延で過小評価)。 ### 出版フォーラム - コミュニティ分布: Cloud and Big Data が主、続いて Distributed Systems・Network/OS・Software Engineering・Autonomic Computing・Application。 - フォーマット: conference/workshop が支配的、journal/magazine は少数(主にサーベイ)。形成期分野の典型的パターン。 ### 研究方法論 - Contribution type: Solution proposal が支配的、validation/evaluation は少ない。 - Evaluation method: 数学的証明や詳細な experience report は皆無。サンプル実装としての experience report と controlled experiment が一部。 - Solution proposals が技術主導であり、理論的基礎を欠くことを示唆。 ### Technology Stack の詳細 - **Virtualisation Basics**(Count): virtualisation/VM (20), isolation (14), OS (5), control group (5), namespace (5), hypervisor (4)。isolation はセキュリティ懸念から注目される。 - **Container Construction**: construction (14), provisioning (13), application packaging (10), image building (5)。functional composition 寄り。 - **Container Management**: management (22), application execution (18), communication (7)。operations 寄り。 - **Cluster Construction**: construction (8), definition (2)。 - **Cluster Management**: management (12), execution (5), communication (4)。 ### Management Services の詳細 - **Architecture/Construction**: construction/composition (10), interoperability/heterogeneity (7), topology (4), adaptivity (4), microservice architecture (4), integration (3)。 - **Execution Management**: orchestration (12), provisioning (10), start-up (7), load management (7), configuration (4), installation (4), scheduling (4), network address mapping (4), delivery (3), network management (3)。 - **Quality Management の 3 分割**(monitorable=56・non-monitorable=8・testable=6): - monitorable: performance (23), resource utilisation (13), startup time (10), elasticity (10), security (7), reliability (4), memory use (4), workload (3), size/volume (3), compliance (1)。 - non-monitorable: portability (5), interoperability (5), resilience (2)。 - testable: scalability (6), configurability (2), integration (1)。 ### Architecture Setting - Deployment Stage: deployment 中心(43)、requirements+design (17)、migration+DevOps (8)。 - Cloud delivery model: IaaS と PaaS がほぼ均等。IaaS は仮想化・オーケストレーション視点、PaaS はアプリケーションパッケージング視点。 - Container Type: container 中心、cluster は 2015 年以降に増加。 ### Tools/Platforms/Technology - **Docker と LXC が支配的**。Kubernetes・CoreOS・OpenVZ・Diego・Rocket が次点。Bernstein([S5])は Docker(スタートアップ)・Kubernetes(Google 主導)のガバナンス構造に懸念を示し、より中立なコラボレーション構造が共通パッケージング/デプロイ標準合意のために必要と論じる。 - VMware の [S8] が OVF ベースの標準化アプローチを示し、業界視点を補強。 ## 考察 ### 発見事項のまとめ - **形成期(formative stage)**: ソリューション提案中心で、検証研究・評価研究が少ない。journal 出版が限定的で、conference/workshop 中心の発信パターン。 - **デプロイ容易性が動機の主**: 大規模・自動的デプロイと管理の容易さがコンテナの主要な動機。軽量リソース管理よりもデプロイ容易性が優先される。 - **品質関心**: パフォーマンス(23)・リソース利用(13)・起動時間(10)・エラスティシティ(10)が支配的。SLA パラメータ(36)とインフラパラメータ(33)はステークホルダ視点が異なる(consumer vs provider)。 - **構築と管理の均衡**: フレキシビリティと自己適応性(27)、モジュール性と統合と相互運用性(24)が中核アーキテクチャ関心。DevOps と継続的開発への融合がトレンド。 - **クラスタオーケストレーションの台頭**: 2015 年中盤以降にクラスタ関連研究が急増。[[Kubernetes]]・Mesos の出現が Docker と同様の刺激を与えている。 - **エッジ/フォグへの拡張**: 単一基板デバイス上のコンテナと、それらのクラスタによる分散トポロジ管理がエッジ/IoT コンピューティングに適合([S9][S25][S26][S43][S44])。 ### 業界動向との接続 - **[[CNCF]](Cloud Native Computing Foundation)**: [[Kubernetes]] をコンテナクラスタオーケストレーション技術として採用し、ネットワーク・ストレージ・クラスタ管理を統合。本論文発表時点(2017)で形成途上であった CNCF エコシステムを位置付ける。 - **Borg([S21])の限界**: マルチジョブサービスを単一エンティティとして扱う first-class メカニズムが欠如している、と Verma ら(EuroSys 2015)が指摘。スケジューラ・admission control・垂直/水平オートスケーリング・再パッキング・周期ジョブ提出・ワークフロー管理・アーカイブを含む分散型管理が必要。 ### 障害管理(failure management)の欠落 - [S21] の Borg 経験報告にあるとおり、根本原因特定と異常イベント対応のためには、より良いリソース監視とログ解析が必要。本論文は障害管理を未解決領域として明示する(本 vault の [[根本原因分析]]・[[障害緩和]]・[[Fault Localization]] と直接接続する)。 ### 将来研究方向 - **DevOps アプローチによる継続的開発・デプロイの統合**: 開発と運用の分離を超えて、監視運用データを開発側にフィードバックする継続的プロセスが必要。 - **サーバーレスアーキテクチャと unikernel への進展**: VM → コンテナ → さらなる軽量化(unikernel・serverless)というトレンドの観察。 - **クラスタ空間でのオープンソース活性化**: Docker がコンテナ単体研究を活性化させたように、[[Kubernetes]] と Mesos がクラスタ空間で類似の活性化を起こすことが期待される。 - **エッジ/フォグコンピューティング**: クラスタリングを必要とするアーキテクチャ設定として、コンテナの相互運用性が貢献する。 ## 強み - **包括的かつ再現可能な手法**: PICO・検索式・包含/除外基準・分類フレームワークを明示し、外部専門家による検証を受けた SMS プロトコル。 - **4 軸分類フレームワークの汎用性**: Technology Stack・Management Services・Architecture Setting・Tools/Platforms/Technology は、コンテナ以外のクラウド技術にも再利用可能な視点を提供。 - **時系列俯瞰**: LXC 出現から Docker 普及までのコンテナ研究成長軌跡を年次分布で可視化。 - **データ公開**: 抽出データを `inf.unibz.it/~cpahl/CCT/` で公開し再現性を担保。 ## 弱点・限界 - **業界白書・ブログの除外**: 業界実践から生まれる革新を捕捉するメカニズムが欠如(Threats to the Relevance で著者自身が認識)。Docker・cloud-native アーキテクチャの一部 blog を補完的に参照したが、protocol ベースの体系的取り込みではない。 - **検索式の広範化によるノイズ**: コミュニティが異なる用語を用いるため広範囲な検索が必要となり、絞り込みコストが大きい。手動スクリーニングが残る。 - **2016 年カットオフ**: クラウドネイティブ・サービスメッシュ・GitOps・eBPF などの後続発展は対象外。本 vault の [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] や [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]] のような近年研究で補完が必要。 - **journal カバレッジの偏り**: peer-reviewed journal/magazine を一部含めるが、systematic literature review(SLR)の厳密さには達していないと著者自身が認める。 - **数学的基礎の欠如**: primary studies の全てが技術的解決策で、理論的基礎を持つアプローチは皆無。著者は今後の研究方向として理論的基礎付けを指摘。 ## 関連 - 概念: [[コンテナオーケストレーション]] / [[体系的マッピング研究]] / [[マイクロサービスアーキテクチャ]] / [[コンテナ配置最適化]] / [[サーバーレスアーキテクチャ]] / [[プラットフォームエンジニアリング]] - エンティティ: [[Claus Pahl]] / [[Antonio Brogi]] / [[Jacopo Soldani]] / [[Pooyan Jamshidi]] / [[Free University of Bozen-Bolzano]] / [[University of Pisa]] / [[Carnegie Mellon University]] / [[Docker]] / [[LXC]] / [[Kubernetes]] / [[CNCF]] - 関連 source: [[@2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement]] / [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]]