Azure Database for PostgreSQL フレキシブル サーバーがストレージ逼迫後に「起動中(Starting)」のまま戻らない――この状態はポータル操作が制限され、復旧の糸口が見えにくいトラブルです。本記事では実際に復旧した事例（CPU 100%＋予約領域ファイル）を軸に、切り分け・サポート依頼のポイント・再発防止まで具体的に解説します。
「Starting（起動中）」から復帰しないときに起きていること
Azure Database for PostgreSQL フレキシブル サーバーは、停止後の起動時に内部でいくつかの初期化・整合性処理（回復処理、構成の適用、ストレージ接続の確認、バックアップ連携の再確立など）を順に進めます。通常は数分〜長くても数十分で「Ready（利用可能）」に戻ります。
ところが、ストレージ不足をきっかけに異常停止が発生した後は、起動時の回復処理が通常より重くなり、さらにCPU が張り付く、内部ファイルが異常状態、ストレージやバックアップ連携が不整合といった要因が重なると、起動シーケンスが完了できず Starting のまま固まることがあります。
今回の質問で起きていた症状（整理）
- ストレージ使用量が急増し、容量不足になった
- 接続不可になったため、一度停止した
- 起動後、ポータル表示が「Starting（起動中）」から数日変わらない
- Ready ではないため、ポータル上のストレージ変更などができない（操作がグレーアウト/失敗）
| 観点 | よくある見え方 | ユーザーが困るポイント |
|---|---|---|
| 状態 | Starting のまま長時間固定 | スケール変更や設定変更が通らない |
| 接続 | DB 接続不可（タイムアウト/拒否） | SQL で原因調査・掃除ができない |
| リソース | CPU が 90〜100% で張り付き | 起動処理が進まず、復旧の出口が見えない |
| ストレージ | 使用率が高止まり（逼迫/満杯） | 「増やせば直る」状況でも増やせないことがある |
直接原因と、実際に行われた復旧対応（今回の事例）
直接的な原因
バックエンド側の調査により、今回の事象は次の条件が重なっていました。
- サーバーの CPU 使用率が常に 100%の状態になり、起動処理が完了できない
- 内部的に「予約領域ファイル（reserved space file）」が原因となって高負荷が継続していた
ここでいう「予約領域ファイル」は、サービス側で安全運用のために確保・利用される領域／ファイル（名称や実装はマネージドサービス内の要素）を指します。ユーザーが通常の手段（SQL や OS 操作）で直接触れない領域で問題が起きると、ポータルから見える範囲だけでは原因特定が難しくなります。
Microsoft サポート側で実施された対処
- 問題となっていた予約領域ファイルを削除
- 併せてSAS キー（共有アクセス署名）のリセット
- 結果として起動シーケンスが完了し、ポータル上の状態がStarting → Ready（利用可能）に復帰
ポイント：この手の「Starting 固着」は、ユーザー側の設定変更や再起動だけではどうにもならない“内部要因”が含まれることがあります。今回の復旧も、まさにサポートでしか触れない領域への対応によって回復しています。
同じ状況で、ユーザー側がまずやるべき切り分け
Starting が数日続いている場合でも、闇雲に操作を繰り返すと復旧が遅れることがあります。以下は「最短で原因候補を絞り、サポートへ正確に渡す」ための手順です。
1) まず確認すべきメトリック（ポータル / Azure Monitor）
ポータルの対象サーバーから Azure Monitor（メトリック）を開き、直近数時間〜数日で次を確認します。
| メトリック | 見るべき状態 | 疑うこと |
|---|---|---|
| CPU 使用率 | 90〜100% に長時間張り付き | 回復処理のループ、内部タスクのスタック、特定処理の異常 |
| ストレージ使用率 / 使用量 | 逼迫（例：80〜95%超）や満杯付近 | 書き込み不可→回復処理が進まない、内部保守が完走できない |
| IO 関連（ある場合） | 高止まり、スパイクが継続 | WAL/回復処理での読み書き地獄、断続的な再試行 |
| 接続数 | 0 のまま / 急増してすぐ 0 | 起動が最後まで行けていない、または接続受付前で停止 |
今回のケースでは、特にCPU 100% が継続していた点が「起動が終わらない直接理由」として効いています。
2) 「ストレージ不足が原因か？」を現実的に判断する
ストレージが急増して接続不能になった、という時点でストレージ逼迫が引き金である可能性は高いです。ただし Starting 固着は、ストレージを増やせば必ず直るとは限りません。ストレージ不足 → 回復処理が異常化 → CPU 張り付き → 操作不能、という“二次障害”が起きると、増量操作そのものが塞がれることがあります。
判断材料として、次のような状況が揃うほど「自力復旧が難しい」寄りになります。
- Starting が数時間を超えて継続し、状態が変化しない
- 停止/起動/再起動を試しても同じ状態に戻る
- CPU が高止まり（90〜100%）し続ける
- ストレージ変更・スケール変更がポータルで無効化/失敗する
3) Activity Log（アクティビティログ）で「失敗の種類」を押さえる
サーバーのリソース画面からアクティビティログを確認し、起動・停止・更新操作がどのような結果になっているかを確認します。
- 開始操作が成功扱いなのに Ready にならない（＝バックエンドで起動シーケンスが完了していない）
- 更新操作（ストレージ増量など）が失敗し、その失敗理由が一定（＝状態依存でブロックされている）
ここで得られる「失敗コード」や「エラーメッセージの断片」は、サポートに渡す情報として非常に有効です。
ユーザー側で試せる対処と、期待値
ストレージ増量（できる場合は最優先）
ストレージ逼迫が疑われる場合、基本は「計算 + ストレージ」からストレージのスケールアップ（増量）です。増量によって回復処理や保守処理が完走できるようになり、結果的に Ready に戻ることがあります。
ただし今回のように Starting 固着でポータル操作が無効化される場合は、ここで詰まります。CLI など別経路での更新も、内部状態がブロックしていれば失敗することがあり、「増量したいのに増量できない」が最大の詰みポイントになります。
停止→起動の繰り返しは「やり過ぎない」
停止→起動の再試行で直るケースもゼロではありませんが、次の状態なら繰り返しは逆効果になりやすいです。
- 起動直後から CPU が即 100% に張り付く
- 起動処理が毎回同じ時間だけ進んで止まる（＝同じ箇所で詰まっている）
- Starting のまま長時間経過しても変化がない
マネージドサービスの起動処理は内部の再試行やキュー処理を含むため、ユーザー側の頻繁な操作で「復旧の順番待ち」をリセットしてしまう可能性があります。1〜2回確認してダメなら、次は情報収集とサポート連携に切り替えるのが現実的です。
「接続できた瞬間」がもし来たら、最短でやること
まれに一瞬だけ接続が通る／起動が進むことがあります。その場合は原因調査よりも先に、安全側に倒す応急処置を優先します。
- 不要データの削除（巨大テーブルの整理、古いパーティション削除、肥大化した一時データの削除）
- ログや監査設定が原因で肥大化している場合は出力量の見直し
- 最優先でストレージ増量（可能なら）
ただし、Starting 固着中は接続自体ができないことが多いため、ここは「接続できたらやるチェックリスト」として持っておく位置づけになります。
結論：Starting 固着で操作不能なら、サポート連携がほぼ必須になる理由
Azure Database for PostgreSQL フレキシブル サーバーはマネージドサービスのため、OS レベルの操作で内部領域を直接修復できません。特に次の条件が揃うと、ユーザーができる手段が一気に減ります。
- サーバー状態が Ready ではない（＝更新操作の多くがロックされる）
- 接続できない（＝SQL で掃除・調査ができない）
- CPU 100% など、起動処理が完走できない状態が固定されている
今回の復旧は、予約領域ファイルの削除とSAS キーのリセットという、ユーザー側では実施できない対応で回復しています。つまり「やり方が分かれば自力で直せる」というより、内部要因を取り除く権限が必要なタイプの障害です。
サポートに出すときに“最短で進む”情報のまとめ方
チケットを切るときは「状況説明が長い」よりも「調査に必要な事実が揃っている」方が進みます。以下のテンプレを埋めて渡すのがおすすめです。
サポート依頼テンプレ（そのまま使える形）
- 対象：Azure Database for PostgreSQL Flexible Server（サーバー名 / リソースID）
- 発生日時：ストレージ急増を検知した日時、接続不可になった日時、停止/起動を実施した日時
- 現象：起動後に状態が Starting のまま（継続時間：○時間/○日）
- 影響：接続不可、ポータルからストレージ変更不可（操作が無効化/失敗）
- メトリック：CPU 使用率（最大/平均/推移）、ストレージ使用率（推移）
- 試したこと：停止→起動、再起動、更新操作（失敗した操作とエラー）
- アクティビティログ：失敗レコードの有無（失敗コード/メッセージ断片）
| 添付/共有できると強い情報 | 例 | 効果 |
|---|---|---|
| CPU/ストレージのグラフ画像 | 直近24時間〜7日 | 「いつから異常化したか」が一目で分かる |
| アクティビティログの失敗詳細 | 開始/更新操作の失敗 | バックエンド調査の入口が早くなる |
| ストレージ急増のきっかけ | バッチ開始、ログ設定変更、特定アプリのデプロイ | 根本原因（再発防止）の特定に直結 |
再発防止：ストレージ急増と CPU 張り付きの“予兆”を運用で潰す
今回のような障害は「ある日突然」というより、メトリック上は予兆が出ることが多いです。特にストレージ使用率とCPU 使用率は、Starting 固着の前段で異常値になりやすい代表格です。
推奨アラート設定（Azure Monitor）
以下は実運用で使いやすい目安です。環境（ワークロードやピーク特性）に合わせて微調整してください。
| 監視対象 | しきい値（例） | 評価期間（例） | 狙い |
|---|---|---|---|
| ストレージ使用率 | 80% 超 | 5〜15分 | 増量・掃除の初動を早くする |
| ストレージ使用率 | 90% 超 | 5分 | 緊急対応（即増量/原因調査） |
| CPU 使用率 | 90% 超 | 15〜30分 | 高負荷の継続を検知（暴走バッチ/回復処理の詰まり） |
| 接続失敗の兆候（ログ/メトリックがある場合） | 急増 | 5〜15分 | アプリ側でのリトライ嵐→負荷増の連鎖を止める |
「ストレージが急増する」典型パターンと対策アイデア
PostgreSQL では、ストレージ急増の原因がアプリ側の変更に紐づくことも多いです。代表例と、今日からできる対策をまとめます。
| 急増パターン | 起きがちな原因 | 対策（例） |
|---|---|---|
| ログ/監査の出力増 | ログレベル上げっぱなし、監査対象が広すぎる | 必要期間だけ上げる運用、出力先・保持期間の設計 |
| 巨大データの一括投入 | ETL/バッチの暴走、重複投入 | 投入量の上限、ジョブのガードレール、重複排除 |
| 削除しているのに減らない | 肥大化（VACUUM/再利用待ち）、大きいトランザクション | 定期メンテ設計、パーティション運用、削除より入替戦略 |
| 一時領域の膨張 | ソート/ハッシュがディスクに退避、重い集計 | クエリ改善、インデックス、ワークロード分離 |
運用チェックリスト（障害を“起こさない”ための仕組み）
- ストレージ80%アラートで「増量 or 掃除」を必ず実施する運用にする
- CPU 高止まりアラートで「直近のデプロイ/バッチ/クエリ変更」を必ず確認する
- 月次/週次でメトリックを見返し、普段のベースライン（通常時の CPU/IO/ストレージ増分）を把握しておく
- アプリ側のリトライが過剰にならないよう、リトライ間隔・回数に上限を設ける
- 「ストレージが増えたらどの順で消すか」「増量判断は誰がするか」を手順書化しておく
Starting 固着時の“現実的な復旧ルート”まとめ
最後に、今回の事例を踏まえた復旧ルートを整理します。
最短ルート（今回のケースに近い状況）
- メトリックで CPU 100% 張り付きや ストレージ逼迫を確認
- ポータルでストレージ増量ができない（または失敗）ことを確認
- アクティビティログの失敗情報を添えて Microsoft サポートへ連絡
- バックエンド調査で内部要因（例：予約領域ファイル）が判明
- サポート対応（例：予約領域ファイル削除、SAS キーリセット）で Starting → Ready に復帰
- 復帰後に、ストレージ急増の根本原因（ログ、バッチ、クエリ、データ増）を潰して再発防止
重要な学び
- 「ストレージ不足」はきっかけであり、Starting 固着は二次障害として発生しうる
- Ready ではないと操作が塞がれ、ユーザー側だけでは詰む局面がある
- サポートに渡すべき最重要情報はCPU・ストレージの推移と失敗ログ
- 再発防止は「監視」ではなく、アラート→具体アクションまでを運用に組み込むのが肝
まとめ
本件は「ストレージ不足をきっかけに、CPU 100％状態と予約領域ファイルの問題が重なり、起動処理が完了できず Starting のまま固まっていた」ケースでした。実際の復旧は Microsoft 側の内部対応（予約領域ファイルの削除と SAS キーリセット）で行われ、サーバーは Ready に戻りました。
同様の事象が起きた場合は、まず CPU・ストレージのメトリックとアクティビティログで状況を固め、ポータルで操作不能なら早めにサポートへエスカレーションするのが最短です。そして再発防止として、ストレージと CPU のアラートを仕組み化し、急増の原因（ログ・バッチ・クエリ・データ設計）を継続的に潰す運用が有効です。
コメント