リソースグループのパラメータの意味が良くわからない&どう設計すべきかわからない
Azure上で仮想マシンを作成する際、リソースグループや、可用性セットなどわからない単語がいっぱいありました。この記事ではリソースグループというメニューについて、パラメータ毎に意味を調べたので記載しておきます。また、エンタープライズシステム向けにどのような観点から設計すべきかも個人的見解を記載してます
おすすめ構成について
少なくともシステム単位での作成は最低限すべき。さらに800インスタンス以上リソースグループ内に作成できないようなのでその点は考慮したほうがいいです。
システム単位にすべき理由:
作成可能なインスタンス数の制限があるので、システム以上に会社といかいう範囲でリソースグループ使っちゃうと制限に引っかかってアウトになるかも。
上記以上にリソースグループの単位を細分化すべきかというと無駄に増えてもめんどくさいので上記くらいでいいかなと。
おすすめしないケース
リージョン毎にリソースグループを作成すると、リージョン跨ぎのリソースをどこのリソースグループに参加すべきか考えちゃうのであんまりやらないほうがいいかなと思いました。
##命名規則
RG-[systemname]-[3digit number]
例として、RG-hashimoto-001
とかでいいっしょー。
そもそもリソースグループとは?
MS社の説明は”通常は、同じライフサイクルを共有するリソースを同じリソース グループに追加して、グループとして簡単にデプロイ、更新、および削除できるようにします”とありますが・・・よくわかんねぇ。
リソースグループ単位でシステムリソースを任意の単位でグループ化し、操作できるもののようです。具体的にはリソースグループ単位で課金情報や、アクティビティログ、システムリソース一覧を参照できたり、削除、アクセスの制御ができるのできちんと設計すると運用で便利です。リソースグループより上位レイヤにあたるサブスクリプションをシステムカット、もしくはそれより小さい単位で用意すればよいかなという印象です。
個人的にはシステム担当者にサブスクリプション単位で環境を渡してその中でやりくりしてもらうのがいいかなと思いました。
サブスクリプション
別記事にサブスクリプションを説明してますのでそちらをご確認ください。
今回のリソースグループをどのサブスクリプションに作成するかを指定するものです。
場所
このリソースグループという情報自体が管理保管される場所を指定する必要があるようです。正直どこでもいいですし、なにか後の設計や構築に依存するものでもないようです。
たとえば、リソースグループが管理する仮想マシンリソースの場所がリソースグループで指定した場所で固定されるということもありません。仮想マシンの作成場所は仮想マシン作成時に別途指定可能です。ただ、SSHキーはリソースグループと同じ場所に強制的に作成されます。こんなの正直どうでもいいからMS側でいい感じに管理しろよって思いますけど、これをわざわざ指定しなければならないユースケースや要件ご存じでしたらお知らせください。あんまり詳しくないですけど、データ格納先の地理的制約を受ける法律要件が厳しいヨーロッパ圏のシステムは気にすべきかも。