Azure研究サイト

Azure研究サイト

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

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

 

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


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

サブスクリプション

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

 
   

リソースグループ

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

www.azureportal-site.com

 
 

リージョン

リソースが稼働するサーバの場所のことです。
 
リソースグループ・AppServiceを作成する際に、指定するもので、日本人が日本でシステム構築するなら、東日本(JapanEast)・西日本(JapanWest)のどちらかを選択するのが一般的です。
 
海外を選択した方が安くなることはなく、アプリケーション処理の応答時間が長くなる可能性があります。
 
 

料金プラン

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

www.azureportal-site.com

 

Application Insights

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

docs.microsoft.com

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

qiita.com

 
 

Kudu(SCM)サイト

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

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

■ AppServiceのURL
https:// <<AppService名>>.azurewebsites.net/
 
■ Kudu(SCMサイト)のURL
https:// <<AppService名>>.scm.azurewebsites.net/
※ AppServiceのURLに .scm を付けると、AppServiceのKuduサイトにアクセスできます。
 

Kuduのトップページ

 
 

KuduのEnvironmentのページ

 

スペック変更

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

スケールアップ

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

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

スケールダウン

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

スケールアウト

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

スケールイン

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

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


/*--------------------------------------------------------------------*/