← 概念解説に戻る

Concept Fable

自動スケーリング

先に結論:自動スケーリングは負荷、キュー長、CPU、GPU、リクエスト指標に応じてリソース数を動的に調整し、コストと性能のバランスを取る。LLM/Agent プラットフォームでは、autoscaling は API workers、GPU 推論インスタンス、タスクキュー、embedding サービス、検索ノード、ブラウザ実行者を対象に展開されることがあり、コールドスタート、並行性、遅延、優先度、予算上限を組み合わせて設計する必要がある。

Autoscaling · 運用/インフラ

まず物語を読む。ここでは急いで定義を示さず、まず問題そのものを立ち上がらせる。

寓話

昼のピークが来ると、麺屋はただ人を急かすだけでは済まない

東街の麺屋は普段、鍋が二つ、テーブルが三つ、給仕が一人しかいない。朝は客が少なく、みんなゆっくりで、麺も伸びない。昼時になると、埠頭の労働者がなだれ込み、行列は街の入り口まで伸び、鍋の湯はまだ沸いていない。

店主の第一反応は、店員に早く動けと叫ぶことだった。店員は汗だくで走り回ったが、それでも客は待ちきれずに帰っていった。翌日、彼は十人を固定で雇い、早朝から夜まで見張らせた。昼の時間帯は確かに安定したが、午後は店内ががらんとし、十人が二卓の客を囲んでぼんやりしていた。

経理係は注意を促した。問題は人の多さや少なさだけでなく、客足が起伏することだ。店主はまた感覚で隣人を呼んで手伝わせたが、しばしば呼ぶのが遅れた。人が来たときにはピークが過ぎ、あるいは人を引いた直後にまた船客の波が来た。

後に店主は入口に順番待ちの札を置き、かまどのそばに生地の数の札を置いた。二十人を超える行列ができたら第三の鍋を開き、四十人を超えたら裏庭の席を使い、半時辰連続で五卓を下回ったら臨時のかまどと手伝いを撤去する。

初めての雨の日、客足が突然崖のように落ちた。古い方法ではすべての帮工が閉店まで待ち続ける。新しい規則は牌の数に応じて縮小し、必要な人と鍋だけを残す。夕方に船団が岸に着くと、牌の数が再び上がり、裏庭はすぐに再開した。

麺屋は無限に大きな店になったわけでも、遊んでいるだけの固定チームを抱えたわけでもない。実際の負荷に応じて処理能力を増減させることを学んだ:忙しい時は広げ、暇な時は縮め、行列を崩さず、空席のそばでコストを燃やさない。

後に主人はさらに規則を加えた:拡張後は誰かが品質を見なければならない。第三の鍋が麺のスープを薄くし、裏庭の卓が配達ミスを生むなら、人数だけで拡張してはならない。処理能力を増やしても、各椀が基準通りに提供されなければならない。

隣町の酒場が真似をした時は、「人が多ければ人を増やす」だけを写し、すぐに暇な時間のコストが高すぎて損をした。麺屋の主人は理解した。伸縮の要点は、圧力を観察し、閾値を設定し、自動で増減し、コストと体験の間で制御可能に保つことだ。後に主人はもう一つの規則を加えた。拡張した後は誰かが品質を見なければならない。三つ目の鍋で麺のスープが薄くなるなら、裏庭の席で配膳ミスが出るなら、人数だけで拡張してはならない。処理能力が増えても、各杯の麺は基準通りに提供されなければならない。隣町の酒場が真似をした時は、「人が多ければ人を増やす」だけを写し、すぐに暇な時間のコストが高すぎて損をした。麺屋の主人は理解した。伸縮の要点は、圧力を観察し、閾値を設定し、自動で増減し、コストと体験の間で制御可能に保つことだ。

明らかにする

この物語が伝えるのは:自動スケーリング

自動スケーリングは負荷、キュー長、CPU、GPU、リクエスト指標に応じてリソース数を動的に調整し、コストと性能のバランスを取る。LLM/Agent プラットフォームでは、autoscaling は API workers、GPU 推論インスタンス、タスクキュー、embedding サービス、検索ノード、ブラウザ実行者を対象に展開されることがあり、コールドスタート、並行性、遅延、優先度、予算上限を組み合わせて設計する必要がある。

重要なのは、それが単なる用語ではなく、実際のAI/Agentシステムで繰り返し現れる構造的な問題だという点だ。これを理解して初めて、いつモデルを足すべきか、いつプロセスを変えるべきか、いつガバナンスを補うべきかを判断できる。

メタファーのマッピング

  • 麺屋の昼市:リクエストのピークとタスクキューの急増
  • 上司は早くしろと叫ぶ:既存の worker を加速させるだけの素朴な修正
  • 毎日十人を余分に雇う:静的な過剰予約容量
  • 長い行列を見てから呼ぶ:反応が遅すぎる手動スケーリング
  • 船の運航スケジュール、鍋の稼働率、出面の遅延:拡縮の指標と予測シグナル
  • 必要に応じて鍋架を増設:horizontal scaling と弾力的リソース
  • 夜に竈の火を収める:scale down でコストを制御する
  • 最終的な洞察:自動スケーリングは負荷シグナルで性能、コスト、安定性を動的にバランスする

Andy(任旭)判断

この概念の実戦的価値は、「賢く見えるAI機能」を納品可能、検収可能、ガバナンス可能な作業単位に分解する手助けをすることです。

水平スケーリングvertical scalingKubernetes HPAGPU scalingqueue depthlatency
京ICP备2026014272号