Azure Database for MySQL フレキシブルサーバーが更新中から戻らない時の原因と対処法（プライベートエンドポイント・SAL完全解説）

Azure Database for MySQL フレキシブルサーバーを運用していると、サーバーが「更新中（Updating）」からいつまでも戻らず、ポータル表示も不安定になるケースがあります。特にサブスクリプション移動後にプライベートエンドポイントや VNet 統合をやり直したタイミングで発生しやすく、App Service から接続できない状態が長引きがちです。本記事では、サーバーが更新中で固まったように見えるときの原因と、サブネットの委任やサービスアソシエーションリンク（SAL）を含めた具体的な解決手順、再発防止の設計ポイントまでを詳しく解説します。

Azure Database for MySQL フレキシブルサーバーが「更新中」から戻らないときの全体像

Azure Database for MySQL フレキシブルサーバーは、通常ポータルからの設定変更やサブスクリプション移動を行うと、短時間「更新中（Updating）」ステータスになります。しかし、何らかの理由でバックエンドの制御面（コントロールプレーン）の処理が完了しない、もしくは完了しているのにポータル側が正しく反映できないと、いつまでも「更新中」に見えてしまうことがあります。

特に次のような操作が絡むときにトラブルが目立ちます。

Azure Database for MySQL フレキシブルサーバーを別サブスクリプションに移動した
移動後にプライベートリンク（プライベートエンドポイント）を作り直した
同じ VNet 上の App Service から接続できなくなった
問題切り分けのためプライベートエンドポイントを削除したところ、サーバーが長時間「更新中」のままになった
Azure ポータルの表示も不安定で、操作するたびにエラーになったり、状態が変わらない

このような状況では、「MySQL のサービス自体が壊れたのでは？」と不安になりますが、多くの場合は次のような要因が絡んでいます。

ポータル側の一時的な不具合やキャッシュ
サブネットに残った委任（delegation）設定
プライベートエンドポイントに紐づいたサービスアソシエーションリンク（Service Association Link / SAL）の残骸
プライベート DNS ゾーンのリンク・レコード不整合

特に重要なのがサブネットの委任と SALです。これらが残っているとサブネットや関連リソースの削除・更新がブロックされ、結果として MySQL サーバーの更新処理も巻き込まれてしまうケースがあります。

よくあるシナリオとトラブルの流れ

典型的なトラブルの流れを整理しておくと、原因のイメージが掴みやすくなります。

タイミング	操作・イベント	起こりやすい問題
① 事前	既存の MySQL フレキシブルサーバー + プライベートエンドポイント + App Service（VNet 統合）で運用	この時点では正常に接続できている
② サブスクリプション移動	MySQL サーバーを別サブスクリプションへ移動	リソース ID が変わり、プライベートエンドポイントや DNS が旧構成のままになる
③ 接続不可	App Service からの接続エラーが発生	DNS がパブリックを返す、古いプライベート IP を引いている、VNet リンクがズレているなど
④ 再構成	プライベートエンドポイントを再作成したり削除したりする	サブネットに SAL が残り、サブネット更新やリソース更新が詰まる
⑤ 障害	MySQL サーバーが「更新中」から戻らない	ポータル操作が失敗し、実態を確認しづらい状態になる

この「詰まり」がサブネット・プライベートエンドポイント・DNS などのネットワーク周辺で起きていると、MySQL サーバーの状態だけを見ていても解決に辿り着きにくくなります。そこで、まずは 「本当にサーバーが壊れているのか？」「ネットワーク周りでブロックされていないか？」を切り分けることが重要です。

まず確認すべきポイント（現状調査）

ポータルが不安定なときほど、落ち着いて CLI や REST API で実態を確認することが有効です。最初に見ておきたいチェックポイントをまとめます。

サーバーの provisioningState を CLI で確認

Azure CLI で MySQL フレキシブルサーバーの状態を確認します。

az mysql flexible-server show \
  --resource-group &lt;リソースグループ名&gt; \
  --name &lt;サーバー名&gt; \
  --query "{name:name, state:userVisibleState, provisioningState:properties.provisioningState}"

userVisibleState が Ready なのに、ポータルで「更新中」と表示され続ける場合は、ポータル側の表示不整合である可能性が高いです。
provisioningState が Updating や Failed になっている場合は、裏側の更新が完了していない、もしくはエラーで止まっています。

アクティビティログで直近の操作を確認

次に、Azure ポータルのアクティビティログで、対象の MySQL サーバーに対してどのような操作が走り、どこで失敗しているかを確認します。

対象リソースを MySQL サーバーに絞り込む
直近 24 時間〜72 時間に絞る
ステータス「失敗」や「キャンセル」のイベントを確認する
該当イベントの操作 ID（correlationId）を控えておく（サポート依頼時に有効）

ここでプライベートエンドポイントの作成や削除、VNet 関連の更新に失敗しているログがあれば、ネットワーク周りの詰まりを疑いやすくなります。

プライベートエンドポイント接続状態の確認

プライベートエンドポイントを使っている場合は、サーバー側とネットワーク側の両方で接続状態を確認します。

MySQL サーバーの「プライベートエンドポイント接続」で、状態が承認済みになっているか
「保留」や「拒否」が残っていないか
ネットワーク側のプライベートエンドポイントリソースが、意図したサブネットを参照しているか

問題がこじれている場合、「既に削除したつもり」のプライベートエンドポイントが別リソースグループに残っていたり、接続が「保留」のまま止まっているケースもあります。

サブネットの委任・サービスアソシエーションリンク（SAL）が原因でハマる理由

今回のような「更新中から戻らない」問題でよく犯人になるのが、サブネットに残った委任（delegation）設定や、プライベートエンドポイントが作成するSAL（Service Association Link）です。

サブネット委任（delegation）とは

App Service の VNet 統合を使う場合、VNet 側にVNet 統合用サブネットを用意し、そのサブネットを Microsoft.Web/serverFarms などに委任します。この委任によって、サブネットは特定の PaaS サービス専用のような扱いになり、サブネット側にもいくつかの制約がかかります。

代表的な例として、委任されたサブネットは次のような制約があります。

特定の種類のリソースしか配置できない
サブネットの削除や更新に追加の制約がかかる

SAL（Service Association Link）とは

プライベートエンドポイントを作成すると、対象のサブネットに対して Azure 側でサービスアソシエーションリンク（Service Association Link / SAL）が自動的に生成されます。SAL は、サブネットと PaaS サービスの間の関連付け情報で、これが残っているとサブネットの削除・更新がブロックされることがあります。

本来はプライベートエンドポイントを削除すれば SAL も消えるべきですが、操作の途中で何かトラブルがあった場合などに、サブネットに SAL 情報だけが残ってしまうことがあります。すると次のような問題が起きます。

サブネットを削除しようとしても「使用中」で削除できない
サブネットの更新（アドレス範囲変更など）が完了しない
ひいては MySQL サーバー側のネットワーク関連更新も完了せず、「更新中」に張り付く

サブネット委任 + SAL が絡んだときの典型症状

症状	考えられる原因	対処の方向性
サブネットを削除できない	委任（Microsoft.Web など）が残っている／SAL が残っている	委任を解除し、関連プライベートエンドポイントを削除して SAL を解消
MySQL サーバーが「更新中」のまま	ネットワーク更新がサブネットの制約でブロックされている	サブネット周り（委任・SAL・プライベートエンドポイント）を整理してから再試行
プライベートエンドポイントを作り直しても接続できない	サブネット設計が不適切（統合用と PE 用が混在）／DNS 設定が古い	サブネットを分離し、新しいサブネットで PE を再作成、DNS を更新

このように、サブネットの委任と SAL は一見「MySQL とは関係なさそう」に見えますが、実際には MySQL フレキシブルサーバーの更新処理に大きく影響します。

実際の解決ステップ（推奨手順）

ここからは、実際に「更新中から戻らない」「App Service から接続できない」状況に陥った場合の、具体的な解決手順を整理します。

Step 1: 現状の状態を整理する

まずは、次の 3 点を落ち着いて確認します。

MySQL サーバーの provisioningState / userVisibleState
直近の アクティビティログ（失敗している操作の有無）
プライベートエンドポイント接続の状態

CLI での確認例（再掲）：

az mysql flexible-server show \
  --resource-group &lt;リソースグループ名&gt; \
  --name &lt;サーバー名&gt; \
  --query "{state:userVisibleState, provisioningState:properties.provisioningState}"

アクティビティログでは、MySQL サーバーだけでなくVNet やサブネット、プライベートエンドポイントに対する操作も合わせて確認し、「どのリソースで失敗が続いているのか」を見つけましょう。

Step 2: ネットワークの“つかえ”を解消する

MySQL サーバー側の操作を繰り返す前に、まずは VNet/サブネット側の「詰まり」を解消します。特に、プライベートエンドポイントを作り直したり削除したりしたあとは、サブネットに SAL が残っていないか要注意です。

サブネットの委任を一旦解除する

App Service の VNet 統合用サブネットに委任（Microsoft.Web など）が設定されている場合、問題切り分けのため一時的にこれを解除します。

Azure ポータルで該当 VNet → サブネットを開く
「サブネットの委任」で Microsoft.Web/serverFarms などの委任が設定されているか確認
できる範囲で委任を解除する（影響が大きい場合はメンテナンス時間帯に実施）

委任の解除によって、サブネット上の制約が一時的に緩和され、SAL の削除などが行いやすくなります。

SAL の原因になっているリソースを削除する

SAL 自体はポータルから直接操作できませんが、通常は原因となっているプライベートエンドポイントを削除することで解消されます。次の点を確認します。

該当サブネットを利用しているプライベートエンドポイントが残っていないか
別リソースグループや別サブスクリプションに、古いプライベートエンドポイントが残っていないか

不要なプライベートエンドポイントは削除し、その後サブネットの状態を再チェックします。場合によっては、VNet をエクスポート（テンプレート出力）することで SAL の存在を確認できることもあります。

Step 3: プライベート接続（プライベートエンドポイント + DNS）の再構成

ネットワークの「詰まり」をある程度解消できたら、プライベートエンドポイントと DNS を正しい形で再構成します。

VNet 統合用サブネットとプライベートエンドポイント用サブネットを分離する

設計上のベストプラクティスとして、次のようにサブネットを分けることが推奨されています。

用途	サブネット例	主な設定
App Service の VNet 統合	`subnet-appsvc-integration`	委任: Microsoft.Web/serverFarms、NSG 必要に応じて
プライベートエンドポイント	`subnet-pe-mysql`	プライベートエンドポイント専用、NSG は厳しめに設定可能

サブネットを分離することで、App Service の委任設定とプライベートエンドポイントの SAL が混在せず、トラブル発生時の切り分けもしやすくなります。

プライベートエンドポイントの作り直し

プライベートエンドポイントを再作成する際は、次の点を必ず確認します。

対象リソースに、移動後の MySQL フレキシブルサーバー（新しいリソース ID）を指定しているか
サブネットに、プライベートエンドポイント用に用意した専用サブネットを指定しているか
DNS を自動構成させる場合、紐づくプライベート DNS ゾーンの設定が正しいか

MySQL フレキシブルサーバーの場合、プライベート DNS ゾーンは通常 privatelink.mysql.database.azure.com を利用します。ゾーン内の A レコードが、新しいプライベートエンドポイントの IP アドレスを向いていることを確認してください。

プライベート DNS ゾーンと VNet リンクをチェック

DNS 周りでよくある問題は次の通りです。

旧サブスクリプション側の VNet にだけプライベート DNS ゾーンがリンクされたまま
ゾーンは存在するが、新しい VNet へリンクされていない
A レコードが古いプライベート IP を指したまま更新されていない

ポータルの「プライベート DNS ゾーン」から、

リンクされている VNet の一覧
MySQL サーバーの FQDN に対応する A レコード

を確認し、App Service が統合されている VNet にもリンクされていること、新しいプライベートエンドポイントの IP アドレスに更新されていることを確実にします。

Step 4: App Service 側の設定と疎通確認

プライベートエンドポイントと DNS を再構成したら、App Service 側の設定と疎通を確認します。

VNet 統合と接続先 VNet/サブネットを確認

App Service の「ネットワーク」→「VNet 統合」で、統合先の VNet/サブネットが想定通りか確認
サブスクリプション移動後、同名の VNet を再作成している場合は、意図しない VNet に統合されていないか慎重にチェック

サブスクリプションを跨いで VNet 統合している場合、サブスクリプション移動の影響で VNet のリソース ID が変わり、統合設定だけが古い ID を参照し続けることもあるため注意します。

接続文字列の整合性をチェック

ホスト名（FQDN）：MySQL フレキシブルサーバーの FQDN を指定しているか
ポート：3306 を指定しているか
TLS 設定：フレキシブルサーバー側の TLS 要件に沿っているか
サーバー名変更やサーバー再作成をしていないか

サーバー移動や再構成の過程で、接続文字列を一部だけ修正し、古いサーバー名やホスト名が残っているケースも非常に多いです。

App Service コンソールからの疎通確認

App Service の Kudu コンソール（「高度なツール」→「Kudu」）を開き、「Debug console」から PowerShell または Bash を開いて疎通確認します。

nslookup &lt;mysql-server-name&gt;.privatelink.mysql.database.azure.com
tcpping &lt;mysql-server-fqdn&gt; 3306

nslookup の結果がプライベート IPになっているか
tcpping で 3306 ポートに対して応答があるか

ここで名前解決がパブリック IP を返している場合は、プライベート DNS ゾーンの構成に問題があります。また tcpping が失敗する場合は、NSG や UDR（ユーザー定義ルート）も含めて経路を確認する必要があります。

Step 5: それでも「更新中」から戻らない場合の対応

ここまでの手順を行っても MySQL サーバーの状態が改善しない場合は、Azure 側の制御プレーンで何らかのエラーが継続している可能性があります。その場合は、次の情報を整理したうえで Azure サポートに問い合わせるのが現実的です。

MySQL サーバーのリソース ID
アクティビティログで失敗している操作の操作 ID（correlationId）
問題が発生した日時と、行った操作の概要（サブスクリプション移動、プライベートエンドポイントの再作成など）
CLI で取得した userVisibleState と provisioningState の値

これらを添えて問い合わせることで、バックエンド側の状態を踏まえた調査・復旧を依頼しやすくなります。

原因別のチェックリストと対応表

ここで、よくある原因とその対処方法を一覧表にまとめます。トラブルシューティング時の「道しるべ」として活用してください。

現象	主な原因	確認ポイント	主な対処
サブスクリプション移動後に App Service から接続できない	プライベートエンドポイントとプライベート DNS ゾーンが、旧構成のまま	PE の対象リソース ID、DNS ゾーンの VNet リンク、A レコードの IP	新しいサブスクリプションのリソースに合わせて PE・DNS を再作成／更新
サーバーが「更新中」のまま長時間変わらない	サブネットの委任や SAL が原因でネットワーク更新がブロック	サブネットの委任設定、不要なプライベートエンドポイントの有無	委任解除 → PE 削除 → SAL 解消 → 再構成
サブネットが削除できない	委任または SAL が残っている	委任の有無、PE の存在、テンプレート出力で SAL の有無を確認	委任を外し、原因となる PE や関連リソースを削除したうえで再試行
DNS がパブリック IP を返す	プライベート DNS ゾーンが VNet にリンクされていない／レコード未更新	プライベート DNS ゾーンの VNet リンク、A レコードの IP	正しい VNet へリンクし、A レコードを最新のプライベート IP に更新
プライベートエンドポイントを作り直しても疎通できない	App Service の VNet 統合サブネットと PE サブネットの混在、NSG/UDR の誤設定	サブネット設計、NSG ルール、UDR の経路	サブネット分離、NSG/UDR の見直し、設計の整理

DNS（プライベート DNS ゾーン）に関する注意点

プライベートエンドポイントを利用して MySQL フレキシブルサーバーへ接続する場合、DNS の設定は非常に重要です。いくらネットワーク的に正しいプライベートエンドポイントができていても、名前解決がパブリック側を向いていれば接続は失敗してしまいます。

基本となる構成

プライベート DNS ゾーン：privatelink.mysql.database.azure.com
VNet とのリンク：App Service が統合されている VNet を含め、プライベート接続を行う VNet すべて
A レコード：MySQL サーバーの FQDN → プライベートエンドポイントの IP

サブスクリプション移動を行った場合、この DNS 構成が旧サブスクリプション側に残ったままになることがあります。新サブスクリプション側に新しいプライベート DNS ゾーンを作り直すか、既存ゾーンを新しい VNet にリンクし直す必要があります。

名前解決の確認手順

App Service のコンソールや VM などから、次のコマンドで名前解決を確認します。

nslookup &lt;mysql-server-name&gt;.privatelink.mysql.database.azure.com

返ってくる IP アドレスがプライベートエンドポイントの IPになっているか
もしパブリック IP や別の IP が返ってきていれば、DNS 構成の見直しが必要

オンプレミス環境やカスタム DNS サーバーと連携している場合は、フォワーダー設定や split-horizon DNS の構成も合わせて確認してください。

App Service からの疎通確認とログの取り方

App Service 側では、接続が失敗しているとアプリケーションログに「接続タイムアウト」「ホスト名解決に失敗」などのメッセージが出ますが、それだけでは原因を特定しづらいことも多いです。Kudu コンソールを活用した簡易テストを組み合わせると、問題の切り分けが進めやすくなります。

Kudu コンソールでのネットワークテスト

App Service →「高度なツール」→「移動」→ Kudu を開く
「Debug console」→「PowerShell」または「Bash」を選択
次のようなコマンドを実行

nslookup &lt;mysql-server-fqdn&gt;
tcpping &lt;mysql-server-fqdn&gt; 3306

nslookup がプライベート IP を返し、tcpping も成功するなら、ネットワークレベルでは到達可能
この状態で接続できない場合は、接続文字列や認証情報、TLS 設定などアプリ側の問題が疑われます
nslookup は通るが tcpping が失敗する場合、NSG や UDR、Firewall ルールなど経路レベルの問題が濃厚です

アプリケーションログと組み合わせた分析

ネットワークテストと合わせて、App Service のアプリケーションログや診断ログも確認します。

接続タイムアウト系のエラー：ネットワークか Firewall、NSG を疑う
ホスト名解決失敗：DNS の問題を最優先で確認
認証エラー：ID/パスワード、TLS/SSL 設定、ユーザー権限の問題を確認

これにより、「そもそも MySQL に届いていないのか」「届いているが認証で弾かれているのか」の切り分けがはっきりします。

再発防止のためのネットワーク設計と運用ポイント

今回のようなトラブルをきっかけに、ネットワーク設計や運用フローを見直しておくと、今後のトラブルシューティングが格段に楽になります。

ネットワーク設計の分離と役割の明確化

VNet 内のサブネットは役割ごとに分け、プライベートエンドポイント用サブネットと App Service VNet 統合用サブネットは必ず分離しましょう。

サブネット種別	主な役割	ポイント
アプリケーション層（App Service 統合）	App Service から内部リソースへアクセス	Microsoft.Web への委任、ルートや NSG はアプリ用に最適化
データベース用プライベートエンドポイント	MySQL、SQL Database、Cosmos などの PaaS DB 接続	プライベートエンドポイント専用。NSG で到達元を限定しやすい
ゲートウェイ／ハイブリッド接続	VPN ゲートウェイ、ExpressRoute ゲートウェイとの接続	オンプレミスとの経路を意識し、UDR の影響も考慮

依存関係の可視化とドキュメント化

サブスクリプション移動や大きな構成変更を行う前に、次のような依存関係を図に落としておくと安全です。

MySQL フレキシブルサーバーとプライベートエンドポイントの関係
プライベートエンドポイントとサブネット／VNet の関係
プライベート DNS ゾーンと VNet リンクの対応表
App Service の VNet 統合先サブネット・VNet

図や表があれば、サブスクリプション移動時に「どの順番で何を作り直すべきか」「どのリソースがどこに依存しているか」を関係者間で共有しやすくなります。

変更前後のチェックリスト運用

サブスクリプション移動や大きなネットワーク変更の前後で、チェックリストを運用するのも有効です。例として、次のような項目をリスト化しておきます。

項目	チェック内容
DNS	プライベート DNS ゾーンの VNet リンク、A レコードの IP（新しい PE IP になっているか）
プライベートエンドポイント	対象リソース ID、サブネット、接続状態（承認済み）
サブネットの委任	App Service 用サブネットにのみ Microsoft.Web を委任しているか
NSG・UDR	App Service → MySQL への経路をブロックしていないか
名前解決テスト	App Service コンソールから nslookup でプライベート IP を引けるか
到達性テスト	tcpping や簡易ツールで 3306 ポートへの疎通確認

このチェックリストを、運用手順書や変更管理プロセスに組み込んでおくことで、「なんとなく構成をいじる」ことによるトラブルを大幅に減らせます。

サブスクリプション移動時に意識したいポイント

最後に、Azure Database for MySQL フレキシブルサーバーを含む構成をサブスクリプション間で移動する際に、特に意識しておきたいポイントを整理します。

サブスクリプション移動の対象に含まれるリソースと含まれないリソース（VNet、プライベート DNS ゾーンなど）を事前に洗い出す
移動後、リソース ID が変わることで影響を受けるリソース（プライベートエンドポイント、連携サービスなど）をリストアップしておく
移動前後で、テスト用の App Service や VMから疎通確認を行い、問題を早期に検知する
可能であれば IaC（Bicep、ARM テンプレート、Terraform など）で構成をコード化し、移動後に再デプロイできるようにする

これらを意識することで、「移動してみたら繋がらなくなった」「よくわからないが更新中から戻らない」といった事態を避けやすくなります。

まとめ：更新中表示に惑わされず、ネットワーク依存関係から疑う

Azure Database for MySQL フレキシブルサーバーが「更新中（Updating）」から戻らないとき、つい「MySQL サービス自体が壊れた」と考えがちですが、実際にはポータルの一時的な不具合や、サブネットの委任や SAL、プライベートエンドポイントと DNS の不整合が原因であることが少なくありません。

この記事で紹介したように、

CLI/アクティビティログで実際の状態を確認する
サブネットの委任を一旦解除し、不要なプライベートエンドポイントや SAL を整理する
プライベートエンドポイントと DNS を設計どおりに再構成する
App Service から nslookup / tcpping で疎通確認する

というステップを踏むことで、多くのケースは自力で解消できます。それでも解決しない場合は、リソース ID と操作 ID を添えて Azure サポートに相談することで、制御プレーン側の状態も含めて調査してもらえます。

「更新中で固まっているように見えるときほど、ネットワーク依存関係を疑う」ことを意識し、サブネットの委任・SAL・プライベート DNS ゾーン・プライベートエンドポイントの関係を整理しておくことで、同種のトラブルを最小限に抑えることができるはずです。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。