次の方法で共有


Azure Cloud Services (クラシック) の概要

重要

Cloud Services (クラシック) は、2024 年 9 月 1 日をもって、すべてのお客様に対して非推奨になりました。 実行中の既存のデプロイはすべて Microsoft によって停止およびシャットダウンされ、2024 年 10 月以降、そのデータは永久に失われます。 新しいデプロイでは、新しい Azure Resource Manager ベースのデプロイ モデル、 Azure Cloud Services (延長サポート) を使用してください。

Azure Cloud Services は、サービスとしてのプラットフォーム (PaaS) の 1 つの例です。 このテクノロジは、Azure App Service と同様に、スケーラブルで信頼性が高く、運用コストが低いアプリケーションをサポートするように設計されています。 App Service と同様に、Azure Cloud Services も仮想マシン (VM) 上でホストされます。 しかし、VM に対してより細かな制御を行うことができます。 Azure Cloud Services を使用する VM に独自のソフトウェアをインストールし、それらにリモートでアクセスできます。

Azure Cloud Services の図

コントロール能力の高さは、使いやすさが低下することも意味します。 より多くの制御オプションが必要でない限り、通常は、App Service の Web Apps 機能の方が、Azure Cloud Services よりも短時間で容易に Web アプリケーションを稼働させることができます。

Azure Cloud Services ロールには、次の 2 種類があります。 2 つの唯一の違いは、VM でロールがホストされる方法です。

  • Web ロール: インターネット インフォメーション サービス (IIS) を介してアプリを自動的にデプロイおよびホストします。

  • worker ロール: IIS を使わず、アプリをスタンドアロンで実行します。

たとえば、単純なアプリケーションでは、web ロールを 1 つだけ使用して web サイトにサービスを提供している場合があります。 もっと複雑なアプリケーションでは、Web ロールを使用してユーザーからの受信要求を処理し、次にそれらの要求を worker ロールに渡して処理を行っている場合があります (この通信は、Azure Service Bus または Azure Queue Storage を使用する可能性があります)。

上記の図に示すように、1 つのアプリケーションのすべての VM は同じクラウド サービスで実行されます。 ユーザーは 1 つのパブリック IP アドレスを通してアプリケーションにアクセスし、要求はアプリケーションの VM 間で自動的に負荷分散されます。 プラットフォームは、ハードウェアの単一障害点を回避するように、Azure Cloud Services アプリケーションで VM をスケールおよびデプロイします。

アプリケーションは VM で実行しますが、Azure Cloud Services はサービスとしてのインフラストラクチャ (IaaS) ではなく PaaS を提供することを理解することが重要です。 次の例を考えてみましょう。 Azure Virtual Machines のような IaaS では、アプリケーションが実行する環境を最初に作成して構成します。 次に、この環境にアプリケーションをデプロイします。 この方法では、パッチが適用された新しいオペレーティング システムのバージョンを各 VM にデプロイするなど、ほとんどの管理をユーザーが担当します。 それに対し、PaaS では環境が既に存在するかのように管理できます。 ユーザーはアプリケーションをデプロイするだけで済みます。 オペレーティング システムの新バージョンのデプロイをはじめ、実行するプラットフォームの管理がユーザーに代わって処理されます。

スケーリングと管理

Azure Cloud Services では、ユーザーは仮想マシンを作成しません。 代わりに、"Web ロール インスタンスを 3 個"、"Worker ロール インスタンスを 2 個" のように、それぞれがいくつ必要かを Azure に指示する設定ファイルを提供するだけで、プラットフォームがそれらを自動的に作成します。 その場合も、バッキング VM の サイズ を選択する必要がありますが、自身で明示的に作成する必要はありません。 アプリケーションが高い負荷を処理する場合は、追加の VM を要求すると、Azure がそれらのインスタンスを作成します。 負荷が減少した場合は、それらのインスタンスをシャットダウンして支払いを停止できます。

Azure Cloud Services アプリケーションは通常、2 つの手順から成るプロセスで利用可能になります。 最初に、開発者はプラットフォームのステージング領域に アプリケーションをアップロード します。 アプリケーションを稼働する準備が整ったら、Azure Portal を使用して運用とステージングを切り替えます。 ステージングと運用の切り替え にはダウンタイムが生じないため、ユーザーに支障を与えることなく、実行中のアプリケーションを新バージョンにアップグレードできます。

監視

Azure Cloud Services は監視も提供します。 Virtual Machines と同様に、故障した物理サーバーを検出し、そのサーバーで実行していた VM を別のマシンで再開します。 さらに、Azure Cloud Services はハードウェアの故障だけではなく、エラーが発生した VM やアプリケーションも検出します。 Virtual Machines と異なり、各 Web ロール内と Worker ロール内にエージェントが含まれているので、エラーが発生したときに、新しい VM とアプリケーションのインスタンスを開始できます。

PaaS という Azure Cloud Services の本質には、他の含意もあります。 最も重要なことの 1 つは、このテクノロジを基に構築するアプリケーションは、いずれかの Web または Worker ロール インスタンスでエラーが発生しても正常に実行するように記述する必要があることです。 この目標を実現するには、Azure Cloud Services アプリケーションがそれ自体の VM のファイル システムで状態を維持しないようにする必要があります。 Virtual Machines で作成された VM と異なり、Azure Cloud Services VM への書き込みは永続的ではありません。 Virtual Machines のデータ ディスクのようなものはありません。 Azure Cloud Services アプリケーションはすべての状態を Azure SQL Database、BLOB、テーブルか、その他の外部ストレージに明示的に書き込む必要があります。 この方法でアプリケーションを構築すると、スケーリングしやすく、障害への耐性が高くなります。 スケーラビリティと回復性は、どちらも Azure Cloud Services の重要な目標です。

次のステップ