[{"data":1,"prerenderedAt":312},["ShallowReactive",2],{"blog-ja-k3s-keda-hpa-event-driven-autoscaling-decision":3,"blog-related-ja-k3s-keda-hpa-event-driven-autoscaling-decision":268,"blog-ja-k3s-keda-hpa-event-driven-autoscaling-decision-alt":255},{"id":4,"title":5,"author":6,"body":7,"date":249,"description":250,"extension":251,"image":252,"locale":253,"meta":254,"navigation":255,"path":256,"seo":257,"stem":258,"tags":259,"__hash__":267},"blog\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision.md","CPU使用率は正常なのにリクエストが詰まる。KubernetesでHPAにKEDAを足すべきタイミング","Kubo Team",{"type":8,"value":9,"toc":235},"minimark",[10,15,23,34,43,47,53,62,70,73,77,83,91,96,99,103,112,116,119,128,132,138,145,172,175,188,201,215,218,221],[11,12,14],"h2",{"id":13},"cpu使用率は正常なのになぜリクエストが詰まるのか","CPU使用率は正常なのに、なぜリクエストが詰まるのか",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision\u002Fsection01.webp",[16,24,25,26,33],{},"KubernetesのHorizontalPodAutoscaler（HPA）を本番で運用していると、「CPU使用率もメモリ使用率も正常なのに、処理が追いついていない」という状況に出くわすことがある。原因は単純で、HPAは",[27,28,32],"a",{"href":29,"rel":30},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fworkloads\u002Fautoscaling\u002F",[31],"nofollow","Kubernetesの公式ドキュメント","が定義する通り、「観察されたリソース使用率（CPUやメモリ使用量など）に基づいてワークロードのレプリカ数を周期的に調整するコントローラー」であり、キューの滞留数やKafkaのコンシューマーラグといった「クラスタの外側」にあるシグナルを見ることができない構造になっているからだ。",[16,35,36,37,42],{},"典型的なのは、非同期ジョブワーカーやメッセージキュー処理を担うPodだ。CPU負荷は低いまま、処理待ちのメッセージだけが積み上がっていく。HPAにこの状態を検知させる方法はない。ここで登場するのが",[27,38,41],{"href":39,"rel":40},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2023\u002F08\u002F22\u002Fcloud-native-computing-foundation-announces-graduation-of-kubernetes-autoscaler-keda\u002F",[31],"CNCFの卒業プロジェクトであるKEDA","（Kubernetes Event-Driven Autoscaling）だ。KuboのようにK3sベースでKubernetesクラスタを運用している現場でも、この「HPAの死角」は同じ形で現れる。",[11,44,46],{"id":45},"kedaはhpaを置き換えるのではなく補完する","KEDAはHPAを置き換えるのではなく補完する",[16,48,49],{},[19,50],{"alt":51,"src":52},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision\u002Fsection02.webp",[16,54,55,56,61],{},"ここで多くのチームが誤解するのが、「KEDA vs HPA」を二者択一の比較だと捉えてしまうことだ。実際には",[27,57,60],{"href":58,"rel":59},"https:\u002F\u002Fkeda.sh\u002Fdocs\u002F2.21\u002Freference\u002Fscaledobject-spec\u002F",[31],"KEDA公式のScaledObject仕様","が明記している通り、KEDAはHPAを自動的に生成・管理する仕組みであり、HPAそのものを置き換えているわけではない。",[16,63,64,69],{},[27,65,68],{"href":66,"rel":67},"https:\u002F\u002Fgithub.com\u002Fkedacore\u002Fkeda",[31],"KEDAのGitHubリポジトリ","の説明でも、KEDAは「event driven Kubernetesワークロードのためのきめ細かいオートスケーリング（ゼロからのスケールも含む）」を実現するコンポーネントと位置づけられている。ScaledObjectというカスタムリソースを作成すると、KEDAはその定義に基づいてHPAリソースを裏側で生成し、外部イベントのメトリクスをHPAが参照できる形に変換して橋渡しする。",[16,71,72],{},"つまり構造としては、HPAが「スケーリングの実行エンジン」であり、KEDAはその手前に立つ「メトリクス翻訳レイヤー」だ。レプリカ数が1以上の領域ではHPAがスケーリングを主導し、0から1への立ち上げだけをKEDAが制御するという役割分担になっている。この構造を理解しないまま「KEDAを入れればHPAは不要」と考えると、併用設計でつまずく。",[11,74,76],{"id":75},"k3sで使い分ける判断基準3つの軸","K3sで使い分ける判断基準（3つの軸）",[16,78,79],{},[19,80],{"alt":81,"src":82},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision\u002Fsection03.webp",[16,84,85,90],{},[27,86,89],{"href":87,"rel":88},"https:\u002F\u002Fwww.plural.sh\u002Fblog\u002Fkeda-vs-hpa-guide\u002F",[31],"KEDAとHPAの比較ガイド","が提示する実践的な判断軸は、次の3つに整理できる。",[92,93,95],"h3",{"id":94},"_1-メトリクスソースがクラスタ内部か外部か","1. メトリクスソースがクラスタ内部か外部か",[16,97,98],{},"同期型のAPIサーバーやWebフロントエンドのように、CPU・メモリがそのまま負荷の指標になるワークロードはHPA単体で十分だ。一方、メッセージキューの深さ、Kafkaのコンシューマーラグ、外部クラウドサービスのキュー長といった「クラスタの外側」にあるシグナルでスケールしたい場合は、KEDAの出番になる。",[92,100,102],{"id":101},"_2-scale-to-zeroが必要かどうか","2. scale-to-zeroが必要かどうか",[16,104,105,106,111],{},"HPAには「1レプリカ未満にはスケールできない」という構造的な制限がある。常時起動のコストを許容できない非同期ワーカーやバッチ処理では、アイドル時にゼロまでスケールダウンできるKEDAの価値が大きい。",[27,107,110],{"href":108,"rel":109},"https:\u002F\u002Fcast.ai\u002Fblog\u002Fkeda-kubernetes-event-driven-autoscaling\u002F",[31],"KEDA導入によるコスト効果を分析した記事","でも、アイドル状態のPodを完全に削除できる点が最もインパクトの大きいコスト削減要因として挙げられている。",[92,113,115],{"id":114},"_3-負荷のバースト特性","3. 負荷のバースト特性",[16,117,118],{},"緩やかに増減する負荷であればHPAのポーリング周期でも追従できる。しかし、突発的でバースト性の高い負荷（セール開始直後の注文処理など）には、外部イベントをトリガーに即座に反応できるKEDAの仕組みが向いている。",[16,120,121,122,127],{},"多くの本番環境では、これらを二者択一にせず「同期サービスにはHPA、非同期ワーカーにはKEDA」という形で併用しているのが実情だ。K3sのような",[27,123,126],{"href":124,"rel":125},"https:\u002F\u002Fdocs.k3s.io\u002F",[31],"軽量Kubernetesディストリビューション","を使っている環境でも、この判断軸はそのまま当てはまる。",[11,129,131],{"id":130},"併用設計で事故らないための-pollinginterval-cooldownperiod-設定","併用設計で事故らないための pollingInterval \u002F cooldownPeriod 設定",[16,133,134],{},[19,135],{"alt":136,"src":137},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision\u002Fsection04.webp",[16,139,140,141,144],{},"HPAとKEDAを併用する際に実務上つまずきやすいのが、ScaledObjectのデフォルト値をそのまま使ってしまうケースだ。",[27,142,60],{"href":58,"rel":143},[31],"によれば、主要パラメータのデフォルトは次の通りになっている。",[146,147,148,156,162],"ul",{},[149,150,151,155],"li",{},[152,153,154],"strong",{},"pollingInterval","（デフォルト30秒）: 各トリガーをチェックする間隔。ただしこれは0→1スケーリングにのみ関与し、1→Nのスケーリングは下位で生成されるHPAが自身のポーリング周期（デフォルト15秒）で主導する",[149,157,158,161],{},[152,159,160],{},"cooldownPeriod","（デフォルト300秒）: 最後にトリガーがアクティブだったと報告されてから、スケールダウンを開始するまでの待機時間",[149,163,164,167,168,171],{},[152,165,166],{},"minReplicaCount","（デフォルト0）\u002F ",[152,169,170],{},"maxReplicaCount","（デフォルト100）: スケールの下限・上限",[16,173,174],{},"ここで注意すべきなのは、minReplicaCountが0より大きい設定になっている場合、ワークロードは決してゼロにはスケールされず、スケーリングの主導権は実質的にHPA側へ完全に移るという点だ。「KEDAを入れたのにscale-to-zeroが効かない」という事故の多くは、このminReplicaCountの設定ミスか、cooldownPeriodがコールドスタートの重いワークロードに対して短すぎることが原因になっている。pollingIntervalとcooldownPeriodの値を近づけておくことで、スケールアップとスケールダウンが交互に起きる「フラッピング」を防ぎやすくなる。",[16,176,177,182,183,187],{},[27,178,181],{"href":179,"rel":180},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Frun-application\u002Fhorizontal-pod-autoscale-walkthrough\u002F",[31],"HPA単体のwalkthrough","にある ",[184,185,186],"code",{},"kubectl autoscale deployment php-apache --cpu=50% --min=1 --max=10"," のようなシンプルな設定しか経験していないと、KEDAを足したときにこのパラメータ間の依存関係を見落としがちだ。併用設計をする際は、まずHPA単体での挙動を確認したうえで、ScaledObjectのパラメータを1つずつ検証していくのが安全だ。",[16,189,190,191,195,196,200],{},"K3sクラスタでのHPA運用そのものにクセがある場合は、",[27,192,194],{"href":193},"\u002Fblog\u002Fja\u002Fk3s-hpa-scaledown-stabilization-window-replica-flapping","HPAのレプリカ数が数分おきに増減する問題","や、",[27,197,199],{"href":198},"\u002Fblog\u002Fja\u002Fk3s-gpu-oomkilled-vpa-resource-estimation","VPAによるリソース見積もりの落とし穴","も合わせて確認しておくと、KEDA併用時の挙動分析がしやすくなる。",[16,202,203,204,209,210,214],{},"こうした併用設計や監視基盤の構築は、K3sベースで",[27,205,208],{"href":206,"rel":207},"https:\u002F\u002Fkubo.hexabase.io\u002F",[31],"Prometheus\u002FGrafanaが標準搭載された","マネージドKubernetes環境なら、メトリクス基盤をゼロから構築する手間をかけずに検証を始められる。",[27,211,213],{"href":206,"rel":212},[31],"Kubo","はAI-Driven DeploymentとCaptain UIにより、ScaledObjectの挙動を可視化しながら調整できる。",[11,216,217],{"id":217},"まとめ",[16,219,220],{},"HPAとKEDAは対立する選択肢ではなく、役割の異なるレイヤーだ。HPAはCPU・メモリといった内部リソースメトリクスに基づく「土台」であり、KEDAはキューの深さや外部イベントに基づく「拡張」として機能する。K3s環境で判断に迷ったら、まず「メトリクスソースが内部か外部か」「scale-to-zeroが必要か」「負荷がバースト性かどうか」の3軸で整理し、併用する場合はpollingIntervalとcooldownPeriodの依存関係を理解した上でチューニングすることが事故を防ぐ鍵になる。",[16,222,223,224,228,229,234],{},"この併用設計をコスト効率よく検証したいなら、EKSの約58%のコストで本格的なKubernetesを運用できる",[27,225,227],{"href":206,"rel":226},[31],"Kubo Cloud","で試すという選択肢もある。構成の検証コストを抑えたい場合は、",[27,230,233],{"href":231,"rel":232},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[31],"料金プラン","を比較してみてほしい。",{"title":236,"searchDepth":237,"depth":237,"links":238},"",2,[239,240,241,247,248],{"id":13,"depth":237,"text":14},{"id":45,"depth":237,"text":46},{"id":75,"depth":237,"text":76,"children":242},[243,245,246],{"id":94,"depth":244,"text":95},3,{"id":101,"depth":244,"text":102},{"id":114,"depth":244,"text":115},{"id":130,"depth":237,"text":131},{"id":217,"depth":237,"text":217},"2026-10-03","KEDAとHPAはどちらか一方を選ぶものではない。K3s\u002FKubernetesでイベント駆動ワークロードが増えたとき、HPAだけで限界に達する理由とKEDAを併用する判断基準を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision",{"title":5,"description":250},"blog\u002Fja\u002Fk3s-keda-hpa-event-driven-autoscaling-decision",[260,261,262,263,264,265,266],"k3s","kubernetes","keda","hpa","autoscaling","event-driven-scaling","scaledobject","IEtl6fp8xgBYtj7zt4563rPUvnSi7Xh4GgNzSyu9Kew",[269,275,283,291,298,305],{"path":270,"title":271,"description":272,"date":273,"tags":274},"\u002Fblog\u002Fja\u002Fk3s-keda-vs-hpa-event-driven-autoscaling-decision","K3sでイベント駆動オートスケーリングが必要になったら。HPAとKEDA、どちらを選ぶかの判断基準","K3sでHPAのCPU\u002Fメモリベースのスケーリングでは対応しきれないイベント駆動ワークロードに直面したとき、標準のHPAを使い続けるべきか、CNCF GraduatedプロジェクトのKEDAを導入すべきか。3つの判断基準とK3s環境での注意点を整理する。","2026-09-10",[260,261,263,262,264],{"path":276,"title":277,"description":278,"date":279,"tags":280},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[260,261,263,281,264,282],"containerresource","service-mesh",{"path":284,"title":285,"description":286,"date":287,"tags":288},"\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics","discoveryIntervalを疑え。K3sのHPAがPrometheus Adapter経由で\"古いメトリクス\"を掴み続ける設定ミス","K3sのHPAがCPU使用率は正常なのにスケールしない。原因はPrometheus Adapterのmetrics-relist-interval\u002Fmetrics-max-ageとHPA sync-periodが噛み合っていない設定ミスだった。3層の遅延構造と診断コマンドを解説する。","2026-10-12",[260,261,263,289,264,290],"prometheus-adapter","observability",{"path":292,"title":293,"description":294,"date":295,"tags":296},"\u002Fblog\u002Fja\u002Fkubernetes-hpa-vpa-autoscaling-conflict-design","\"両方入れれば安心\"が一番危ない。KubernetesでHPAとVPAを併用するとスケーリングが暴走する理由","KubernetesでHPAとVPAを両方有効にすると、良かれと思った自動化同士が干渉し、スケーリングが際限なく暴走することがある。衝突が起きる仕組みと、updateModeやメトリクス分離による安全な併用設計を解説する。","2026-10-07",[260,261,263,297,264],"vpa",{"path":299,"title":300,"description":301,"date":302,"tags":303},"\u002Fblog\u002Fja\u002Fk3s-hpa-not-scaling-metrics-unknown-vpa-death-spiral","HPAの設定は合っている。なのにPodが増えない。K3sで起きる『メトリクス不明』の正体とHPA\u002FVPAの死のスパイラル","K3sでHPAを設定したのにPodが増えない。原因はリソースリクエスト未設定によるメトリクス不明化と、HPA\u002FVPAの死のスパイラルにあることが多い。診断手順と対策を解説する。","2026-09-02",[260,261,263,297,264,304],"metrics-server",{"path":306,"title":307,"description":308,"date":309,"tags":310},"\u002Fblog\u002Fja\u002Fk3s-vpa-inplaceorrecreate-pod-resize-cgroup","VPAをInPlaceOrRecreateにしたのに、Podはまだ再起動していた。K3sでInPlacePodVerticalScalingの\"無停止\"を検証する","VPAのInPlaceOrRecreateモードとIn-Place Pod ResizeでPodは本当に再起動しないのか。K3s環境でQoSクラス制約とcgroup v1の罠を実際の設定例とkubectlコマンドで検証する。","2026-10-17",[260,261,297,264,311],"cgroup",1792592607375]