AzurePaaS研究サイト

~理解しずらい情報をシンプルにお伝えします~

Microsoft Azure の用語を解説(基礎編)

サブスクリプション

 
簡単にいうと、Azure の契約単位のことです。
課金額の請求は、サブスクリプションごとに行われます。
 
Azure を使いだすときは、まずサブスクリプションを作って、作ったサブスクリプションの中に作成したリソースがぶらさがっていくイメージです。
 
また、ひとつのユーザが複数のサブスクリプションを持てます。
 
課金精算については、登録メールアドレスに、以下のメールが届きます。
どのサブスクリプションについての請求なのかは、SubscriptionID でわかるようになってます。

f:id:nanacy7741:20200126215005p:plain

 
   

リソースグループ

 
わたしのリソースグループを説明した記事を参照ください。

www.azureportal-site.com

 
 

リージョン

 
リソースが稼働するサーバの場所のことです。
 
リソースグループ・App Service を作成する際に、指定するもので、日本人が日本でシステム構築するなら、東日本(japan east)・西日本(japan west)のどちらかを選択するのが一般的です。
海外を選択した方が安くなることはなく、通信速度が遅くなる可能性があります。
 
 

料金プラン

 

www.azureportal-site.com

 

Application Insights

 

docs.microsoft.com

アプリケーション内にログ出力を実装すると、プログラムから任意のログを Azure プラットフォーム上に送信することができます。
送信したログデータは Azure プラットフォーム上に保存されています。
送信して保存されているログデータを使って Azure Portal 上から解析・調査することができます。
 
 
何でもかんでも Application Insights で送っていると課金額が膨らんでしまう可能性がある、という記事を共有しておきます。

qiita.com

 
 

Kudu

 
リソース管理ツールのことで、AppService/Functions でデプロイしたファイルなどのリソースを管理できるツールです。
 
デプロイされているファイル一覧をみれたり、ファイルの追加・削除もできます。
ファイルの内容をみれて、直接編集することもできます。

アクセス方法(URL)について

■ App Service URL
https://{app service name}.azurewebsites.net/

App Service の URL に ".scm" を付けると、App Service の Kudu にアクセスできます。

■ Kudu の URL
https://{app service name}.scm.azurewebsites.net/
 
 

Kudu の トップページ

f:id:nanacy7741:20200118152937p:plain

 
 

Kudu の Environment のページ

f:id:nanacy7741:20200118153344p:plain

 

スペック変更

 
まず、AppService/Functions のアプリケーションが実行されてる仮想サーバ・仮想マシンのことを、インスタンスと呼んでいます。
そのインスタンスについて、より高いスペックのインスタンスを使用したい場合や、たくさんのリクエストを同時に処理させたい場合にインスタンス自体の台数を増やしたいときなどに、スペック変更を行います。
 

スケールアップ

インスタンス自体のスペックアップ

Web サーバのように大量の読み取り要求を同時並行で処理する場合は、スケールアウトではなくスケールアップがオススメです。
単純にいうと、App Service プラン変更のことです。
App Service プランを変更すると、アプリケーションが動作しているサーバ側のインスタンス自体のスペックをあげることができます。
インスタンス数は変わりません。

スケールダウン

スケールアップの反対で、プランを下げること。
 

スケールアウト

インスタンスの台数を増やすことです。
 
AppService/Functions にリクエストが送られたときに最初に受け取っている FrontEnd のところにロードバランサーが組み込まれているため、WebWorker 側で複数のインスタンス構成をしていると、自動で負荷を分散しながらリクエストを転送してくれたりします。
 
DBサーバのように排他的に書き込み要求を、処理する必要がある場合は、スケールアップではなくスケールアウトがオススメです。
 
リクエストが多い場合に、アプリケーションを2倍の人力で動作させたい場合は、スケールアウトします。(パソコンのクアッドコアのように、コア数を増やすイメージです)
インスタンス数は、1→2台、1→5台、5→10台のように増やしていくことができます。
 
自動スケール機能を使うと、
条件(CPU使用率が80%を超えたら)を満たした場合に、インスタンス数を1→3台に変更する。
という動作をするような設定もできます。
 

スケールイン

スケールアウトの反対で、インスタンス数を減らすこと。
 
スケールアウトにより台数を増やしたものの、たとえばリクエスト数が落ち着いて負荷が下がったら、スケールインでインスタンス数を減らしたります。
 
 
以上です。

ご意見・ご要望はこちらへ