Azure Database for PostgreSQL フレキシブル サーバーのサイズ変更後、ポータルのステータスが「更新中 (Updating)」のまま数時間進まず、再起動もできない——現場でよく出会う“詰まり”です。本記事では、実際に発生した事例をベースに、根本原因の理解から復旧の要点、再発防止の設計・運用までを、コマンド例やチェックリストとともに体系的に解説します。現場で即使えるRunbook付きです。
事象の概要と前提
同一コンピュート層（例：汎用／メモリ最適など）で Azure Database for PostgreSQL フレキシブル サーバーの SKU を変更したところ、以下が発生。
- ポータル表示：「更新中 (Updating)」から進まず、長時間（数時間）経過。
- 操作の制限：再起動・停止が不可（ボタンが無効、または実行しても効果なし）。
- 監視面：アクティビティ ログに明確なエラーが出ない／サービス正常性アラートも届かない。
この挙動は、バックエンドでの仮想マシン（VM）割り当て・起動に関連する内部処理の滞留で起きることがあります。実際のケースでは、アップグレード処理が WaitingForVirtualMachineStartForUpgrade に留まり、同一可用性ゾーン（AZ）でのリソース逼迫により VM の割り当てに失敗していました。
原因・一次対応・回避策の要点
| 観点 | 詳細 |
|---|---|
| 原因 | 内部調査の結果、アップグレード処理が WaitingForVirtualMachineStartForUpgrade で停止。同一ゾーン内のリソース需要増加により VM の割り当てが不成立となり、プロビジョニングが進行不能に。 |
| 一次対応 | Microsoft サポート側で内部再割り当て（強制リトライ／別ホスト再配置）を実施し、サーバーは復旧。 |
| 再発防止・回避策 | 同じ AZ 内で vCPU/メモリが近い別世代の SKU（例：Intel V4 / AMD V5）へスケールし、空きキャパシティのある SKU を選定。 別 AZ（例：AZ02、AZ03）で Intel V5 SKU を新規デプロイし、混雑ゾーンを回避。 変更作業は可能なら需要の少ない時間帯（夜間・週末）に実施。 |
| 補足アドバイス | 長引く場合はサポート チケットを起票し、割り当てステータスの確認と再割り当てを依頼。 CLI や PowerShell で az postgres flexible-server show --name <server> を定期実行し、state / status を監視。 事前バックアップ（PITR 前提の保持確認）とメンテナンス ウィンドウの見直しでダウンタイムを最小化。 |
内部で何が起きているのか（仕組みの理解）
フレキシブル サーバーのサイズ変更は、背後で新しい計算リソース（VM）への差し替えや、I/O の再最適化などを伴います。同一コンピュート層内のスケールであっても、該当 AZ に空きキャパシティがなければ、割り当て待ち（キューイング）が発生し、WaitingForVirtualMachineStartForUpgrade のような内部状態で停止します。これは失敗というより進行不能な待機であり、ユーザー操作で中断やロールバックができない場合があります。
まずやるべき確認（5 分チェック）
- Activity Log：対象サーバーの最近の “Update” 操作に対して、Start/Accepted/Succeeded/Failed のイベントと correlationId を確認。
- Resource Health：状態が “Available / Degraded / Unavailable / Unknown” のいずれか。Unknown/Degraded が続く場合は要エスカレーション。
- Server プロパティ：CLI で
state、SKU、AZ を取得し、どのゾーン・世代で詰まっているかを把握。
az postgres flexible-server show \
--name <serverName> \
--resource-group <rgName> \
--query "{state:state, zone:availabilityZone, sku:sku.name, ha:highAvailability.state}"
即時復旧の選択肢（優先度順）
1) サポートによる「再割り当て」要求（最短ルート）
工事中の“待ち”をユーザー側で解除できないときは、サポートに強制リトライ・別ホスト再配置を依頼するのが最も手堅いです。チケットには以下を添えます。
- サブスクリプション ID、リソース グループ、サーバー名、リージョン、AZ。
- 実行した変更（元 SKU → 先 SKU、実行時刻、所要時間）。
- Activity Log の correlationId と該当タイムスタンプ。
- 業務影響（RTO / RPO 目標、疎通不可時間、代替系の有無）。
2) 別 AZ / 別 SKU による退避（PITR）
RTO を短縮したい場合、ポイントインタイム復元（PITR）で新サーバーを作成し、アプリの接続先を切り替える回避策が有効です。混雑する AZ を避け、空きのある AZ と世代（例：AMD V5）を選びます。
# 復元（例）
az postgres flexible-server restore \
--resource-group <rgName> \
--name <newServerName> \
--source-server <srcServerName> \
--restore-time <UTC: 2025-11-06T23:50:00Z> \
--location <region> \
--availability-zone AZ03 \
--sku-name Standard_D8s_v5
復元後は接続文字列・FW/NSG・Private Endpoint/DNS の差し替えを行い、アプリ側のコネクションプールをフラッシュして切替完了を確認します。
3) 待機を続ける場合の監視（上限時間を決める）
「業務影響が小さい」「近く割り当てが空きそう」などの事情で待機する場合も、必ずタイムボックスを設定しましょう（例：60～90 分）。CLI でポーリングし、状態遷移がない場合はプラン B に切り替えます。
# Ready になるまで待機（最大 90 分）
RES_ID=$(az postgres flexible-server show -g <rg> -n <server> --query id -o tsv)
az resource wait --ids $RES_ID --custom "properties.state=='Ready'" --interval 30 --timeout 5400
根本原因の深掘り：なぜ「同一層内」でも詰まるのか
フレキシブル サーバーは、VM ファミリー（例：Intel V4/V5、AMD V5）と可用性ゾーンの空き状況に左右されます。同一コンピュート層（汎用・メモリ最適など）での変更でも、ファミリーやサイズ、AZ の組合せが混雑していると割り当てに失敗し、アップグレードが進みません。特に以下の条件が重なるとリスクが高まります。
- ピーク時間帯（業務時間）に大きめのサイズへスケール。
- 特定 AZ にリソース需要が集中（同一プロジェクトで AZ を固定など）。
- 人気の SKU 世代へ集中（例：コスト効率の良い v5 系）。
キャパシティを事前に読む：SKU/AZ の空き確認
計画変更の前には、利用リージョンで選べる SKU と AZ の対応をチェックします。
# 利用可能な SKU を一覧（リージョンごと）
az postgres flexible-server list-skus \
--location <region> \
--output table
出力から、狙いの SKU が狙いの AZ に存在するか、近似リソースの代替世代（Intel V4 ⇄ AMD V5 など）を比較検討します。
変更時の標準Runbook（現場で回せる手順書）
事前準備
- RTO/RPO、許容停止時間、切替手順（DNS/接続文字列）、ロールバック条件を合意。
- 最新バックアップと復元テストの確認（PITR が有効に機能するか）。
- メンテナンスウィンドウを適切化（アプリ停止・通知）。
- 必要なら読み取りレプリカの凍結（DDL/長大トランザクションの抑制）。
実行
- メトリックのベースライン取得（CPU・メモリ・IOPS・接続数・待機イベント）。
- アプリ側をメンテナンスモードにし、長時間トランザクションを解消。
- SKU 変更を実行（例）：
az postgres flexible-server update \ --resource-group <rg> \ --name <server> \ --sku-name Standard_D8s_v5 - ポーリング監視（Ready 遷移、接続確認、クエリ遅延確認）。
- タイムボックス超過なら PITR 退避またはサポートへ再割り当て依頼。
復旧確認（UAT）
- 接続テスト：アプリ・バッチ・BI からの疎通。
- 性能テスト：代表クエリのレイテンシ比較。
- エラーログ：認証・コネクション・ストレージ警告の確認。
監視・可観測性：詰まりの早期検知
| 視点 | 見るべき項目 | アラート例 |
|---|---|---|
| プロビジョニング | Activity Log の Update/Write 操作の継続時間、correlationId | Update 操作が 30 分超継続で通知 |
| 可用性 | Resource Health（Unknown/Degraded） | Unknown/Degraded が 10 分継続で通知 |
| 接続 | 接続失敗率、待機イベント増加 | 失敗率 > 5% を 5 分継続で通知 |
| 容量 | CPU/メモリ/ストレージ使用率、IOPS 制限近接 | しきい値（例：80%）超過で予兆通知 |
切替・退避時のネットワーク注意点
- Private Endpoint：新サーバー側の Private DNS ゾーンレコード更新が必要。
- NSG/Firewall：送信元サブネット・IP 範囲の再許可を忘れずに。
- 接続プール：アプリ再起動や
pgbouncerのセッションをクリア。
アプリ側のドレイン手順（サンプル）
-- 長時間実行セッションの確認
SELECT pid, usename, state, wait_event_type, wait_event, query
FROM pg_stat_activity
ORDER BY state, now() - query_start DESC
LIMIT 50;
-- メンテナンスモード中、必要に応じてセッション終了
-- SELECT pg_terminate_backend(); 代替 SKU／AZ の選定ヒント
同一層・同等 vCPU/メモリであれば、世代を変える（Intel V4 → AMD V5 など）ことで空きが見つかるケースは多いです。さらに、別 AZ（AZ02 / AZ03 など）への配置は割り当て成功率を上げます。下表は検討の観点です。
| 観点 | チェックポイント | 備考 |
|---|---|---|
| 世代 | Intel V4 / V5、AMD V5 等の可用性 | 同等リソースで価格・性能差を比較 |
| サイズ | vCPU・メモリ比のバランス | メモリ不足は性能劣化の主因 |
| AZ | AZ01/02/03 の空き傾向 | 混雑 AZ を避けて配置 |
| I/O | ディスク種別・IOPS・スループット | ワークロードに合わせて最適化 |
「待ち」が長引いたときの判断基準（意思決定ツリー）
- 0～30 分：正常範囲。待機しつつ監視。
- 30～60 分：高リスク。サポート起票・PITR 退避の準備開始。
- 60～90 分：切替判断。PITR 実行 or 再割り当て依頼の明確化。
- 90 分超：業務影響大。PITR による切替を第一候補に。
運用テンプレート（貼って使える）
変更前チェックリスト
| 項目 | Yes/No | メモ |
|---|---|---|
| PITR 復元テスト済み（直近） | ||
| メンテナンスウィンドウ設定・周知済み | ||
| 候補 SKU（第1～第3）と代替 AZ の用意 | ||
| 接続先/DNS/Private Endpoint の切替手順書 | ||
| アプリ側ドレイン手順・戻し手順 |
実行メモ（コマンド サンプル）
# 現状態の取得
az postgres flexible-server show -g <rg> -n <server> \
--query "{state:state, zone:availabilityZone, sku:sku.name}"
# SKU の候補を事前確認
az postgres flexible-server list-skus --location -o table
# SKU 更新（例）
az postgres flexible-server update -g -n
--sku-name Standard_D8s_v5
# Ready 待機（90 分上限）
RES_ID=$(az postgres flexible-server show -g -n --query id -o tsv)
az resource wait --ids $RES_ID --custom "properties.state=='Ready'" --interval 30 --timeout 5400
# 退避（PITR）作成（AZ/世代を変えて混雑回避）
az postgres flexible-server restore -g
--name
--source-server
--restore-time
--location
--availability-zone AZ03
--sku-name Standard_D8s_v5 HA（ゾーン冗長）構成時の考慮
ゾーン冗長 HA を有効にしている場合、バックエンドでスタンバイが別 AZ に存在します。サイズ変更やホスト再配置のタイミングでは、スタンバイ側のリソース確保が別経路で必要になることがあり、これが混雑するとやはり“待ち”が発生します。HA があるからといって割り当て待ちがゼロになるわけではない点に注意し、変更は低需要帯で実施してください。
よくある質問（FAQ）
Q1. 「更新中」のまま何時間も経つのは正常ですか？
A. 正常ではありません。上限時間（推奨 60～90 分）で判断し、サポート起票や PITR 退避に切り替える方が結果的に早いケースが多いです。
Q2. ユーザー操作でロールバックや強制停止はできますか？
A. 状態によってはできません。無理に操作すると状態遷移が複雑化する恐れがあるため、サポート経由の内部再割り当てが安全です。
Q3. どの SKU にすれば詰まりにくいですか？
A. 一概には言えませんが、同一層・近似リソースで世代を変える（Intel V4 ⇄ AMD V5）か、別 AZを選ぶと成功率が高まります。事前に list-skus で候補を洗い出してください。
Q4. バックアップや PITR は影響を受けますか？
A. バックアップの仕組み自体は維持されますが、直近の更新直後は復元ポイントの選択に注意が必要です。復元時刻はUTC 明示で指定しましょう。
Q5. 変更は営業時間内でも大丈夫？
A. 推奨しません。低需要帯で実施すれば、割り当て失敗時の再試行・退避の余裕を確保できます。
ケーススタディ：実際の復旧までのタイムライン
| 時刻 | イベント | ポイント |
|---|---|---|
| 00:00 | SKU 変更開始（同一層・同一 AZ） | Activity Log に Update/Accepted を確認 |
| 00:30 | 「更新中」継続 | タイムボックス発動。サポート準備 |
| 00:45 | サポート起票（correlationId 添付） | 再割り当て依頼 |
| 01:20 | 内部再割り当て実施 | 数分で Ready へ遷移 |
設計原則：再発を減らす 7 つの実践
- 二重案の準備：第 1 候補 SKU/AZ と第 2 候補を用意し、即時切替できるよう Runbook 化。
- 低需要帯の変更：OS/DB のキャッシュ再構築・アプリのウォームアップ時間も見込む。
- 状態監視の自動化：CLI ポーリングやアラートで“待ち”を自動検知。
- PITR 訓練：四半期ごとに復元ドリルを実施し、RTO/RPO を数値で把握。
- 接続の疎結合化：接続文字列を KeyVault/設定で抽象化し、切替をコード変更なしで実施。
- AZ バランシング：単一 AZ 固定を避け、HA/分散を前提に設計。
- 長大トランザクション抑止：メンテ前の VACUUM/Analyze、バッチ停止でドレイン。
トラブル発生時の情報採取テンプレート
- 発生時刻（JST/UTC）、対象サーバー名、RG、リージョン、AZ。
- 元 SKU → 先 SKU、変更手段（Portal/CLI/IaC）。
- Activity Log の correlationId、status 遷移。
- アプリ影響（対象サービス・SLA・ユーザー数）。
- 直近の構成変更（ネットワーク・セキュリティ・パラメータ）。
最後に：現場での指針
「更新中」で止まる最大の原因は、同一 AZ・同一世代への需要集中に対するキャパシティ不足です。待てば直る時もありますが、タイムボックス・二重案・PITR 退避・サポート再割り当ての 4 点セットを標準化すれば、業務影響を最小化できます。設計段階で別世代／別 AZ の逃げ道を用意し、運用段階で低需要帯での変更・自動監視を徹底しましょう。
付録：コマンド早見表
| 目的 | コマンド | 補足 |
|---|---|---|
| 状態確認 | az postgres flexible-server show -g <rg> -n <server> | state / availabilityZone / sku.name |
| SKU 一覧 | az postgres flexible-server list-skus --location <region> | 世代/サイズ/AZ の候補確認 |
| SKU 更新 | az postgres flexible-server update -g <rg> -n <server> --sku-name <sku> | 同一層内のスケールに利用 |
| Ready 待機 | az resource wait --ids <resId> --custom "properties.state=='Ready'" | 最大待機時間を設定 |
| PITR 復元 | az postgres flexible-server restore ... | 別 AZ / 別世代へ退避 |
付録：変更時のローリング・チェック（実務メモ）
- 変更直前：ロックの多いテーブル・長時間クエリの洗い出し。
- 変更中：ログイン拒否や遅延が出ていないか（簡易ヘルスチェック）。
- 変更後：ページキャッシュの温まりを考慮した性能確認（代表 5 クエリ）。
- トラブル時：PITR の restore-time は UTC で誤指定に注意。
まとめ
「更新中 (Updating)」で止まる問題は、見た目以上に“待ち”の正体が掴みにくく、現場では判断に迷いがちです。しかし、原因＝VM 割り当ての詰まりと捉えれば、対応はシンプルです。すなわち、サポート再割り当てで短期復旧、PITR 退避で業務継続、別世代・別 AZ・低需要帯の 3 点セットで再発確率を下げる。これを Runbook 化して反復運用することが、最短距離の解です。
コメント