今回作成したWeb Appsのサービスは、「Standard S1」という価格プランを「South Central US」リージョンで利用しています。これらはWordPressインストール時にデフォルトとして設定されていたものをそのまま使っただけで、特に積極的に選んだわけではありませんが。
利用するアプリの構成や想定されるトラフィック、負荷などによっては、もっと別のプランが向いていることもあります。
上の画面にある[スケールアップ]のメニューをクリックすると、他のプランに変更できます。以下にプランの選択画面を示しておきます。
価格レベルにはFree(無料)/Shared(共有)/Basic/Standard/Premiumというランクがあります。
価格レベルが高くなると、実行できるアプリ(プロセス)の最大数が増えたり、利用できるディスクサイズや最大インスタンス数が増えたりします。
またそれぞれの価格レベルに対して、例えばCPU/メモリが「1コア/1.75GB」「2コア/3.5GB」「4コア/7GB」といったように基本性能の違う3〜4種類の「サイズ」が用意されています。サイズが大きくなると、大きなアプリを同時に多数動かしたり、高速に動作させたりすることが可能になります。
Web Appsの価格は、上記の価格レベルとサイズによって決まりますが、最終的にはネットワークトラフィックの量や利用するストレージなどのサイズも加味して決められます。
ただ、CPUの利用状況(負荷状態)は価格には関係ないようです。CPUがほぼずっと0%近くになっていても、逆にずっと50%以上の高い負荷をかけて使用し続けていたとしても、料金は同じです(Freeプランは除く。詳細は後述)。
ならば、なるべくたくさんのWeb Appsを同居させて実行した方がお得なような気もします。でも、価格プランが1つだと、インスタンスやリソースなどが共通化されるので処理が遅くなったり、セキュリティ的に分離するのが困難になったりします。また例えばスケールアウトしようとすると、すべてのアプリがまとめてスケールアウトの対象となるので、(必要ないアプリまでスケールアウトして)無駄にリソースを消費することにもなりかねません。このあたりはケースバイケースで考える必要があるでしょう。
Web Appsの価格レベルが変わると、利用できる機能やリソースが増えますが、価格もかなり上がります。コストを抑えたければ、必要なリソース(CPUやメモリ)などをしっかり見積もったり、日々の課金情報をこまめに把握しておいたりする必要がありそうです。
ここで「インスタンス」について補足しておきます。
インスタンスとは簡単に言うと、Web AppsやLogic Appsなどのプロセスを実行するための実行環境です。例えば「Standard S1」という価格プランなら、「CPU 1コア/メモリ1.75GB」という環境になっています。
Web Appsなどのプロセスはこのインスタンスの中にロードされ、実行されます。StandardやPremiumプランなら、CPUやメモリなどのリソースが許す限り、インスタンス内にいくらでもアプリを同時にロードして実行できます(Freeプランだと10個、Sharedプランだと100個まで)。
もっと高速に動作させたり、大量のメモリを専有するプロセスを動作させたりしたいなら、より規模の大きいインスタンスに契約を変更する必要があります。このような強化の方法を「スケールアップ」と呼んでいます(1台のパソコンのCPUやメモリを増強して性能を上げようする方法ですね)。
これに対して、1つのWeb Appsなどのプロセスを複数のインスタンス上に展開して、同時並行で動作させることもできます(同時並行で実行するパソコンを増やして、性能を上げようとする方法ですね)。これを「スケールアウト」と呼んでいます。例えばStandard価格プランなら、最大10インスタンスまで利用できます。
複数のインスタンスを同時に実行するには、それなりにアプリ側での対応も必要ですが、インスタンスを増やすだけで済むなら簡単なので、できることなら利用したいところです。
ただしスケールアウトすると、当然ですが、その分料金は上がります。例えば、3インスタンスにすると3倍になります。コストを抑えるためには、常にスケールアウトするのではなく、負荷が増加したときだけとか、特定の時間帯だけスケールアウトして負荷増に備える、というような運用も必要になるでしょう。
スケールアウトを利用した柔軟な性能の調整は、クラウドサービスの最大の利点でもありますが、当然ながら高性能な状態で使うと、料金は増えることになります。料金を節約したいなら、ズボラな運用ではなく、必要な状況に応じた、きめ細かな対応が必要になります。
先ほどの価格プランを見ると、「Free(無料)」と「Shared(共有)」という2つの価格プランがあります。
Freeにすると、確かにインスタンスの料金は不要になりますが、利用できるCPU時間やメモリサイズ、Logic Appsの呼び出し回数、ネットワーク通信量、ストレージサイズなどに制限があります。例えば、1日当たりのCPU使用時間は60分までです。制限に達すると一定時間サービスが使えなくなります。実験的な用途で使うとよいでしょう。
Sharedは他の(ユーザーの)アプリと1つのシステムを共有して実行されます。SharedプランはBasicプランよりも安価ですが(約1000円/月)、Freeよりも緩いながらリソース制限がある他、アプリごとに課金されるプランとなっています(Basic以上は、アプリごとではなくインスタンスごとに課金)。アプリを1つ(WordPressなら1サイト)作るごとに、Sharedプランの料金がかかります。ごく限られた数の、負荷や必要リソースの少ないWebアプリしか実行しないような場合に向いています。
Azure VMの場合は、Azureのダッシュボード管理画面で[停止]しておくと、それ以上は課金されませんでした(連載第2回参照)。
しかしWeb Appsの場合は、管理画面にある[■停止]をクリックして動作を止めても、ずっと課金され続けます(実行準備のためにストレージなどのリソースを使用しているため)。
Web Appsではこのようになっているので、完全に課金を停止したければ、作成したWeb AppsやApp Serviceプランを削除する必要があります。次にまた使いたくなった場合は、アプリを作成し直すか、デプロイし直す必要があります。
VMの場合と違って、Web Appsではアプリを[■停止]しても課金はそのまま続きます。完全に課金を止めたければアプリやApp Serviceプランを削除する必要があります。アプリを停止したから料金はかからないと勘違いして、Web Appsをそのまま放置したりすると、後で料金を見てびっくりすることになるかもしれません。
ちなみに、停止中にWeb Appsのサイト(URL)にアクセスすると、次のようなエラー画面が表示されます。
今回はWeb Appsの料金や価格プランなどについて見てきました。1つのWeb Apps(WordPressなど)だけを動作させるなら、少々料金が高いかもしれません。しかし複数のWeb Appsアプリなどを動作させたいような場合は、うまく使うと、料金を下げてお得に利用できる可能性があります。ここでは触れていませんが、Azureで利用できるバックアップや負荷分散/障害対策機能なども含めて判断したいところです。
次回は、Azureサービスの管理/監視機能について見ていこうと思います。
Copyright© Digital Advantage Corp. All Rights Reserved.