1. はじめに

業務でAzure上のWindows Server構築に関わった際、最初に迷ったのが「このサーバには、どのVMサイズを選べばよいのか」という点でした。

Azure PortalからVMを作る操作自体は、それほど難しくありません。しかし、実際のインフラ構築では、VMを作成できれば完了というわけではありません。

「このサーバは何のために使うのか」「どれくらいの処理が発生するのか」「障害が起きたときにどう復旧するのか」といったことを考えながら、VMサイズ、ネットワーク、ディスク、監視、バックアップなどを決める必要があります。

この記事では、業務システムでよく使われる以下のWindows Serverを例に、VMサイズの考え方や構築時に気を付けたい点を、インフラ担当者の目線で整理します。

IF（インターフェース）サーバ
Webサーバ
AP（アプリケーション）サーバ
DBサーバ

記事内のVMサイズは、あくまで検討を始めるための一例です。実際には、利用するリージョン、製品要件、処理件数、性能試験の結果、予算などを基に決定します。

2. 今回想定するシステム構成

今回は、Webサーバ、APサーバ、DBサーバからなる一般的な3層構成に、外部システムとのデータ連携を担当するIFサーバを加えた構成を想定します。

それぞれの役割を簡単にまとめると、以下のようになります。

サーバ種別	主な役割
IFサーバ	外部システムとのファイル連携、API連携、データ変換、ジョブ実行
Webサーバ	利用者からのHTTP／HTTPS通信の受付、画面や静的ファイルの配信
APサーバ	業務ロジック、API、バッチ処理の実行
DBサーバ	業務データの保存、検索、更新、トランザクション管理

同じWindows Serverであっても、担当する役割によって必要なCPU、メモリ、ディスク性能は変わります。そのため、すべてのサーバに同じVMサイズを当てはめるのではなく、それぞれの処理内容から考えることが大切です。

3. Azure VMサイズをどう考えるか

AzureのVMサイズには多くの種類があります。初めて一覧を見ると選択肢の多さに戸惑いますが、まずはシリーズごとの特徴を把握すると考えやすくなります。

シリーズ	特徴	向いている用途
Bシリーズ	CPU負荷が低い間にクレジットを貯め、必要なときに性能を上げる	開発・検証環境、常時負荷が低い小規模サーバ
Dシリーズ	CPUとメモリのバランスがよい	IF、Web、APなど一般的な業務サーバ
Fシリーズ	メモリ量に対してCPU性能が高い	CPU処理が多いWeb、AP、バッチサーバ
Eシリーズ	vCPU当たりのメモリ量が多い	SQL ServerなどのDB、メモリを多く使う処理

たとえば、Standard_D4s_v5はDシリーズの4 vCPU、Premium SSD対応、第5世代のVMサイズです。

実際にサイズを決めるときは、最初から完璧な答えを出そうとするよりも、用途に合ったサイズを初期候補として選び、検証環境や性能試験でCPU、メモリ、ディスクI/Oなどを確認して調整する方が現実的だと感じました。

Bシリーズはコストを抑えやすい一方、CPUクレジットを使い切ると性能が制限されます。処理時間が重要な本番サーバでは、安さだけで選ばず、継続的なCPU負荷が発生しないか確認する必要があります。

4. サーバごとのVMサイズと構築時の注意点

4.1 IFサーバ

IFサーバは、外部システムと業務システムの間でデータを受け渡すためのサーバです。

たとえば、SFTPで受信したファイルを決められたフォルダーに配置したり、文字コードやファイル形式を変換したり、決められた時刻に連携ジョブを実行したりします。

一見すると負荷が低そうに見えますが、複数のジョブが同じ時間帯に動くと、CPU、ディスク、ネットワークの負荷が一気に上がることがあります。そのため、普段のCPU使用率だけではなく、ピーク時間帯の処理状況を見ることが重要です。

VMサイズの初期候補としては、次のような構成が考えられます。

想定規模	VMサイズ例	vCPU／メモリ	利用イメージ
小規模	`Standard_D2s_v5`	2 vCPU／8 GiB	少数の連携ジョブ、低頻度のファイル転送
中規模	`Standard_D4s_v5`	4 vCPU／16 GiB	複数ジョブの並列実行、データ変換処理

IFサーバを構築するときは、特に次の点を確認します。

連携先のIPアドレス、ポート、通信方向
ファイル名、文字コード、改行コード、圧縮・暗号化方式
同じファイルを二重に送信・取込しない仕組み
処理中、正常終了、異常終了ファイルを分けるフォルダー構成
エラー発生時のリトライ回数、タイムアウト、再送方法
タスクスケジューラやジョブ管理製品の実行ユーザー
連携ファイルやログの保存期間と削除方法

IFサーバでは、「ファイルを送れたか」だけでなく、「途中で失敗した場合に、どこから安全に再実行できるか」まで決めておくことが大切です。

また、ウイルス対策ソフトが連携ファイルをスキャンしたことで、一時的にファイルがロックされる可能性もあります。連携処理が不安定な場合は、アプリケーションだけでなく、ウイルス対策ソフトやWindowsイベントログも確認対象になります。

4.2 Webサーバ

Webサーバは、利用者からのHTTP／HTTPS通信を最初に受け付けるサーバです。Windows Serverでは、IISを使用する構成がよくあります。

小～中規模のシステムであれば、まずはDシリーズから検討しやすいです。CPU処理が多く、メモリ使用量が少ないことが分かっている場合は、Fシリーズも候補になります。

想定規模・特性	VMサイズ例	vCPU／メモリ
小～中規模	`Standard_D2s_v5`	2 vCPU／8 GiB
中規模	`Standard_D4s_v5`	4 vCPU／16 GiB
CPU負荷が高い	`Standard_F4s_v2`	4 vCPU／8 GiB

Webサーバは外部からの通信を受けるため、性能だけでなくセキュリティ面の設計が重要です。

VMへ直接インターネット通信を到達させるのではなく、必要に応じてApplication GatewayやLoad Balancerを前段に配置します。また、NSG（ネットワークセキュリティグループ）では、必要な通信元とポートだけを許可します。

構築時には、IISのアプリケーションプール、実行ユーザー、ログの出力先も確認します。ログをOSディスクへ出し続けると、気付かないうちに空き容量が少なくなることがあるため、ログローテーションと容量監視も必要です。

HTTPSを使用する場合は、証明書を登録して終わりではありません。証明書の有効期限を誰が確認し、どのような手順で更新するかまで運用として決めておく必要があります。

4.3 APサーバ

APサーバでは、業務ロジック、API、バッチなどを実行します。

APサーバの難しいところは、アプリケーションの作りによって負荷の傾向が大きく変わることです。CPUを多く使用する処理もあれば、メモリ上へ大量のデータを展開する処理もあります。

そのため、次のように処理特性から候補を分けると考えやすくなります。

処理特性	VMサイズ例	vCPU／メモリ
一般的な業務処理	`Standard_D4s_v5`	4 vCPU／16 GiB
CPU負荷の高い処理	`Standard_F4s_v2`	4 vCPU／8 GiB
メモリ使用量が多い処理	`Standard_E4s_v5`	4 vCPU／32 GiB

構築前には、OSだけでなく、.NET、Java、各種ミドルウェアの対応バージョンも確認します。Windows Serverのバージョンを上げた結果、古いアプリケーションやミドルウェアが動作しないということも考えられます。

また、サービスやタスクの実行ユーザーには必要最小限の権限を設定します。動作しないからといって安易にAdministrator権限を付けると、後から見直すのが難しくなります。

APサーバでは、CPUとメモリに加えて、処理件数、応答時間、バッチの所要時間を記録しておくと、VMサイズを見直す際の判断材料になります。

4.4 DBサーバ

DBサーバは業務データを保持するため、ほかのサーバよりも慎重に設計する必要があります。

SQL ServerをWindows Server VM上に構築する場合、CPUやメモリだけでなく、ディスクのIOPS、スループット、遅延が性能へ大きく影響します。

想定規模	VMサイズ例	vCPU／メモリ
小規模・検証用途	`Standard_D4s_v5`	4 vCPU／16 GiB
中規模	`Standard_E4s_v5`	4 vCPU／32 GiB
中～大規模	`Standard_E8s_v5`	8 vCPU／64 GiB

DBはキャッシュとしてメモリを多く利用するため、一般的にはEシリーズが候補になります。ただし、データ量が少ない検証環境まで本番と同じサイズにすると費用が大きくなるため、環境ごとに目的を整理してサイズを決めます。

ディスクについては、OS、データ、トランザクションログ、tempdb、バックアップの配置を分けて考えます。すべてを1本のディスクへ置くと、障害調査や性能分析が難しくなるためです。

さらに、次の点も確認します。

Windows Server、SQL Server、業務製品のサポート組み合わせ
SQL Serverのエディションとライセンス費用
SQL Serverの最大メモリ設定とOS用メモリの確保
バックアップの保存先、保存期間、暗号化
バックアップから実際に復元できるかを確認するリストア試験
可用性ゾーンやAlways On可用性グループなどの冗長化方式
DBへ接続できるサーバと管理者の制限

Azure VMの一時ディスクは、ホスト移動や再デプロイなどによってデータが失われる可能性があります。DBファイル、連携ファイル、バックアップなど、消失してはいけないデータは保存しないようにします。

5. どのサーバでも共通して確認したいこと

5.1 OSとネットワーク

Windows Serverのバージョンを決める際は、OS単体のサポート期限だけでなく、導入するアプリケーションやミドルウェアが対応しているかも確認します。

ネットワークについては、Web、AP、DB、運用管理などの役割でサブネットを分け、NSGで必要な通信だけを許可します。

特にRDPの3389番ポートをインターネットへ常時公開する構成は避け、Azure Bastion、VPN、閉域接続、Just-In-Timeアクセスなどを検討します。

5.2 ディスク

Azureのディスクは、容量だけを見て選ばないことがポイントです。同じ容量でも、ディスクの種類によってIOPSやスループットが異なります。

設計書には、ディスクサイズに加えて、用途、ドライブ文字、ボリュームラベル、ファイルシステム、必要な性能を記載しておくと、構築時の設定間違いを減らせます。

5.3 セキュリティ

ローカルAdministratorを日常的に使用せず、誰が操作したか分かる管理アカウントを使用します。Azure側のRBACも、担当者の役割に応じた必要最小限の権限にします。

また、パスワード、接続文字列、証明書などを手順書へ平文で記載しないようにします。必要に応じてAzure Key Vaultなどを利用し、秘密情報と通常の設定値を分けて管理します。

Windows Updateについても、単に「定期的に適用する」だけでは不十分です。適用日、事前確認、再起動の調整、動作確認、問題が起きた場合の切り戻し方法まで決めます。

5.4 監視、バックアップ、可用性

VMを構築した直後は正常に動いていても、運用開始後にCPU負荷やディスク使用量が増えることがあります。

Azure MonitorやLog Analyticsを利用し、CPU、メモリ、ディスク、ネットワーク、Windowsイベントログを確認できるようにします。アラートは多ければよいわけではなく、通知を受けた担当者が何を確認するのかまで決めておくことが大切です。

バックアップについても、取得が成功していることだけで安心せず、定期的にリストア試験を行います。実際に復元できて初めて、バックアップが使える状態だと確認できます。

6. 実際の構築作業で意識した流れ

構築作業では、いきなりAzure PortalからVMを作り始めるのではなく、次の順序で進めると確認漏れを減らしやすくなります。

サーバの利用目的、処理件数、可用性、停止可能時間を確認する
VMサイズ、OS、ネットワーク、ディスク、監視、バックアップを設計する
Azure側とWindows Server側の設定値をパラメーターシートへまとめる
検証環境で構築し、手順と設定値を確認する
検証結果を設計書と構築手順書へ反映する
本番環境を構築し、作業前後の証跡を取得する
正常系だけでなく、通信断、サービス停止、再起動、リストアを試験する
監視、定期作業、障害対応の手順を運用担当者へ引き継ぐ

特に大切だと感じたのは、設定値だけでなく「なぜその設定にしたのか」を残すことです。

たとえば「VMサイズはD4s_v5」とだけ記載すると、後から見た人は選定理由が分かりません。「並列ジョブ数と性能試験時のCPU使用率を基に選定した」と書いておけば、将来サイズ変更を検討する際の材料になります。

7. 構築後に確認したい項目

Windows Serverへ接続した後は、画面から確認するだけでなく、PowerShellでも基本情報を取得しておくと便利です。

# OS情報
Get-ComputerInfo |
    Select-Object CsName, WindowsProductName, WindowsVersion, OsBuildNumber, OsLastBootUpTime

# CPU・メモリ情報
Get-CimInstance Win32_ComputerSystem |
    Select-Object NumberOfLogicalProcessors, TotalPhysicalMemory

# IPアドレス、DNS情報
Get-NetIPConfiguration

# ディスク情報
Get-Volume |
    Select-Object DriveLetter, FileSystemLabel, FileSystem, Size, SizeRemaining

# タイムゾーン
Get-TimeZone

コマンド結果はテキストで保存しておくと、検証環境と本番環境の比較や、設定変更前後の差分確認がしやすくなります。

8. 手順書を作るときに気を付けたいこと

構築手順書には、「○○を設定する」という操作だけでなく、次の内容も記載します。

作業を開始できる条件
作業による影響
入力する設定値
設定後の確認方法と想定結果
エラーになった場合の対応
切り戻し方法

また、環境ごとの設定値は本文へ直接埋め込むより、パラメーターシートにまとめた方が管理しやすくなります。

項目	開発環境	検証環境	本番環境
VM名	`dev-if-01`	`stg-if-01`	`prd-if-01`
VMサイズ	`Standard_D2s_v5`	`Standard_D2s_v5`	`Standard_D4s_v5`
サブネット	開発用	検証用	本番IF用
バックアップ	任意	有効	有効

Qiitaなどへ記事を公開する場合は、実際のIPアドレス、ホスト名、アカウント、顧客名、構成図、ログをそのまま載せないようにします。画面キャプチャの隅に機密情報が残っていないかも、投稿前に確認が必要です。

9. まとめ

Azure上でWindows Serverを構築する場合、Azure Portalの操作だけでなく、その後の運用まで考えて設計する必要があります。

今回整理した内容を簡単にまとめると、次のようになります。

IF、Web、APサーバはDシリーズを基準に、処理特性に応じて調整する
CPU負荷が高い処理ではFシリーズ、メモリを多く使う処理ではEシリーズも検討する
DBサーバはメモリだけでなく、ディスクI/Oとライセンスも確認する
VMサイズは最初から固定せず、性能試験や監視結果を基に見直す
設計書には設定値だけでなく、選定理由も残す
バックアップは取得結果だけでなく、実際に復元できることを確認する

実際に構築へ関わってみて、インフラ構築は「サーバを作成できたら終わり」ではないと改めて感じました。

障害が発生したときに調査できること、データを復旧できること、ほかの担当者でも同じ手順で作業できることまで考えて、初めて運用可能なサーバになると思います。

今後は、今回整理した内容を基に、Azure Portalを使ったWindows Server VMの作成手順や、構築後の確認項目についてもまとめていきたいと思います。

10. 参考資料