比較しなければ害はありません!クラウドコンテナプラットフォームの選択方法は重要

クラウド コンテナ サービス市場における競争は激化しており、Google、Amazon、Microsoft Azure は、より良く、より早く市場に適応できるように、サービスの開発に尽力しています。

この記事では、3 つの異なるクラウド コンテナ プラットフォームを詳細に比較し、どのプラットフォームがビジネスに適しているかを読者が理解できるようにします。

Docker Linux クラウド コンテナにおける最も重要な競合相手は依然として Amazon と Google であり、Microsoft Azure が加わったことで、その競争は激化しています。

[[203687]]

Amazon Web Services と Google は、エンタープライズ アプリケーション開発ビジネスに適したクラウド コンテナ サービスを積極的に開発しています。

これらの企業のクラウド コンテナ サービスにより、Docker コンテナの管理がユーザーから解放され、コンテナ上に構築されたアプリケーションの展開と拡張が容易になります。ただし、自動スケーリング、冗長性、サードパーティのツールやクラウドとの相互運用性の実装方法など、各製品の間には依然として大きな違いがあります。

自動スケーリングは競争上の大きな障害である

Google Container Engine (GKE) は、ポッド、レプリケーション コントローラ、ノードで構成されています。ポッドは、アプリケーション固有の論理ホストをモデル化するコンテナの論理グループです。レプリケーション コントローラーは、ポッドのレプリカが常に一定数実行されるようにします。ノードは、コンテナ化された環境をサポートする Google Compute Engine 仮想マシンです。

GKE は、Google の Kubernetes クラウド コンテナ オーケストレーション プラットフォームに基づいています。 11 月 24 日にリリースされた Kubernetes バージョン 1.1 は、バージョン 1.0 の 1 か月後にデビューし、水平ポッド自動スケーリングを使用してポッドを自動的に調整する市場初の機能であり、GKE のさまざまなユースケースを正当化するためにユーザーが強く求めていた機能です。

「当社はあらゆる種類のプロジェクトに自動スケーリングを使用しています」と、マサチューセッツ州ロスアラモスに拠点を置き、ペタバイト単位の衛星データを処理する機械学習企業、デカルト・ラボの共同設立者兼クラウドアーキテクチャ責任者、ティム・ケルトン氏は語る。

(注: 「テラバイトは、2 の 40 乗、つまり約 1 兆バイト (つまり 1,000 ギガバイト) に相当するコンピューターの記憶容量の単位です。」

データの規模を考えるとき、人々は通常、米国議会図書館を思い浮かべます (写真参照)。 Deloitte、McKinsey、IBM、Gartner、モバイル広告会社Adfonicのデータ専門家は、TechTargetの記者に対し、PBレベルのデータがいかに大きいかを語った。

マッキンゼーのアナリスト、マイケル・チュイ氏は、米国議会図書館は「2011年4月までに235テラバイトのデータを収集しており、1ペタバイトはその4倍にあたる」と指摘した。

TechTarget 独自の百科事典サイト Whatis には、PB サイズの定義があります。「PB はデータ ストレージ容量の単位で、2 の 50 乗バイトに相当し、数値で約 1000 TB に相当します。」

未来学者レイモンド・カーツワイルは論文の中で PB の定義を拡張し、人間の機能的記憶の容量は 1.25 TB と推定されていると述べています。つまり、1PB に相当するには 800 個の人間の記憶が必要になります。

それが十分に明確でないなら、Adfonic の CTO である Wes Biggs がもっとわかりやすい計算を提示しています。

MP3 を再生する携帯電話のエンコード速度が平均 1 分あたり 1 MB で、曲の平均長さが 4 分であると仮定すると、1 PB の曲を 2000 年間連続して再生できます。

スマートフォンのカメラで撮影した写真の平均サイズが 3MB、プリント写真の平均サイズが 8.5 インチだとすると、1 ペタバイトの写真を並べると 48,000 マイル (地球を約 2 周する距離) に及ぶことになります。

1PB は米国全人口の DNA を保存するのに十分な容量で、さらに 2 回クローン化できます。 ）

ケルトン氏は、自動スケーリングが便利だと説明しています。ある時点で、彼の会社は 100 ペタバイトのデータを処理し、30,000 コアへの拡張が必要になりました。その後すぐにGKEによって追加されたKubernetesの最初のバージョンでは、「それはコア機能セットの一部ではありませんでした」と彼は言いました。 GKE はコンテナの垂直スケーリングやノードの自動スケーリングをサポートしていないが、これらの機能は近々提供される予定だと、Kubernetes の製品管理も監督する GKE のシニア プロダクト マネージャー、David Aronchick 氏は述べている。

一方、Amazon の EC2 クラウド コンテナ サービス (ECS) は、サービス、タスク、インスタンスで構成されています。サービスはアプリケーションを構成するタスクのグループであり、インスタンスは GKE のノードと同様にコンテナをサポートする Elastic Compute Cloud 仮想マシンです。

Amazon ECS の自動スケーリング機能は GKE の逆です。サービスは Amazon CloudWatch と Amazon Web Services (AWS) Lambda を使用して自動スケーリングでき、インスタンスも CloudWatch メトリックに基づいて自動スケーリングできます。一方、自動スケーリングできないポッドは自動スケーリングできます。

あらゆる種類の自動スケーリングは重要ですが、Amazon ユーザーは ECS に自動スケーリング機能が追加されることを望んでいます。 「追加のインスタンスを立ち上げるということは、他のタスクを実行するための余剰容量が確保されるということだが、新しいタスクが移動されるわけではない」と、Web コンテンツ アグリゲータである ACI Information Group の技術担当副社長、クリス モイヤー氏は語る。

「インスタンスを自動スケーリングするだけでは、追加の負荷を処理するのにはあまり役立ちません。スケーリングするには追加のタスクを起動する必要があります。」

地域間の冗長性

ECS を開発する際、Amazon は、顧客の需要に基づいてタスクを自動的にスケーリングして冗長性を確保するために、同じクラスター内の複数のアベイラビリティーゾーン (AZ) にネイティブにまたがる機能を優先しました。 ECS サービス スケジューラは、新しいタスクを起動すると、クラスター内の AZ 間で自動的にバランスを取ることも試みます。

「これは重要です。なぜなら、1 つの AZ に障害が発生する可能性があるため、両方のタスクが同じ AZ にあると、サービスが簡単に停止する可能性があるからです」と Moyer 氏は述べています。

Google の Aronchick 氏によると、Google はコマンドライン インターフェース (CLI) を通じて GKE の複数のリージョンにまたがることができるという。

「本当に簡単です。たった2つか3つのコマンドだけです」と彼は言いました。ただし、これは GKE の顧客にとって最大の希望である、リージョン間でクラスターをスケーリングする機能を含む Web UI の改善に関係しています。

「UIには多くの改善が必要だ」と、メディア企業向けの販売・マーケティングソフトウェアを開発するサスカトゥーン（サスカチュワン州）のベンダスタ・テクノロジーズの主任アーキテクト、デール・ホプキンス氏は語った。現在、UI ではクラスターの作成などが可能だとホプキンス氏は語った。 「クラスターをスケーリングする方法は直感的ではありません。」 ”

相互運用性

ECS は、主にユーザーに代わってクラスターの状態を処理するために、顧客の既存のワークフローに組み込むように設計された拡張可能なプラットフォームとして構築されています。既存のワークフローへの統合の一部は、高度なスケジュール設定のための Apache Mesos など、顧客がすでに使用しているツールに適用されます。 Amazon には、Amazon ECS に監視、継続的インテグレーション、セキュリティなどの機能を提供するクラウド コンテナ パートナーの広範なネットワークもあります。

Aronchick 氏によると、Google は Kubernetes を複数のクラウド プロバイダーに展開できるようにするために Cloud Container Partner Alliance も設立しており、これが今日の CLI 機能にもなっているという。 Kubernetes 1.0 が昨年の夏にリリースされたとき、Google は Cloud Native Computing Foundation の設立を主導しました。財団のメンバーには、IBM や Red Hat などのエンタープライズ クラウド サービス企業のほか、Box、eBay、Twitter などのエンド ユーザーが含まれます。

「Kubernetes を使えば、実際に Amazon にデプロイできるし、Azure にもデプロイできるし、IBM にもデプロイできるし、自分の物理ハードウェアにもデプロイできる」と Descartes のケルトン氏は言う。 「選択肢があるというのは魅力的です。」 Google には、数百人のコミッターと毎月数千件のコミットを伴うオープンソース プロジェクトもあり、これにより Kubernetes は水平ポッド自動スケーリングなどの新機能を迅速に追加できます。

「GoogleはKubernetesのリーダーであり、コミュニティの成長に非常に貢献している」と451 Researchのアナリスト、ジェイ・ライマン氏は語った。

ニューヨークに本拠を置き、大企業のITプロジェクトに関するコンサルティングを行っている同社は、創設者のジョン・デスポジト氏によると、2つの新しいプロジェクトでECSを使用する予定だという。 「ECS を使用する動機となった主なメリットには、Elastic Load Balancing、Virtual Private Cloud、Identity and Access Management、Elastic Block Storage などの既存の実績のあるインフラストラクチャ サービスとのシームレスな統合が含まれていました。

GKE と Compute Engine の価格設定も顧客にとって非常に魅力的です。 GKE では、VM リソースに対して 10 分単位で課金されるだけでなく、Kubernetes ホストも無料で提供されるため、Vendasta の Hopkins 氏にとって特に便利です。 「マシンの数が多くなるまではKubernetesにお金を払っていませんでした。GKEは最初のマシンセットにはKubernetesマスターを無料で提供してくれるのです」と彼は語った。

ホプキンス氏とケルトン氏は、Kubernetes と Container Engine がリリースされる前から、Google App Engine を含む Google Cloud サービスを使用していました。したがって、データ重力は、クラウド サーバー サービスの導入の選択にも影響します。

「当社のデータのほとんどはペタバイト単位なので、そのまま移動したりコピーしたりすることはできません。そのため、データを次のデータに移動する必要があります」とケルトン氏は語った。そのデータのほとんどは現在 Google Cloud Platform に保存されていますが、Descartes は AWS のパートナーと協力しています。

Microsoft Azure クラウド コンテナー サービスが準備完了

Google と AWS がクラウド コンテナ戦争をリードしている一方で、Amazon の最も重要な競合相手は、制限が予想される独自の Linux ベースのクラウド コンテナ サービスと、今年 Windows ベースのコンテナをサポートする予定の新しいバージョンの Windows Server を持つ Microsoft Azure のままです。 「当社の顧客のほとんどは、Azure か Amazon を利用しています」と、マサチューセッツ州ロチェスターの HKM コンサルティングの創設パートナーであるクリス・ライリー氏は語る。「Microsoft は興味深いツールを開発中です。次に検討するなら、Google よりも Azure でしょう。」

ノルウェーの Microsoft Azure システム インテグレーターである Kristian Nese 氏によると、多くの Microsoft 製品と同様に、シンプルさと使いやすさが設計の重要な焦点でした。

「現在、Azure Cloud Container Service を展開する場合、必要なコードは 100 行です」と Nese 氏は述べています。 「Azure Container Service をデプロイすると、23 個のリソースがデプロイされます。これを手動で実行すると、おそらく数千行のコードになるでしょう。」

Azure Container Service には、VM Scale Sets と呼ばれる、スタンドアロン サービスとして機能する自動スケーリング機能もプレビュー段階にあります。 Nese 氏はまた、Azure では Azure Resource Manager など、コンテナーを管理するための既存の使い慣れたツールもいくつか提供されると述べました。 Azure Container Service と Google および AWS の比較

クラウド テクノロジー パートナーの David Linthicum 氏によると、AWS、Google、Azure はいずれも独自のクラウド コンテナー サービスを提供しています。それぞれに長所と短所がありますが、最適なサービスはアプリケーションのニーズによって異なります。

コンテナ技術を使用してクラウド アプリケーションを展開する組織が増えるにつれて、コンテナとクラウドがよりトレンドの領域に加わると思われます。したがって、Amazon Web Services、Microsoft Azure、Google という 3 大クラウド サービス プロバイダーが独自のコンテナ サービスを市場に提供していることは驚くことではありません。ただし、これらのサービスは同じように作られているわけではありません。

この記事のために、ボストンを拠点とするクラウド コンピューティング コンサルティング会社である Cloud Technology Partners が、Amazon Web Services (AWS)、Google、Azure コンテナ サービスの内部レビューを実施し、テクノロジに関するコンサルタントの意見を聞き、ユースケースを調査しました。クラウドベースのコンテナ サービスを評価または使用する場合、企業は、データ管理、スケーラビリティ、パフォーマンス、セキュリティ、DevOps、管理と運用との統合 (表 1 を参照) など、開発と運用を使用していくつかの重要な機能を考慮します。つまり、企業はそれに対して何をすべきでしょうか。

レベル 1 ～ 5 の場合、1 が最高で、5 が最低です。 1 の指定は、テクノロジがカテゴリをまったくサポートしていないことを意味し、5 は、テクノロジがカテゴリの機能要件と特徴要件のほとんどを満たしていることを意味します。 DevOps カテゴリで検討した要件の 1 つは、コンテナ サブシステムが DevOps 操作をサポートしたり、統合リポジトリを提供したりできるかどうかでした。この記事では、Google、AWS、または Azure のコンテナ サービスを評価する企業向けに、いくつかの基本事項を説明します。最終的に、あなたのビジネスがそれをどのように適用するかによって、最終製品の方向性が決まります。

統合とデータに関する考慮事項

Azure Container Service (ACS) は、オープン ソースのコンテナー オーケストレーション システムである Apache Mesos に基づいています。これは、ACS の以前の機能と機能を考慮すると、ACS の機能と能力についていくつかの適切な仮定を立てることができることを意味します。まだ一般には提供されていない ACS は、上記の 3 つのコンテナ サービスの中で最も小さいものです。 Microsoft コンテナー製品に関するデータ ポイントがさらに提供されると、状況は劇的に変化します。

AWS EC2 Container Service (ECS) では、コンテナを詳細なレベルで監視できないなど、運用上の問題がいくつか発生しました。 ECS の管理および運用との統合は AWS のどのサービスと同様に強力であるはずなので、Google Container Engine (GKE) の 5 に対して 4 に下げる必要があります。ただし、ECS には CloudWatch 統合が含まれているため、ACS と比較してより安定している可能性があります。さらに、現時点では、ACS は Linux コンテナのみをサポートしています。 Windows のサポートは近づいていますが、過去に Microsoft が Mesos を移植したため、.NET 開発者は時代遅れになっています。データ面では、これらのサービスはすべて、外部 API の使用を強制することなくネイティブのデータ接続を提供しますが、改善の余地があります。 1 つの問題は、コンテナーがローカル データ サービスに結び付けられ、移植性を高めるオープン データ アクセスが提供されないことです。データがコンテナに密接に結合されている場合、ポータブル コンテナを作成することは困難です。これは私たちが現在注力している新興分野です。

AWS、Google、Azure コンテナのセキュリティ

セキュリティについて検討したところ、Google のサービスには、Kubernetes コンテナ オーケストレーション システムを通じて、他の 2 つのサービスにはない「シークレット」機能と追加のリソース制限があることがわかりました。その結果、GKE はより高いセキュリティ ランキングを獲得しました。覚えておいてください、Microsoft も Kubernetes を使用していますが、方法は異なります。テクノロジー自体の多くはユーザーから抽象化されています。

しかし、ホスト プラットフォームやコンテナ サービスが配置されているパブリック クラウド プラットフォームを見ると、セキュリティの面では Google プラットフォームが AWS や Azure ほど優れていない点がいくつかあることがわかります。 Google はサードパーティの ID アクセス管理 (IAM) ツールを使用できますが、ネイティブの IAM サポートはありません。これは表に記載されているランキングには影響しませんが、今後これらのプラットフォームを利用する際には考慮すべき事項です。

DevOpsのスケーラビリティ

DevOps の場合、GKE と Amazon ECS には現在独自のレジストリがありますが、Azure Container Service にはそれがありません。 Google と AWS は、それぞれのクラウドでコンテナ サービスを検討する場合、より優れた DevOps 統合を提供します。

スケーラビリティはアプリケーションのニーズに関係するため、アプリケーションが提供するメカニズム (Mesos など) と、プロジェクトで確認したいくつかのユースケースに基づいて想定を行います。コンテナをホストおよび実行するためのこれらのテクノロジーを検討する場合、同じアプローチを使用できます。たとえば、Mesos を使用する ACS は適度なスケーラビリティを提供しますが、より優れたクラスタリング機能を提供するという点では GKE ほど優れていません。

ご存知のとおり、Amazon ECS は、主に AWS がコンテナエンジンに提供する高度にスケーラブルなプラットフォーム機能によって、優れたスケーラビリティを提供します。

全体として、Google の製品は、独自の Kubernetes コンテナ統合との緊密な統合と、Google の開発および運用サポートのおかげで、全体的にさらに進歩しています。それでも、Google は AWS や Microsoft が追いつけないほど遅れているわけではありません。 AWS の市場における懸念を考慮すると、近い将来、より優れたコンテナ技術が提供される可能性もあります。