3.1コンピューティングサービス

アプリを動かすには「計算資源（コンピュート）」が要ります。Azure には複数の選択肢があり、選ぶ基準は前章のサービスモデルと同じ——自分でどこまで管理するか（制御）と、どれだけ任せて楽をするか（手間）のトレードオフです。仮想マシン のように OS まで自由に握れるものから、Azure Functions のようにサーバーを一切意識しない（サーバーレス）ものまで幅があり、要件に応じて使い分けます。

3.1.1仮想マシン（VM）

Azure Virtual Machines は IaaS の中核で、OS から上（ミドルウェア・アプリ・データ）を自分で管理できる最も自由度の高いコンピュートです。Windows/Linux を選び、サイズ（CPU/メモリ）を決め、必要なソフトを自由に入れられます。その代わり、OS のパッチ適用やバックアップなどの運用は自分の責任です。既存サーバーをそのまま移すリフト＆シフトや、特殊なソフト構成に向きます。

3.1.1.1VM の拡張と可用性

• 仮想マシンスケールセット（VMSS）：同一構成の VM を多数まとめて管理し、負荷に応じて自動スケール（台数増減）できる。
• 可用性セット（availability set）：VM を障害ドメイン（電源/ネットワークの単位）と更新ドメイン（メンテの単位）に分散し、ハード障害や計画更新でも一斉停止を避ける（同一リージョン内）。
• 可用性ゾーン（availability zone）：VM をリージョン内の物理分離DCに分散し、データセンター単位の障害に耐える（可用性セットより広い保護）。
• Azure Virtual Desktop（AVD）：クラウド上に Windows デスクトップ/アプリを提供し、どこからでも安全に利用できる（VDI）。

紛らわしいのが VMSS（スケール） と 可用性セット/ゾーン（可用性） の役割分担です。VMSS は「台数を増やして負荷をさばく」ためのもの、可用性セット/ゾーンは「1つ壊れても止めない」ためのもの。守りたいのが性能（さばく力）か、可用性（止まらなさ）かで使い分けます（両立も可能）。

3.1.2コンテナ

コンテナ は、アプリと必要な依存をひとまとめにした軽量な実行単位で、VM より起動が速く可搬性に優れます。Azure では用途で2つに分かれます。Azure Container Instances（ACI） は、オーケストレーションの手間なく単発・手軽にコンテナを動かす用途。Azure Kubernetes Service（AKS） は、多数のコンテナを本番運用するためのマネージドな Kubernetes（自動配置・自己修復・スケール）。「小さく手軽なら ACI、大規模な本番運用なら AKS」が目安です。

3.1.3App Service とサーバーレス

Azure App Service は、Web アプリや API を PaaS で手早くホストするサービスです。OS やパッチをプロバイダーが管理するため、コードのデプロイに集中でき、スケールや独自ドメイン/TLS も簡単に扱えます。

Azure Functions は サーバーレス（FaaS） の代表で、HTTP 要求やキュー投入などのイベントが来たときだけ関数を実行し、実行した分だけ課金されます。待機中の費用がほぼゼロで、断続的な処理・自動化・通知に向きます。App Service が「アプリを常時ホスト」なら、Functions は「イベント時だけ動く小さな処理」と捉えると区別できます。

3.1.4この節のまとめ

• VM（最も自由・IaaS）。拡張はVMSS（自動スケール）、可用性は可用性セット/ゾーン
• ACI（手軽なコンテナ）／AKS（マネージド Kubernetes）／App Service（Web の PaaS）
• Functions＝サーバーレス（イベント駆動・使った分だけ）。AVD＝クラウドデスクトップ
• 選択は制御⇔手間の軸。1システムでも複数を適材適所で組み合わせる