コンテナは、近年間違いなくテクノロジーのバズワードとなりました。コンテナ化技術の登場と普及、そしてそれが生み出したマイクロサービスアーキテクチャ、DevOps、クラウドネイティブの概念は、ソフトウェア業界に大きな影響を与えています。
コンテナには多くの利点があります。徹底したカプセル化、便利なデプロイ、軽量な起動とスケジューリングが、その普及に貢献しています。オーケストレーションシステムと組み合わせることで、システムの複雑さに関わらず、アプリケーションの管理と反復を簡素化します。さらに、コンテナ化されたアプリケーションは優れた移植性を示し、標準準拠のコンテナランタイムが搭載されたあらゆる環境でシームレスに動作します。
軽量なコンテナと弾力性のあるクラウドコンピューティングは、互いに完璧に補完し合います。多様な動作環境への適応性と高速起動能力を持つコンテナは、動的クラウド拡張による膨大なリソース拡張性と相まって、クラウド上のコンテナ化アプリケーションを短期間で数千のインスタンスにまで拡張することを可能にします。したがって、クラウドはコンテナ化アプリケーションの実行と拡張にとって理想的なプラットフォームです。
Docker が広く認識される以前から、クラウドプロバイダーはコンテナに似た技術を模索し、活用していました。クラウドのマルチテナント性は環境の分離を必要とするため、クラウドプロバイダーはコンテナ化のユーザーであると同時に受益者でもあります。独自のソリューションを選んだ企業もいましたが、すべてが Docker を直接採用したわけではありません。
例えば、AWS Elastic Beanstalk は Web アプリケーションを分離するために独自のコンテナ類似技術を採用していました。その後、Docker コンテナとしてパッケージ化されたアプリケーションへのサポートを拡張しました。
Docker の台頭に伴い、大手パブリッククラウドプロバイダーは一貫して標準化されたコンテナ関連の PaaS サービスを提供し始め、継続的に強化してきました。コンテナ PaaS の進化をたどると、明確な発展段階が見えてきます。
当初、クラウドコンテナプラットフォームは、Docker コンテナをクラウド上でシームレスに実行することに重点を置いていました。これらのサービスは主に、ユーザーが基盤となる仮想マシンクラスターを作成するのを支援し、手動による仮想マシン管理の負担を軽減することを目的としていました。しかし、コンテナ化アプリケーションが複雑になるにつれて、オーケストレーションが差し迫ったニーズとなりました。その結果、ベンダーはコンテナオーケストレーションソリューションを導入し、強化していきました。
オーケストレーションフレームワークが競合していた時代には、複数のアプローチを採用するベンダーもありました。例えば、Microsoft の Azure Container Service は Docker Swarm、Apache Mesos（DC/OS）、Kubernetes をサポートしていました。一方、AWS は Elastic Container Service（ECS）で独自のオーケストレーション手法を採用し、既存のクラウドサービスとの統合を強化しました。
ご存知の通り、Kubernetes はオーケストレーションフレームワークの戦いに勝利し、事実上の標準となりました。クラウドプロバイダーは迅速に方針転換し、クラウド上での Kubernetes サポートを優先し、AWS Elastic Kubernetes Service（EKS）や Azure Kubernetes Service（AKS）などの Kubernetes 専用サービスを立ち上げました。同様に、Alibaba Cloud もコンテナサービスにおける Swarm サポートを段階的に廃止し、Kubernetes 版（ACK）に集中しました。
コンテナ技術に対するクラウドのサポートは、コンテナエコシステムと共に進化してきました。クラウドプロバイダーは、参加者として、また実現者として重要な役割を果たしています。例えば、Google Cloud の Google Kubernetes Engine（GKE）は、このエコシステム内で「生まれ育った」存在であり、クラウドベースの Kubernetes サービスにおいて常にベンチマークとなっています。
クラウドベースの Kubernetes サービスには、セルフホストの Kubernetes クラスターに比べていくつかの明確な利点があります。
まず、クラウドのマルチテナント性により、多くのクラウドベースの Kubernetes サービスでは Master ノードをプロビジョニングする必要がありません。ユーザーは Worker ノードを作成して支払うだけでよく、クラウドプラットフォームが Master ノードを提供・管理するため、リソース消費と運用コストが削減されます。
次に、Kubernetes は複雑ではありますが、非常に優れた抽象設計を備えており、広範かつ柔軟な拡張が可能です。クラウドプロバイダーはこの分野に多額の投資を行っており、プラットフォーム上のさまざまな IaaS および PaaS コンポーネントが Kubernetes エコシステムとシームレスに統合され、より緊密な連携を実現しています。
例えば、外部トラフィックを誘導するために一般的に使用される Ingress Controller の分野では、AWS ALB Ingress Controller や Azure AKS Application Gateway Ingress Controller などのクラウドベースのロードバランサーコントローラー実装があります。これらのコントローラーは、対応する PaaS サービスインスタンスを作成して Kubernetes クラスターに提供します。
さらに、Kubernetes で動的ストレージボリュームの割り当てポリシーを定義する StorageClass のレベルでは、クラウドのブロックストレージサービスを使用して、永続ストレージを必要に応じてプロビジョニングおよびマウントするように指定することが可能です。
アーキテクチャの柔軟性の観点から、クラウドベースの Kubernetes サービスにはもう一つの利点があります。それは、マルチクラスターデプロイです。
Kubernetes クラスターの構築障壁が低くなったため、ビジネスユニット間の依存関係がほとんどない場合は、各ユニットに個別の Kubernetes クラスターを作成できます。このアプローチにより、分離性が向上し、異なるクラスターを個別にスケーリングできます。
Docker から Kubernetes へと、コンテナエコシステムの継続的な進化は、クラウドネイティブ技術の波をもたらしました。開発者は、コンテナ技術を学び受け入れるという探求において、孤独ではありません。クラウドコンピューティングベンダーもまた、コンテナを実行するための最適なプラットフォームとして自らを位置づけようと競い合い、数多くのコンテナ関連サービスを導入してコンテナユーザーを自社のクラウドに引き寄せています。
興味深いことに、コンテナとベンダーが積極的に推進する特定のクラウドサービスの間には、微妙な関係が存在します。競合と代替の要素が働いています。
一部の PaaS 機能が IaaS を使用して再現できるのと同様に、コンテナはその優れた構築の自由度と便利なパッケージ化・デプロイのメカニズムにより、クラウド内の特定の再利用可能なコンポーネントを部分的に置き換えることができます。さらに、コンテナはより大規模なシステムの一部としてオーケストレーションすることができ、ベンダーロックインを軽減する手段としても機能します。
コンテナが特定のクラウドサービスに与える潜在的な脅威にもかかわらず、クラウドコンピューティングは再びその技術的な中立性を示しています。クラウドプラットフォームはコンテナの実行を公然と受け入れ、サポートし、さらには開発における主要なサービスとして指定しています。選択肢をユーザーに与えることは、クラウドの包括性を示しています。
Novita AI は、AI の野望を実現するためのオールインワンのクラウドプラットフォームです。統合 API、サーバーレス、GPU インスタンス - コスト効率の高いツールを提供します。インフラストラクチャを排除し、無料で始めて、AI ビジョンを現実にしましょう。
おすすめの記事:
