コンテナ、コンテナ クラウド、コンテナ化された PaaS プラットフォームの関係は何ですか?

多くの人は、コンテナが IaaS レイヤーに属するべきか、それとも PaaS レイヤーに属するべきかについて常に混乱しており、コンテナ クラウドをどこに分類すべきか、どのチームが構築すべきか、どのチームが保守すべきかについても不明確です。 K8s はコンテナ クラウドと同等ですか?そのため、概念や定義に混乱が見られ、コンテナ クラウドの実装時に多くの意見の相違や混乱が生じます。現在、多くの企業がコンテナ化された PaaS という概念を立ち上げており、誰が誰なのかを把握することがさらに難しくなっています。

では、コンテナ、コンテナ クラウド、コンテナ化された PaaS、Docker、Kubernetes の関係は何でしょうか?これは私たちが明確にし、理解する必要がある問題です。

コンテナはオペレーティング システム レベルの仮想化テクノロジであり、Docker はコンテナ エンジンです。 Docker を使用して運用コンテナを実行します。しかし、コンテナ自体の観点から見ると、IaaS レイヤーの機能を提供します。 Kubernetes は、コンテナのスケジューリングおよび管理機能をクラウド コンピューティングのテナント機能と組み合わせて提供し、コンテナ クラウド プラットフォーム機能を実現します。コンテナ技術をベースに構築されたアプリケーション開発、アプリケーションホスティング、アプリケーション運用・保守プラットフォームは、軽量な PaaS 実装であるコンテナ化 PaaS プラットフォームと呼ぶことができます。ログ記録、監視、認証、権限などの基本機能を組み合わせることで、エンタープライズレベルのプラットフォームと再利用可能なサービスを構築し、マイクロサービス アーキテクチャを使用してエンタープライズ技術サービス ミドルオフィス機能を実装し、アジャイル R&D とエンタープライズ ビジネスのモデル変革をサポートします。

1. コンテナ

コンテナは軽量の仮想化テクノロジーです。 VMware 仮想化とは異なり、分離性とセキュリティは比較的劣りますが、軽量であることも特徴です。コンテナの概念は実際には長い間存在していましたが、実際の選択肢は異なります。当時私が勤めていた会社では、2006 年にはすでに Java ベースのマルチ JVM コンテナの概念を提案し、製品として実践していました。 Java コンテナは複数の JVM を実行できます。しかし、Java 自体の特性上、その後の変換はうまくいかず、結局断念せざるを得ませんでした。アプリケーション層コンテナとオペレーティング システム レベルのコンテナの実装には、依然として大きな違いがあります。オペレーティング システム レベルのコンテナー設計は明らかにより合理的であり、実装と促進も簡単です。環境の一貫性は、標準化されたイメージパッケージングによって実現されます。

コンテナは、弾力的なスケーラビリティを実現するためにステートレス アプリケーションになる傾向があり、これによりコンテナの設計と実装の複雑さが簡素化されます。したがって、コンテナ自体の特性により、コンテナを使用できるシナリオは無制限ではありません。もちろん、Kubernetes はバージョン 1.9 以降、ステートフル アプリケーションを正式にサポートしており、さまざまなシナリオに対するコンテナの適応性が向上し、適用可能なシナリオが拡大しています。

コンテナと仮想マシンはよく比較されます。どちらも仮想化ではありますが、両者の間には依然として大きな違いがあります。仮想マシンは完全な人間のようなもので、コンテナは母親のお腹の中の胎児のようなものです。コンテナは存続するために母体に依存する必要があるため、コンテナはオペレーティング システム内のプロセスとして実行されることがわかります。コンテナの仮想化損失は約 1% ですが、仮想マシンの損失は約 20% です。ただし、コンテナは管理と運用を複雑化させます。 Docker は CLI と REST API メソッドを提供しますが、どちらも学習コストが高くなります。 CLI を使用して一定数のコンテナを管理および操作するのは悪夢となるため、管理と操作の効率を向上させ、操作の難易度と作業負荷を軽減するために、Docker Swarm、Mesos、Kubernetes などのコンテナのスケジューリングおよび管理フレームワークが登場しました。

コンテナもオペレーティング システム レベルの仮想化であるため、仮想マシンに似たオブジェクトとして見ることができます。コンテナ自体によって提供されるサービスは依然としてインフラストラクチャ リソース サービスであるため、コンテナは IaaS レイヤーに配置する必要があります。 Kubernetes などのコンテナ技術とコンテナスケジューリング管理技術に基づくコンテナクラウドプラットフォームは、コンテナ操作をカプセル化し、プラットフォーム機能を提供するため、コンテナクラウドプラットフォームは PaaS レイヤーに属する必要があります。おそらくこれが、多くの人がコンテナ クラウド プラットフォームを PaaS プラットフォームと直接呼ぶ理由です。しかし、正確に言うと、コンテナ クラウド プラットフォームは実際には PaaS ではありません。現在、多くのコンテナ クラウド プラットフォームが提供する機能は、アプリケーション開発、アプリケーション ホスティング、アプリケーションの運用と保守に関する PaaS プラットフォームの機能要件を満たすことができません。代わりに、通常はテナント + クラウドのコンテナのスケジュール設定と管理機能のみが実装され、CLI の操作と保守の作業が依然として多く残っています。コンテナ クラウドを使用する人にとって、学習コストと要件は比較的高くなります。

2. コンテナクラウド

Kubernetes はコンテナ クラウドと同じではありません。 Kubernetes は、コンテナのスケジュールと管理に使用される、docker swarm や mesos のようなコンテナのスケジュールと管理のフレームワークです。たとえば、コンテナをリソースに合わせてスケジュールしたり、コンテナの弾性スケーリング、グレースケールリリース、負荷ルーティングを管理したりします。クラウド コンピューティングで非常に重要な概念はテナントです。テナントは共有クラウド コンピューティング リソースをレンタルし、需要と使用量に基づいて料金を請求されます。使用されない場合は料金は発生しません。 Kubernetes にはテナントの概念はありません。したがって、Kubernetes だけでは不十分です。 kubernetes は、コンテナ クラウド プラットフォームのカーネルと見なすことができます。コンテナ クラウド プラットフォームを実装するには Kubernetes を使用する必要がありますが、インフラストラクチャ リソースやその他の機能を共有するテナントをサポートするには、Kubernetes に基づいてそれをカプセル化する必要もあります。

テナンシーはクロスプラットフォームの概念になる場合があります。コンテナ クラウド プラットフォームの構築では、コンテナ クラウド プラットフォームの一部のテナント設計が Kubernetes 名前空間に基づいて分割されます。 1 つのテナントが 1 つの名前空間を使用するため、大きな制限が生じます。テナントの定義には明確な標準はありませんが、理論的にはテナントは Kubernetes よりも上位にあるため、Kubernetes 内にはテナントの概念はなく、リソースの分離を実現するために名前空間が使用されます。コンテナ クラウド プラットフォームの実践では、複数の Kubernetes クラスターや、さらには複数の IaaS プラットフォームにまたがる可能性のあるテナントの設計を考慮する必要があります。Kubernetes を使用してコンテナ スケジューリングを実装し、コンテナを異なるクラウド プラットフォームで実行するようにスケジュールできます。たとえば、コンテナを Tencent Cloud、Huawei Cloud、AWS Cloud などのクラウド プラットフォームに同時にスケジュール設定できます (クラウド管理を通じて、統一されたリソース管理と制御を実現し、コンテナ クラウド プラットフォームのリソース スケジュール設定をサポートします)。これにより、高度なバックアップと災害復旧が実現します。これには、Kubernetes マルチクラスターに基づくコンテナ クラウド プラットフォーム機能の抽象化と設計を考慮する必要があります。

コンテナは、軽量、弾力性、ステートレスなどのビジネス シナリオに適していますが、従来の業界での適用シナリオは広くないことも決定づけています。伝統産業のビジネスは安定性を追求し、頻繁な変更や再開を必要としません。再起動するとデータが失われる可能性があり、ビジネス トラフィックの処理に変動が生じる可能性もあります。また、本番環境とテスト環境の要件が異なることを認識することも重要です。テスト環境では、アジャイルな反復テスト、迅速な環境準備、頻繁な展開と削除が可能になりますが、実稼働環境では継続的かつ安定した運用が求められることがよくあります。そのため、コンテナはテスト環境に適しており、テスト環境をより速く構築し、回帰テスト環境の一貫性を確保し、より迅速かつ頻繁な構築、リリース、展開、テスト、フィードバックを実現できるため、効率が向上し、エラーの頻度が減ります。これは、当社のすべてのチームがコンテナ クラウド プラットフォームに喜んで切り替える理由の 1 つでもあります。生産環境には安定性が求められます。アプリケーション サービスがデプロイされた後は、頻繁な起動と停止は必要なくなり、頻繁な弾性スケーリングが必要になることはほとんどありません。スムーズさと安定性を確保するには、システム容量の要件を事前に計画することが必要になることがよくあります。

1 つの技術ですべての問題を解決できるわけではありません。コンテナは万能ではありませんが、特定のシナリオには適しています。無理やり合わせることはできませんが、コンテナの特性を理解し、適切なビジネスシナリオを選択する必要があります。企業はビジネス ニーズを満たすためにさまざまなテクノロジを組み合わせる必要があり、コンテナーは軽量で弾力性があり、ステートレスなビジネス アプリケーションをサポートするのに適しています。そのため、テスト環境では、テスト用の Kafka、Mysql、ES などをすぐにデプロイできますが、これらのコンポーネントは、コンテナ化されたデプロイではなく、本番環境に物理的にデプロイする必要があります。テストと本番では、パフォーマンス、安定性、効率性などの要件が異なるため、シナリオに応じて異なるアプローチを検討する必要があります。

コンテナはリソースを節約できると主張する人も多くいますが、これは相対的なものにすぎません。各コンテナは、ビジネス アプリケーションと依存パッケージの完全な組み合わせです。依存ファイルが増えると、デプロイされるコンテナが増え、占有される重複リソースも増えます。無駄が増えるほど、1 つのサーバー上で複数のサービスを直接開始するのと同じようなものになります。さらに、多数のコンテナが適切にスケジュールされていない場合、リソースの競合が発生することが多く、アプリケーションのパフォーマンスが時々影響を受けることになります。コンテナ クラウドはいつリソースを節約するのでしょうか?一定量に達し、中規模から大規模で使用されるようになった後、リソースは異なる期間で使用できるようになります。例えば、日中に業務処理を行い、夜間にデータ分析、計算、統合、統計などを行うことができます。これはリソースをスライスすることと同じです。ただし、これはコンテナの量だけでなく、事業の運用リソースと期間の要件によっても異なります。一定の量に達した後にのみ、リソースをより適切に計画し、さまざまな期間で使用できるようになり、「リソースの節約」という目標を達成できます。ただし、これらはコンテナ クラウド プラットフォームのコンテナ スケジューリング機能に非常に高い要求を課します。

3. コンテナ化されたPaaS

コンテナ クラウドは、コンテナ化された PaaS のプロトタイプと見ることができますが、実際には PaaS とは言えません。 PaaS プラットフォームはオペレーティング システム (クラウド オペレーティング システム) に似ており、アプリケーションの開発、ホスティング、運用、保守機能を提供します。特に、伝統的な業界の人々にとっては、ユーザーが追加の学習なしに PaaS プラットフォームを簡単に使用してアプリケーションの開発、ホスティング、運用、保守のニーズを満たすことができる、使いやすい UI が必要です。

コンテナ クラウドまたはコンテナ化された PaaS プラットフォームは基本的なプラットフォームであり、理論的には運用保守チームによって構築される必要があります。しかし、コンテナ クラウドを導入した後、PaaS 運用保守チームは従来の運用保守チームとは異なります。むしろ、運用保守プラットフォームの構築、運用保守ツールの開発、定常業務アプリケーションの運用保守に重点を置いた開発指向の運用保守チームにすべきです。運用保守は、インフラストラクチャ リソースの運用保守、プラットフォームとツールの運用保守、ビジネス アプリケーションの運用保守の 2 ～ 3 つのレベルに分けられます。開発チームはビジネス アプリケーションの開発と反復に重点を置き、ビジネス チームはビジネス運用とイノベーションに重点を置きます。 PaaS プラットフォームは、インフラストラクチャ リソースを下位に活用し、ビジネス アプリケーションの開発、保守、運用を上位にサポートする接続の役割を果たします。これは、企業のデジタル変革における IT 組織変革の重要な側面でもある Google SRE と多少似ています。

コンテナ化された PaaS プラットフォームは、コンテナの特性をより有効に活用して、マイクロサービス ビジネス アプリケーションをサポートできます。そこで、コンテナ クラウド プラットフォームを構築するにあたり、コンテナ クラウド プラットフォームにサービス ガバナンス機能が必要となるマイクロサービス ビジネス アプリケーションをサポートするために、「アプリケーション管理を中核とする」ことを提案しました。サービス ガバナンスは SpringCloud や dubbo を指すものではありません。マイクロサービス開発フレームワークとマイクロサービスガバナンスは 2 つの概念です。コンテナ クラウド プラットフォームまたはコンテナ化された PaaS プラットフォームでは、SpringCloud や dubbo を使用せずにマイクロサービスを開発できるため、マイクロサービスの管理とガバナンスが簡素化されます。たとえば、サービス登録の場合、Eureka を SpringCloud で使用するには、追加の Eureka コンポーネントが必要です。コンテナ クラウド プラットフォーム自体がサービス登録および検出メカニズムを提供するため、SpringCloud などのツールを選択する必要はありません。ただし、これにより、さまざまな種類のマイクロサービスを管理および制御できる必要があるコンテナ クラウド プラットフォームまたはコンテナ化された PaaS に比較的高い要求が課せられます。

これを理解すると、コンテナ化された PaaS プラットフォームを設計および実装するときに、SpringCloud や Dubbo を考慮するだけでなく、より一般的な PaaS プラットフォームを設計できるようになります。

コンテナ化された PaaS を軽量 PaaS と定義します。いわゆる軽量 PaaS は、安定性、信頼性、パフォーマンスなどの点で非コンテナ化デプロイメントに劣り、運用と保守の複雑さが高いため、本番データベース、Kafka、ES などの重いデータベースやミドルウェア システムを展開する代わりに、マイクロサービス アーキテクチャのビジネス アプリケーションをサポートするために使用します。したがって、コンテナ クラウドまたはコンテナ化された PaaS は、マイクロサービス アーキテクチャのビジネス アプリケーションをサポートし、アジャイルなビジネス アプリケーション サービスの開発と反復を実現し、一貫した開発およびテスト環境を迅速に構築し、突然のトラフィックに対処するための柔軟なスケーリングをサポートし、サービス ガバナンスを拡張してセキュリティ管理を強化し、統合されたログ記録、監視、監査などのエンタープライズ レベルの機能センターを提供するために使用されます。これにより、同社の再利用可能なミドルオフィスサービスはコンテナ化されたPaaSに基づいて構築され、企業のビジネスアプリケーションやビジネスモデルの変革のアジャイルな変更ニーズを満たし、企業のデジタル変革を促進します。

また、アジャイル状態と定常状態という 2 つの状態の運用と保守についても多くの人が話しています。私たちは、新しい運用保守モデルと従来の運用保守モデルの並行運用保守モデルではなく、異なるビジネス シナリオの要件が核心であると考えています。敏捷性と安定性が常に求められます。すべてのデータベースがコンテナにデプロイされている場合、これは俊敏性ではなく、トラブルを招くことになります。前述したように、これは PoC 環境とテスト環境では実行できますが、実稼働環境ではシナリオ要件が異なります。インターネットビジネス、従来型ビジネスを問わず、生産環境の安定性は第一の要件です。

コンテナ、コンテナ クラウド、コンテナ化された PaaS には、ユーザーに対する要件が異なります。コンテナ クラウドの製品化では、コンテナ化された PaaS プラットフォームに変換する必要があり、アプリケーション開発、ホスティング、運用および保守機能の要件をより適切に満たすために、さまざまなビジネス シナリオのニーズを考慮する必要があります。これは、PaaS プラットフォームを実装する比較的便利な方法でもあります。