計算機システムの制御

拡張指令を出しても、新しいインスタンスはまだ起動中かもしれません。要求済み容量と利用可能容量を混同したり、保留中の操作を無視したりすると、過剰な調整を繰り返します。サンプリングと遅れ、制約を応用します。

状態と単位を選ぶ

待機リクエスト数を$q_k$、毎秒の到着率を${\lambda }_k$、1インスタンスの処理能力を$\mu$、利用可能数を$n_k$、時間幅を$\Delta t$秒とすると、流体近似は

$$q_{k+1}=\max \{0,q_k+\Delta t({\lambda }_k-\mu n_k)\}.$$

仕事量を連続分割でき、各個体が同質で能力一定と仮定します。個別の処理時間、実行中タスク、再試行、故障、負荷分散は含みません。滞留は説明できますが、実際のp99遅延を直接求めるモデルではありません。

$\mu =10,n=4,\lambda =70$なら毎秒30件増えます。容量の反映に20 sかかれば600件滞留します。7個へ増やしても到着と処理が釣り合うだけで、既存滞留は減りません。

推奨、指令、有効化を分ける

教材用の推奨式を

$$n_k^{\ast }=\lceil \frac{{\hat{\lambda }}_k+q_k/T_{\mathrm{clear}}}{\mu }\rceil$$

とします。到着率の推定値が新規仕事量、$q_k/T_{\mathrm{clear}}$が過去の滞留を解消する余力です。到着70、滞留600、解消目標30 sなら9個が必要で、7個ではありません。

これはKubernetes HPAの実装ではなく、任意の遅れに対する安定保証もありません。個数上限、変化率、起動遅延を別途考慮します。「目標個数を9にする」と「毎回9個追加する」も区別します。

到着率は20–100 sに20から70件/sへ増え、その後20へ戻ります。10 sごとに決定し、1個10件/s、最大12個です。指令は指定遅延後に順番に有効になります。縮小窓は最近の推奨値の最大を使います。拡張と縮小が同じ遅れを持つのは教材上の簡略化です。

平滑化の代償

許容幅は小さな変化を無視し、安定化窓は急な反転を抑え、変化率制限は容量変化を制約します。反復動作を減らせても、応答を遅くしたり空き容量を増やしたりします。移動最大値と移動平均は別の操作です。

HPAの基本比率は

$$n_{\mathrm{desired}}=\lceil n_{\mathrm{current}}\frac{m_{\mathrm{current}}}{m_{\mathrm{target}}}\rceil .$$

全体のアルゴリズムは、許容幅、欠測、準備未完了のPod、複数指標、拡縮動作も扱います。縮小安定化は窓内の最大推奨であり、単に低い値が数回続くことを要求する方式ではありません。設定項目と既定値は使用バージョンで確認します。HPA公式仕様

滞留、使用率、遅延は交換できない

低CPU使用率はI/O待ちでも生じ、高CPUでも待ち行列があるとは限りません。平均・裾の遅延はサービス時間分布、スケジューリング、負荷に依存します。モデルなしの変換は帰還に測定誤差を持ち込みます。

適切な安定・長期平均の条件下で、Littleの法則は平均個数、実効通過率、平均滞在時間を結びます。瞬間の行列長を瞬間流量で割ってもp99ではありません。待ち行列理論で条件を詳しく扱い、ここでは仕事量の収支に限定します。

他の分野への移し替え

TCPはACK、損失、RTT、ECNなどから送信を調整し、往復遅延とアルゴリズム固有の状態を持ちます。すべてをPIDと呼ぶと詳細が失われます。TCPで観測と操作を特定し、元の方式を保ちます。

電源回路では電圧・電流、蓄積エネルギー、補償回路が動特性を作ります。共通なのはモデル化の方法で、同じゲインではありません。

理解を確かめる

毎秒70件到着、1個10件処理、滞留600件で、7個ならいつ空になりますか。

縮小窓は長いほどよいですか。

実践での確認

指標の時刻、取得、決定、指令、実際の有効化を記録し、保留操作を重複計算していないか確認します。通常負荷、突発、過負荷、コールドスタート、欠測を再生して評価します。良好な結果は試験条件での根拠であり、全負荷への保証ではありません。