この文章は、WavefrontでHorizontal Pod Autoscaler　シリーズの第一回目です。

シリーズ

第一回　：　概要編　← いまここ
第二回　：　Wavefront情報からスケールする
第三回　：　サーバーレスもどきを実装する

Wavefrontとはなんぞや？

WavefrontとはいうのはSaaSベースのクラウドおよびアプリケーションの監視プラットフォームです。
現在はVMwareに買収されており、Tanzu Observabilityと呼ばれています。
このシリーズでは、旧称のWavefrontを多用しますが同じものです。

Horizontal Pod Autoscalerとはなんぞや？

Horizontal Pod Autoscaler(HPA)とは、KubernetesでデプロイしたPODを負荷をモニターしてスケールアウトする機能です。

HPAを普通に使って何が悪いの？

さて、この機能でよく勘違いされるのが、k8sをインストールした直後にOOTB（Out of the Box)で使えないという点です。

通常はHPAを使えるようになるためには、なんらかのメトリクスを収集する別のツールが必要です。
有名なのが、metrics-serverです。

ただし、かかれている通り、CPU、Memoryにのみの対応です。
さらによくある問題として、「ほんとうにCPUがそのとき高かったの？」問題です。結局のところOpsチームはモニターダッシュボードをみていて、そのCPU、MemoryがうまくAutoScaleの事象に合わないといらぬコミュニケーション問題に発展しかねないです。

Prometheusは？

PrometheusをHPAのソースとして使うというのは昨今外国のブログで紹介されています。
例えば以下です。

ただし、これも注意しないといけないのが、Prometheusを本番業務に影響を与えるコンポーネントに昇格させてしまう点です。Prometheusの運用に慣れていない場合やHAの構成をとれていない場合、あまりお勧めができない構成となってしまいます。

じゃあどうするの？

そこでWavefrontですよ。
Wavefrontでは昨今のTanzu情勢から、kubernetesの連携を強めており、正式にHPAのアダプターをサポートしています。

英語ですが以下の動画でも取り上げて説明されています。

https://www.youtube.com/watch?v=nZnbdNHFNyU

これを使うことのメリットとして

Opsが見ているダッシュボードと同じメトリクスでHPAができる
CPU、Memory以外の好きなメトリクスで自由に定義できる
SaaSならではの、可用性(%99.95 Availability）とパフォーマンス保証

このシリーズはなんぞや？

HPAというものを長らく存在を知っておきながら、いまだkubernetesの飛び道具的存在であり、手を出すの躊躇していたのはきっと私だけではないはず。

このシリーズでは、WavefrontというSaaSモデルでサポートされているシステムでHPAを構成してみて、今一度HPAがどのように動くものなのか理解を深めるというものです。

次回は「Wavefront情報からスケールする」です。