Knative v0.3 オートスケーリング — 愛の物語 ¶
公開日：2021年10月6日、 更新日：2024年1月17日
Knative v0.3 オートスケーリング — 愛の物語¶
著者：Google のソフトウェアエンジニア、Joseph Burnett
Knative v0.3 オートスケーリング — 愛の物語
Knative v0.3 リリースのスケーリングには、オートスケーリングサブシステムをカスタマイズするための新しいオプションが含まれています。すぐに使えるスケールツゼロのデフォルトから、オートスケーリングシステム全体を置き換える機能まで、そしてその間のすべて。 Knativeの新しいカスタムリソースであるPodAutoscalerは、アプリケーションを設定するための拡張ポイントと制御ポイントを提供します。
これらのオプションを説明するために、Webアプリケーションの初期段階から複雑なオートスケーリングまでの進化を見ていきましょう。「Knative オートスケーリングはあなたと共に成長します」ことをお約束します。
シンプルに保ちたい
ある朝、あなたはベッドで突然起き上がり、人々が本当に求めているものは…愛であることに気づきます。あなたは、任意の画像にハート型のウォーターマークを適切な場所に適用する簡単なWebアプリケーションを作成します。あなたは精通した最新のアプリケーション開発者であるため、それをコンテナにドロップし、 `gcloud run deploy --image gcr.io/joe-does-knative/love` を使用してGKEのKnativeサービスで起動します。
これがあなたのKnativeサービスの外観です
あなたはそれをあなたの親友に見せ、彼らはそれをHacker Newsに投稿します。ほら、あなたはハッカーのインターネットのフロントページにいます！ HNはあなたにハグ・オブ・デスを与えようとしますが、あなたのアプリケーションとクラスターはシームレスに1000 op / sのトラフィックを処理するためにスケールアップします。しばらくすると、興奮は収まり、サービスは1時間あたり1〜2リクエストを受信するようになります。幸いなことに、Knativeは未使用時にはゼロポッドにスケールダウンするため、アイドル状態のプロセスを実行するためにお金を費やすことはありません。そして、最初のデプロイメントの後、何も変更していません！それは簡単でした。
消えないでください
数週間後、再び雷が落ち、あなたは気づきます…「これで収入を得ることができる」。明らかに人々はハート型のウォーターマークを楽しんでいました。おそらく、人々があなたのサービスを使用してWebサイト全体の画像にウォーターマークを付けることができるようにするでしょう！ Rubyスクリプト（そうです、Rubyです）の前にクイックインメモリキャッシュを追加して、再デプロイしてから、製品を一般的な画像処理サービスとして宣伝し始めます。物事はうまくいっていますが、トラフィックは予測不可能であることにすぐに気づきます。それはたくさんバーストします。そして、サービスが0ポッドにスケールダウンし、後でトラフィックが再開すると、最初の数分間はキャッシュの再構築に費やされ、リクエストレイテンシが少し高くなります。そこで、Knativeサービスのリビジョンテンプレートにアノテーションを追加して、常に少なくとも2つのポッドを維持することにしました。
これがあなたのKnativeサービスの現在の外観です
物事はゼロにスケーリングしていません。しかし、それはあなたがベンチャーから少しのお金を稼いでいるので大丈夫です。
事態は加熱しています
うわー！トラフィックが増え始めています。あなたは平均約500 op / sで、時刻によっては10〜50ポッドの間で実行しています。このジョブはほとんどCPUバウンドであり、すべてのリソースを可能な限り効率的に活用していないことに気づきました。そこで、デフォルトのオートスケーリングターゲットにいくつかの調整を行います
しかし、最終的には、マシンをホットに保つためにCPUでスケーリングする必要があると結論付けます。そこで、まったく異なるKnativeオートスケーリングクラスを選択します。クラスアノテーションは、Kubernetes Ingressのように、Knativeに異なるPodAutoscalerコントローラー実装を使用するように指示します。
これがあなたのKnativeサービスの現在の姿です
60％のCPUで常に実行されているため、実際には支出よりも多くのお金を稼ぎ始めています！そこで、あなたはハート型のウォーターマークをフルタイムで追求するために、あなたの仕事を辞めました。
真剣に取り組もう
事態は複雑になっています。専門家の助けを求めて、あなたはサービス業務を支援するためにマーク博士を雇います。彼が最初に実装することの1つは、サービスのロールアウトモードです。もう見ないで飛躍することはありません！
マーク博士が舵を取っているので、物事は順調に進んでいます！数週間が経ち、大晦日が近づくと、指標に非線形的な成長が見られ始めます。マーク博士との簡単な相談で、あなたの最悪の恐怖が確認されます。人々は、大晦日に互いにハートのついた写真を送ることに夢中になります。そして、彼らはまるで愛のDDOS攻撃を調整しているかのように、すべて同時にそうします。あなたは計画を立てる必要があります。
幸いなことに、マーク博士はKnative Servingのリリースノートを読み込んでおり、既存のKnativeリビジョンでPodAutoscalerの編集を試みています。 PodAutoscalerは、KnativeがKnativeリビジョンのオートスケーリング状態と構成を保持する場所です。そして、Knativeリビジョンとは異なり、それは変更可能です（意図的に）。あなたは、世界中で発生するそれぞれの新年イベント（そうです、24回発生します！）に向けてトラフィックが増加するにつれて、トラフィックの少し前に容量を増やす計画を立てます
大晦日の夜、新年はタイムゾーンをまたいで進んでいきます。最初の新年イベントでは、CPU使用率の目標値60%が高すぎるため、数分間のエラーが発生します。しかし、次のイベントのために目標値を40%に調整すると、その後の夜は順調に進みます。やったー！ 🎉
あなたは特別な存在です
丸一年が経ち、状況は大きく変化しました！ いくつかの主要な画像ホスティングWebサイトと緊密に統合した結果、それらがトラフィックと収益の約80%を占めるようになりました。少し時間をかけて、自動スケーリングの統計を分析し始めます。すると、アップストリームのリファラーによって観測されたトラフィックが、トラフィックパターンをほぼ完璧に予測していることに気付きます。しかも、API統合を通じてこれらのメトリクスを取得できるのです！
しかし、CI/CDパイプラインはKnativeで動作するように実装されています。そして、これまでの運用経験はすべてKnativeワークロードの実行に関するものです。独自の自動スケーリングアルゴリズムを実装するためだけに、これらすべてを捨てるのはもったいないことです。しかしその時、Mark博士がKnative v0.3を調べ始めた頃に言っていたことを思い出します。PodAutoscalerカスタムリソースを使用すれば、Knative Servingシステムの他の部分を変更することなく、独自のリコンサイラーと自動スケーリングシステムを実装できるのです。さあ、これで解決です！
Kubernetesのsample-controllerを少しコピーするだけで、独自のKnative PodAutoscalerクラスで動作するリコンサイラーを実装できました。アップストリームのメトリクスをクエリして、予測的にスケーリングを行います。
Knativeサービスを接続するために変更する必要があるのは、以下のとおりです。
コントローラーとオートスケーラーの作成は困難です。しかし、それはビジネスの中核となる問題であり、あなたはそれを稼働させました。しかも、この特定の自動スケーリングの問題とは関係のない他のすべての部分を触る必要はありませんでした。ここ数年、Knativeがビジネスと共にどのように成長してきたかを考えると、「選択肢はたくさんあるけど、Knative… あなたが一番だ！」と言わざるを得ません。
何が起こったのですか？
PodAutoscalerの仕組みとKnativeの自動スケーリングのオプションについて詳しくは、KubeConの講演Knative: Scaling From 0 to Infinityをご覧いただき、GitHubのコードをご確認ください。または、Knative Servingの自動スケーリングのサンプルで試してみてください。
これは、他のKnativeエンティティとの関係におけるPodAutoscalerの位置付けです。
