ポイント: 仮想マシン (VM) は物理ハードウェアをエミュレートし、コンテナは孤立した環境で動作するモジュラーアプリケーションを提供し、効率とスケーラビリティを向上させます。VM はワークロードの移行に対して完全な OS の移行が必要で、リソースの浪費を招くのに対し、コンテナは複数のワークロードがリソースを共有できるため、開発のスピードを向上させます。
- VM はリソース集約型で、柔軟性が低い。
- コンテナはリソースの利用を最大化し、迅速な開発サイクルをサポートします。
仮想化は1970年代初頭にネットワークコンピューティングを変革し、近年のクラウドコンピューティング革命のような前例のないパラダイムシフトへの道を開きました。
最近では、コンテナ革命が同様の目標で登場しました：データセンター技術とアプリケーション開発の改善です。この技術は全く新しいものではありません。LXC や Solaris Zones などの Linux コンテナソリューションは、業界で10年以上使用されています。Google のような企業は、数年間独自のコンテナ技術を使用しています。（Googleは報告によれば、毎週20億のコンテナを開始しています！）
しかし、2013年にDockerが開発者に優しいコンテナソリューションとエコシステムを提供したとき、技術は本当に企業ITで traction を得ました。実際、私たちは従来の仮想化手法が完全にコンテナ化に置き換わる時代に向かっているかもしれません。
アプリケーション開発とソフトウェアリリースプロセスのためにコンテナベースの開発ソリューションを採用する前に、仮想マシンとコンテナの概念と操作を十分に理解していることを確認してください。この記事の終わりまでに、あなたは：
- VM とコンテナの概念と違いを理解する
- 両者の欠点を考慮する
- 重要なトレンドを探る
- コンテナの使い始めに関するヒントを得る
仮想マシンとは？
仮想マシン (VM)は、物理的なハードウェアまたはコンピューティングシステムの機能をエミュレートするソフトウェアプログラムとして最もよく説明されます。これは、ハイパーバイザーと呼ばれるエミュレーションソフトウェアの上で動作し、ソフトウェア環境で基盤となる物理的なハードウェアリソースの機能を複製します。これらのリソースはホストマシンと呼ばれることがありますが、ハイパーバイザー上で動作する VM は通常ゲストマシンと呼ばれます。
仮想マシンには、アプリを実行するために必要なすべての要素が含まれています。これには以下が含まれます：
- コンピューティング
- ストレージ
- メモリ
- ネットワーキング
- 仮想化システムとして利用可能なハードウェア機能
VM には、アプリを実行するために必要なシステムバイナリとライブラリも含まれている場合があります。しかし、実際のオペレーティングシステム (OS) は、ハイパーバイザーを使用して管理および実行されます。
[helix-video]
仮想マシンの動作
仮想化されたハードウェアリソースはまとめられ、VM 上で動作するアプリに提供されます。そして、アプリを基盤となる物理インフラストラクチャから切り離すための抽象化レイヤーが作成されます。これにより、物理ハードウェアを変更、アップグレード、またはスケールしてもアプリのパフォーマンスが妨げられることはありません。
VM は独立した PC として動作し、基盤となるハードウェアは異なるワークロードのために複数の独立した、孤立した VM を動作させることができます。VM の操作は通常リソース集約型であり、異なるモジュラー要素のアプリのために別の VM が使用されない限り、個々のアプリ機能が孤立した PC のような仮想化環境で実行されることは許可されません。アプリのワークロードが異なる仮想マシンまたは物理データセンターの場所間で移行する必要がある場合、OS 全体も一緒に移行する必要があります。
ワークロード操作が関連する VM に提供されるすべてのリソースを消費することはめったにありません。その結果、残りの未使用リソースは、すべての VM とワークロード全体に対するキャパシティプランニングおよび分配に組み込まれない場合があります。これにより、VM の大きな欠点が生じます：不正確なプランニングと重要なリソースの浪費です。仮想化は、データセンター内のハードウェアリソースの使用と分配を最適化するために特に開発されたにもかかわらずです。
現代のアプリと IT サービスは、次のことを促進するためにいくつかのモジュラー部分で開発されています：
- より迅速な開発とリリース
- 高いスケーラビリティ
- ビジネスと市場のニーズの変化に応じてアプリケーション開発を進化させる柔軟性
モノリシックアプリ開発の実践は人気を失いつつあり、組織はハードウェアの利用をさらに最適化するためのインフラストラクチャアーキテクチャソリューションを追求しています。これがまさにコンテナ化が発明され、人気を得た理由です。
コンテナとは？
コンテナ化は、OS レベルでの抽象化を作成し、アプリの個々のモジュラーおよび明確な機能が独立して動作できるようにします。その結果、複数の孤立したワークロードであるコンテナが、同じ物理リソースを動的に使用できます。
コンテナの技術的でない定義は次のようになります：軽量だが、コード、その依存関係、構成をすべて1つのイメージにまとめたソフトウェアのユニットです。コンテナは以下で実行できます：
- ベアメタルサーバー上
- ハイパーバイザー上
- クラウドインフラストラクチャ上
コンテナは、モジュラーアプリの機能に対する孤立した OS 環境として機能するために VM と共有するすべての必要な機能を持っていますが、1つの重要な違いがあります。Docker Engine のようなコンテナ化エンジンを使用すると、コンテナは同じホストシステムカーネル内にいくつかの孤立した OS 環境を作成します。これにより、アプリの異なる機能を実行するために他のコンテナと共有できるようになります。各コンテナのために開発または実行されるのは、バイナリ、ライブラリ、その他のランタイムコンポーネントだけです。これにより、VM と比較してリソース効率が向上します。
コンテナの利点
コンテナは、現代の分散アプリやマイクロサービスの開発、展開、およびテストに特に役立ち、同じホストマシン上で孤立した実行環境で動作できます。
コンテナ化を使用すると、開発者は異なる VM に異なるアプリコンポーネントを操作するためのアプリケーションコードを書く必要がありません。完全なアプリケーションコンポーネントは、他のアプリコンポーネントやソフトウェアに影響を与えることなく、孤立した環境内で完全に実行できます。ライブラリやアプリコンポーネント間の競合は、実行中には発生せず、アプリケーションコンテナは効率的にクラウドまたはデータセンターインスタンス間を移動できます。
セキュリティの問題
もちろん、すべてが順調というわけではありません。おそらくコンテナの最大の欠点はセキュリティの欠如です。2018年には、60%の組織がコンテナに特有のセキュリティインシデントを経験しました。Tripwire によると、通常のセキュリティの脆弱性、バグ、認証および認可の不備、さらには誤設定があります。つまり、潜在的な攻撃対象面は広いのです。
しかし、全体のスタック、ライフサイクル、パイプラインにセキュリティを持ち込むのはそれほど簡単ではありません。このため、調査に参加した組織のほぼ半数が、既知の脆弱性を持つコンテナをデプロイしたり、脆弱性をテストせずにデプロイしたことを認めています。
それでも、コンテナが指数関数的に成長し続ける中、より多くのチームが最初からDevOpsと SecOps を取り入れています。
アーキテクチャ：コンテナ対仮想マシン
主要な価値提案
アーキテクチャの違いは、IT 人員と企業に次の主要な価値提案を提供します：
- 継続的インテグレーション、デプロイメント、テスト。DevOps 主導の組織では、組織はコンテナを活用して、CI/CD パイプラインのプロセスを促進できます。コンテナは、一貫したインフラストラクチャ環境として動作し、開発者は物理リソース間でワークロードが移行する際に、毎回複雑な構成作業を行う必要がありません。
- ワークロードのポータビリティ。IT ワークロードは、アプリケーションコードに対する重要な構成変更や再作業を行うことなく、異なるインフラストラクチャインスタンスや仮想環境間で切り替えることができます。
- ソフトウェアの品質とコンプライアンス。アプリケーションの運用チャンクを提供する開発者とテスト担当者間の透明なコラボレーションは、より良いソフトウェア品質、より迅速な開発サイクル、および改善されたコンプライアンスにつながります。
- コスト最適化。コンテナは、自身の孤立した仮想化環境内でリソースの利用を最大化します。これにより、組織はインフラストラクチャのキャパシティと消費を正確に計画できます。
- インフラストラクチャに依存しない。コンテナは、アプリコンポーネントをインフラストラクチャに依存させず、組織がビジネスニーズの変化に応じてベアメタルサーバーから仮想化環境、クラウドインフラストラクチャへのワークロードを移動できるようにします。
コンテナのトレンド
これらの価値提案は、コンテナ化技術への関心と支出の増加を正当化します。そして、それは急速に進行しています！2023年までに、ガートナーは推定、世界中の組織の2/3以上が2つ以上のコンテナ化されたアプリケーションを実行するようになるでしょう。昨年の2019年と比較すると、その数は20％未満でした。
最近の State of Container and Kubernetes Security Report では、2020年初頭にStackroxが500人以上の技術専門家を対象にコンテナと採用のトレンドについて調査しました。ここでの重要なポイントは：
- コンテナ化されたアプリが急増しています。アプリの半分以上がコンテナ化されている企業は、6か月間で23%から29%に急増しました。これは29%の成長率です。
- コンテナは DevOps とセキュリティを引き入れます。コンテナに関する大きな懸念はセキュリティですので、成熟したコンテナユーザーはプロセスの早い段階で DevOps とセキュリティを巻き込んでいます。これは DevSecOps にとって大きな勝利です。
- AWS は依然として王者です。しかし、クラウドデプロイメントの第2位を獲得するのは ongoing battle です。Azure は不安定な第2位に留まっており、GCP は第3位の地位を7ポイント上げています。
- Azure ユーザーは最もコンテナの成熟度が低い。Azure ユーザーのうち、アプリの半分以上をコンテナ化しているのはわずか20%です。これは、非 Azure ユーザーの33%と比較すると著しく低いです。
組織でのコンテナの実装方法
企業は、ツールにコンテナを追加することをためらう必要はありません。利点を享受したいですか？コンテナで作業を開始する方法は以下の通りです：
- 現在の環境を見てください。アプリを分析し、それに最適な環境を確認します。アプリをリファクタリングしますか、それとも完全に新しく構築しますか？リファクタリングが興味深い場合は、他のアプリと相互作用せずに動作するスタンドアロンのアプリから始めてください。
- Kubernetes で実験してください。あなたの開発者がすでに K8s を使用している可能性が高いです。私たちの多部構成のKubernetes ガイドで詳細を学びましょう。
- 推進者を受け入れます。あなたの会社の中には、コンテナ化戦略に関して考えを持っている人（または多くの人）がいるでしょう。彼らと話し、学び、この取り組みの顔にすることを検討してください。
- プロジェクトを指定します。小さなプロジェクトを特定し、チームの名前を付け、達成したいことを概説します。将来的に変化を測定します。
- 教育を奨励します。新しい技術を十分に学ぶには時間がかかります。Kubernetes 認定への投資を検討するか、少なくとも開発者に専用の学習時間を与えます。
迅速で継続的なリリースサイクルに重点を置く DevOps 主導の組織では、コンテナ化は、特に仮想化が提供できなかった領域で投資を引き続き引き寄せるでしょう。
追加リソース
このトピックについての詳細は、これらのリソースを探索してください：
- BMC DevOps ブログ
- BMC マルチクラウドブログ
- 仮想ネットワークとは？
- DevOps における仮想化の役割、私たちの多部構成の DevOps ガイドの一部
- コンテナ管理プラットフォーム：どれが最も人気ですか？
- エンタープライズに Docker コンテナを導入するための3つのステップ
- コンテナは常に解決策ではない
元の参照画像：
これらの投稿は私自身の意見であり、必ずしも BMC の立場、戦略、または意見を代表するものではありません。