「Azureサブスクリプション設計:サブスクリプションとは」の記事に引き続き、第2回はサブスクリプションを含めたAzure内部の管理体系とその使いこなしの話です。Best Practiceまでには至っていませんが、弊社内の経験も交えて検討ポイントを洗い出していきます。
第1回 EA Azureサブスクリプション設計:Azureのサブスクリプションとは
2016/1/5追記
本記事執筆時点で未知だったのですが、現在ではアカウントに対して、「コストセンター(CC)」や「部署名」を追加で定義できます。ea.azure.comにエンタープライズ管理者でアクセスすることで請求金額等が閲覧できますが、その際に上記追加定義を使っていると、課金のくくりとして使えるようになっているようです。このあたりをうまく使うことで、もう1階層管理単位を作ることができるようになっているので、より柔軟にコスト管理ができそうです。こちらで試せていませんので、こんな書き方になっていてすいません。(汗;
管理の体系
Azure サブスクリプションの管理で、ググるとこんな絵がよく出てきます。
Accountの下にSubscriptionが紐付いているのはわかるけど、「Enteprise Enrollmentって何?」という話です。
Enrollmentは「登録」とか「記載」の意味ですが、ピンときません。
MSさんのサイトに概要資料があるのですが、下記の通りです。
"With the Enterprise Agreement you can take advantage of various Enrollments. Enrollments are designed to help your organization license Microsoft solutions, delivered via on-premises licenses and/or cloud services."
「EA契約を締結すると、様々なEnrollmentにより利点が得られます。Enrollmentは、お客様のオンプレ環境のライセンスやクラウドサービスを通じて提供されるマイクロソフト社のソリューションを認可(License)することを支援するように作られています。」
ということで、最上位のレイヤでAzureが使える権利の登録(Enrollment)すなわちEA契約をしておくと、Azureが使えるんだ程度でさらっと流してしまいましょう。
Azure3つの管理者ロールと管理対象
・Enterprise Administrator (エンタープライズ管理者)
・Account Owner (アカウントオーナー)
・Service Administrator (サービス管理者)
上記3種類の管理者が管理する範囲は、下図の通りで、管理ツール(実体はポータルサイト)も個別に用意されています。
次は各管理者が行う管理業務ですが、簡単に書くと下記の通りです。
1. エンタープライズ管理者(Enterprise Administrator)*
・Accountの作成
・全てのAccountの使用量の把握
・複数の管理者を登録可能
・Azure上のコンピューティングリソースそのものを管理することはありません。
*:この管理者は、EA契約のみ存在します。一般的な従量課金契約のユーザには存在しません。
2.アカウントオーナー(Account Owner)
・Subscriptionの作成
・該当Accountの使用量の把握
・各Accountに一つのIDのみ(後述)
3.サービス管理者(Service Administrator)
・Windows Azure上に提供される各種のCloudサービスを作成
・Azure上のコンピューティングリソースという実体の管理業務を担うので、従来のシステム管理者の意味合いが含まれます。
FAQ
一部の用語が紛らわしくてわかりにくいと思いますので、具体例を挙げてFAQ的に書いてみました。
・「Account」の実体のイメージがつかないのですが?
Accountと書くと最初に思いつくのがユーザアカウントそのものですが、それではありません。
Accountに設定する内容は、だいたい下記の3つから検討されることが多いと思います。
1.部門(情報システム部、研究開発グループなど)
2.プロジェクトとかシステム群
3.開発、ステージング、本番などのランドスケープ用途別
要はなんでも設定できるのですが、あえて平たい言葉で説明するとすれば、
「Account」=Azureの利用量を「管理」する際の括りとか単位
とざっくりと捕えるのがよいと思います。
なおAccountの下位にはSubscriptionがあり、そこでもコスト明細が分けられますので、比較的大きな括りが適切かと思います。ちなみに弊社では部門を採用しています。(ここに至った経緯は後述)
たまに部門横断でプロジェクト的に使うこともありますが、基本的にはどこかの部門がオーナーシップを持つ形で運用を回しています。
Accountを「プロジェクト名」とか「システム名」にして、複数部署に費用分担させるケースもあるかと思いますが、その際には分担ロジックをどうするかというのは先に方針を決めて設計しておかないと、いざ分けようとしたら簡単に分けられない!という事態になってしまいますので要注意です。
弊社の場合は社内のIT担当者が担当しています。実際の業務はAccountを作る際のAdmin作業のみです。複数登録できるのですが、EAの契約担当者も契約更改とかで使う可能性があり一応追加登録していますが、今のところ使っていません。なおAccount毎の使用量の把握は弊社の場合は別な仕組みでやっていることもあり、ここではやっていません。
「Account」のオーナーということで、Subscriptionを新たに振り出すことできます。
なお、アカウントオーナーは一人しか設定できません。Accountが部門だったらノリ的には部門長とかを設定することを考えますが、管理ポータルを触れないとまずいです。(操作自体は簡単ですが、Subscriptionを消したりもできますので、万が一誤って消したりすると大変なことになりますので要注意です。)
Azurer上に仮想マシンを作ったり、各種サービスを設定することになるので、Azureの管理ポータルを触れる技術担当者がいいと思います。ただ、仮想マシンの削除とか、VPNのセキュリティキー発行とか、サービス管理者と同様の役割を担う共同監理者を追加することができますので、使える権限は大変強いので配慮が必要です。
[RELATED_POSTS]
Microsoft アカウントと管理者の紐付け
Microsoftアカウントとは、Microsoftの各種製品やサービスを利用する際にこちらのWebサイトからオンライン登録して使うことができるMicrosoft の個人認証システム上のアカウントのことです。またアカウントが出てきて紛らわしいですのですが、これはユーザアカウントのことです。例外を除き、ほとんどの方はこれを登録してAzureを管理していくことになり、先にご説明した管理者(ロール)はMicrosoftアカウントと紐付けることになります。
Accountを部門にした場合の紐付け例:
一つ気をつけなくてはいけないことがあります。
複数のAccountに同一のMicrosoft アカウントを紐付けることはできません。
また、エンタープライズ管理者とアカウントオーナーとサブスクリプションは同一のMicrosoftアカウントが使えます。まとめると下図のようになります。
実際に複数のAccountに同一のMicrosoft アカウントを紐付けようとすると、Accoun追加時にこんな感じではじかれます。
当初は我々もよくわからなくて(当時はAccountとSubscriptionで2階層で管理できそうだからくらいの浅い知識のみ)、とりあえず設定して後から考えようと安易に考えていました。で、最初にやろうとしたのが全ての管理者を単一のMicrosoft アカウントにしちゃえという超安易策。(笑)
当初Accountをシステム、ランドスケープ名案も検討していたのですが、この件が判明した結果不採用です。理由は単純で、その分だけ新たにメールアドレスを乱発することになりそうからです。そもそもMicrosoftアカウントはメールアドレスがIDとなりますが、その際にはメールアドレスも登録し、かつMicrosoftアカウントに登録しててあげる必要があり、そもそも個人認証システムなので属人性を前提に考えると、そもそもAzureを設計した天才アーキテクトの超絶思考には合ってないのは明らかです。少なくともAccountとSubscriptionを単純な利用量の括り(単位)として同じに扱うのは厳しいのがわかりました。
弊社の場合はちょっと特殊かもしれませんが、Subscriptionにコンサルタント名を設定しています。弊社は本業が技術コンサルティングファームなので、各コンサルタント一人一人がオーナシップをもって様々な最新技術検証を随時行うこともあり、そもそも各システムのオーナーシップが明確です。また、Azureコストもどこの部門の誰が、毎月幾ら使っているかを明確にしたかったからです。
これ以外の注意事項としては、Subscriptionをいったん設定して、その中で作った仮想マシンとかサービスを別Subscriotionに後から移設することについては、先に下記の情報を見つけていました。場合によってはかなり手間がかかります。
サブスクリプション間のデータ移行手順について
http://blogs.msdn.com/b/dsazurejp/archive/2013/01/16/windows-azure-subscription-migration.aspx
念のため、MSさんにこの件を問い合わせてみました。
「Account以外で課金の括りをわけたいというときはSubscriptionをわけるしかないが、後からSubscriptionを変更することになると、最悪の場合手で移行しないといけなくなるので、お客様からするとなぜそんな大事な話を最初にガイドしてくれなかったのかと叱責を受けると思うのですが、どうですか?」と。回答としては、Subscription間の移行は契約変更とかのまれなケースと考えているとのことでした。
弊社の場合、新しい技術に着手する特攻メンバーが数年に渡って、雨の日も風の日も実機を触って、なんとかモノにします。なのでコスト管理の括り、実際の利用用途という意味で最も永続性があり意味を持つのが「個人」だったりしますので、Subscriptionに個人名を選択することで、Subscription間移行の可能性も最小にできると判断しました。
ちなみに一時的なシステムを構築する場合もプロジェクトなどで発生しますが、規模が小さければSubscription、ちょっと大きめであればAccount+Subscriptionも使ってます。(テンポラリの環境なので、ガチガチにしなくてもいいかと。)
「【手順詳細】Azureサブスクリプションを移行してみた」もご参考にしてください。
- カテゴリ: 技術情報