【予言】止めたAzure Database for MySQLへの課金は、30日後に復活する：Tech TIPS

Azure Database for MySQLを停止してから30日後、止めたはずのサーバが自動的に再起動し、課金も再開されてしまうことはご存じだろうか？　サーバ停止と料金の関係、およびサーバの起動／停止を制御するためのコマンドを説明する。

» 2024年10月30日 05時00分公開

[島田広道，デジタルアドバンテージ]

連載目次

対象：Azure Database for MySQL（フレキシブルサーバ）、Azure CLI、Azure PowerShell

　サーバ統合によって役目を終えた「Azure Database for MySQL」（以下、「Azure MySQLサーバ」）のインスタンスを停止したまま1カ月以上放置していたら、いつの間にか減ったはずのAzure課金が元に戻っていた……。このような経験をしたのは筆者だけだろうか？

　本Tech TIPSでは、こうしたAzure MySQLサーバの停止と課金に関する重要な特性について説明する。

　Azure MySQLサーバの対象は、特記しない限り「フレキシブルサーバ」とする（廃止が決まっている「単一サーバ」は対象外）。

Azure MySQLサーバは停止すると料金を節約できる

　デプロイしたAzure MySQLサーバを停止すると、コンピュータリソースへの課金が止まる。つまり、MySQLサーバを実行しているプラットフォーム（Linuxの仮想マシン）部分の料金がゼロになる。

　一方、デプロイしたサーバが占有しているストレージ（バックアップも含む）や予約しているIOPS（入出力の性能）については、停止していても料金はかかったままになる。

　それでも、データ量や予約IOPSがよほど大きくない限り、一般的にはコンピュータリソースの料金は全料金の大半を占めることが多い。そのため、不要なときにはAzure MySQLサーバを停止することで、大幅に料金を節約できることも多いはずだ。

停止したAzure MySQLサーバは30日後に自動で起動する！

　しかし油断してはいけない。Azure MySQLサーバを停止してから1回も起動することなく30日を過ぎると、そのサーバは自動的に起動する（フレキシブルサーバの場合。単一サーバだと7日後）。当然、コンピュータリソースへの課金も再開されてしまう。これはAzureの仕様であり、起動そのものを止めることはできない。

Azure MySQLサーバのコスト分析グラフの例
とあるサブスクリプションで実際に利用しているAzure MySQLサーバ（複数）の日々の料金増減をグラフ化したもの。4月10日に対象サーバを手動停止した後、料金は減少した。しかし、放置していたら5月10日に対象サーバが自動起動し、料金は増えて元の水準に戻ってしまった。

　となれば、サーバを管理／運用している側で、何とかして課金再開を防ぐ必要がある。

【CLI】Azure MySQLサーバが起動済みかどうかコマンドで確認するには

　ここからは、課金再開を防ぐために、Azure MySQLサーバの起動／停止を自動的に処理するのに便利なコマンドを紹介していく（実行前には、Azureへのログインとテナント／サブスクリプションの選択を済ませておく必要がある）。

　Azure MySQLサーバが起動済みかどうかを確認するには、以下のAzure CLIのコマンドラインを実行すればよい。

az mysql flexible-server show -g ＜Azure MySQLサーバのリソースグループ名＞ -n ＜Azure MySQLサーバ名＞ --query "state"

【CLI】Azure MySQLサーバが起動済みかどうかを確認する
※Microsoftのリファレンス： az mysql flexible-server show

　上記コマンドの実行結果が「"Ready"」であれば、対象のサーバは既に起動している。それ以外であれば、停止しているか起動の途中と判断できる。

　対象のサーバが削除済みか、リソース名／リソースグループ名／サブスクリプションを間違えて指定した場合は、「(ResourceNotFound)～」というエラーメッセージが返される。

【CLI】Azure MySQLサーバをコマンドで停止したり起動したりするには

az mysql flexible-server stop -g ＜Azure MySQLサーバのリソースグループ名＞ -n ＜Azure MySQLサーバ名＞

【CLI】Azure MySQLサーバを停止する
※Microsoftのリファレンス： az mysql flexible-server stop

az mysql flexible-server start -g ＜Azure MySQLサーバのリソースグループ名＞ -n ＜Azure MySQLサーバ名＞

【CLI】Azure MySQLサーバを起動する
※Microsoftのリファレンス： az mysql flexible-server start

　startサブコマンドでサーバを起動する場合、「--no-wait」オプションを付けると、サーバの起動を待つことなく、即座にコマンドが終了する。

【PowerShell】Azure MySQLサーバが起動済みかどうかコマンドレットで確認するには

(Get-AzMySqlFlexibleServer -ResourceGroupName ＜Azure MySQLサーバのリソースグループ名＞ -Name ＜Azure MySQLサーバ名＞).State

【PowerShell】Azure MySQLサーバが起動済みかどうかを確認する
※Microsoftのリファレンス： Get-AzMySqlFlexibleServer

　上記コマンドの実行結果が「Ready」であれば、対象のサーバは既に起動している。それ以外であれば、停止しているか起動の途中と判断できる。

　対象のサーバが削除済みか、リソース名／リソースグループ名／サブスクリプションを間違えて指定した場合は、「The Resource ～ was not found.」というエラーメッセージが返される。

【PowerShell】Azure MySQLサーバをコマンドレットで停止したり起動したりするには

Stop-AzMySqlFlexibleServer -ResourceGroupName ＜Azure MySQLサーバのリソースグループ名＞ -Name ＜Azure MySQLサーバ名＞

【PowerShell】Azure MySQLサーバを停止する
※Microsoftのリファレンス： Stop-AzMySqlFlexibleServer

Start-AzMySqlFlexibleServer -ResourceGroupName ＜Azure MySQLサーバのリソースグループ名＞ -Name ＜Azure MySQLサーバ名＞

【PowerShell】Azure MySQLサーバを起動する
※Microsoftのリファレンス： Start-AzMySqlFlexibleServer

　Start-AzMySqlFlexibleServerコマンドレットでサーバを起動する場合、「-NoWait」オプションを付けると、サーバの起動を待つことなく、即座にコマンドレットが終了する。

自動起動によってAzure MySQLサーバへの課金が再開されるのを防ぐには

　前述のコマンド／コマンドレットを使ってAzure MySQLサーバの起動／停止をするスクリプトを用意し、定期的に実行するタスクを組めば、サーバの自動的な起動／停止を実現できる。その上で、どのようにしたらAzure MySQLサーバの料金を抑えつつ、自動起動による課金再開を防げるか、考えてみよう。

●サーバは「停止」より「削除」がお得だが再開には手間と時間がかかる

　停止したAzure MySQLのサーバをすぐ利用する予定がなく、また利用を再開するときには多少時間がかかってもよいなら、そのサーバを削除するのが最も料金の節約になる。コンピュータリソースだけではなく、ストレージや追加IOPSの料金も省けるからだ。

　ただし、利用を再開するのに手間はかかる。まずサーバをプロイし直さなければならない。AzureポータルのGUIだと設定を間違えやすいので、ARM（Azure Resource Manager）のテンプレートからデプロイするのが現実的だろう。その手順については、Tech TIPS「Azure Database for MySQLをARMテンプレートからデプロイする手順とコツ」を参照していただきたい。

　サーバをデプロイしたら、最低限、アカウント（ユーザー）の作成とバックアップからのデータベース復元をしなければならない。ここで注意したいのは、サーバを削除した場合、Azure MySQLの標準機能である自動バックアップからは復元できないことだ。自動バックアップによって保存されたバックアップデータは、サーバとともに削除されてしまう。そのため、バックアップは（Azureの機能ではなく）mysqldumpコマンドのようなMySQLの機能で取得しておく必要がある（Azure MySQLの「今すぐエクスポート」というプレビュー中の機能が一般的に使えるようになれば、この状況は変わるかもしれない）。

　また、この方法だと利用再開までの時間もかかる。サーバのデプロイには通常、数分から十数分の時間が必要だ（ファイアウォールルールが多いほど、分単位でデプロイ時間は延びていく）。バックアップからのデータベース復元については、当然ながらデータ容量が大きいほど、そしてサーバの性能が低いほど時間がかかる。復元完了までに数十分かかることも珍しくないだろう。

●バックアップのサーバなら30日より短い頻度で定期的に更新する手もあり

　バックアップ用のMySQLサーバであれば、定期的な更新時のみ起動して、更新が完了したら次回更新まで停止させておくことで、コンピュータリソースの料金を節約できる。更新頻度を30日以内にしておけば、意図しない自動起動が生じることもない。

　この方法でどれくらい料金を節約できるかは、更新頻度や更新にかかる時間などに左右される。例えば1日1回の更新に1時間かかるなら、残りの23時間弱は停止できるので、コンピュータリソースの料金は無停止時（フル稼働状態）のおおよそ1/24＝4.2％にまで減らせることになる。しかも前述のサーバ削除と比べると、メインサーバの代わりに使おうとした時にサーバ起動まで数分待てば利用可能になる。

　その一方で、更新に時間がかかるする場合は、停止時間があまり長く取れず、料金削減の効果は下がることになる。

■関連リンク