ビジネスのリソースリクエストが予測不可能であったり、周期的に変動したりする場合は、ビジネスの自動スケーリングを有効にすることを推奨します。たとえば、Web アプリケーション、ゲームサービス、オンライン教育アプリケーションなどで自動スケーリングを有効にできます。ワークロードのスケーリングは、Pod レプリカの数やワークロードに割り当てられるリソース量を自動的に調整し、ワークロードの要件を満たします。ワークロードのスケーリングは、トラフィックの急増に対応し、リソースコストを削減するのに役立ちます。
注意事項
このトピックでは、運用保守エンジニアと開発者向けにワークロードのスケーリングとノードのスケーリングについて説明します。まず、Horizontal Pod Autoscaler (HPA) や Vertical Pod Autoscaler (VPA) などの Kubernetes コミュニティが提供するスケーリングソリューション、および Cluster Autoscaling などのノードスケーリングソリューションについて理解しておくことを推奨します。
ご利用のクラスターに 500 を超えるノードまたは 10,000 を超える Pod がある場合は、「クラスターリソースのスケーリングレートの計画」に記載されている注意事項を参照して、クラスターとそのコントロールプレーンの安定性を確保してください。
ワークロードのスケーリングと計算リソースのスケーリング
Container Service for Kubernetes (ACK) の自動スケーリング機能は、以下の側面から弾力性を提供します：
ワークロードのスケーリング：これはスケジューリングレイヤーのソリューションであり、Pod レベルで動作します。ワークロードの変動に基づいて Pod の数や Pod に割り当てられるリソース量を動的に調整します。たとえば、HPA はトラフィックの変動に応じてアプリケーション Pod の数を自動的に調整し、現在のワークロードが占有するリソース量をさらに調整できます。
計算リソースのスケーリング：これはリソースレイヤーのソリューションであり、ノードのスケーリングと仮想ノードのスケーリングで構成されます。このソリューションを使用すると、Pod のスケジューリング結果とリソース使用量に基づいて、アプリケーションに割り当てられるリソース量を増減させることができます。
上記ソリューションを組み合わせて使用することを推奨します。これにより、Pod レプリカをスケーリングしてリソース使用率を向上させ、クラスター内の計算リソースをスケーリングして Pod のリソース要件を満たすことができます。
ワークロードのスケーリングソリューション
kubectl scale コマンドを実行して、Pod の数を手動で調整できます。この方法は、一時的なスケーリング要件に適しています。次の表は、ビジネスシナリオに基づいて ACK が提供するワークロードのスケーリングソリューションの中から選択する方法を説明しています。これらのソリューションを使用して、コスト管理、安定性の向上、柔軟なリソース管理などの要件を満たすことができます。
ソリューション | 説明 | スケーリングメトリック | シナリオ | 関連ドキュメント |
HPA | HPA は、ピーク時に Pod をスケールアウトしてトラフィックの急増に対応し、オフピーク時に Pod をスケールインしてリソースコストを削減します。HPA はほとんどのシナリオに適しています。 |
| HPA は、e コマースサービス、オンライン教育、金融サービスなど、トラフィックの変動に対応するために頻繁なスケーリングを必要とする多数の Pod を含むオンラインサービスに最適です。 | |
CronHPA | CronHPA は、Crontab のような戦略を使用して、事前に定義されたスケジュールに基づいて Pod をスケーリングします。スケジュールには、スケーリングを実行するタイムゾーンと日付を指定できます。また、祝日などの日付をスケジュールから除外することもできます。CronHPA は HPA と組み合わせて使用できます。 | スケジュールされたスケーリング | CronHPA は、トラフィックパターンが予測可能なアプリケーションや、スケジュールされた時間にタスクを実行する必要があるシナリオに最適です。 | |
VPA | VPA は、Pod のリソース消費パターンを監視し、CPU とメモリの割り当てに関する推奨事項を提供します。VPA はリソース割り当てを調整しますが、Pod レプリカの数は変更しません。 | VPA は、Pod の CPU リクエスト、CPU リミット、メモリリクエスト、メモリリミットに関する推奨事項を提供します。さらに、VPA は上記のリソースリクエストとリミットを自動的に調整できます。 | VPA は、ステートフルアプリケーションのスケールアウトや大規模なモノリシックアプリケーションのデプロイなど、安定したリソース割り当てが必要なシナリオに最適です。ほとんどの場合、VPA は Pod が異常から回復したときに有効になります。 | |
Kubernetes-based Event Driven Autoscaling (KEDA) | KEDA は、豊富な種類のイベントソースをサポートし、ワークロードのイベント駆動型自動スケーリングを可能にします。 | キューの長さなどのイベント数。 | KEDA は、即時スケーリングが必要なシナリオ、特にイベントベースのオフラインジョブに最適です。たとえば、オフラインのビデオおよびオーディオのトランスコーディングジョブ、イベント駆動型ジョブ、ストリーム処理ジョブに対して KEDA を有効にできます。 | |
Advanced Horizontal Pod Autoscaler (AHPA) | AHPA は、ワークロードの変動パターンを自動的に学習し、過去のメトリックデータに基づいてリソース需要を予測することで、予測スケーリングの実装を支援します。 |
| AHPA は、ライブストリーミング、オンライン教育、ゲームサービスなど、トラフィックが周期的に変動するシナリオに最適です。 |
上記のソリューションに加えて、UnitedDeployment コントローラーを使用してワークロードを定義できます。UnitedDeployment コントローラーを使用すると、複数のサブセットで同じタイプの複数のワークロードを柔軟かつ便利に管理できます。これにより、各サブセットの Pod レプリカの数を動的に調整できます。UnitedDeployment コントローラーを上記のソリューションと組み合わせて使用することで、複数のタイプの計算リソースが使用されるシナリオで、柔軟なワークロードのスケーリングとスケジューリングが可能になります。詳細については、「UnitedDeployment を使用したワークロードのスケーリング」をご参照ください。
計算リソースのスケーリング
トラフィックの変動に対応するために即時のスケーリングが必要なシナリオでは、ワークロードの変更に基づいてクラスターが計算リソースを自動的に調整できるようにする必要があります。これにより、ビジネスの弾力性が向上し、運用保守作業が削減されます。計算リソースのスケーリングコンポーネントは、保留中の Pod をリッスンして、Pod のスケジューリングに新しい ECS ノードまたは Elastic Container Instance が必要かどうかを判断します。
ノードのスケーリングの詳細については、「ノードのスケーリング」をご参照ください。
次の表に記載されているリソースデリバリーの統計は理論値です。実際値はご利用の環境によって異なる場合があります。
ソリューション | 説明 | シナリオ | リソースデリバリー効率 | 関連ドキュメント |
ノードの自動スケーリング | ノードの自動スケーリング機能を使用すると、クラスター内のリソースが Pod のスケジューリングを満たせない場合に、ACK が自動的にノードをスケーリングできるようになります。 | ノードの自動スケーリング機能はすべてのシナリオに適しており、特にオンラインサービス、ディープラーニングタスク、小規模なスケーリングアクティビティ、および毎回 1 回のスケーリングアクティビティのみを必要とするワークロードに最適です。たとえば、自動スケーリングが有効になっているノードプールが 20 未満のクラスターや、自動スケーリングが有効になっている各ノードプールに 100 未満のノードが含まれている場合に、ノードの自動スケーリングを有効にできます。 | クラスターに 100 ノードを追加するのに必要な時間：
| |
ノードの高速スケーリング | ノードの自動スケーリングと比較して、ノードの高速スケーリングは、より高速なスケーリング速度、向上したスケーリング効率、およびより高いリソースデリバリーの成功率を提供します。さらに、ECS インスタンスの在庫に基づいてノードの高速スケーリングの健全性ステータスを表示できます。ノードの自動スケーリングとノードの高速スケーリングの比較に関する詳細については、「ソリューションの比較」をご参照ください。 | ノードの高速スケーリング機能はすべてのシナリオに適しており、特に大規模クラスターや、より高速なリソーススケーリング、複数のインスタンスタイプとゾーンにまたがる自動スケーリング、およびトポロジ分散制約などの高度なスケジューリング戦略を必要とするクラスターに最適です。クラスター内の自動スケーリングが有効になっているノードプールに 100 を超えるノードが含まれている場合、またはクラスターに自動スケーリングが有効になっているノードプールが 20 を超える場合、そのクラスターは大規模と見なされます。 | クラスターに 100 ノードを追加するのに必要な時間：
| |
仮想ノード | 仮想ノードにより、ノード管理や容量計画が不要になります。仮想ノードを使用すると、クラスターに最大 50,000 個の Pod をデプロイできます。仮想ノードを使用してアプリケーション Pod をスケールアウトし、トラフィックの急増に対応できます。アプリケーションをスケールアウトすると、1 分以内に最大 10,000 個の Pod を作成できます。 | 仮想ノードはすべてのシナリオに適しており、特にタスク、スケジュールされたタスク、データコンピューティングジョブ、AI アプリケーション、およびワークロードの急増が存在するシナリオに最適です。 | クラスターに 1,000 個の Pod を作成するのに必要な時間：
|
課金
自動スケーリング機能は無料です。自動スケーリングコンポーネントは Pod にデプロイされるため、クラスターに少なくとも 1 つのノードをデプロイする必要があります。自動スケーリング機能を使用して追加されたノードに対して課金されます。詳細については、「課金の概要」をご参照ください。
よくある質問
自動スケーリング機能に関するよくある質問への回答の詳細については、「自動スケーリングに関するよくある質問」をご参照ください。
関連ドキュメント
事前インストールや高性能が要求されるシナリオでは、カスタム OS イメージを使用して自動スケーリングを容易にすることができます。詳細については、「カスタムイメージの作成」をご参照ください。
自動スケーリングログの収集方法の詳細については、「システムコンポーネントのログファイルの収集」をご参照ください。
ワークロードを設定する際は、「推奨されるワークロード構成」で提供されている提案に従うことを推奨します。
サーバーレスコンテナを使用するシナリオでは、Knative を設定して、リクエスト数と同時に処理されるリクエスト数に基づいてスケーリングアクティビティをトリガーできます。リクエストが受信されない場合、Knative は自動的に Pod の数をゼロにスケーリングします。詳細については、「Knative」および「トラフィックの変動に耐えるための自動スケーリングの有効化」をご参照ください。