Azure VM・App Service・Functionsの違い｜管理する範囲と動かし方で整理

Azure Virtual Machines（VM）はOSから自分で管理する仮想マシン、App ServiceはWebアプリを動かすための管理された環境、Functionsは決めたきっかけで関数を実行するサービスです。 違いをつかむ軸は、「どこまで自分で管理するか」と「処理をどう動かすか」の二つです。

勉強会の申込ページや会場写真を扱う、架空の小さなアプリで考えてみましょう。サービスを選んで契約する記事ではなく、教材の説明を読み分ける練習です。Azureアカウントや実際の操作は必要ありません。

まず、何を用意して動かすのかを比べる

どれを使っても、データやアクセス権、アプリの安全性を考える仕事は残ります。Microsoftへ任せる範囲が広くなることと、利用者の管理がゼロになることは違います。クラウドの共同責任の説明

ここでは、App Serviceは組み込みランタイムを使う方式、Functionsはコードを配置して使う方式を中心に比べます。コンテナーやApp ServiceのManaged Instanceなど、管理範囲の異なる方式は含めません。ランタイムは、プログラムを動かすための実行環境のことです。App Serviceの提供方式

勉強会アプリの三つの相談で考える

同じ企画でも、担当者からは違う相談が出てきます。

• 「以前の申込アプリを動かすには、OSの設定や専用ソフトの導入が必要」
• 「対応する実行環境で動く申込Webアプリがある。OSの保守よりアプリの開発に集中したい」
• 「会場写真が保存先に追加されたら、一覧用の小さな画像を作りたい」

一つ目ではVMの管理範囲、二つ目ではApp ServiceのWebアプリ実行環境、三つ目ではFunctionsのトリガーに注目できます。これは次に読む資料を選ぶための例で、そのサービスで必ず動くと判定したものではありません。

三つを全部そろえる必要がある、という意味ではありません。VMでもWebアプリや写真処理を動かせます。できることが重なる中で、どの部分を自分で用意・運用したいかを考えます。

VM：OSの自由度と、保守する仕事を引き受ける

VMは、クラウド上で使う仮想マシンです。物理サーバーを自分で購入・保守せずに使えますが、その中のOSの設定、修正プログラムの適用、ソフトウェアの導入などは管理する必要があります。Azure VMの公式概要

先ほどの既存アプリなら、「どのOSが必要か」「何をインストールするか」「更新と動作確認を誰が担当するか」が最初の確認事項です。OSを細かく扱えることは、動かし始めた後の保守も考える、ということです。

保存先の学習で出てきたマネージドディスクは、VMのOSやデータを置く役割でした。今回はそのディスクを使う側で、アプリを実行するVMに注目しています。関係が曖昧なら、Blob・Files・マネージドディスクの違いで「動かすもの」と「保存するもの」を分けてみてください。

App Service：Webアプリを配置し、アプリ側を管理する

App Serviceは、WebアプリやAPIなどをホストするサービスです。対応する言語・実行環境を選び、アプリを配置して動かします。申込ページを持つWebアプリなら、その実行環境を調べる入口になります。App Serviceの公式概要

今回の範囲ではAzureがOSと組み込みの実行環境を管理します。一方、アプリのコード、使っているライブラリ、設定、データは自分たちで扱います。新しいランタイムへの移行が必要になる場合もあるため、「更新について何も考えなくてよい」とは覚えないようにしましょう。OSとランタイム更新の説明

また、Webアプリと一緒に出てくるApp Serviceプランは、そのアプリを動かす計算資源を定めるものです。単なる契約名のラベルではなく、利用できる機能や拡張方法にも関わります。App Serviceプランの公式説明

紙の学習メモには「Webアプリ」と「それを動かすプラン」を別々に書いてみると、教材の構成を読みやすくなります。

Functions：「何が起きたら、何をするか」を書く

Functionsでは、処理を呼び出すきっかけをトリガーと呼びます。HTTPリクエスト、決めた時刻、Blobへのファイル追加などをきっかけに、用意した関数を実行できます。Functionsの用途

会場写真の例なら、次の二行で整理できます。

• きっかけ：Blob Storageに新しい会場写真が追加された
• 処理：その写真を読み、一覧表示用の小さな画像を作る

Blob Storageは写真の保存先、Functionsは処理する側です。保存しただけで縮小画像が自動的にできるわけではなく、処理のコードやトリガー、接続先の設定が必要です。一つの関数には、一つのトリガーを定義します。トリガーの公式説明

Functionsは裏側の処理だけに限りません。HTTPトリガーを使ってAPIを作ることもできます。「画面から呼ばれる処理は必ずApp Service」とは分けず、アプリの構造と実行の仕方を読み取ります。

サーバーレスでも、実行条件は確認する

サーバーレスは、処理を実行するサーバーが存在しない、という意味ではありません。利用者が個々のサーバーの用意や保守を直接抱える部分を減らし、コードに集中できる仕組みです。コードやデータ、設定の管理は残ります。Functionsの概要・利用者に残る管理範囲

Functionsには複数のホスティング方式があり、処理の実行時間、負荷に応じた拡張、費用の決まり方は一律ではありません。App Serviceプラン上で関数を動かす方式もあります。「Functionsはすべて同じ時間で停止する」「使っていない間は必ず無料」とは判断しないでください。ホスティング方式の比較

長い処理を扱う教材では、関数そのものの実行時間と、HTTPの呼び出し元が応答を待てる時間も分けて確認します。ここではプランを選ばず、条件を読む場所があることを押さえれば十分です。

最後に、サービス名より先に二つの問いを書く

紙や手元のメモで、次の説明の手掛かりに線を引いてみてください。

1. 「OSへ専用ソフトを入れ、更新後の動作も自分たちで確認する」
2. 「対応ランタイムへ申込Webアプリを配置し、OSの保守はAzureへ任せる」
3. 「会場写真の追加をトリガーに、縮小画像を作る関数を実行する」

今回の比較では、順にVM、App Service、Functionsの考え方に対応します。1はOSからの管理、2はWebアプリの配置、3はトリガーと関数が手掛かりです。

次に、同じメモへ「自分で何を管理する？」「何をきっかけに、どんな処理をする？」と書き足してみましょう。サービス名だけ覚えるより、別の例にも当てはめやすくなります。

実際の選定には、対応する言語やOS、接続先、負荷、処理時間、運用体制、料金などの確認が必要です。今日の目標は、三つのうち一つを契約することではなく、教材を読んで次に確かめる条件を言えることです。

なお、AzureポータルやCLIは、こうしたリソースを管理する道具です。アプリを動かすサービスとの違いは、ポータル・CLI・PowerShell・Cloud Shellの整理で復習できます。

動かし方の候補を決めたら、料金計算ツール・コスト分析・予算通知の違いで、何を想定し何を記録するか整理できます。