2022年1月24日
FinOps
Kubernetesクラスターの自動停止ルール
Harness Intelligent Cloud AutoStopping Rulesは、リソースを自動的に管理し、使用時のみ稼働させ、アイドル時には決して稼働させないようにします。
企業は通常、クラウドに対しておよそ35%の過剰支出をしています。そして、想定外のクラウドコスト支出を引き起こす最大の要因の１つは、未割り当てのリソースとアイドル状態のリソースです。もし、アイドル状態のクラウドリソースを使用していないときはオフにし、必要なときに再びオンにすることができたら、素晴らしいと思いませんか？これを自動化できたら？
ここでは、アイドル状態のリソースを動的かつ自動的に管理するHarness Intelligent Cloud AutoStopping Rulesを紹介します。自動停止ルールは、非運用リソースが使用時にのみ実行され、アイドル時には決して実行されないようにします。さらに、完全にオーケストレーションされたスポットインスタンスで、スポットの中断を心配することなくワークロードを実行することができます。自動停止ルールを設定すると、次のようになります。
- オフにするのを忘れていたクラウドリソースに支払わずに済みます。
- 非本番環境のクラウドリソースにかかるコストを最大70％削減できます。
- クラウドサービスの無駄遣いに支払わずに済みます。
AutoStopping Rulesの特徴 は？
AutoStopping Rulesは、非本番ワークロードのためのダイナミックで強力なリソースオーケストレーターです。クラウドリソースにAutoStopping Rulesを組み込むことで、以下のような大きなメリットが得られます。
- アイドル時間を自動的に検出し、リソースをシャットダウン（オンデマンド）またはターミネート（スポット）します。
- スポットの中断を気にすることなく、完全にオーケストレーションされたスポットインスタンス上でワークロードを実行できるようにします。
- 特に勤務時間中のアイドルタイムを静的に予測します。
- 強制的なシャットダウンでは不可能な、停止または終了したマシンへのアクセスを可能にします。
- コンピューティングの最適化を行わず、スタート／ストップの操作のみでクラウドリソースを停止します。
また、AutoStoppingダッシュボードを使用すると、作成した全ての自動停止ルールのサマリーをシンプルで直感的なインターフェイスで表示することができます。
AutoStopping Rules以前は、同様の問題に対応するのにリソーススケジューラーしかありませんでした。しかし、さまざまな模造品が出回っていました。
- アイドル時間を静的に予測できない
- チームが停止中のマシンにアクセスできない
- 最適化が最小限に留まる
AutoStopping Rulesのメリット
AutoStopping Rulesを採用することで得られる最も大きなメリットは以下の通りです。
- 測定可能なクラウド料金の削減で、実際に70%以上の削減が可能です。
- アイドル状態のリソースが稼働していないか、クラウドの無駄が発生していないかを自動でチェックします。
- 人為的なミスによる費用超過を防ぎます。
- リソースの使用後、シャットダウンや終了を意識しておく必要がありません。
- 初期設定後、手動での作業は必要ありません。
- 現在のインフラストラクチャーのプロビジョニング技術と容易に統合できます。
k8sクラスターでの自動停止ルールの使用
AutoStopping Rulesの力と特長について、ご理解いただけたと思います。それでは、AutoStopping Rulesがk8sクラスターにどのように役立つかを見ていきましょう。
AutoStopping Rulesは、以下をサポートしています。
- EKS（AWS）
- GKE（GCP）
- AKS（Azure）
自動停止ルールの作成手順は簡単です。
まず、自動停止ルールを使用して管理したいワークロードが実行されているクラウドアカウントを選択します（AWS、GCP、またはAzure）。
次に、自動停止ルールを定義します。ここで、リソースのアイドル時間も指定します。これは、自動停止ルールがアイドル状態のリソースを停止するまでに待機する時間です。
３つ目に、このルールを使用して管理したいリソースを選択します。また、高度な設定を指定することもできます。例えば、２つ以上の自動停止ルール間に依存関係を追加することができます。これは、１つのルールで、そのルールやトラフィックに基づいて１つまたは複数のルールをアクティブにする場合に便利です。
４つ目に、クラスターに適用するKubernetes自動停止ルールのリソース定義YAMLを更新します。
YAMLファイルの仕様は、KubernetesのIngress/Non-Ingressと同じで、メタデータが追加されています。これらは、自動停止ルールがServiceに対して作成するIngress/Non-Ingressの設定です。
自動停止を有効にした場合のIngressの例。
apiVersion: ccm.harness.io/v1
kind: AutoStoppingRule
metadata:
name: testK8s
namespace: default
annotations:
harness.io/cloud-connector-id: awstest3
nginx.ingress.kubernetes.io/configuration-snippet: 'more_set_input_headers
"AutoStoppingRule: default-testK8s";'
spec:
idleTimeMins: 15
hideProgressPage: false
ingress:
rules:
- host: <replace with your domain name, for example, qa.harness.com>
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: <replace your service name, for example, test>
port:
number: <replace with your service port, for example, 80>
自動停止を有効にした場合のNon-Ingressの例。
apiVersion: ccm.harness.io/v1
kind: AutoStoppingRule
metadata:
name: <postgres>
namespace: <dev-poc>
annotations:
harness.io/cloud-connector-id: <connector_id>
spec:
idleTimeMins: <40>
workloadName: <postgres>
workloadType: <Deployment>オートスケールと自動停止ルールの比較
オートスケールとは、需要の変化に合わせてリソースを自動的に増減させる機能です。 オートスケールには、cluster autoscalerやKarpenterなどのツールが使用されます。
cluster autoscalerは、以下の条件のいずれかに該当する場合、Kubernetesのクラスターサイズを自動的に調整します。
- リソース不足でクラスターでの実行に失敗したPodがある。
- クラスター内に長期間利用されていないノードがあり、そのPodを他の既存ノードに配置することができる。
Google Cloudによれば、cluster autoscalerはノードプール単位で動作します。cluster autoscalerでノードプールを構成する場合、ノードプールの最小サイズと最大サイズを指定します。
cluster autoscalerは、ノードプールの基礎となるCompute Engineのマネージドインスタンスグル ープ（MIG）内の仮想マシン（VM）インスタンスを追加または削除することによって、ノードプールのサイズを自動的に増減させます。cluster autoscalerは、ノードプールのノードで実行されているPodのリソース要求（実際のリソース使用率ではなく）に基づいて、このようなスケーリングの決定を下します。また、定期的にPodとノードの状態をチェックし、対処します。
- ノードプールに十分な数のノードがないためにPodがスケジューリングできない場合、cluster autoscalerはノードプールの最大サイズまでノードを追加します。
- ノードの使用率が低く、ノードプールのノード数が少なくても全てのPodがスケジュール可能な場合、cluster autoscalerはノードプールの最小サイズまでノードを削除します。タイムアウト期間（現在は10分）が経過してもノードを優雅に排出できない場合、そのノードは強制的に終了されます。
cluster autoscalerには、それなりの複雑さと制約があることはお分かりいただけたと思います。
しかし、AutoStopping Rulesは、最もきめ細かい範囲でクラウドのコスト削減を実現します。これは、非生産的なワークロードのためのダイナミックで強力なリソースオーケストレーターです。その独自性と機能については既に説明しました。
次の例は、定義されたルールに従って、k8sクラスターのアイドル状態のリソースがどのように処理され、自動停止されるかを示しています。アイドル状態のリソースを自動停止することで、リソースの累積節約量を表示します。
HarnessのAutoStopping Rulesソリューションは、特定の条件下では、定義されたルールに関係なくリソースを稼働させることが必要な場合があることも認識しています。ECGハートビートエージェントや固定スケジュールをルールと一緒に設定することで、このような場合の解決策を提供することができます。
ECG
自動停止ルールを使用すると、アイドル状態のクラウドリソースを自動的にオフにし、必要なときに再びオンにすることができます。さらに、アイドル状態のリソースを停止する前に、自動停止ルールが何分待機すべきかを定義します。
デフォルトでは、自動停止ルールはHTTP/HTTPSトラフィックをリッスンします。一方、リソースが機械学習（ML）などの長時間稼働するバックグラウンドジョブで作業している可能性があります。この場合、ネットワークトラフィックのみを使用してリソースのアイドル状態を検出することは 、最適な戦略とは言えない場合があります。そこで、ECGと呼ばれるハートビートエージェントに自動停止ルールを設定することができます。
さらに、ECGをイベントエミッターまたはルールのリスナーとして想定することができます。ECGは、設定されたルールの使用記録を送信します。
ECGには、以下のウォッチャーがプリインストールされています。
- 指標
- プロセス
ルールにメトリックウォッチャーまたはプロセスウォッチャーを設定します。メトリクスウォッチャーでは、指定されたメトリクスのしきい値に達するとハートビートシグナルを送信することができます。プロセスウォッチャーは、指定された条件に一致するプロセスの存在を監視します。
メトリクスの例
# A heartbeat will be sent when the metrics are greater than or equal to the configured threshold
[metrics]
cpu = "40"
memory = "5Gb"
プロセスの例
# A heartbeat will be sent when a process with the matching condition is found
[process]
condition = "python*"
固定スケジュール
固定スケジュールは、AutoStopping Rulesでもサポートされています。特定のシナリオにおいては、リソースをダウンまたはアップさせたくないことがあります。例えば、毎週金曜日の午後５時にABCリソースを停止させたいとします。AutoStopping Rulesは、これを非常に簡単に実現します。ABCリソースのダウンタイムをスケジュールできます。この時間帯は、定義されたルールに関係なく、リソースが強制的に停止されます。さらに、同じ方法でリソースの稼働 時間を指定することもできます。
アイドル状態のクラウドリソースの管理を開始する
ここまで来たら、このインテリジェントな自動クラウドコスト管理ソリューションをどのように使い始めるか知りたいですよね。
- デモを申し込むだけで、Harnessの担当者がHarness Cloud Cost Managementを使い始めるお手伝いをします。
- k8sリソースの自動停止ルールの作成方法について詳しく知りたい場合は、こちらのドキュメントを参照してください。
この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。