[{"data":1,"prerenderedAt":327},["ShallowReactive",2],{"blog-ja-kubernetes-cpu-throttling-connection-pool-exhaustion":3,"blog-related-ja-kubernetes-cpu-throttling-connection-pool-exhaustion":275,"blog-ja-kubernetes-cpu-throttling-connection-pool-exhaustion-alt":263},{"id":4,"title":5,"author":6,"body":7,"date":257,"description":258,"extension":259,"image":260,"locale":261,"meta":262,"navigation":263,"path":264,"seo":265,"stem":266,"tags":267,"__hash__":274},"blog\u002Fblog\u002Fja\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion.md","『CPU使用率は低いから大丈夫』は罠。Kubernetesが隠すスロットリングと接続プール枯渇の天井","Kubo Team",{"type":8,"value":9,"toc":243},"minimark",[10,15,27,30,41,61,67,76,80,86,89,103,111,123,127,133,146,155,158,162,168,173,181,185,188,191,199,203,206,212,220,224,227,230],[11,12,14],"h2",{"id":13},"cpu使用率は低いのに遅いkubernetesの遅延原因を見誤る典型パターン","「CPU使用率は低いのに遅い」――Kubernetesの遅延原因を見誤る典型パターン",[16,17,21],"p",{"className":18,"dir":20},[19],"content-paragraph","ltr",[22,23],"img",{"src":24,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion\u002Fsection01.webp","","inherit",[16,28,29],{},"本番環境のダッシュボードを見ると、CPU使用率は30%程度しかない。それなのにAPIのレスポンスは明らかに遅い。多くのインフラエンジニアが一度は遭遇する、この「矛盾した監視画面」こそが、Kubernetesの遅延原因を見誤らせる最初の罠です。",[16,31,32,33,40],{},"原因は、CPUリミットの実装がカーネルレベルで行われている点にあります。",[34,35,39],"a",{"href":36,"rel":37},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fconfiguration\u002Fmanage-resources-containers\u002F",[38],"nofollow","Kubernetes公式ドキュメント","によれば、CPUリミットはCFS（Completely Fair Scheduler）によって強制され、コンテナがリミットに近づくとカーネルがCPUへのアクセスそのものを制限します。メモリのようにプロセスがOOM killで終了するわけではないため、パッと見ではエラーも出ず、単に「遅い」という現象だけが残ります。",[16,42,43,44,48,49,54,55,60],{},"さらに厄介なのは、多くの監視ツールが表示する「CPU使用率」は、スロットリングされた",[45,46,47],"strong",{},"後","の使用量である点です。",[34,50,53],{"href":51,"rel":52},"https:\u002F\u002Fwww.datadoghq.com\u002Fblog\u002Fkubernetes-cpu-requests-limits\u002F",[38],"Datadogの解説記事","が指摘するように、コンテナは制限されているからこそ使用率が低く見えるのであって、「低い使用率＝余裕がある」という直感はここでは通用しません。",[34,56,59],{"href":57,"rel":58},"https:\u002F\u002Fwww.ibm.com\u002Fthink\u002Ftopics\u002Fkubernetes-cpu-throttling-identification",[38],"IBMのトラブルシューティング記事","でも、CPU使用率だけを見た調査ではスロットリングを見逃しやすいことが指摘されています。",[16,62,64],{"className":63,"dir":20},[19],[22,65],{"src":66,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion\u002Fsection02.webp",[16,68,69,70,75],{},"こうした\"見た目に反する遅延\"の調査は、監視スタックが最初から整っていないと非常に時間がかかります。",[34,71,74],{"href":72,"rel":73},"https:\u002F\u002Fkubo.hexabase.io\u002F",[38],"Kubo","のようにPrometheus・Grafanaが標準搭載されたマネージドK3s環境であれば、こうした指標の可視化に追加の構築コストがかかりません。",[11,77,79],{"id":78},"podを増やすhpaでスケールするほど状況が悪化する理由","Podを増やす（HPAでスケールする）ほど状況が悪化する理由",[16,81,83],{"className":82,"dir":20},[19],[22,84],{"src":85,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion\u002Fsection03.webp",[16,87,88],{},"CPUスロットリングを疑い、レプリカ数を増やしてスケールアウトしても遅延が直らない、あるいは悪化することがあります。これは、ボトルネックがアプリケーション層やデータベース層にあるケースです。",[16,90,91,92,96,97,102],{},"代表的なのがデータベースへのコネクションプール枯渇です。PostgreSQLは",[93,94,95],"code",{},"max_connections","パラメータで同時接続数の上限を管理しており、",[34,98,101],{"href":99,"rel":100},"https:\u002F\u002Fplanetscale.com\u002Fblog\u002Fscaling-postgres-connections-with-pgbouncer",[38],"PlanetScaleの解説","によれば、Postgresは接続ごとにOSプロセスをフォークするため、接続数が増えるほどメモリとコンテキストスイッチのコストが跳ね上がります。ここでHPAがPodを増やすと、各Podが個別にコネクションプールを持つ設計であれば、合計の接続要求数はさらに膨らみます。",[16,104,105,110],{},[34,106,109],{"href":107,"rel":108},"https:\u002F\u002Fcubeapm.com\u002Fblog\u002Fpostgresql-connection-pool-exhausted-kubernetes\u002F",[38],"CubeAPMの技術記事","は、Kubernetes上のアプリケーションでこの種の接続枯渇が起きるパターンを具体的に解説しています。Podを増やすことは本来「処理能力を増やす」対策であるはずが、データベース側の接続上限に対しては逆効果になり、「too many clients」といったエラーが増えるという逆転現象が起きるのです。",[16,112,113,114,119,120,122],{},"この問題を回避する仕組みとして知られるのがコネクションプーラーです。",[34,115,118],{"href":116,"rel":117},"https:\u002F\u002Fneon.com\u002Fdocs\u002Fconnect\u002Fconnection-pooling",[38],"Neonの公式ドキュメント","が説明する通り、PgBouncerのようなプーラーを中間に置くことで、多数のアプリケーション接続を少数の実DB接続に多重化でき、",[93,121,95],{},"の上限に振れることなくPodの水平スケールが可能になります。",[11,124,126],{"id":125},"見るべき指標はcpuではないkubernetesの遅延原因の切り分け方","見るべき指標はCPU%ではない――Kubernetesの遅延原因の切り分け方",[16,128,130],{"className":129,"dir":20},[19],[22,131],{"src":132,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion\u002Fsection04.webp",[16,134,135,136,141,142,145],{},"CPU使用率という単一指標だけを見ている限り、スロットリングも接続プール枯渇も両方見逃す可能性があります。",[34,137,140],{"href":138,"rel":139},"https:\u002F\u002Flast9.io\u002Fblog\u002Fkubernetes-cpu-throttling\u002F",[38],"Last9の技術ブログ","は、",[93,143,144],{},"container_cpu_cfs_throttled_seconds_total","というPrometheusメトリクスこそが、CPU使用率ではなく「実際にスロットルされた時間」を直接示す指標だと解説しています。CPU使用率が低くても、このメトリクスが高ければスロットリングが疑われます。",[16,147,148,149,154],{},"一方、データベース側の遅延を切り分けるには、コネクションプールの使用率やキューでの待機時間を可視化する必要があります。HPAをCPUだけで運用している場合、",[34,150,153],{"href":151,"rel":152},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fhorizontalpodautoscaler",[38],"Google Cloudの公式ドキュメント","が示すように、Kubernetes 1.6以降のCustom Metrics APIを使えばPrometheus経由でアプリケーション固有のメトリクス（キュー長やレスポンスタイムなど）をHPAのスケール条件に組み込むことができます。CPU使用率だけでスケールを判断する構成から脱却する第一歩がここにあります。",[16,156,157],{},"つまり、Kubernetesの遅延原因を正しく特定するには、CPU%・CFSスロットリング時間・DB接続プール使用率・p99レイテンシという最低4種類の指標を並べて見る必要があります。どれか一つだけを見ていると、必ず別の原因に目を塞ぐことになります。",[11,159,161],{"id":160},"正しい対処法podを増やす前にやるべきこと","正しい対処法：Podを増やす前にやるべきこと",[16,163,165],{"className":164,"dir":20},[19],[22,166],{"src":167,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion\u002Fsection05.webp",[169,170,172],"h3",{"id":171},"cpu-limitはレイテンシ重視のサービスでは外す選択肢もある","CPU limitはレイテンシ重視のサービスでは外す選択肢もある",[16,174,175,180],{},[34,176,179],{"href":177,"rel":178},"https:\u002F\u002Fwww.groundcover.com\u002Fblog\u002Fkubernetes-cpu-throttling",[38],"groundcoverの解説","は、CPU limitを設定しすぎると、ノードに空きキャパシティがあってもコンテナが不必要にスロットルされる場合があると指摘しています。すべてのワークロードにCPU limitを設定するのではなく、requestsで優先度を確保しつつ、レイテンシに敏感なサービスではlimitを緩めるという選択肢を検討する価値があります。",[169,182,184],{"id":183},"hpaのスケール条件をcpuからアプリケーション指標に変える","HPAのスケール条件をCPUからアプリケーション指標に変える",[16,186,187],{},"前述のCustom Metrics APIを使い、CPU使用率だけでなくリクエストキューの長さやレスポンスタイムでスケールする設定に切り替えることで、「CPUは空いているのに詰まっている」状態を早期に検知できます。",[169,189,190],{"id":190},"コネクションプーラーを間に挟む",[16,192,193,198],{},[34,194,197],{"href":195,"rel":196},"https:\u002F\u002Fkomodor.com\u002Flearn\u002Fkubernetes-cpu-limits-throttling\u002F",[38],"Komodorの記事","も指摘する通り、リソースの誤診断は運用コストの多くを消費します。PgBouncerなどのプーラーをsidecarまたは中間層に配置すれば、Pod数の増加とDB接続数の増加を分離できます。",[169,200,202],{"id":201},"maxreplicasはdb側の受け入れ可能上限から逆算する","maxReplicasはDB側の受け入れ可能上限から逆算する",[16,204,205],{},"HPAのmaxReplicasを「クラスタのCPUキャパシティ」だけで決めるのではなく、「データベースが安全に受け付けられる接続数 ÷ Pod1台あたりの接続数」から逆算して設定することで、スケールアウトが自滅的にエラーを増やす事態を防げます。",[16,207,209],{"className":208,"dir":20},[19],[22,210],{"src":211,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion\u002Fsection06.webp",[16,213,214,215,219],{},"こうした指標を1画面で見られる状態を最初から用意しておくことが、誤診断による対応の長期化を防ぐ最短ルートです。",[34,216,218],{"href":72,"rel":217},[38],"Kubo Cloud","はK3sベースのマネージドKubernetesで、Prometheus + Grafanaが標準搭載されているため、CFSスロットリング時間やカスタムメトリクスによるHPA設定を、追加の監視基盤構築なしにすぐに始められます。",[11,221,223],{"id":222},"まとめスケールは魔法ではない","まとめ：スケールは魔法ではない",[16,225,226],{},"「Podを増やす」は便利な対処法ですが、万能ではありません。ボトルネックがカーネルレベルのCPUスロットリングやデータベース側の接続プール枯渇にある場合、スケールアウトは問題を隠すどころか、接続エラーという新しい問題を生み出すことさえあります。",[16,228,229],{},"Kubernetesの遅延原因を正しく特定するには、CPU使用率という単一の数字を信じず、スロットリング時間・DB接続プール使用率・p99レイテンシまで見える状態を整えることが第一歩です。",[16,231,232,233,236,237,242],{},"EKSやAKSでゼロから監視スタックを構築するとコストも時間もかかりますが、K3sベースでPrometheus・Grafanaが標準搭載された",[34,234,74],{"href":72,"rel":235},[38],"なら、月額48,000円〜でこうした可視化環境をすぐに使い始められます。ベンダーロックインのない標準Kubernetesのまま、誤診断に時間を溶かさない運用を試したい方は、",[34,238,241],{"href":239,"rel":240},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[38],"お問い合わせ","から相談してみてください。",{"title":25,"searchDepth":244,"depth":244,"links":245},2,[246,247,248,249,256],{"id":13,"depth":244,"text":14},{"id":78,"depth":244,"text":79},{"id":125,"depth":244,"text":126},{"id":160,"depth":244,"text":161,"children":250},[251,253,254,255],{"id":171,"depth":252,"text":172},3,{"id":183,"depth":252,"text":184},{"id":190,"depth":252,"text":190},{"id":201,"depth":252,"text":202},{"id":222,"depth":244,"text":223},"2026-07-28","KubernetesでPodを増やしても遅延が直らないとき、真のKubernetes遅延原因はCPUではなくスロットリングやDB接続プールの枯渇かもしれない。見えない天井の正体と正しい診断・対処法を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion",{"title":5,"description":258},"blog\u002Fja\u002Fkubernetes-cpu-throttling-connection-pool-exhaustion",[268,269,270,271,272,273],"kubernetes","k3s","performance-tuning","cpu-throttling","connection-pooling","hpa","Kt3ajZS6kCjFMIOlJj07OYsLIRurMKddHeJXbNSro5g",[276,285,294,303,311,320],{"path":277,"title":278,"description":279,"date":280,"tags":281},"\u002Fblog\u002Fja\u002Fkubernetes-gpu-multitenancy-namespace-vs-dedicated-node","高価なGPUを独り占めさせるな。Kubernetesでアクセラレーターを分け合う設計に「唯一の正解」がない理由","KubernetesのGPUマルチテナント設計は namespace分離か専用ノードかの二択ではない。コストと分離レベルのトレードオフを解説し、ハイブリッド設計の考え方を紹介する。","2026-08-13",[269,268,282,283,284],"gpu-multitenancy","cost-optimization","namespace-isolation",{"path":286,"title":287,"description":288,"date":289,"tags":290},"\u002Fblog\u002Fja\u002Fkubernetes-gitops-branch-antipattern-fleet-scaling","そのdev\u002Fstaging\u002Fprodブランチ、実は時限爆弾。KubernetesのGitOpsが壊れる本当の理由","dev\u002Fstaging\u002FproductionをGitブランチで分けるGitOps運用は、実はKubernetesの宣言的インフラの前提を壊すアンチパターンだ。ドリフトが起きる理由とディレクトリ構成・トランクベース運用への移行手順、フリート規模での崩壊を防ぐ設計を解説する。","2026-08-10",[269,268,291,292,293],"gitops","argocd","devops",{"path":295,"title":296,"description":297,"date":298,"tags":299},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[269,268,300,301,302],"cert-manager","tls","security",{"path":304,"title":305,"description":306,"date":307,"tags":308},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[269,268,309,310,302],"kata-containers","ai-agent",{"path":312,"title":313,"description":314,"date":315,"tags":316},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[269,268,317,318,319],"kubevirt","networking","managed-kubernetes",{"path":321,"title":322,"description":323,"date":324,"tags":325},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[269,268,326,291,302],"ci-cd",1786701432051]