Azure Stack のキャパシティを管理する
azurestack
Published: 2018-12-15

はじめに

本エントリーはMicrosoft Azure Stack Advent Calendar 2018の15日目です。

本日のエントリでは、Azure Stack のキャパシティを管理する方法をまとめます。

有限のキャパシティ

パブリッククラウドのキャパシティは有限です。クラウドを支える物理リソースが有限だからです。したがって、利用者に自由にリソースを作らせてしまうと、特定ユーザのためにパブリッククラウド全体のキャパシティが枯渇してしますリスクがあります。

そのため、パブリッククラウド事業者は、利用者が利用できるリソースを制限しています。Azure ではクオータという仕組みを利用して、利用者が利用できるリソースを制限しています。たとえば、私が個人で契約している Azure のサブスクリプションには、1つのリージョンに作成できる vCPU の数が20に制限されています。他にもさまざまなリソースが制限されています。全てはキャパシティの枯渇を防ぐためです。

サブスクリプションに設定されているクオータ

Azure Stack のキャパシティ管理

Azure と一貫性のある Azure Stack も、Azure と同じ考え方がとられており、クオータを利用して利用者が利用できるリソースを制限する実装がなされています。リソースを制限する際に利用する機能が次の4つです。

  • クオータ
  • プラン
  • オファー
  • ユーザ サブスクリプション

クオータ

クオータとは、利用できるリソースの上限を定義したものです。コンピュートのクオータやストレージのクオータ、ネットワークのクオータなどサービスごとにクオータが存在します。各クオータでは、上限を設定できるリソースの種類が決まっています。たとえばコンピュータのクオータでは仮想マシンの数やコア数などの上限を設定できます。

コンピュートのクオータ

ネットワークのクオータ

クオータで利用できるリソースの種類の詳細は次の URL に記載されています。

参考:Azure Stack のクォータの種類

プラン

ブランとは、各種サービスのクオータを意味のある粒度でまとめたものです。利用できるリソースが少ない各サービスのクオータをまとめて「お試しプラン」を作ったり、ストレージのクオータだけを持つ「ストレージだけ使えるプラン」というキワモノを作ったりできます。

下図は、Azure Stack のすべてのサービスが利用できるプランです。1つのオファーの中にサービスごとのプランが含まれていることが分かります。

全サービスが使えるプランの例

オファー

オファーとは、プランを利用者に提供するためのものです。オファーは1つ以上のプランで構成されています。上記の「お試しプラン」を利用者に提供するためには、「お試しプラン」を利用した「お試しオファー」を作る必要があります。

オファーには2つの種類があります。1つ目は Public です。Public なオファーは利用者に公開されて。後述するユーザサブスクリプションの作成に使われます。もう一つが Private です。Private なオファーは利用者に公開されません。

Public なオファーと private なオファー

利用者に公開されるPublic なオファー

ユーザサブスクリプション

ユーザーサブスクリプションとは、利用者とオファーをつなぐためのものです。ユーザサブスクリプションを所持する利用者は、Azure Stack にリソースを作成できます。Azure を利用する際に、まずはじめにサブスクリプションを取得するのと同じです。

管理者が Public なオファーを用意していれば、利用者が利用者自身で Public なオファーを購読してユーザサブスクリプションを作成できます。誰でも Azure Stack を使い始められます。セルフサービスを推進するのであれば、Public なオファーを用意しておくとよいでしょう。

利用者に公開されるPublic なオファー

一方で、Private なオファーの場合は、管理者がユーザサブスクリプションにオファーと利用者を明示的に設定します。管理者によるサブスクリプション作成が必須なため、利用者が Azure Stack を使い始めるまでに待ち時間が発生してしまいます。そのかわり、管理者が Azure Stack のキャパシティを把握したうえで利用者へのリソースを割り当てられるというメリットがあります。

管理者側にのみ表示される Private なオファー

制限を超えると?

利用者がクオータで割り当てた制限を超えてリソースを作ろうとした場合、その要求は失敗します。例えば 、利用者が、Public IP Address の上限が0になっている Plan が割り当てられているユーザサブスクリプションを利用して Public IP Address を作ろうとすると、次の図のようにエラーになります。

デプロイがエラーになる

まとめ

本日のエントリでは、キャパシティを管理する仕組みであるクオータとプラン、オファー、ユーザサブスクリプションについてまとめました。利用者に沢山のキャパシティを与えると基盤の上限を超えてしまい利用者全体に迷惑がかかります。一方で、制限を厳しくしすぎるとセルフサービスのメリットが失われてしまいます。組織のあり方とAzure Stack の使い方を踏まえて、良い塩梅を見つけて運用しましょう。