2026年、バースト型クラウドVMのCPUクレジット枯渇後はどうする？

【判断】バースト型クラウドVMのCPUクレジット枯渇が疑われる場合は、まず対象インスタンスがクレジット制かを確認し、残高・CPU使用率・業務の応答を同じ時間帯で照合してください。長時間にわたり基準性能を超える負荷が続くなら、インスタンスの変更を先に比較し、負荷が安定していて運用を担える体制がある場合に限って独立サーバーも候補にします。

クラウドVMの日常運用を担当し、性能低下とクレジット残高の関係を確かめたい方が対象です。
インフラ予算を管理し、現行構成・仕様変更・独立サーバーの費用を同じ条件で比べたい方にも役立ちます。
サイトやデータベースの担当者は、継続負荷と移行前の検証方法を確認できます。

最終更新：2026年11月2日。対象シリーズ、指標名、クレジット消費後の挙動は、本文中の公式資料を同日に照合しています。プラットフォームやインスタンス系列が異なる場合は、必ず該当する仕様を確認してください。

CPUクレジット枯渇後の挙動

バースト型インスタンスは、常時利用できる基準性能と、必要なときに一時的に上げられる性能を組み合わせた設計です。基準性能を下回る時間にクレジットを蓄積し、上回る時間に消費する仕組みは、対象系列の公式資料で確認できます。たとえば、BシリーズのCPUクレジットモデルは、同シリーズについてこの考え方を説明しています。

クレジットが尽きた後に何が起きるかは、すべてのクラウドVMで同じではありません。対象系列や動作モードによって、基準性能に抑えられる場合や、別の料金が発生しうる設定があるため、一般論だけで判断せず、該当する仕様を読み分けます。たとえば、バースト型インスタンスの標準モードの仕様では、そのモードにおけるクレジット消費後の動作が示されています。

したがって、残高がゼロに近いという事実だけでは、性能低下の原因を確定できません。残高の推移とCPU使用率に加えて、応答時間やキューの滞留が同じ時間に変化したかを確かめる必要があります。

CPU Credit Remainingと負荷の照合

「CPU Credit Remaining」は、CPUクレジットの残量を示す指標名として使われます。ただし、名称や提供されるメトリクスはプラットフォームと系列で異なります。クレジット残量・消費量をどの監視画面で確認できるかは、クレジット関連の公式監視指標や、仮想マシンの公式監視指標リファレンスで対象環境に合わせて確認します。

監視値は、業務側の記録と同じ時間軸にそろえてください。CPU使用率が高くても、クレジット残量が維持され、応答時間にも変化がないなら、積分枯渇が直接の原因とは限りません。逆に、残量の低下と応答悪化、キューの増加が重なっていれば、関係を調べる根拠になります。

クレジット指標の定義は、監視サービスの仕様や対象範囲も確認してください。サブスクリプション範囲のメトリック定義は、指標名や定義を照合するときの公式資料です。画面上の表示だけで意味を推測せず、指標の説明と対象リソースを確かめます。

CPU使用率以外の要因の切り分け

クレジット残高が減っているときも、遅延の原因がCPUだけとは限りません。変更を決める前に、次の項目を順に確認します。

• □ CPU使用率とクレジット残量が同時に変化しているかを確認します。
• □ アクセス数、同時処理数、キュー長に変化がないかを調べます。
• □ 定期実行ジョブやデプロイの時刻が、性能低下の開始と重なっていないかを確認します。
• □ メモリ不足によるスワップや、ディスクI/Oの遅延が発生していないかを調べます。
• □ アプリケーションログとデータベースの処理状況を、同じ時間帯で照合します。
• □ ゲストOSでCPU stealが確認できる場合は別項目として記録し、クレジット指標と混同しません。

CPU stealは、仮想CPUの実行待ちに関わる指標であり、クレジット残量そのものではありません。また、ディスクやメモリの飽和もCPUクレジットの枯渇とは別の問題です。高CPUの調査では、仮想マシンの高CPU問題に関する公式の切り分け手順も参照し、アプリケーションやOS側の要因を除外します。

残高が減り続ける場合の仕様変更

クレジットの残高が業務時間を通じて下がり続けるなら、負荷がインスタンスの基準性能を上回っている可能性があります。短いアクセス集中だけでなく、定期処理、データベースの集計、バックグラウンド処理が継続していないかを確認し、通常時と繁忙時を分けて評価してください。

次の条件分岐を使い、変更の候補を絞ります。

• 負荷が短時間に限られ、通常時は基準性能内で、業務指標も安定している場合：現行の突発型を維持し、監視とアラートを整えます。
• CPU負荷が長く続き、クレジット残高の低下と業務遅延が繰り返し重なる場合：まず、より大きな仕様または固定性能型のクラウドVMを比較します。
• 負荷が安定し、必要なCPU・メモリ・ディスク・ネットワークの条件を説明でき、チームがサーバー管理を担える場合：独立サーバーも比較候補に含めます。
• 需要が大きく変動する、複数地域への展開が必要、またはマネージドサービスへの依存が強い場合：クラウドを維持する案を優先し、依存関係を解消できるまで全面移行を避けます。

クレジットを追加消費できるモードがある場合も、追加料金の有無や計算方法を先に確認します。たとえば、無制限モードの公式料金例は、対象機能における料金計算を説明しています。モードの名称だけで無料・有料を決めつけず、実際の設定と請求条件を照合してください。クレジットの設定変更についても、公式のクレジット設定手順で適用条件を確認します。

サイトやデータベースの継続運用適性

サイトやデータベースを継続して動かす場合、短時間のCPUピークだけでなく、平常時の処理が基準性能を上回るかが判断の要点です。突発型クラウドVMは負荷に波があり、低負荷の時間にクレジットを回復できる構成なら候補になります。一方、CPUを継続して使う処理では、基準性能への制限やクレジット関連料金を含めて比較する必要があります。

独立サーバーへの移行は、CPU性能だけで決めないでください。アプリケーションの依存サービス、必要メモリとディスク容量、ネットワークの条件、バックアップと復旧の担当、障害時の対応手順まで整理します。独占的な物理資源を使うことは、高可用性、バックアップ、代行運用が自動で提供されることを意味しません。

料金を比較するときは、請求期間、対象地域、CPU・メモリ、ストレージ、通信量、IPアドレス、バックアップなどの条件をそろえます。クラウド側は実請求と対象地域の公式料金、独立サーバー側は製品表で確認し、割引を推測して埋めないことが重要です。構成の候補を整理する際は、XFP Cloudのサーバー構成案内を参照し、必要な資源と照合してください。

小規模な検証と切り替え判断

構成を広く変更する前に、代表的な処理を使って候補を検証します。検証環境が用意できる場合は本番データや外部連携への影響を避け、難しい場合は戻せる変更手順と担当者をあらかじめ決めます。

• □ 比較対象の処理と、通常時・繁忙時の負荷を選びます。
• □ CPU使用率、クレジット残量、応答時間、キュー長など、判定に使う指標を決めます。
• □ 変更前の値とログを記録し、同じ処理を候補構成で実行します。
• □ 性能だけでなく、料金、監視、バックアップ、障害対応の責任も記録します。
• □ 期待した結果が得られない場合の復旧方法を実行前に確かめます。
• □ 検証記録を比較し、要件を満たした範囲だけを段階的に切り替えます。

移行先を選ぶときは、CPUの結果だけを採用理由にしないでください。負荷の再現性、ストレージとネットワークの要件、復旧手順、運用に割ける時間まで含めて、現在のクラウドVMを維持する場合と比較します。短時間の実験や負荷が軽いサービス、需要に合わせた急な拡縮が不可欠なサービスは、独立サーバーに移さない判断も合理的です。

突発型VMでは、クレジット残高の低下、基準性能への制約、料金条件の確認漏れが悩みになりやすく、固定性能型VMでも継続的な利用料金や構成変更の制約が残ります。独立サーバーはクレジット制のVMとは資源の使い方が異なりますが、バックアップや高可用性、日々の運用責任を別途設計する必要があるため、安定した負荷と自主管理できる体制がそろう場合に検討するのが適切です。

独立サーバーのレンタルを候補にする場合は、必要なCPU・メモリ・ディスクと運用条件を整理したうえで、XFP Cloudの構成案内から適合する構成と製品表の金額を確認してください。クラウドVMとの同一条件で比較し、移行後の改善や節約を事前に保証せず、検証結果をもとに判断します。