Cloud AutoStoppingがKubernetesクラスターの自動スケーリングを補完してコストを節約する

このブログでは、Harness AutoStoppingとAutoscalingの定義から始め、両者がどのように補完し合っているのかを掘り下げて解説します。

企業がクラウドの使用を拡大するにつれて、クラウドコストの管理が不可欠になります。Harness Cloud Cost Managementは、人工知能と機械学習（AI/ML）を使用してクラウドリソースのアイドル時間を積極的に管理するインテリジェントなCloud AutoStopping™を備えており、非運用ワークロードのクラウド支出を最大80%削減します。

Harness CloudのAutoStopping機能とネイティブのKubernetesクラスターの自動スケーリング機能を区別する方法や、これら2つの機能を一緒に使用できるかどうかについてよく質問を受けます。それに対する答えは間違いなく「はい」です。なぜなら、それらはクラウド使用の2つの異なる側面に対処するからです。このブログでは、各機能を定義することから始め、次にそれらがどのように相互に補完するかを詳しく説明します。
 

Harness Cloud AutoStopping

開発リソースは、特にフルタイムで実行し続ける場合、クラウド支出のかなりの部分を消費します。エンジニアは24時間働いているわけではなく、開発リソースも同様です。ここで、アイドル状態の開発リソースの管理を自動化するために、Harness Cloud AutoStoppingが登場します。

Harness Cloud AutoStoppingは、手動によるリソーススケジューリングを越えて、クラウドリソースがアイドル状態になったことを検知し、ポリシー設定に基づいたアクションを実行する洗練された自動化された手法を提供します。Cloud AutoStoppingは、アイドル状態のワークロードを動的に停止させるだけでなく、そのワークロードにアクセスするユーザーを検出すると、透過的に再起動します。現在、Cloud AutoStoppingは、Amazon Web Services（EC2、ASG、ECS、RDS、EKS）、Microsoft Azure（Azure VM、AKS）、Google Cloud Platform（Compute Engine VM、Instance Group、GKE）、Kubernetesクラスターに対応しています。

ネイティブKubernetesクラスターの自動スケーリング

エンジニアがは１日24時間働くわけではなく、顧客も同様に、１日24時間何かを連絡するわけではありません。しかし、本番環境のSaaSアプリは、世界中の顧客からのリクエストに対応するために、フルタイムで利用できる必要があります。需要は予測できないものですが、日々のピークに対応できる大規模なクラスターを作るよりも（需要が少ないときに無駄なコストがかかる）、Kubernetesクラスターの自動スケールを使って、オンデマンドで対応する柔軟なアーキテクチャーの構築が可能です。

Kubernetesクラスターの自動スケーリングは、エンドユーザーの需要に基づいてクラスターのサイズを調整します。現在のワークロードの需要に合わせて本番クラスターにノードを追加または削除し、強力なパフォーマンスを確保しながらリソースの利用を最適化します。非本番環境の開発／テスト環境を本番環境のミラーリングにすることがベストプラクティスであるため、両環境でクラスターの自動スケーリングを有効にする必要があります。

では、Cloud AutoStoppingとクラスターの自動スケーリングはどう違うのでしょうか？建物の照明を例として考えてみましょう。週末に社員が全員退社すると、人感センサーがスイッチを入れて館内の照明を全て消し、誰かが入ってくると再び照明を点灯する。それが、Cloud AutoStoppingです。ただし、平日は部署によって勤務時間が違ったり、お客様がいらしたりするので、やはりある程度の明るさは必要です。しかし満席時ほどではないので、アクティブな需要に合わせて照明レベルを調整します。それが、クラスターの自動スケーリングです。

非本番リソースに対するCloud AutoStoppingの利点

KubernetesやAmazon Elastic Container Service（ECS）クラスターについては、製品環境でのアーキテクチャーは自動スケーリングをデフォルトの選択すべきです。ただし、非本番環境の場合、Cloud AutoStoppingにはクラスターの自動スケーリングに比べていくつかのコスト削減の利点があります。これらの利点には次のようなものがあります。

• より正確なメトリクスに基づく– Cloud AutoStoppingは、クラウドリソースへのリアルタイムのトラフィックアクセスに基づいて動作します。一方、自動スケーリングはCPUとメモリーのメトリクスを監視しますが、これはアクティビティーと使用量の正確なメトリクスではありません。特に、アイドル時でもバックグラウンドで実行するウォッチドッグプロセスを持つワークロードの場合、そのようなメトリクスはあまり意味がありません。
• ゼロまでスケールすることで節約効果を高める–Cloud AutoStoppingは、Kubernetesクラスターのワークロード全体またはECSタスクを停止し、新しいアクセス要求がきたときにそれらを再起動します。（訳注：一般的な）自動スケーリングは、アクティブなKubernetesワークロードレプリカ数、またはECSタスク数を、特定のサービスの事前に決定された最小ノード数（決してゼロにならない）までスケールダウンすることしかできません。サービスごとにKubernetesワークロードレプリカやECSタスクを１つでも維持するためのコストは、規模に応じて大きく蓄積されることになります。これに対し、Cloud AutoStoppingはより積極的にコストを削減できます。
• 依存関係のサポート–Cloud AutoStoppingでは、さまざまなリソースを管理する異なるサービスやルール間で依存関係を設定できます。その結果、トラフィックを直接受け取らない依存関係のあるサービスやリソースも、ネイティブのオートスケーリングでは実現不可能な、任意のエンドポイントでのトラフィックに基づいてゼロまでスケールダウンしたりシャットダウンできます。Harness Cloud AutoStoppingは、全体的なコスト削減効果を大幅に向上します。
   

クラウド利用を節約した例

Amazon ECS Fargateクラスターから、同じクラスター、または異なるクラスターにあるAmazon RDSデータベースとのサービスを考えてみましょう。Harness Cloud AutoStoppingは、トラフィックパターンに基づいて依存リソースをスケールダウンすることで、大幅なコスト削減を実現できます。この例の詳細については、以下の図を参照してください。

Cloud AutoStoppingとクラスターの自動スケーリングは連携できますか？

はい！Harness Cloud AutoStoppingとネイティブKubernetesクラスターの自動スケーリングは、実際に連携して相互に補完できます。テスト・開発クラスター環境は、本番クラスターが顧客の要求に確実に対応できるように、本番クラスターと同じ方法で自動スケーリングできる必要があります。そして、Cloud AutoStoppingを用いて、使わないときは完全にオフにします。これらのソリューションを統合することで、企業は非本番用ワークロードのコスト最適化とリソース効率の向上を実現できます。この相乗効果により、ユーザーは全体的なコストを削減しながら、よりきめ細かくインテリジェントな方法でクラスターを管理できるようになります。

今すぐHarness Cloud Stoppingとクラスター自動スケーリングの活用を始めましょう

Harness Intelligent Cloud AutoStoppingは、KubernetesやECSのネイティブクラスター自動スケーリング機能に加え、独特な機能を提供するものです。Cloud AutoStoppingと自動スケーリングを併用することで、組織は非本番働環境でのリソース管理とコストの最適化を強化できます。この２つの強力なソリューションを組み合わせることで、クラウドリソースをインテリジェントに、そしてコスト効率よく管理できます。

Harness Cloud AutoStoppingとHarness Cloud Cost Managementの詳細については、デモをリクエストするか、今すぐ無料で開始してください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。