AzurePaaS研究サイト

AzurePaaS研究サイト

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

MicrosoftAzureの用語を解説(基礎編)

 

Azure用語を覚えるならこの本をオススメします


 
 
 
以下の用語説明は公式ドキュメントなどをコピーしたものではなく、私がAzureを勉強・利用して理解した内容をできるだけ自分の言葉で説明した内容になりますので、そのつもりで読んでいただけると幸いです。
 
 

サブスクリプション

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

 
   

リソースグループ

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

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のトップページ

 
 

KuduのEnvironmentのページ

 

スペック変更

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

スケールアップ

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

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

スケールダウン

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

スケールアウト

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

スケールイン

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

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