Azure Portal サイト

クラウドサービスの Azureを学んで、仕事に活用するサイト

Microosft Azure の用語を覚えよう(基礎編)

サブスクリプション

 

Azure の契約単位

課金額の請求は、サブスクリプションごとに行われる。
1つのユーザが複数サブスクリプションを持てる。
Azure を使いだすときは、まずサブスクリプションを作って、作ったサブスクリプションの中に作成したリソースがぶらさがっていく。

登録メールアドレスに、以下のメールが届きます。
SubscriptionID が記載されていますね。

f:id:nanacy7741:20200126215005p:plain

 
   

リソースグループ

 

リソースのひとまとまり

サブスクリプションの中に複数登録・存在するもの。
・"本番用" のリソースグループ
・"試験用" のリソースグループ
・"機能A用" のリソースグループ
・"機能B用" のリソースグループ
というように、各プロジェクトで決めた、まとまりごとにリソースを整理できます。
 
名前は "日本語" にもできますが、この記事のようなことがあるので、名前を決める際はすべて "英名" が推奨です。
リソース名が、サーバのパス上に使われる可能性があるため、日本語は控えた方がよいという話です。

www.azureportal-site.com

 
 

リージョン

 

リソースが稼働するサーバの場所

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

料金プラン

 

App Service プラン

App Service プランを作る=VM サーバをレンタルするイメージ

サーバ自体を借りることになるので、複数アプリケーションをデプロイすることができます。 選択するプランごとに、レンタルするサーバの「スペック」「サポートレベル」などが異なります。

App Service プラン

https://azure.microsoft.com/ja-jp/pricing/details/app-service/plans/

お金をかけずに Azure をテスト的に使いたい人は、Free(F1) を選択すればほとんどお金を請求されることなく利用できます。 ただし、作成できる App Service の数は 10 個までという制限があります。

f:id:nanacy7741:20200118162443p:plain

 
Basic / Standard 以上のプランは、App Service プランを作成した時点で課金が発生します。
ただし、App Service プランをひとつ作れば、複数の App Service を作成してそれぞれにアプリケーションをデプロイできます。
いくつでもできますが、App Service プラン(サーバ)のスペックは限られているので、スペックを超えて動作するとシステムエラーが発生します。
Basic は動作確認用のプランなので、システム公開するのであれば Standard 以上が必須になります。
 
 

従量課金制

Functions で選択できるプランで、App Service には存在しない。
アプリケーションが動作した分、CPU・メモリを使用した量によって課金されます。
Functions を作成・デプロイしただけでは課金されず、利用者にアプリケーションアクセスされると課金されます。
 
デメリットとしては、他ユーザと同じインスタンス上でアプリケーションが動作するので、 ・アプリケーションごとの CPU 使用率の取得などができない
・インスタンスのスペックが選べない
・アプリケーションの起動に少し時間がかかる
 
 

Application Insights

 

docs.microsoft.com

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

qiita.com

 
 

Kudu

 

リソース管理ツール

App Service のファイルなどのリソースを管理できるツールです。

デプロイされているファイル一覧をみれます。
ファイルの追加・削除ができます。
ファイルの内容をみれて、編集もできます。

■ 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

 
 

スペック変更

 

インスタンス=仮想サーバ

まず、仮想サーバ・仮想マシンのことを、インスタンスと呼んでいます。
そのインスタンスをスペックアップさせたり、台数を変更したりする設定について説明します。
Azure ではデフォルトでロードバランサーが組み込まれているため、複数のインスタンスを稼働すると、自動で負荷を分散してくれたりします。
 
 

スケールアップ

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

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

スケールアウト

インスタンス数を増やす

DB サーバのように排他的に書き込み要求を、処理する必要がある場合は、スケールアウトではなくスケールアウトがオススメです。
App Service が動作するインスタンス数はデフォルトで1つ。
アプリケーションを2倍のパワーで動作させたい場合は、スケールアウトします。
インスタンス数を、1→2台、1→5台、5→10台のように増やすことができます。

"自動スケール機能" を使うと、条件(CPU使用率が80%を超えたら)を満たした場合に、インスタンス数を1→3台に変更する。
という動作をするように設定できます。
 
 

スケールイン

インスタンス数を減らす

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