Kubernetes や Docker SWARM などのコンテナ オーケストレーション フレームワークでコンテナをスケジュールするプロセスは、単にランタイム リソースをワークロードに割り当てることとして説明できます。無制限 (または少なくとも十分な) リソースがあり、すべてのワークロードが等しい世界では、現在のコンテナー スケジューリング システムが適切であると考えられます。しかし、エンタープライズ コンピューティングの現実の世界では、すべてのワークロードが等しいわけではなく、ほとんどの組織にはリソースの制約があることがわかっています。さらに、大規模組織には独自のニーズがあり、特定の方法でワークロードを実行したいと考えているため、高度なスケジューリングのビジネス ケースを作成します。
コンテナーを実験したり、いくつかの小規模なパイロット プロジェクトを実行したりする場合、コンテナーのスケジュール設定は非常に簡単になります。しかし、些細なユースケースを越えると、コンテナーのスケジュール設定はより複雑になり、非常に重要な課題になります。
次のセクションでは、固有の複雑さについてさらに詳しく説明し、強力で自動化されたコンテナー スケジューリングの必要性について説明します。
コンテナ環境は静的ではなく動的です
サービスベースのアーキテクチャは静的で、あまり変化しない長時間実行されるサービスが含まれているように見えるかもしれませんが、実際はそうではありません。レプリケーション コントローラーや動的負荷分散などのコンポーネントの動的な性質により、実行するサービス コンポーネントの数と性質は 1 日に何度も変化する可能性があります。以下に挙げるような要件と境界条件は、いつでも変更されることが予想されます。これには通常、次の理由によりワークロードの配置を変更する必要があります。
- システム障害により、サービスまたはそのコンポーネントの一部を再スケジュールする必要がある
- リソースの再割り当て、追加または削除。例:クラウド環境で
- ワークロードの需要と優先順位は、特に他のワークロードとの関係で変化する可能性があります。需要が高まる時間帯
特定のサービスまたはその一部のコンポーネントに対するソフトウェアの更新によっても、環境に動的な変更が生じる可能性があります。また、サービス以外のより一時的なワークロードには優先順位が必要となり、リソースの制約が生じる可能性があります。バッチ ジョブ、インタラクティブな作業、ソフトウェア ビルド (例: CI/CD フレームワークを通じてトリガーされる) またはテスト スイート タスクなどのワークロードも、やはり CI/CD フレームワークから生じ、競合を引き起こす可能性があり、ワークロードの再バランスが必要になる場合があります。
コンテナのスケジューリングは非常に複雑で単純ではありません
コンテナーを使用すると、従来のモノリシックなアプリケーション開発アプローチよりも多くの (そしてはるかに小さい) 可動部分が存在します。たとえば、マイクロサービス アプリケーション コンポーネントには相互依存性と多様なニーズがあり、スケールを達成するためにサービス コンポーネントのレプリカを利用します。ネットワークとストレージのソフトウェア定義レイヤーへの依存関係も増えています。エンジニアによるチェックインごとに、大量のビルド/デプロイ/テスト手順と自動オーケストレーションがトリガーされ、サービスの準備と健全性が確保され、オンデマンドでサービス コンポーネントが作成または縮小されます。 DevOps が関与すると、より多くの関係者が運用に影響を及ぼし、すべてのアプリケーション エンジニアと単一の開発ステップが運用に直接影響を与える可能性があります。これらの動くパズルのピースに基づいた一貫性と信頼性の高いサービスの提供は、特により高いサービスレートとより多くのサービスで規模を拡大する場合に課題となります。
コンテナのスケジューリングはリソースの制約を処理する必要がある
クラウド コンピューティングの世界では、リソースが無限に利用できるかのような幻想が生まれますが、これらのクラウド リソースには本質的に制約があることがよくあります。これらは通常、予算、または目的のノードの可用性と馬力によって制約されます。ワークロードのスケーラビリティによっても制限が発生する可能性があり、コストと利益のトレードオフにより、特定のしきい値を超えると経済的利益が制限される可能性があります。対応できるリソースを超えた作業を実行する必要がある場合、スケジュール設定は、「誰が実行し、誰が実行しないのか」、「誰が最初に実行され、誰が次に実行されるのか」という難しい意思決定プロセスになります。そして、「誰がより多くを獲得し、誰がより少なく獲得するのか?」
強力で自動化されたスケジューリングの必要性
記録的な速さでコンテナが導入されていることは周知の事実であり、ほとんどの組織はまだパイロット、開発、またはテストモードにありますが、デプロイメントが本番環境に移行し、最終的には拡張されるにつれて、制約により高度な自動スケジューリングツールの必要性が決まります。 。
- リソースの制約、複雑なコンテナのユースケース、動的に変化する環境や境界条件など、さまざまな課題の組み合わせに対処するための意思決定を自動化することは、コンテナ オーケストレーションにおける最大の課題です。
- 自動スケジュールには強力なポリシーとその効率的な実装が必要です
- 強力で自動化されたスケジューリングがなければ、リソースの無駄を受け入れざるを得なくなるか、常に手動で調整しなければならないにもかかわらず、最適な結果は得られません。
したがって、事前にスケジュールを設定しなければ、時間、労力、お金を無駄にすることになります。そして、環境がより動的になり (クラウドを考えてください)、ユースケースが高度になるほど、無駄になるものが増えます。
Navops コマンドの紹介 – Kubermetes のスーパーパワー
Kubernetesの開発に携わったGoogleのエンジニアたちは、初期の段階から高度なスケジューリングが必要になると見抜き、Kubernetesのモジュール型アーキテクチャにおいて、Kubernetesスケジューラを容易に置き換えたり、複数のスケジューラを並列で利用したりできる機能を考慮に入れました。Univaは、高性能コンピューティングおよびテクニカルコンピューティングアプリケーションにおけるスケジューリングに関して長年の経験を有しています。当社は、この実績ある専門知識を基盤として、洗練されたコンテナ指向のWebインターフェース、API、およびコマンドラインインターフェースを備え、Kubernetesに対応したNavops Commandスケジューリング機能を設計しました。このシステムは、比例リソース共有管理、リソースクォータ、アクセス制御リスト、リソースインターリーブといった概念をコンテナの世界にもたらします。詳細および早期アクセスのお申し込みについては、www.navops.io/command.htmlをご覧ください。
フリッツ・フェルストル（ Univa社、EMEA地域CTO兼事業開発担当）
Fritz は、分散ワークロードとリソース管理の第一人者として 23 年以上の経験を積んできました。彼の経験は、グリッド コンピューティングからクラウド コンピューティング、ハイ パフォーマンス コンピューティング、仮想化、コンテナの最適化まで多岐にわたります。 Univa Corporation の CTO として、彼はあらゆる業界の数百の大企業顧客をサポートし、そのワークロード管理要件を代表して Univa の製品とテクノロジーの方向性を定義しています。これらの顧客の中には、世界最大のコンピューティング環境の企業が数多く存在します。
Amazon