はじめに
Azureの仮想マシン構築について、気づいたことや引っかかったことを、AWSとの違いを踏まえつつ、まとめます。
ひとつ前の記事 の続きです。
気づいたこと
SQL Server
Azure VMの SQL Server については、2点ありました。
- SQL Server日本語版を再インストールする必要がある。
- SQL Serverインスタンスは、デフォルトで1TB x 3のディスクが追加される。
SQL Server日本語版を再インストールする必要がある
Azure VMのイメージとしては、SQL Serverの日本語版は用意されていません。
手作業で、SQL Serverをアンインストールし、日本語版SQL ServerのISOイメージをダウンロードし、インストールする必要があります。
（参考）
・Azure 仮想マシン上に作成した SQL Server の日本語化手順（Windows OS 版 SQL Server 2019 / 2022 対応手順）
・SQL込みVMのSQL日本語化について
https://cloudsteady.jp/blog/2021/05/31/39798/
SQL Server のインストールについては、インスタンス名など、インストール時に指定し、あとから変更できない設定もあり、ややハードルが高いように感じました。
SQL Serverインスタンスは、デフォルトで1TB x 3のディスクが追加される
VMを作成し、SQL Server を日本語化した後で、エクスプローラーを眺めていて気づいたのですが、1TBのF,G,Hの3ドライブが存在しました。
実は、VMの作成時にイメージとして SQL Server を指定した場合、「SQL Serverの設定」という設定タブがあり、その中の「ストレージの構成」で、1024GiBの以下のディスクドライブが指定されています。
- F:\data（SQLデータ）
- G:\log（SQLログ）
- H:\tempDb（tempdb）
ディスク負荷分散によりパフォーマンスを向上させるため、用途ごとにディスクを別にするということですね。
ディスクサイズは変更できますが、なし（デフォルトのCドライブを指定するなど）はできないようです。
必要なパフォーマンスと、ディスク料金の兼ね合いで、追加ディスクを使用するかどうかや、ディスクサイズを決めるとよいでしょう。
今回は、日本語版SQL Serverのインストールの際に、SQLデータ・ログ、tempdb のドライブを、デフォルトのままのCドライブと指定しました。
F,G,Hドライブは使用しないため、AzureポータルでディスクをVMからデタッチし、削除しました。
1TiBディスク(Premium SSD)の料金は、2025年4月下旬の時点で$155 とけっこうな金額ですので、「実際には使用しないのに接続している」という状態は避けたいところです。
VMのバックアップからのリストア
Azure VMのバックアップとしては、AWS Backup のような、Azure Backup という機能でスケジュール等、柔軟に設定できます。
ただし、バックアップからのリストアについては、4点、気になることがありました。
- 一時保存用ストレージアカウントの作成が必要
- ストレージアカウントのネットワーク設定
- ストレージアカウントにVHDファイルが残る
- リストアに要する時間は不定
一時保存用ストレージアカウントの作成が必要
バックアップからリストアする際に使用する「ストレージアカウント」の作成が必要となります。
これはAWSにはないしくみで、正直なところ、そんなのはクラウドサービスの裏側でうまくやってくれよ、と思います。
「ストレージアカウント」自体は、AWSでいえば、S3バケットに相当するストレージ機能と理解しました。
（参考）
・Azure VM Backup でリストアする際に利用するステージングの場所として利用するストレージ アカウントについて – Japan CSS ABRS Support Blog !!
https://jpabrs-scem.github.io/blog/AzureVMBackup/RestoreStagingStorageAccount/
ストレージアカウントのネットワーク設定
ストレージアカウントを作成する際のネットワーク設定で、
「ネットワーク アクセス」という設定項目があり、「すべてのネットワークからのパブリックアクセスを有効にする」か、「プライベート」かを選択できます。
VHDファイルが残る、とのことで、第三者からアクセスされると考えると怖いので、ここの設定は悩みましたが、「匿名アクセス」設定を無効（デフォルト）にしつつ、「パブリックアクセス有効」としました。
これは、Azure Storage の仕様で、
「匿名アクセスを明示的に有効にしない限り、アクセスには承認が必要となる＝第三者からのアクセスは不可」
ということがわかったからです。
（参考）
・コンテナーと BLOB 用の匿名読み取りアクセスを構成する
https://learn.microsoft.com/ja-jp/azure/storage/blobs/anonymous-read-access-configure
Amazon S3の「ブロックパブリックアクセス有効」と同じようなものですね。
実際に、リストア後に生成されたVHDファイルのエンドポイントURLに対して外部からアクセスを試みたところ、409エラーとなりました。
$ wget https://xxx.blob.core.windows.net/xxx/xxx.vhd -- HTTP による接続要求を送信しました、応答を待っています... 409 Public access is not permitted on this storage account. 2025-03-10 03:29:05 エラー 409: Public access is not permitted on this storage account.。 --
もちろん、ストレージアカウントの「プライベート」とするとセキュリティ的に、より強固となります。
その場合は、プライベートエンドポイントの作成が必要となり、Private Linkの料金（時間課金＋送受信転送量課金）がかかります。
ストレージアカウントにVHDファイルが残る
リストアの際、短期間の保持となるスナップショットからの復元でない限り、VHDファイルが残ります。
VHDファイルのサイズは、VMのディスクサイズと同じで、残しておくとディスクサイズ分の課金が発生しますので、Azureの推奨どおり、リストアが完了したのち、手作業で削除する必要があります。
削除を忘れることもありますので、ストレージアカウントのライフサイクル設定で、一定期間経過したオブジェクトは削除するよう設定するとよいでしょう。
Amazon S3のライフサイクルルール設定と同じような機能です。
リストアに要する時間は不定
以下によると、
「Azure VM Backup におけるバックアップやリストアの時間を見積もることは出来ません。」
とのことです。
（参考）
・Azure Backup の バックアップ / リストア 所要時間について – Microsoft Japan CSS ABRS Support Blog !!
https://jpabrs-scem.github.io/blog/AzureBackupGeneral/Backup_RecoveryTIme/
僕が試したときは、ディスク128GBのリストアで、「インスタント リストアではない（＝スナップショットからの復旧ではないため時間がかかる）」場合で20分ぐらいでした。
おわりに
Azure仮想マシン構築で気づいたこと、引っかかったことについて、AWSとの違いを交えつつまとめました。
利用ユーザーのインターネット上での記事も以前よりはずいぶん増えたようですが、VMを1台作成するだけでも、本番運用のためには、バックアップ・リストアやセキュリティなど、いろいろ考慮することがありました。
今回は、30日間使用できる $200 のクレジットを使用して事前調査したことで、実環境の構築は比較的スムーズに進みました。
AWSも同様だと思いますが、初めて使用するサービスは、事前に十分な余裕をもって調査するとよいでしょう。