この記事は、Azure Database for PostgreSQL / MySQL フレキシブル サーバーの バースト可能コンピュート（Burstable）サイズ をお使いの際に、予期しない性能低下や接続不可、サーバー操作失敗などの事象に悩まれている方に向けた内容です。バースト可能コンピュートがどのような前提で設計されているか、メトリックの見え方、実際の現場で起きているパターン、そして「どのような用途なら選んでよいか」「どの用途には向かないか」を整理してお伝えすることを意図しています。
※この記事の内容は、記事を公開した時点での情報となり、今後のアップデートで変更がある場合もございますことをご了承ください。最新の情報についてはお気軽にお問い合わせください。
バースト可能は、CPU クレジット型の VM
まず前提として、Azure Database for PostgreSQL / MySQL フレキシブル サーバーは、内部的には Azure Virtual Machines (VM) の上で動作する PaaS サービスです。
コンピューティングレベルで選択する SKU（B1ms / B2s / B2ms など）は、そのまま基盤となる VM のサイズを意味します。
そのため、「バースト可能コンピュート」の挙動を理解するためには、まず バースタブル VM（Bv1 シリーズ）側の CPU クレジットモデル を押さえておく必要があります。
バースト可能（バースタブル）VM は、「いつもフルパワーは要らないが、ときどきだけ CPU を大きく使いたい」という前提で設計されたコンピュートモデルです。現在、Azure Database for PostgreSQL / MySQL フレキシブル サーバーのバースト可能コンピュートで利用される VM は Bv1 シリーズ (B1ms / B2s / B2ms など) に該当します。これらの B 系列 VM は CPU クレジットモデルを採用しており、CPU 使用率がベースラインを下回っているあいだはクレジットが貯まり、その後ベースラインを超えて CPU を使うときに、その貯まったクレジットを消費しながら一時的に100%までバーストできる仕組みになっています。
重要なポイントは、クレジットを使い切ってしまうと、CPU はベースライン相当までしか動けなくなる という点です。たとえば vCPU が 1 コアでベースライン 20% のサイズであれば、クレジットがゼロの状態では、常に 0.2 コア分程度の計算力 しか出せません。見かけ上は CPU 使用率メトリックが 100% 付近に張り付き続けても、それはフル 1 コアの 100% ではなく、ベースライン 0.2 コアを使い切って頭打ちになっている 100% という状態になり得ます。
よくある誤解として、「バースト可能は負荷が増えたら自動的にコア数（vCPU 数）が増えるのではないか」という質問がありますが、実際は、クレジットモデルで変化するのは 1 コア当たりの利用可能な時間（パフォーマンス） であり、vCPU の数そのものは増えません。より多くの CPU リソースが恒常的に必要な場合は、上位の SKU や vCPU 数の多いサイズへスケールアップする必要があります。
また、同じ Bv1 シリーズの中でも B1ms / B2s / B2ms など SKU ごとに、ベースラインの CPU パーセンテージ、初期クレジット量、クレジットの蓄積速度が異なります。これらの具体的な数値は Azure Virtual Machines の Bv1 シリーズのサイズ のドキュメントに一覧化されており、ページ上部のタブを切り替えることで各サイズの詳細（ベースライン、クレジットレートなど）を確認できます。
Azure Virtual Machines Bv1 シリーズ
https://learn.microsoft.com/azure/virtual-machines/sizes/general-purpose/bv1-series
Azure Database for PostgreSQL / MySQL フレキシブル サーバーにおける「バースト可能コンピュート」
例えば、Azure Database for PostgreSQL フレキシブル サーバーには、バースト可能 (Burstable)、汎用 (General Purpose)、メモリ最適化 (Memory Optimized) の 3 種類のコンピューティングレベルがあります。公開情報では、バースト可能コンピュートレベルについて、低コストの開発 と、継続的なコンピューティング容量を必要としない低コンカレンシーのワークロード に最適であると明記されています。一方で、高いコンカレンシーや予測可能なパフォーマンスが必要な運用環境のワークロード には、汎用などの上位レベルが推奨されています。
Azure Database for MySQL フレキシブル サーバーでも、基盤の VM は同じ Bv1 シリーズであることから考え方は同様です。バースト可能コンピュートレベルは、本番環境ではなく、継続的な最大 CPU を必要としない軽いワークロード の場合や、開発 / テストなどの環境でコストを抑えたい場合 に適した構成として説明されています。一方で、クレジットが枯渇した場合には CPU 性能が制限され、最悪の場合は接続不可やサーバー操作への影響が出る ことは、PostgreSQL / MySQL で共通の注意点です。
つまり、Azure Database for PostgreSQL / MySQL フレキシブル サーバーのバースト可能コンピュート は、元になっている Bv1 バースタブル VM と同じく 「軽い・一時的なワークロード」向け であり、「本番業務システム」や「本番と同等負荷のパフォーマンス テスト」 のような用途は前提としていません。
メトリックの見え方と、よくある誤解
バースト可能コンピュートを使うときに混乱が起きやすいポイントが、CPU 関連メトリックの解釈 です。
例えば、Azure Database for MySQL フレキシブル サーバーの Host CPU Percent メトリックの値は、ベースラインではなく 「フル vCPU に対する割合」 を表しています。たとえばベースライン 40% のサイズで Host CPU Percent が 50% と表示されている場合、「50% × 40% = 実効 20%」という意味ではなく、「1 コア分の 50% を使っている ＝ すでにベースライン 40% を超えてクレジットを消費し始めている」という状態になります。
クレジットがゼロになった場合でも、メトリック上は 100% と表示され続けますが、その時点では ベースライン相当の性能を使い切っている 100% であり、CPU をさらに増やすことはできません。その結果として、クエリが遅くなったり、接続や管理操作がタイムアウトしやすくなったりします。
このため、バースト可能コンピュートレベルを利用する場合は、Host CPU Percent だけでなく、CPU Credits Remainings のメトリックも合わせて監視 し、クレジットが減り続けてゼロに近づいていないかを確認することがとても重要です。
現場で実際に起きているパターン
サポート現場で実際に相談を受けている、よくある事例を典型的なパターンとして整理します。
あるお客様では、B1ms や B2s といった非常に小さいバースト可能 SKU を使って、開発と本番をまとめて運用されていました。最初のうちは CPU 使用率も 20〜30% 程度で問題なく動いていましたが、年々本番データや処理が増える につれて、CPU 使用率が 20% を超える時間帯が増え、クレジットが少しずつ削られていきました。ある時点からは、ほぼ常時 80〜100% の高い CPU 使用率になり、いったんクレジットが枯渇すると、その後はワークロードが落ち着いてもクレジットが再構築されず、サーバーの停止・起動・再起動などの操作さえ時間がかかる、あるいは失敗する 状況になってしまいました。このケースでは、お客様と協議のうえ、そのサーバーを実質的に本番として扱うのであれば、General Purpose などの上位レベルにスケールアップする ことをご提案し、最終的にアップグレードを選択されました。
別のお客様では、開発環境としてバースト可能コンピュート を選択し、毎朝サーバーを起動して業務終了後に停止する、という運用でコスト削減を図っていました。しかし、ある日からポータル上で「停止中」の状態のまま変わらず、サーバーが停止できない、あるいは再起動操作が完了しない という事象が発生しました。調査の結果、そのサーバーも小さなバースト可能 SKU で、通常のアプリケーション負荷に加えて、サービス内部のメンテナンス処理やログ関連処理によって CPU クレジットが使い切られ、サーバー内部のリソースが逼迫した ことで、管理操作そのものに影響が出ていたことが分かりました。このように、バースタブルでは サーバーを小さくし過ぎると、アプリ側の負荷が少なくても、内部のコンポーネントだけでクレジットが消費されてしまう ことがあります。
また、別の開発環境では、1 分あたり百数回程度のトランザクション（BEGIN〜COMMIT の単位）が継続 している状態で、アプリからはほとんどクエリを投げていないはずなのに、Total Transactions が多すぎるのではないかと疑問を持たれたパターンもございます。実際には、Azure Database for PostgreSQL フレキシブル サーバー側で行っているヘルスチェックやメトリック収集などのシステム処理も含めてトランザクション数が計測 されており、B1ms のような小さいサイズでは、これら内部処理だけでもクレジット消費に影響し得ることが確認されています。
バースト可能レベルの機能制限
さらに、バースト可能コンピュートレベルでは 一部の機能制限 も存在します。Azure Database for PostgreSQL フレキシブル サーバーでは、組み込みの PgBouncer 接続プール機能 は、汎用またはメモリ最適化レベルでのみサポート されており、バースト可能レベルにスケールダウンすると PgBouncer が利用できなくなります。PgBouncer に依存している構成では、そもそもバースト可能レベルを選択できないという制約があります。また、Azure Database for PostgreSQL / MySQL フレキシブル サーバーともに、高可用性構成はバースト可能コンピュートレベルでは利用できません。本番システムでは、設計段階でバースト可能を選択肢から外すべきポイントとなります。
ワークロードによっては動作が安定しないのに、なぜ存在するのか？
サポートで実際にいただく率直なご質問として、「ワークロードによって動作が安定しない可能性があるのに、なぜバースト可能という SKU が存在するのか」というものがあります。
背景としては、主に次のようなニーズがあります。
・気軽に低価格でクラウドを触り始めたい
・まずは小さな検証環境を安く動かしたい
これらのニーズに応えるため、クレジット型のバースト可能 VM を基盤とする低価格なコンピュート を提供しているという側面があります。比較的安価な VM やデータベースを提供することで、初めてクラウドを利用するお客様や、小さな開発・検証用途のお客様の選択肢を広げたい という意図があります。
一方で、「安価な SKU を提供すること」と「どんな本番ワークロードにも適していると誤解されないこと」 のバランスが非常に難しいのも事実です。Azure Database for PostgreSQL / MySQL フレキシブル サーバーともに、バースト可能レベルは 、低コストの開発や低コンカレンシーなワークロード向け」 であり、「高いコンカレンシーや予測可能なパフォーマンスが必要な運用環境のワークロードでは汎用などの上位レベルを推奨しております。
しかし、ポータルの UI 表示や価格の差だけを見ると、「安いし、うちの業務もそこまで重くないから大丈夫だろう」と判断されることが多いのが、日々のサポートの中で感じている実情です。
弊社開発側でも、小さな SKU で起きている内部コンポーネントの負荷やログ関連処理の最適化など、品質向上のための改善を継続していますが、CPU クレジットという仕組み上、「クレジットを使い切ると性能が制限される」こと自体をなくすことは仕様としてできません。そのため、バースト可能コンピュートは、あくまで 用途を絞って使っていただく前提のお試し的な SKU である、という理解を持っていただくことが重要になります。
特に、何か期限が迫っていたり、多くのワークロードが求められるケース においては、バースト可能コンピュートは適していないと考えます。
どんな用途ならバースト可能コンピュートを選んでよいか
バースト可能コンピュートが有効に機能するのは、次のような性質を持つワークロードです。
・日中はほとんどアクセスがなく、開発者が時々ログインして軽く操作する程度の 開発用・検証用データベース
・PoC や個人検証のために、軽いデータを扱う 小規模アプリケーション
・夜間や決まった時間にだけ重くないバッチ処理を行い、それ以外の時間はほぼアイドルに近い 検証環境
こういったケースでは、通常はベースライン以下で動きつつ、時々のピーク時にクレジットを使ってバーストする という設計思想とマッチすると考えます。
逆に、次のような性質のワークロードでは、バースト可能コンピュートレベルの設計思想と適していないことから、基本的に選ぶべきではない と考えます。
・業務時間帯を通して常にトランザクションが流れ続ける 基幹システム
・1 日の多くの時間帯で CPU 使用率が 20〜40% を超えている 本番データベース
・利用者が増えたりデータ量が増えたりしても、一定以上の応答性能を維持することが必須の 外部向けサービス
・PgBouncer などの接続プール機能を前提としており、多数の接続をさばく必要がある 高コンカレンシー構成
・特定の期日までに完了させる必要のある、軽くない 検証・負荷試験環境
こういったシステムは、クレジットの有無に関係なく、そもそも汎用やメモリ最適化レベルでの運用を前提に設計することが適しています。
バースト可能コンピュートをすでに使っている場合に、確認すべきポイント
もしすでにバースト可能コンピュートレベルで Azure Database for PostgreSQL / MySQL フレキシブル サーバーを運用している場合は、次のような観点で状況を確認していただくとよいと思います。
・コンピューティングレベルが バースト可能 で、SKU が B1ms / B2s といった小さいサイズになっていないかどうか
・監視メトリックで Host CPU Percent が 50〜80% 以上の時間帯が長く続いていないか どうか
・CPU Credits Remaining が、時間の経過とともに減り続けてゼロ付近をうろうろしていないかどうか
・クレジットがゼロの状態で Host CPU Percent が 100% に張り付き続けるようであれば、すでに ベースライン性能を使い切っている証拠 と考えます。
こうした状況が確認できる場合、短期的には 高負荷処理を一時的に完全に止めてクレジットの蓄積を待つ という対処もありますが、本番環境では現実的ではないことが多いです。
根本的には、次のような構成変更が必要になることが、今まで対応してきたケースにおける共通した根本対処となります。
・コンピュートレベルの見直し（汎用などの上位レベルへ）
・vCPU 数の増加（SKU のスケールアップ）
・本番と開発・検証を別サーバーに分ける
最後に、お使いの中でご不明点等ございましたら、この記事の内容に重複する部分であっても、お気軽にサポートリクエストをご起票いただけますと幸いです。
弊チームが最後までサポートいたします。
参考情報（VM / PostgreSQL / MySQL）
最後に、本記事の内容とあわせてお客様にご参照いただきたい公開情報の URL を記載します。
Azure Virtual Machines Bv1 シリーズ
https://learn.microsoft.com/azure/virtual-machines/sizes/general-purpose/bv1-series
Azure Database for PostgreSQL フレキシブル サーバーのコンピューティング オプション（バースト可能の詳細）
https://learn.microsoft.com/ja-jp/azure/postgresql/configure-maintain/concepts-compute
Azure Database for MySQL フレキシブル サーバーのサービス レベルとストレージ（バースト可能の詳細）
https://learn.microsoft.com/ja-jp/azure/mysql/flexible-server/concepts-service-tiers-storage
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。