クラウド データベースをご利用いただく中で、「スケールしようとしたらエラーになった」「クォータ不足と言われたが、何を見てどう対応すればよいか分からない」「リージョン制限と言われて作成できなかった」といったお問い合わせをいただくことがあります。いずれも Azure 側の仕様としては正しい動作ではあるものの、キャパシティ・クォータ・リージョン制限といった概念が整理されていないと、「なぜこのエラーになっているのか」「どこに相談すべきなのか」が見えにくくなりがちです。
本記事では、Azure Database for MySQL フレキシブル サーバーおよび Azure Database for PostgreSQL フレキシブル サーバーを例に、クラウドならではの柔軟なスケールの仕組みと、その裏側を支えるキャパシティ / クォータ / リージョン制限という 3 つの考え方を整理します。それぞれの概念がどのような目的で存在しているのか、実際にどのようなエラーメッセージとして現れるのか、そしてお客様側でどのような対応や準備ができるのかを順番にご紹介することで、容量関連のエラーに遭遇した際の見通しを持っていただくことを目的としています。
また、この記事を拝見してご不明点等ございましたらお気軽にサポートチームへご相談ください。
※この記事の内容は、記事を公開した時点での情報となり、今後のアップデートで変更がある場合もございますことをご了承ください。最新の情報についてはお気軽にお問い合わせください。
はじめに：オンプレミスでは、すぐには増やせない、減らせない
オンプレミス環境でデータベースを運用していると、今すぐリソースを増やしたいと思っても簡単にはいかないことが多くあります。サーバーを増強するには、まず機材をオーダーし、多くの場合は日本国外の工場で製造されたものが海外から輸送され、日本到着後は国内配送を経てお客様のデータセンターに到着します。そのうえでラックへの設置や配線、動作確認、本番環境への切り替えといった作業が必要です。この長いタイムラインの途中には、日本においては輸送中の災害や遅延といったリスクも存在いたします。「ちょっとCPU を倍にしたい」と考えてから実際に性能が上がるまでに、数週間から数か月かかることも珍しくありません。
クラウドで実現できる柔軟なスケール
Azure製品、今回は弊チームが扱う Azure Database for MySQLフレキシブル サーバーやAzure Database for PostgreSQLフレキシブル サーバーは、そうしたオンプレミスの制約を大きく緩和するために設計されています。検証環境であれば、普段は小さなコンピュートサイズでコストを抑え、負荷テストや検証が重なる期間だけサーバーサイズを一時的に大きくする、といった運用が可能です。本番環境でも同様に、繁忙期の前だけ CPU やメモリを増やし、ピークが終わればサーバーサイズを落としてランニングコストを下げることができます。何より、こうした作業をサーバー名や接続文字列を変えず、Azure ポータルやAPIからPC一台でクリックで完結できる、というのがクラウドならではの柔軟性です。「ちょっとCPU を倍にしたい」が気軽に叶うというのが魅力になります。
とはいえ、クラウドも無限の魔法ではなく、最終的には世界のどこかに存在する物理的なデータセンターの上に成り立っています。Azure には世界中に複数のリージョンがあり、それぞれのリージョンの内部には CPU やメモリ、ストレージ、ネットワークといった物理リソースが配置されています。その上に、仮想マシンや PaaS サービスとして Azure Database for MySQLフレキシブル サーバーやAzure Database for PostgreSQLフレキシブル サーバー が動いている、という構造です。サーバーを新規作成したり、スケールアップやスケールダウンしたりする際、内部ではそのサーバーを動かすための基盤リソースへの「割り当て」が行われます。選択されたリージョンや可用性ゾーン、SKU の組み合わせに、今この瞬間に割り当て可能な空きがない場合、「リージョンの容量が不足しています」「このリージョンでは指定された SKU はサポートされていません」といった様々な種類の容量関連のエラーメッセージとしてその状況が表面化することがあります。
ここで関係してくる主な概念が、キャパシティ、クォータ、リージョン制限です。
ややこしい概念ではありますため、それぞれの意味と役割、そしてそのエラーに遭遇したときにどう考えればよいかを整理していきます。
キャパシティとは何か：リージョンごとの収容力
キャパシティは、あるリージョンや可用性ゾーンが特定の SKU や vCore 数をどれだけ物理的に収容できるか、という「収容力」を示すイメージです。需要は常に揺れ動いているため、特定の組み合わせに対してある時間帯だけ需要が集中し、一時的に「満席」のような状態になることがあります。この場合、少し時間をおいて同じ操作を再試行すると、他のお客様のスケールダウンや削除などによってキャパシティに余裕が生まれ、今度は成功する、といったことが実際に起こり得ます。
また、中長期的な視点では、Azure が継続的にデータセンターの増強や最適化を行っているため、特定リージョンでのキャパシティの逼迫も、時間の経過とともに緩和されていくケースが多い、というのがこれまでの経験から見える傾向です。短期的には「需要の波に伴う一時的な満席」、長期的には「ハードウェア増強や配置最適化による改善」という二つの時間軸でキャパシティを捉えていただくとキャパシティエラーの背景がイメージしやすくなります。Azureは常にデータセンターの増量に取り組んでいますが、需要に追い付かない場合は特定の製品・サイズに起こることがどうしてもございます。
キャパシティ関連エラーが出たときにお客様ができること
- 時間をおいて再試行する
- 別の可用性ゾーンを試す
- 別の SKU・vCore 数を試す
- 代替リージョンを検討する
- サポートリクエストを作成する
クォータとは何か：安全装置としての予約枠
クォータは、キャパシティとは別レイヤーの仕組みとして、サブスクリプションごとに用意されている「予約枠」のようなものです。例えば、あるサブスクリプションが特定リージョンに対して利用できる vCore の上限値が決められており、その範囲内であれば自由にサーバーを作成したりスケールしたりできますが、それを超えようとすると「サブスクリプションのサーバーをプロビジョニングまたは更新するのに十分なクォータがありません」といったエラーになります。
キャパシティという概念があるのであれば、キャパシティでカバーすればよいのでは？と直感的に感じる部分もありますが、実際にクォータが存在する理由の一つは、誤操作や不正利用からお客様を守る安全装置としての役割です。もしクォータがなければ、バグやスクリプトのミスによって意図せず大量のサーバーが作られてしまい、気づいたときには請求額が大きく膨らんでいる、といった事態になりかねません。クォータのラインを超えようとしたタイミングでエラーとなることで、何かがおかしいと気づけるセーフティネットが用意されていると考えると分かりやすいと思います。
もう一つの理由は、プラットフォーム全体のお客様同士の公平性です。キャパシティだけで制御していると、ある一つのサブスクリプションが短時間のうちに大量のリソースを確保してしまい、同じリージョンを利用したい他のお客様がサーバーを作成できない、という状況になりかねません。クォータをサブスクリプション単位で設定しておくことで、まずは全てのお客様に対して既定の枠を公平に割り当て、より大きな需要がある場合にはサポートリクエストを通じて個別にその都度、枠を拡大していく、という運用ができるようになります。結果として、キャパシティの無駄遣いや偏りを防ぎつつ、必要なところにはきちんとリソースを回せるようになる、という二つのことを達成できます。クォータは請求額そのものを決める仕組みではありませんが、「これ以上リソースが増えると危ない」という目安のラインを用意し、予期せぬコスト爆発を防ぐ効果も持っています。
クォータ関連エラーが出たときにお客様ができること
- 検証用の不要サーバーや過剰な vCore を一時的に減らすことで、既存クォータ内で収まるかを検討する
- クォータ増加依頼のサポートリクエストを送信する
- クォータ増加の完了を待つ間、別リージョンでの作成や、一時的に vCore を抑えた構成で立ち上げることが可能か検討する
リージョン制限が存在する理由：どこでも自由は危ない
リージョン制限とは、「どのサブスクリプションが、どのリージョンにリソースを作成できるか」を決める仕組みです。Azure 側の設定と、お客様側のポリシー（Azure Policy など）の両方が関わっており、その結果として「このサブスクリプションでは East US には作れるが、別のこのリージョンには作れない」といった振る舞いになります。「要求されたリージョンでのプロビジョニングはサポートされていません」「リージョンは制限されています」といったメッセージは、この制御に引っかかったときに表示されるものです。
まず大きな理由が、コンプライアンスやデータレジデンシの要件です。国や地域、業種によっては「個人データは国内に保存しなければならない」「この地域外に顧客データを持ち出してはならない」といったルールがあります。もし「どこにでも自由に作れる」状態だと、開発者が何気なく海外リージョンを選んでクリックだけでデプロイまでいけてしまうと、キャパシティやクォータに問題がなくても、組織としては規制違反になってしまう可能性があります。そこで、「このサブスクリプションはこのリージョン群だけ使える」「この特別なリージョンは条件を満たしたお客様だけ」といった形で、そもそも誤った場所にデプロイできないようにしています。
次に、お客様自身のガバナンスの観点があります。Azure Policy の「Allowed locations」などを使って、「このテナントからリソースを作成して良いのは日本とアジアだけ」「EU データは必ず EU 域内に置く」といった社内ルールとして強制しているお客様もいらっしゃいます。これにより、プロジェクトや担当者ごとの判断に任せてバラバラなリージョンを使うのではなく、組織としてデータの所在やシステム構成をコントロールしやすくなります。リージョン制限は、「勝手に海外に作られていた」「いつの間にか別リージョンに本番が立っていた」といった事態を未然に防ぐための仕組みでもあります。
もしリージョン制限がまったく存在しなかったとすると、開発者や運用者のちょっとした操作だけで、コンプライアンスに合わない場所にデータを置いてしまうヒューマンエラーや悪意による問題の発生が起こりえます。また、チームや拠点ごとに好きなリージョンを使い始めれば、時間の経過とともに「このシステムのデータはどこにあるのか」「どのリージョンを監視しておけばよいのか」が分かりにくくなり、DR 計画やインシデント対応、監査対応のたびに大きなコストが発生し得ます。ネットワーク的にも、アプリとデータベースが別リージョンに散らばることでレイテンシやデータ転送料金が膨らみ、なぜ遅いのかや、なぜ高いのかが見えにくくなる可能性があります。
したがって、リージョン制限は、自由度を大幅に削っているわけではなく、コンプライアンスやガバナンスを破綻させないために、「どこにリソースを置いてよいか」を明示的にコントロールするための仕組みです。そのうえで、必要な場合にはサポートに例外付与を相談できる、というのが基本的な考え方になります。
リージョン制限関連エラーが出たときにお客様ができること
- なぜそのリージョンが必要なのかを整理する
- Azure Policy による制限を確認する
- サブスクリプション種別・契約条件を確認する
- 代替リージョンの候補を検討する
- どうしてもそのリージョンが必要な場合はサポートに相談する
- 上記で整理した理由（なぜそのリージョンが必須なのか、代替案が難しい理由、必要な台数・スペック・時期）をまとめたうえで、Azure サポートに対し、当該リージョンへのアクセス権付与や例外設定が可能かどうかをご相談ください
オンプレとの違いを活かした設計・運用のポイント
オンプレミスでは、最初に最大構成をまとめて買っておくことも安全策になりがちでしたが、クラウドではスケールアップとスケールダウンを前提にした設計・運用に切り替えることで、性能とコストのバランスを取りやすくなります。検証環境では小さいコンピュートサイズでコストを抑え、本番リリース前や負荷が高くなる期間だけ一時的にスケールアップする。本番環境では、繁忙期の前だけサーバーサイズを上げ、ピーク終了後にスケールダウンする。こうした運用は、Azure が提供する柔軟性を最も活かせる使い方の一つです。
その一方で、その柔軟性はキャパシティ、クォータ、リージョン制限といったレイヤーの上に成り立っているため、大規模なスケールや重要イベント前の増強が見込まれる場合には、早めにこれらの観点も含めて準備することが重要です。クラウドの「必要なときに必要なだけリソースを増やせる」という価値と、物理キャパシティやガバナンスの制約をうまく両立させることで、より安心してご利用いただけるようになるはずです。
本記事でご紹介した内容が、Azure Database for MySQLフレキシブル サーバーやAzure Database for PostgreSQLフレキシブル サーバーをご利用いただくうえで、容量エラーの理解やトラブルシューティングの一助になれば幸いです。実際の運用の中で、「こういうケースではどう考えればよいか」「このパターンも説明してほしい」といったご要望があれば、ぜひ気軽にフィードバックをお寄せください。いただいた声をもとに、今後もドキュメントやプラットフォームの改善を続けていきたいと考えています。
参考情報
本記事に関連する詳細な手順や仕様については、以下のドキュメントもあわせてご参照ください。
Azure Database for MySQL の容量エラーを解決する
https://learn.microsoft.com/ja-jp/azure/mysql/flexible-server/resolve-capacity-errors
Azure Database for MySQL のクォータの増加を要求する
https://learn.microsoft.com/ja-jp/azure/mysql/flexible-server/how-to-request-quota-increase
Azure Database for PostgreSQL のクォータの引き上げを要求する
https://learn.microsoft.com/ja-jp/azure/postgresql/configure-maintain/how-to-request-quota-increase
Azure Database for PostgreSQL の制限
https://learn.microsoft.com/ja-jp/azure/postgresql/configure-maintain/concepts-limits
Azure Policy の概要（Allowed locations などのポリシーによるリージョン制御）
https://learn.microsoft.com/ja-jp/azure/governance/policy/overview
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。