AzurePaaS研究サイト

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

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

 

Azure 用語を覚えるならやっぱりこの本


 

サブスクリプション

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

f:id:nanacy7741:20200126215005p:plain

 
   

リソースグループ

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

www.azureportal-site.com

 
 

リージョン

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

料金プラン

 
AppService/Functions の料金プランについては、以下の記事にすべて書きました。

www.azureportal-site.com

 

Application Insights

 
アプリケーション内にログ出力を実装すると、プログラムから任意のログを Azure プラットフォーム上に送信することができます。
送信したログデータは Azure プラットフォーム上に保存されています。
送信して保存されているログデータを使って Azure Portal 上から解析・調査することができます。
 

docs.microsoft.com

 
 
何でもかんでも Application Insights で Azure 側に送っていると課金額が膨らんでしまう可能性がある、という記事を共有しておきます。

qiita.com

 
 

Kudu(SCMサイト)

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

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

■ AppService URL
https:// <<AppService名>>.azurewebsites.net/

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

■ Kudu(SCMサイト) の URL
https:// <<AppService名>>.scm.azurewebsites.net/
 
 

Kudu の トップページ

f:id:nanacy7741:20200118152937p:plain

 
 

Kudu の Environment のページ

f:id:nanacy7741:20200118153344p:plain

 

スペック変更

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

スケールアップ

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

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

スケールダウン

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

スケールアウト

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

スケールイン

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

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