Azure SQLの「Azure SQL update for early-May 2026」で押さえるべき結論は、Azure SQL Managed InstanceのBusiness Criticalで、vCoreを増やさずにメモリ量を調整できるPublic Previewが追加されたという点です。CPUは足りているのにメモリ不足で性能が伸びない環境では、過剰なvCore増強を避けながらパフォーマンス改善を狙える可能性があります。
ただし、この更新は「Public Preview」です。MicrosoftのAzure Updatesでは、In previewは非運用環境での利用とテスト向けの位置づけと説明されています。まずは本番適用を急がず、対象条件、料金、フェールオーバーの影響、APIやIaCの対応状況を確認し、検証環境で効果を測ることが重要です。(Microsoft Azure)
Azure SQL update for early-May 2026の変更点
今回の更新は、2026年5月上旬のAzure SQL向けPublic Previewとして案内されたものです。中心となる内容は、Business CriticalのAzure SQL Managed Instanceでメモリを適正サイズに調整できる機能です。
Microsoft Learnでは、この機能は「Flexible memory」として説明されており、従来は選択したvCore数によって静的に決まっていたメモリ割り当てを、vCore数を変えずに変更できる機能とされています。特に、既定のメモリ割り当てでは不足するワークロードに有効です。(Microsoft Learn)
| 観点 | これまでの考え方 | 今回の更新で可能になること |
|---|---|---|
| メモリ不足への対応 | vCoreを増やしてメモリも増やす | vCore数を維持したままメモリ量を増やせる |
| コスト最適化 | CPUが余っていても上位サイズへ変更しがち | メモリだけを追加し、過剰なCPU増強を避けやすい |
| 対象 | vCoreとメモリの組み合わせが固定的 | 対応構成ではメモリ割り当てを選択可能 |
| 注意点 | 通常のスケール変更と同様に計画が必要 | メモリ変更時にフェールオーバーが発生するため、事前調整が必要 |
ここで重要なのは、これは「自動的にAzureが最適なメモリ量へ調整してくれる機能」ではないことです。管理者が現在の負荷、待機統計、Query Store、Azure Monitorなどを見ながら、適切なメモリサイズを選ぶ運用になります。
対象となる環境
今回のPublic Previewは、Azure SQL全体のすべてのサービスに適用されるわけではありません。対象は、Azure SQL Managed InstanceのBusiness Criticalサービスレベルです。
Microsoft Learnでは、Flexible memoryがPremium-seriesハードウェア上の構成で利用でき、Business Criticalではローカル冗長インスタンスとゾーン冗長インスタンスが対象、かつBusiness CriticalではPreviewであると説明されています。(Microsoft Learn)
| 項目 | 対象かどうか | 確認ポイント |
|---|---|---|
| Azure SQL Managed Instance | 対象 | ただしBusiness Criticalが前提 |
| Azure SQL Managed Instance Business Critical | 対象 | Premium-seriesハードウェアか確認 |
| ローカル冗長のBusiness Critical | 対象 | リージョン対応も確認 |
| ゾーン冗長のBusiness Critical | 対象 | 可用性要件とフェールオーバー設計を確認 |
| Azure SQL Database 単一データベース | 対象外 | 今回の主対象ではない |
| Azure SQL Database エラスティックプール | 対象外 | Managed Instance向けの更新として整理する |
| SQL Server on Azure VM | 対象外 | VMのサイズ変更やSQL Server設定の話とは別 |
既存インスタンスでも新規インスタンスでも利用できる点は実務上のメリットです。一方で、利用できるリージョン、サブスクリプション種別、クォータには制約があります。Azure SQL Managed Instanceはサポートされているリージョンでのみ作成でき、必要に応じてAzure Portalからサポートリクエストを送る流れになります。(Microsoft Learn)
何がうれしいのか：メモリ不足だけを狙って改善しやすくなる
Business CriticalのAzure SQL Managed Instanceでは、ミッションクリティカルな業務アプリケーション、基幹系データベース、レポーティングを含む高負荷環境で利用されることがあります。そのような環境では、CPUよりも先にメモリがボトルネックになるケースがあります。
たとえば、次のような状態です。
| よくある状況 | Flexible memoryで期待できること |
|---|---|
| CPU使用率は高くないが、クエリが遅い | メモリ不足が原因なら改善余地がある |
| 大きな集計や並べ替えでtempdbへのスピルが多い | メモリ付与量の余裕によりスピル削減を検証できる |
| バッファキャッシュ不足で読み取りI/Oが増えている | データページをメモリに保持しやすくなる可能性がある |
| メモリ目的でvCoreを増やすとCPUが余る | 追加メモリ課金で済むか比較できる |
| ライセンスや予約容量の都合でvCore増加を避けたい | CPU構成を変えずに性能改善を検証できる |
ただし、メモリを増やしてもすべての性能問題が解決するわけではありません。CPUが常時逼迫している、ログ書き込みが詰まっている、ネットワーク待ちが大きい、インデックス設計が不適切、といった問題では、メモリ増強よりも別の対策が優先されます。
メモリサイズの選択範囲
Flexible memoryでは、選択中のvCore数に応じて指定できるメモリ量が決まります。Microsoft Learnでは、4 vCoreなら28GBから48GB、8 vCoreなら56GBから96GB、16 vCoreなら112GBから192GBのように、サポートされる値が示されています。(Microsoft Learn)
主な例を整理すると、次のようになります。
| vCore数 | 最小メモリ | 最大メモリ | 指定できる主な値 |
|---|---|---|---|
| 4 | 28GB | 48GB | 28 / 32 / 40 / 48GB |
| 8 | 56GB | 96GB | 56 / 64 / 80 / 96GB |
| 16 | 112GB | 192GB | 112 / 128 / 160 / 192GB |
| 24 | 168GB | 288GB | 168 / 192 / 240 / 288GB |
| 32 | 224GB | 384GB | 224 / 256 / 320 / 384GB |
| 40 | 280GB | 480GB | 280 / 320 / 400 / 480GB |
| 48 | 336GB | 480GB | 336 / 384 / 480GB |
| 56 | 392GB | 448GB | 392 / 448GB |
| 64 | 448GB | 448GB | 448GB |
| 80 | 560GB | 560GB | 560GB |
| 96 | 560GB | 560GB | 560GB |
| 128 | 560GB | 560GB | 560GB |
この表から分かるように、柔軟に増やせる余地が大きいのは、主に4〜40 vCore付近です。64 vCore以上では上限が固定または頭打ちになるため、「大規模インスタンスなら必ず追加メモリの余地がある」と考えない方が安全です。
料金面で確認すべきポイント
Flexible memoryを使うと、追加したメモリはGB単位・時間単位で課金されます。Microsoft Learnでは、課金対象メモリは「合計メモリ − 既定メモリ」で計算されると説明されています。たとえば、4 vCoreで40GBを割り当てる場合、既定の28GBを超える12GB分が課金対象になります。(Microsoft Learn)
| 確認項目 | 実務での見方 |
|---|---|
| 追加メモリ単価 | 利用リージョンと契約条件により異なるため、Azure Pricing Calculatorや請求画面で確認する |
| vCore増強との比較 | 追加メモリのみの費用と、vCoreを上げた場合の費用を比較する |
| 予約容量・Azure Hybrid Benefit | vCore側のコスト最適化と追加メモリ料金を分けて考える |
| 検証期間のコスト | Preview検証中も課金が発生する前提で予算を確保する |
| タグ管理 | 検証用インスタンスや追加メモリ変更の目的をタグで残す |
コスト最適化の観点では、「メモリを増やせるから最大まで上げる」のではなく、「性能改善に必要な最小限のメモリを探す」ことが大切です。最初から最大値にするより、1段階ずつ増やして、クエリ時間、待機統計、I/O、CPU使用率の変化を見る方が判断しやすくなります。
設定変更時の注意点
Flexible memoryはAzure Portalの「Compute + storage」から変更できるほか、REST APIではproperties.memorySizeInGBを使って指定できます。APIは2024-08-01-preview以降のManaged Instance Create or Updateで利用する説明になっています。(Microsoft Learn)
特に注意すべきなのは、メモリ割り当ての変更がインスタンス内のすべてのデータベースに適用され、最終操作としてフェールオーバーが実行される点です。(Microsoft Learn)
| 注意点 | 具体的な対策 |
|---|---|
| フェールオーバーが発生する | メンテナンス時間帯に実施し、アプリ側の再接続を確認する |
| すべてのデータベースに影響する | インスタンス単位で影響範囲を棚卸しする |
| Preview APIを使う場合がある | IaC、CI/CD、承認フローでPreview API利用を明示する |
| 指定できる値が限られる | vCore数ごとのサポート値に合わせて設計する |
| 料金が増える | 変更前後の月額見込みをFinOps担当と確認する |
| 性能改善が保証されるわけではない | 変更前後のメトリックを必ず比較する |
フェールオーバーに備えるには、アプリケーション側の接続リトライ、タイムアウト、トランザクション再実行の設計を確認しておく必要があります。特に、長時間実行されるバッチ処理やレポート処理がある場合は、実行中断時の再開方法まで決めておきましょう。
管理者が確認すべきチェックリスト
Azure管理者やDBAは、設定変更の前に次の項目を確認します。
| チェック項目 | 確認内容 |
|---|---|
| サービス種別 | Azure SQL Managed Instanceであるか |
| サービスレベル | Business Criticalか |
| ハードウェア | Premium-seriesハードウェアか |
| 冗長構成 | ローカル冗長またはゾーン冗長の対象構成か |
| リージョン | 対象リージョンで利用可能か |
| vCore数 | 指定できるメモリ値に合っているか |
| クォータ | サブスクリプションとリージョンの制限に余裕があるか |
| 変更時間 | フェールオーバーを許容できる時間帯か |
| 監視項目 | 変更前後で比較するメトリックを決めているか |
| コスト | 追加メモリ課金を予算に反映しているか |
| Preview利用承認 | 社内の本番利用ルールに抵触しないか |
特に見落としやすいのは、Business CriticalのvCoreユニット制限です。Microsoft Learnでは、リージョンごとの制限として、Business Criticalの1 vCoreはGeneral Purposeより多いvCoreユニットを消費する考え方が示されています。大規模環境では、単一インスタンスだけでなく、同一リージョン内のManaged Instance全体で余裕を確認しましょう。(Microsoft Learn)
開発者が確認すべき影響
開発者にとっては、「メモリが増えればアプリのコードを変えなくてよい」と考えがちですが、実際には確認すべき点があります。
まず、フェールオーバー時の接続断に耐えられるかを確認します。Azure SQL Managed Instanceはマネージドサービスですが、設定変更やメンテナンスのタイミングで一時的な接続影響が起こり得ます。アプリケーション側では、短時間の接続失敗に対するリトライ、冪等な処理、バッチ再実行の仕組みを整えておくことが重要です。
次に、クエリプランの変化を確認します。メモリ量が増えることで、大きなソート、ハッシュ結合、集計処理の挙動が変わる可能性があります。Query Storeを使って、変更前後の実行時間、CPU時間、論理読み取り、待機時間を比較しましょう。
最後に、メモリ増強を「悪いSQLの延命策」にしないことです。不要な全表スキャン、過剰なSELECT句、古い統計情報、欠落インデックスが原因なら、メモリを増やしても根本解決になりません。まずは性能問題を分類し、メモリ不足が主因である場合に使うのが適切です。
使うべきケース、見送るべきケース
Flexible memoryは便利な選択肢ですが、どの環境にも向くわけではありません。判断基準を分けて考えると、導入可否を決めやすくなります。
| 判断 | 具体的な状況 |
|---|---|
| 使う価値が高い | CPU使用率は余裕があるが、メモリ不足に起因する待機やI/O増加が見られる |
| 使う価値が高い | vCoreを増やすとCPUが大きく余り、コスト効率が悪い |
| 使う価値が高い | 大きな集計、分析、レポート処理でメモリ付与量が課題になっている |
| 使う価値が高い | Business Criticalを使う理由はあるが、CPUよりメモリを細かく調整したい |
| 慎重に検討 | 本番環境でPreview機能を使う社内ルールが未整備 |
| 慎重に検討 | フェールオーバーによる一時影響を許容できない |
| 慎重に検討 | 性能問題の原因がCPU、ログI/O、ネットワーク、ロック待ちである |
| 見送るべき | Azure SQL DatabaseやSQL Server on Azure VMなど、対象外のサービスを使っている |
| 見送るべき | 対象リージョンやクォータの制約を満たせない |
移行・展開の進め方
既存のBusiness Critical Managed Instanceで検証する場合は、いきなり本番に適用せず、段階的に進めます。
| 手順 | 作業内容 | 成果物 |
| -: | ————— | ——————————- |
| 1 | 対象インスタンスを棚卸しする | サービスレベル、vCore、ハードウェア、リージョンの一覧 |
| 2 | ボトルネックを分類する | CPU、メモリ、I/O、ロック、クエリ設計の切り分け結果 |
| 3 | 変更前のベースラインを取る | 主要クエリの実行時間、待機統計、I/O、CPU、メモリ関連指標 |
| 4 | 検証環境でメモリを1段階増やす | 変更値、変更時刻、フェールオーバー影響の記録 |
| 5 | 変更後の性能を比較する | 改善率、追加コスト、想定リスク |
| 6 | 本番適用可否を判断する | 承認記録、ロールバック手順、監視計画 |
| 7 | 本番反映後に監視する | 24〜72時間程度の負荷推移と請求影響の確認 |
検証では、単に平均応答時間を見るだけでは不十分です。ピーク時間帯、バッチ時間帯、レポート実行時、バックアップやメンテナンスと重なる時間帯など、実際に問題が出やすい条件で比較しましょう。
失敗しやすいポイント
今回の更新で失敗しやすいのは、機能そのものを誤解して導入するケースです。
| 失敗パターン | なぜ問題か | 回避策 |
|---|---|---|
| Public Previewを本番標準機能として扱う | 仕様変更や制約のリスクを見落とす | 社内のPreview利用ルールに沿って承認する |
| メモリ増強で全性能問題が解決すると考える | CPU・I/O・ロック待ちには効かない場合がある | 待機統計とQuery Storeで原因を分類する |
| 最大メモリまで一気に上げる | 追加コストの妥当性を判断しにくい | 1段階ずつ増やして効果を測る |
| フェールオーバー影響を見積もらない | アプリ側で接続断や処理中断が起きる | メンテナンス枠、リトライ、再実行手順を準備する |
| IaCの対応を確認しない | REST APIでは使えても運用コードに反映できない場合がある | APIバージョンとプロビジョニング手順を事前確認する |
| コスト比較をしない | vCore増強より安いとは限らない | 追加メモリ料金とスケールアップ案を比較する |
よくある質問
既存のAzure SQL Managed Instanceでも使える？
Microsoft Learnでは、新規および既存のSQL Managed Instanceに対して、Azure PortalまたはREST APIでメモリ割り当てを変更できると説明されています。ただし、対象となるサービスレベル、ハードウェア、リージョン、冗長構成を満たす必要があります。(Microsoft Learn)
vCoreを減らしてメモリだけ増やせる？
今回の機能は、選択したvCore数の範囲内でメモリ割り当てを変更するものです。vCoreの変更は別のスケール操作として考える必要があります。コスト最適化を狙う場合は、「現在のvCoreを維持してメモリを増やす案」と「vCore構成そのものを変える案」を分けて比較しましょう。
Azure SQL Databaseでも使える？
今回の更新は、Azure SQL Managed InstanceのBusiness Criticalに関する内容です。Azure SQL Databaseの単一データベースやエラスティックプールのメモリ設定を個別に変更する機能として捉えないようにしましょう。
メモリを増やすと必ず速くなる？
必ず速くなるわけではありません。効果が出やすいのは、メモリ不足によってデータ読み取り、クエリメモリ付与、tempdbスピルなどが問題になっているケースです。CPU、ログI/O、ロック、ネットワーク、アプリケーション側の待機が原因なら、メモリ増強の効果は限定的です。
本番環境で使ってよい？
今回の機能はPublic Previewです。Azure UpdatesではIn previewが非運用環境での使用とテスト向けであると説明されています。実運用で検討する場合は、Microsoftの最新ドキュメント、サポート条件、社内のリスク管理ルール、フェールオーバー時の影響を確認したうえで判断してください。(Microsoft Azure)
まず取るべき行動
Azure SQL update for early-May 2026は、Business CriticalのAzure SQL Managed Instanceを使っている企業にとって、性能改善とコスト最適化の選択肢を増やす更新です。特に、CPUではなくメモリがボトルネックになっている環境では、vCoreを過剰に増やさずに改善を試せる点が大きなメリットです。
一方で、Public Previewであること、変更時にフェールオーバーが発生すること、追加メモリが課金対象になることは必ず押さえておく必要があります。
まずは、対象インスタンスのサービスレベル、ハードウェア、vCore数、リージョンを確認しましょう。そのうえで、メモリ不足が疑われるワークロードを1つ選び、検証環境で1段階だけメモリを増やして、性能とコストの変化を測るのが現実的な進め方です。
コメント