Docker は次の「Linux」になれるか?

Linux オペレーティングシステムは過去 20 年間にわたってデータセンターに革命をもたらし、今日ではアプリケーションホスティングプラットフォームの紛れもないリーダーとなっています。ミッションクリティカルな本番ワークロードを Linux 以外のものに展開することは想像しにくいです。

Docker によって Linux コンテナが普及したとき、それは数年前に始まったアプリケーションのパッケージ化、展開、ホスティングの革命に似ていました。それ以来、コンテナの使用は業界全体で飛躍的に増加し、日々増加し続けています。

重要なアプリケーションを Linux 以外のオペレーティングシステムにデプロイすることは考えられないのと同様に、コンテナーについても同じことが言えます。つまり、Web スケールの将来のニーズ (セキュリティ、スケーラビリティ、プラットフォームの独立性、容易な移植性など) を満たすには、すべてのアプリケーションをコンテナーにする必要があります。これらのコンテナは、あらゆる重要なアプリケーションやワークロードを実行するための新しい「Linux」であり、これからもそうあり続けるでしょう。

コンテナ導入の傾向

Datadog が 2018 年 6 月に更新した調査によると、すでに 25% の企業が Docker を導入しており、残りの企業も急速に追いついている傾向にあります。詳細な調査データはこちらです。

コンテナとオーケストレーション

Kubernetes、OpenShift、Apache Mesos、Docker Swarm は、コンテナに対する優れたオーケストレーションサポートを提供し、数千のコンテナのプラットフォームまたはインフラストラクチャの管理を大幅に容易にします。オーケストレーションツールによって提供される自動化機能の助けを借りて、1 人のエンジニアがコンテナ化されたアプリケーションの異種デプロイメントを管理できます。

Kubernetes は Docker コンテナのオーケストレーションの世界を支配しており、Google がそのオリジナルの作成者であり、CNCF が所有者です。 Kubernetes は、業界全体で最高のコミュニティサポートと優れた適応性も備えています。

コンテナ化されたアプリケーションにオーケストレーションサポートを提供する機能の一部:

リソース使用率に基づく水平自動スケーリング。
クラウドインフラストラクチャと緊密に統合すると、アプリケーションインスタンスを無限に拡張できます。
アプリケーションインスタンスの自己修復。
オンラインアップグレード。
カナリアアップグレード。

コンテナとマイクロサービス

Kubernetes は、オーケストレーションツールとして再びマイクロサービス展開の分野で優位に立ち、コンテナベースのマイクロサービスをホストおよび実行するための最も有名で人気のあるプラットフォームの 1 つとなっています。

識別されたすべてのマイクロサービスは、まず Docker コンテナに変換され、その後 Kubernetes プラットフォームに移動されて展開されます。これにより、迅速に展開され、ライフサイクル全体を通じて簡単に管理できるようになります。

コンテナベースのマイクロサービスは、シナリオ内でのスケーリングと自己修復が容易で、ワークロードの起動と提供が高速です。

従来とは異なるアプリケーションにおけるコンテナの採用

コンテナの導入に伴って、多くの驚くべきことが起こっています。かつてはコンテナで実行することは不可能だと思われていたアプリケーションが、現在ではコンテナに移行され、コンテナ化されたプラットフォームで使用できるようになりました。

データベース

数年前、データベースはコンテナテクノロジの範囲外にあると考えられていましたが、現在では、コンテナ上で実行してデータベースレベルで WebScale 機能をサポートするように特別に設計および開発されたコンテナおよびクラウドネイティブデータベースである NuoDB があります。

Oracle 12c は、Docker レジストリの公式 Docker イメージに事前構成された状態で利用できるようになりました。

私は、データベースレイヤーのコンテナー化に非常に期待しています。これにより、オンデマンドでデータベース (物理サーバーにデプロイ) をスケーリングする際の制限がなくなり、コンテナー内で実行され、ビジネスプロセスエンジンにデプロイされたデータベースが、必要に応じてアプリケーションインスタンスとともに簡単にスケーリングできるようになるため、アプリケーションの WebScale が容易になります。

通信業界におけるコンテナ化された通信ネットワークコンポーネント

通信業界では、プログラム可能なネットワークへの移行が加速しており、これにより、すべての CSP は従来の高価なハードウェア上でネットワーク機能を実行するのではなく、仮想化された方法ですべてのネットワーク機能を実行できるようになり、運用コストが大幅に削減されます。これにより、すべての CSP は、需要の増加時に完全に自動化された方法でネットワークを迅速に拡張できるようになります。しかし、コンテナが VM よりも優れていることはアプリケーションで実証されているため、業界では通信事業者の VNF でも同様の利点を実現したいと考えています。

通信業界では、SDN-NFV を使用したプログラム可能なネットワークへの移行が加速しており、これによりすべての CSP は、従来の高価なハードウェアではなく仮想化された方法ですべてのネットワーク機能を実行しながら、運用コストを大幅に削減できるようになります。これにより、すべての CSP は、需要の増加に応じて、完全に自動化された方法でネットワークを迅速に拡張できるようになります。ただし、アプリケーションの世界では VM よりもコンテナの方がメリットがあることが実証されているため、通信 VNF でも同様のメリットを得ることに業界全体で大きな関心が寄せられています。

こうした傾向から、アプリケーションレベルと仮想化ネットワークレベルの両方で、通信業界がコンテナ化されたプラットフォームによって支配される日もそう遠くないでしょう。

コンテナベースのビッグデータプラットフォーム

ビッグデータの世界では、HortonWorks の HDP 3.0 データプラットフォームの新しいバージョンでは、内部コンポーネント (YARN コンテナー、Web アプリケーション、HDP サービス) を実行するために Docker コンテナーが使用されるようになりました。 Hadoop クラスターは、最新の標準クラスターアプリケーションを完全にサポートする自己管理型クラスターであるため、ビッグデータプラットフォームをコンテナー上で実行し、オーケストレーションツール (クラスター内のクラスター!!) で管理できます。これは、以前は議論の的となっていたトピックでした。しかし、コンテナ化されたサービスの新しいバージョンがすでに存在するため、近い将来に Kubernetes プラットフォームで Hadoop クラスターを実行するようになるのも不思議ではありません。

クラウドとコンテナ

コンテナの人気が高まるにつれ、すべてのクラウドサービスプロバイダー (AWS、Azure、GCE、Oracle、OpenStack など) も、ネイティブコンテナと Kubernetes オーケストレーションサービスを提供およびサポートする必要があることに気付きます。現在、ほぼすべてのクラウドプロバイダーが独自のネイティブコンテナーおよびオーケストレーションサービス/プラットフォームを備えています。クラウド企業が提供するネイティブコンテナプラットフォームの例をいくつか示します。