K8S ベースのクラウド ネイティブ アーキテクチャのコスト最適化ガイド

鄭漢

ララムーブテクノロジーセンターコアインフラ部門

建築家

• Huolala では、Kubernetes 実装のプロセス全体を 0 から 1 まで主導し、Huolala の特性に合ったクラウド ネイティブ アプローチの探求に尽力しました。

今日の共有には主に次の 5 つの側面が含まれます。

1. フオララの基本情報

2. K8Sに基づくコスト最適化手法

3. Lalamoveの特性に合わせたコスト最適化ルート

4. スポットインスタンスコスト最適化の実践

5. 計画的な拡張と縮小のコスト最適化の実践

1. フオララの基本情報

探索中 この最適化 前に  、私たち 最初に来る 見てください ララムーブ ベース 元の状況 条件、let  みんな  Huolala について予備的な理解を深めます。

• Huolala の運用環境は 100% パブリック クラウド上で実行されるため、コストの最適化もパブリック クラウドを対象としています。
• Lalamove は世界的なインターネット企業です。当社の事業は世界中に広がっています。当社はシンガポール、インド、ラテンアメリカ、中国にクラスターを持っているため、異なるクラウドベンダーで複数のクラスターを実行する必要があります。これにより、当社のすべてのソリューションは普遍的であり、特定のクラウド ベンダーに縛られないことが求められます。
• Huolala の交通量は比較的規則的で、明らかなピークと谷があります。一般的に、貨物輸送業界では交通量の急増を引き起こすような突発的な出来事は発生しません。これは、有名人が突然ゴシップを流して大勢の人を引き付け、トラフィックが急増するようなWeiboのようなサービスとは異なります。一方、市内貨物輸送は日の出から日没まで稼働する産業であるため、日中のピーク時には交通量が比較的安定しており、夜間のオフピーク時には交通量が非常に少なくなります。このようなトラフィック特性により、単純な予測アルゴリズムを通じてより優れた予測結果を達成できます。同時に、オフピーク期間のコスト最適化も最適化の焦点となります。
• Huolala にはオフラインのビッグデータ タスクも多数あり、それが当社のコンピューティング リソースの約半分を占めています。ピーク期間はビジネスのオフピーク期間でもあるため、オフラインとオンラインのハイブリッド展開を通じて全体的なリソース使用率を向上させることも、当社の最適化の方向性の 1 つです。

2. K8Sに基づくコスト最適化手法

Huolala の基本的な状況を説明したあと、クラウドネイティブ時代の一般的なコスト最適化手法について見ていきましょう。私は主流のコスト最適化手法を 4 つのカテゴリに分類しています。

• プライベートクラウドのサーバーコスト最適化
• パブリッククラウドサーバーのコスト最適化
• サーバー利用の最適化
• サービスパフォーマンスの最適化

Huolala は 100% パブリック クラウド上で実行されるため、今回はプライベート クラウドの最適化については説明しません。サービスパフォーマンスの最適化は、高度にパーソナライズされた最適化であるため、今回の議論の範囲外となります。今回はパブリッククラウドのサーバーコスト最適化とサーバー利用率最適化を中心に解説します。

1. パブリッククラウドサーバーのコスト最適化

いわゆるパブリック クラウド サーバーのコスト最適化とは、実際には、企業の実際のニーズが満たされるようにしながら、サーバー インスタンスを可能な限り低価格で購入する方法についての研究です。

パブリック クラウド サーバーには通常、次の 3 つの優先モードがあります。

• 年間または月間パッケージ:  固定スケジュールでサーバーを購入するのは、安定性が高く、手頃なモデルですが、特に夜間は容量をまったく縮小できないため、柔軟性に欠けます。
• 貯蓄プラン:  このモデルは、実際には、最小時間消費を約束する代わりに割引を受けるというものです。安定性は保証されており、サーバーは自由にスケールアップまたはスケールダウンできますが、1 時間あたりの合計消費量は約束された消費量を下回ることはできません。一般的に、企業は最小需要に応じて購入します。
• スポットインスタンス:  スポット インスタンスは、クラウド ベンダーが固定割引または入札を通じて販売するアイドル インスタンスです。割引は通常10%または20%オフです。スポットインスタンスは価格が最も安く、オンデマンドインスタンスと同様に柔軟性がありますが、不安定であり、いつでもリサイクルされるリスクがあります。このようなインスタンスを使用すると、企業の技術力とサービス品質に高い要求が課せられます。

2. サーバー利用率の最適化

次に、サーバーの使用率を向上させるための一般的な最適化方法をいくつか見てみましょう。

1) 合理的な要求/制限

リクエスト/制限を科学的かつ合理的に設定する方法は、k8s を使用する際にすべての企業が直面する問題です。リクエストが大きく調整されすぎるとノードの使用率が低下し、小さく調整されすぎるとサービスが OOM になったり、強制排除されたりしやすくなります。一般的に言えば、最適化方法は 2 つのステップに分かれます。最初のステップは、アプリケーション プロファイルと過去の負荷に基づいて初期値を設定することです。 2 番目のステップは、定期的な検査のための検査メカニズムを確立し、実際の負荷と戦略に基づいて要求/制限の構成を動的に調整することです。

2) HPA

水平 POD は自動的に拡大および縮小します。指標としきい値を事前に設定してください。指定した指標が閾値を超えると自動的に容量を拡大し、閾値を下回ると自動的に容量を縮小します。たとえば、CPU が 35% を超えると容量が拡張されます。 HPA はバースト トラフィックの処理に非常に優れていますが、HPA の容量拡張には一定の遅延があります。負荷が急激に増加すると、容量を時間内に拡張できず、短期間で障害や雪崩が発生する可能性があります。

3) クローンHPA

水平方向の拡大・縮小の予定が分かりやすいです。時点とレプリカの数を設定するだけです。システムは、拡張時点で容量を拡張し、縮小時点で容量を縮小します。予測可能なシナリオや計画されたシナリオに適しています。

4) インテリジェントなスケジューリング

スマート スケジューリングとは、企業の実際のニーズに基づいてスケジューラーを強化することを指します。 k8s のデフォルトのスケジューラは比較的シンプルですが、一般的に企業のニーズを完全に満たすことはできず、実際の負荷認識、重み計算への次元の追加、ディスク GPU、スタッキング戦略の最適化など、最適化の余地がまだたくさんあります。企業の実際の状況にもっと合ったスケジューリング アルゴリズムを最適化することで、ノード リソースの使用率を効果的に向上させることができます。

5) オフラインハイブリッド展開

オフラインとオンラインのハイブリッド展開は、オフライン タスクが中断される可能性があり、そのピーク時間がオンライン サービスのピーク時間と逆であるという事実を利用して、サーバーのコンピューティング能力を最大限に活用する方法です。オフライン タスクは通常夜間に実行されるため、オフライン タスクとオンライン サービスを k8s クラスターに統合すると、オンライン サービスのオフピーク期間中のリソースの浪費を補うことができます。同時に、オフライン タスクがいつでも中断をサポートできる場合は、自動回避とリソース分離を通じて、アイドル リソースを使用してピーク時にオフライン タスクを実行し、サーバーのパフォーマンスを最大限に引き出すことも可能になります。しかし、この機能はサーバーの使用率を大幅に向上させる一方で、大きな技術的課題をもたらしました。

3. Lalamoveの特性に合わせたコスト最適化ルート

上記の業界のベストプラクティスと Huolala の実際の状況を組み合わせることで、次のような Huolala コスト最適化の進化の道筋を探りました。

まず、節約プランを通じて比較的有利な価格で Huolala の基本的なコンピューティング能力と安定性を確保し、次に低コストでスケーラブルなスポットインスタンスを使用して、弾力的にスケーラブルなコンピューティング能力を提供しました。もちろん、スポットインスタンスによってもたらされる安定性の課題にも対処する準備はできていました。これにより、サーバー価格の最適化の問題は基本的に解決されました。

次に、サーバーの使用率の問題に対処する必要があります。

まず、オフピーク時の資源浪費の問題を解決する必要があります。先ほども述べましたが、Huolala のトラフィックは非常に規則的であるため、予測可能で計画的な弾性スケーリングを実現するために独自に開発した CronHPA を使用し、トラフィックが突然増加したときには HPA を使用して緊急時の容量拡張を実現します。これが私たちがやったことです。

私たちが現在取り組んでいるのは、アプリケーション プロファイルと過去の指標に基づいて適切なリクエストと制限を計算するインテリジェント リクエストです。この機能により、ピーク時のノードリソースの使用率が向上することを期待しています。

前の項目を完了した後、ノードのリソース使用率が大幅に向上したと考えています。残っているのは、最後の 1 マイルを完了し、インテリジェントなスケジューリングとオフライン ハイブリッド展開を通じてサーバーのパフォーマンスを最大限まで引き出すことです。これらの機能は2023年に完成し、その後もプロセス全体の最適化を進めていく予定です。

次に、すでに実行した 2 つの最適化に焦点を当てます。  スポットインスタンス そして 予定されている拡張と縮小。

4. スポットインスタンス

1. スポットインスタンスとは何ですか?

クラウドベンダーが提供するサーバーインスタンスが、物理的なコンピュータールームから仮想化されていることは誰もが知っています。物理的な計算機室なので、サーバーは比較的固定されており、提供できる計算能力も固定されています。しかし、購入するインスタンスの数は変動するため、クラウドベンダーには常にアイドル状態のコンピューティングパワーが残り、アイドル状態のサーバーが生み出す経済的価値は 0 になります。そのため、クラウドベンダーはこれらのアイドル状態のコンピューティングパワーを取り出し、割引価格または入札価格で販売します。これらの割引またはオークションにかけられたインスタンスは入札インスタンスです。

スポットインスタンスの起源はすべてのクラウドベンダーで同じですが、スポットインスタンスの価格計算方法はクラウドベンダーによって異なります。主な方法は 2 つあります。  固定割引 基本的に20％オフなので、わかりやすいです。もう一つは 入札  、入札がわかりにくいです。入札の基本的な流れをご紹介します。

2. 入札方法の紹介

スポットインスタンスを購入する際は、許容できる最大価格を記入します。その後、クラウドベンダーは、全員の見積もりと在庫に基づいて価格を計算します。この価格以上で入札した人は、この価格でインスタンスを購入できます。価格が価格より低い場合、購入は失敗します。上の写真の細部に気づいたかどうかはわかりません。写真全体の中で、価格のみが黒く表示されています。それは価格の計算方法がブラックボックスだからです。アルゴリズムを知っているのはクラウドベンダー自身だけです。私たちが知っているのは、彼らが最終的に価格を決めるということだけです。その価格は最低 10% オフから最高で割引なしまでさまざまです。

3. スポットインスタンスの原則

次に、スポットインスタンスを使用する際の基本的な原理について説明します。

まず、マシンモデルと許容可能な最大価格を記載した購入申請をクラウドベンダーに提出します。クラウドベンダーが、指定されたモデルの在庫があり、価格が当社の見積りよりも安いと判断した場合、インスタンスを当社に割り当て、購入が完了します。現時点では、通常通りご利用いただけます。

スポットインスタンスの通常の使用中、クラウドベンダーは在庫と価格の変化を監視します。リアルタイムの価格が当社の見積りよりも高い、または在庫が不足していることが判明した場合、中断信号が送信されます。信号を受信した後、ビジネスに影響を与えずにインスタンスがリサイクルされるようにするための対策を講じる必要があります。中断信号を受信して​​から数分後にインスタンスがリサイクルされます。

クラウドベンダーによってリサイクルのメカニズムは若干異なります。 AWS には、在庫不足が予測された場合に事前に通知し、対応する時間を増やす予測アルゴリズムがあります。 Alibaba Cloud には、スポットインスタンスが運用開始後 1 時間以内にリサイクルされないようにする 1 時間の保護メカニズムがあります。しかし、例外なく、私たちがやりたいことをやり終えるまで待ってリサイクルすることはありません。たとえば、サービスを移行するために別のマシンを購入したいが、移行前にそのマシンがリサイクルされる可能性があるとします。したがって、突然の中断に対処する手段は、ビジネスに影響を与えないように十分に迅速でなければなりません。

4. スポットインスタンスの特徴

スポットインスタンスの基本原理を紹介した後、スポットインスタンスの特徴をまとめてみましょう。

• お金に見合う価値があります。  オンデマンド インスタンスと比較すると、スポット インスタンスの価格は通常 10 ～ 20% のみです。リザーブドインスタンスと比較すると、スポットインスタンスの価格は通常 30 ～ 60% のみです。
• スポットインスタンスは、アイドル状態のリソースを割引価格で販売します。  アイドルリソースがない場合、それらを購入することはできません。クラウドベンダーは、購入したいときにいつでも在庫を持っているとは限りません。
• いつでも中断できます。  クラウドベンダーは、現在の市場価格と在庫を動的に検出します。在庫が不足したり、入札額が市場価格よりも低くなったりした場合、クラウド ベンダーはいつでもこれらのインスタンスを回収できます。

スポットインスタンスを使用する際の目標は、高いコスト効率です。保証されていない在庫といつでも中断が発生するという問題は、解決する必要があります。

5. スポットインスタンスとK8Sの組み合わせ 着陸

次に、スポットインスタンスを K8S に統合する方法と、スポットインスタンスによって発生する安定性の問題を解決する方法を紹介します。

まず、図から、k8s ノードを複数のノード グループに分割し、クラスター オートスケーラーを使用して弾性スケーリングを実行したことがわかります。オンデマンドインスタンス用のノードグループとスポットインスタンス用のノードグループがあります。これは、すべてのサービスがスポットインスタンスへのデプロイに適しているわけではないためです。スポットインスタンスでの実行に適さないサービスをデプロイするには、より安定したノードが必要です。同時に、スポットインスタンスの在庫が不足しているときに通常の業務をサポートするために十分なコンピューティング能力を提供するために、オンデマンドインスタンス用のノードグループも必要です。

次に割り込み回復部分を見てみましょう。スポットインスタンスを中断する必要がある場合、クラウドベンダーは中断信号を送信します。管理対象クラスターの場合は、クラウドベンダーが割り込み信号を独自に処理し、新しいノードの起動と古いノードのリサイクルを支援します。ただし、自作クラスタの場合は、このサービス内の割り込み問題を処理するために、割り込み信号処理サービスを独自に実装する必要があります。

私たちは Lalamove でホストされたクラスターですが、それでも通知ハンドラーを独自に開発しました。このサービスは主に、中断信号を収集し、中断頻度を監視して、その後のアラームや緊急計画の起動に使用します。

全体的なアーキテクチャは比較的シンプルですが、実際の使用時には最適化が必要な領域がまだ多くあることがわかりました。以下にいくつかの主要な最適化ポイントを紹介します。

6. スポットインスタンスの最適化ポイント

1) スポットインスタンスのモデルを追加する

スポットインスタンスの在庫は保証されていないと上で述べましたが、私たちにできることはプールを拡張することです。プールの数が多いほど、在庫不足の可能性が低くなるため、作成するノード グループは、より多くの可用性ゾーンとインスタンス モデルをカバーする必要があります。ただし、クラスター オートスケーラーの制限により、同じノード グループ内のノードの CPU とメモリは一貫している必要があることに注意してください。

2) ノードグループの優先度を設定する

現在、クラスターにはオンデマンド インスタンス ノード グループとスポット インスタンス ノード グループがあります。リソースが不足している場合はスポットインスタンスを優先的にポップアップし、スポットインスタンスがポップアップできない場合にのみオンデマンドインスタンスをポップアップしたいと考えています。これにより、スポット インスタンスの最大限の利用が保証されると同時に、スポット インスタンスの在庫が不足しているときにオンデマンド インスタンスが適時にポップアップ表示され、安定した業務運営が保証されます。

ここでは、クラスター オートスケーラーの優先度設定が使用されます。クラスター オートスケーラーの configmap でノード グループの優先度を設定し、スポット インスタンスの優先度を 20 に、他のノード グループの優先度を 10 に設定します。このようにして、CA は最初にスポット インスタンスをポップアップし、スポット インスタンスをポップアップできない場合はオンデマンド インスタンスをポップアップします。

3) ポッドアフィニティを設定する

スポット インスタンスはいつでも中断される可能性があり、中断されると、同じモデルのノードが同時に中断される可能性が非常に高いため、すべての卵を 1 つのバスケットに入れることは避け、同じサービスのポッドを異なるインスタンス、異なるモデル、さらには異なる可用性ゾーンに分散して、サービスのすべてのポッドが同時に削除され、サービスが利用できなくなることを回避するようにしてください。

ここではポッドのアフィニティ構成が使用されます。構成から、可用性ゾーンに最大の重み付けをし、次にインスタンス モデル、最後にインスタンス名が続くことがわかります。このようにして、k8s は同じアプリのポッドを異なるアベイラビリティーゾーンに分散しようとします。適切なノードがない場合、異なるインスタンスタイプに分散されます。それでも適切なノードがない場合は、別のインスタンスに分散されます。これにより、同じサービスのポッドの分散が最大化され、スポットインスタンスの中断によるサービスの利用不能を回避できます。

4) PDBを構成する

インスタンスの中断により同じサービスのポッドが同時に排除されるのを防ぐためにさまざまな対策を講じてきましたが、この状況を 100% 回避することはできないため、別の保険レイヤー、つまり PDB が必要になります。 PDB を使用すると、同じサービスのポッドのレプリカが同時にいくつ使用可能になるかを設定できます。下の図の構成では、サービス レプリカの 70% が正常であることが保証されます。このように、同時に削除する必要がある場合でも、k8s は少なくとも 70% のレプリカを強制的に使用可能にしながらローリング削除を実行し、プロセス全体を通じてサービスが利用可能であることを保証します。

ただし、この構成では、同時実行できるはずの削除がシリアル化され、ノードのドレイン時間に影響するため、ノードが実際にリサイクルされる前に移行プロセス全体を完了するのに十分な速さでサービスを開始する必要があることに注意してください。

5) 低優先度の一時停止ポッドを使用してクラスターのスペースを確保する

前述したように、割り込み信号を受信して​​からスポットインスタンスがリサイクルされるまでには、わずか 2 ～ 3 分しかかかりません。時間が経過すると、状況に関係なくインスタンスはリサイクルされます。したがって、インスタンスをリサイクルする前に、移行全体が完了していることを確認する必要があります。この2、3分の1秒がとても貴重です。移行の効率を改善する方法を見つけなければなりません。ただし、新しいノードの作成には少なくとも数十秒、最大で 1 ～ 2 分かかります。実際、新しいノードが準備されるまで待つのに多くの時間が無駄になります。したがって、割り込み信号を受信したときに古いノードを直接ドレインする方法を見つける必要があります。ただし、ノードをドレインするには、クラスターに、削除されたポッドをいつでも実行できるだけの十分なスペースがあることを確認する必要があります。十分なスペースを確保するには、優先度の低い一時停止ポッドを使用してクラスターのスペースを予約します。

k8s にはポッドの優先順位という概念があります。リソースが不足している場合、優先度の高いポッドが優先度の低いポッドを優先することができます。下の図から、Node1 と Node2 の両方にいくつかの低優先度の Pod が配置されていることがわかります。 Node1 が中断され、リサイクルされると、優先度の高い Pod が優先度の低い Pod を直接プリエンプトし、新しいノードの準備が整うのを待たずに高速起動を実現します。優先度の低いポッドはすべて保留中になり、容量の拡張がトリガーされるか、新しいノードの準備が整うまで待機してから開始され、予約済みのスペースが再作成されます。

以下は具体的な yaml です。ここでの優先度は、通常のポッドの優先度よりも小さければ、-1 である必要はありません。優先度の低いポッドの場合、重要なのは PriorityClassName を正しく入力し、実際の状況に応じてレプリカとリクエストの数を設定することです。

7. スポットインスタンスへの導入に適さないサービス

• シングルコピーサービス。  説明しなくても誰もがこれを理解します。
• 起動に時間がかかりすぎるサービス。  インスタンスがリサイクルされる前にサービスを開始できることを確認する必要があるため、サービスの起動時間は長すぎてはなりません。
• サービスの非正常なシャットダウンは許容されません。  どれだけ対策を講じても、インスタンスが空になる前にリサイクルされることを完全に防ぐことはできないため、正常に停止できず、それを許容できないサービスはスポットインスタンスへの展開には適さないことを認識する必要があります。
• ステートフル サービス。  ステートフル サービスは、ステートレス サービスに比べて移行の柔軟性がはるかに低くなります。さまざまな問題を回避するために、スポットインスタンスにステートフル サービスをデプロイすることはお勧めしません。

5. 今後の拡大と縮小

1. 背景

弾性スケーリングの本質は、サーバーの使用率を向上させることです。最適化を行わない Huolala クラスターの CPU 使用率を見てみましょう。

このグラフから、このクラスターの CPU 使用率は、日中のピーク時には 35% ですが、深夜の低ピーク時には 2.5% にしかならないことがわかります。 2 時にも小さなピークがありますが、これはこの時間帯に多数のスケジュールされたタスクが実行されているためですが、今のところは無視できます。現時点では、この利用率は仮想マシンの時代ではまだ比較的許容範囲内ですが、クラウドネイティブの時代では、この利用率を向上させる方法がまだたくさんあります。

私たちの最適化の目標は、ピーク期間中のノードの平均 CPU 使用率を 50% にし、オフピーク期間中のノードの平均 CPU 使用率を 30% にすることです。

2. デフォルトHPAのデメリット

通常のやり方では、HPA をインストールし、トラフィックが増加すると自動的に容量を拡張し、トラフィックが減少すると自動的に容量を削減することで、これらの問題を解決できるはずです。実際、私たちはこれを実行しましたが、すぐに問題を発見しました。

最初の質問は 能力拡大には一定の遅れが生じています。   HPA は、負荷がしきい値に達するまで待ってから拡張を開始する必要があります。負荷が急激に増加すると、拡張が間に合わない可能性があります。毎日午前 9 時と午後 2 時にトラフィックが急増します。このとき、HPA は容量を大幅に拡張しますが、大規模な拡張にはまずノードの大規模な拡張が必要となり、この 2 つの時点では拡張が遅くなりすぎます。毎日、この 2 つの時点で何らかのエラーが発生し、アラームがトリガーされます。

2番目の質問は 拡張の閾値は限られている  。日中にトラフィックが増加したときに拡張が可能な限り安定するようにするには、レプリカの最小数を低く設定しすぎて、夜間に CPU 使用率が増加しないようにする必要があります。時間内に容量を拡張するために、CPU しきい値を高く設定しすぎることはできません。値が高いと容量拡張時の応答が遅くなり、低く設定しすぎるとピーク時の CPU 使用率が低くなるためです。たとえば、HPA で CPU しきい値を 35% に設定した場合、ポッドの CPU 使用率は基本的に 35% を超えることはできません。35% を超えると、容量が拡張され、CPU 使用率が低下するためです。

3番目の質問は 膨張と収縮のタイミングは制御できません。   HPA は、構成された指標としきい値に基づいて完全に容量を拡張し、企業の特性に基づいて戦略をカスタマイズすることはできません。たとえば、Huolala の交通量は日中は比較的安定しています。日中のピーク時にリソースを浪費しても、安定性に影響を与えるような過度な拡大や縮小は望ましくありません。ただし、HPA ではそのような構成は提供されません。

3. クローンHPA+HPA

HPA に関する当社の実践経験と Huolala のビジネス特性を組み合わせ、自社開発の CronHPA+HPA の組み合わせである Huolala の特性に適した水平弾性スケーリング手法をまとめ、検討しました。

CronHPA は、設定された時間に応じて対応する HPA のコピーの最小数を調整し、予測可能または計画された弾性スケーリングを実現します。

Huolala のトラフィック パターンの特性を考慮し、タイミング + 過去の指標分析 + シンプルな予測アルゴリズムを通じて、独自に開発した CronHPA で、比較的高品質の事前拡張とスケジュールされた容量削減を実現できます。たとえば、午前 9 時にトラフィックが急増し始めた場合、午前 7 時から 8 時の間にクラスターをピーク レベルまで事前に拡張できます。午後 10 時以降はトラフィックが大幅に減少するため、容量を安全にスケールダウンできます。事前拡張を基盤として、日中に容量拡張ができなくなることを心配することなく、夜間にレプリカ数を極めて低いレベルにまで減らすことができます。

CronHPA はデプロイメントのレプリカ数を直接操作するのではなく、HPA のレプリカの最小数を操作します。これは、CronHPA がスケーリングのニーズを 99% カバーできるものの、1% のトラフィック急増の問題を解決するには、HPA の自動スケーリングが依然として必要だからです。トラフィックの急増はほとんど発生しませんが、HPA を使用すると、時折発生するトラフィックの急増に対して追加のバフを加えることなく、ピーク時にスケールダウンしたりレプリカの数を設定したりできるため、全体的なリソース使用率が向上します。

4. 建築

スケジュールされた拡張と縮小の原理を説明した後、スケジュールされた拡張と縮小のアーキテクチャについて説明します。

独自開発した hll-cronhpa-controller を K8S に導入し、CronHPA CRD を追加しました。ユーザーは主に CronHPA CRD を設定して弾性スケーリングを設定し、HPA の数やデプロイメント コピーを直接設定することはありません。 hll-cronhpa-controller は、CronHPA CRD オブジェクトの変更を監視します。新しい追加または更新が見つかった場合、HPA オブジェクトは同期的に変更されます。最小限のコピー数を除き、他のすべてのデータは直接送信されます。 CronHPA のすべてのビジネス ロジックは、最終的に HPA コピーの最小数の変更に反映されます。

CronHPA のビジネス ロジックは主に、hll-cronhpa-controller が cronHPA オブジェクトの構成に従って Prometheus から過去のインジケーター分析を取得し、アプリケーション管理プラットフォームから取得したアプリケーション ポートレートと構成センターから取得したスケーリング戦略に基づいて包括的な分析を行った後、適切なタイミングで対応する HPA オブジェクトに適切な最小数のレプリカを設定するというものです。少し抽象的かもしれません。

たとえば、現在、夜間にスケールダウンする必要があるサービスがあるとします。サービスの過去の夜間のリソース使用率を分析した結果、夜間はレプリカを 2 つだけに縮小できるという結論に達しました。同時に、アプリケーション ポートレートから、このサービスはコア サービスであり、構成センターのスケーリング ポリシーでは、コア サービスには少なくとも 5 つのレプリカが必要であることがわかります。この包括的な分析に基づいて、夜間に設定する必要があるレプリカの数は 5 です。

5. 実装パス

私たちの実装パスについてお話ししましょう。私たちが独自の研究を始めたとき、cronHPA+HPA アーキテクチャを選択しました。

最初の段階は完全に手動での構成です。トラフィックを分析してグローバルスケールインの時点とグローバルスケールアウトの時点を設定し、各サービスが経験に基づいてスケールイン比率を手動で推定します。この段階では、世界全体の容量が拡大と縮小を同時に行うため、拡大の瞬間にインフラにかかる圧力が比較的高くなります。同時に、手動で推定した削減率は依然として保守的すぎます。

第二段階は、過去の指標分析に基づいて拡大と収縮のタイミングを自動的に設定することで、拡大と収縮の圧力を効果的に分散し、拡大と収縮のタイミングをより合理的にすることができます。たとえば、一部のサービスは午後 6 時にトラフィックが不足する可能性があり、フェーズ 1 では午後 10 時まで待つ必要があります。規模を縮小する。

3 番目の段階では、appid に基づいて収縮率を自動的に計算します。縮小率の手動推定はまだ保守的すぎます。たとえば、ピーク時の 100 個のポッドのうち、夜間に必要なのは 10 個だけかもしれません。ただし、手動で推定すると、比率は一般的に 50 に縮小することが示されます。ただし、アルゴリズムによる自動計算ははるかに科学的です。さらに、過去の指標を分析することで自動計算を継続的に修正することができます。たとえば、計算後、夜間にはポッドが 2 つに縮小されます。しかし、過去の指標を分析すると、過去 7 日間、夜間に HPA が 3 つのポッドに容量を拡大するために使用されていたことがわかります。この場合、縮小されたレプリカの数は 8 日目に自動的に 3 に調整されます。

4 番目の段階では、低ピーク期間を自動的に識別します。以前は、オフピークの時間帯を手動で設定し、プログラムがこの時間帯内でスケールアップまたはスケールダウンする時間を選択していました。この段階で、各サービスのオフピーク期間を自動的に識別し、パーソナライズされたスケールダウンを実行できます。

第 5 段階は、段階的な自動スケーリングです。前のステージではすべてスケーリングのタイム ポイントが決定され、レプリカの数をターゲット数に直接スケーリングします。しかし、実際のトラフィックは徐々に変化します。この段階を通じて、ピーク期間が到来する前にトラフィックが増加するにつれてサービスがレプリカの数を徐々に増やし、トラフィックが減少するオフピーク期間中にレプリカの数を徐々に減らすことを実現できます。このステージと HPA の最大の違いは、HPA が指標としきい値に基づいているのに対し、cronHPA は予測に基づいていることです。

6. 将来の計画

最後に、弾性スケーリングに関する今後の計画についてお話しします。将来的には、エラスティックスケーリングによって、サービス初期化時にアプリケーションプロファイリングを通じて要件/制限とレプリカ数を自動的に設定し、過去の指標分析とアルゴリズムを通じてピーク時と低ピーク時に事前拡張とタイムリーな削減を自動的に実行できるメカニズムを形成できるようになることを期待しています。

バースト トラフィックが発生した場合は、その場で構成をアップグレードすることで、急速な垂直拡張を実現できます。インプレース構成のアップグレードと VPA の最大の違いは、ポッドを再起動する必要がないため、容量の拡張を数秒で実現できることです。ノード リソースが不足している場合は、HPA を通じて水平方向に容量が拡張されます。同時に、指標分析に基づいてサービス要件/制限とレプリカ数を継続的に修正し、完全に自動化された弾性スケーリングのクローズドループを実現します。